DEV Community: Aparna Krishnamoorthy

Gradual rollout with AWS AppConfig: change configuration slowly and watch the metrics

Aparna Krishnamoorthy — Thu, 15 Oct 2026 13:17:41 +0000

A configuration change looks harmless. You flip a feature flag, adjust a timeout, raise a rate limit, and push it out. There's no build, no deploy pipeline, no code review gate. That's the appeal of dynamic configuration: you change behavior in seconds without shipping code.

It's also the risk. When a configuration change deploys to 100% of your fleet at once, a bad value reaches every user before you can react. The blast radius is the whole system. The time to notice is however long it takes an alarm to fire, a customer to complain, or a dashboard to turn red. By then it's everywhere.

AWS AppConfig is built around a different assumption: change configuration slowly and watch the metrics while it rolls out. You can't start an AppConfig deployment without choosing a deployment strategy. The strategy says how fast the change spreads and how long AppConfig keeps watching afterward. This post explains how deployment strategies work, what AppConfig needs from you to make the watching real, and why "slowly, while watching" is the single most important habit for safe configuration changes.

The problem with all-at-once

Imagine you lower a downstream call timeout, managed in AppConfig, from 3,000 ms to 1,500 ms so slow requests stop tying up threads. The value is perfectly valid. A schema validator would wave it through. What you don't know is that the downstream's tail latency sits around 1,800 ms at peak. Deploy it all at once and every caller picks up the new value within a minute or so. Requests that used to succeed slowly now time out. Callers retry, the retries pile on load, and the failure is fleet-wide before your on-call has finished reading the first alert.

Now imagine you roll the same change out to 10% of your fleet first, with Amazon CloudWatch alarms on the environment so AppConfig can watch your error rate. The bad value still ships, but it reaches a tenth of your callers. An alarm goes off, and AppConfig rolls the deployment back. The other 90% never receive it, and the 10% that did receive it get the old value back on their next poll. Same mistake, a fraction of the damage.

That's the whole idea. You can't stop every bad value from being created. A value that's valid but still wrong, like this one, slips past validators and only reveals itself in production. What a gradual rollout gives you is time and containment: the change reaches a small slice of your fleet long enough for your metrics to say whether it's healthy, before it reaches everyone.

A quick orientation

Before we get into the mechanics, a few terms are worth pinning down. In AppConfig, an application is a logical grouping for one app's configuration. Within it, an environment is a place you deploy to, such as production or staging. A configuration profile is one piece of configuration data you deploy: a set of feature flags, or a free-form JSON, YAML, or text document. A deployment takes a version of one profile and rolls it out to one environment.

That last step, rolling a profile's new version out to an environment, is where a deployment strategy comes in. It governs the rollout itself, and it's what the rest of this post is about.

Rollout progress is measured in targets, and that word earns a precise definition because it does a lot of work below. When AppConfig says a deployment has reached 10% of targets, it's counting the callers that poll for the configuration, not machines. Each caller holds a configuration session, and AppConfig decides session by session whether it's in the current slice. One AppConfig Agent per host makes a target effectively a host. Several sessions per host, or Lambda execution environments, make the mapping looser. You can also use the AppConfig Agent to roll out by user or segment instead, so a given user sees one consistent version throughout the rollout no matter which host serves them. See entity-based gradual deployments.

What a deployment strategy is

Every deployment names a deployment strategy: a reusable definition of how fast the change rolls out and how long AppConfig watches before calling it done. A strategy isn't tied to an application, so you define it once and select it on each deployment. "How we roll out config" becomes something you decide up front and pick from a list, not something you improvise every time.

A deployment strategy is built from four settings:

Growth type: the shape of the rollout curve, linear or exponential.
Growth factor: how big each step is, as a percentage of targets.
Deployment time: the total window over which those steps are spread.
Bake time: how long AppConfig keeps watching your CloudWatch alarms after the configuration reaches 100% of targets, before it considers the deployment complete.

Get these four right and you've described exactly how cautiously, or how quickly, a change reaches your fleet. Let's take them one at a time.

Growth type: the shape of the curve

Growth type controls how the percentage of targets grows at each step. AppConfig supports two, linear and exponential. The console calls this setting deployment type.

Linear grows by the same increment every step. A rollout with a 20% growth factor moves 0% → 20% → 40% → 60% → 80% → 100%, in even steps across the deployment window. Every interval exposes the same additional slice of your fleet, which makes it predictable and easy to reason about.

Exponential starts small and accelerates. It follows the formula G * (2^N), where G is the growth factor and N is the step number, counting from zero. With a growth factor of 2, the rollout reaches 2% of targets, then 4%, then 8%, then 16%, and so on until it hits 100%. This keeps early exposure very small at the riskiest moment (when you know least about the change) and widens quickly once the first steps clear. It's the classic canary shape: tiptoe out, then stride once nothing has broken. The trade-off is at the far end, where the steps are big jumps. With a 10% growth factor they run 40% → 80% → 100%, so a problem that only surfaces at majority exposure arrives in one leap rather than several.

As a rule of thumb: exponential for maximum caution at the start, linear for steady, evenly paced exposure all the way through.

Growth factor: the size of each step

The growth factor is the percentage of targets that receive the configuration during each step. It can be anything from 1 to 100. The console calls it step percentage; the API, CLI, and SDKs call it growth factor.

For linear growth, the factor is the size of every step. For exponential growth, it's the G in G * (2^N): the size of the first step, which then doubles each step until the configuration reaches all targets. The final step is capped at 100%.

Deployment time: how long the whole thing takes

Deployment time is the total window over which AppConfig spreads the steps. Note what it is not: a timeout. It's the window during which the deployment is processed in intervals. A 30-minute deployment with 20% linear growth advances one 20% step every six minutes until it reaches 100%. Exponential works the same way. A 10% growth factor takes five steps to reach 100% (10 → 20 → 40 → 80 → 100%), so a 20-minute exponential deployment advances roughly every four minutes.

One detail is easy to miss: AppConfig doesn't push configuration to callers. They poll for it. "Reached 20% of targets" means 20% of sessions are now eligible, and each picks up the new version on its next poll. So real exposure lags the deployment's percentage by up to one poll interval. The default is 45 seconds with the AppConfig Agent. The same lag applies in reverse. After a rollback, callers that got the bad value revert on their next poll.

Deployment time is your main lever for pacing. A longer window gives your metrics more time to reveal a problem at each stage. A shorter one ships faster but leaves less room to notice trouble between steps.

Bake time: watching after full deployment

Reaching 100% of targets isn't the end of the deployment. Bake time is how long AppConfig keeps monitoring your CloudWatch alarms after the configuration reaches every target, before marking the deployment complete.

It matters because some problems don't surface during the rollout itself: a slow memory leak, a cache that only fills after a few minutes, a scheduled job that fires on the hour. Bake time keeps AppConfig watching for a defined window afterward. If an alarm goes off during it, AppConfig rolls the deployment back exactly as it would mid-rollout. The next section covers what AppConfig needs from you for that to happen.

