Amazon Linux Release History: AL1, AL2, AL2023 and Support Dates

Amazon Linux has had three generations. The original Amazon Linux AMI (AL1), versions 2011.09 to 2018.03, reached end of life on 31 December 2023. Amazon Linux 2 (AL2) reached end of support on 30 June 2026. Amazon Linux 2023 (AL2023) is the supported release, with standard support until 30 June 2027 and maintenance until 30 June 2029.

The three generations differ in more than their dates. AL1 and AL2 pointed every instance at a rolling "latest" repository and installed critical and important security updates on first boot. AL2023 locks each instance to a dated repository version, so nothing changes until you choose a newer one. That one design decision changes how patching, golden images and container builds work, and it is the part most teams moving off AL2 get wrong. This post covers every generation with its dates, how each repository model works, how the Amazon Linux Security Center (ALAS) publishes advisories, what AL2023 changed in its security defaults, and a step by step routine for checking a host, patching it, pinning a version and planning the move from AL2.

Key takeaways

• AL1 is over. The Amazon Linux AMI FAQ says AL1 "reached its end of life on December 31, 2023" and receives no security updates or bug fixes from 1 January 2024. Its standard support ended on 31 December 2020, followed by three years of maintenance support.
• AL2 is over too. The Amazon Linux 2 FAQ states that AL2 "reached its end of support on 2026-06-30" and "is no longer receiving standard security updates". AWS tells customers to move to AL2023 now rather than wait for the next major version.
• AL2023 has two support phases. The release cadence page says AL2023 was released in March 2023, gets quarterly minor versions until standard support ends on 30 June 2027, then security updates and critical bug fixes only until 30 June 2029.
• AL2023 does not patch itself on launch. By default an AL2023 instance stays on the repository version its AMI was built with. The deterministic upgrades page is blunt: an instance "doesn't automatically receive additional critical and important security updates at launch".
• Pin to a version, not to "latest". The AL2023 updating guide says dnf --releasever=latest update "is not best practice". Use a specific version such as 2023.12.20261021.
• AL2023 is not a Fedora release. AWS says it "includes components from Fedora 34, 35, and 36", with other pieces closer to CentOS Stream 9 and a kernel from kernel.org LTS branches (6.1, 6.12 or 6.18 today).
• ALAS is the source of truth for fixes. Amazon Linux backports fixes, so compare the amzn2023 release string with the advisory, not the upstream version.
• A next major version is already visible. The Amazon Linux Security Center now lists an "Amazon Linux 2027 Preview" with its own advisory stream. Treat it as a preview until AWS publishes a release date and support policy.

For how the RPM world upstream of Amazon Linux fits together, see our post on the Fedora, CentOS Stream and RHEL pipeline. This post stays on the Amazon side of that story.

The three generations at a glance

Before the history, here is the comparison most readers come for. Every cell comes from AWS's own FAQs, user guides or release notes, linked in the sections that follow.

AWS's current AL1 and AL2 FAQ pages do not name a single upstream distribution, so this table does not either.

Timeline: releases and end of support dates

Every date below is taken from an AWS FAQ, release note, announcement or ALAS page cited in this post.

Amazon Linux AMI (AL1): the rolling image, 2011.09 to 2018.03

The Amazon Linux AMI FAQ describes AL1 as "a supported and maintained Linux image provided by Amazon Web Services for use on Amazon Elastic Compute Cloud". It was only ever available inside EC2. The FAQ is explicit on that point: "The Amazon Linux AMI is only available for use inside of Amazon EC2." Source code was reachable from inside EC2 with yumdownloader --source.

Versions

AL1 was versioned by year and month. The Amazon Linux AMI page still lists release notes for fourteen versions, two a year:

The same page says the "latest Amazon Linux AMI 2018.03 was released on 2018-11-19". That is an AMI rebuild of the final version, not a new version: 2018.03 was the last AL1 version, and later AMIs refreshed its packages.

Accounts of AL1 often date it to 2010. We could not find a current AWS page that dates it before 2011.09, the oldest release notes AWS still publishes, so that is where this history starts.

One architecture note from AWS's AL2 to AL2023 comparison: 2014.09 "would be the last release to produce 32-bit AMIs", and from 2015.03 Amazon Linux no longer supported running in 32 bit mode.

How AL1 repositories worked

AL1 was a rolling distribution with snapshots. The FAQ explains that "Amazon Linux AMIs are treated as snapshots in time", and that by default /etc/yum.conf set releasever=latest, so any AL1 instance, whatever version it was launched from, pulled packages from the newest repository.

That design had two consequences:

