TLS 1.3 Handshake Internals on AWS: ALB, CloudFront, and ACM
Quick summary: A full TLS handshake on every API call adds RTTs your p99 cannot afford. This guide walks through TLS 1.3 1-RTT handshakes and resumption, ACM cert rotation, and security policies on ALB and CloudFront.
Key Takeaways
- A full TLS handshake on every API call adds RTTs your p99 cannot afford
- This guide walks through TLS 1.3 1-RTT handshakes and resumption, ACM cert rotation, and security policies on ALB and CloudFront
- TLS 1.3 (June 2026) is the default forward path on CloudFront and modern ALB security policies ( )
- Handshake cost moved from 2-RTT (TLS 1.2) to 1-RTT for new sessions; 0-RTT exists in the protocol but is risky for non-idempotent APIs, and ALB does not implement it
- Handshake flow (architect view) 1
Table of Contents
TLS 1.3 (June 2026) is the default forward path on CloudFront and modern ALB security policies (ELBSecurityPolicy-TLS13-1-2-...). Handshake cost moved from 2-RTT (TLS 1.2) to 1-RTT for new sessions; 0-RTT exists in the protocol but is risky for non-idempotent APIs, and ALB does not implement it.
Symptoms, mechanisms, and AWS controls
| Production symptom | Mechanism | AWS control |
|---|---|---|
| High TLS handshake latency | TLS 1.2 requires more round trips | ALB/CloudFront TLS 1.3 security policy |
| Certificate renewal outages | Manual cert rotation | ACM auto-renewal with DNS validation |
| 0-RTT replay risk | Early data accepted before full handshake | Keep 0-RTT off mutation endpoints; ALB does not accept early data |
My recommendation: set ALB and CloudFront to TLS 1.3 policies and, wherever an edge does accept early data, restrict 0-RTT to idempotent reads. Never use it on POST/PUT without anti-replay guards.
Benchmark pattern (hypothetical workload): ALB with TLS 1.3 policy ELBSecurityPolicy-TLS13-1-2-2021-06, full handshake 1-RTT (vs 2-RTT on TLS 1.2), PSK session resumption saves 45ms p50 on repeat clients; CloudFront TLS 1.3 + HTTP/3 cuts handshake to ~1 RTT on QUIC.
Handshake flow (architect view)
- ClientHello with key shares
- ServerHello + encrypted extensions + cert chain (ACM)
- Application data
Session tickets and resumption cut repeat handshake work, so ensure clients enable reuse. Broken middleboxes that disable tickets show up as p99 spikes after deploy.
AWS services mapping
| Layer | Cert source | Knob |
|---|---|---|
| CloudFront | ACM us-east-1 | Security policy, HTTP/3 + TLS 1.3 |
| ALB | ACM regional | ssl_policy, mTLS optional |
| API Gateway | ACM / import | Minimum TLS 1.2 |
ACM rotation is automatic for DNS-validated certs, so watch CloudWatch DaysToExpiry only for imported certs.
When this advice breaks
- Legacy IoT clients on TLS 1.0 must use an isolated endpoint with an older policy (compliance debt).
- Mutual TLS at scale: consider Verified Access or private CA with device provisioning.
What to do this week
- Audit ALB/CloudFront policies and remove TLS 1.0/1.1 unless there is a documented exception.
- Measure
ssl_handshake_timevia CloudFront access logs or ALB target timing. - Enable OCSP stapling (default on CloudFront) and verify chain completeness.
More in This Track
Part of the Engineering Guides library (June 2026).
- Previous: Part 1
- Next: Part 3
- Browse tracks: Engineering Guides hub
What this guide doesn’t cover
mTLS service mesh: see the Kubernetes track service mesh guide.
Frequently asked questions
Should I enable TLS 1.3 0-RTT on POST APIs?
Do DNS-validated ACM certificates need DaysToExpiry alarms?
When must I keep TLS 1.0 or 1.1?
Will session tickets always cut p99 after a deploy?
AWS Cloud Architect & AI Expert
AWS-certified cloud architect and AI expert with deep expertise in cloud migrations, cost optimization, and generative AI on AWS.