Once bake time ends, the deployment is complete and automatic rollback is off. If you discover a problem after that, reverting is a deliberate act rather than an automatic one. See Reverting a configuration.

Alarms: the setup that makes rollback automatic

Everything above about AppConfig "watching your alarms" depends on a setup step that's easy to skip. On its own, AppConfig knows nothing about your application's health. You attach one or more CloudWatch alarms to the environment, plus an IAM role AppConfig can assume to read them. With that in place, AppConfig checks those alarms throughout the rollout and the bake time. It rolls back automatically if any goes off, whether at 10% exposure or in the last minute of the bake.

Without it, a deployment strategy still slows the rollout down, but nothing stops it for you. You watch the dashboard yourself, and your safety net is stopping an in-progress deployment by hand, which rolls it back. That's a reasonable way to run a small system, as long as you know that's the mode you're in.

Three details are worth knowing before you rely on automatic rollback:

It triggers on INSUFFICIENT_DATA, not only on ALARM. That's the conservative choice, but it has a catch. An alarm whose metric goes quiet during a rollout, such as one on a low-traffic endpoint or one that only reports when an error occurs, can roll back a perfectly healthy deployment. The fix is to match the alarm's missing-data treatment to the metric: a metric that reports continuously must treat missing data as breaching, while one that only emits on errors must treat it as not breaching. (The default treatment is missing, which is what sends a quiet alarm to INSUFFICIENT_DATA.) Also give a new alarm time to evaluate before you deploy, since a freshly created alarm sits in INSUFFICIENT_DATA until its first evaluation.
It ignores alarms whose actions are disabled. If someone silenced an alarm for maintenance, it won't roll back your deployment either.
Your metrics don't have to live in CloudWatch. If you monitor with a third-party tool, an AppConfig extension can check it at each deployment tick and trigger the same rollback. AWS publishes examples for Datadog and New Relic.

The wiring is covered in Monitoring deployments for automatic rollback.

Predefined strategies vs. rolling your own

You don't have to design a strategy from scratch. AppConfig ships four predefined strategies that cover the common cases:

Strategy	Rollout	Bake time	Best for
`AppConfig.Canary10Percent20Minutes`	Exponential, 10% growth factor, 20 minutes (10 → 20 → 40 → 80 → 100%)	10 minutes	Production; caution up front, AWS-recommended
`AppConfig.Linear20PercentEvery6Minutes`	Linear, 20% every 6 minutes, 30 minutes (20 → 40 → 60 → 80 → 100%)	30 minutes	Production; steady pace and a long bake, AWS-recommended
`AppConfig.AllAtOnce`	100% immediately	10 minutes	Low-risk changes and emergencies, when you accept full exposure
`AppConfig.Linear50PercentEvery30Seconds`	Linear, 50% every 30 seconds, 1 minute (50 → 100%)	1 minute	Testing and demos only, not production

Two things stand out in that table. First, even AllAtOnce isn't unmonitored. The change ships to everyone immediately, but AppConfig still bakes for 10 minutes. So with alarms on the environment you get automatic rollback even when you skip the gradual part. What you lose is containment: by the time an alarm fires, every caller already has the value. Second, Linear50PercentEvery30Seconds is for testing and demos. Its one-minute duration and bake time are deliberately too short to catch much.

For most production workloads, one of the two AWS-recommended strategies is the right starting point: Canary10Percent20Minutes or Linear20PercentEvery6Minutes.

The predefined strategies won't always fit. Maybe you want a very long bake time for a change you're especially nervous about, or a smaller first step for a large fleet. Then you create your own. Here's a custom strategy that rolls out exponentially at a 10% growth factor over an hour, then bakes for a full hour:

aws appconfig create-deployment-strategy \
  --name "Cautious-Exponential-1Hour" \
  --deployment-duration-in-minutes 60 \
  --growth-type EXPONENTIAL \
  --growth-factor 10 \
  --final-bake-time-in-minutes 60 \
  --replicate-to NONE

The same strategy in AWS CDK:

import * as appconfig from 'aws-cdk-lib/aws-appconfig';
import { Duration, Stack, StackProps } from 'aws-cdk-lib';
import { Construct } from 'constructs';

export class DeploymentStrategyStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);

    new appconfig.DeploymentStrategy(this, 'CautiousExponential', {
      deploymentStrategyName: 'Cautious-Exponential-1Hour',
      rolloutStrategy: appconfig.RolloutStrategy.exponential({
        growthFactor: 10,
        deploymentDuration: Duration.minutes(60),
        finalBakeTime: Duration.minutes(60),
      }),
    });
  }
}

The four settings map directly onto the parameters. In the CLI they're --growth-type, --growth-factor, --deployment-duration-in-minutes, and --final-bake-time-in-minutes. In CDK they're RolloutStrategy.exponential with growthFactor, deploymentDuration, and finalBakeTime. The --replicate-to flag isn't a rollout setting. It's optional, and it controls whether AppConfig also saves the strategy as an AWS Systems Manager document. NONE keeps it in AppConfig only. Once created, a custom strategy is selectable anywhere a predefined one is: the console, CLI, API, or infrastructure code.

That snippet is a complete AWS CDK stack. Drop it into a CDK app, run cdk synth, and deploy it as-is to create the strategy. The posts that follow in this series build on the same pattern, each one standing up its piece with a self-contained stack you can paste in and deploy.

Choosing a strategy

There's no universally correct strategy. The right one depends on how much risk a given change carries, how many targets you're rolling it out to, and how quickly your metrics react. A few guidelines:

Higher-risk changes deserve a slower ramp and a longer bake. Say a bad value would be expensive: a pricing flag, a change to an auth path, anything touching data. Lean toward exponential growth and a generous bake time. Small early exposure plus a long watch is exactly what you want when the downside is large.
Larger fleets let you start smaller. With thousands of targets, a 1% to 2% first step still covers enough sessions to produce a real signal, and exponential growth lets you start that small without dozens of steps to reach 100%. With a fleet of twenty, a 2% first step probably reaches no one, so a bigger step, or linear growth, makes more sense.
Make each step longer than your metrics' reaction time. Some signals, such as latency percentiles or error rates averaged over a window, take minutes to appear. When they do, the next step starts before the last one has been judged, unless the step interval outlasts that lag. The interval is deployment time divided by the number of steps. A rollout faster than your metrics is flying blind.
Size the bake time for problems that only appear at full exposure. Queue backlogs, cache churn, and hourly jobs may not register until everyone is on the new value. The bake window is the only monitored time you get after 100%.
Reserve fast strategies for low-stakes changes, emergencies, or non-production. AllAtOnce is fine for a copy tweak behind a flag, and it's the right call for a kill switch you need everywhere now. It's the wrong one for anything that could take the system down.

Two constraints shape all of this. First, you choose the strategy per deployment, so nothing forces you to use the same one for a routine flag flip and an emergency change. Second, an environment accepts one deployment at a time. While a two-hour canary is in flight, the next change waits until the canary completes, unless you stop the canary to make room, which rolls it back. That's the real cost of a long strategy, so decide in advance what you'll do if an urgent change lands mid-rollout.