1. Patching was easy and implicit. On first boot AL1 installed "any user space security updates that are rated critical or important", before services such as SSH started. The message of the day told you whether more updates were waiting.
2. Reproducibility was hard. Two instances launched a week apart from the same AMI could end up with different packages. AWS offered a "lock on launch" option for people who did not want to roll into a new major version: pass repo_releasever: 2015.09 in cloud-init user data, or comment out releasever=latest in /etc/yum.conf on an existing instance.

The FAQ warns about the cost of that lock in plain terms: "If you lock your AMI to a version of the repositories that is not 'latest' you will not receive any further updates." In AL1, locking and patching were mutually exclusive. AL2023's versioned repositories are, in large part, a fix for that trade off.

How AL1 ended

AL1's end was staged over three years:

• Standard support ended on 31 December 2020. The AL2 FAQ confirms AWS kept providing "security updates for the last version of Amazon Linux and container image until December 31, 2020" to ease migration.
• Maintenance support ran from 31 December 2020 to 31 December 2023. In that window AWS added no new instance types, services, features or packages, and provided only "critical and important security fixes that apply to a reduced set of packages".
• End of life came on 31 December 2023. ALAS posted announcement 2024-008, "Amazon Linux AMI End Of Life Announcement", on 22 January 2024 (ALAS announcements).

The maintenance phase also retired whole language stacks. The AL1 FAQ lists packages that got no updates during maintenance at all, among them every compat- package, PHP 5.3 to 7.2, Python 3.4 and 3.5, Tomcat 7 and 8 and OpenJDK 1.7.0. A "supported" AL1 instance during 2021 to 2023 could still be running an unsupported runtime.

Amazon Linux 2: long term support and extras, 2017 to 2026

AWS introduced Amazon Linux 2 on 13 December 2017 as an "LTS Candidate", saying it "will offer extended availability of software updates for the core operating system through 5 years of long-term support" and that "the LTS build will follow". The candidate shipped with "LTS Kernel (4.9)". Unlike AL1, AL2 was also available as a Docker container image and as virtual machine images for VMware, VirtualBox and Hyper-V, so teams could develop on it outside EC2.

There were at least two candidate builds before the final one: the AL2 FAQ answers "Can I perform a rolling upgrade from Amazon Linux 2 LTS Candidate 2 to the LTS version of Amazon Linux 2?" with yes, with a recommendation to test on a fresh install first. We could not find a current AWS page that gives the exact date of the final LTS build, so we do not quote one here.

What AL2 was made of

The AL2 FAQ lists the pieces:

• "A Linux kernel tuned for performance on Amazon EC2."
• "A set of core packages including systemd, GCC 7.3, Glibc 2.26, Binutils 2.29.1 that receive Long Term Support (LTS) from AWS."
• "An extras channel for rapidly evolving technologies that are likely to be updated frequently and outside the Long Term Support (LTS) model."

Long term support covered core only. For core packages AWS committed to security updates and bug fixes, and to user space ABI compatibility for a listed set of packages. It did not commit to kernel ABI stability: "No, Amazon Linux 2 does not maintain kernel-space ABI compatibility", so third party kernel drivers could need rework after a kernel update.

The kernel moved over AL2's life, from 4.14 to 5.10 (the FAQ cites WireGuard and kernel lockdown among 5.10's gains), and the AL2 release notes record kernel 4.19 arriving in Extras on 18 July 2019.

Extras: freshness outside the support promise

Extras was AL2's answer to the tension between a five year stable base and developers who want current runtimes. The FAQ describes it as "a mechanism in Amazon Linux 2 to enable the consumption of new versions of application software on a stable operating system", with topics such as tomcat9, postgresql13, mariadb10.5, redis6 and rust1. You listed topics with amazon-linux-extras and installed with sudo amazon-linux-extras install rust1.

The catch is the sentence that follows in the FAQ: "The contents of extras topics are exempt from the Amazon Linux policy on long-term support and binary compatibility." When a new version of a topic shipped, "support will be provided only for the most current packages". ALAS made the split visible in its advisory IDs: core fixes are ALAS2-YYYY-NNNN, while topics get their own prefix, such as ALAS2DOCKER-, ALAS2KERNEL-5.10- or ALAS2PHP8.2-. ALAS posted announcement 2023-007, "Clarify AL2 Core and AL2 Extras Advisories", on 17 November 2023, and a run of extras end of support notices followed, for example unbound 1.14, dnsmasq 2.85 and rust1 in May 2025 and redis6 in September 2025.

For inventory, this means an AL2 host's support status depended on which extras topics it had enabled, not just on the OS version. Two AL2 hosts with identical /etc/os-release files could have very different exposure.

How AL2 patched

AL2 kept AL1's rolling model. The FAQ says updates come from "a pre-configured repository hosted in each AWS region", and that on initial launch AL2 "attempts to install any user space security updates that are rated critical or important". New AL2 AMI builds "point to the same repositories and include the cumulative set of security and feature updates". AL2 AMI builds are named by date, for example 2.0.20261021.0.

