DEV Community

Aparna Krishnamoorthy
Aparna Krishnamoorthy

Posted on Edited on

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

#aws #devops #infrastructure

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

For ARM64:

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

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}}'
Enter fullscreen mode Exit fullscreen mode

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

Top comments (0)