AWS

AWS feature flags with AppConfig: pricing, targeting, and the new experimentation tools

AppConfig is the flag system most AWS teams already have and never turned on. It is cheap, it validates and rolls back on its own, and in 2026 it grew real user targeting and managed experiments. It also has a specific cost trap that catches teams the month after they ship. Here is the whole picture, with current published prices.

No card required

The short answer

AWS feature flags live in AWS AppConfig, a capability of AWS Systems Manager, generally available since March 2022. You store flags as a versioned configuration profile, deploy them over a chosen rollout duration, and AppConfig watches your CloudWatch alarms during a bake time and rolls back automatically if one fires. Pricing is $0.0000002 per configuration request and $0.0008 per configuration received, where "received" means the config actually changed. Two 2026 updates matter: enhanced targeting arrived in March 2026, giving sticky per-user and per-segment assignment during a rollout, and managed experimentation tools reached general availability in 2026 at $0.90 per experiment hour. The trap: the $0.0008 received charge is 4,000 times the request charge, so a fleet that re-receives configuration on every poll costs far more than the headline suggests.

Last updated July 2026 · verified against aws.amazon.com/systems-manager/pricing and the AWS AppConfig user guide

01 · What you are actually turning on

Four AWS services answer to "feature flags"

Search results for AWS feature flags mix up four different things, and one of them was retired. Sort this out before you design anything.

Service	What it does	Use it for flags?
AWS AppConfig	First-party feature flags and dynamic configuration, with schema validation, monitored rollouts and automatic rollback. Part of Systems Manager.	Yes. This is the answer.
SSM Parameter Store	Key-value storage for configuration and secrets. No validation, no rollout, no rollback.	Only for a crude on/off value you accept changing instantly everywhere.
CloudWatch Evidently	The former AWS feature flag and experimentation service. AWS stopped accepting new customers and directed teams to AppConfig.	No. Migrate to AppConfig.
CDK feature flags	Unrelated. These are opt-in behavior changes to the CDK framework itself, set in cdk.json. Nothing to do with runtime flags.	No. Different concept entirely.

The CDK confusion is worth naming because "aws cdk feature flags" is a common search that has nothing to do with releasing software behind a toggle. Those flags live in cdk.json and control how the CDK synthesizes CloudFormation.

02 · Set it up

Use the agent, never the raw API

The single most consequential decision on AppConfig is how your code reads a flag. Calling GetLatestConfiguration directly on every request works, and it is how most first attempts are written, but it puts a network call on your critical path and bills every single evaluation.

The AWS AppConfig Agent solves both. It runs as a Lambda extension layer, an ECS or EKS sidecar, or a systemd service on EC2. It polls in the background, caches the current configuration in memory, and serves it to your process over localhost port 2772. Your flag read becomes a local HTTP call measured in microseconds, and your bill drops to the agent's poll rate rather than your request rate.

Always keep an in-code default. AppConfig hands you a document, not a decision. If the fetch fails, your code must fall back to a hardcoded value rather than throw. Flags that break the request when the config service hiccups are worse than no flags.

python · appconfig agent · localhost:2772 live

# AppConfig Agent sidecar / Lambda extension, NOT the raw API.
# The agent polls in the background and caches; your code reads locally.
#
#   Lambda: add the AWS-AppConfig-Extension layer, then read port 2772.
#   ECS/EKS: run the agent as a sidecar container.
#   EC2:     install the agent as a systemd service.

import os, json, urllib.request

APP  = os.environ["APPCONFIG_APP"]          # e.g. "checkout"
ENV  = os.environ["APPCONFIG_ENV"]          # e.g. "production"
PROF = os.environ["APPCONFIG_PROFILE"]      # e.g. "flags"
AGENT = "http://localhost:2772"

def flags() -> dict:
    url = f"{AGENT}/applications/{APP}/environments/{ENV}/configurations/{PROF}"
    with urllib.request.urlopen(url, timeout=0.3) as r:
        return json.loads(r.read())

def enabled(key: str, default: bool = False) -> bool:
    try:
        return flags().get(key, {}).get("enabled", default)
    except Exception:
        # Fail to the in-code default. Never let config fetch break the request.
        return default

if enabled("checkout.new-flow"):
    new_checkout()
else:
    classic_checkout()

The flag document itself is plain JSON validated against the AppConfig feature flag schema, so it is reviewable in a pull request if you manage it as code:

json · feature flag configuration profile

{
  "flags": {
    "checkout.new-flow": {
      "name": "checkout.new-flow",
      "attributes": {
        "rolloutPercent": { "constraints": { "type": "number" } }
      }
    }
  },
  "values": {
    "checkout.new-flow": {
      "enabled": true,
      "rolloutPercent": 25
    }
  },
  "version": "1"
}

