# Chapter 10 | Elastic Load Balancing (ELB)

## Overview

1. Elastic Load Balancing automatically distributes incoming application traffic across multiple targets, such as EC2 instances

2. Can be done **across multiple AZs**

### 4 Types of Load Balancers

1. ++Application Load Balancer (L7)++
* Intelligent load balancer
* Best suited for load balancing of **HTTP and HTTPS traffic**
* Operates at Layer 7
* Application aware

2. ++Network Load Balancer (L4)++
* Performance load balancer
* Capable of handling millions of requests per second while maintaining **ultra-low latencies**
* Operates at Layer 4 (transport layer, TCP/UDP)

3. ++Gateway Load Balancer (L3)++
* For inline virtual appliance load balancing
* For deploying inline virtual appliance where network traffic is not destined for the Gateway Load Balancer itself
* Operates at Layer 3 (network layer, IP/ICMP/...)

4. ++Classic Load Balancer (L4/7)++
* Classic/test/dev load balancer
* Legacy load balancers
* Can load balance HTTP/HTTPS applications and use Layer 7-specific features
* E.g., X-Forwarded, sticky sessions

### ELB Comparison Chart


### Health Checks

1. All AWS load balancers can be configured with health checks

2. Health checks periodically send request to load balancers' **all registered instances** to test their status
* The status of the instances that are healthy at the time of the health check is `InService`
* Unhealthy instance's status is `OutOfService`

3. The load balancer routes requests only to the healthy instances
* Resumes routing requests to the instance when it has been restored to a healthy state

---

## Application Load Balancer

### Layer 7 Load Balancing

1. An Application Load Balancer functions at Application layer

2. After the load balancer receives a request, it evaluates the **listener rules** in **priority order** to determine which rule to apply, and selects a **target** from the target group for the rule action

### Listeners, Rules, and Target Groups

1. ++Listener++
* A listener **check for connection request** from clients, using the protocol and port you configure
* You define rules that determine how the load balancer route requests to its registered targets
* Each rule consists of a **priority**, one or more **actions** and one or more **conditions**

2. ++Rule++
* When the **conditions** for a rule are met, then its **actions** are performed
* Must define a **default rule** for each listener, and you can optionally define additional rules

3. ++Target Group++
* Each target group **routes request** to one or more registered targets, such as EC2 instances, using the protocol and port number you specify
* E.g., can have a target group for web servers; another for media servers

### Application Load Balancer Diagram


### Path-Based Routing

==Common Exam Scenario==


A user browses to a URL that hits route 53, and that's sending traffic to an application load balancer

When the user visits `myurl.com`, the application load balancer needs to send traffic to the web servers in `us-east-1a`

But when the user visits `myurl.com/images`, the application load balancer needs to send it to some other EC2 instances in another target group in another AZ

1. Since Application Load Balancer is Layer 7 aware and can do intelligent routing based on **paths**

2. Enable **path patterns**
* So the `myurl.com` will go to all your web servers in `us-east-1a`
* And the application load balancer will route-traffic to `myurl.com/images` to your media servers in `us-east-1b`

### Limitations of Application Load Balancer

1. Only supports HTTP and HTTPS, doesn't support any other listeners
* Can also route and load balance **gRPC traffic** between microservices or between gRPC-enabled clients and services. This will allow customers to seamlessly introduce gRPC traffic management in their architectures without changing any of the underlying infrastructure on their clients or services
* 

2. To use an HTTPS listener, you must deploy at leat one **SSL/TLS server certificate** on your load balancer
* The load balancer uses a server certificate to **terminate the frontend connection** and then **decrypt** requests from clients before sending them to the targets

### Demo

1. Set up listener


2. Create target group


3. Can configure rules after the LB is deployed under the `Listeners and rules` tab


4. Use the DNS name to send request to the LB


---

## Network Load Balancer

### Layer 4 Load Balancing

1. A Network Load Balancer functions at Layer 4 (transport layer, TCP/UDP)

2. It can handle millions of requests per second

### Request Received, Listeners, and Target Groups

1. ++Request Received++
* After the load balancer receives a connection request, it selects a target from the target group for the default rule
* It attempts to **open a TCP connection to the selected target** on the port specified in the listener configuration

2. ++Listener++
* A listener **check for connection request** from clients, using the protocol and port you configure
* The listener on a Network Load Balancer then **forwards the request** to the target group
* The are **NO RULES**, unlike the Application Load Balancers

