AWS says Amazon Linux 2 (AL2) reaches end of support on 30 June 2026, and recommends that customers migrate to Amazon Linux 2023 (AL2023) before that date. AWS also notes that AL2023 is the latest Amazon Linux release and is supported until June 2029. See the Amazon Linux 2 FAQ and the Amazon Linux 2 end-of-support notice for the current AWS wording.
For small AWS teams, the migration should not be treated as a last-minute operating system swap. It is an opportunity to find old hosts, remove fragile assumptions, improve patching, and produce better evidence for customers, insurers and leadership.
The practical question is:
If we had to rebuild every Amazon Linux 2 system before end of support, which systems would we trust, which would worry us, and which would no one recognise?
1. Start with inventory, not urgency
The first mistake is starting with a production change ticket before knowing where Amazon Linux 2 is actually used.
A useful inventory should include:
- EC2 instances running Amazon Linux 2;
- launch templates and launch configurations;
- Auto Scaling groups;
- golden AMIs or EC2 Image Builder pipelines;
- bastion hosts and administrative jump hosts;
- CI/CD runners and build hosts;
- Elastic Beanstalk, ECS, EKS or other platform-managed environments where the underlying image matters;
- container base images derived from Amazon Linux 2;
- old AMIs kept for rollback;
- user-data scripts, bootstrap scripts and package installation scripts that assume Amazon Linux 2;
- Systems Manager managed instances and patch baselines;
- monitoring, backup, security and endpoint agents installed on those hosts.
Do not rely only on a console view of currently running instances. A stopped instance, launch template, old AMI or pipeline image can still bring Amazon Linux 2 back into production later.
A simple inventory record should capture:
| Field | Why it matters |
|---|---|
| Account and region | Prevents missed systems in secondary accounts or unused regions |
| Host or image owner | Someone must decide whether to migrate, retire or accept risk |
| Business service | Migration priority depends on business impact |
| Internet exposure | Public systems need earlier attention |
| Current patch state | An already stale host is not a good migration candidate |
| Rebuild path | Shows whether the host can be recreated cleanly |
| Backup or rollback path | Reduces pressure during production change |
The first useful output is not a migration plan. It is a list of systems with owners.
2. Separate production systems from historical clutter
Not every Amazon Linux 2 item deserves the same treatment.
Group findings into practical categories:
| Category | Typical action |
|---|---|
| Production and customer-facing | Plan, test and migrate deliberately |
| Internal but important | Migrate or replace on a controlled schedule |
| Build, deployment or administrative | Treat as sensitive because these may have privileged access |
| Staging or development | Rebuild or retire where possible |
| Old AMIs and snapshots | Keep only where the retention reason is clear |
| Forgotten or unowned | Remove, archive or assign ownership before migration work starts |
This prevents the team spending the same amount of effort on a long-forgotten staging host as on a production database helper, while also avoiding the opposite mistake of ignoring a build runner that has broad AWS permissions.
A small team can often reduce the migration workload by retiring systems before migrating them.
3. Understand what might change with AL2023
Amazon Linux 2023 is not just Amazon Linux 2 with a newer date.
AWS documents key differences between AL2 and AL2023, including package, runtime and system changes. AL2023 uses DNF as the default package manager, replacing YUM as used in AL2, and AWS publishes a comparison of AL2 and AL2023 in the Amazon Linux 2023 User Guide. The package-management change is also documented in the AL2023 package management guide.
For migration planning, the important point is not to memorise every difference. The important point is to test the assumptions your current hosts depend on.
Check for:
- package names that have changed or disappeared;
- scripts that call
yumdirectly; - Python, Java, Node, PHP or other runtime assumptions;
- cron jobs, systemd services and timers;
- logging assumptions, including syslog, journald and agent configuration;
- file paths used by application scripts;
- cloud-init and user-data behaviour;
- security agent compatibility;
- backup agent compatibility;
- hard-coded AMI IDs;
- old kernel or library assumptions;
- local firewall rules;
- custom repositories;
- third-party packages installed outside normal package management.
A migration that passes a basic boot test can still fail later if deployment, backup, logging or patching scripts silently stop working.
4. Prefer rebuildable migration over manual in-place change
For most AWS environments, the cleaner migration path is to build new hosts or images, test them, and move traffic or workloads deliberately.
That may mean:
- creating a new AL2023 AMI;
- updating a launch template;
- testing an Auto Scaling group replacement;
- rebuilding a bastion host from documented configuration;
- moving a workload behind a load balancer;
- replacing a CI runner image;
- updating a container base image;
- using infrastructure-as-code rather than manual console changes.
The migration should prove that the host can be rebuilt. If the only known path is “SSH to the old server and carefully change things until it works”, the migration is exposing an operational problem that already existed.
For fragile legacy systems, a short-term exception may be realistic. But the exception should be explicit:
- which host is staying on AL2;
- why it cannot move yet;
- what business service depends on it;
- whether it is internet-facing;
- who owns the risk;
- when it will be retired or migrated;
- what compensating controls are in place.
A risk exception is not ideal, but it is better than pretending the system was missed accidentally.
5. Use the migration to improve the Linux baseline
A migration that preserves every old weakness is a missed opportunity.
Before cutting over a rebuilt host, review the Linux baseline:
- SSH access;
- direct root login;
- unmanaged keys in
authorized_keys; - sudo rules;
- service accounts with shell access;
- patch cadence;
- reboot handling;
- CloudWatch, Systems Manager or other management agent health;
- host firewall settings;
- listening services;
- log collection;
- backup hooks;
- monitoring checks;
- local secrets or configuration files;
- public IP and security group exposure;
- time sync and certificate renewal.
The goal is not to turn the migration into a huge hardening programme. The goal is to avoid rebuilding old risk onto a new operating system.
A useful rule is:
If the system is important enough to migrate, it is important enough to assign an owner, check access and confirm logging.
6. Test the boring operational paths
A successful migration test is more than “the instance starts”.
Test the paths the business will rely on:
- application startup;
- deployment workflow;
- rollback or replacement workflow;
- patching process;
- log delivery;
- monitoring alerts;
- backup process;
- restore assumptions;
- certificate renewal;
- scheduled jobs;
- IAM role permissions;
- database connectivity;
- object storage access;
- outbound vendor integrations;
- inbound customer traffic;
- security agent operation.
If a host is behind a load balancer, test traffic in a controlled way before changing production routing. If a host is a bastion or administrative system, test who can log in, whether old keys were removed, and whether privileged access is recorded.
Do not leave the most important checks until the final cutover window.
7. Prepare evidence for customers and leadership
End-of-support migration often becomes visible to customers when they ask about patching, vulnerability management or unsupported software.
Good evidence does not need to expose the full environment. It should show that the issue is known, owned and being handled.
Useful evidence includes:
| Evidence item | What it shows |
|---|---|
| AL2 inventory summary | The team knows where the affected systems are |
| Migration priority list | Production and public systems were prioritised |
| Completed migration notes | Specific systems have moved or been retired |
| Exception register | Remaining AL2 systems are not being ignored |
| Test notes | The team tested application and operational paths |
| Hardening notes | Access, logging and patching were reviewed during migration |
| Ownership record | Every remaining system has an accountable owner |
Avoid sharing raw host lists, account IDs, internal DNS names or detailed architecture unless there is a clear reason. A customer-safe summary is usually enough.
8. Weak vs stronger answers
| Question | Weak answer | Stronger answer |
|---|---|---|
| Are you affected by Amazon Linux 2 end of support? | We are checking. | We have inventoried affected AWS accounts and classified AL2 systems by business impact and exposure. |
| Have you migrated? | Mostly. | Production customer-facing systems have been migrated or have assigned migration dates. Remaining exceptions are tracked with owners. |
| Are unsupported systems still running? | Maybe a few. | Any remaining AL2 systems are documented, risk-assessed and scheduled for migration, replacement or retirement. |
| Did you test the migration? | The instance starts. | Application startup, deployment, logging, monitoring, backup and rollback paths were tested for important systems. |
| Did the migration improve security? | We changed the OS. | SSH, sudo, patching, logging, exposure and ownership were reviewed as part of the migration baseline. |
The stronger answers are more precise. They do not claim perfection. They show control.
9. Common migration gaps
Common findings in small AWS environments include:
- production instances are known, but launch templates still reference old AL2 AMIs;
- old AMIs remain available and undocumented;
- staging hosts are public and unpatched;
- CI runners use AL2 and have broad AWS permissions;
- user-data scripts install packages that do not exist on AL2023;
- monitoring agents are missing from rebuilt hosts;
- backup jobs were configured manually and not recreated;
- SSH access was copied forward without review;
- no one knows who owns a legacy host;
- migration evidence exists only in chat messages.
These problems are usually fixable. The first step is making them visible.
10. What good AL2 migration leaves behind
A good Amazon Linux 2 migration should leave the team with more than new instances.
It should leave behind:
- a cleaner host inventory;
- fewer unowned systems;
- current launch templates and AMIs;
- better SSH and sudo hygiene;
- clearer patching expectations;
- working logging and monitoring;
- tested backup and restore assumptions;
- documented exceptions;
- customer-safe evidence;
- a repeatable path for the next operating system lifecycle event.
The best outcome is not simply that Amazon Linux 2 disappears. The best outcome is that the AWS and Linux environment becomes easier to operate, explain and harden.