The habit to build is to ask, for every configuration change: if this value is wrong, how much do I want exposed before I find out? The answer picks your strategy.

Why this matters

Configuration changes feel low-stakes because they're fast and code-free, and that's exactly why they're dangerous. A deployment strategy puts a governor on that speed. Instead of arriving everywhere at once, a change arrives a slice at a time, under observation, with a monitored window at the end. The cost is time: minutes for the recommended strategies, hours for a cautious custom one, during which the environment is committed to that deployment. In return, a bad value is contained to a fraction of your fleet instead of all of it, your metrics get time to catch it, and, with alarms on the environment, AppConfig reverses it without waiting for a human.

The core habit is simple: change configuration slowly, and watch the metrics while you do. The rest of safe configuration management builds on that foundation. You validate values before they deploy, alarm on the right metrics, and plan for emergency changes.

Learn more

Working with deployment strategies
Using predefined deployment strategies
CreateDeploymentStrategy API reference
Deploying a configuration
Creating environments (where you attach CloudWatch alarms)
Monitoring deployments for automatic rollback

Why Consolidating Feature Flags and Experiments Cuts Hidden Costs

Aparna Krishnamoorthy — Mon, 05 Oct 2026 13:50:29 +0000

Feature flags and experiments do two different jobs.

A flag controls delivery. It decides whether a feature is on for a given user, and lets you switch it off fast when something breaks.

An experiment is about measurement. Split users into groups, show them different variations, and find out which performs better on a metric that matters.

Take a new checkout button. The flag delivers it: on for these users, off for those. The experiment measures it: does the new button convert better than the old one? Both halves describe a single idea — try a different checkout button and see if it helps — but because the jobs are different, teams run them in different places. Delivery lives in a flagging tool or a config service. Measurement lives somewhere else: a dedicated A/B platform, or a home-grown mix of an SDK and an analytics pipeline.

Describe that one idea in two systems, and keeping them in agreement about which users are in which group becomes your job, not the tooling's. That's the seam — the join between delivery and measurement — and it carries a cost in money and engineering time that's easy to overlook. Now that AWS AppConfig runs A/B tests natively on the same feature flags you already deploy, the seam is worth a second look. This post is about the hidden tax of keeping delivery and measurement apart, and what you get back when they share one control plane.

The multi-service tax

You pay in four ways.

Integration. Two systems to wire into your application, each with its own setup, authentication, and configuration. Two things to provision and keep correct across every environment.

SDK sprawl. A flag-evaluation SDK here, an experiment or analytics SDK there, multiplied across every language and every service you run. More dependencies to ship, more versions to keep current, more surface area when something breaks.

Operational overhead. Two control planes. Two sets of dashboards. Two permission models to manage and audit. Two things every engineer has to learn before they can safely change what customers see. And the gap between "what's flagged" and "what's being measured" becomes its own category of confusion.

Assignment drift. This is the subtle one. When a flagging system and an experiment system bucket users independently, keeping a single user in a consistent variation across both gets fiddly. A small mistake here quietly pollutes your experiment data. It's the worst kind of bug, because nothing errors — you just end up deciding on bad numbers.

None of these is dramatic on its own. Together they're a standing tax on every change worth measuring.

What changed

In mid-2026, AWS announced the general availability of experimentation tools in AWS AppConfig. A/B and multivariate testing are now built into the feature flags you already deploy, with no separate experimentation infrastructure to build or run. You define variations, target an audience with a rule builder, set the traffic split, ramp exposure, and promote the winner — all anchored to the flag itself — through the console, CLI, API, or CDK. It's available in all commercial AWS Regions.

The timing matters for a second reason. Amazon CloudWatch Evidently, AWS's dedicated A/B testing service, reached end of support on October 17, 2025. So "where does A/B testing live now?" has been a live question for anyone who relied on Evidently, not a hypothetical one.

The practical effect is simple: the flag that delivers a feature is now the same flag that runs the experiment measuring it.

What you get back

Walk back through the same four costs.

One control plane. The flag is the experiment surface. An experiment selects an existing feature flag, and each treatment is a variation of that flag's configuration. The thing that controls the rollout is the thing that runs the test, and defining a variation and its traffic split is just part of the experiment definition. Here it is in the CDK, where each treatment carries the flag values it sets and the weight that splits traffic:

from aws_cdk import aws_appconfig as appconfig

AttrValue = appconfig.CfnExperimentDefinition.AttributeValueProperty
Treatment = appconfig.CfnExperimentDefinition.TreatmentProperty

# app, env, and profile are the L1 CfnApplication, CfnEnvironment, and
# CfnConfigurationProfile for your feature flags, defined elsewhere in the stack.
# The checkout_button flag must already define a "color" attribute. Treatments
# set the value of an attribute the flag defines; they don't create new ones.
appconfig.CfnExperimentDefinition(self, "CheckoutButtonExperiment",
    name="checkout-button-color",
    application_identifier=app.ref,
    environment_identifier=env.ref,
    configuration_profile_identifier=profile.ref,
    flag_key="checkout_button",
    # Editor-syntax expression. $country is a caller-supplied context attribute,
    # not an AWS Region; here, everyone in the US is eligible.
    audience_rule='(eq $country "US")',
    # Baseline: today's blue button, half the traffic. AppConfig generates the
    # treatment key; the Agent returns it as "_variant". The control comes back
    # as "__control__" and treatments as "__t1__", "__t2__", and so on.
    control=Treatment(
        enabled=True, weight=50,
        attribute_values={"color": AttrValue(string_value="blue")},
    ),
    # Variation under test: green button, the other half.
    treatments=[
        Treatment(
            enabled=True, weight=50,
            attribute_values={"color": AttrValue(string_value="green")},
        ),
    ],
)

The CfnExperimentDefinition construct is only in recent versions of aws-cdk-lib (2.268.0 or later).

One agent. Experiments are delivered through the AWS AppConfig Agent, which runs on Amazon EC2, AWS Lambda, Amazon ECS, Amazon EKS, and on-premises servers. If you already use the agent to evaluate flags, that's one component per runtime to ship and keep current, not two. If you currently call the AppConfig API directly, budget for adding the agent: experimentation requires it.

One workflow. Define your variations, target the audience, set the traffic split, then start at 0% exposure and ramp up while watching your metrics. When a treatment wins, you promote it through a standard AppConfig safe rollout — the same gradual, monitored deployment you'd use for any other configuration change. One detail worth getting right: update and deploy the flag with the winning values while the experiment is still running, then stop it. In that order, users go straight from the split to the full rollout. Stop first, and the flag reverts to whatever is currently deployed (usually the default) until you redeploy.

Consistent assignment by construction. The system doing the flagging is the system doing the bucketing. There's no second service to disagree with, so "did both systems put this user in the same group?" stops being a question you can get wrong. It isn't zero work. You retrieve a treatment with the same agent call you already use for flags, plus two headers: an Entity-Id that identifies the user, and a Context that carries the attributes your audience rule evaluates. But given a stable entity ID, the agent returns the same treatment for that entity for the life of the run — consistency is the system's job, not yours. And because treatment allocations lock once a run starts, the split can't quietly shift underneath you partway through.

