Azure App Configuration   

This is a continuation of a series of articles on Azure services from an operational engineering perspective with the most recent introduction to Azure App Configuration with the link here. This article elaborates on the best practices with Azure App Configuration.  

Application configuration is a regional service. Applications with different configurations per region are encouraged to create separate instances for each region so that they don’t introduce a single point of failure. Multiple configuration stores also help with disaster recovery mitigation. Regions and availability zones in Azure continue to guarantee high availability for this service just like that of other services. Regions are scattered throughout the globe and regions support multiple availability zones.   

There are two options for organizing keys – key prefixes and labels. Key prefixes are the beginning part of keys. A set of keys can be grouped by using the same prefix in their names. Prefixes can have folder paths like separators and qualifications. Keys are what the application code references to retrieve the values of the corresponding settings. Labels are an attribute on keys and they are used to create variants of a key. A version might be an iteration, an environment, or some other contextual information.  

App Configuration treats all keys stored with it as independent entities App configurations don’t attempt to infer any relationship between the keys. Aggregation is made possible with the help of labels. Application code can perform configuration stacking. Any configuration data can be stored such as those that are kept as configuration files or environment variables. For large or sensitive data, it is preferable to store it in other stores or key vaults and save only the references as configuration keys and values. A connection string can be used to access an app configuration store. Managed identities can be used to access the App configuration store.  

Excessive requests made to App Configuration can result in throttling or overage charges. Requests can be reduced by increasing the refresh timeout, watching a single sentinel key, using Azure Event Grid to receive notifications when configuration changes, and spreading requests across multiple app configuration stores. There is an option to bulk import the configuration settings from the current configuration files using either the portal or CLI. The same option can be used to export key values from app configuration. 

Client applications demonstrate two common risks. First, they use a connection string that is exposed to the public, and second, the scale of the requests from client applications can be excessive. It is recommended that a proxy be used instead between the applications and the app configuration store. The proxy service can securely authenticate with the app configuration store without a security issue of leaking the authentication information. App configuration provider libraries enable writing such a proxy service and come with a built-in cache. 

When the configuration is checked in as code in a git repository, it gives the benefits like traceability and approval process for changes. There are tools to deploy this configuration data. App Configuration syncs GitHub action synchronizes the app configuration whenever a pull request is merged to the configuration as a code repository. Azure Dev Ops can include Azure App Configuration push for synchronization which is a pipeline task. Similarly, Azure App configuration uses Azure CLI as part of the CI/CD system to import configuration files.