Amazon Linux 2023 Default AMI Now Launches Kernel 6.18

For administrators, this is a deployment-behavior change rather than a normal AMI refresh. The SSM parameter has always pointed at a current Amazon Machine Image with updated packages, but it previously remained tied to the 6.1 kernel line. Now the same infrastructure definition can produce an instance with a different major kernel generation, even if the CloudFormation template, launch template, Auto Scaling group, CI pipeline, or command line has not otherwise changed.

AWS’s updated Amazon Linux documentation confirms that existing instances stay on the kernel they booted. The immediate exposure is therefore limited to newly launched or replaced instances that resolve the moving kernel-default parameter, including scale-out capacity, failed-node replacements, blue-green deployments, and disaster-recovery launches.

The parameter changed, not every running server​

The affected AL2023 public SSM parameter family is under /aws/service/ami-amazon-linux-latest/, with names such as al2023-ami-kernel-default-x86_64, al2023-ami-kernel-default-arm64, and their minimal-AMI equivalents. As of August 17, those default names resolve to AMIs built with kernel 6.18 rather than kernel 6.1.

That distinction is important because EC2 does not silently replace the kernel underneath a running instance. A host already booted with 6.1 remains on 6.1 until an administrator explicitly installs a different kernel and reboots, or replaces the instance with one launched from a newer AMI. AWS’s kernel guidance is clear that changing a running kernel requires installation and a reboot.

The operational consequence is that a fleet can become mixed without anyone scheduling a conventional operating-system upgrade. An Auto Scaling group that uses the default parameter may retain long-lived 6.1 nodes while placing its next replacement or capacity expansion on 6.18. Kubernetes worker pools, ECS container hosts, build runners, batch fleets, and immutable application tiers are particularly likely to encounter that split state.

AWS has published version-specific alternatives for 6.1, 6.12, and 6.18. The move to 6.18 does not retire the older two branches. AWS says each supported kernel continues to receive maintenance under its AL2023 kernel lifecycle, so pinning a version remains a supported choice rather than an emergency rollback mechanism.

AWS skipped the default from 6.1 directly to 6.18​

Kernel 6.12 was already available in AL2023 in 2025, and kernel 6.18 arrived as an explicit option in March 2026. AWS did not move the default parameter to 6.12 first. It retained 6.1 as the default until the August 2026 switchover, then advanced directly to 6.18.

For teams that treated kernel-default as shorthand for “AL2023 with the familiar 6.1 ABI,” the naming is now misleading. It means “the Amazon Linux team’s currently recommended LTS kernel,” and AWS says that choice will advance annually after a validation period of roughly three to six months following general availability.

That policy has a security rationale. AWS’s kernel lifecycle documentation says a new AL2023 LTS kernel is introduced annually, with two years of full support followed by two years of maintenance support. In maintenance support, Amazon Linux focuses on critical and important vulnerabilities, defined as CVSS 7.0 and higher, plus known exploited flaws. Lower-severity fixes no longer receive the same backport treatment once a kernel leaves full support.

The change therefore reduces the chance that newly built fleets stay on an older branch simply because their infrastructure code was never revisited. But it also means the parameter now encodes a vendor-managed compatibility decision. Organizations that need reproducible instance behavior must decide whether they want that decision made at every fresh launch.

Infrastructure code determines the blast radius​

The most exposed deployments are those that resolve AWS’s parameter at provisioning or launch time. The AWS CLI supports this directly with the resolve:ssm: prefix, and AWS documents the same public parameters for its EC2 workflows. If that resolution happens when an instance is launched, the next launch receives whatever AMI the parameter currently maps to in that Region.

A pinned AMI ID is different: it remains a fixed image until an operator changes the configuration. A version-specific SSM parameter, such as al2023-ami-kernel-6.1-x86_64, offers a middle position. It continues to follow fresh AMIs and package updates within the 6.1 kernel family while avoiding an unexpected jump to the next kernel line.

AWS CDK users need to inspect how their image lookup is handled rather than assuming the library’s “latest” selection behaves identically in every deployment. The CDK API documentation says AL2023 SSM image lookups can be cached in cdk.context.json; when cached, later deployments continue to use the previously resolved AMI ID until the cache entry is deliberately refreshed. With caching disabled, a newly resolved image can trigger replacement activity during a deployment.

In practical terms, two teams can use what appears to be the same CDK image abstraction and see different results:

• A team using an SSM parameter dynamically at EC2 launch can receive kernel 6.18 when new capacity is created.
• A team whose build or CDK context already resolved and retained a 6.1 AMI ID may remain on 6.1 until it refreshes that lookup and deploys.
• A team that hard-coded an AMI ID will see no change at all, including no benefit from newer AMI package updates.

This makes an inventory exercise more useful than a blanket response. Search infrastructure repositories for kernel-default, latest_amazon_linux2023, AmazonLinux2023ImageSsmParameter, resolve:ssm, and the Amazon Linux public-parameter path. Then determine whether each reference is evaluated during synthesis, stack deployment, template processing, or instance launch.

FIPS workloads should not follow the moving default​

The sharpest exception is FIPS. AWS’s current AL2023 kernel documentation says only the cryptography in kernel 6.1 has completed FIPS 140-3 validation; the cryptography used by kernels 6.12 and 6.18 remains in the validation process.

That means a FIPS-dependent workload using the moving default parameter could launch a 6.18 instance on August 17 even though its earlier 6.1-based deployment met the kernel-validation requirement. The issue is not merely application compatibility. It can affect a compliance control, evidence collection, and the approved operating baseline.

AWS’s own documentation warns that the default kernel may not be the FIPS-validated one. Administrators with FIPS obligations should pin their AL2023 source to the specific 6.1 parameter and validate the exact booted kernel with uname -r as part of instance attestation. They should also review boot arguments, cryptographic policy configuration, and the organization’s scope of validation rather than treating the AMI selection alone as proof of compliant operation.

Kernel-dependent software needs comparable scrutiny. Third-party drivers, kernel modules, eBPF-based observability agents, endpoint security products, GPU stacks, low-level storage tooling, and custom networking components are the obvious candidates. AWS says AL2023 supports the available kernel lines with the same userspace packages, but that does not eliminate compatibility testing for code or agents coupled to kernel interfaces.

Treat the next replacement as a kernel rollout​

AWS recommends the default parameter because it keeps newly launched systems on the latest validated kernel. That is a defensible default for ordinary cloud-native workloads, especially where instances are routinely rebuilt and validation is already part of a release pipeline. The policy aligns image selection with AWS’s annual kernel cadence instead of making each customer manually change parameter names.

But the company’s own lifecycle guidance also tells customers to test workloads before adopting a new kernel. Those two positions can coexist only if teams recognize that kernel-default has become part of their change-management process.

The sensible response is to launch representative 6.18 test instances using the explicit al2023-ami-kernel-6.18-* parameters, exercise boot-time agents and workload-specific I/O paths, and test a real replacement event rather than only an in-place package installation. Confirm that monitoring, vulnerability scanning, backup, container runtime, and hardware-specific dependencies recognize the new kernel.

Teams that pass that testing can continue using the default parameter, knowing that AWS plans another annual shift after advance notice and validation. Teams that need a controlled kernel baseline should replace kernel-default with a version-specific parameter now. On AL2023, the phrase “default kernel” no longer describes a stable 6.1 foundation; it describes the kernel AWS will choose for the next instance your automation creates.