Amazon Aurora brings post-quantum key exchange to PostgreSQL 18
AWS now lets you pick hybrid ML-KEM key-exchange groups on Aurora PostgreSQL 18 through the ssl_groups parameter, with no reboot. Turn it on for databases holding long-lived data to neutralize harvest-now-decrypt-later collection.
October 29, 2026. AWS announces post-quantum key exchange for Amazon Aurora PostgreSQL-Compatible Edition. Aurora PostgreSQL 18 and higher only. One parameter to change: ssl_groups. The cloud just lowered the cost of a defense that, a year ago, still looked like a migration project reserved for labs.
Why key exchange, and not encryption
The risk AWS is addressing here is not data encryption but the negotiation of the key that protects it. In TLS, the payload is encrypted with a symmetric algorithm such as AES or ChaCha20, which a quantum computer does not directly break. What it does break, through Shor’s algorithm, is the key exchange: ECDHE, X25519 and RSA all rest on mathematical problems that a sufficiently large quantum computer solves in polynomial time. The symmetric ciphers that carry the data are a different story: a quantum computer only halves their effective strength through Grover’s algorithm, which is why the key exchange — not the bulk encryption — is the urgent target.
An attacker capturing encrypted traffic today therefore does not need to decrypt it now. They store it and will decrypt it once a fault-tolerant quantum computer exists. The strategy has a name: “harvest now, decrypt later.” For a database, the stakes are maximal: personal, medical and financial data has a legal and commercial lifetime measured in decades, well beyond any reasonable quantum-decryption horizon.
The industry’s answer is ML-KEM, short for Module-Lattice-Based Key-Encapsulation Mechanism. It is the algorithm standardized by NIST in August 2024 as FIPS 203. It does not “replace” classical key exchange: it encapsulates a key in a Euclidean lattice problem believed to resist quantum attack.
What the ssl_groups parameter actually does
In practice, Aurora PostgreSQL 18 exposes a cluster parameter named ssl_groups, inherited from PostgreSQL 18 itself. It is a dynamic parameter: changing it requires no instance reboot.
The default value remains classical: prime256v1:X25519. The new part is an allowlist of five permitted values, including two hybrid groups:
- X25519MLKEM768 — a hybrid of X25519 + ML-KEM-768;
- SecP256r1MLKEM768 — a hybrid of P-256 (ECDHE) + ML-KEM-768;
- X25519, prime256v1, secp384r1 — the classical groups kept as fallback.
The order of the list sets the server preference. The first group the client also supports is the one used for the connection. To enable post-quantum exchange, you flip the parameter value:
aws rds modify-db-cluster-parameter-group \
--db-cluster-parameter-group-name my-aurora-pg18 \
--parameters "ParameterName=ssl_groups,ParameterValue=X25519MLKEM768:X25519,ApplyMethod=immediate"The key point: the hybrid X25519MLKEM768 keeps the X25519 component. If the ML-KEM part were broken tomorrow, the classical part would still guarantee confidentiality. That is exactly what makes the deployment defensible in production today, while ML-KEM is still young.
The hidden constraint: ML-KEM requires TLS 1.3
Enabling ssl_groups is not enough. The AWS documentation sets two conditions that many teams will discover after the fact.
First, the ML-KEM groups only work over TLS 1.3. A connection that falls back to TLS 1.2 simply ignores ssl_groups where RSA key exchange is involved. To be sure the post-quantum layer applies, you need to combine three parameters:
aws rds modify-db-cluster-parameter-group \
--db-cluster-parameter-group-name my-aurora-pg18 \
--parameters "ParameterName=ssl_min_protocol_version,ParameterValue=TLSv1.3,ApplyMethod=immediate"
aws rds modify-db-cluster-parameter-group \
--db-cluster-parameter-group-name my-aurora-pg18 \
--parameters "ParameterName=rds.force_ssl,ParameterValue=1,ApplyMethod=immediate"rds.force_ssl forces encryption on every connection, and ssl_min_protocol_version set to TLSv1.3 removes the silent fallback to TLS 1.2. Without that second line, an older application could negotiate a classical exchange while you believe you are protected — a false sense of security that is precisely what post-quantum must avoid.
The trade-off is a real operational constraint: any client that does not speak TLS 1.3 will be refused. Across a heterogeneous pool of connectors, that is a compatibility test to plan before the switch, not a checkbox to flip on a Friday evening.
The real work is still on the client side
The server half is simple — it is the other half that takes work. The X25519MLKEM768 group only negotiates if the client supports it too. That depends on the software stack:
- libpq and the official PostgreSQL drivers rely on OpenSSL; ML-KEM and hybrid-group support is only present in recent library versions;
- JDBC, .NET and ORM drivers ship their own TLS stack, with uneven post-quantum support;
- connection pools such as PgBouncer or access proxies terminate their own TLS: a pool still on TLS 1.2 would cancel the gain on the server side.
The practical consequence is that a full rollout starts with a client inventory before enabling the strict switch. AWS offers a soft transition here: you can first put X25519MLKEM768 at the head of ssl_groups while leaving X25519 as fallback. Post-quantum clients negotiate the hybrid, older ones fall back to X25519. You measure adoption, then harden with ssl_min_protocol_version.
Handshakes get heavier, not slower where it counts
ML-KEM does not come free at the wire level. A hybrid X25519MLKEM768 key share is far larger than a plain X25519 share — the ML-KEM-768 ciphertext alone is 1 088 bytes, against 32 bytes for an X25519 public key. The cost shows up as a marginally larger ClientHello and ServerHello and a few extra milliseconds on session establishment, not on the symmetric encryption that follows. For a pooled application that reuses sessions, the amortized cost is negligible; for a fleet opening thousands of short-lived connections per second, benchmark before you flip the switch.
That is why the hybrid-by-default posture matters: you keep X25519 in the list, so the negotiation only pays the ML-KEM cost when both sides support it. A sound first step is to enable the hybrid group, then watch connection latency and error rates for a week before forcing TLS 1.3.
What this says about post-quantum maturity
The AWS announcement is part of a broader shift that teams sometimes struggle to date. NIST published FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) in August 2024. Browsers and major providers already ship hybrid groups, and Aurora joins a movement where post-quantum stops being a watchlist item and becomes a configuration parameter.
What changes here is the barrier to entry. Until now, securing a database against deferred collection meant maintaining your own cryptographic library, compiling current versions and handling incompatibilities yourself. With Aurora PostgreSQL 18, the server half fits in one no-reboot parameter. That is the signal that post-quantum is entering the managed-service era.
Do not over-read it, though. ML-KEM-768 corresponds to NIST security level 3, comparable to AES-192. It is not “unbreakable”: it is believed resistant to known quantum attacks, and implementations are still maturing, as shown by the adjustments NIST made between successive versions of its standards.
Verdict
If you run Aurora PostgreSQL 18 or higher with personal, health or financial data whose lifetime exceeds ten years, enable ssl_groups with X25519MLKEM768 at the head now: the cost is near zero, no reboot is required, and the hybrid group keeps X25519 as fallback. Then harden progressively: force TLS 1.3 via ssl_min_protocol_version once the client inventory is validated, and set rds.force_ssl. If your database holds only ephemeral or already-exposed data, the switch is not urgent — but fold it into your next major upgrade, because migration cost only rises as the client fleet ages. And if you run versions older than 18, note the deadline: the “harvest now” window is already open, and every month of waiting makes deferred decryption more likely.