Amazon Linux History and Timeline - Amazon Linux AMI, Amazon Linux 2, AL2023, AL2027, and the Clocks That Do Not Move Your Instances
First Published:
Last Updated:
Readers often have two primary questions regarding this topic. First, how long will the current generation continue to be supported and what features will it continue to offer? Second, who is responsible for planning and executing the transition to the next generation? While official dates provide answers to both questions, that information is scattered across four separate locations: the user guide's release cadence section, the release notes' document history, the product page's FAQ, and AWS What's New. Simply collecting numbers without context can lead to misunderstandings.
The first thing to know is that Amazon Linux does not have a single expiration date. Each individual AMI carries a deprecation date 90 days out. Kernel live patches are discontinued after three months. The kernel itself has a Long-Term Support (LTS) period of four years. The distribution itself has two support phases; for AL2023, they are bounded by 2027-06-30 and 2029-06-30. These four clocks run independently, and none of them moves a running instance.
This article presents a timeline, constructed solely from officially published dates, detailing the four generations of Amazon Linux. It is not a feature overview of the distribution, and it does not compare Amazon Linux with other distributions.
Related articles on this site:
- AWS End-of-Support and EOL Reference - Lambda, EKS, RDS and Aurora, ElastiCache, and OpenSearch Service
- AWS Service Lifecycle States - Maintenance, Sunset, Full Shutdown, and What Each One Takes Away
- AWS History and Timeline regarding Amazon EC2 - Overview, Functions, Features, Summary of Updates, and Introduction
- Amazon EC2 Instance Types History and Timeline - Instance Families, Generations, and Introduction
- AWS History and Timeline regarding Amazon EKS - Overview, Functions, Features, Summary of Updates, and Introduction
- AWS History and Timeline regarding AWS Lambda - Overview, Functions, Features, Summary of Updates, and Introduction
Background and Method of Creating the Amazon Linux Historical Timeline
The reason for creating this timeline is that dates related to the Amazon Linux lifecycle are not consolidated in one place. Sometimes, the same fact is expressed differently depending on where it is written.The dates originate from four main sources:
- AWS What's New: The announcement date. This article takes the date under
Posted on:on the page as the definitive one. - User guides and release notes document history: The version number and the date that version was released.
- Product page FAQs: Current statements regarding support periods. This source often contains the most up-to-date lifecycle dates.
- AWS Official Blog update notes: Occasionally, after an initial announcement, changes occur, and those changes are documented only in the update note at the top of the article, not in the body.
When constructing this timeline, the following principles were applied:
- To trace the lineage of the Amazon Linux product itself, arranging generations and support milestones in chronological order.
- To compile a list of the current state of each generation, as well as any features that have been replaced between generations.
Inclusion Criteria: The timeline includes dates related to the introduction and general availability of each generation, support milestones, minor releases that significantly impacted the system, changes to default settings, and features where the user's workload either increased or decreased. Each entry includes a URL to the primary source where the date was verified. Any entries without verifiable URLs have not been included.
Certain items have been intentionally excluded. The deprecation dates for Lambda runtimes are not covered in this article. This is because the runtime table and the Amazon Linux product lifecycle are separate, and dates may occasionally appear to coincide by chance. For more information, please refer to AWS End-of-Support and EOL Reference. AWS Service Lifecycle States defines state words such as maintenance and sunset. Separate resources exist for the timeline of Amazon EC2 and instance families, the lineage of Amazon EKS AMIs, and the correspondence between AWS Lambda runtimes and Amazon Linux generations. Operational procedures for applying patches are also outside the scope of this article. Pricing is not addressed.
Track Values: The second column in the timeline indicates the type of event represented by each row.
Launch— The generation was announced or general availability began.Lifecycle— The boundary of support periods. The announcement date and the date when the support takes effect are listed on separate lines.Release— A minor release (quarterly update).Default— The default value changed.Feature— A new feature was added to that generation.Scheduled— A date that has not yet arrived. This is an officially published schedule.
Accuracy. All dates are listed in
YYYY-MM-DD format. An exception is the end-of-support date for AL2027, where the original source only provided the year, so it is listed as 2032. The final version of AL1 was only publicly announced with a version number of 2018.03 and is not treated as a date.Sourcing Policy. This timeline was created using only primary sources. These include AWS What's New, AWS user guides and release notes, product page FAQs, and the official AWS blog. Summary websites and news articles were not used as sources for any dates. No judgments are made regarding the selection of generations or default values.
The primary sources consulted are:
- Amazon Linux 2023 User Guide - Release cadence
- Document history for Amazon Linux 2023 Release Notes
- Amazon Linux AMI FAQs
- Amazon Linux 2 FAQs
- Amazon Linux 2023 FAQs
- Amazon Linux 2027 User Guide - Release cadence
- AWS What's New
Some of the older AWS What's New pages are no longer served. Within this article, three entries fall into this category; clicking their links leads to AWS index pages rather than the original announcement. The original URLs stay as they are. The dates and the wording of those entries were checked against the publication timestamps and bodies that the What's New API still holds.
This timeline includes only those events that were deemed essential for understanding how Amazon Linux has evolved to its current state.
In other words, please note that the items on this timeline are not all updates to Amazon Linux, but are representative milestones that I have picked out.
The verification date is 2026-09-09. Support dates and availability status were verified against primary sources as of this date.
Amazon Linux Historical Timeline (Updates from September 14, 2010)
This timeline details the evolution of Amazon Linux, from the initial announcement of the first AMI through to the fourth-generation public preview. Each entry includes a link to the relevant announcement, user guide, FAQ, or official blog post.Use the following index to navigate by year:
- 2010 - Initial launch as a single AMI.
- 2014 - Announcement of the end of 32-bit AMI support.
- 2015 - End of 32-bit support.
- 2016 - Introduction of container images.
- 2017 - Second-generation release appears as an LTS candidate.
- 2018 - General availability of Amazon Linux 2.
- 2019 - Migration tools and Extras kernel.
- 2020 - Extension of end-of-life for the first generation, and general availability of live patching.
- 2021 - First generation enters maintenance, third generation enters preview.
- 2023 - General availability of AL2023 and end-of-life for the first generation.
- 2024 - Quarterly updates continue.
- 2025 - Kernel end-of-life approaches.
- 2026 - End of second generation, default kernel migration, fourth generation preview.
- 2027 - End of standard support for AL2023.
- 2029 - End of maintenance for AL2023.
- 2032 - End of support for AL2027.
You can sort the table by clicking on the column name. Sorting by the
Track column groups the generation rows and the lifecycle rows separately.| Date | Track | Summary |
|---|---|---|
| 2010-09-14 | Launch | The Amazon Linux AMI was announced. It was introduced as a Linux image for Amazon EC2, provided and maintained by AWS, and described as including a suite of packages designed to simplify integration with AWS, offered at no additional cost. This was the first generation, later known as Amazon Linux 1 (AL1). References: Announcing the Amazon Linux AMI |
| 2014-09-23 | Release | Amazon Linux AMI 2014.09 was made available across all regions. It included the kernel 3.14, Ruby 2.1, Java 8, Tomcat 8, PostgreSQL 9.3, and Docker 1.2, among other components. It was announced that this release would be the last to generate a 32-bit AMI. References: Amazon Linux AMI 2014.09 / Functionality deprecated in AL2 and removed in AL2023 |
| 2015-03-24 | Release | Amazon Linux AMI 2015.03 was released. The user guide noted that, from this version onwards, Amazon Linux no longer supported system execution in 32-bit mode. There was one release between the initial announcement and the actual discontinuation. References: Amazon Linux AMI 2015.03 / Functionality deprecated in AL2 and removed in AL2023 |
| 2016-11-01 | Feature | Amazon Linux container images were introduced. These images, available from Amazon ECR and Docker Hub, were built from the same software configuration as the Amazon Linux AMI, allowing them to be used as Docker base images outside of Amazon EC2. From this point forward, Amazon Linux was no longer solely a product of AMIs. References: Introducing New Amazon Linux Container Image for Cloud and On-Premises Workloads |
| 2017-12-13 | Launch | Amazon Linux 2 (AL2) was announced. Introduced as the next-generation Amazon Linux, it stated that the core operating system would receive 5 years of long-term support, and that the latest packages would be accessible through the Amazon Linux Extras repository. At this point, it was positioned as a Long-Term Support (LTS) candidate. References: Introducing Amazon Linux 2 |
| 2018-04-09 | Launch | Amazon Linux 2 LTS Candidate 2 was released. This was the second candidate build provided prior to general availability. References: Announcing Amazon Linux 2 LTS Candidate 2 |
| 2018-06-26 | Launch | Amazon Linux 2 began general availability, with 5 years of long-term support. This version incorporated feedback from the two LTS candidate builds and included kernel 4.14, systemd, GCC 7.3, glibc 2.26, and binutils 2.29.1. Additional software can be installed through the Extras mechanism. This generation marked the transition from System V init to systemd. References: Announcing Amazon Linux 2 with Long Term Support (LTS) |
| 2018-09-25 | Feature | Amazon Linux 2 added support for 32-bit applications and libraries. This brings back limited 32-bit execution, which was discontinued in the first generation (2015.03). This functionality was again lost in the third generation. References: Amazon Linux 2 Now Supports 32-bit Applications and Libraries |
| 2019-03-07 | Feature | A preupgrade assistant is now available to help migrate from Amazon Linux AMI to Amazon Linux 2. When run on active instances, it checks for incompatibilities in packages, libraries, services, command-line options, and configuration files, and generates a report. This tool is designed with the assumption that the migration process is the user's responsibility. References: Announcing the Preupgrade Assistant to Migrate to Amazon Linux 2 From Amazon Linux AMI |
| 2019-07-26 | Feature | A new kernel, optimized by AWS, has been added to Amazon Linux 2 Extras. Initially, kernel 4.19 was made available through the Extras channel. The kernel that stayed both the default and the one under long-term support was 4.14. At this point, using the new kernel and receiving long-term support are separate choices. References: Amazon Linux 2 Extras now provides AWS-optimized versions of new Linux Kernels |
| 2020-01-27 | Lifecycle | The end-of-life date for Amazon Linux AMI has been extended from 2020-06-30, to 2020-12-31, and a maintenance support period has also been announced. This extension is based on feedback from users. The blog post was amended twice afterwards with further update notes. References: Update on Amazon Linux AMI end-of-life |
| 2020-04-28 | Feature | Kernel Live Patching is now available in preview for Amazon Linux 2. This allows you to apply security updates to running kernels without requiring a reboot. References: Kernel Live Patching is now available in Preview for Amazon Linux 2 |
| 2020-06-29 | Feature | Kernel Live Patching for Amazon Linux 2 is now generally available. It is available to all users without additional charge. This is positioned as an alternative to the traditional process of redistributing updated AMIs or applying patches and restarting instances, with the goal of reducing downtime. References: Kernel Live Patching for Amazon Linux 2 is now generally available |
| 2021-01-01 | Lifecycle | The Amazon Linux AMI left standard support and entered maintenance support. During this phase, only critical and important security updates for a limited set of packages will be provided, and support for new Amazon EC2 features and new AWS features will no longer be guaranteed. The end-of-life date is announced as 2023-12-31. References: Update on Amazon Linux AMI end-of-life / Amazon Linux AMI FAQs |
| 2021-11-19 | Release | An Amazon Linux 2 AMI with kernel 5.10 was released. It includes optimizations for Intel Ice Lake and AWS Graviton2, and supports live patching on both x86 and ARM architectures. According to the publicly available release notes for AL2 as of the verification date, two SSM parameters are listed for the AMI: 4.14 and 5.10, with kernel-default referring to 5.10. References: Amazon Linux 2 AMI is now available with kernel 5.10 |
| 2021-11-22 | Launch | The public preview of Amazon Linux 2022 (AL2022) was announced. This announcement outlined the policy of providing major new versions every two years, with each version supported for five years. The ability to pin repository versions was also highlighted. This product will be named Amazon Linux 2023 upon general availability. References: Announcing preview of Amazon Linux 2022 |
| 2023-03-15 | Launch | Amazon Linux 2023 (AL2023) began general availability. The document history in the release notes records version 2023.0.20230315 as the initial general availability release. The package management system has been updated from yum to dnf, and deterministic upgrades, allowing users to pin repository versions, are now enabled by default. References: Announcing Amazon Linux 2023 / Document history for Amazon Linux 2023 Release Notes / Amazon Linux 2023, a Cloud-Optimized Linux Distribution with Long-Term Support |
| 2023-06-28 | Release | AL2023.1 now supports secure boot. This is the initial version released as a minor update for the quarter. References: Amazon Linux announces support for secure boot with AL2023.1 |
| 2023-10-10 | Release | AL2023.2 now supports Ansible and Amazon Corretto 21. References: Amazon Linux announces support for Ansible and Corretto 21 with AL2023.2 |
| 2023-12-15 | Release | AL2023.3 now provides KVM and VMware images. This release expands the options for running AL2023 outside of Amazon EC2. References: Amazon Linux announces support for KVM and VMWare images with AL2023.3 |
| 2023-12-31 | Lifecycle | The Amazon Linux AMI reached end of life. No further security updates or bug fixes will be provided as of 2024-01-01. That is more than 13 years after the first announcement, and three and a half years after the originally planned end-of-life date. References: Amazon Linux AMI FAQs / Update on Amazon Linux AMI end-of-life |
| 2024-03-25 | Release | AL2023.4 is now available. This release includes packages such as mock, lustre-client, fetchmail, and smart-restart. References: Amazon Linux announces new quarterly update with AL2023.4 and availability of EKS optimized AMI |
| 2024-06-26 | Release | AL2023.5 was released, featuring new versions of PHP and Microsoft .NET, as well as IPA Client and mod-php. References: Amazon Linux announces availability of AL2023.5 with new versions of PHP and Microsoft .NET |
| 2025-04-01 | Release | AL2023.7 was released, introducing a graphical desktop environment powered by GNOME 47, the option of kernel 6.12, and OpenSSL 3.2.2. This is the seventh quarterly update. The desktop environment has been changed from MATE, which was previously used in AL2. References: Announcing the general availability seventh quarterly update for Amazon Linux 2023 (AL2023), AL2023.7 |
| 2025-10-31 | Lifecycle | Live patching for kernel 4.14 on Amazon Linux 2 has ended. The user guide recommends either using kernel 5.10 as the default kernel for AL2, or migrating to AL2023, which includes kernel versions 6.1 or 6.12. This occurred eight months prior to the end-of-support date for the product itself, with the kernel support reaching its end first. References: Kernel Live Patching on AL2 |
| 2025-11-11 | Feature | Mountpoint for Amazon S3 has been included in Amazon Linux 2023. References: Mountpoint for Amazon S3 is now included in Amazon Linux 2023 |
| 2025-11-17 | Lifecycle | The end-of-support date for Amazon Linux 2 has been extended to 2026-06-30. This change is noted in an updated section at the beginning of the AWS official blog post announcing the general availability of AL2023. No separate What's New announcement for this change was found in the search this article performed. References: Amazon Linux 2023, a Cloud-Optimized Linux Distribution with Long-Term Support |
| 2025-11-18 | Feature | Supplementary Packages for Amazon Linux (SPAL) are now generally available. This dedicated repository contains numerous packages derived from EPEL9 and is compatible with AL2023. It is not covered by AWS Enterprise Support and does not receive CVE tracking from AWS. It serves as a replacement for the functionality previously provided by AL2 Extras, but with different support conditions. References: AWS announces Supplementary Packages for Amazon Linux / Amazon Linux 2023 FAQs |
| 2026-06-30 | Lifecycle | Amazon Linux 2 has reached its end-of-support date. The product page states that it will no longer receive standard security updates and encourages users to migrate to AL2023. There is no Extended Lifecycle Support program available. References: Amazon Linux 2 FAQs / Security-Focused, High-Performance Linux Environment - Amazon Linux 2 / How do I get extended lifecycle support for RHEL 7 and AL2 after their end-of-support date? |
| 2026-08-17 | Default | The kernel-default SSM parameter for AL2023 moved from kernel 6.1 to kernel 6.18. This is the first instance of a change to the default parameter since its initial release. Currently running instances will not be affected, as they continue to use the kernel version they were launched with. Going forward, this default will advance once per year, after a validation period of 3 to 6 months following the general availability of a new kernel. References: Amazon Linux default SSM parameter will now track the latest kernel / The Amazon Linux Kernel |
| 2026-09-03 | Launch | The public preview of Amazon Linux 2027 (AL2027) has been announced. This is the fourth generation and the successor to AL2023, and it highlights the 7.1 kernel, enforcing SELinux by default, and AWS-LC as a cryptographic library. It is explicitly stated that the preview is for evaluation and validation purposes and is not recommended for production workloads. References: Amazon Linux 2027 is now available in public preview / What is Amazon Linux 2027? |
| 2026-09-09 | Release | Version 2023.12.20260909 of AL2023 has been released. As of 2026-09-09 (the verification date), this is the latest version listed in the document history of the release notes. The minor version number has reached 12. References: Document history for Amazon Linux 2023 Release Notes |
| 2027-06-30 | Scheduled | Standard support for AL2023 is scheduled to end. Following this date, quarterly minor version updates will cease, and the product will enter a maintenance phase. References: Amazon Linux 2023 User Guide - Release cadence |
| 2029-06-30 | Scheduled | The maintenance phase for AL2023 is scheduled to end. During the maintenance period, security updates and critical bug fixes will be released as they become available. References: Amazon Linux 2023 User Guide - Release cadence |
| 2032 | Scheduled | Support for AL2027 is scheduled to end. The AL2027 user guide states that support will end in 2032, but the specific date is not provided as of the verification date. References: Amazon Linux 2027 User Guide - Release cadence |
Current Overview of Amazon Linux Generations and Support
With the timeline in hand, this section sets out the picture as of the verification date, 2026-09-09.The Four Generations at a Glance
Amazon Linux has four generations. Two of these have already reached the end of updates, one is currently supported, and one is in preview.
| Generation | Announcement | General Availability | End of Standard Support | End of Support |
|---|---|---|---|---|
| Amazon Linux AMI (AL1) | 2010-09-14 | 2010-09-14 (announced as initial release) | 2020-12-31 | 2023-12-31 |
| Amazon Linux 2 (AL2) | 2017-12-13 | 2018-06-26 | No distinction between standard support and maintenance was found in the primary sources. | 2026-06-30 |
| Amazon Linux 2023 (AL2023) | 2021-11-22 (as AL2022 preview) | 2023-03-15 | 2027-06-30 | 2029-06-30 |
| Amazon Linux 2027 (AL2027) | 2026-09-03 (public preview) | Not yet available | No date was given in the primary sources as of the verification date. | 2032 |
Only the AL2 row does not have two phases. The Amazon Linux 2 FAQ lists only one end-of-support date, and as of the verification date, no distinction between standard support and maintenance was found in the primary sources for AL2. AL1 has two phases, and both AL2023 and AL2027 also have two phases.
The generational phases overlap. At the time AL2 became generally available (2018-06-26), AL1 was still receiving standard support, and when AL2023 became generally available (2023-03-15), AL1 was in the maintenance phase, while AL2 was still receiving standard support. Even as of the verification date, both the standard support for AL2023 and the preview for AL2027 are running concurrently. Each new generation arrived while the previous one was still receiving updates.
The name changed midway through. The third generation was initially released as Amazon Linux 2022 in a public preview on 2021-11-22, but was released as Amazon Linux 2023 on 2023-03-15. As of the verification date,
aws.amazon.com/linux/amazon-linux-2022 redirects to the product page for AL2023. Non-existent paths in the same hierarchy return 404, so this route is one that has been kept for the old name.What Changed Between Generations
As generations change, package management, init systems, and update models all undergo changes. This represents a shift far beyond simply incrementing a version number.| Axis | AL1 | AL2 | AL2023 | AL2027 (preview) |
|---|---|---|---|---|
| Init | System V init | systemd | systemd 252 | systemd 260 (support for System V service scripts removed) |
| Package Management | yum | yum | DNF 4.14 | DNF5 5.4 |
| Update Model | Default releasever=latest (rolling) | Rolling | Locked to a repository version (deterministic upgrades) | Locked to a repository version |
| Security Updates on First Boot | Applied by default | Applied by default | Not applied by default | Not applied |
| Entry Point for Additional Packages | EPEL | amazon-linux-extras | None. SPAL added on 2025-11-18 | — |
| Default SELinux | — | — | permissive | enforcing |
| Networking | — | dhclient | systemd-networkd | systemd-networkd |
| cgroup | — | v1 | v2 | v2 |
| Scheduled Tasks | — | cron | systemd timers (cron is not installed by default) | — |
| Logging | — | rsyslog | systemd journal | — |
| Desktop | — | MATE | GNOME (2023.7 and later) | — |
| 32-bit User Space | Discontinued in 2015.03 | Limited support | None | — |
| Default JVM | — | — | Amazon Corretto | — |
| Cryptographic Library | OpenSSL | OpenSSL | OpenSSL | OpenSSL 3.5 is the default. AWS-LC is shipped alongside it. |
The
— in the table indicates that a description for that generation could not be found in primary sources as of the verification date. This does not necessarily mean that the corresponding feature did not exist. The high number of — entries in the AL2027 column is due to the fact that publicly available documentation at the preview stage primarily focuses on the differences from AL2023.Some capabilities leave and come back across generations. AL1 dropped the 32-bit user space in 2015.03, AL2 brought a limited form of it back, and AL2023 dropped it again. Similarly, the entry point for additional packages transitioned from EPEL in AL1, to
amazon-linux-extras in AL2, then had no equivalent in AL2023, before returning as SPAL on 2025-11-18. However, SPAL is not covered by AWS Enterprise Support, and does not receive CVE tracking from AWS. Even when a feature is reintroduced, the support conditions may not be the same.Two Phases of Support - Standard Support and Maintenance
The AL2023 user guide divides support into two phases:Amazon Linux 2023 (AL2023) was released in March 2023 and will be supported until June 30, 2029.
There are two phases of support:The standard support phase provides minor version updates on a quarterly basis. These updates include security patches, bug fixes, and new features and packages. This phase ends on 2027-06-30.
The maintenance phase provides only security patches and critical bug fixes, released as they become available. This phase ends on 2029-06-30.
The difference between the two phases lies in the content of the updates, not the availability of updates. Even after entering the maintenance phase, users will continue to receive security updates. What stops are the addition of new features and packages. The AL1 FAQ provides more specific details about what ends during the maintenance support phase. Support for new Amazon EC2 instance types, new AWS services and features, and the addition of new packages will cease. Only critical and important security patches will be provided for a targeted set of packages.
The end of the maintenance phase does not mean that the generation will no longer be usable. The AL1 FAQ answers the question of whether you can still launch Amazon Linux AMI after the maintenance support period ends by saying that you can. The FAQ adds that AWS will give advance notice if that policy changes. The generation does not stop working. Updates simply stop arriving. This distinction is crucial for operational decision-making.
The state words themselves, such as maintenance and sunset, are organized in AWS Service Lifecycle States.
Four Clocks, and None of Them Moves a Running Instance
Amazon Linux does not have a single expiration date. Four clocks of different lengths run at the same time.
| Clock | Duration | What Happens | Scope as Described in Primary Documentation |
|---|---|---|---|
| Individual AMIs | 90 days | The AMI receives a deprecation date. | Described in relation to AL2023 AMIs. |
| Kernel Live Patch | 3 months | No new live patches will be released for that kernel version. | Described for both AL2023 and AL2 for the same 3-month period. |
| Kernel LTS | 4 years (2 years full support + 2 years maintenance support) | The kernel reaches end-of-life, and AMIs specific to that kernel will no longer be updated. | Described in relation to the LTS kernel for AL2023. |
| Distribution | AL2023: From March 2023 to 2029-06-30 (two phases) | Updates for the distribution itself cease. | Each generation has a chapter detailing the release cadence. |
The fourth column was added because the four durations do not all apply to the same scope. The 90-day and 4-year durations are described in relation to AL2023, while the primary sources do not state that these same durations apply to AL2 AMIs or kernels. Only the 3-month period is consistently described for both generations.
The first two durations are approximately the same, while the remaining two are significantly different in scale. There's a reason why the first two durations align.
Mixing up the shortest clock with the longest one throws the reading of the whole timeline off. The AL2023 user guide includes notes to prevent this confusion.
The 90 day deprecation date refers to an individual AMI and doesn't refer to the AL2023
Release cadence or product support period.The same page explains that the 90 days match the period for which Kernel Live Patching covers each individual kernel release. That is why the first two clocks line up. The AMI deprecation date therefore hangs off the kernel live patch window, not off the product lifecycle.
However, Kernel Live Patching is disabled by default in AL2023. To use it, you need to install a DNF plugin, enable the live patching feature, and start the
kpatch service. The 90-day duration for the AMI is therefore determined based on the provision period for a feature that is not enabled by default. The two facts sit on different pages of the same user guide.The kernel's lifecycle operates on a separate timeline. AL2023 releases a new LTS kernel in the first quarter of every year, based on the upstream annual LTS kernel. Each LTS kernel is supported for four years: the first two years with full support, followed by two years of maintenance support. During the full support phase, all CVE fixes, regardless of severity, are incorporated through regular rebases to the upstream LTS kernel. During the maintenance support phase, critical and important CVEs with a CVSS score of 7.0 and above, together with known exploited vulnerabilities, are backported; low and medium severity CVEs are not backported.
Kernel-specific AMIs will no longer be updated after the end of support date of a kernel.None of these four clocks moves a running instance.
Running instances are not automatically updated to a new kernel. To upgrade the kernel on an
existing instance, you must explicitly install the new kernel package and reboot.The default kernel migration that occurred on 2026-08-17, clearly demonstrates this characteristic. The AL2023 SSM parameter,
kernel-default, which has consistently pointed to kernel 6.1 since its introduction, has now changed to kernel 6.18. New instances will boot using kernel 6.18, but instances already running will continue to use the kernel they were initially started with. The fact that the default kernel has changed does not mean that your instance will automatically update.Deterministic Upgrades - What Is Guaranteed and What Is Left to You
The most significant design change in AL2023 is the introduction of deterministic upgrades. AMIs and container images ship locked to one version of the repository. Instances launched from the same AMI will have the same package versions.What is guaranteed is consistency. Regardless of how many instances are launched from the same AMI, their configurations will be consistent. According to the official explanation, this makes it easier to fold OS updates into continuous integration and continuous deployment.
The responsibility for applying updates remains with the user.
By default, your AL2023 instance doesn't automatically receive additional critical and
important security updates at launch.The AL2023 FAQ answers the question of whether running instances automatically receive critical and important security updates, stating that by default, they do not. While the default behavior can be changed to enable automatic updates, or to receive only security updates, nothing will happen if you take no action.
In AL1, the default behavior was the opposite. AL1 defaulted to
releasever=latest and, upon initial launch, applied critical and important user-space security updates before services like SSH were started. A lock on launch mechanism was provided for users who wanted to pin the version, and pinning was the explicit act. In AL2023, this default behavior has been reversed.Therefore, in AL2023, users must choose one of three paths to receive updates. They can either relaunch from a new AMI, upgrade the repository version on running instances, or change the default settings to enable automatic updates. Regardless of the choice, the decision-making process remains with the user. AWS Systems Manager Fleet Operations at Scale covers how to apply updates across an entire fleet.
Furthermore, the AL2023 user guide does not recommend reverting to the latest version.
Running `dnf --releasever=latest update` is not best practice, and is likely to result in an
OS update being first tested in production.Instead, it encourages users to specify a version, explaining that using a command like
dnf --releasever=2023.12.20260817 update will ensure that the system is always updated to that specific version. The default approach that was standard in AL1 is now explicitly discouraged in AL2023.The same page directly refutes two common assumptions regarding OS updates. One is the assumption that the OS provider will never make mistakes in their updates. The other is the assumption that the specific behavior of, or interface to, the OS that you rely on is behavior the provider also considers something to be relied upon.
The user guide itself gives an example of this design earning its keep. In one instance, a problem existed in a particular version, and when it was corrected in the subsequent release, affected users were able to immediately revert to the previous AMI and container images. The ability to lock to a specific version is not only a way to halt updates, but also a mechanism to roll back.
Moving Between Generations Is a Rebuild, Not an Upgrade
There is no in-place path for transitioning between generations. This is consistent across two generational changes.The Amazon Linux 2 FAQ states regarding migration from AL1 to AL2:
No, an in-place upgrade from the existing Amazon Linux image to Amazon Linux 2 is not
supported.The same FAQ states plainly that a rolling upgrade will not turn an AL1 instance into an AL2 one. It frames this as leaving existing applications undisturbed, which read the other way means that nothing moves unless someone moves it.
The same applies to transitions from AL2 to AL2023. An AWS official blog post in a migration article states:
There is no in-place upgrade path from AL2 to AL2023.However, transitions within the same major version can be performed in-place. Upgrading minor versions of AL2023 involves checking the available repository versions using
dnf check-release-update and then selecting the desired version with dnf upgrade --releasever=version. The user guide states that pre-upgrade validation is not required for minor releases, because minor releases do not bring changes that break application compatibility. For major version upgrades, however, the guide recommends validating your applications, as packages may be added, removed, or modified.Tools to assist with cross-generational transitions have been provided at various times. The preupgrade assistant, released on 2019-03-07, was designed to inspect AL1 instances for incompatibilities in packages, libraries, services, command-line options, and configuration files, generating a report. The tool's function was to inspect and report; migrating was the user's responsibility.
The kernel design incorporates features to aid in transitions.
To simplify migrations between Amazon Linux distributions, at least one kernel version will be
available on both the current and the next Amazon Linux distribution.The design anticipates a process of upgrading to a new kernel on the current distribution, validating it, and then migrating to the next distribution with the same kernel version. The goal is not to eliminate the transition itself, but rather to reduce the number of changes that occur simultaneously during the transition.
The same logic applies to the deprecation of features. The user guide states that preparing for the next major version should be done on top of the currently used generation. It explains that by reviewing the list of features deprecated in AL2023 and discontinuing their use while still using AL2023, the major version upgrade will be a smaller and safer series of steps. The AL2027 user guide provides a specific example: AL2027 has removed the System V init scripts that were deprecated in AL2023, and workloads that were migrated to
systemd unit files while still using AL2023 can be moved without any changes.Deprecation may not be completed within a single generation. The AL2023 user guide, for example, outlines how AL1 deprecated 32-bit AMIs, AL2 deprecated 32-bit packages, and AL2023 deprecated 32-bit runtime support. It also notes that the migration from IMDSv1 spans multiple major versions. This is why a generation timeline is worth following. When a change is spread across three generations, it can be difficult to determine your current position simply by reading the documentation for a single generation.
As of the verification date, the specific steps for migrating from AL2023 to AL2027 have not been publicly released, due to AL2027 being in a preview stage. However, the AL2023 FAQ states that major releases will support in-place updates on a package-by-package basis. This explanation did not apply to the migration from AL2 to AL2023, and currently, there is insufficient information available to determine how the next generation will handle this transition.
What AL2023 Turns On by Default
AL2023 ships with several settings enabled by default. When you move to a new generation, these settings become active without being asked for.By default, any instances launched with the AL2023 AMI require IMDSv2-only and your default
hop limit will be set to 2 to allow for containerized workload support.This is achieved by setting the
imds-support parameter to v2.0 in the AMI. If you need to use IMDSv1, you can override this setting in the instance metadata options. The AL2023 FAQ notes that registering AMIs that only boot with IMDSv2 was one of the changes introduced between the candidate release and general availability.In AL2023, SELinux is set to permissive by default. To switch to enforcing mode, you can run the
setenforce command or configure it through cloud-init user data at boot time. The instance remembers the initially configured SELinux setting after a reboot and continues to use it unless you change it. In the AL2027 preview, this default has been changed to enforcing.Many of the kernel hardening features are enabled by default, including features related to secure boot, such as kernel module signing. The cryptographic policy is not preset; you configure it either at launch time or at run time. Changes from AL2 include UEFI Preferred, Secure Boot, cgroup v2, and the conversion of
/tmp to tmpfs.Tracking when these defaults changed and understanding the impact on existing resources is a separate topic. This article focuses on the generational lineage, while the history of AWS-wide default changes is documented in AWS Security Defaults History.
Failure Modes and Anti-Patterns
| Failure Mode | What Happens | What to Do Instead |
|---|---|---|
| Interpreting the AMI deprecation date as the product's end-of-support date. | Users may misunderstand that the product will end in 90 days, leading to unnecessary migration planning. Conversely, they might continue using older AMIs, assuming the date applies to them as well. | Read the 90 days as the deprecation date of one AMI, and read the product's two dates from the release cadence section. Refer to the user guide's notes, which explicitly separate these two dates. |
| Pinning an AMI ID instead of tracking the latest AMI. | Instances launched from that AMI will use packages from the time the AMI was created. Deterministic upgrades guarantee that the version stays put; they do not carry updates to the instance. | Resolve the latest AMI using SSM parameters, or incorporate a process to update the repository version into your operations. |
| Assuming that because the default kernel moved, running instances moved with it. | Running instances continue to use the kernel from when they were initially launched. The end-of-support date of that kernel runs separately for each instance. | Verify the kernel version of running instances and check the support window for that specific kernel. |
| Believing that applying live patches eliminates the need for reboots. | One kernel version receives live patches for only three months. To continue receiving live patches, you must migrate to a new kernel and reboot. | Live patches are a mechanism to extend the time before a reboot is required. A reboot is still ultimately necessary. |
| Postponing generational replacements as an indefinite task. | Because there is no in-place upgrade path, a generational replacement requires rebuilding. The move does not happen by itself on the end-of-support date. | Plan the rebuild process, working backward from the generational support end date. |
| Reading a generation past its end-of-support as still supported, because updates are still appearing. | Support is determined by the statements on the product page and in the FAQ. The continued release of related components does not indicate ongoing support. | Refer to the end-of-support information on the product page and in the FAQ. |
| Taking the deprecation date for a Lambda runtime as a date for Amazon Linux. | Because the runtime table lists Amazon Linux versions as a column, the dates appear to relate to the product's lifecycle. | The dates for the runtimes can be found in AWS End-of-Support and EOL Reference, while the dates for the products are listed in the release cadence section. |
Where the Primary Sources Disagree
Cross-referencing the primary sources on 2026-09-09 turned up places where they describe the same fact differently. This article presents both descriptions and does not decide which one is correct.| # | Issue | Description in One Source | Description in the Other Source |
|---|---|---|---|
| A | Length of standard support and the name of the subsequent phase | The release cadence section states that standard support ends on 2027-06-30, and calls the next phase maintenance. | The naming and versioning section states that minor releases occur during the two years of standard support and refers to the subsequent phase as extended support, with its start condition tied to the release of the next major version. |
| B | Support period for AL2023 | The section comparing AL2 and AL2023 states For AL2023, we offer five years of support. | The release cadence section specifies the period as March 2023 to 2029-06-30, representing a period exceeding six years. |
| C | End date for AL2023 support | A blog post update from 2024-01-02, announcing the end-of-life for AL1, states long term support through 2028. | The release cadence section specifies 2029-06-30. |
| D | Kernel Live Patching supported kernels | The prerequisites section of the Kernel Live Patching page lists the supported kernels as 6.1 or 6.12. | The first step on the same page states that live patching is only available for kernel 6.1. Furthermore, the default kernel has been updated to 6.18 as of 2026-08-17. |
| E | Default kernel for AL2023 | The comparison table in the AL2027 user guide lists kernel 6.1 as the default for AL2023, with kernels 6.12 and 6.18 as selectable options. | The AWS Compute Blog and the AL2023 user guide state that the default kernel was changed to 6.18 on 2026-08-17. |
| F | End of security updates for AL1 | The Amazon Linux 2 FAQ states that security updates for AL1 will continue until December 31, 2020. | The Amazon Linux AMI FAQ states that maintenance support continued until 2023-12-31. |
| G | End-of-support for AL2 | The Amazon Linux 2 FAQ and product page state that AL2 reached its end-of-support on 2026-06-30, and no longer receives standard security updates. | The Amazon Linux 2 release notes document history shows releases continuing after that date, up to version 2.0.20260909.0 dated 2026-09-09 as of the verification date. Those releases carry a note stating that AL2 reached end of life. |
| H | In-place upgrades across major versions | The AL2023 FAQ describes changes for major releases and states that in-place upgrades are possible on a package-by-package basis. | The Amazon Linux 2 FAQ states that in-place upgrades from AL1 to AL2 are not supported, and an official AWS blog states that there is no in-place upgrade path from AL2 to AL2023. |
Points B, C, and F are the same fact left in two places, one old and one new. In each case a date moved and only one of the two pages followed. Point A represents a discrepancy in wording, with differing names and conditions for when the change occurs. Points D and E are pages that have not yet caught up with the default kernel change of 2026-08-17. Point H may represent a difference in tense. The FAQ descriptions could be interpreted as announcements for future major releases, but as of the verification date, that generational change has not yet been implemented.
Point G should be read without adding interpretation. What can be verified here is that both the product page and the FAQ explicitly state the end-of-support date, while publication of the release notes continued afterward. This does not necessarily imply continued support. The basis for determining whether support is available lies in the statements made on the product page and the FAQ.
When encountering discrepancies of this kind, the practical guideline is as follows. Refer to the lifecycle dates found in the product page FAQ and the release cadence section of that product's user guide. Do not use dates found in comparison sections, other generation user guides, or the main content of older blog posts.
However, update notes that appear at the beginning of blog posts should be treated separately. For example, the AL2 end-of-support extension, placed in the timeline above at 2025-11-17, could only be verified by examining the update note at the beginning of a blog post announcing the general availability of AL2023. The update note is newer than the main content of the blog post. Because both the old and new information may appear on the same page, it is worth knowing which of the two you are reading.
Frequently Asked Questions about Amazon Linux History
When was each generation of Amazon Linux released?
There are four generations of Amazon Linux. Amazon Linux AMI (AL1) was announced on 2010-09-14. Amazon Linux 2 (AL2) was announced as a Long-Term Support (LTS) candidate on 2017-12-13, and general availability began on 2018-06-26. Amazon Linux 2023 (AL2023) was initially released as a public preview under the name Amazon Linux 2022 on 2021-11-22, and general availability began on 2023-03-15. Amazon Linux 2027 (AL2027) was announced as a public preview on 2026-09-03, and as of 2026-09-09, it had not yet reached general availability.Until when does Amazon Linux 2023 receive updates?
Amazon Linux 2023 will continue to receive updates until 2029-06-30. However, the type of updates provided may change over time. Support runs in two phases. Until 2027-06-30 the release is in standard support and receives quarterly minor version updates. From that date until 2029-06-30 it is in maintenance and receives only security updates and critical bug fixes. The release cadence section of the AL2023 user guide is the source of record for these two dates.Is there an extended support program for Amazon Linux 2?
No. AWS states the following:Unlike RHEL 7, AL2 doesn't have an Extended Lifecycle Support (ELS) program. No extensions,
exceptions, or additional support options are available after this date.Amazon Linux 2 reached end-of-support on 2026-06-30, and AWS recommends migrating to AL2023.
Why are Amazon Linux 2 release notes still being published after its end of support?
As of the verification date, no explanation for this was found in the primary sources. Two facts are verifiable. The Amazon Linux 2 FAQ and product page state that AL2 reached its end-of-support on 2026-06-30, and no longer receives standard security updates. At the same time, the Amazon Linux 2 release notes document history lists releases after that date, the most recent as of the verification date being version2.0.20260909.0 on 2026-09-09. Those releases carry a note stating that AL2 reached end of life. These two facts cannot be interpreted as a continuation of support. The basis for determining support status is the information provided on the product page and FAQ.How does an AMI deprecation date differ from the product support period?
AMI deprecation dates and the product support period for AL2023 are different. Each individual AL2023 AMI is assigned a 90-day deprecation date, calculated from its registration date. This 90-day period aligns with the duration for which Kernel Live Patching is provided for each individual kernel release. The product support period for AL2023 itself is defined by two dates, 2027-06-30 and 2029-06-30. The AL2023 user guide explicitly notes that the 90-day period refers to individual AMIs and does not represent the release cadence or the product's overall support period.How long does a kernel receive live patches?
Three months. The AL2023 user guide states that live patches for a specific kernel version are provided for a maximum of three months from its release. To continue receiving live patches, you have to move to a newer kernel version and reboot the instance. Kernel Live Patching is disabled by default in AL2023, and using it requires installing and enabling a DNF plugin. The support period for the kernel itself is separate; each LTS kernel receives four years of support, with the first two years providing full support and the subsequent two years providing maintenance support.Does a running AL2023 instance receive security updates automatically?
No. By default, it does not receive automatic security updates. AL2023 AMIs and container images ship with a specific version of the repository, and instances launch with the updates available at the time the AMI was created. However, you can configure it to automatically receive updates, or to receive only security updates. The direction is the opposite of AL1, which applied critical and important security updates on first boot by default.Can you upgrade in place from one generation to the next?
No. Amazon Linux 2's FAQ states that in-place upgrades from AL1 to AL2 are not supported, and AWS's official blog also indicates that there is no in-place upgrade path from AL2 to AL2023. Both moves between generations so far required a rebuild. However, it is possible to perform in-place upgrades within the same major version as you move to a different minor version. You can check the available repository versions usingdnf check-release-update and then select the desired version using dnf upgrade --releasever=version. The AL2023 FAQ mentions that package-level in-place upgrades may become available for major releases. However, as of the verification date, no major version upgrades have been implemented with this capability.Has a successor to Amazon Linux 2023 been announced?
Yes. Amazon Linux 2027 (AL2027) was announced as a public preview on 2026-09-03. This generation is built upon Amazon Linux 2023 and includes features such as the 7.1 kernel, SELinux with enforcing enabled by default, DNF5, and AWS-LC as a cryptographic library. As of 2026-09-09, it was not generally available. The user guide clearly states that the preview is intended for evaluation and validation purposes and is not recommended for production workloads. Support is scheduled to continue until 2032.What happens to running instances when the default kernel changes?
Changes to the default kernel do not affect currently running instances. On 2026-08-17, the SSM parameter namedkernel-default for AL2023 was updated from kernel 6.1 to kernel 6.18. The change reaches only instances that launch afterwards and resolve that parameter. Existing, running instances will continue to use the kernel they were launched with. To upgrade to a newer kernel, you must explicitly install a new kernel package and reboot the instance. If you are already using SSM parameters that specify a particular kernel version, this change will not affect you.Summary
This article presents a timeline of the four generations of Amazon Linux, outlining their support status as of 2026-09-09.The timeline is divided into three phases. From 2010 to 2017, a single AMI was continuously updated, the repository always reflected the latest version, and security updates were applied upon initial boot. From 2017 to 2023, the second generation, with systemd and five years of long-term support, ran alongside the first generation, whose end-of-life was postponed once and then followed by a maintenance support phase. From 2023 to the present, the default for updates flipped to locking, quarterly minor releases accumulated, the second generation reached its end-of-support, and the fourth generation entered preview.
Two key takeaways can be derived from this history.
First, there is no single expiration date. An individual AMI carries a 90-day deprecation date, a kernel receives live patches for three months, a kernel stays under long-term support for four years, and the distribution itself has two support phases. Four clocks of different lengths are running at the same time, and assuming any single one represents the product's expiration date can completely derail your planning. AWS expects this misreading and places a note in the user guide against it.
Second, none of these clocks moves a running instance. Even if the default kernel is updated, instances that have already been started will continue to use the kernel they were initially launched with. Even if the repository version advances, an instance launched from an older AMI does not follow it. Even when a generation reaches its end-of-support, those instances will continue to function. It is the user's responsibility to initiate updates.
These two points represent two sides of the same design principle. Deterministic upgrades offer exactly that as the guarantee: nothing moves on its own. In exchange for this guarantee, the responsibility for retrieving and applying updates remains with the user. The fates of AL1 and AL2 illustrate what happens when updates are not applied. They do not stop working. Updates simply stop being offered.
Regarding date interpretation, it is advisable to consult the product page FAQ and the release cadence section of that product's user guide. As of the verification date, comparison sections, other generations' user guides, and older blog posts all still carried statements that disagree with the current dates.
This timeline will be updated as Amazon Linux evolves.
Replacing a generation stays the user's work, and that is not the only arrangement available. Inside a Kubernetes cluster, the job of putting a newer copy in place before the old one expires has been moved onto the platform, where a controller performs it on a schedule: Certificate Distribution in Kubernetes with AWS Private CA. The same clock runs in both places. What differs is whose calendar it sits on.
In addition, there are related history-and-timeline articles on this site, so please have a look if you are interested.
AWS History and Timeline - Almost All AWS Services List, Announcements, General Availability(GA)
AWS History and Timeline regarding Amazon EC2 - Overview, Functions, Features, Summary of Updates, and Introduction
Amazon EC2 Instance Types History and Timeline - Instance Families, Generations, and Introduction
AWS History and Timeline regarding Amazon EKS - Overview, Functions, Features, Summary of Updates, and Introduction
AWS History and Timeline regarding AWS Lambda - Overview, Functions, Features, Summary of Updates, and Introduction
References:
Announcing the Amazon Linux AMI
Amazon Linux AMI FAQs
Update on Amazon Linux AMI end-of-life
Introducing Amazon Linux 2
Announcing Amazon Linux 2 with Long Term Support (LTS)
Amazon Linux 2 FAQs
Kernel Live Patching on AL2
Amazon Linux 2 release notes
Prepare your migration to AL2023
Announcing preview of Amazon Linux 2022
Announcing Amazon Linux 2023
Amazon Linux 2023, a Cloud-Optimized Linux Distribution with Long-Term Support
What is Amazon Linux 2023?
Amazon Linux 2023 User Guide - Release cadence
Amazon Linux 2023 User Guide - Naming and versioning
AL2023 on Amazon EC2
Deterministic upgrades through versioned repositories on AL2023
Comparing AL2 and AL2023
Functionality deprecated in AL2 and removed in AL2023
The Amazon Linux Kernel
Best practices for safely deploying updates (AL2023)
Kernel Live Patching on AL2023
IMDSv2
Document history for Amazon Linux 2023 Release Notes
Amazon Linux 2023 FAQs
Amazon Linux default SSM parameter will now track the latest kernel
Amazon Linux 2027 is now available in public preview
What is Amazon Linux 2027?
Amazon Linux 2027 User Guide - Release cadence
Comparing AL2023 and AL2027
Best practices for safely deploying updates (AL2027)
How do I get extended lifecycle support for RHEL 7 and AL2 after their end-of-support date?
Scale your AWS Storage Gateway AL2023 migration with infrastructure as code
References:
Tech Blog with curated related content
Written by Hidekazu Konishi