Azure

Azure feature flags in App Configuration: pricing per tier, request quotas, and variants

Azure App Configuration ships a real feature manager with targeting, variants and experimentation, and it is cheap enough that most teams underestimate it. The catch is not the price, it is the request quota: every tier below Premium throttles you with HTTP 429, and feature flags are metered differently from configuration. Here are the current published numbers and how to plan around them.

No card required

The short answer

Azure feature flags live in Azure App Configuration, on all four tiers including Free. Pricing in US East is $0 per day for Free, $0.12 for Developer, $1.20 for Standard and $9.60 for Premium, roughly $0, $3.65, $36.50 and $292 per month, with the Premium price including one replica. What actually decides your tier is the request quota, not the money: Free is capped at 1,000 requests per day, Developer at 6,000 per hour, Standard at 30,000 per hour, and only Premium has no cap. Free and Developer carry no SLA, which makes Standard the practical production floor. Flags support per-user targeting through the targeting filter and multi-variant flags for A/B tests, with the experimentation engine powered by Split Software running on Azure. The gap that matters: the feature management libraries that evaluate flags are .NET and Java Spring, so a Node, Go or Python service reads the values but implements filters itself.

Last updated July 2026 · prices pulled from the Azure Retail Prices API for US East on 2026-07-23; limits from learn.microsoft.com

01 · The spec sheet

All four tiers, with the numbers that actually decide it

Every tier includes feature flags, Key Vault references, snapshots, metrics and logs. What separates them is throughput, storage, history and whether Microsoft will sign an SLA.

Dimension	Free	Developer	Standard	Premium
Price per day (US East)	$0	$0.12	$1.20	$9.60 (includes a replica)
Roughly per month	$0	$3.65	$36.50	$292
Extra replica	n/a	n/a	$1.20 per day	$4.80 per day
Requests included	n/a	3,000 per day	200,000 per day	800,000 origin + 800,000 replica per day
Overage price	n/a	$0.04 per 1,000	$0.06 per 10,000	$0.06 per 10,000
Hard request quota	1,000 per day, then 429 until midnight UTC	6,000 per hour	30,000 per hour	None
Throughput	Not guaranteed	Not guaranteed	~300 reads/sec, 60 writes/sec	~450 reads/sec, 100 writes/sec
Storage	10 MB + 10 MB snapshots	500 MB + 500 MB	1 GB + 1 GB	4 GB + 4 GB
Revision history	7 days	7 days	30 days	30 days
SLA	None	None	99.9%, or 99.95% with geo-replication	99.9%, or 99.99% with geo-replication
Stores per subscription	One per region	Unlimited	Unlimited	Unlimited
Private Link	No	Yes	Yes	Yes
Customer-managed keys	No	No	Yes	Yes
Soft delete	No	No	Yes	Yes
Geo-replication	No	No	Yes	Yes

Snapshot storage beyond the included allowance is $0.0016 per MB per day on every paid tier. Prices are US East and vary by region.

02 · Set it up

Two packages, and one line people forget

Feature flags in .NET need two pieces that are easy to confuse. The App Configuration provider pulls values from the store and handles refresh. The feature management library evaluates them, applies filters and gives you IsEnabledAsync. You need both.

The line most often missing is app.UseAzureAppConfiguration(). Without that middleware the provider loads once at startup and never refreshes, so flipping a flag in the portal appears to do nothing and the usual next step is a wasted afternoon. If your flags change but your app does not, check that line first.

Feature flags are metered differently from configuration. Configuration monitoring uses a sentinel key. Feature flags do not: Microsoft documents one request to monitor every 100 feature flags per refresh interval. So 250 flags on a 30-second refresh is three requests every 30 seconds per instance, which is 360 per hour per instance before anything else.

c# · asp.net core · feature management live

// Program.cs  ·  dotnet add package Microsoft.FeatureManagement.AspNetCore
//                dotnet add package Microsoft.Azure.AppConfiguration.AspNetCore

builder.Configuration.AddAzureAppConfiguration(options =>
{
    options.Connect(new Uri(builder.Configuration["AppConfig:Endpoint"]),
                    new DefaultAzureCredential())
           // Feature flags do NOT use the sentinel key. They are monitored
           // separately: ONE request per 100 flags per refresh interval.
           .UseFeatureFlags(ff => ff.SetRefreshInterval(TimeSpan.FromSeconds(30)));
});

builder.Services.AddAzureAppConfiguration();
builder.Services.AddFeatureManagement()
       .WithTargeting<TargetingContextAccessor>();   // per-user rollout

var app = builder.Build();
app.UseAzureAppConfiguration();   // required, or nothing ever refreshes

// In a controller or minimal API:
if (await featureManager.IsEnabledAsync("Checkout.NewFlow"))
{
    return NewCheckout();
}
return ClassicCheckout();

The flag itself is stored as JSON, so a targeting rollout is reviewable and diffable:

json · Microsoft.Targeting filter

