Amazon Corretto 27 ships post-quantum TLS and compact object headers enabled by default
On September 17, 2026, AWS released Corretto 27, its free OpenJDK distribution, with hybrid post-quantum key exchange for TLS 1.3 and compact object headers turned on by default. Test these wins in non-critical environments, but keep your LTS workloads on Java 21 or 25 — this release is only supported through April 2027.
September 17, 2026. AWS ships Amazon Corretto 27, its free, multi-platform OpenJDK distribution. April 2027. The end-of-support date for this Feature Release. JEP 527. Hybrid post-quantum key exchange for TLS 1.3. Why it matters: for the first time, a production JDK turns post-quantum cryptography and memory compression on by default, with no tuning or configuration line required.
Corretto 27 is not an exotic product. It is the OpenJDK that millions of Java workloads run on EC2, Lambda, and AWS managed services, distributed under the open-source GPLv2+CE license for Linux, Windows, and macOS. Its particularity lies in the Java calendar: 27 is a Feature Release, not an LTS, which makes it a proving ground rather than a long-term migration target.
Post-quantum TLS walks through the service door
The headline is JEP 527. Corretto 27 adds to TLS 1.3 a hybrid key exchange that combines a classical algorithm with a post-quantum one — the ML-KEM family, standardized by NIST. The logic is defensive: even if a future attacker breaks elliptic-curve cryptography with a quantum computer, the post-quantum half of the exchange still protects the session secret.
It is not a magic fix. The hybrid exchange protects the session secret, not certificate signatures, which remain classical until the PKI infrastructure transitions. But it is the first piece teams can enable without doing anything — negotiation happens automatically when the server supports it — and it covers the most urgent risk: the capture and later decryption of traffic recorded today.
For a CISO, the stakes are clear: the post-quantum migration is a long race, and every component that turns the hybrid on by default shrinks the surface exposed to store-now, decrypt-later attacks. Corretto 27 lets you evaluate the real-world behavior of that negotiation on your workloads before the LTS releases make it mandatory.
Two performance wins that ask for nothing
The second notable change is JEP 534, compact object headers enabled by default. Every Java object carries a header of a few bytes; shrinking it reduces the memory footprint of the entire JVM, improves CPU cache utilization, and mechanically lowers garbage collector pressure on large heaps. It is a “free” win for anyone who does not depend on a precise memory layout.
JEP 523 completes the picture by making G1 the default garbage collector in all environments. Until now, small heaps sometimes fell back to other collectors depending on the machine. From now on, behavior is homogeneous, with more predictable pause times — a real comfort for anyone running the same application in a container, on an EC2 instance, and on a laptop.
JEP 536 deserves a separate mention because it touches compliance: JFR in-process data redaction masks sensitive data from a Java Flight Recorder recording before it leaves the JVM. For teams that profile in production without wanting to export secrets, it is one more guardrail.
The preview features
The rest of the release is a preview of what will become standard in the next LTS releases. JEP 532 extends pattern matching to primitive types (int, boolean) in instanceof and switch, JEP 533 refines the structured concurrency API that treats a group of tasks as a single unit, and JEP 531 introduces lazy constants to defer initialization of immutable data until first use. JEP 537 keeps the Vector API in incubator status for vectorized computation.
These preview and incubator features are not enabled by default and should not drive a production decision. They signal a direction — less boilerplate, safer concurrency — worth experimenting with in development environments.
What this changes for your AWS workloads
The first reflex is to ask whether “moving to 27” is urgent. The answer is no. Corretto 27 is a Feature Release supported only through April 2027, roughly seven months. Production workloads should stay on an LTS — Corretto 21 or Corretto 25 — whose support spans years.
The right use of Corretto 27 is preparation. It is the opportunity to test, on non-critical environments, the three new defaults — G1 everywhere, compact headers, hybrid post-quantum TLS — and to measure their effect on your metrics. If a compact header breaks a library that reads raw memory, you find out now rather than during the next LTS migration.
# Check the installed Corretto version and confirm post-quantum TLS availability (JEP 527)
java -version
# Java 27 should expose the X25519-MLKEM768 hybrid cipher suite (per JEP 527)
java -XshowSettings:properties -version 2>&1 | grep -i 'java.version'
# Test hybrid negotiation against a local server that supports it
keytool -list -v -keystore /tmp/test.jks -storepass changeit 2>/dev/null || echo "generate a test keystore first" The conclusion is comfortably simple: do not migrate critical workloads to a Feature Release, but use it to validate the new defaults and prepare the ground for the next LTS.
Verdict
Corretto 27 is a strategic trial release, not a production target. If you run Java workloads on AWS, stay on Corretto 21 or 25 for production, but deploy 27 in staging to measure the compact-header and generalized G1 gains, and to confirm that hybrid post-quantum TLS negotiates correctly with your load balancers and services. If you handle sensitive data in transit over TLS, the mere availability of this negotiation by default is an argument to push the post-quantum switch onto your roadmap — before the next LTS makes the question unavoidable.