Where the savings stop

Consolidation covers delivery, assignment, and exposure control. Analysis is still yours. Configuring an analytics platform to capture experiment data is an explicit step in the workflow, and AppConfig is deliberately agnostic about which one: CloudWatch, Snowflake, Datadog, or your own warehouse. You're unifying where experiments run, not how you measure them. That's the right trade — your metric definitions are usually the last thing you'd want to migrate — but it does mean the analytics side stays with you.

It also isn't free. AppConfig experimentation is pay-as-you-go, billed per experiment-run hour from the moment a run starts until you end it, and standard AppConfig configuration-request charges still apply on top while the experiment runs. (See the pricing link below for current rates.) The argument isn't that consolidation costs nothing. It's that you stop paying twice for one idea.

When consolidating isn't the answer

This isn't a case for ripping out a system that's serving you well.

If you've already invested in a dedicated experimentation platform — one your analysts have built tooling around, with its own statistics engine, holdout groups, and a workflow people rely on — the math is different. AppConfig's AI-assisted experiment design validates your setup against experimentation best practices at design time, which helps you reach sufficient statistical power, but the analysis itself happens in your own tools, and very advanced programs may still want a platform that does both.

The same goes if your flags are evaluated in a browser or mobile client. The documented path runs through the agent on server-side compute, so client-side experiments mean your backend does the assignment and hands the result down. That's a design decision, not a blocker, but one to make deliberately.

The value of consolidation is highest when your second system is mostly overhead — when it exists only because flagging and experimentation historically couldn't share a home. The case is strongest for teams already running AppConfig feature flags, where a separate experiment system duplicates flags they already have.

A quick gut check

Four questions to size up your own tax:

Do you deliver a feature in one system and measure it in another, describing the same change twice?
How many SDKs or agents does a single feature touch as it evaluates end to end?
When an experiment produces a winner, can you promote it through your existing deployment safety net, or is that a separate manual step?
Is keeping a user in a consistent variation across systems something you actively babysit?

The more "yes" answers, the more there is to reclaim.

Why this matters

For teams building on AWS, the split between delivering a feature and measuring it used to be structural. AppConfig flagged, something else experimented, and stitching the two together was the cost of doing business.

It isn't structural anymore. It's a choice — and consolidating saves more than dollars: fewer moving parts, less drift, and one safe path from testing an idea to shipping the winner. It's the kind of cost that's easy to keep paying precisely because no invoice ever arrives for it, which is exactly why it's worth adding up on purpose.

Stop hardcoding AWS Lambda layer ARNs: use public parameters for the AWS Parameters and Secrets Lambda Extension

Aparna Krishnamoorthy — Tue, 15 Sep 2026 13:09:51 +0000

To add the AWS Parameters and Secrets Lambda Extension to an AWS Lambda function, you can open the documentation, find the ARN table, locate your AWS Region and architecture, copy the ARN, and paste it into your template. This approach works, but the version number at the end of that ARN changes every time AWS releases an update. If you hardcode that number, your deployment stays pinned to an older version, which you might not notice for months.

There's a better approach that uses public parameters in AWS Systems Manager Parameter Store (Parameter Store).

What is the AWS Parameters and Secrets Lambda Extension?

The AWS Parameters and Secrets Lambda Extension is a Lambda layer that retrieves and caches values from Parameter Store and AWS Secrets Manager. It runs as a companion process alongside your function, and serves cached parameter values over a local HTTP endpoint. The use of this extension reduces latency, reduces API call costs, and simplifies your function code: you make a local HTTP call instead of configuring an SDK client and managing your own caching logic.

If you're new to the extension, the AWS Compute Blog post covers the full setup, and provides a walkthrough with load test results showing ~98% fewer API calls.

The problem with hardcoded layer ARNs

The extension is distributed as a Lambda layer. To attach it, you need its ARN:

arn:aws:lambda:us-east-1:177933569100:layer:AWS-Parameters-and-Secrets-Lambda-Extension:122

The version number at the end (122 at the time of writing) changes with each release. If you hardcode it, it'll keep working, but you won't get bug fixes, performance improvements, or new features until someone manually checks the docs and updates it.

The Lambda console makes this easy for a single function. You pick "AWS-Parameters-and-Secrets-Lambda-Extension" from a dropdown and choose the latest version. But that doesn't help your CloudFormation templates, CDK stacks, or Terraform configurations, where the ARN is a static string that someone has to maintain.

For a team managing many functions across multiple AWS Regions, it becomes a maintenance chore that's easy to forget.

A better approach: resolve at deploy time

AWS publishes the latest extension layer ARN as a public parameter in every commercial AWS Region. The paths are:

Architecture	Parameter path
x86_64	`/aws/service/aws-parameters-and-secrets-lambda-extension/x86/latest`
ARM64	`/aws/service/aws-parameters-and-secrets-lambda-extension/arm64/latest`

When you reference these parameters in infrastructure code, the ARN resolves at deploy time. Each deployment picks up the latest version automatically.

The only IAM permission you need is ssm:GetParameter. The parameters are public and readable from any AWS account.

Retrieving the ARN from the CLI

To see the latest layer ARN for your AWS Region, run the following command:

aws ssm get-parameter \
  --name "/aws/service/aws-parameters-and-secrets-lambda-extension/x86/latest" \
  --query "Parameter.Value" \
  --output text

For ARM64:

aws ssm get-parameter \
  --name "/aws/service/aws-parameters-and-secrets-lambda-extension/arm64/latest" \
  --query "Parameter.Value" \
  --output text

You can use these commands in a script, a CI pipeline, or to check what version is the latest before deploying.

Using the parameter in CloudFormation

CloudFormation supports dynamic references that resolve SSM parameters during stack operations. If you reference the public parameter directly, your template won't need a version-specific ARN:

Resources:
  MyFunction:
    Type: AWS::Lambda::Function
    Properties:
      FunctionName: my-function
      Runtime: python3.12
      Handler: index.handler
      Architectures:
        - x86_64
      Code:
        ZipFile: |
          import json
          import os
          import urllib.request

          def handler(event, context):
              token = os.environ['AWS_SESSION_TOKEN']

              req = urllib.request.Request(
                  'http://localhost:2773/systemsmanager/parameters/get?name=%2Fmy%2Fparameter'
              )
              req.add_header('X-Aws-Parameters-Secrets-Token', token)
              config = urllib.request.urlopen(req).read()
              return json.loads(config)
      Layers:
        - !Sub '{{resolve:ssm:/aws/service/aws-parameters-and-secrets-lambda-extension/x86/latest}}'
      Role: !GetAtt MyFunctionRole.Arn