{
  "id": "Checkout.NewFlow",
  "enabled": true,
  "conditions": {
    "client_filters": [
      {
        "name": "Microsoft.Targeting",
        "parameters": {
          "Audience": {
            "Users": [ "[email protected]" ],
            "Groups": [ { "Name": "beta", "RolloutPercentage": 100 } ],
            "DefaultRolloutPercentage": 25
          }
        }
      }
    ]
  }
}

In Blazor server apps and anywhere you need scoped services, swap AddFeatureManagement() for AddScopedFeatureManagement(), available since Microsoft.FeatureManagement 3.1.0. The singleton IHttpContextAccessor pattern the targeting docs use does not work in Blazor.

03 · The quota, not the price

Work out your request volume before you pick a tier

App Configuration is cheap enough that cost rarely decides anything. What decides it is whether your instance count times your refresh rate fits inside an hourly quota, because the failure mode is HTTP 429 rather than a bigger invoice.

Fifty instances, 1,000 settings, a 30-second refresh

Microsoft works this example through in its own FAQ, and it is worth repeating because the arithmetic is not intuitive. Each instance polls the sentinel key every 30 seconds, so 120 requests an hour. Across 50 instances that is 6,000 requests an hour just for monitoring. Loading all 1,000 settings takes 10 requests per instance since each request returns up to 100 key-values, so a full reload across the fleet is 500 requests. Update the sentinel twice in an hour and you have made about 7,000 requests.

Here is the part that saves you: on a Standard store, the frequent unchanged sentinel requests mostly do not count against the hourly quota, so only around 1,000 of those 7,000 consume it. On a Free store there is no such exclusion, and 7,000 requests against a 1,000 per day cap means your app spends most of the day getting 429s. That single difference, not the $1.20, is why Free is an evaluation tier and nothing more.

Add feature flags on top. They are monitored separately at one request per 100 flags per refresh interval, per instance. Fifty instances with 250 flags on a 30-second refresh is 3 requests times 120 per hour times 50 instances, so 18,000 requests an hour. On Standard, with a 30,000 per hour ceiling, you are past halfway before you have loaded a single configuration value. Lengthening the flag refresh interval to two minutes cuts that to 4,500. This is the lever, and almost nobody pulls it until the 429s start.

Lengthen the refresh interval

The default 30 seconds is a choice, not a requirement. Most flags do not need sub-minute propagation, and a kill switch you pull twice a year does not justify quota pressure every hour of every day.

Use the providers, not raw HTTP

The App Configuration providers carry retry, caching and jitter. Custom clients hitting the REST API directly hammer the quota and then retry into the throttle. If you must write your own, honor the retry-after-ms header.

Watch the Request Quota Usage metric

It is in Azure Monitor. Alert on it at 70% rather than discovering the limit through 429s in production. Free tier stores reset at midnight UTC, which is a long time to be broken.

04 · Variants and experiments

Azure's A/B testing runs on an engine Harness owns

This is a genuinely interesting piece of the landscape and it is barely written about anywhere.

Variant feature flags

Instead of a boolean, a flag carries several named variants, each assigned to specific users, groups or percentile buckets. Your code asks for the variant and switches on it. This is the substrate everything else sits on, and it works on any tier.

Telemetry to Application Insights

The feature management library emits an evaluation event per variant assignment. You send those, plus your own conversion events, into Application Insights. No telemetry means no experiment, and this is the step teams skip.

The experimentation engine

Microsoft states plainly that experimentation in App Configuration is powered by Split Software, Inc., running on Azure. Harness acquired Split in 2024 and rebranded it Feature Management and Experimentation. So Azure experimentation and Harness FME descend from the same statistics engine, arriving through very different front doors.

The practical read: Azure gives you a credible experimentation path without a separate vendor contract, provided your app is .NET and your telemetry already goes to Application Insights. If you want to see how the same job is done elsewhere, the Harness feature flags page covers what that engine looks like sold directly, and A/B testing software built on flags covers the general shape.

05 · The walls

Four limits worth knowing before you commit

Wall 1

Evaluation is a .NET and Java Spring story

Microsoft is explicit: creating and updating flags works from the SDKs of every supported language, but evaluating and consuming them requires the App Configuration provider and the feature management libraries, which are .NET and Java Spring. A Node, Go, Python or Rust service can read the raw JSON, but the targeting filter, percentage bucketing and variant assignment are yours to reimplement, and reimplementing bucketing consistently across languages is exactly the bug you do not want.

Wall 2

No SLA below Standard

Free and Developer have no service level agreement and no guaranteed throughput. That is fine for a dev store and disqualifying for anything a customer touches. Standard at $1.20 a day is the real starting line, and if a regional outage would take your flags down with it, geo-replication and a second replica are another $1.20 a day each.

Wall 3

Revisions eat your storage quota

