azure-native.appconfiguration.KeyValue should use Azure AppConfiguration DataPlane instead of ARM Control Plane

[JiriKovar]

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

Hi,

it seems that the azure-native.appconfiguration.KeyValue (and probably other similar resources as well, possibly also KeyVaults) are using the ARM Control Plane, which is not recommended according to the feedback from the Azure collaborative engineer we were recently in touch with to resolve some rate limitation issues. It is recommended to use the Azure AppConfiguration DataPlane (via the configuration store endpoint) for all configuration settings interactions. This approach is generally advised for most scenarios as it offers significantly higher throttling limits compared to ARM.

The ARM control plane should primarily be used for configuration settings in the context of ARM template deployment scenarios.

The workaround for us right now is to split the workload to utilize multiple identities / multiple Azure subscriptions, which works fine, but I wanted to relay this suggestion to you.

Affected area/feature

AppConfiguration

[rquitales]

Thanks for informing us of the limitations of using ARM Control Plane and rate limits.

[EronWright]

Most resources in this provider are implemented using Azure Resource Manager (ARM). There is some support for "custom resources" that are not ARM-based, for example the Blob resource (see code).

The task here is assumedly to introduce new resource(s) representing the Azure App Configuration Data Plane REST API. Retrofitting into the existing resource is probably not practical, but if we can offer both approaches, the user would have choice.

[JiriKovar]

Hi @EronWright, when can we expect an update on this? Turns out, we are currently running ~700K requests/month on the ARM API of this kind, which is turning out to be a bit of an issue with the Azure rate limitation even with the aforementione workaround.

As for whether it would be retrofitted or implemented as a new resource: both would work for us, but I guess using the Azure AppConfiguration DataPlane should be the default that users should use.