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.
Top comments (0)