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 Microsoft Intune with the link here. The previous article mentioned Microsoft 365 capabilities. This article discusses Azure App Configuration.

This is a service to centrally manage application settings and feature flags. Configuration settings must not be spread out across distributed components of an application or service hosted in the cloud because it can lead to hard-to-troubleshoot errors during an application deployment. App configuration must store all the settings for the application and secure their access in one place.

Unlike zookeeper, which is a co-ordination service with elements from group messaging, shared registers and distributed lock services and provides an interface to guarantee wait-free property and FIFO execution of requests from each client, the Azure App Configuration merely centralizes the configuration as a resource provisioned by a service that can perform access control. This lightweight conversion of configuration to a configuration service is just right to those clients that want to add a key-value or read a key-value from the store.

Azure App Configuration can be deployed using an Azure Resource Manager Template (ARM template) which is a json file that defines the infrastructure and configuration for the project. Azure App Configuration supports hierarchical namespaces, labeling, extensive queries, batch retrieval, specialized management operations, and a feature-management user interface. It is not meant to be a  KeyVault to store secrets and is usually complimentary to a KeyVault in most deployments. It provides hardened security for references to those secrets as configuration key-values.

App Encryption encrypts all key values it holds, and it encrypts network communication. Key name and labels are used as indexes for retrieving configuration data and aren’t encrypted.

It is different from Azure App Settings which allows to define app settings for each App service instance. The settings are passed as environment variables to the application code while the Azure App Configuration allows to define settings that can be shared across multiple applications. The application code accesses these settings through the configuration providers for .NET and Java, Azure SDKs or via REST APIs. Settings can be imported and exported between Azure App Settings and Azure App Configuration.

There’s a limit of 10 KB for a single key-value including its attributes, labels, tags and other metadata. This suffices for most configuration. If a key-value is larger than this, then it can be placed in a cloud store.

Configurations are generally created one store per environment such as development, integration and production environments. This provides the best security isolation.  If we do not need security isolation between environments, we can use labels to differentiate between configuration values.

Free and Standard tiers both provide core functionality, including config settings, feature flags, basic manage              ment operations, metrics and logs but if more than one store is required for a subscription, a standard tier provides unlimited number of stores. Each configuration store in a standard access tier can store up to 10GB and stores history for 30 days. Free tier stores are limited to 1000 requests/day while standard access stores are limited to 30000 requests per hour. Only the standard tier has an SLA and it is 99.9% availability. The first 200,000 requests to a standard tier are free but there is overage charge for requests past the daily allocation.