What is load balancing?
Nowadays many applications and websites can serve millions of concurrent requests to users/clients globally. When the amount of network workload increases on an application or website, a single server may fail to support network traffic. To manage the demand of volatile network traffic efficiently, you can use a Load balancer to distribute incoming network traffic across multiple servers, and prevent failure caused by overloading on a single server. The load balancer sits between user/client devices and backend servers to support efficient handling of high traffic.
Benefits of Load balancer:
- Increase the availability and reliability of your application, by sending traffic to healthy available servers.
- Handling peak demands (traffic increase) by distributing application/website traffic efficiently across multiple healthy servers.
- Load balancer with auto scaling, provides flexibility to automatically scale (add or remove) servers on demand.
AWS Elastic Load Balancing
AWS Elastic Load Balancing (ELB) is a cloud-based load balancing service, that automatically distributes incoming traffic across multiple targets, such as EC2 instances, containers, and IP addresses.
Features of Elastic Load Balancing
High Availability and Health checks
Elastic Load Balancer is a highly available cloud service. You can distribute traffic in one Availability Zone or multiple Availability Zones. ELB only routes traffic to healthy targets like EC2 instances, IP addresses, Lambda functions. Health check configuration allows monitoring the health status of your targets that are running behind the load balancer.
For example, if any EC2 server is unhealthy or not available, ELB routes traffic to the other healthy EC2 server. It can also route traffic to the other availability zones, in case of all EC2 servers are down in a specific availability zone.
High throughput
An Elastic Load balancer provides reliable handling of network traffic, when it grows. It can control millions of application/website requests per second.
Sticky sessions
When a request reached to Application Load Balancer (ALB), it routes the request independently to a registered target. It means requests can be served by any server, that is running behind the Load balancer. You can use the Sticky session feature to bind a user’s session to a specific server, to make sure all the requests from the user during the session are sent to the same server.
Security
Elastic Load Balancer associates with Amazon Virtual Private Cloud (VPC) to provide strong network security. Depending on your requirement, you can create internet-facing (load balancer with public IP)) and non-internet-facing (internal load balancer with private IP) load balancers. You can associate security groups, authentication, and SSL/TLS decryption with ELB to provide more network security.
Operational monitoring, logging and auditing
Elastic Load Balancer also provides other features like : –
- Using Amazon CloudWatch metrics you can monitor request counts, error counts, request latency, and more
- Using AWS CloudTrail you can track API calls to the load balancer.
- You can configure ELB to prevent it from accidental deletion, by enabling deletion protection.
Types of Elastic Load Balancing
There are four types of elastic load balancers : –
- Classic Load Balancer
- Application Load Balancer
- Network Load Balancer
- Gateway Load Balancer
Classic Load Balancer
AWS retiring the classic load balancer, it’s better to migrate to another available load balancer. For more information see the – Migration Process.
Application Load Balancer
Application Load Balancer Operates at layer-7 of the OSI (Open Systems Interconnection) model. ALB can distribute incoming traffic to multiple targets based on the application-level details such as HTTP and HTTPS traffic, Content of the message.
Working of Application Load Balancer Components
- User/client makes a request to the application.
- Each request from the client is received by listeners in the load balancer. A listener specifies the rules such as protocol, port, target group (EC2 instances, IP addresses, lambda functions), priority, and conditions for routing the requests.
- After receiving the request from the listener, It evaluates the incoming request against the specified rules and decides to route the request to the appropriate target group. You can use HTTPS listener to offload/drop the work of TLS encryption and decryption to the load balancer.
- You can configure a health check while creating a Target Group. Only healthy targets receive the traffic from the load balancer.
Network Load Balancer
Network Load Balancer Operates at layer-4 of the OSI (Open Systems Interconnection) model. It is useful for load balancing based on TCP (Transmission Control Protocol) and UDP (User Datagram Protocol). NLB is capable of handling millions of requests per second while maintaining high throughput and ultra-low latencies. NLB is very well optimized for handling sudden and volatile traffic patterns.
Working of Network Load Balancer Components
- User/client makes a request to the application.
- Each request received by listeners in the load balancer, either directly or through an endpoint (from AWS PrivateLink)
- After receiving the request by the listener, It evaluates the incoming request against the specified rules and decides to route the request to the appropriate target group. You can use a TLS listener to offload/drop the work of TLS encryption and decryption to the load balancer.
- You can configure a health check while creating a Target Group. Only healthy targets receive the traffic from the load balancer according to the flow hash algorithm based on the protocol, source IP address, source port, destination IP address, destination port, and TCP sequence number
Gateway Load Balancer
Gateway Load Balancer Operates at layer-3 of the OSI (Open Systems Interconnection) model. It allows you to deploy, scale, and manage virtual appliances, such as firewalls, intrusion detection and prevention systems, and deep packet inspection systems. It combines a transparent network gateway (i.e. A single entry and exit point for all traffic) and distributes the connections to virtual appliances and scales them up or down with demand.
The Gateway Load Balancer and its registered virtual appliance instances exchange application traffic using the Gateway Load Balancer endpoint (GENEVE protocol on port 6081).
Working of Gateway Load Balancer Components
- User/client makes a request to the application.
- Load balancer receives the request based on the route table configurations that are set with VPC, Internet Gateway, or Transit Gateway.
- Load balancer routes requests to the target group consisting of appliances (for example – firewalls, deep packet inspection systems, URL filtering systems, etc.) to process the request.
- Virtual appliance processes the request and forwards it back to the load balancer, and the load balancer forward again to its destination. Depending on the configuration request may drop also if it is failed to process.
Comparison of different type of load balancers
| Feature | Application Load Balancer | Network Load Balancer | Gateway Load Balancer |
| Load Balancer type | Layer 7 | Layer 4 | Layer 3 Gateway + Layer 4 Load Balancing |
| Target type | IP, Instance, Lambda | IP, Instance, Application Load Balancer | IP, Instance |
| Terminates flow/proxy behavior | Yes | Yes | No |
| Protocol listeners | HTTP, HTTPS, gRPC | TCP, UDP, TLS | IP |
| Reachable via | VIP | VIP | Route table entry |
| Common configurations and characteristics | |||
| Slow start | ✔ | ||
| Outpost support | ✔ | ||
| Local Zone | ✔ | ||
| IP address – Static, Elastic | ✔ | ||
| Connection draining (deregistration delay) | ✔ | ✔ | ✔ |
| Configurable idle connection timeout | ✔ | ||
| PrivateLink Support | ✔ (TCP, TLS) | ✔ (GWLBE) | |
| Zonal Isolation | ✔ | ✔ | |
| Session resumption | ✔ | ✔ | |
| Long-lived TCP connection | ✔ | ✔ | |
| Load Balancing to multiple ports on the same instance | ✔ | ✔ | ✔ |
| Load Balancer deletion protection | ✔ | ✔ | ✔ |
| Preserve Source IP address | ✔ | ✔ | ✔ |
| WebSockets | ✔ | ✔ | ✔ |
| Supported network/Platforms | VPC | VPC | VPC |
| Cross-zone Load Balancing | ✔ | ✔ | ✔ |
| IAM Permissions(Resource, Tag based) | ✔ | ✔ | ✔ |
| Flow Stickiness (All packets of a flow are sent to one target, and return traffic comes from same target) | Symmetric | Symmetric | Symmetric |
| Fail close on targets, unless all targets are unhealthy(fail open) | Fail close on targets, unless all targets are unhealthy(fail open) | Existing flows continue to go to existing target appliances, new flows are rerouted to healthy target appliances. | |
| Target Failure behavior | |||
| Health Checks | HTTP, HTTPS, gRPC | TCP, HTTP, HTTPS | TCP, HTTP, HTTPS |
| Security | |||
| SSL Offloading | ✔ | ✔ | |
| Server Name Indication (SNI) | ✔ | ✔ | |
| Back-end Server Encryption | ✔ | ✔ | |
| User Authentication | ✔ | ||
| Custom Security Policy | |||
| ALPN | ✔ | ✔ | |
| Kubernetes Controller | |||
| Direct-to-pod | ✔ | ✔ (Fargate pods) | |
| Load Balance to multiple namespaces | ✔ | ||
| Support for fully private EKS clusters | ✔ | ✔ | |
| Logging and monitoring | |||
| CloudWatch Metrics | ✔ | ✔ | ✔ |
| Logging | ✔ | ✔ | ✔ |