Introduction
In modern cloud architectures, delivering high availability and seamless user experiences is critical. Load balancers play a key role in distributing incoming traffic across multiple instances, ensuring that no single server is overwhelmed. However, certain applications require a more tailored approach to routing, where requests from the same client are consistently directed to the same backend resource. This concept is known as stickiness.
Stickiness, or session persistence, ensures that client traffic is routed to the same target, maintaining session data and improving user experience. Whether you’re dealing with session-specific data, caching, or stateful applications, using a stickiness strategy can be essential to ensure smooth operations.
In this guide, we will explore the different types of stickiness available in AWS, such as sticky sessions and target group stickiness, and explain how to choose the right approach for your application. We’ll provide insights on scenarios where stickiness is beneficial, and demonstrate how to implement these strategies using AWS CloudFormation templates.
By the end of this guide, you’ll have a comprehensive understanding of load balancer stickiness and the tools needed to optimize traffic routing in your AWS environment.
What is Load Balancer Stickiness?
At its core, load balancing is about distributing incoming traffic across multiple servers to ensure availability and responsiveness. However, in some cases, it’s important for traffic from a specific client to be directed to the same server or group of servers consistently, rather than being spread across multiple destinations. This is where load balancer stickiness—also known as session persistence—becomes critical.
Stickiness ensures that once a client establishes a connection with a particular backend server or target, subsequent requests from that same client are routed to the same server. Without stickiness, load balancers typically distribute requests based on algorithms like round-robin, which doesn’t account for session continuity. This can lead to issues where different parts of a user’s session are handled by different servers, resulting in lost session data or inconsistent application behavior.
For example, imagine a user browsing an e-commerce site. If their session is not bound to a single server, their cart might be updated on one server, but when they move to another page that request could be routed to a different server—one that doesn’t have their latest cart information. This inconsistency can negatively affect user experience, especially for applications that rely heavily on session data.
There are two primary types of stickiness in AWS Elastic Load Balancers:
1. Sticky Sessions: This type of stickiness binds a client session to a specific Amazon EC2 instance, ensuring that all requests during that session go to the same server.
2. Target Group Stickiness: Instead of tying a client to a specific server, target group stickiness ensures that all requests from a client go to the same target group, which is particularly useful in deployment scenarios like blue/green, where you want to direct all client requests to a consistent version of an application.
Stickiness can improve user experience by ensuring session consistency and helping maintain performance, but it’s essential to choose the right strategy based on your application’s architecture and needs.
Traffic Flows
Understanding the traffic flow within an AWS environment is essential when designing a scalable and efficient application architecture. A load balancer acts as the entry point, distributing incoming traffic to the backend resources like EC2 instances. Below, we walk through the flow of traffic from the internet to an Application Load Balancer (ALB) and how it determines the appropriate route to an EC2 instance.
Complete Traffic Flow
In this scenario, traffic flows through the Application Load Balancer, which is associated with two public subnets. The ALB manages traffic distribution using the Elastic Load Balancing service. The flow of traffic can be summarized as follows:
1. Client Traffic Enters Through the DNS Name
All traffic from the internet flows into the Application Load Balancer using its DNS name. The DNS directs client requests to the load balancer, which is responsible for distributing the requests to the appropriate resources in the backend.
2. Traffic Routed to Public Subnets
The ALB is deployed in two public subnets, one in each Availability Zone (AZ). For high availability, the Elastic Load Balancing service creates load balancer capacity in each enabled Availability Zone. Traffic is routed through the availability zone, and the load balancer uses its internal routing logic to determine which target group and instance should handle the request.
3. Routing to the Target Group
Based on predefined rules and health checks, the ALB directs the request to the appropriate target group. The target group could contain multiple EC2 instances or other AWS resources (such as Lambda functions or containers), and the load balancer selects an optimal target for the request.
4. Routing to EC2 Instances in Private Subnets
Once the ALB determines the target group, it forwards the request to an EC2 instance within that group. The EC2 instances are hosted in private subnets. These instances are isolated from direct internet access but can still handle inbound traffic through the ALB.
5. Outbound Traffic Routing
After the EC2 instance processes the request, the outbound traffic is routed back through the route table. The route table contains local routes that direct traffic between the private subnet (where the EC2 instance resides) and the public subnet (where the ALB node resides).
6. Response Sent Back to the Client
The ALB routes the traffic back through its public interface and forwards the response to the client. The route table ensures that the response follows the reverse path, returning to the client via the public subnet and internet gateway. The public subnet’s route table has a default route pointing to the internet gateway, which handles outbound traffic to the client.
Traffic Flow Diagram
Load Balancer Subnets and Routing
• Public Subnets: These are subnets associated with the ALB. Public subnets allow the ALB to communicate with the internet via an internet gateway. This is where the incoming client traffic initially lands.
• Private Subnets: The EC2 instances that handle the application logic reside in private subnets. These subnets do not have direct access to the internet, but they are reachable from the ALB, which forwards client requests securely.
• Route Table: The route table ensures traffic is directed appropriately between the public and private subnets, enabling smooth communication between the load balancer and the backend instances. The route table also handles outbound traffic, ensuring responses are routed back to clients via the internet gateway.
This traffic flow, combined with the internal logic of the ALB, ensures efficient routing of requests while maintaining security and high availability through multi-AZ deployment.
Which Stickiness Strategy is Right for You?
Choosing the right stickiness strategy for your application is crucial to optimizing performance and user experience. AWS offers different stickiness options, and the best choice depends on your application’s architecture, how session data is managed, and your deployment strategies. Below is a set of guiding questions to help you determine which strategy is most appropriate for your needs.
1. Are You Using WebSockets?
• Yes: WebSockets maintain a persistent connection between the client and server, inherently achieving stickiness. In this case, you don’t need any additional stickiness strategies, as WebSockets naturally handle session persistence.
• No: If your application doesn’t rely on WebSockets, move to the next question.
2. Are You Planning a Blue/Green Deployment?
• Yes: In a blue/green deployment, where different versions of your application are running concurrently, you need target group stickiness to ensure that client traffic remains directed to the same version (target group) throughout a session. This minimizes inconsistencies for the end user.
• No: If your application doesn’t require version consistency through target groups, proceed to the next question.
3. Do You Need All Client Traffic to Be Routed to the Same EC2 Instance?
• Yes: If your application needs to maintain a consistent state across requests for a client, you’ll need to enable sticky sessions. Sticky sessions ensure that client requests are directed to the same EC2 instance, which can be crucial for session state retention.
• No: If your application is stateless and doesn’t need consistent session data, sticky sessions may not be necessary.
4. Do You Want Your Application Code or Client to Control the Cookie Attributes and Duration?
• Yes: If you want to control the specifics of session handling—such as the attributes, duration, or expiration of the session cookies—you should use application-based cookies. This method gives developers control over session management at the application level.
• No: If you prefer AWS to manage the session cookies automatically, load balancer-generated cookies are the better choice. This strategy is simple to set up and maintains session persistence with minimal configuration.
Summary of Stickiness Strategies:
1. WebSockets: No additional stickiness is required as WebSockets inherently maintain a persistent connection.
2. Target Group Stickiness: Ideal for blue/green deployments, where the version of an application matters across multiple requests.
3. Sticky Sessions with Load Balancer-Generated Cookies: Useful when session persistence is necessary, but the application does not need to manage the cookies.
4. Sticky Sessions with Application-Based Cookies: The best choice when you need fine-grained control over session cookies, including their expiration and other attributes.
By answering these questions, you can identify the stickiness strategy that best fits your application’s requirements. Whether you’re handling version consistency with target groups or managing user sessions through sticky cookies, AWS provides flexible solutions to ensure reliable and optimized traffic routing.
Application Load Balancer Without Stickiness
When no stickiness strategy is applied to an Application Load Balancer (ALB), the default behavior is to distribute client requests using a round-robin routing method. This approach spreads incoming traffic evenly across all available targets in the target group, ensuring that no single instance is overburdened. In scenarios where session persistence is not required, this stateless load balancing mechanism is highly effective.
How It Works
In the absence of stickiness, the ALB treats each request as an independent event. The load balancer distributes traffic to different EC2 instances based on its internal round-robin algorithm. Since there is no session persistence, each request from a client might be routed to a different backend instance, even if they are part of the same session.
For example, if you refresh a webpage hosted behind an ALB without stickiness, one request might be sent to Instance 1, and the next refresh could be routed to Instance 2. Each instance is independent, and no session data is maintained between requests.
Common Use Cases
Using an Application Load Balancer without stickiness is ideal for the following scenarios:
1. Stateless Applications
Applications that do not rely on session data can efficiently utilize round-robin distribution. This is typical for services where requests are entirely independent of each other, such as RESTful APIs or microservices.
2. High Availability & Load Distribution
Without stickiness, traffic is distributed evenly across all healthy targets, making this strategy effective for applications that require high availability and resilience. It ensures that no single instance is overwhelmed with traffic.
3. Non-session-based Web Servers
Websites or applications that don’t require user sessions to persist across multiple requests can safely use this approach. For example, static content websites or web servers serving files (like images or scripts) do not benefit from session persistence, so round-robin distribution works perfectly.
CloudFormation Template
To implement an ALB without stickiness, you can use a basic CloudFormation template to deploy the infrastructure. The template sets up the ALB, target groups, and EC2 instances with the default round-robin routing mechanism.
Template:
Here’s how you can deploy the template in a lab environment:
1. Deploy the CloudFormation Template: Use the basic.yml CloudFormation template to deploy the Application Load Balancer, target group, and EC2 instances.
2. Check Target Group Health: Wait for the health status of the target group instances to update from initial to healthy.
3. Test Load Balancer URL: Once the deployment is complete, navigate to the Application Load Balancer URL in a browser (using HTTP, TCP/80).
• Example URL: http://alb-123456789.us-east-1.elb.amazonaws.com/
4. Observe Traffic Distribution: Refresh the webpage several times. The page should alternate between Instance 1 – TG1 and Instance 2 – TG1, demonstrating round-robin routing.
Expected Results
Each time you refresh the page, the load balancer will direct your request to a different instance, following its round-robin logic. If the page alternates between “Instance 1” and “Instance 2,” you’ll observe how the load balancer manages traffic without persisting client sessions.
This non-sticky approach ensures that the load is spread evenly across all available resources. It’s ideal for applications where maintaining session state is unnecessary, but distributing traffic across multiple instances is critical for performance and availability.
Target Group Stickiness
Target group stickiness is a specialized feature of the Application Load Balancer that allows traffic to be consistently routed to the same target group within a specified time period. Instead of focusing on sending requests to the same individual EC2 instance, this stickiness method ensures that traffic from a client stays within a specific target group. This feature is particularly useful in blue/green deployments and other multi-version environments where you need to ensure consistent access to specific target groups for a client session.
How Target Group Stickiness Works
With target group stickiness, the Application Load Balancer binds a client session to a particular target group based on the group’s configuration. Each request from the client will be routed to the same target group for a specified duration (e.g., 10 seconds). However, within that target group, the load balancer can still apply its internal logic, such as round-robin routing, to distribute requests across the targets (EC2 instances).
Here’s the process flow:
1. A client initiates a request.
2. The load balancer assigns the request to a target group and creates a sticky session for that client within that group.
3. The client’s requests will continue to be routed to the same target group until the stickiness duration expires.
4. Once the session duration ends, new requests may be routed to different target groups based on the load balancer’s rules.
This allows for controlled and predictable traffic routing, while still leveraging load balancing within the assigned target group.
Common Use Cases
Target group stickiness is ideal for scenarios where you need traffic consistency at the group level, rather than at the instance level:
1. Blue/Green Deployments
In blue/green deployments, where different versions of an application are running in separate target groups, you need to ensure that a user session remains within the same version. Target group stickiness helps achieve this by routing all client traffic to the appropriate version for the duration of the session.
2. A/B Testing
If you are running A/B tests, where different groups of users experience different versions of an application, target group stickiness ensures that a user’s session sticks to a specific group (A or B) for consistency in their experience.
3. Multi-version Applications
When you have multiple versions of an application running simultaneously, target group stickiness allows users to continue interacting with the same version, maintaining data and session integrity.
CloudFormation Template
AWS provides an easy way to implement target group stickiness using CloudFormation templates. You can create an Application Load Balancer that routes traffic based on group stickiness by modifying the default actions of the listener to include target groups with sticky sessions enabled.
Template:
To deploy target group stickiness, follow these steps:
1. Deploy the CloudFormation Template: Use the targetgroupstickiness.yml template to create an ALB with two target groups (TG1 and TG2) and enable stickiness between them.
2. Monitor Target Group Health: Wait for the target groups’ health statuses to change from initial to healthy.
3. Test Load Balancer Behavior: Navigate to the ALB’s DNS URL in your browser, using HTTP (TCP/80).
• Example URL: http://alb-123456789.us-east-1.elb.amazonaws.com/
4. Refresh the Page: You should see responses from Instance 1 – TG1, Instance 2 – TG1, Instance 3 – TG2, or Instance 4 – TG2, depending on the target group stickiness behavior.
Expected Results
When you refresh the page within the configured stickiness duration, your session should remain within the same target group (TG1 or TG2). The ALB maintains a binding between your session and the target group, ensuring that all subsequent requests are routed within that group. After the stickiness duration (e.g., 10 seconds) expires, new requests might be routed to a different target group depending on the load balancer’s routing logic.
For example:
• If the initial request is routed to Target Group 1, subsequent requests within the stickiness period will continue to be sent to targets in TG1 (e.g., Instance 1 or Instance 2).
• After the session expires, the next request might go to Target Group 2, depending on the ALB’s internal rules.
This approach allows for session consistency at the target group level, while still maintaining the flexibility of load balancing between instances within that group.
Sticky Sessions with Load Balancer-Generated Cookies
Sticky sessions, also known as session affinity, enable a load balancer to route all requests from a specific client to the same target (EC2 instance) for the duration of their session. One common method of enabling sticky sessions is through load balancer-generated cookies. This approach ensures that traffic from a client sticks to the same backend server, helping maintain session consistency across multiple requests.
How It Works
When the Application Load Balancer generates a cookie, it assigns a client to a specific target (an EC2 instance) within the target group. The load balancer generates a special cookie (called the AWSELB cookie) to track the client’s session and routes the requests to the same instance for the duration of that session.
The AWSELB cookie contains information that ties the client’s requests to a particular target. When the client makes subsequent requests, the load balancer reads the cookie and forwards the request to the same instance. The session duration can be configured according to the application’s needs, after which the cookie expires, and the load balancer returns to its default behavior (such as round-robin distribution).
Here’s the basic flow of sticky sessions with load balancer-generated cookies:
1. The client sends an initial request to the Application Load Balancer.
2. The ALB routes the request to a target (EC2 instance), and generates an AWSELB cookie that ties the client to that instance.
3. The AWSELB cookie is stored in the client’s browser and is sent with subsequent requests.
4. For each request with the AWSELB cookie, the load balancer directs traffic to the same target, ensuring session persistence.
5. After the session duration expires, the next request may be routed to a different instance based on the load balancer’s routing logic.
Common Use Cases
Sticky sessions with load balancer-generated cookies are useful for applications where maintaining client-specific session data is critical for user experience. Some common use cases include:
1. E-commerce Websites
In e-commerce platforms, user sessions often need to be persistent to maintain shopping carts, user preferences, and checkout details across multiple requests. By using sticky sessions, the user remains connected to the same backend instance, ensuring session data consistency.
2. Personalized User Experience
Websites or applications that offer personalized content based on user sessions (such as customized dashboards) rely on sticky sessions to ensure a smooth and seamless experience. Session data such as login states, preferences, and activity history can be stored and accessed efficiently by keeping a user connected to the same server.
3. Stateful Applications
Applications that store session state locally on the server can benefit from sticky sessions, as routing traffic to the same instance ensures access to that session state, avoiding issues with distributed or missing data.
CloudFormation Template
To implement sticky sessions with load balancer-generated cookies, AWS provides templates to deploy and test this functionality in a lab environment.
Template:
Follow these steps to deploy the setup:
1. Deploy the CloudFormation Template: Use the stickysessionslb.yml template to deploy an ALB, target group, and EC2 instances with sticky sessions enabled using load balancer-generated cookies.
2. Check Target Group Health: Wait until the target group’s health status changes to healthy.
3. Access the Load Balancer URL: After deployment, navigate to the ALB URL in a browser using HTTP (TCP/80).
• Example URL: http://alb-123456789.us-east-1.elb.amazonaws.com/
4. Test Session Stickiness: Refresh the page multiple times and observe that your requests are routed to the same instance consistently throughout the session.
Expected Results
Once the sticky sessions are enabled, you should notice that each request made by the client within the session is routed to the same target (EC2 instance). This persistence is maintained until the cookie expires, after which subsequent requests may be routed to a different instance.
For example:
• After the first request, the ALB might route the traffic to Instance 1.
• Subsequent requests will continue to go to Instance 1, as long as the cookie is valid.
• Once the session expires (after a configured timeout), the next request might be routed to Instance 2 or another available instance, based on the ALB’s routing rules.
Configuration Options
The stickiness duration, controlled by the session timeout, is configurable. You can set this timeout based on the expected user session length. A shorter duration (e.g., 5–10 minutes) might be appropriate for applications with rapid session turnover, while longer durations could be suitable for applications requiring extended user sessions.
Sticky Sessions with Application-Based Cookies
Sticky sessions can also be implemented using application-based cookies, which offer greater flexibility and control compared to load balancer-generated cookies. With application-based cookies, the application itself generates and manages the session cookies. This allows you to control key attributes such as the cookie’s content, duration, and expiration, giving your application more control over session management and persistence.
How It Works
In this approach, the Application Load Balancer (ALB) relies on cookies created and maintained by the application, rather than generating them on its own. Here’s the process flow for sticky sessions with application-based cookies:
1. Client sends a request: The client initiates a request to the Application Load Balancer.
2. Application sets a cookie: The application backend (running on EC2 instances) responds with an application-specific cookie, often tied to session information.
3. Load Balancer tracks the session: The ALB is configured to recognize this application-defined cookie and route subsequent requests from the client to the same target (EC2 instance).
4. Sticky sessions persist: As long as the cookie is valid, the ALB will route requests to the same instance, ensuring session persistence.
5. Cookie expiration: Once the application cookie expires, the load balancer will resume routing traffic based on its default logic, such as round-robin or least connections.
With application-based cookies, the backend application can implement complex session handling and state management rules, making this approach more versatile for applications that require custom session behavior.
Common Use Cases
Application-based cookies provide more granular control over session management and are ideal for applications that require precise control over session duration and state handling. Some common use cases include:
1. Custom Session Management
Applications that need to manage session attributes, such as user authentication tokens, shopping cart IDs, or session expiration times, can leverage application-based cookies to enforce these rules. The backend application determines when and how to terminate a session, offering greater flexibility in session management.
2. Advanced Security Requirements
Applications that handle sensitive data or require secure session management can use application-based cookies to enforce stricter security policies, such as encryption or signing of cookie values. This provides enhanced protection against session hijacking and other security threats.
3. Multi-tiered Applications
In complex, multi-tiered applications where multiple components are involved in processing a user session, application-based cookies can be used to track state across various services. For instance, when a session spans multiple services, the application can manage the state using a custom cookie to ensure consistent routing across different parts of the system.
CloudFormation Template
To implement sticky sessions with application-based cookies, AWS provides a CloudFormation template that sets up an Application Load Balancer with targets that leverage custom session cookies from the backend application.
Template:
Follow these steps to deploy and test the configuration:
1. Deploy the CloudFormation Template: Use the stickysessionslb.yml template to create an ALB and EC2 instances that handle application-based sticky sessions.
2. Monitor Target Health: Wait for the target group health status to change from initial to healthy.
3. Access the Application Load Balancer URL: Navigate to the ALB’s DNS URL in your web browser using HTTP (TCP/80).
• Example URL: http://alb-123456789.us-east-1.elb.amazonaws.com/
4. Test Sticky Sessions: As you browse the application, the application’s custom cookie will be set in your browser. Refresh the page multiple times, and you should observe that requests continue to be routed to the same instance.
Expected Results
With application-based cookies enabled, client requests will be routed to the same target instance throughout the session. The cookie, set by the application, dictates how long the session persists. For example:
• If the first request is routed to Instance 1, the custom session cookie will instruct the ALB to continue sending requests to Instance 1.
• As long as the cookie is valid, all requests from the client will be routed to the same target instance.
• Once the application-based cookie expires, or if it’s invalidated by the application, the next client request may be routed to a different instance based on the ALB’s routing logic.
Configuration Options
With application-based cookies, the flexibility lies in the cookie configuration. You can specify various attributes for the cookie, such as:
• Expiration: The application can set a specific expiration time for the cookie, defining how long the session should persist.
• Content: The cookie can carry encoded session data, allowing the application to maintain more complex session states.
• Security: The application can enforce secure attributes like encryption, signing, or setting the Secure and HttpOnly flags to mitigate security risks.
Comparing Application-Based Cookies and Load Balancer-Generated Cookies
Both types of sticky sessions have their advantages:
• Load balancer-generated cookies are simpler to implement and require no changes to your application. They are ideal for stateless applications where you need basic session persistence.
• Application-based cookies offer greater flexibility and are suitable for applications requiring more control over session management. These cookies allow the application to handle session expiration, attributes, and security policies.
Choosing the right type of sticky session depends on the specific needs of your application. If you require more control over session duration and attributes, application-based cookies are the better choice. On the other hand, load balancer-generated cookies are easier to configure and manage for simpler scenarios.
Conclusion
Choosing the right stickiness strategy for your load balancer is crucial to ensuring both optimal performance and a seamless user experience. Whether you’re maintaining session state for e-commerce transactions, handling personalized content delivery, or managing complex deployment environments, the correct implementation of sticky sessions can significantly impact the behavior and efficiency of your applications.
In this guide, we explored two primary methods for enabling stickiness: target group stickiness and sticky sessions with both load balancer-generated cookies and application-based cookies. Each of these methods offers distinct advantages depending on your use case, from managing session persistence during blue/green deployments to ensuring custom session management for stateful applications.
Key takeaways:
• Application Load Balancer without stickiness works well for stateless applications where consistent routing to the same backend instance is not required.
• Target group stickiness provides session persistence at the target group level, making it a strong choice for deployment strategies like blue/green.
• Sticky sessions with load balancer-generated cookies offer a simple solution for maintaining session state, allowing the load balancer to handle session persistence automatically.
• Sticky sessions with application-based cookies provide greater flexibility, allowing you to define and manage session behavior at the application level, which is useful for complex or highly secure applications.
Ultimately, the decision on which stickiness strategy to use depends on the specific requirements of your application, such as session duration, control over session state, and the need for custom behavior. With a clear understanding of the available options and their use cases, you can confidently select the stickiness strategy that best fits your architecture, ensuring better performance, reliability, and user satisfaction.