Where things stand
AWS documentation gives 30 June 2026 as Amazon Linux 2's end-of-life date. For Lambda, AWS says some AL2-based runtimes keep receiving patches for critical and selected important AL2 security issues until their own deprecation dates. Don't read that as support for your EC2 instances. Plan as if AL2 hosts get no more fixes, and confirm current status on the Amazon Linux 2 FAQ.
There's no in-place upgrade from AL2 to AL2023. You build new instances on AL2023 and move the workload.
1. Find AL2 everywhere
Running instances (SSM Inventory):
aws ssm get-inventory \
--filters "Key=AWS:InstanceInformation.PlatformName,Values=Amazon Linux,Type=Equal" \
"Key=AWS:InstanceInformation.PlatformVersion,Values=2,Type=Equal" \
--query "Entities[].Data.\"AWS:InstanceInformation\".Content[0].[InstanceId,PlatformVersion,ComputerName]" \
--output text
Instances without SSM Agent won't show up. Cross-check with the AMIs that instances were launched from:
aws ec2 describe-instances --query "Reservations[].Instances[].ImageId" --output text |
tr '\t' '\n' | sort -u |
xargs -n 50 aws ec2 describe-images --image-ids --query "Images[].[ImageId,Name]" --output text 2>/dev/null |
grep -i "amzn2"
(Images that have been deregistered won't resolve; treat those instances as unknown and check them directly.)
Launch templates and AMI pipelines: search IaC for amzn2-ami, al2, and SSM parameters such as /aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2.
EKS and ECS: AL2-based optimised AMIs for nodes also need replacing (AL2023 or Bottlerocket).
2. What changes in AL2023
| Area | Amazon Linux 2 | Amazon Linux 2023 |
|---|---|---|
| Package manager | yum | dnf (yum is an alias) |
| Extra software | amazon-linux-extras | Removed; packages come from the main repo or versioned repos |
| EPEL | Commonly used | Not supported; find packages elsewhere or build them |
| Instance metadata | IMDSv1 allowed by default | AMIs default to IMDSv2 only |
| Python | 2.7 present, Python 3 optional | Python 3 only |
| cron | Installed | Not installed by default (dnf install cronie), or use systemd timers |
| Updates | Rolling | Versioned repository; you choose when to move to a newer release |
| Logs | rsyslog writes /var/log/messages | systemd journal by default (journalctl) |
The scripts most likely to break are user data and configuration management that call amazon-linux-extras, install from EPEL, read /var/log/messages, or use IMDSv1 calls without a token.
3. Migrate by rebuilding
- Build an AL2023 AMI with your usual pipeline (EC2 Image Builder or Packer). Replace each
amazon-linux-extras installand EPEL package with the AL2023 equivalent. - Test the application on a single instance. Check services, log shipping, agents (CloudWatch agent, security agents) and the IMDSv2 calls.
- For Auto Scaling groups, create a new launch template version with the AL2023 AMI and use instance refresh with a minimum healthy percentage.
- For single "pet" servers, build the replacement, move data (EBS snapshot of the data volume or application-level copy), switch DNS or the Elastic IP, and keep the old instance stopped for a short rollback window.
aws autoscaling start-instance-refresh --auto-scaling-group-name web-asg \
--preferences '{"MinHealthyPercentage":90,"InstanceWarmup":300}'
4. Instances you can't move yet
Reduce the risk while you plan:
- Remove public exposure (no public IP; access through SSM Session Manager).
- Restrict security groups to the minimum.
- Monitor with GuardDuty and your EDR tool.
- Record each exception with an owner and a date.
Checklist
- AL2 instances, AMIs, launch templates and node groups listed
- AL2023 AMI built without amazon-linux-extras or EPEL dependencies
- User data and scripts tested with IMDSv2
- Auto Scaling groups moved with instance refresh
- Remaining AL2 hosts isolated, owned and dated