App Configuration keeps a history of every change, and those revisions count toward the store storage limit. If you exceed it you can no longer create or modify key-values or feature flags at all. On a Free store with 10 MB, a chatty automated pipeline writing flags can reach that faster than you would guess, and the fix is reducing revision retention rather than deleting flags.

Wall 4

The portal is an Azure portal

Flipping a flag means an Azure sign-in with RBAC permissions on the store. That is appropriate for engineers and a real obstacle for the product manager, support lead or marketer who wants to enable a feature for one account. You can build a management UI on the SDKs, since the flag APIs are available in every supported language, but that is a project rather than a setting.

06 · The honest fork

Should you just use App Configuration? If you are a .NET shop, probably.

Use Azure

Stay put if all of this is true

Your services are ASP.NET Core or Java Spring, where the feature management library does the real work for you.
Engineers own the flags and an Azure sign-in is a reasonable gate on changing one.
Your telemetry already lands in Application Insights, which is what makes experimentation almost free to adopt.
Standard at about $36.50 a month, or Premium at about $292, is comfortably inside your existing Azure spend.
You want configuration and flags in one store with Key Vault references, snapshots and Entra ID auth already wired up.

Plainly: for a .NET team on Azure, App Configuration covers most of what a flag vendor sells, at a price that is hard to argue with. Take the best practices and stay.

You need more

Look further when any of this is true

A meaningful share of your stack is not .NET or Java Spring, and you refuse to reimplement bucketing per language.
You need the same flag evaluated in a browser or a mobile app with consistent assignment.
You are managing request quotas across many services and would rather not tune refresh intervals to avoid 429s.
Non-engineers need to flip flags without an Azure RBAC grant.
You want flag lifecycle tooling: ownership, staleness, code references, cleanup.

A platform-independent feature flags platform gives you one evaluation core with identical bucketing in every language, a UI your product team can use, and a kill switch nobody needs a cloud console to pull. Running both clouds? The AWS feature flags page covers the AppConfig equivalent, and best feature flag tools compares the managed vendors with verified pricing.

07 · FAQ

Questions people actually search

Does Azure have feature flags?

Yes. Azure App Configuration includes a first-party feature manager: you store feature flags alongside your configuration key-values, edit them in the Azure portal, and read them in your app through the .NET or Java Spring feature management libraries. Feature flags are available on every tier, including the Free one, so there is nothing extra to enable or buy.

How much does Azure App Configuration cost?

In US East, the Free tier is $0 per day, Developer is $0.12 per day, Standard is $1.20 per day, and Premium is $9.60 per day including one replica. That works out to roughly $3.65, $36.50 and $292 per month. Overage is $0.04 per 1,000 requests on Developer and $0.06 per 10,000 requests on Standard and Premium.

How many requests does each Azure App Configuration tier include?

Free stores are capped at 1,000 requests per day and return HTTP 429 for the rest of the day once you hit it. Developer includes the first 3,000 requests per day and is throttled at 6,000 per hour. Standard includes 200,000 per day and is throttled at 30,000 per hour. Premium includes 800,000 per day for the origin plus 800,000 for its replica, with no request quota at all.

Why is my Azure App Configuration returning 429?

You exceeded a daily quota on Free, an hourly quota on Developer or Standard, or the throughput allowance on any tier. Standard allows a run rate of about 300 read requests per second and 60 writes per second; Premium allows 450 and 100. The response body names the specific reason, and the retry-after-ms header tells your client how long to wait.

How do Azure feature flags handle per-user targeting?

Through the targeting filter, which takes a targeting context of a user id and a list of groups and resolves a flag consistently for that user. You can enable a flag for named users, for named groups with a percentage each, and for a default percentage of everyone else. The rollout is deterministic, so a user who sees the feature keeps seeing it as you widen the percentage.

What are variant feature flags in Azure App Configuration?

A variant flag holds several named variants of a feature rather than a single on or off value, and assigns them to specific users, groups or percentile buckets. Variants are the building block for A/B testing: you define the variants in App Configuration, send evaluation telemetry to Application Insights, then define metrics and run an experiment against them.

Does Azure App Configuration support A/B testing?

Yes, through experimentation built on variant feature flags and Application Insights telemetry. Worth knowing who built it: Microsoft states the experimentation engine is powered by Split Software running on Azure. Split was acquired by Harness in 2024, so Azure experimentation and Harness FME trace back to the same statistics engine.

Which Azure App Configuration tier do I need for production?

Standard is the production floor: it is the cheapest tier with an SLA, at 99.9% or 99.95% with geo-replication, plus 30-day revision history, soft delete and customer-managed keys. Free and Developer carry no SLA at all, which rules them out for anything customer-facing. Premium buys 99.99% with geo-replication, no request quota, 4 GB of storage and a bundled replica.

Early access · launching soon

One flag, evaluated the same way everywhere

Identical bucketing across every language and runtime, no request quotas to tune, unlimited flags and seats, flat per-team pricing. Join the early-access list, no card required.

No card required · your data stays yours

Keep exploring