The {{resolve:ssm:...}} syntax tells CloudFormation to fetch the parameter value during stack creation or update. The resolved value is fixed until the next stack operation. To pick up a new extension version, update the stack. (The template itself doesn't change.)

For ARM64 functions, swap the path:

Layers:
  - !Sub '{{resolve:ssm:/aws/service/aws-parameters-and-secrets-lambda-extension/arm64/latest}}'

Using the parameter in CDK

CDK resolves the parameter at deploy time using the same underlying SSM resolution:

import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as ssm from 'aws-cdk-lib/aws-ssm';
import { Stack, StackProps } from 'aws-cdk-lib';
import { Construct } from 'constructs';

export class ParameterCacheStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);

    const extensionArn = ssm.StringParameter.valueForStringParameter(
      this,
      '/aws/service/aws-parameters-and-secrets-lambda-extension/x86/latest'
    );

    new lambda.Function(this, 'MyFunction', {
      runtime: lambda.Runtime.PYTHON_3_12,
      handler: 'index.handler',
      code: lambda.Code.fromAsset('lambda'),
      layers: [
        lambda.LayerVersion.fromLayerVersionArn(this, 'ParamsSecretsExt', extensionArn),
      ],
    });
  }
}

Under the hood, CDK synthesizes this into a CloudFormation template parameter of type AWS::SSM::Parameter::Value<String>, so the layer ARN is resolved from the public parameter at deploy time.

Using the parameter in Terraform

data "aws_ssm_parameter" "params_secrets_extension" {
  name = "/aws/service/aws-parameters-and-secrets-lambda-extension/x86/latest"
}

resource "aws_lambda_function" "my_function" {
  function_name = "my-function"
  runtime       = "python3.12"
  handler       = "index.handler"
  filename      = "lambda.zip"
  role          = aws_iam_role.lambda_exec.arn

  architectures = ["x86_64"]

  layers = [
    data.aws_ssm_parameter.params_secrets_extension.value
  ]
}

Each terraform apply resolves the parameter. If a new version was published since your last deploy, you'd see it in the plan.

A common mistake: parameter ARN vs. parameter value

Because it's an AWS resource, the SSM public parameter has its own ARN, and it contains a value that is the Lambda layer ARN. These are not the same thing:

Parameter ARN (the address): arn:aws:ssm:us-east-1::parameter/aws/service/aws-parameters-and-secrets-lambda-extension/x86/latest
Parameter value (the content): arn:aws:lambda:us-east-1:177933569100:layer:AWS-Parameters-and-Secrets-Lambda-Extension:122 (version number at the time of writing)

If you paste the parameter ARN into the Lambda layer field in the console, you'll get a validation error. Lambda expects a layer ARN, not a parameter ARN. The dynamic references in CloudFormation and Terraform handle this resolution automatically. However, if you copy manually from the console, make sure you're copying the value.

One more detail the parameters save you from: the x86_64 and ARM64 layers have different names, not just different version numbers. The x86_64 value resolves to a layer named AWS-Parameters-and-Secrets-Lambda-Extension, while the ARM64 value resolves to AWS-Parameters-and-Secrets-Lambda-Extension-Arm64. Reference the right architecture's parameter and you never have to track that distinction yourself.

Why it matters for teams

Public parameters reduce maintenance work. Every team's deployment pipeline resolves the latest version independently. You don't need shared spreadsheets of ARNs, Slack messages asking what the latest version is, or pull requests that just bump a version number.

When AWS publishes an update with a bug fix or performance improvement, your next deployment picks it up automatically without the need for coordination.

Learn more

Stop hardcoding AWS Lambda layer ARNs, and use AWS Systems Manager Parameter Store public parameters instead

Aparna Krishnamoorthy — Tue, 01 Sep 2026 03:43:00 +0000

To add the AWS AppConfig Agent Lambda extension to an AWS Lambda function, you can open the documentation, scroll through a table of ARNs, find the one that matches your AWS Region and architecture, copy it, and paste it into your template. However, a few months later, AWS publishes a new version and now your deployment is silently using an older one. There’s a better approach that uses public parameters in AWS Systems Manager Parameter Store (Parameter Store).

What are public parameters in Parameter Store?

Many AWS services use Parameter Store to publish read-only public parameters with names that start with /aws/service/{service-name}. These public parameters contain up-to-date metadata about AWS services.

You've probably seen them used for AMI lookups for fetching the latest Amazon Linux AMI ID without hardcoding it. The same mechanism is available for Lambda layer ARNs, ECS-optimized AMIs, and other resources that AWS updates regularly.

The key idea is that instead of looking up a value in documentation and pasting it into your code, you query Parameter Store at deploy time and get the current value. The only IAM permission that's required is ssm:GetParameter. The parameters are public and readable from any AWS account.

The problem with hardcoded layer ARNs

The AWS AppConfig Agent Lambda extension is distributed as a Lambda layer. To attach it, you need the layer's ARN, which includes a version number at the end like in this example:

arn:aws:lambda:us-east-1:027255383542:layer:AWS-AppConfig-Extension:128

That version number changes every time AWS releases an update. If you hardcode it, you get a working deployment, but you also get silent drift. A few months from now, you'll be running an older version without realizing it.

Imagine a team that's managing dozens of functions in multiple AWS Regions, and you can see how this can become a maintenance problem. Someone has to regularly check the documentation, update the ARN, and redeploy. It's not difficult work, but it's the kind of thing that's a hassle and that gets forgotten.

A better approach: resolve at deploy time

AWS publishes the latest AppConfig extension layer ARN as a public parameter in every commercial AWS Region. Here are the two paths:

Architecture	Parameter path
x86_64	`/aws/service/aws-appconfig/lambda-extension/x86/latest`
ARM64	`/aws/service/aws-appconfig/lambda-extension/arm64/latest`

Note: The x86 path uses x86, not x86_64, even though the Lambda architecture name is x86_64.

When you reference these parameters in your infrastructure code, each deployment resolves the current value from Parameter Store. How and when that resolution happens depends on your tooling. The AWS CLI resolves the parameter on each invocation. CloudFormation dynamic references ({{resolve:ssm:...}}) and parameter types (AWS::SSM::Parameter::Value) resolve during stack create or update operations. The resolved value is then fixed until the next stack operation. Either way, you avoid hardcoding and pick up new versions through your normal deployment workflow.

Retrieving the ARN from the CLI

As an example, run the following AWS CLI command. It returns the full layer ARN for your current AWS Region.

aws ssm get-parameter \
  --name "/aws/service/aws-appconfig/lambda-extension/x86/latest" \
  --query "Parameter.Value" \
  --output text

For ARM64:

aws ssm get-parameter \
  --name "/aws/service/aws-appconfig/lambda-extension/arm64/latest" \
  --query "Parameter.Value" \
  --output text

Using the parameter in CloudFormation

You can reference the public parameter directly in a CloudFormation template using a dynamic reference:

MyFunction:
  Type: AWS::Lambda::Function
  Properties:
    FunctionName: my-function
    Runtime: python3.12
    Handler: index.handler
    Architectures:
      - x86_64
    Layers:
      - '{{resolve:ssm:/aws/service/aws-appconfig/lambda-extension/x86/latest}}'

