关于AWS SSM参数动态传播及启动模板AMI字段引用SSM参数的技术问询

Great question—this is a super common pain point when trying to keep EC2 Auto Scaling Groups (ASGs) running on the latest AMIs without manual work. Let’s break this down clearly:

Can you directly reference an SSM Parameter Store parameter (aws:ec2:image type) in a Launch Template’s AMI field for automatic updates? #

Short answer: No, not out of the box for automatic dynamic updates.

Here’s the thing: If you use the {{ssm:param-name}} syntax when creating or updating a Launch Template, AWS will only resolve that parameter to a specific AMI ID at the moment you save the template. After that, even if the SSM parameter is updated to point to a new AMI, the Launch Template will stick with the old AMI ID it resolved initially. Any new instances launched by the ASG will still use that stale AMI unless you explicitly update the Launch Template again.

The docs mention referencing SSM parameters in "configuration and automation workflows"—this refers to SSM-native tools like Run Command, Automation Documents, State Manager, or CloudFormation templates (during stack creation/update), not static infrastructure resources like Launch Templates automatically syncing with parameter changes post-creation.

So how do you get ASGs to automatically use the latest AMI from an SSM parameter? #

The approach you mentioned—using EventBridge + Lambda—is the standard way to handle this. Here’s a quick breakdown of how it works:

• Set up an EventBridge Rule: Configure it to listen for UpdateParameter events from SSM Parameter Store targeting your specific AMI parameter.
• Trigger a Lambda Function: The function will fetch the latest AMI ID from the SSM parameter, then call the EC2 API to update your Launch Template with this new ID. If your ASG is set to use the Launch Template’s default version, updating the default version will make all new instances use the new AMI. If you’re using specific template versions, you’ll also need to update the ASG to point to the new version of the Launch Template.

Alternative options include using CloudFormation to manage your Launch Template and ASG, then setting up triggers to update the CloudFormation stack when the SSM parameter changes—but the EventBridge + Lambda route is simpler for most use cases.

Quick note on the {{ssm:param-name}} syntax #

This syntax works great in places where the value is resolved at execution time:

• AWS CLI commands (e.g., aws ec2 run-instances --image-id {{ssm:/aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2}} will pull the latest AMI when you run the command)
• CloudFormation templates (during stack creation/update, it resolves to the current parameter value)
• SSM Automation Documents or Run Command scripts (resolves when the automation/command runs)

But it doesn’t enable "live" dynamic updates for static resources like Launch Templates that are stored with fixed values once created.

备注：内容来源于stack exchange，提问作者benjimin