How to handle application-specific settings in the Azure App Service platform?

There are multiple ways to handle application-related settings when using Azure App Service. Typically application needs ex. database connection string and authentication-related parameters which should be able to change without deploying the application again. This blog post presents a comparison of typical ways to handle application settings in Azure App Service.

1. App Service Configuration (App Settings)

In this setup, all application settings are handled via Azure Portal (App Service > Configuration > App Settings).

Pros

• App settings can be easily changed in Azure Portal and changes are applied quickly. Note! saving changes causes the application pool to recycle.
• Allows to use of complex configuration types like arrays
• You can use Key Vault Reference to reference Key Vault secrets directly from App Settings without adding Key Vault SDK to the application.

Cons

• No good version control. Changed values can be retrieved from the Activity log but it requires some digging. Note! Default retention for the Activity log is 90 days.
• If Key Vault Reference is used be aware that secrets are exposed in the Kudu portal for users who have Contributor privileges to App Service even though they don't have direct permissions to Key Vault.
• In disaster recovery situations it's difficult to revert settings if you haven't backed up App Service or settings.
• Be aware that if a specific setting is missing from the App Service configuration (Azure Portal) fallback mechanism tries to find this same setting from the appsettings.json file from the file system. This could cause dangerous situations if appsettings.json with values is deployed to Azure.

2. Azure DevOps variables

In this setup, all application settings are handled via Azure DevOps variables. Azure DevOps is the master data source for application settings.

Pros

• Azure DevOps provides a quite good UI for handling variables which can be used to handle settings and different kinds of configuration values.
• You can separate variables easily to different environments/stages with Variable Groups.
• Variable Groups can be shared in multiple pipelines in the same project.
• Sensitive variable values can be also fetched directly from Key Vault.
• Possibility to use SecureString instead of Key Vault to hide secret configuration values.
• You can easily check which application settings were related to which release.
• Azure DevOps CLI enables to backup of configuration values if necessary to another storage/location.

Cons

• Handling variables via Classic Pipelines could be deprecated at some point.
• Assigning variable values to App Service App Settings requires some extra work on the Pipeline side (applies to both Classic and YAML Pipeline).
• If a variable value is configured to fetch from Key Vault this value is not visible in Azure DevOps logs but it's visible in plain text in the App Settings section of App Service.
• You need to have a separate setting file (appsetting.development.json) for local development.

3. ARM parameter files

In this setup, all application settings are handled in ARM parameter files which are stored in the source control.

Pros

• All settings are in source control. You can easily check which application settings were related to which release.
• Simple and straightforward implementation.
• Good solution from a disaster recovery point of view.
• Additional backup solution for settings is not required (assuming that source control backups exist).

Cons

• A small threshold to making mistakes and committing secrets to source control. When Key Vault SDK is used in the application, you should only store secret key names in the parameter file.
• Adding new settings requires modifications also to Bicep files or maybe you could loop parameters dynamically.
• You need to have a separate setting file (appsetting.development.json) for local development.

4. Azure App Configuration

In this setup master of configuration/setting data is in the external Azure App Configuration service.

Pros

• You can export / import settings between other App Configuration instances.
• Managed Identity is supported.
• Labeling allows you to group settings. You can ex. create a label called "Shared" which settings are shared between multiple applications.
• Built-in feature toggle functionality. You don't necessarily need to use an external Feature Toggle service like Launch Darkly.
• Revision history for 30 days (Standard pricing tier only).
• Direct integration with KeyVault (Managed Identity).
• Private Endpoint support.
• Encryption with customer-managed keys.
• One free App Configuration is available per Azure subscription.
• No necessary need for a local setting file (appsetting.development.json) for local development.

Cons

• Requires minor code changes on the application side.
• Increases Azure costs. The first 200,000 requests are included in the daily charge. Additional requests will be billed as overage (€1.035 per resource per day, plus an overage charge of €0.052 per 10,000 requests.)
• The application side might need caching because the App Configuration service has a request quota (30,000 requests per hour).

What do I prefer?

I have used all of these solutions in past years. Currently, I prefer solutions where settings are stored in ARM-parameter files or an App Configuration service. All secrets and credentials should be always stored in the Key Vault! It depends on the case which one of these is better. App Configuration is very handy especially if need to share settings between multiple applications.