If you are evaluating the same flags from a Python service, our Python feature flags guide covers the caching and default-value patterns in more depth.

03 · The pricing trap

Two prices, and one of them is 4,000 times the other

AppConfig bills two separate events and almost every write-up quotes only the first. Getting this wrong is the difference between a rounding error and a real line item.

Billed event	Price	When it fires
Configuration request	$0.0000002 each	Every poll your agent or code makes, changed or not.
Configuration received	$0.0008 each	Only when the configuration has actually changed since your last poll.
Experiment hour	$0.90 each	One experiment running for one hour, regardless of targets or traffic percentage. Request and received charges still apply on top.
Multi-variant data	No extra charge	Requesting data on multiple variants within the same version of a flag, because variant data is cached locally.

Work the numbers

100 tasks, polling every 15 seconds

A hundred containers polling at the agent's default cadence make roughly 17.3 million configuration requests a month. At $0.0000002 that is about $3.46. Genuinely cheap, and this is the number everyone quotes.

Now suppose something in your setup causes each poll to count as a configuration received rather than an unchanged request. The same 17.3 million events at $0.0008 is about $13,800 a month. That is the whole ballgame. The received charge is what you are managing, and you manage it by letting the agent handle polling and by not rewriting the configuration on a schedule. A pipeline that redeploys the flag profile every few minutes, even with identical content, is the classic way to land in the expensive column.

None of this is hidden. AWS publishes both numbers plainly. It is simply that the interesting one is the second, and the second is the one people skip. If you are budgeting for flags across a portfolio of services, the same discipline applies as with any usage meter: model the worst case, not the brochure case. Our feature flag software pricing page exists partly because flat pricing removes this whole class of forecasting work.

04 · What changed in 2026

AppConfig grew the two things it was always criticized for

For years the honest summary of AppConfig was: excellent deployment safety, no user targeting, no experiments. Both halves of that criticism went away this year, and most comparison content has not caught up.

March 2026

Enhanced targeting during rollout

AppConfig added controls to target flag and configuration values to specific segments or individual users across the lifecycle of a gradual rollout. It uses entity identifiers you provide to make a value sticky to a given target, so a user who lands in the new experience stays there instead of flapping as the rollout advances. Before this, a gradual rollout moved a percentage of your hosts, which is a deployment concept rather than a user-experience one.

2026

Managed experimentation tools, generally available

AWS shipped A/B and multivariate experiments inside AppConfig, with a rule builder for audience targeting, traffic allocation percentages, exposure control and locked treatment allocations, available through the console, CLI, API and CDK. AWS positions it for UI changes, recommendation algorithms and model or prompt selection alike. Billing is per experiment hour at $0.90, independent of how much traffic runs through it.

July 2024

Targets, variants and splits

The groundwork: multi-variant flags that hold several values under one key and resolve by rules. Variant data is cached locally by the agent and AWS does not bill extra for reading multiple variants in one flag version, which makes variants the cheap way to express a choice.

Still true

Validators, bake time and automatic rollback

The original reason to pick AppConfig has not changed. A configuration is validated against a JSON schema or a Lambda before deployment, rolled out over a duration you choose, and monitored against CloudWatch alarms during a bake time. If an alarm fires, AppConfig rolls back on its own. Very few flag products do this, because very few flag products think of a flag change as a deployment.

05 · The walls

Where AppConfig still stops being the right tool

These are structural, not gaps AWS is about to close, because they follow from what AppConfig is: a configuration deployment service with excellent operational safety.

Wall 1

It is built for infrastructure, not for the browser

AppConfig is designed around an agent that runs beside your server process. There is no client-side SDK you drop into a React app and no mobile SDK. To flag a frontend experience you build your own endpoint that evaluates server-side and hands the answer to the browser, which means writing and operating the piece every commercial flag vendor gives you.

Wall 2

Nobody outside engineering will touch the console

Flipping a flag means editing a hosted configuration version and starting a deployment in the AWS console, with IAM permissions to match. That is correct for a kill switch owned by the on-call engineer. It is a non-starter for a product manager who wants to enable a beta for one customer on a Friday afternoon, and handing out AppConfig write access to do it is not a trade most teams will make.

Wall 3

Flag lifecycle management is entirely yours

AppConfig will happily hold a flag you shipped eighteen months ago and forgot. There is no stale flag report, no code reference scanning, no owner field, no automatic reminder that a permanent toggle has been at 100% since last spring. Flag debt is the main long-run cost of a flag program and AppConfig gives you nothing to fight it with. Our notes on feature flag naming, ownership and flag debt cover what to build if you stay.

Wall 4

One cloud

