How to handle application specific settings in 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 application again. This blog post presents a comparison about 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 application pool recycle.
• Allows to use 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 application.

Cons

• No good version control. Changed values can be retrieved from Activity log but it requires some digging. Note! Default retention for Activity log is 90 days.
• If Key Vault Reference is used be aware that secrets are exposed in Kudu portal for users who has Contributor privileges to App Service even tough they don't have direct permissions to Key Vault.
• In disaster recovery situation it's difficult to revert settings back if you haven't backed up App Service or settings.
• Be aware that if specific setting is missing from App Service configuration (Azure Portal) fallback mechanism tries to find this same setting from appsettings.json file from 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 kind of configuration values.
• You can separated 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 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 in Pipeline side (applies to both Classic or YAML Pipeline).
• If 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 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 to 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 disaster recovery point of view.
• Additional backup solution for settings is not required (assumes that source control backups exists).

Cons

• A small threshold to make mistake and commit secrets to source control. When Key Vault SDK is used in the application, you should only store secret key names to 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 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 necessary need to use 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 available per Azure subscription.
• No necessary need for local setting file (appsetting.development.json) for local development.

Cons

• Requires minor code changes in 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 at €0.052 per 10,000 requests.)
  
• Application side might need caching because App Configuration service has request quota (30,000 requests per hour).

What I prefer?

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