AL2 also introduced Kernel Live Patching. The release notes date the public preview to 29 May 2020. The AL2 FAQ says AWS "typically will provide kernel live patches to fix CVEs, which are rated as critical and important by AWS, for the default Amazon Linux 2 Kernel", that those ratings "generally map to the Common Vulnerability Scoring System (CVSS) score of 7 and higher", and that kernels from Extras or third parties do not get live patches.

AWS also kept patching Python 2 in AL2 core after its upstream end of life in January 2020, leaving the move to Python 3 for a major version boundary: AL2023.

AL2 end of support: 30 June 2026

The AL2 FAQ now opens with the answer: "Amazon Linux 2 reached its end of support on 2026-06-30." The follow up question, whether to wait for the version after AL2023, gets a direct no: AL2 "is no longer receiving standard security updates", and "Customers should migrate to Amazon Linux 2023 (AL2023) now rather than waiting for a future version."

There is one thing in AWS's own records that can confuse an inventory review. The AL2 release notes still list package update builds after 30 June 2026, the most recent being 2.0.20261021.0 on 21 October 2026, and the AL2 ALAS feed still carries new advisories, such as ALAS2-2026-4001 (bind, important) on 14 October 2026 and ALAS2PHP8.2-2026-015 on 22 October 2026. ALAS itself labels the product "Amazon Linux 2 (EOS)". We read the FAQ as the commitment and these entries as AWS publishing what it chooses to publish, not as an extension of support. If your compliance position depends on a supported OS, AL2 no longer qualifies, whatever the feed shows on a given day.

FIPS is a second AL2 deadline worth knowing. The AL2 FAQ says AL2's OpenSSL, NSS, Libgcrypt, GnuTLS and kernel crypto modules are FIPS 140-2 validated, and notes that FIPS 140-2 validated modules move to the historical list after 21 September 2026. AL2023's modules are validated under FIPS 140-3.

Amazon Linux 2023: versioned repositories and a fixed lifecycle

AWS announced general availability of AL2023 on 15 March 2023. The announcement promised that "a new Amazon Linux major release will be available every 2 years" with "up to 5 years of support", and listed security by default changes: preconfigured security policies, "SELinux in permissive mode and IMDSv2 enabled by default", and kernel live patching.

How AL2023 is built

AWS's relationship to Fedora page is the most precise statement of the upstream:

• AL2023 "maintains its own release and support lifecycles independent of Fedora".
• The GA version "isn't directly comparable to any specific Fedora release" and "includes components from Fedora 34, 35, and 36".
• Some components are the same as Fedora's, some are modified, and "Other components more closely resemble the components in CentOS Stream 9 or were developed independently."
• "The Amazon Linux kernel is sourced from the long-term support options that are on kernel.org, chosen independently from Fedora."

The AL2023 FAQ adds that major releases "will be based in part on the current version of the upstream Fedora Linux distribution, though Amazon may choose to add or replace specific packages from other non-Fedora upstreams". Package release strings carry the amzn2023 dist tag, for example glibc-2.34-52.amzn2023.0.2 in AWS's own example, which is how you tell an Amazon build from a Fedora one.

Kernels: 6.1, 6.12 and 6.18

AL2023 launched on kernel 6.1. The AL2023 FAQ says kernel 6.12 was released for AL2023 in March 2025 and kernel 6.18 in March 2026, and the current release notes ship separate default and minimal AMIs for all three. The choice matters for FIPS: kernel 6.1 "includes a FIPS 140-3 validated Kernel Cryptographic Module" (certificate 5369), while 6.12 (submitted 19 July 2025) and 6.18 (submitted April 2026) are still in validation. If you need validated cryptography today, the FAQ says to stay on 6.1, which "will be supported throughout the AL2023 lifecycle".

The lifecycle: standard support, then maintenance

The release cadence page currently reads:

• AL2023 "was released in March 2023 and will be supported until June 30, 2029".
• Standard support gives "quarterly minor version updates" and "ends June 30, 2027".
• Maintenance gives "only security updates and critical bug fixes", published "as soon as they're available", and "ends June 30, 2029".

Every release, "major version, minor version, or a security release", comes with a new AMI.

The documents do not agree perfectly, and it is worth saying so. The 2023 announcement promised a new major version every two years with up to five years of support. The comparison page and the latest release notes still say "five years of support". The naming and versioning page says AL2023 gets a minor release every three months "during the two years of standard support". But the current cadence page gives dates that run more than six years from March 2023, and the newest release is described as "an update to the 12th quarterly release of AL2023", which is three years of quarterly minors, not two. The dated cadence page is the one to plan against: 30 June 2027 and 30 June 2029. Re-check it before any decision, because AWS has clearly revised these dates since launch.

Long term support: core packages versus everything else

