Elastic Load Balancing (ELB) is the load balancing service provided by Amazon Web Services (AWS), when load increases on one Web server or application server, on another server. It plays the role of distributing the load on it. In other words, you realize scale-out by distributing the load per unit.
So why do you need ELB to use SSL certificate to communicate with SSL?
Actually, ELB has SSL Termination function, it is possible to do SSL processing on the ELB side without making SSL processing EC2 (Web server) side. In other words, when a client (user) accesses a certain site with HTTPS, it normally performs SSL processing once via the ELB before accessing the self-built web server, from there it seems to be accessed to each Web server.
Benefits of Elastic Load Balancing
- Distribution can be performed for multiple Availability Zones (AZ). Even if one AZ goes offline, we can continue processing with another AZ
- Only normal instances can be distributed. Stop sorting for abnormal instances.
- You can use HTTPS / SSL
- Supports sticky session to maintain user sessions
- One can apply security group policy and realize flexible security
How Elastic Load Balancing works
- It consists of two components: load balancer and controller service
- Handle requests sent over the Internet
- Assign a unique DNS name to the load balancer instance you create
- You can use a custom domain (any domain like example.com).
- Use alias in CNAME
- When resolving a domain name in DNS, multiple global IP addresses are returned
- When ELB expands or shrinks, the number of IP addresses that respond changes
- ELB registers with the load balancer using the IP associated with the instance
- ELB performs health check, normal time: sorting is performed, abnormal time: not doing sorting
- Load balancing with multiple AZs in same region
- By using Auto Scaling, it is possible to automatically increase distributed EC 2 instances when they exceed the threshold of CPU etc
Distribution method of ELB
User Access → DNS (Round Robin) → Load Balancer (Least Connection) → EC 2
Elastic Load Balancing Monitoring
- Can be monitored by CloudWatch metrics
- It can be set to save ELB access log to S3 (default invalid)
- With CloudTrail, you can audit ELB API calls
HTTP error in ELB
- HTTP 400: BAD_REQUEST → Client sends an invalid request
- HTTP 405: METHOD_NOT_ALLOWED → Invalid method length
- HTTP 408: Request Timeout -> The client canceled the request or failed to send the entire request
- HTTP 502: Bad Gateway → The load balancer was unable to parse the response sent from the registered instance
- HTTP 503: Service Unavailable or HTTP 504: Gateway Timeout → Error due to Load Balancer or Registered Instance
- The load balancer lacks the ability to process the request (the scale of ELB is not catching up → it fits over time)
Types and characteristics of Elastic Load Balancing
Currently available ELBs are of the following three types and corresponded to generic names.
- Network Load Balancer (NLB): L4 NAT load balancer
- Application Load Balancer (ALB): L7 reverse proxy
- Classic Load Balancer (CLB): L4 / L7 Reverse Proxy
The atmosphere treated by NLB and others is quite different. Without fear of misunderstanding, NLB is an impression close to network components, which are classified as VPC functions such as NAT Gateway and Elastic IP rather than conventional ELB (ALB and CLB).
ALB and CLB communicate with the client via the load balancer as both the reverse proxy wrote and go back and forth. On the other hand, since NLB transfers the destination IP of the traffic by rewriting it to the IP of the target, returning from the target directly to the client without going through the load balancer.