Load Balancing

Load balancers are servers that forward internet traffic to multiple servers (EC2 Instances) downstream

 

Why use a load balancer?

- Spread load across multiple downstream instances

- Expose a single point of access (DNS) to your application

- Seamlessly handle failures of downstream instances

- Do regular health checks to your instances

- Provice SSL termination (HTTPS) for your websites

- Enforce stickiness with cookies

- High availability accoss zones

- Seperate public traffic from private traffic

 

Why use an EC2 Load Balancer?

 

- An ELB (EC2 Load Balancer) is a managed load balancer

 a) AWS guarantees that it will be working

 b) AWS takes care of upgrades, maintenance, high availability

 c) AWS provides only a few configuration knobs

 

- It costs less to setup your own load balancer but it will be a lot more effort on your end

- It is integrated with many AWS offerings / services

 

Types of load balancer on AWS

 

- AWS has 3 kinds of Load Balancers

- Classic Load Balancer (v1 - old generation) - 2009

- Application Load Balancer (v2 - new generation) - 2016

- Network Load Balancer (v2 - new generation) - 2017

- Overall, it is recommended to use the newer / v2 generation load balancer as they provide more features

 

Health Checks

- Health Checks are crucial for Load Balancers

- They enable the load balancers to know if instances it forwards traffic to are available to reply to requests

- The health check is done on a port and a route (/health is common)

- If the response is not 200 (OK) , then the instance is unhealthy

 

Application Load Balancer (v2)

- Application load balancers (Layer 7) allow to do:

 a) Load balancing to multiple HTTP applications accross machines (target groups)

 b) Load balancing to multiple applications on the same machine(ex:containers)

 c) Load balancing based on route in URL

 d) Load balancing based on hostname in URL

 

- Basically, they're awesome for micro services & container-based application (ex: Docker & AWS ECS)

- Has a port mapping feature to redirect to a dynamic port

 

- In comparison, we would need to create one Classic Load Balancer per application before. That was very expensive and inefficient.

 

Application Load Balancer (v2) HTTP Based Traffic

 

- Stickiness can be enabled at the target group level

 a) Same request goes to the same instance

 b) Stickiness is directly generated by the ALB (not the application)

- ALB support HTTP/HTTPS & Websockets protocols

- The application servers don't see the IP of the client directly

 a) The true IP of the client is inserted in the header X-Forwarded-For

 b) We can also get Port (X-Forwarded-Port) and proto (X-Forwarded-Proto)

 

Network Load Balancer (v2)

 

Network load balancers (Layer 4) allow to do:

 a) Forward TCP traffic to your instances

 b) Handle milions of request per seconds

 c) Support for static IP or elastic IP

 d) Less latency ~ 100ms (vs 400 ms for ALB)

 

Network Load Balancers are mostly used for extreme performance and should not be the default load balancer you choose

 

Overall, the creation process is the same as Application Load Balancers

 

Classic Load Balancers are Deprecated 

 a) Application Load Balancers for HTTP / HTTPs & Websocket

 b) Network Load Balancer for TCP

CLB and ALB support SSL certificates and provide SSL termination

All Load Balancers have health check capability

ALB can route on based on hostname / path

ALB is a greate fit with ECS (Docker)

Any Load Balancer (CLB, ALB, NLB) has a static host name. Do not resolve and use underlying IP

LBs can scale but not instantaneously - contact AWS for a "warm-up"

NLB directly see the client IP

4XX errors are client induced errors

5XX errors are application induced errors

 a) Load Balancers Errors 503 means at capacity or no registered target

If the LB can't connect to your application, check your security groups