3. ++Target Group++
* Each target group **routes request** to one or more registered targets, such as EC2 instances, using the protocol and port number you specify

### Ports and Protocols

1. Supported protocols: TCP, TLS, UDP, TCP_UDP
2. Supported ports: 1-65535

### TLS/SSL Offloading

1. You can use a **TLS listener to offload the work of encryption and decryption** to your load balancer so your applications can focus on their business logic

2. If the listener protocol is TLS, you must deploy exactly one **SSL server certiciate** on the listener

### Use Cases

1. NLBs are best suited for load balancing of TCP traffic where **extreme performance** is required

2. Operates at the transport level (layer 4), are capable of handling millions of requests per second while maintaining ultra low latencies

3. Other use cases: need protocols not supported by ALBs

---

## Classic Load Balancer

### Overview

1. Classic Load Balancers are the **legacy** load balancers

2. Can load balance HTTP/HTTPS applications and use **Layer 7-specific features**, such a `X-Forwarded` and sticky sessions

2. Can also use **strict** Layer 4 load balancing for applications that rely purely on the TCP protocol

### `X-Forwarded-For` Header

> [ref](https://developer.mozilla.org/zh-TW/docs/Web/HTTP/Headers/X-Forwarded-For)

1. When traffic is sent from a load balancer, the server access logs contain the IP address of the proxy or load balancer only

2. To see the **original IP address of the client**, the `X-Forwarded-For` header is used


### Gateway Timeouts

1. ==Exam Scenario== If your application stops responding, the Classic Load Balancer responds with a `504` error
* `504` error = gateway timeout
* Application is not responding within the idle timeout period

2. This means the **application** is having issues, which could be either at the **web server** layer or the **database** layer
* **LB is up and running** but it can't make a connection

---

## Sticky Session

1. Classic Load Balancers route each request **independently** to the registered EC2 instance with the **smallest load**

2. Sticky sessions allow you to **bind a user's session to a specific EC2 instance**
* Since it could be you're saving data locally on that EC2 instance, and you want to make sure when that user is visiting the website, they're going to the same EC2 instance and retrieve the data

3. Ensures all request from the user during the session are sent to the same instance
* Application session data is cached in **web servers** when using sticky sessions

4. **Scaling issues**
* If we remove the instance from the ELB pool that a user "sticks to", the user is going to get an error because the LB continues to direct traffic to that EC2 instance
* To solve this, we need to **disable** sticky sessions

5. We can enable sticky sessions for **Application Load Balancers** as well, but the traffic will be sent at the **target group level**
* If you got multiple EC2 instances in that target group, it might go to other EC2 instance

---

## Deregistration Delay

> Called "connection draining" in Classic Load Balancers

1. Deregistration Delay allows LBs to **keep existing connections open** is the EC2 instances are de-registered or become unhealthy

2. This enables the LB to **complete in-flight requests** made to instances that are de-registering or unhealthy

3. Can disable Deregistration Delay if you want your LB to **immediately close connections** to the instances that are de-registering or have become unhealthy

4. Classic LB


5. Other LBs
* Do it at **target group level**
* 

---

## Quiz

1. What happens if all registered targets in a Network Load Balancer (NLB) are unhealthy?
:::spoiler Ans
It will try to send traffic to all the instances

When the NLB has only unhealthy registered targets, the Network Load Balancer routes requests to all the registered targets, known as **fail-open mode**
:::

2. Which of the following statements about Application Load Balancers (ALBs) is true?
* (A) By default, ALB listeners check for connection requests from clients on port 443
* (B) You can create only one rule per ALB listener
* \(C\) ALB rules are evaluated in priority order, from the highest value to the lowest value
* (D) Application Load Balancers can be configured to use static IPs by partnering with a Network Load Balancer

:::spoiler Ans
(D) Application Load Balancers can be configured to use static IPs by partnering with a Network Load Balancer

In AWS, an Application Load Balancer (ALB) typically uses dynamic IP addressing. If you need your ALB to have a static IP address, you can achieve this by using a Network Load Balancer (NLB). You can associate the NLB with an Elastic IP address, which is a static, public IPv4 address, and then register your ALB as a target of the NLB. This setup effectively allows the ALB to use a static IP address, although it requires additional configuration and is not the default behavior of an ALB.
:::