The cadence page and the FAQ draw the same line AL2 did, with different words. "Core packages such as the glibc library, OpenSSL, OpenSSH, and the DNF package manager receive support for the lifetime of the major AL2023 release." Packages outside core "are supported based on their specific upstream sources". AL2023 gives you a command to see which is which:

sudo dnf supportinfo --pkg glibc
sudo dnf supportinfo --show installed

The output lists a support status and support periods per package. AWS's own example shows glibc supported from 2023-03-15. This is the AL2023 replacement for "is this an extras topic?": run supportinfo across a host and you know which packages will outlive their upstream and which will not.

No extras: namespaced packages and SPAL

The AL2023 FAQ says plainly: "No, AL2023 does not have extras." Newer runtimes arrive in quarterly minor releases "as separate namespaced packages in addition to the default package", for example python39 alongside a default Python. The current release notes show this pattern for PHP and .NET: php8.2, php8.3, php8.4 and php8.5, and dotnet8.0, dotnet9.0 and dotnet10.0, all updated in the same 21 October 2026 release.

For software outside the distribution, AWS now offers Supplementary Packages for Amazon Linux (SPAL), "a dedicated repository containing thousands of pre-built EPEL9 packages compatible with AL2023". The FAQ is careful about what SPAL is not: SPAL packages "are not covered by AWS Enterprise Support", are provided "as-is", get patches "when available from upstream EPEL9 and provided by AWS on a best-effort basis", and "will not receive AWS CVE security tracking". That last clause matters for anyone who uses ALAS as their vulnerability source: a SPAL package will not appear there.

How versioned repositories and the releasever lock work

This is the part of AL2023 that changes day to day operations most, so it is worth walking through slowly.

The model

The deterministic upgrades page explains that "Whenever we release new package updates, there's a new version to lock to, and new AMIs that lock to that version." Each AL2023 AMI is built against one repository version, and "By default, the plugin for managing repository versions locks to the same version that was used to build the AMI." Old versions remain available: "When we publish a new version of the AL2023 repositories, all previous versions are still available."

So an instance launched today from an AMI built in August keeps installing August's packages. dnf install httpd on that instance gives you August's httpd, not October's, even if October's fixes a CVE. Nothing moves until you pass a newer --releasever, or you rebuild from a newer AMI.

Release version names

The naming page gives the format. A release version is 2023.<minor>.<date>, where minor counts quarterly releases from 0 and the date is the build date. AWS's own examples are 2023.0.20230301, 2023.1.20230601 and 2023.2.20230901, and the AMI names follow suit, for example al2023-ami-2023.0.20230301.0-kernel-6.1-x86_64. The current version at the time of writing is 2023.12.20261021, released on 21 October 2026.

Within a minor version, AWS releases new AMIs with new dates. Minor versions themselves, per the deterministic upgrades page, "include feature and security updates, but don't include package changes", so AWS says testing before moving between minors "isn't necessary". Major versions may add, delete or change packages and need testing.

Why this matters for reproducible builds and patching

The versioned model gives you something AL1 and AL2 could not: the same AMI or tag produces the same package set every time, and a fleet moves to new packages in one tested step.

1. Reproducible images. A Packer or Image Builder pipeline that runs dnf install against a pinned release produces identical results today and next month. That makes an SBOM generated in CI a faithful description of what runs in production.
2. Testable patching. You can stage 2023.12.20261021 in a test account, run your suite, then roll exactly that version to production. The updating guide's warning about --releasever=latest exists because "latest" can move between your test run and your production run.
3. Auditable state. A host's release version tells you its patch level. Two hosts on the same release version have the same available package set.

The cost is that patching is now an explicit act. If nobody moves the release version, nothing gets fixed. The AL2023 FAQ answers "Will my AL2023 instance automatically receive critical and important security updates?" with "Not in a default configuration." AL2 teams who relied on first boot patching and launch from an old AMI will be running old packages until someone notices.

If you do not need controlled updates, you can select the "latest" version, which the FAQ says "restores the legacy behavior" AL2 users expect. That suits disposable development hosts, not production.

A known gotcha with check-release-update

On 4 February 2026 ALAS published announcement 2026-015, "AL2023 dnf check-release-update plugin does not report the latest release version". The announcement title is the lesson: do not rely on one plugin's output as your only signal that a new release exists. Cross check against the AL2023 release notes, the ALAS feed or the SSM parameter for the latest AMI.

How Amazon Linux publishes security advisories

The Amazon Linux Security Center

ALAS is where AWS posts advisories for every Amazon Linux product. Its navigation today lists five sections: Amazon Linux 2027 Preview, Amazon Linux 2023, Amazon Linux 2 (EOS), Amazon Linux 1 (EOL) and Explore CVEs, plus announcements and FAQs. The AL2 FAQ describes what an advisory contains: "Advisory ID, severity of the issue, CVE ID, advisory overview, affected packages, and issue correction", with CVSS v3 scores for CVEs (v2 for some older than 2018).

