Availability and Scalability - Sticky Sessions/Cross-Zone LB Flashcards
What are sticky sessions?
Also known as session affinity, sticky sessions ensure that a client’s requests are consistently routed to the same backend server (e.g., EC2 instance) within a load balancer.
How do sticky sessions work?
A cookie is associated with the client. This cookie is sent with each request, allowing the load balancer to identify the client and route them to the specific server they were previously assigned to.
What are the benefits of sticky sessions?
Maintain user sessions: Prevents loss of session data (e.g., login information).
Improve application performance: Can optimize for applications that rely on in-memory caching on the server.
What are the drawbacks of sticky sessions?
Load imbalance: Can lead to uneven distribution of traffic across servers if some servers become “stickier” than others.
Reduced fault tolerance: If a sticky server fails, all clients associated with that server will be impacted.
What are the two main types of cookies used for sticky sessions?
Application-based cookies: Generated by the application itself. Customizable with application-specific attributes.
Duration-based cookies: Generated by the load balancer. Have an expiration time set by the load balancer.
Where do you configure sticky sessions for an AWS load balancer?
In the target group settings.
What is Cross-Zone Load Balancing?
Cross-Zone Load Balancing distributes incoming traffic evenly across all registered instances in all availability zones (AZs), regardless of which AZ the request was initially sent to.
How does Cross-Zone Load Balancing differ from Non-Cross-Zone Load Balancing?
Without Cross-Zone Load Balancing, traffic is distributed only within the AZ where the load balancer instance is located, leading to potential imbalances if EC2 instances are unevenly distributed across AZs.
When Cross-Zone Load Balancing is enabled, does AWS charge for data transfer between AZs?
No, with Application Load Balancers (ALBs), there are no charges for inter-AZ data transfer even when Cross-Zone Load Balancing is enabled.
How does Cross-Zone Load Balancing affect costs for Network Load Balancers (NLBs) or Gateway Load Balancers (GLBs)?
With NLBs and GLBs, enabling Cross-Zone Load Balancing incurs data transfer charges when traffic moves between AZs.
Is Cross-Zone Load Balancing enabled by default for each type of load balancer in AWS?
Application Load Balancer (ALB): Enabled by default.
Network Load Balancer (NLB): Disabled by default.
Gateway Load Balancer (GLB): Disabled by default.
Classic Load Balancer (CLB): Disabled by default.
Can you enable or disable Cross-Zone Load Balancing for an ALB’s target group?
Yes, for ALBs, you can either inherit settings from the load balancer or manually enable/disable Cross-Zone Load Balancing at the target group level.
How can you verify/change Cross-Zone Load Balancing settings in AWS?
To verify or change the Cross-Zone Load Balancing settings, navigate to the attributes section of the specific load balancer (ALB, NLB, or GLB) in the AWS Management Console.
When would you choose to disable Cross-Zone Load Balancing?
You might disable Cross-Zone Load Balancing if you have a use case where traffic should be distributed within a specific AZ, or to minimize inter-AZ data charges (e.g., with NLB or GLB).
