What the AWS edge will and will not carry: NLB passthrough, ALB hybrid policies, and ACM's refusal
A Network Load Balancer carried fully post-quantum TLS to a fleet without looking at it; the Application Load Balancer turned out to offer hybrid key exchange already; and AWS Certificate Manager would not accept an ML-DSA certificate at all.
The objective was to establish which post-quantum properties survive the passage through a public cloud's load balancers, and to state precisely where each one stops. Three services were measured in fourteen minutes on 10 October 2026, against a fleet of three nginx nodes serving hybrid-KEM, ML-DSA-65 TLS under a hardware root. One prediction made before the measurement was wrong, and it is kept.
The Network Load Balancer carries everything, because it carries nothing. A TCP listener on port 443 with instance targets is passthrough: the balancer forwards bytes and never sees the handshake's contents. Probed through the balancer's DNS name with a hybrid-only offer, four connections in four distributed across the fleet by flow hash, and each reported the same thing:
Peer signature type: mldsa65
TLS_AES_256_GCM_SHA384
Verify return code: 0 (ok)Verified against the Fortanix root. The balancer preserves the client's address, which means the nodes' security group must admit the probing host directly — a detail that cost one failed connection and one rule. Passthrough is how post-quantum authentication reaches a fleet behind AWS today: the servers terminate for themselves, and the cloud is a wire.
The Application Load Balancer offers hybrid key exchange, which the author did not expect. The chapter's draft, written before the measurement, said the AWS edge had no post-quantum policy. describe-ssl-policies listed thirteen policies in a *-PQ-2025-09 family, FIPS variants included, applicable to application and network load balancers alike, with TLS 1.2 and 1.3 and the classical cipher list; the API does not expose named groups, but the family name and its date — September 2025 — say what they are. The prediction was wrong, the measurement is right, and the text now says so.
Certificate Manager refuses the algorithm. Importing an ML-DSA-65 leaf issued by the book's own issuing CA, with a throwaway key generated on the host for the purpose, returned a single line:
ValidationException: Encryption Algorithm ML-DSA_65 is not supported in us-east-1 regionSo a terminating balancer — the ALB, or an NLB with a TLS listener — cannot present a post-quantum certificate, because the only certificates it can hold come from a service that will not issue or import one. The cloud edge therefore lands in exactly the posture Chapter 19 found at the database: post-quantum key exchange, classical authentication. That is not a defect to work around; it is the honest statement of what an enterprise can deploy at an AWS edge this quarter, and the reason a fleet that needs post-quantum authentication terminates behind a passthrough balancer rather than at one.
One procedural note belongs in the record. The lab's API-only identity could not grant itself the permissions this measurement needed; the Certificate Manager and load-balancer policies were attached in the console, by hand, and the screenshot is a figure. An identity that cannot escalate itself is a feature, and the book treats it as one.
In the book: Chapter 21 carries the full transcript, the figures and the runbook. In the apparatus: the fix is in the repository, pinned to the versions that were measured. In your estate: if this is the problem you are looking at, this is what an engagement does about it.