Each product has an RSS feed. The ones you will most likely subscribe to are https://alas.aws.amazon.com/AL2023/alas.rss and https://alas.aws.amazon.com/AL2/alas.rss. Each item carries the advisory ID, severity and package in its title, and the CVE IDs in its description. For example, the AL2023 feed on 22 October 2026 led with ALAS2023-2026-3248 (critical): dotnet9.0, describing CVE-2026-70188 and CVE-2026-88092.

What an advisory looks like

That advisory, ALAS2023-2026-3248, shows the structure every AL2023 advisory follows:

• Issue overview: a short description of each CVE.
• Affected packages: dotnet9.0.
• Issue correction: the exact command, tied to a release version: dnf update dotnet9.0 --releasever 2023.12.20261021, or dnf update --advisory ALAS2023-2026-3248 --releasever 2023.12.20261021.
• New packages: every fixed RPM per architecture, with full release strings such as dotnet-runtime-9.0-9.0.21-1.amzn2023.0.1.aarch64.

The --releasever in the correction is the important part. On AL2023 a fix exists in a specific repository version and later ones. If your instance is locked to an earlier version, dnf update without --releasever will tell you there is nothing to do.

Advisory ID prefixes

The prefix tells you which product and which channel:

Severity ratings

The ALAS FAQ defines four ratings. In summary:

Two practical rules follow from AWS's own text. First, the AL2 FAQ says Critical and Important "generally map" to CVSS 7 and higher, which is a useful default for patch SLAs. Second, the ALAS FAQ explains why AWS's score can differ from NVD's: Amazon Linux "evaluates each CVE for their applicability and impact on our products", so scores "may differ from NVD and other vendors because of the characteristics of our software, such as versions, infrastructure platforms, default configurations, or build environments". Prioritise by the ALAS rating for the package you run, then adjust for your environment.

Backports and why scanners disagree

The AL2 FAQ addresses a question every security team asks sooner or later: "Amazon Linux, like most Linux distributions, routinely backports security fixes to stable package versions vended in its repositories." The advisory lists the specific package version in which the issue is fixed for Amazon Linux, and AWS warns that "Security scanners that rely on versioning from a project's authors sometimes won't pick up that a given CVE fix has been applied in an older version."

In concrete terms: if a tool sees OpenSSL 3.0.8 and compares it with the upstream fixed version, it may flag a CVE that AWS fixed in openssl-3.0.8-1.amzn2023.0.N. The fix is in the amzn2023.0.N part of the release string. Always resolve a finding against the ALAS advisory for your product before you open a ticket.

The Amazon Linux 2027 Preview

The ALAS navigation now includes "Amazon Linux 2027 Preview", with advisories numbered ALAS2027-2026-NNN. On 21 October 2026, for example, it listed ALAS2027-2026-243 (important, php8.5) and ALAS2027-2026-223 (critical, dotnet10.0). We could not load an AL2027 user guide page in a scripted fetch, so we do not quote a release date, a base or a support window for it. What the existence of a preview tells you is practical: the next major version is in public testing while AL2023 still has standard support. AWS's AL2 FAQ explicitly tells AL2 users not to wait for it.

What AL2023 changed in its security defaults

The comparison page and AL2023 user guide document the changes. These are the security relevant ones, each confirmed on an AWS page.

A few of these deserve more than a table cell.

SELinux permissive is a starting point, not a control. The SELinux page is clear that in permissive mode "permission denials are logged but not enforced". The AL2023 FAQ says you can switch to enforcing with setenforce or from cloud-init user data at launch, and that the setting persists across reboots. The value of permissive by default is that you can collect denials from your real workload, fix them, then enforce. Leaving it permissive forever gives you logs and no protection.

IMDSv2 only is set on the AMI, so it can be undone. The IMDSv2 page says AL2023 AMIs set imds-support to v2.0 with a hop limit of 2, and that you can "manually override these settings and enable IMDSv1". Check that your own AMI pipeline keeps it.

Live patching has a three month window. The live patching page says AWS provides patches "for an AL2023 kernel version for up to 3 months after its release", on a best effort basis, so "not all important or critical CVEs may be available as live patches". After three months you must update to a newer kernel and reboot to keep getting live patches. Live patching postpones a reboot; it does not remove the need for one. While a live patch is being applied you cannot hibernate or use tools such as SystemTap, kprobes and eBPF based tracers.

