Intro
Michael Larabel over at Phoronix spent his own money to put the new Amazon Linux 2027 preview head-to-head against Amazon Linux 2023 on a single m8a.4xlarge in EC2, the AMD EPYC 5th Gen “Turin” 9R45 with 16 vCPUs, and the results are the first real Amazon Linux 2027 benchmarks (opens in new tab) we have to work with. The setup is narrow on purpose. One instance shape, a limited benchmark set, no cloud credits handed to him, and the usual tight Phoronix operating budget that keeps him from spinning up forty boxen the way he would on a sponsored run. I think the framing matters before anyone quotes a percentage on Twitter. A single m8a is a useful data point, not a verdict.
I read these results the way I read any single-host comparison: as a hint about what to reproduce on my own fleet, not a recommendation to flip a switch. I run a handful of cPanel and bare Nginx boxes on AWS, and I have had to defend migration choices in front of paying customers more than once, so my default posture on any new distro release is suspicion until I see the numbers with my own workload on the screen.
Background: what changed between Amazon Linux 2023 and 2027
The headline numbers are easy to remember. The default kernel jumps from Linux 6.18 to Linux 7.1, the default compiler moves from GCC 11.5 to GCC 16.1, and Python is bumped from 3.9 to 3.14. That is a real generation of work, not a service pack. Underneath those versions sit the two changes that actually move the needle in the benchmark graphs.
The first is LTO. Amazon is now building packages with link-time optimizations, which lets the compiler see across translation units and inline, dead-code-eliminate, and reorder in ways the per-file model of AL2023 could not. The second is the enforcement of x86-64-v3, the ABI level that assumes AVX and AVX2. Any package or library that does not have the right baseline is excluded or rebuilt, which means the distros in 2027 are running tuned code paths on Turin rather than the lowest-common-denominator build that has to work on a 2012 Xeon’s vapor trails.
The lineage is Fedora 44 to 45 era sources plus Amazon’s own patches, and the OpenJDK situation is worth noting in passing. AL2023 has already backported most of the JDK 25 and 26 work, so the Java story is not as one-sided as the kernel and compiler numbers look. The wins you see in the Phoronix writeup are coming from the C and C++ stack, not from a JVM change.
Amazon Linux 2027 benchmarks on m8a.4xlarge
The rig is described plainly on the Phoronix page, and I am going to repeat it because it is the only thing keeping the numbers honest: 16 vCPUs on a Turin 9R45, 64 GB of DDR5-6400, 400 GB of local storage, both AMIs at their default configuration. No kernel tuning, no tuned-adm profile throughput-performance, no extra repos, no hand-rolled sysctl drop-ins. The point of the exercise was to test what AWS ships, not what a performance engineer can squeeze out of it.
The shape of the results is what you would expect from a toolchain bump and a baseline instruction-set change, but the gains are not uniform. Compute-heavy tests that are pinned to long CPU loops, which is the bulk of the Phoronix OpenBenchmarking suite, show a measurable jump on AL2027. Single-digit percentages are common, with the occasional test running well into the double digits when the workload happens to call into the kind of inner loop that LTO cleans up. Where 2027 looked flat or slightly behind, it was usually in a test that is dominated by startup cost or a memory pattern that does not benefit from AVX2, which is a useful reminder that LTO is not free magic, it just moves work around.
I will not quote a single number from the graphs because I want you to read them yourself, and because compressing a benchmark suite into one percentage is exactly the kind of thing that ages badly. The right takeaway is direction, not magnitude.
What it means in practice for AWS customers
The honest answer for most people running on m6a, m7a, and m8a is: it matters, but mostly to a narrow group. If you are running a compute-bound service that spins up a long-running worker process, anything from a video pipeline to a build server to a heavy PHP-FPM pool crunching through real requests, the toolchain delta will probably show up in your p99. If your workload is short-lived or I/O bound, you are mostly going to be paying the same bills in November as you are today.
There is also the compliance angle. A lot of the AL2023 installs I see in the wild are pinned because of a specific FIPS module, a SCAN recipe, or a quarterly review board that does not want to re-approve a new OS. For those shops the LTO and v3 wins are a non-event until the next review cycle, which is fine, the gains will still be there when they get to it.
What I would not generalize from a single m8a run: anything memory-bound, anything networking-bound, and anything that depends on the vCPU-to-memory ratio of a different instance family. A 4xlarge on m8a is a very different machine from a 4xlarge on r8a, and the right way to read the Phoronix numbers is “2027 looks like a free upgrade on this class of work,” not “2027 is faster everywhere.”
Should you switch to Amazon Linux 2027 in preview? (Q&A)
Is Amazon Linux 2027 faster than 2023 on EPYC? In the m8a tests Phoronix ran, yes, with the usual caveats about a single instance, a single instance type, and a benchmark suite that is not your suite. The wins are not imaginary, and they are not a rounding error.
Do I need a new instance type to get the gains? No, and this is the part I like. The improvements come from the OS build itself, not from a new CPU. The catch is that x86-64-v3 does exclude some very old hardware, but on a current EPYC or Xeon host you are already past that bar.
Can I run Amazon Linux 2027 in production today? It is a public preview. I would not, and I say that as someone who has eaten my own bad decisions on more than one “stable enough” upgrade. Wait for GA, or at minimum run your specific workload in a staging account against the preview AMI before you change one line of Terraform.
Will my existing AMIs and automation still work? Mostly, yes. It is still an RPM-based Amazon distro, your CloudFormation and Ansible will not panic. The kernel and glibc bumps are real, though, and any custom RPM you build in your own pipeline needs to be rebuilt against the new toolchain, or it will run against the compat libraries and lose some of what you are upgrading to get.
What to expect next
I expect Phoronix will get to more instance shapes once budget allows, and that is when we will learn whether the LTO and v3 wins hold on Graviton (where v3 does not apply in the same way, since the baseline is different), on smaller vCPU counts where single-thread latency matters more, and on r8a where memory bandwidth is the bottleneck. My guess, and it is only a guess, is that the percentage gains shrink on the memory-tuned sizes and stay roughly the same on the smaller compute shapes, because the toolchain delta is workload-dependent rather than topology-dependent.
On the Amazon side, I expect a normal preview-to-GA window of a few months, with AL2023 continuing to receive parallel security updates for a while, then a gradual de-emphasis the way AL2 trailed off once 2023 went stable. I would not be surprised to see Amazon ship a migration assistant similar to the AL2-to-AL2023 tool, because they have done this before and they know the upgrade cost is the real barrier.
What I am doing this week
I am spinning up a matching m8a.4xlarge in our own AWS account this week, deploying the AL2023 and AL2027 preview AMIs back to back, and rerunning the three tests I actually care about for hosting workloads: sysbench cpu --threads=16, openssl speed rsa2048, and a pgbench run against a small Postgres 16 instance. I will capture the exact AMI IDs, the cloud-init output, and the raw numbers in a follow-up post so the comparison is reproducible instead of a screenshot from someone else’s account. If you want to do the same before I publish, the AMI IDs are listed on the Phoronix review page, and the AMIs are free to launch. The cheapest way to find out whether 2027 helps you is to run your own benchmark on your own workload, on your own instance type, with your own data, and the AMIs are sitting in EC2 waiting.