DEV Community: Aparna Krishnamoorthy

# 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 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:

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. The following 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`

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, every deployment picks up the latest version automatically.

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

Why this issue 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.