System wide crypto policies. AL2023 uses system wide cryptographic policies, set with update-crypto-policies, with the LEGACY, DEFAULT, FUTURE and FIPS levels named on AWS's post-quantum cryptography page. From AL2023.12, a PQ subpolicy turns on hybrid ML-KEM key exchange and ML-DSA signatures, backed by OpenSSL 3.5, GnuTLS 3.8.10 and NSS 3.112. AWS's example is sudo update-crypto-policies --set DEFAULT:PQ, checked with update-crypto-policies --show. The policy is opt in; nothing changes until you set it. Test it against every peer you talk to before you roll it out, because a stricter policy can break connections to older systems.

UEFI and Secure Boot. The comparison page lists "UEFI Preferred and Secure Boot" among the AL2023 changes. If you build your own AMIs, check which boot mode your images register with.

Walkthrough: identify, patch, pin and migrate

The commands below come from AWS's user guides. Run them in a test account first. None of them destroy data, but moving a release version or a kernel changes what runs, so treat each as a change.

Step 1: identify what you are running

AWS's naming page recommends the CPE string as the reliable way to identify AL2 and AL2023:

cat /etc/system-release-cpe
# AL2023 example: cpe:2.3:o:amazon:amazon_linux:2023
# AL2 example:    cpe:2.3:o:amazon:amazon_linux:2

cat /etc/system-release
cat /etc/os-release

# AL2023 only: these exist and are symlinks
ls -l /etc/amazon-linux-release /etc/amazon-linux-release-cpe

# The exact release version (AL2023) or build (AL2)
rpm -q system-release
uname -r

On AL2023, rpm -q system-release returns something like system-release-2023.12.20261021-0.amzn2023.noarch, which is the release version the host is on. Note that AL2023 does not ship lsb_release; scripts that call it need to read /etc/os-release instead.

For an image, run cat /etc/system-release-cpe in a throwaway container from it. At fleet scale, Systems Manager inventory or Patch Manager can collect the same data. The goal is a list of hosts and images by generation and, for AL2023, by release version.

Step 2: list pending security updates

On AL2023, first find out whether newer repository versions exist, then check what they would change:

# Which newer release versions are available?
sudo dnf check-release-update

# What would change if you moved to a specific version?
sudo dnf check-update --releasever=2023.12.20261021

# Only the security advisories in that version
sudo dnf updateinfo list --security --releasever=2023.12.20261021

The AL2023 update guide explains why the --releasever flag matters: without it "only the currently configured repository version is checked", so updates that exist only in later versions are invisible. dnf updateinfo is standard DNF; it reads the same advisory metadata that ALAS publishes.

On AL2 (now past end of support), the equivalent is:

sudo yum updateinfo list security
sudo yum update --security

Step 3: patch AL2023 to a tested release version

AWS's recommended path is to move the whole host to a new release version rather than cherry pick packages. The update guide explains the reasoning: "By applying all updates, existing instances are moved to the same package set as launching an updated AMI."

# Move every installed package to the tested release
sudo dnf upgrade --releasever=2023.12.20261021

# Confirm the new release version
rpm -q system-release

dnf upgrade --releasever shows the package list and asks for confirmation. After it completes, "the new release version becomes the default release version that dnf uses for all future activities". If you must apply a single advisory urgently, use the command printed in the ALAS advisory, for example:

sudo dnf update --advisory ALAS2023-2026-3248 --releasever 2023.12.20261021

Then decide whether you need a reboot. AWS lists three cases in the update guide: kernel updates need a reboot (live patching can postpone it), CPU microcode updates on EC2 metal instances apply only after a reboot, and some systemd services only work correctly after a full restart. AL2023's smart-restart package restarts affected services after updates and leaves a hint file at /run/smart-restart/reboot-hint-marker when it advises a reboot:

sudo dnf install -y smart-restart
# after an update
test -f /run/smart-restart/reboot-hint-marker && echo "reboot advised"

Step 4: pin new instances to the same release

To make every new instance match what you tested, either launch from the AMI that corresponds to the release version, or apply the version at launch. AWS's update guide shows a user data script for the second option:

#!/bin/bash
dnf upgrade -y --releasever=2023.12.20261021
# further setup here

For new instances that should always start from the newest AMI, AWS publishes SSM parameters. The update guide's example launches from one:

aws ec2 run-instances \
  --image-id resolve:ssm:/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64 \
  --instance-type m5.xlarge \
  --user-data file://cloud-config.yml

The SSM parameter always resolves to the newest AMI: right for a golden image pipeline that tests and publishes its own AMI, wrong for a production autoscaling group that should only run what you tested.

For containers, pin the full tag. AWS's base container guide says :2023 always gets the latest AL2023 image, and specific versions use :2023.<quarter>.<date>.<build>. Prefer a digest in production:

# Tag pins the release; the digest pins the exact image bytes
FROM public.ecr.aws/amazonlinux/amazonlinux:2023.12.20261021.0@sha256:<digest-you-tested>
RUN dnf install -y --releasever=2023.12.20261021 httpd && dnf clean all