The agent model assumes AWS credentials and AWS networking. If part of your estate is on another cloud, in a customer VPC, or on a laptop for local development, you are back to configuring endpoints and credentials per environment. Teams running a genuinely multi-cloud footprint usually end up with a second flag system, which is the outcome flags were supposed to prevent.

06 · The honest fork

Should you just use AppConfig? Often, yes.

Use AppConfig

Stay on AWS if all of this is true

Your flags are operational: kill switches, rate limits, circuit breakers, capacity toggles, region drains.
Engineers own every flag and no one outside engineering needs to change one.
Your services run on Lambda, ECS, EKS or EC2, where the agent is a layer or a sidecar rather than a project.
You value validation, bake time and automatic CloudWatch rollback more than a friendly dashboard. This is the best part of AppConfig and it is genuinely rare.
You want the cost inside an existing AWS bill with no new vendor, no procurement and no security review.

We will say it plainly: for backend-only operational flags on an all-AWS estate, AppConfig is a good answer and adding a vendor on top of it buys you very little. Read the best practices and stay where you are.

You need more

Look further when any of this is true

Product managers, designers or support need to flip a flag without an AWS login.
You need the same flag evaluated in a browser, an iOS app and a backend service, with one definition and consistent bucketing.
Part of your estate is not on AWS, or you deploy into customer environments.
You want flag debt handled for you: ownership, staleness reports, code references, cleanup prompts.
You would rather pay a predictable flat amount than model configuration-received volume across every service.

A cloud-independent feature flags platform gives you one evaluation core across every language and runtime, a UI non-engineers can use, built-in A/B testing software, and a kill switch that does not require a console deployment to pull. If you are weighing that against building the missing pieces yourself, our build vs buy analysis puts numbers on it.

Comparing the managed options too? The best feature flag tools roundup has verified 2026 pricing for every major vendor, and the Azure feature flags page covers the equivalent Microsoft path if you run both clouds.

07 · FAQ

Questions people actually search

Does AWS have feature flags?

Yes. AWS AppConfig, part of AWS Systems Manager, has offered first-party feature flags since they became generally available in March 2022. You define flags as a configuration profile, deploy them with a rollout strategy, and read them from your application through the AppConfig Agent or the GetLatestConfiguration API. There is no separate product to buy.

How much do AWS feature flags cost?

AWS AppConfig charges $0.0000002 per configuration request and $0.0008 per configuration received. The request price applies every time your app polls; the far larger received price applies only when the configuration has actually changed since your last poll. Experimentation adds $0.90 per experiment hour on top of those two charges.

What is the difference between AWS AppConfig and Parameter Store?

Parameter Store holds individual values with no concept of validation, rollout or rollback. AppConfig treats a configuration as a deployable artifact: it validates against a JSON schema or a Lambda, rolls the change out over a chosen duration, monitors CloudWatch alarms during the bake time, and rolls back automatically if an alarm fires. Use Parameter Store for values, AppConfig for controlled change.

How do I use AWS AppConfig feature flags in Lambda?

Add the AWS AppConfig Agent Lambda extension as a layer, then read the flag from the extension's local HTTP endpoint on port 2772 rather than calling the API directly. The extension caches the configuration and polls in the background, so a warm invocation reads from memory. Without it, every invocation is a billed configuration request and adds latency to your critical path.

Can AWS AppConfig target individual users?

Yes, since March 2026. AppConfig added enhanced targeting during rollout, which lets you target flag values to specific segments or individual users using entity identifiers you supply, and keeps the assignment sticky for that entity through the life of a gradual rollout. Before that update, gradual rollouts moved a percentage of your fleet, not a percentage of your users.

Does AWS AppConfig support A/B testing?

It does now. AWS announced general availability of managed experimentation tools in AppConfig in 2026, covering A/B and multivariate experiments with a rule builder for audience targeting, traffic allocation percentages, exposure control and locked treatment allocations. It is billed at $0.90 per experiment hour, defined as one experiment running for one hour regardless of traffic volume.

What are multi-variant feature flags in AppConfig?

A multi-variant flag holds several values for the same flag key and picks one based on rules evaluated against attributes you pass in. AWS does not charge for requesting data on multiple variants inside the same version of a flag, because the variant data is cached locally by the agent. That makes variants cheaper than splitting one flag into several.

Is AWS AppConfig a good LaunchDarkly alternative?

It is a genuine alternative if your whole estate is AWS and your flags are operational rather than product-facing. It gives you validation, monitored rollouts and automatic rollback at very low cost. Where it falls short is a flag UI a product manager will use, SDKs beyond the agent model, client-side and mobile evaluation, and flag lifecycle management across many teams.

Early access · launching soon

Flags that outlive your cloud choice

One evaluation core across every language and runtime, a UI your product team can use, 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