This chapter covers Application Load Balancer (ALB) sticky sessions (session affinity) and connection draining (deregistration delay), two critical features for building resilient and stateful applications on AWS. For the SAA-C03 exam, these topics appear in roughly 5-10% of questions, often in scenarios involving stateful web applications, auto scaling, or rolling deployments. Understanding the exact mechanism, default values, and interaction with other services like Auto Scaling and EC2 is essential for architecting fault-tolerant systems.
Jump to a section
Imagine a hotel where guests (client sessions) arrive and are assigned a room (EC2 instance) by the receptionist (ALB). The receptionist maintains a logbook (sticky session table) recording each guest's name (session cookie) and their assigned room. When a guest returns later, the receptionist checks the logbook and sends them to the same room, ensuring continuity (e.g., their luggage is still there). This is sticky sessions. Now, when a room is about to be taken out of service for maintenance (instance deregistration), the receptionist stops assigning new guests to that room but continues to serve existing guests for a set period (connection draining timeout). During this time, the receptionist updates the logbook to mark that room as 'draining' and stops accepting new reservations for it. If a guest finishes their stay (session ends) before the timer expires, they are checked out normally. When the timer expires, any remaining guests are forcibly moved to a new room (though in reality, their session data may be lost). The receptionist then closes the room for good. This mirrors how ALB uses a cookie to bind sessions to an instance and a draining timer to gracefully stop traffic before instance removal.
What Are Sticky Sessions and Connection Draining?
Sticky sessions (also called session affinity) ensure that all requests from a client during a session are sent to the same target (EC2 instance) behind an ALB. This is necessary for stateful applications that store session data locally on the server (e.g., in-memory session state, local files). Without sticky sessions, a client's subsequent requests could be routed to different instances, breaking the session.
Connection draining (deregistration delay) is a feature that allows an ALB to stop sending new requests to a target that is being deregistered (e.g., during scale-in or rolling update) while completing in-flight requests. This prevents abrupt termination of active connections and ensures a graceful shutdown.
How Sticky Sessions Work Internally
When sticky sessions are enabled on an ALB, the load balancer generates a cookie named AWSALB (or AWSALBAPP for application-based stickiness) that is inserted into the response to the client. The cookie contains an encrypted identifier that maps to the target group and the specific target instance. The cookie has a configurable duration (default 1 day) and is set with the HttpOnly and Secure flags. On subsequent requests, the ALB reads the cookie, decrypts it, and routes the request to the same target. If the cookie is missing or expired, the ALB selects a new target based on the load balancing algorithm (default: round robin).
Key points:
The cookie is encrypted using an AWS-managed key, preventing clients from tampering with it.
The cookie duration is configurable from 1 second to 7 days.
Sticky sessions can be based on the load balancer-generated cookie (AWSALB) or an application-generated cookie (AWSALBAPP). For application-based stickiness, the application sets its own session cookie, and the ALB uses a hash of that cookie to determine the target.
Sticky sessions are configured at the target group level, not the load balancer level.
If a target becomes unhealthy, the ALB will route requests to other targets, breaking stickiness.
Connection Draining Internals
Connection draining is configured via the deregistration_delay setting on the target group. When a target is deregistered (e.g., due to Auto Scaling scale-in, manual detachment, or health check failure), the ALB performs the following steps:
1. The target's state changes to draining.
2. The ALB stops sending new requests to that target.
3. Existing in-flight requests are allowed to complete within the deregistration delay timeout (default 300 seconds, configurable from 0 to 3600 seconds).
4. If the timeout expires and there are still active connections, the ALB forcibly terminates them.
5. The target is then removed from the target group.
Important details:
Connection draining only applies to targets that are explicitly deregistered or become unhealthy. It does not apply to targets that are removed due to a target group deletion.
During draining, the target's health check status remains draining; the target does not receive new health check requests.
The ALB continues to send health checks to draining targets (though the target is considered unhealthy for routing purposes) to monitor if connections have completed.
If the target completes all in-flight requests before the timeout, it is removed immediately.
The default timeout of 300 seconds is suitable for most applications but should be adjusted based on the longest expected request duration.
Configuration and Verification
To enable sticky sessions via AWS CLI:
aws elbv2 modify-target-group-attributes --target-group-arn <tg-arn> --attributes Key=stickiness.enabled,Value=true Key=stickiness.lb_cookie.duration_seconds,Value=86400To set connection draining (deregistration delay):
aws elbv2 modify-target-group-attributes --target-group-arn <tg-arn> --attributes Key=deregistration_delay.timeout_seconds,Value=300To verify settings:
aws elbv2 describe-target-group-attributes --target-group-arn <tg-arn>Interaction with Auto Scaling and Other Services
When an Auto Scaling group triggers a scale-in event, it deregisters targets from the ALB target group. Connection draining ensures that in-flight requests are completed before the instance is terminated. If the deregistration delay is too short, requests may be dropped; if too long, instances may remain in draining state for extended periods, potentially causing resource waste.
Sticky sessions can cause uneven load distribution during scale-in or instance failures. If a client's target becomes unhealthy, the client's session is lost (unless session data is stored externally, e.g., in ElastiCache or DynamoDB). This is a common exam trap: the assumption that sticky sessions provide high availability. They do not; they only provide session affinity.
Edge Cases
Cross-zone load balancing: When enabled, sticky sessions still work across zones. A client may be routed to an instance in a different AZ if that instance is the one associated with the cookie.
Multiple target groups: Sticky sessions are per target group. If a listener rule forwards to multiple target groups, each target group can have its own stickiness configuration.
HTTP/2: Sticky sessions work with HTTP/2; the cookie is still used.
WebSocket: Sticky sessions are required for WebSocket connections to ensure that the connection persists on the same instance.
Common Exam Values
Default sticky session cookie duration: 1 day (86400 seconds)
Maximum sticky session duration: 7 days
Default deregistration delay: 300 seconds
Deregistration delay range: 0 to 3600 seconds
Sticky session cookie names: AWSALB (load balancer generated) or AWSALBAPP (application generated)
Sticky sessions are disabled by default.
Connection draining is enabled by default with a 300-second timeout.
Enable Sticky Sessions on Target Group
An administrator configures stickiness on the target group via the AWS Management Console, CLI, or SDK. The attribute `stickiness.enabled` is set to `true`, and optionally `stickiness.lb_cookie.duration_seconds` is set (default 86400). The ALB now begins inserting the `AWSALB` cookie in responses to clients. The cookie is encrypted and contains the target group ARN and a hashed identifier of the target instance. On the next request from the same client, the ALB will decrypt the cookie and route the request to the same instance, bypassing the normal load balancing algorithm.
Client Sends First Request Without Cookie
A client (e.g., browser) sends an HTTP request to the ALB. The ALB selects a target instance using the default round-robin algorithm (unless another algorithm is configured). The ALB forwards the request to the selected instance. The instance processes the request and returns a response. The ALB intercepts the response and adds a `Set-Cookie` header containing `AWSALB=<encrypted_value>; Path=/; HttpOnly; Secure`. The client stores this cookie.
Client Sends Subsequent Request With Cookie
The client sends a new request to the ALB, including the `AWSALB` cookie in the `Cookie` header. The ALB receives the request, extracts the cookie, decrypts it, and reads the target identifier. If the target is healthy and still registered, the ALB routes the request to that same target. If the target is unhealthy or deregistered, the ALB selects a new target (stickiness is broken) and updates the cookie accordingly.
Instance Deregistration Initiated
An instance is deregistered from the target group, e.g., due to Auto Scaling scale-in or manual action. The ALB immediately marks the instance as `draining`. The ALB stops routing new requests to that instance. Existing in-flight requests continue to be processed. The ALB starts a timer equal to the deregistration delay (default 300 seconds). During this period, the instance remains in `draining` state and is not considered healthy for new traffic.
Connection Draining Completes and Instance Removed
As in-flight requests complete, the number of active connections to the draining instance decreases. If all connections finish before the deregistration delay expires, the instance is removed immediately. If the timer expires and there are still active connections, the ALB forcibly closes those connections (sends TCP RST or HTTP 502). The instance is then removed from the target group. The ALB updates its routing tables accordingly.
Enterprise Scenario 1: E-Commerce Application with Cart State
A large e-commerce platform runs a stateful application where each user's shopping cart is stored in the application server's memory. Without sticky sessions, a user adding an item to the cart on one instance and then checking out on another would lose the cart. The solution is to enable sticky sessions on the ALB target group. The application also uses Auto Scaling to handle traffic spikes. During a scale-in event, connection draining ensures that users who have items in their carts (in-flight requests) are not abruptly disconnected. The deregistration delay is set to 600 seconds (10 minutes) to accommodate long-running checkout processes. The team also uses ElastiCache to store session data externally as a fallback, but sticky sessions reduce cache lookups.
Enterprise Scenario 2: Gaming Platform with WebSocket Connections
A real-time multiplayer game uses WebSocket connections to maintain persistent bidirectional communication between clients and game servers. Each WebSocket connection must remain on the same instance for the game session. Sticky sessions are mandatory for WebSocket traffic. The ALB is configured with stickiness enabled and a cookie duration of 24 hours. During a rolling deployment of game server code, instances are deregistered one by one. Connection draining with a 300-second timeout allows existing game sessions to complete before the instance is replaced. However, if a game session lasts longer than 300 seconds, the connection is forcibly terminated, causing player disconnection. To avoid this, the team sets the deregistration delay to 3600 seconds (max allowed) and coordinates deployments during low-activity periods.
Common Misconfiguration Pitfalls
Setting the deregistration delay too low (e.g., 1 second) causes dropped requests during deployments.
Not enabling sticky sessions for stateful applications leads to session errors and user frustration.
Assuming sticky sessions provide high availability — they do not. If the target instance fails, the session is lost unless external session storage is used.
Forgetting to adjust the deregistration delay for long-running requests (e.g., file uploads) results in incomplete operations.
What SAA-C03 Tests
The SAA-C03 exam tests sticky sessions and connection draining under Domain 2: Resilient Architectures (Objective 2.2: Design highly available and/or fault-tolerant architectures). You must understand:
When to enable sticky sessions (stateful apps, WebSocket)
Default values (cookie duration 1 day, deregistration delay 300 seconds)
How to configure via target group attributes
The interaction with Auto Scaling (draining during scale-in)
That sticky sessions do not guarantee high availability
Common Wrong Answers and Why
"Sticky sessions ensure high availability." This is false. If the target instance fails, the session is lost. High availability requires redundant instances and external session storage (ElastiCache, DynamoDB).
"Connection draining is disabled by default." False. It is enabled by default with a 300-second timeout.
"Sticky sessions are configured at the load balancer level." False. They are configured at the target group level.
"The deregistration delay can be set to 0 to immediately remove instances." True, but the exam may test that setting it to 0 disables draining, which can cause dropped connections.
Specific Numbers and Terms
Cookie name: AWSALB (load balancer generated) or AWSALBAPP (application generated)
Default cookie duration: 86400 seconds (1 day)
Default deregistration delay: 300 seconds
Deregistration delay range: 0–3600 seconds
Sticky sessions are disabled by default
Connection draining is enabled by default
Edge Cases and Exceptions
If a target becomes unhealthy, sticky sessions are broken; the client is routed to a healthy target.
Sticky sessions with HTTP/2: the cookie still works.
Cross-zone load balancing: sticky sessions still work; the cookie maps to a specific instance regardless of AZ.
Application-based stickiness: the application sets its own cookie, and the ALB uses it for routing. This allows the application to control session stickiness.
How to Eliminate Wrong Answers
If a question mentions "stateful application" or "session data stored locally," the answer likely involves sticky sessions.
If a question describes a deployment or scale-in event without data loss, connection draining is the key.
If an answer claims that sticky sessions provide fault tolerance, eliminate it.
Look for specific numbers: 300 seconds for deregistration delay, 86400 seconds for cookie duration.
Sticky sessions are configured at the target group level, not the load balancer level.
Default sticky session cookie duration is 86400 seconds (1 day).
Default deregistration delay (connection draining) is 300 seconds.
Deregistration delay can be set from 0 to 3600 seconds.
Sticky sessions do not provide high availability; they only provide session affinity.
Connection draining is enabled by default and applies when a target is deregistered or becomes unhealthy.
The cookie names are AWSALB (LB generated) and AWSALBAPP (app generated).
Sticky sessions are required for WebSocket connections.
These come up on the exam all the time. Here's how to tell them apart.
Sticky Sessions (Session Affinity)
Ensures client requests go to the same target.
Uses a cookie (AWSALB or AWSALBAPP).
Default disabled; cookie duration default 86400 seconds.
Does not handle graceful termination of in-flight requests.
Configured on target group via stickiness attributes.
Connection Draining (Deregistration Delay)
Gracefully stops traffic to a target being deregistered.
No cookie involved; uses a timer.
Default enabled; timeout default 300 seconds.
Does not affect routing of new requests to healthy targets.
Configured on target group via deregistration_delay attribute.
Mistake
Sticky sessions are enabled by default on ALB.
Correct
Sticky sessions are disabled by default. You must explicitly enable them on the target group.
Mistake
Connection draining is disabled by default.
Correct
Connection draining (deregistration delay) is enabled by default with a timeout of 300 seconds.
Mistake
Sticky sessions guarantee that a client's requests always go to the same instance.
Correct
Sticky sessions only work if the target instance remains healthy. If the instance becomes unhealthy or is deregistered, the client is routed to a different instance.
Mistake
The deregistration delay applies to all target removals, including target group deletion.
Correct
Connection draining only applies when a target is deregistered from the target group. If the target group itself is deleted, all targets are removed immediately without draining.
Mistake
Sticky sessions and connection draining are configured at the load balancer level.
Correct
Both are configured at the target group level. Different target groups behind the same ALB can have different settings.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The default deregistration delay (connection draining timeout) is 300 seconds (5 minutes). It is configurable from 0 to 3600 seconds. Setting it to 0 disables draining, which may cause in-flight requests to be terminated immediately.
Yes, sticky sessions work with HTTP/2. The ALB still uses the AWSALB cookie to maintain session affinity. The cookie is sent in the HTTP/2 response headers and included in subsequent requests.
No. Sticky sessions only route requests from the same client to the same target. If that target fails or becomes unhealthy, the session is lost. For high availability, you should store session data externally (e.g., ElastiCache, DynamoDB) and use multiple instances.
If connection draining is disabled (deregistration delay set to 0), the ALB immediately stops routing new requests and may forcibly close existing connections. In-flight requests may be terminated abruptly, causing data loss or errors.
Yes. Sticky sessions are configured per target group. Each target group can have its own stickiness setting (enabled/disabled) and cookie duration. This allows you to have stateful and stateless applications behind the same ALB.
AWSALB is a load balancer-generated cookie that the ALB creates and manages. AWSALBAPP is an application-generated cookie that the application sets; the ALB then uses a hash of that cookie to maintain stickiness. Application-based stickiness gives the application more control over session management.
Yes. When an Auto Scaling group scales in, it deregisters instances from the target group. The ALB then initiates connection draining for those instances, allowing in-flight requests to complete before the instances are terminated.
You've just covered ALB Sticky Sessions and Connection Draining — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?