Why this approach matters for teams

For one developer working on one function, looking up an ARN in the documentation is fine. But when you have multiple teams deploying functions across AWS Regions, keeping layer versions current becomes a coordination problem.

Public parameters remove that concern. Every team's deployment pipeline resolves the latest version independently. You don't need shared spreadsheets of ARNs or Slack messages asking if anyone has checked the latest version. It's a small thing, but small operational improvements add up.

Learn more

Finding public SSM parameters for AMIs with the EC2 DescribeImages API

Aparna Krishnamoorthy — Wed, 19 Aug 2026 13:49:48 +0000

Services like EC2 and ECS require an AMI ID at launch time, which pins the instance to a specific OS image. AMIs from AWS and its partners get patched often, and each patch ships as a new ID. If you hardcode that ID, it goes stale quickly and your infrastructure drifts behind the latest patches.

The standard fix is to use a public SSM parameter — a well-known path that always resolves to the current AMI in a given family. That works great for new deployments, but what about existing code where the AMI ID is already baked in? Finding the right parameter used to mean navigating cryptic /aws/service/ hierarchies, guessing naming conventions, and making dozens of GetParametersByPathcalls. This tedious process not only slowed down workflows but also introduced the risk of selecting the wrong parameter, potentially leading to deployment issues.

A new EC2 feature eliminates that friction: the DescribeImages API now includes a PublicSsmParameterName field that tells you exactly which parameter maps to a given AMI.

Finding the SSM parameter for a public AMI in DescribeImages

You can avoid the manual search by retrieving the parameter name from DescribeImages.

aws ec2 describe-images \
 --region us-east-1 \
 --image-ids ami-1234567890abcdef0 \
 --query 'Images[*].{ImageId:ImageId,PublicSsmParameterName:PublicSsmParameterName}'

[
 {
 "ImageId": "ami-1234567890abcdef0",
 "PublicSsmParameterName": "aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64"
 }
]

The parameter will now resolve to the updated AMI than the one you described if the publisher has released a newer version.

Adding the leading slash before using the parameter

When you copy the parameter name from the EC2 DescribeImages API, note that it doesn't have the leading slash required by Parameter Store.

aws ssm get-parameter \
 --region us-east-1 \
 --name "aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64"


ValidationException: Parameter name: can't be prefixed with "ssm"...

Add a leading / to avoid the error.

aws ssm get-parameter \
 --region us-east-1 \
 --name "/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64"

Using a parameter instead of a hardcoded AMI ID

Reference the parameter returned by DescribeImages directly in your infrastructure code.

In the following CloudFormation example, you define a parameter of type AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>, and use it for the ImageId property.

Parameters:
 LatestAmiId:
 Type: AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>
 Default: /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64

Resources:
 Instance:
 Type: AWS::EC2::Instance
 Properties:
 ImageId: !Ref LatestAmiId
 InstanceType: t3.micro

In the following CDK example, you pass the same parameter name to MachineImage.fromSsmParameter().

const machineImage = ec2.MachineImage.fromSsmParameter(
'/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64'
);

new ec2.Instance(this, 'Instance', {
 vpc,
 instanceType: ec2.InstanceType.of(ec2.InstanceClass.T3, ec2.InstanceSize.MICRO),
 machineImage,
});

Both approaches resolve the parameter when you create or update the stack, not on every new instance launch, so an update is still reviewable and tied to your normal deployment process.

In the following example, you use the resolve:ssm: prefix on the ImageId. New instances resolve the parameter at launch time, so they can use the current AMI in that AMI family without a redeploy.

aws ec2 create-launch-template \
 --region us-east-1 \
 --launch-template-name my-template \
 --version-description version1 \
 --launch-template-data '{"ImageId":"resolve:ssm:/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64","InstanceType":"t3.micro"}'

Summary

DescribeImages returns the public SSM parameter associated with a public AMI family. Reference that parameter in your launch and deployment code to avoid manually searching for it. Remember to add the leading slash to the parameter name when retrieving it from Parameter Store.

Scaling Parameter Store reads for production workloads

Aparna Krishnamoorthy — Thu, 23 Jul 2026 19:33:35 +0000

Consider an order-processing service running on Amazon ECS Fargate during a weekend sale. Under normal conditions, 20 tasks read configuration values from Parameter Store at startup. As traffic increases, the service scales to 200 tasks, causing many tasks to request the same parameters at nearly the same time. If these requests exceed the available throughput, new tasks can start slowly or fail, potentially delaying or interrupting customer orders.

When an application exceeds the available quota, its logs can show a ThrottlingExceptionor RateExceeded error from GetParameter, GetParameters, or GetParametersByPath. To diagnose such issues, you can check the error source in application logs, or trace the relevant API calls in CloudTrail. Then compare the timing against a known scaling or deployment event. Throttling or latency issues that cluster around this event are a strong signal that concurrent parameter requests caused the bottleneck.

You can address Parameter Store throughput issues in the following complementary ways:

Enable higher throughput. Increase the quota so that production workloads handle concurrent reads during normal operation and scaling events. The cost is based on usage. For example, a workload generating approximately 456,000 parameter interactions for a 60-hour sale costs about $2.28.
Optimize read patterns. Reduce unnecessary API traffic by retrieving only the parameters the application needs and caching values that it reads repeatedly.

Enabling higher throughput raises the quota for each API action in a single account in a single Region. Throughput for SecureString parameters might be further limited by AWS KMS.

API action	Default quota	Higher-throughput quota
GetParameter	Shared 40 TPS	10,000 TPS
GetParameters	Shared 40 TPS	1,000 TPS
GetParametersByPath	Shared 40 TPS	100 TPS

Improving application resilience by enabling higher throughput

Consider enabling higher throughput in the following scenarios:

Parameter Store is part of a production request path, not a one-time deployment. A higher quota ensures configuration requests don’t become a bottleneck at runtime.
Many instances, containers, or Lambda functions read parameters within the same window. Higher throughput lets your fleet scale without individual instances competing for a shared, undersized quota.
Deployments, restarts, or autoscaling events produce bursts of reads. You can absorb these predictable spikes, so a routine deployment doesn't fail.
Usage regularly approaches or exceeds the default 40 TPS quota. By proactively increasing your quota, you eliminate bottlenecks instead of waiting for them to recur under heavier load.
You want more throughput but don’t want to redesign the system. Enabling the higher-throughput setting increases your quota immediately without touching your infrastructure or application.

When you enable higher throughput, you increase the request quota for your AWS account and Region.

The cost of higher throughput is $0.05 per 10,000 parameter interactions. A request that retrieves multiple parameters counts as one interaction for each parameter returned.

An order-processing example
Assume that our order-processing service runs 20 tasks under normal conditions. During a promotional event lasting 60 hours (6 p.m. Friday to 6 a.m. Monday), it scales to 200 tasks for the duration of the sale. To limit stale values, each task refreshes the database endpoint, inventory service, and order dead-letter queue parameters every 5 minutes as follows:

200 tasks × (60 hours × 12 refreshes per hour) = 144,000 refresh calls.
144,000 calls × 3 parameters each = 432,000 parameter interactions.
A Lambda function handling checkout cold starts approximately 8,000 times during traffic bursts, creating 24,000 additional interactions.

The result is approximately 456,000 parameter interactions for the 60-hour sale. With higher throughput enabled, the application avoids throttling errors caused by hitting quota limits. At $0.05 per 10,000 interactions, the total additional cost is $2.28.

Because the higher-throughput setting is billed on usage, you can enable it before an anticipated traffic spike and disable it afterward. If your application is throttled during normal production workloads, however, consider enabling higher throughput as a permanent setting.

Enabling higher throughput in the AWS console and CLI

A throughput setting applies at the account and Region level. It takes effect for all applications reading from Parameter Store in the specified scope.

In the console, increase throughput by choosing Systems Manager > Parameter Store > Settings.

In the AWS CLI, run the following command to enable higher throughput, replacing the AWS Region and account ID with your own.

shell
aws ssm update-service-setting \
  --setting-id arn:aws:ssm:us-east-1:123456789012:servicesetting/ssm/parameter-store/high-throughput-enabled \
  --setting-value true

Optimizing read patterns

Optimizing how your application retrieves parameters is an operational best practice. If your application retrieves only necessary parameters and caches values that it reads repeatedly, it reduces latency and uses throughput more efficiently.

Avoid retrieving more than your application needs. Parameter hierarchies are a useful way to organize configuration values. For example, you can group parameters for a checkout application as follows: /prod/checkout/db-host, /prod/checkout/inventory-service-endpoint, and /prod/checkout/order-dlq-arn. It’s tempting to use GetParametersByPath to retrieve an entire subtree when your application knows the specific parameters it needs.

`# Gets the subtree, including parameters your app might not need`
`aws ssm get-parameters-by-path \
  --path "/prod/checkout/" \
  --recursive \
  --with-decryption`

With higher throughput enabled, GetParametersByPath is limited to 100 TPS, compared to 1,000 for GetParameters and 10,000 for single-parameter GetParameter calls. With default throughput, all three share the same 40 TPS pool. If your application knows its parameter names, requesting them directly means that your application is less likely to hit the quota.

`# Retrieves only the parameters your app actually needs
aws ssm get-parameters \
  --names "/prod/checkout/db-host" "/prod/checkout/inventory-service-endpoint" "/prod/checkout/order-dlq-arn" \
  --with-decryption`

As a best practice, remove unused parameters from a hierarchy. You prevent GetParametersByPath calls from returning parameters that the application doesn’t need and can reduce the paginated requests for larger hierarchies.

Cache parameter values in the application. Many configuration values don’t change often enough to justify reading them on every request. If your application reads the same parameter many times per minute, read it once and reuse the value for an appropriate period. For example, use a short reuse window for values that change often and a longer one for values that don’t.

The following sample code defines a get_parameter() function. You can call this function every 10 seconds for a specific parameter. The first call after the five-minute TTL expires retrieves the latest value from Parameter Store and updates the cache.

`import time
import boto3

ssm = boto3.client("ssm")
_cache = {}
TTL_SECONDS = 300  # how long to trust a cached value

def get_parameter(pname):
    now = time.time()
    if pname in _cache:
        value, cached_at = _cache[pname]
        if now - cached_at < TTL_SECONDS:
            return value

    response = ssm.get_parameter(Name=pname, WithDecryption=True)
    value = response["Parameter"]["Value"]
    _cache[pname] = (value, now)
    return value`

Spread out reads when many resources start at the same time. A common source of throttling is simultaneous startup. This occurs when many EC2 instances or ECS tasks read the same parameters within the same second during deployment or scaling. You can avoid concentrating the read burst by reading parameters once and passing the values to the application, or by staggering reads with a slight delay.

For Lambda functions, consider the AWS Parameters and Secrets Lambda Extension. The extension caches parameter values locally for reuse across invocations. This reduces both the number of calls to Parameter Store and the latency of retrieving values.

Summary

Your application logs might show ThrottlingException or RateExceedederrors from GetParameter, GetParameters, or GetParametersByPath. The results of throttling can be outages and degraded customer experience.

Enabling the higher-throughput setting removes the risk of hitting an API quota during production. You can enable it before an anticipated event and disable it afterward, or leave it on permanently. For most production workloads, the operational benefit of resilience outweighs the modest cost.

You can also address latency by optimizing read patterns. For example, you can replace a GetParametersByPath call with GetParameters, or cache values in your application. The combination of higher throughput and optimized reads helps make your application more resilient when multiple tasks run concurrently.

Questions? Comments? Leave them below!

Improving operational resilience by decoupling code deployments from feature activation using AWS AppConfig feature flags

Aparna Krishnamoorthy — Wed, 13 May 2026 14:31:22 +0000

Shipping quickly isn’t the hard part anymore. The hard part is recovering when something goes wrong.
A lot of teams still release features the same way: deploy code and whatever’s in that deployment goes live immediately. It’s simple, and it works — until it doesn’t. Because when a feature causes problems, you don’t just turn off the feature. You end up rolling back the entire deployment. That means waiting, coordinating, and sometimes introducing new risk just to undo the last change.
That’s a heavy price to pay for something that should be lightweight.

*Where the risk actually comes from *
The issue isn’t deployments themselves. It’s the fact that feature activation is tightly coupled to them. When those two things are tied together, every release becomes an all-or-nothing event. A small issue can impact your entire user base, and recovery depends on how quickly you can redeploy or roll back. That’s where Mean Time to Resolution starts to creep up—not because the fix is complicated, but because the mechanism to apply it is. It also makes it difficult to test safely in production. You either release to everyone or no one, which isn’t much of a choice.

Separating deployment from release
A more resilient approach is to treat deployment and feature release as two different concerns. You can deploy code whenever you want, but keep new functionality inactive until you explicitly turn it on. That control layer is what feature flags provide.

Using AWS AppConfig on Amazon Web Services, feature state becomes configuration rather than code. Your application checks that configuration at runtime and decides which path to execute.
That one change removes the need to redeploy just to change behavior.

What changes in practice
Instead of hardcoding whether a feature is on or off, your application asks AWS AppConfig for the current state and responds accordingly. The flow is straightforward: the application retrieves configuration, evaluates the relevant flag, and executes the appropriate logic.
Here’s a simple example. Imagine you’re introducing a new checkout flow.
Your configuration might look like this:

{
    "version": "1",
    "flags": {
        "enableNewCheckout": {
            "name": "Enable new checkout experience",
            "attributes": {
                "version": { "constraints": { "type": "string" } }
            }
        }
    },
    "values": {
        "enableNewCheckout": {
            "enabled": true,
            "version": "2.0"
        }
    }
}

That lives in AWS AppConfig, not in your codebase.