Check the exact tag exists in the Amazon ECR Public Gallery before you use it; AWS publishes the image with a build number suffix on the release date.

Step 5: plan the AL2 to AL2023 migration

We did not find an in place upgrade procedure from AL2 to AL2023 in AWS's AL2023 user guide, and the differences in the comparison table above (package manager, networking service, Python, cgroups, logging, cron) make a rebuild the realistic route. AWS's guidance on instance replacement points the same way even within AL2023: launching new capacity gives "clear A and B states", while in place patching has "a lot of intermediary states" that are harder to test, and replacement fits "blue/green, wave, and phase based deployment models". A practical order:

AWS notes that 32 bit binaries can run in an AL2 container on an AL2023 host. That is a stopgap: the container still has AL2's support status.

Container images, minimal images and SBOMs

AWS publishes Amazon Linux container images on Amazon ECR Public. The base container guide says the AL2023 image "is built from the same software components that are included in the AL2023 AMI". The minimal container guide describes the second variant, introduced in AL2023.2, which "contains only the bare minimum packages needed to install other packages" and replaces the Python based DNF with microdnf. AWS adds that the minimal image "forms the base of the provided.al2023 AWS Lambda runtime environment".

AWS's size table, as shown on the ECR Public Gallery:

What this means for SBOMs and image scanning

The tag is a moving target; the digest is not. AWS says the 2023-minimal tag always points to the latest AL2023 minimal image, "while the minimal tag may be updated to a newer version of Amazon Linux than AL2023". An image built FROM amazonlinux:minimal today could rebuild on a different major version later, perhaps the 2027 release now in preview, with a different package set. Use 2023-minimal at least, and a pinned version or digest for production.

Fewer packages is a smaller SBOM, not a free pass. The minimal image drops packages, so its SBOM is shorter and there are fewer components to match against advisories. The packages that remain, such as glibc, OpenSSL, curl-minimal and ca-certificates, are the ones that matter most, and they still need patching. Whatever you install on top lands in the SBOM too.

Your SBOM tool must understand the amzn2023 release string. The backport point from the ALAS section applies doubly to images. An SBOM that records only openssl 3.0.8 loses the information needed to know whether the fix is present. Generate SBOMs that keep the full RPM version and release, and match them against ALAS data for the right product, not against upstream versions.

Image release version and host release version are separate. A container's package set is fixed by the image and whatever dnf ran in your Dockerfile. Bumping the release version on the EC2 host does nothing for the containers running on it. Rebuild images when ALAS publishes a fix for a package they contain.

SPAL packages need their own tracking. They will not appear in ALAS, so match them against other sources or accept the gap knowingly.

Common mistakes

1. Assuming AL2023 patches itself at launch. It does not. An autoscaling group on a six month old AMI launches six month old packages every time it scales out.
2. Pinning to latest in production. AWS's updating guide calls it out directly. "latest" means whatever AWS published most recently, which is not what you tested.
3. Running dnf check-update without --releasever. It only checks the version you are already on, so it tells you there are no updates even when a newer release fixes a critical CVE.
4. Reading AL2 advisories after June 2026 as continued support. The AL2 feed still shows new entries, but the FAQ says AL2 is past end of support.
5. Treating extras or SPAL like core. Neither had AWS's long term support promise; inventory them separately.
6. Closing scanner findings by upstream version. Check the amzn release against the advisory instead.
7. Using the minimal tag instead of 2023-minimal. AWS says minimal may move to a newer Amazon Linux than AL2023.
8. Leaving SELinux permissive forever. Permissive logs denials and enforces nothing.
9. Relying on live patching instead of reboots. Live patches cover a kernel version for up to three months, best effort.
10. Moving to kernel 6.12 or 6.18 in a FIPS environment. Only 6.1 has a validated kernel crypto module today.

FAQ

When did Amazon Linux 2 support end?

Amazon Linux 2 reached end of support on 30 June 2026, according to AWS's Amazon Linux 2 FAQ. AWS says it no longer receives standard security updates and recommends migrating to AL2023 now rather than waiting for the next major version.

When does Amazon Linux 2023 support end?

AWS's release cadence page says AL2023 standard support, with quarterly minor releases, ends on 30 June 2027, and the maintenance phase, with security updates and critical bug fixes only, ends on 30 June 2029.

What is the difference between Amazon Linux 1, 2 and 2023?

AL1 was a rolling, EC2 only image. AL2 added long term support for core packages, extras and images for use outside EC2. AL2023 uses DNF and versioned repositories locked per AMI, and turns on SELinux permissive and IMDSv2 only by default.

Is Amazon Linux 2023 based on Fedora?

Partly. AWS says the GA version "includes components from Fedora 34, 35, and 36", that others resemble CentOS Stream 9 or were developed independently, and that the kernel comes from kernel.org LTS releases. Its lifecycle is independent of Fedora's.

