Skip to content

How to identify the source of Amazon Linux 2 instances after EOS and prevent further such instances from being created.

5 minute read
Content level: Intermediate
0

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 group
  • aws:cloudformation:stack-name — instance was created by a CloudFormation stack
  • eks:cluster-name — instance is an EKS worker node
  • aws: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).

  1. 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
  1. Read three fields from the launch event output

    • User agent — classifies the launch as automated or manual.

      • autoscaling.amazonaws.com — Auto Scaling group
      • cloudformation.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

  2. 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:

SourceRemediation
Auto Scaling groupUpdate the launch template to reference an AL2023 AMI, then perform an instance refresh
CloudFormation stackUpdate the template's ImageId parameter to an AL2023 AMI and update the stack
Terraform / IaCUpdate the AMI reference in your Terraform/CDK code, apply the change
EKS managed node groupUpdate the node group to use AL2023 AMI (EKS 1.33+ requires AL2023)
ECS container instancesUpdate the launch template or ASG to use the ECS-optimized AL2023 AMI
EC2 Image Builder pipelineUpdate 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:

  1. Terminate the existing AL2 instance(s)
  2. Confirm that replacement instances launch on AL2023 (check via SSM or instance metadata)
  3. 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


Last updated: July 2026