To retrieve it at runtime, use AWS AppConfig Agent. The agent is an Amazon-managed process that retrieves configuration data from AWS AppConfig in the cloud. It caches configuration data locally and asynchronously polls the AWS AppConfig data plane for updates. This approach keeps configuration data readily available to your application while reducing latency and cost.
Although you can retrieve configuration data by calling the APIs directly, using the agent is the recommended approach. It improves application performance and simplifies configuration management.

With your configuration profile stored in AWS AppConfig and the agent running in your compute environment, using the configuration is just a conditional in your application logic:

const application_name = "MyDemoApp";
const environment_name = "MyEnvironment";
const config_profile_name = "MyConfigProfile";


async function loadFlag(flag_name) {
    // retrieve a single flag's data by providing the "flag" query string parameter
    // note: the configuration's type must be AWS.AppConfig.FeatureFlags
    const url = `http://localhost:2772/applications/${application_name}/environments/${environment_name}/configurations/${config_profile_name}?flag=${flag_name}`;
    const response = await fetch(url);
    return await response.json();
}


export async function handleCheckout(req, res) {
  const enableNewCheckoutFlag = await loadFlag("enableNewCheckout"); // {"enabled":true,"version":"2.0"}


  if (enableNewCheckoutFlag.enabled) {
    return newCheckoutFlow(req, res);
  }


  return legacyCheckoutFlow(req, res);
}

That small shift—moving the decision out of your deployment and into runtime configuration—gives you a surprising amount of control.

Reducing mean time to resolution with gradual deployments
One of the less obvious benefits of feature flags is how they change how quickly you understand and resolve issues, not just how you prevent them.
When you roll out a feature gradually using AWS AppConfig, you’re effectively turning a production release into a controlled experiment. Instead of exposing 100% of users at once, you start with a small segment and watch what happens. That alone shortens the feedback loop. If something is wrong, you’ll see it earlier—and in a much smaller slice of traffic. But the real impact on mean time to resolution comes from the combination of three things working together:
First, reduced scope. If only 5% of users are impacted, you’re not dealing with a full-scale incident. That lowers urgency just enough to make debugging more methodical instead of reactive.
Second, clearer signal. When a change is introduced gradually, it’s easier to correlate cause and effect. You’re not sifting through noise from a full deployment—you’re looking at a controlled change with a defined rollout window.
Third, faster reversal. If metrics start trending in the wrong direction, you don’t need to redeploy or coordinate a rollback. You stop the rollout or revert the configuration. Integration with Amazon CloudWatch or monitoring platforms like DataDog and New Relic (using custom extensions) allow you to define guardrails. If key metrics cross a threshold, AWS AppConfig can automatically roll back to a known good configuration without waiting for someone to step in.
Put together, gradual deployments don’t just reduce blast radius—they reduce the time it takes to understand, isolate, and resolve issues in the first place.
AWS AppConfig also supports pre-deployment syntax and functional validation through integration with AWS Lambda. Pre-deployment validation reduces the chance of a bad configuration making it into production in the first place.

Operational feature flags that make a difference
Once you start using feature flags, it’s tempting to think of them only in terms of user-facing features. In practice, some of the most valuable flags are operational—they exist purely to give you more control during incidents or high-risk changes.
A simple but powerful example is an operational toggle or kill switch. Instead of rolling back an entire service, you can disable a specific capability that’s causing issues. This is especially useful for integrations or newly introduced dependencies where failure modes aren’t fully understood yet.
Another common pattern is traffic shaping. You can route a percentage of requests to a new code path, a new backend, or even a different region. If something looks off, you dial it back immediately. This gives you a level of control that traditional deployments don’t offer.
You can also use flags to control fallback behavior. For example, if a downstream dependency starts failing, a flag can switch your application into a degraded mode—serving cached data, skipping non-critical steps, or simplifying responses. That kind of switch can be the difference between a partial degradation and a full outage.
There’s also value in flags that control operational safeguards. Rate limiting thresholds, retry behavior, or timeout values can all be externalized into configuration. Instead of pushing a code change during an incident, you adjust behavior in real time.
Finally, some teams use feature flags to control observability itself. Increasing logging, enabling additional metrics, or turning on debug paths can all be done dynamically. When paired with validation via AWS Lambda, you can safely introduce these changes without risking malformed configurations.
None of these flags are particularly complex on their own. What matters is that they give you options when things aren’t going smoothly.
And that’s really the point: operational resilience isn’t just about preventing failures—it’s about having enough control to respond effectively when they happen.

When this starts to matter
This approach becomes especially valuable once you’re deploying frequently or operating systems where uptime really matters. If you’ve ever had to rush a rollback, or sit through a tense deployment wondering if something might break, you’ve already felt the limitations of tightly coupled releases.
Decoupling feature activation from deployment doesn’t eliminate failures, but it makes them smaller and easier to recover from.

Most teams focus on improving how they deploy code. Fewer spend time improving how they release features. Using AWS AppConfig shifts that focus. It gives you a way to control behavior independently of deployments, which in turn makes your system more resilient and your releases less stressful. It’s not a massive architectural overhaul. It’s a small change in where decisions are made.

But it has a disproportionate impact on how safely you can move.

For more information, see the AWS AppConfig User Guide.

DEV Community: Aparna Krishnamoorthy

Gradual rollout with AWS AppConfig: change configuration slowly and watch the metrics

The problem with all-at-once

A quick orientation

What a deployment strategy is

Growth type: the shape of the curve

Growth factor: the size of each step

Deployment time: how long the whole thing takes

Bake time: watching after full deployment

Alarms: the setup that makes rollback automatic

Predefined strategies vs. rolling your own

Choosing a strategy

Why this matters

Learn more

Why Consolidating Feature Flags and Experiments Cuts Hidden Costs

The multi-service tax

What changed

What you get back

Where the savings stop

When consolidating isn't the answer

A quick gut check

Why this matters

Further reading

Stop hardcoding AWS Lambda layer ARNs: use public parameters for the AWS Parameters and Secrets Lambda Extension

What is the AWS Parameters and Secrets Lambda Extension?

The problem with hardcoded layer ARNs

A better approach: resolve at deploy time

Retrieving the ARN from the CLI

Using the parameter in CloudFormation

Using the parameter in CDK

Using the parameter in Terraform

A common mistake: parameter ARN vs. parameter value

Why it matters for teams

Learn more

Stop hardcoding AWS Lambda layer ARNs, and use AWS Systems Manager Parameter Store public parameters instead

What are public parameters in Parameter Store?

The problem with hardcoded layer ARNs

A better approach: resolve at deploy time

Retrieving the ARN from the CLI

Using the parameter in CloudFormation

Why this approach matters for teams

Learn more

Finding public SSM parameters for AMIs with the EC2 DescribeImages API

Finding the SSM parameter for a public AMI in DescribeImages

Adding the leading slash before using the parameter

Using a parameter instead of a hardcoded AMI ID

Summary

Scaling Parameter Store reads for production workloads

Improving application resilience by enabling higher throughput

Enabling higher throughput in the AWS console and CLI

Optimizing read patterns

Summary

Improving operational resilience by decoupling code deployments from feature activation using AWS AppConfig feature flags