AWS PQC (s2n-tls + AWS-LC)

Amazon Web Services has deployed post-quantum cryptography more broadly than any other single vendor on the planet, and it has done so without charging customers a premium or requiring configuration changes for most workloads. The foundation is two open-source libraries: s2n-tls, AWS's minimal TLS implementation written in C, and AWS-LC, a FIPS 140-3 validated cryptographic library forked from Google's BoringSSL. Both support ML-KEM-768 and ML-KEM-1024 (FIPS 203), with ML-DSA support shipping through 2026. The deployment footprint is staggering. AWS Key Management Service (KMS), Amazon S3, Amazon CloudFront, AWS Certificate Manager (ACM), Application Load Balancer (ALB), AWS Secrets Manager, and AWS PrivateLink all negotiate hybrid X25519 + ML-KEM-768 TLS by default when the connecting client supports it. This means any organization using these services already has PQC-protected key exchange on their most sensitive data paths — the KMS master keys, the S3 object encryption, the certificate issuance pipeline — without a single line of configuration change. The FIPS 140-3 validation of AWS-LC is a critical differentiator for regulated industries. Financial institutions, healthcare organizations, and government contractors operating under FISMA, HIPAA, or PCI-DSS can satisfy their validated cryptographic module requirements while simultaneously adopting PQC — most other solutions force a choice between the two. For enterprises building on AWS, the practical migration path is clear: audit which services are TLS-terminating client traffic using pre-quantum ciphers, update client-side libraries (including Java, Python, Node.js AWS SDKs) to versions that negotiate hybrid KEM, and use AWS Config rules to enforce PQC-capable TLS policies across the estate. The SDK updates have been available since late 2024. AWS also provides CloudWatch metrics for TLS handshake cipher suite distribution, making it straightforward to measure PQC adoption progress across your fleet.