Elastic Load Balancing (ALB, NLB & CLB)
7 questions found
What is Elastic Load Balancing and why is it important for building scalable, highly available applications?
Beginner
Elastic Load Balancing automatically distributes incoming application traffic across multiple targets, such as EC2 instances or containers, in one or more Availability Zones, improving both the fault tolerance of your application, since traffic automatically avoids unhealthy targets, and its ability to scale, since you can add or remove capacity behind the load balancer without any interruption to end users.
aws elbv2 create-load-balancer --name my-load-balancer --subnets subnet-12345 subnet-67890
Real-world example
An online retailer places a load balancer in front of its fleet of EC2 instances, ensuring that if one instance becomes unhealthy during a traffic surge, the load balancer automatically stops sending it traffic while continuing to serve customers through the remaining healthy instances.
Common follow-ups: What is the difference between the three types of load balancers AWS offers?;How does a load balancer determine whether a target is healthy?
Auto Scaling Groups;EC2 & Compute
What is the difference between an Application Load Balancer, a Network Load Balancer, and a Classic Load Balancer?
Beginner
An Application Load Balancer operates at the application layer and supports advanced routing based on URL paths or hostnames, making it ideal for modern web applications and microservices, a Network Load Balancer operates at the transport layer and is designed for extremely high performance and low latency scenarios needing to handle millions of requests per second while preserving the client's original IP address, and a Classic Load Balancer is an older generation load balancer that has largely been replaced by the more feature rich Application and Network Load Balancer options for new deployments.
aws elbv2 create-load-balancer --name my-alb --type application --subnets subnet-12345 subnet-67890
Real-world example
A company running a modern microservices architecture chooses an Application Load Balancer to route traffic to different services based on URL path, while a separate team running an extremely high throughput gaming backend chooses a Network Load Balancer for its ultra low latency performance characteristics.
Common follow-ups: When should a new application still consider using a Classic Load Balancer?;What specific features does an Application Load Balancer support that a Network Load Balancer does not?
Amazon ECS (Elastic Container Service);Amazon API Gateway
How do target groups and health checks work together within an Application Load Balancer to route traffic only to healthy instances?
Intermediate
A target group defines a set of registered targets, such as EC2 instances or Lambda functions, along with a health check configuration specifying how the load balancer should periodically verify that each target is functioning correctly, and only targets that pass this health check consistently are considered healthy and eligible to receive traffic, meaning the load balancer automatically and continuously routes around any target that starts failing its health checks.
aws elbv2 create-target-group --name my-targets --protocol HTTP --port 80 --vpc-id vpc-12345 --health-check-path /health
Real-world example
A web application configures its target group's health check to hit a dedicated /health endpoint every thirty seconds, and when one instance's application process crashes, the load balancer detects the resulting failed health checks within about a minute and automatically stops routing traffic to that instance.
Common follow-ups: How do you configure the frequency and failure threshold for a health check?;Can a single load balancer route to multiple different target groups based on the request path?
Auto Scaling Groups;Monitoring (CloudWatch)
How does path based and host based routing on an Application Load Balancer support directing traffic to different backend services within a single load balancer?
Intermediate
Path based routing lets you direct requests to different target groups based on the URL path, such as sending requests starting with slash api to one set of servers and slash images to another, while host based routing directs traffic based on the requested hostname, such as routing api.example.com and www.example.com to entirely different target groups, both letting a single Application Load Balancer efficiently serve multiple backend services or microservices without needing a separate load balancer for each one.
aws elbv2 create-rule --listener-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:listener/app/my-alb/abc/def --conditions Field=path-pattern,Values='/api/*' --actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:...
Real-world example
A company running both its main website and a separate API service uses a single Application Load Balancer with path based routing rules, sending requests to slash api to their API servers while all other requests go to their main website servers.
Common follow-ups: How many routing rules can a single Application Load Balancer listener support?;What is the priority order when multiple routing rules could match the same request?
Amazon ECS (Elastic Container Service);Amazon API Gateway
How does a Network Load Balancer's preservation of the client's source IP address benefit certain applications compared to an Application Load Balancer?
Intermediate
A Network Load Balancer operates at the transport layer and by default preserves the original client IP address all the way through to the backend target, which is important for applications that need to log or make decisions based on the actual client IP, such as certain security appliances or applications requiring strict IP based access control, whereas an Application Load Balancer, operating at a higher layer, requires the backend application to read the client's original IP from an added header rather than seeing it directly on the connection itself.
aws elbv2 create-target-group --name nlb-targets --protocol TCP --port 443 --target-type instance --vpc-id vpc-12345
Real-world example
A security appliance vendor requires visibility into the actual client IP address for its filtering logic, so the company deploying it uses a Network Load Balancer rather than an Application Load Balancer to ensure that IP information is preserved without requiring any application level changes.
Common follow-ups: How does an Application Load Balancer expose the client's original IP address if it does not preserve it directly?;What other transport layer protocols does a Network Load Balancer support besides TCP?
VPC & Networking;AWS Security Hub & GuardDuty
How can Application Load Balancer support sticky sessions, and when is this feature actually necessary for an application?
Advanced
Sticky sessions, also called session affinity, let the load balancer consistently route requests from the same client to the same backend target for the duration of a session, using a cookie to track this assignment, which is necessary for applications that store session state locally in memory on a specific server rather than in a shared external session store, though it is generally considered a better long term practice to design applications to be stateless and store session data in a shared store like ElastiCache or DynamoDB instead of relying on sticky sessions.
aws elbv2 modify-target-group-attributes --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-targets/abc --attributes Key=stickiness.enabled,Value=true
Real-world example
A legacy application that stores user session data directly in each server's local memory temporarily enables sticky sessions on its load balancer while the development team works on a longer term migration to store session data in a shared ElastiCache cluster instead.
Common follow-ups: What are the downsides of relying on sticky sessions for scaling and fault tolerance?;How long does a sticky session cookie typically remain valid?
Amazon ElastiCache (Redis & Memcached);Auto Scaling Groups
How do you design a load balancer architecture that supports zero downtime blue green or canary deployments for a production application?
Advanced
A zero downtime deployment architecture typically uses weighted target groups behind an Application Load Balancer listener rule, letting you gradually shift a defined percentage of traffic from an old target group running the current version to a new target group running the updated version, closely monitoring error rates and performance metrics during the shift, and instantly reverting the weight back to the original target group if any problem is detected, without ever needing to take the application offline during the transition.
aws elbv2 modify-rule --rule-arn arn:aws:elasticloadbalancing:... --actions Type=forward,ForwardConfig='{"TargetGroups":[{"TargetGroupArn":"arn:old","Weight":90},{"TargetGroupArn":"arn:new","Weight":10}]}'
Real-world example
A company deploying a major update to its checkout service configures weighted target groups on their Application Load Balancer, gradually shifting traffic from ten percent to one hundred percent onto the new version over the course of an hour while closely monitoring for any increase in error rates.
Common follow-ups: How quickly can traffic weighting be adjusted or reverted during a canary deployment?;What monitoring should be in place to automatically detect problems during a weighted traffic shift?
AWS CodePipeline
CodeBuild & CodeDeploy (CI/CD);Monitoring (CloudWatch)