SSL Termination and Sticky Sessions

SSL/TLS termination means the load balancer decrypts incoming HTTPS traffic, inspects the plaintext HTTP request (for routing decisions), and then optionally re-encrypts the request before forwarding to the backend. When termination happens at the ALB, your application servers can receive unencrypted HTTP traffic from the load balancer, simplifying backend configuration.

Termination at the load balancer reduces CPU overhead on application servers (no TLS handshake per connection), enables content-based routing (which requires reading HTTP headers), and centralises certificate management.

AWS Certificate Manager (ACM) provisions, manages, and renews SSL/TLS certificates at no extra cost. ALB and NLB integrate directly with ACM: you select an ACM certificate in the HTTPS listener configuration and the load balancer presents it to connecting clients.

ACM certificates are automatically renewed before expiry—no manual renewal, no downtime due to expired certificates. For public certificates, ACM validates domain ownership via DNS validation (CNAME record in Route 53) or email validation. For internal use, ACM Private CA can issue private certificates.

SNI (Server Name Indication) is a TLS extension that allows a single IP address (and therefore a single ALB or NLB listener) to serve multiple TLS certificates for different domain names. The client includes the hostname it is trying to reach in the TLS ClientHello message, and the load balancer selects the appropriate certificate.

ALB supports SNI natively: you can attach multiple ACM certificates to a single HTTPS listener. The ALB automatically selects the right certificate based on the client's SNI hostname. This eliminates the need for a separate listener or load balancer per domain, enabling true virtual hosting with SSL.

ALB and NLB support configurable SSL security policies that control which TLS protocol versions and cipher suites the load balancer accepts from clients. AWS provides predefined policies (e.g., ELBSecurityPolicy-TLS13-1-2-2021-06) that are updated as new vulnerabilities are discovered.

Compliance requirements may dictate specific TLS versions: PCI-DSS 3.2.1 requires TLS 1.2 minimum; many modern standards recommend disabling TLS 1.0 and 1.1 entirely. Use a policy that excludes deprecated protocols and weak cipher suites. Prefer policies that include TLS 1.3 for forward secrecy and performance.

Two distinct TLS approaches on ALB:

• SSL termination (most common): ALB decrypts at the load balancer, forwards plain HTTP to targets. Simple, enables routing inspection, reduces server CPU. Backend traffic is unencrypted within the VPC.
• End-to-end TLS: ALB decrypts, then re-encrypts before forwarding to targets (HTTPS between ALB and target). More CPU-intensive, requires certificates on targets, but ensures encryption within VPC for strict compliance scenarios.

For NLB in TLS pass-through mode: NLB does not decrypt at all—it forwards raw TCP to the target which handles TLS. The application server manages its own certificate.

Sticky sessions (also called session affinity) ensure that all requests from the same client are consistently routed to the same target within a target group. This is necessary for stateful applications that store session data in-memory on individual servers (rather than in a shared cache like ElastiCache).

Without sticky sessions, a stateless load balancer might send request 1 to server A (which stores the session) and request 2 to server B (which has no session data), causing the user to appear logged out or lose cart contents. Sticky sessions bind a client to a specific target for the duration of the session.

ALB supports two types of sticky session cookies:

• Duration-based stickiness (LB-generated cookie): ALB generates a cookie named AWSALB (for ALB) and sets an expiry duration. The cookie contains an encrypted reference to the target. The client sends this cookie on subsequent requests.
• Application-based stickiness: uses an existing cookie set by your application. ALB reads the cookie name you specify, generates an encrypted version in its own cookie, and uses it for sticky routing while preserving the original application cookie.

Configure stickiness per target group, with a duration from 1 second to 7 days.

While sticky sessions solve the stateful application problem, they introduce trade-offs:

• Uneven load distribution: some targets may receive more traffic if certain clients are unusually active, defeating the purpose of load balancing
• Scaling limitations: if a sticky target becomes unhealthy, sessions are broken—the client must start a new session with a new target, losing any in-memory session data
• Reduced elasticity: sticky sessions make it harder to drain and terminate instances during scale-in events

Best practice: eliminate the need for sticky sessions by externalising session state to ElastiCache or DynamoDB. This makes your application truly stateless and enables full horizontal scaling.

NLB supports TLS listeners on port 443 (or any port) for TLS termination, similar to ALB. The NLB decrypts traffic, optionally re-encrypts, and forwards to targets. Alternatively, NLB can pass through encrypted TCP traffic without decrypting if you configure a TCP listener—in this mode, the application server handles TLS end-to-end.

NLB TLS termination with ACM provides the same certificate management benefits as ALB but without HTTP-layer features. Use NLB TLS termination when you need static IPs with TLS termination, or when your backend protocol is non-HTTP (e.g., a custom TCP protocol).

When a sticky target is deregistered (e.g., during an Auto Scaling scale-in), connection draining allows in-flight requests to complete. However, new requests from sticky clients that still hold the AWSALB cookie for the draining target are assigned to a new target automatically—the stickiness cookie is invalidated for that client.

This combination of deregistration delay and cookie invalidation ensures graceful transitions: existing long-lived requests finish, while new requests from those clients are smoothly rerouted to healthy targets without appearing as errors to the end user.

Exam-relevant best practices:

• Use ACM certificates for automatic renewal—never manually manage certificates on load balancers
• Use TLS 1.2+ security policies; disable TLS 1.0/1.1 for PCI/HIPAA compliance
• Prefer stateless architectures (session in ElastiCache/DynamoDB) over sticky sessions
• Use SNI on ALB to serve multiple domains from one listener without multiple certificates on separate load balancers
• For strict compliance (data in-VPC must be encrypted): use HTTPS target groups with end-to-end TLS, not just termination at the load balancer

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: ALB SSL/TLS termination with ACM certificates provides automatic renewal and SNI for multiple domains, SSL security policies control TLS version and cipher suites for compliance, and sticky sessions route users to the same target for stateful apps but are best replaced by externalising session state to ElastiCache. Next up we explore Auto Scaling Groups and launch templates.