Does Amazon Linux 2023 install security updates automatically?

Not by default. AL2023 locks to the repository version its AMI was built with and installs nothing new at launch. You choose when to move with dnf upgrade --releasever=<version>, or you set the instance to the "latest" version, which AWS says restores the AL2 style behaviour.

How do I find which Amazon Linux version an instance is running?

Read /etc/system-release-cpe, which AWS recommends for identifying AL2 and AL2023. On AL2023, rpm -q system-release shows the exact release version, such as 2023.12.20261021, and /etc/amazon-linux-release exists only on AL2023.

What do ALAS severity ratings mean?

ALAS uses Critical, Important, Medium and Low. AWS says Critical and Important generally map to CVSS 7 and above, and its scores can differ from NVD because it rates each CVE against Amazon Linux's own builds and defaults.

Why does my scanner report a CVE that ALAS says is fixed?

Amazon Linux backports fixes into older upstream versions. A tool that compares upstream version numbers misses the fix recorded in the amzn2023.0.N release string. Check the advisory's fixed package list against the full installed release.

Can I upgrade Amazon Linux 2 to Amazon Linux 2023 in place?

We found no in place upgrade procedure in AWS's AL2023 user guide. The package manager, network service, Python version and several system defaults all change, so the realistic route is to rebuild images and launch templates on AL2023 and replace instances.

What is Amazon Linux 2027?

The Amazon Linux Security Center lists an "Amazon Linux 2027 Preview" with its own advisory stream, ALAS2027-. AWS had not published a general availability date or support window that we could confirm as of 24 October 2026.

Where Safeguard fits

Safeguard does not manage EC2 instances, patch operating systems or run Amazon Linux's repositories. Moving a fleet to a new release version, choosing a kernel or enforcing SELinux is your platform team's work with AWS's tools. Where Safeguard helps is the software you build on top of Amazon Linux: it scans repositories, container images and SBOM files (safeguard scan --dir ., safeguard scan --image <name>, safeguard scan --sbom <file>), matches components against vulnerability databases, applies reachability analysis, shows which projects contain a given component and version, and evaluates policies and gates. When an image built on amazonlinux:2 needs rebasing, that is how you find every project still carrying it. For OS packages, still confirm fixes against ALAS for the backport reasons explained above.

Amazon Linux fixes its own packages through ALAS, and only AWS can ship those. Most services on Amazon Linux also carry an application layer of npm, PyPI, Maven or Go dependencies plus container base images, and that open source layer is where the steps below apply.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. On a build host that produces images from amazonlinux:2023 or 2023-minimal, that is the route for scanning the repositories and images you build there, for example to list what an old amazonlinux:2 based image contains before you rebase it.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session: asked to fix a lodash CVE, the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same flow applies to a Node.js service running on AL2023, where the vulnerable dependency sits in your repository rather than in an Amazon Linux RPM, so the fix is a change you make and test yourself.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. Once your projects are in Safeguard, that connection lets you ask which of them contain a given component and version, which is the question you need answered when AL2 reaches end of support and you want every image still built on it.

Click through it at your own pace, or open it full screen.

To try the CLI, download Safeguard and follow the CLI documentation.

Quick check

Sources

• AL2023 release cadence
• Comparing AL2 and AL2023
• Amazon Linux 2 FAQs
• Amazon Linux 2023 FAQs
• Amazon Linux AMI FAQs
• Amazon Linux AMI page and release notes list
• Introducing Amazon Linux 2 (13 December 2017)
• Announcing Amazon Linux 2023 (15 March 2023)
• Amazon Linux 2 release notes
• What is Amazon Linux 2023?
• AL2023 relationship to Fedora
• AL2023 naming and versioning
• Deterministic upgrades through versioned repositories on AL2023
• Updating AL2023
• Manage package and operating system updates in AL2023
• AL2023 security updates and features
• Setting SELinux modes for AL2023
• AL2023 IMDSv2
• Kernel Live Patching on AL2023
• Using the AL2023 base container image
• AL2023 minimal container image
• Comparing packages installed on AL2023 container images
• Deprecated functionality in AL2023
• Enable post-quantum cryptography on AL2023
• Deterministic updates via instance replacement
• AL2023 release notes
• AL2023 version 2023.12.20261021 release notes
• Amazon Linux Security Center
• ALAS general FAQs
• ALAS announcements
• ALAS AL2023 RSS feed
• ALAS AL2 RSS feed
• ALAS AL2 (EOS) advisories
• ALAS Amazon Linux 2027 Preview advisories
• ALAS2023-2026-3248

Last reviewed: 24 October 2026. Amazon Linux support dates and release versions change; check the AL2023 release cadence page, the AL2 FAQ and ALAS before planning an upgrade.