AWS Builder Center: Learn, Build and Connect with builders in the AWS community
AWS Builder Center is the official home for builders on AWS. Share and read what others are working on, follow people who inspire you, explore training and workshops, and find tools to support what you're building.
How to identify the source of Amazon Linux 2 instances after EOS and prevent further such instances from being created.
Provides context relating to the identification of sources of EC2 instance instantiation, and how they relate to notifications sent for instances identified by the AmazonLinux 2 End-of-Support campaign.
Overview
After Amazon Linux 2 (AL2) reached end of support on June 30, 2026, you may receive AWS Health notifications identifying AL2 instances in your account. Terminating these instances alone may not resolve the finding if the instance was created by automation (Auto Scaling group, CloudFormation, Terraform, EKS, or CI/CD pipeline), the automation will launch a replacement AL2 instance and it will reappear in a future notification. The durable fix is to correct the source.
This article explains how AWS Health identifies AL2 instances, how to build a complete inventory, and how to trace each instance back to its origin so you can remediate at the source.
How AWS Health identifies AL2 instances
AWS Health identifies AL2 EC2 instances based on operating system information captured during instance launch or reboot events. Instances that recently launched or rebooted appear in the affected-resources list within 1-2 calendar days.
Important considerations:
- Long-running instances that have not rebooted since before April 2026 may not appear, as identification relies on launch or reboot events.
- To include these instances, initiate a reboot and they will appear within 1-2 days.
- AWS Health notifications are per-account, per-region. If you operate across multiple accounts or regions, check each one.
Building a complete AL2 inventory without rebooting
For comprehensive coverage without requiring reboots, use AWS Systems Manager (SSM) to identify all AL2 instances:
aws ssm get-inventory \
--filters Key=AWS:InstanceInformation.PlatformName,Values="Amazon Linux" \
Key=AWS:InstanceInformation.PlatformVersion,Values="2" \
--region us-east-1
SSM does not require a reboot and can be run per-region for complete migration planning coverage. Note that SSM discovery does not add instances to the Health event's affected-resources list, it is a complementary tool for your own tracking.
Recommendation: Use both AWS Health notifications and SSM inventory together. Health captures instances as they cycle. SSM provides immediate, complete coverage regardless of reboot history (for instances with a healthy SSM registration status).
Identifying the source of a flagged AL2 instance
Once you have a specific instance flagged as AL2, determine what created it. If the source is automation, the automation will continue launching AL2 replacements until corrected.
Option 1: Check instance tags
EC2 automatically applies tags that identify the managing resource. Look for:
aws:autoscaling:groupName— instance is managed by an Auto Scaling groupaws:cloudformation:stack-name— instance was created by a CloudFormation stackeks:cluster-name— instance is an EKS worker nodeaws:ec2launchtemplate:id— instance was launched from a specific launch template
If any of these tags are present, they point you directly to the managing resource with no further investigation needed.
Option 2: Look up the launch event in CloudTrail
Every instance was created by a RunInstances API call, which CloudTrail records. Search for the instance ID in CloudTrail. If the instance was launched within the last 90 days, use CloudTrail Event History in the console. For older instances, query your CloudTrail via Amazon Athena or CloudTrail Lake (Event History retains only 90 days).
- Perform the lookup in the account and region where the instance runs.
aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=ResourceName,AttributeValue=i-0abc123def456 \
--region us-east-1
-
Read three fields from the launch event output
-
User agent — classifies the launch as automated or manual.
autoscaling.amazonaws.com— Auto Scaling groupcloudformation.amazonaws.com— CloudFormation- Terraform, EKS, ECS, or Batch agent strings — respective orchestrator
- Console or generic SDK/CLI user agent — a person or bespoke script
-
Calling identity — names the IAM principal, assumed role, and source IP. This identifies the account, role, CI/CD system, or individual responsible.
-
AMI ID — the image used by the launch instance
-
-
Take the AMI ID found above and query for details to confirm whether it is using an AL2 image.
aws ec2 describe-images --image-ids ami-0abc123def456 \
--query 'Images[0].{Name:Name,Description:Description}' \
--region us-east-1
If the same AMI ID recurs across many flagged instances, you have found the single golden image or pipeline producing AL2 instances, and remediating the source referencing this AMI ID would prevent future instantiation of AL2 instances.
Remediating at the source
Once you have identified the source, remediate based on the type:
| Source | Remediation |
|---|---|
| Auto Scaling group | Update the launch template to reference an AL2023 AMI, then perform an instance refresh |
| CloudFormation stack | Update the template's ImageId parameter to an AL2023 AMI and update the stack |
| Terraform / IaC | Update the AMI reference in your Terraform/CDK code, apply the change |
| EKS managed node group | Update the node group to use AL2023 AMI (EKS 1.33+ requires AL2023) |
| ECS container instances | Update the launch template or ASG to use the ECS-optimized AL2023 AMI |
| EC2 Image Builder pipeline | Update the pipeline's base image to AL2023 |
| Manual launch (console/CLI) | Update your documentation or runbooks to reference AL2023 AMIs |
Verifying remediation
After updating the source:
- Terminate the existing AL2 instance(s)
- Confirm that replacement instances launch on AL2023 (check via SSM or instance metadata)
- Monitor subsequent AWS Health notifications — new instances should no longer appear
If instances continue to reappear, there may be multiple sources (e.g., both an ASG and an Image Builder pipeline referencing AL2). Repeat the tracing process for each new instance.
Related resources
- Comparing Amazon Linux 2 and Amazon Linux 2023
- Amazon Linux 2023 migration documentation
- AWS Systems Manager Inventory
- AWS CloudTrail Event History
Last updated: July 2026
- Language
- English
Relevant content
asked 3 years ago
AWS OFFICIALUpdated 3 months ago