Elastic Load Balancer

Traffic Flow (Request Entering):

Client Request → Gateway Load Balancer (L3) → Network Load Balancer (L4) → Application Load Balancer (L7) → EC2 / AWS Resources

Example - User Request → GWLB (Firewall) → NLB (TCP Routing) → ALB (URL-Based Routing) → EC2 Web App

1. Throttle API requests

Elastic Load Balancer(ALB/NLB/..) cannot throttle API requests. Use API gateway for this.

alt text

2. Routes traffic based on content of the request

The Application Load Balancer (ALB) is best suited for load balancing HTTP and HTTPS traffic. It offers advanced request routing, making it ideal for modern application architectures such as microservices and containers. Operating at the application layer/individual request level (Layer 7), the ALB routes traffic to targets within an VPC based on the content of the request, such as URL path or host headers.

3. Gateway Load Balancer (Layer 3) > Network Layer (routes IP traffic, GWLB uses Geneve encapsulation)

  1. Gateway Load Balancer (GWLB) operates at the Network Layer (Layer 3) in the OSI model.
  2. GWLB is specifically designed to handle network packet-level traffic.
  3. It suitable for use cases like third-party virtual appliances, including firewalls, intrusion detection systems (IDS), and deep packet inspection.
  4. Ensures traffic from the same session is consistently routed to the same appliance for stateful processing.
  5. Ideal Use Cases:
    1. Traffic Inspection: Deploying firewalls, intrusion prevention/detection systems (IPS/IDS), or deep packet inspection (DPI) tools.
    2. Compliance and Security: Enforcing security policies or regulatory compliance with third-party appliances.
  6. How it Works:
    1. Traffic is directed to the Gateway Load Balancer endpoint (GWLB Endpoint), typically deployed in a VPC.
    2. GWLB forwards traffic to virtual appliance instances (e.g., firewalls) in a target group for processing.
    3. Processed traffic is returned to the GWLB and routed to the intended destination. alt text

4. Network Load Balancer (Layer 4) > Transport Layer (TCP/UDP traffic)

  1. Network Load Balancer (NLB) works at the Transport Layer (Layer 4) of the OSI model.
  2. NLB routes traffic based on TCP, UDP, and TLS protocols.
  3. NLB support HTTP, HTTPS and TCP health checks.
  4. NLBs only allow EC2 instances or IP addresses as targets. Unlike an ALB(ALB), NLBs do not allow you to provide a URL or domain name as a target.
  5. It is designed for ultra-low latency and high performance, capable of handling millions of requests per second.
  6. Routing decisions are made based on the IP address and port.
  7. Doesn't inspect the content of the packets; focuses only on efficiently routing traffic based on connection metadata.
  8. Use Case: Applications requiring high throughput like Financial services, gaming, or real-time applications.

5. Application Load Balancer (Layer 7) > Application Layer (HTTP/S, WebSockets, etc.)

An Application Load Balancer (ALB) is a Layer 7 load balancer that routes HTTP and HTTPS traffic to different targets based on URL paths, hostnames, query string parameters, HTTP headers, HTTP Method, and Source IP Address CIDR.

  1. Layer 7 corresponds to the Application Layer in the OSI model.
  2. Operates at request level, interpreting the content of HTTP, HTTPS, and WebSocket protocols.
  3. Application and Classic Load Balancers expose a fixed DNS (=URL) rather than the IP address.
  4. Routes traffic to targets – Amazon EC2 instances, containers, IP addresses and AWS Lambda functions based on:
    1. The content of the request.
    2. Example: Redirecting traffic for api.example.com vs. www.example.com.
  5. Can make decisions based on application-specific content (e.g., sending requests to different target groups based on a query string).
  6. Ideal for:
    1. Complex routing needs (content-based routing).
    2. Web applications and microservices.
    3. Use cases: Multi-tenant SaaS applications or modern web apps.

osi-aws

6. Routing Features of ALB(Layer 7)

  1. Path-based Routing: Routes traffic based on the URL path (e.g., x.com/orders or x.com/products).
    1. Requests for https://www.example.com/orders go to the orders microservice.
    2. Requests for https://www.example.com/products go to the products microservice.
  2. Host-based Routing Routes traffic based on the Host header (e.g., www.example.com or api.example.com).
    1. Requests for www.example.com go to one target group.
    2. Requests for api.example.com go to another target group.
  3. HTTP Header-based Routing: Routes traffic based on values in the HTTP headers (e.g., custom headers like X-Request-Type).
    1. Requests with the header X-Request-Type: Order go to the orders microservice.
    2. Requests with the header X-Request-Type: Product go to the products microservice.
  4. Query String Parameter-based Routing: Routes traffic based on query string parameters in the URL (e.g., ?category=electronics).
    1. Requests for www.example.com/products?category=electronics go to one microservice.
    2. Requests for www.example.com/products?category=clothing go to another.
  5. Source IP Address CIDR-based Routing: Routes traffic based on the source IP address (CIDR block) of the client making the request.
    1. Requests from IP range 192.168.1.0/24 route to one microservice.
    2. Requests from 10.0.0.0/16 route to another.
  6. HTTP Method-based Routing: Routes traffic based on the HTTP method (e.g., GET, POST, PUT).
    1. Requests using the GET method route to one microservice.
    2. Requests using the POST method route to another microservice.

7. SSL/TLS

SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are cryptographic protocols that provide secure communication over a network.

SSL is the older version, now replaced by TLS. TLS is modern and more secure. TLS 1.3 is the latest

  1. Purposes of SSL/TLS:
    1. Encryption: Protects data by encrypting communication between the client and server.
    2. Authentication: Verifies the identity of the server to ensure you're communicating with the correct entity.
    3. Data Integrity: Ensures that data isn’t altered or tampered with during transmission.
  2. SSL/TLS Certificates:
    1. Issued by Certificate Authorities (CAs).
    2. Domain Validation (DV): Basic certificate validation.
    3. Wildcard Certificates: Secure multiple subdomains.
    4. Multi-Domain (SAN) Certificates: Secure multiple domains.
  3. Best Practices:
    1. Use TLS 1.2 or 1.3; disable outdated protocols (SSL 2.0/3.0).
    2. Use SSL/TLS certificates for authentication and encryption.
    3. Use SNI (Server Name Indication) for hosting multiple SSL certificates on the same IP.

8. Server Name Indication (SNI)

  1. Server Name Indication (SNI) is an extension of the SSL/TLS protocol that allows multiple SSL certificates to be hosted on a single IP address and port.
  2. This allows the server to select the correct SSL certificate for the requested domain.
  3. Benefits of SNI:
    1. Efficient: Avoids the need for separate IP addresses for each SSL certificate.
    2. Flexibility: You can assign a unique SSL certificate to each domain or subdomain.
    3. Security: Helps in maintaining isolation between different domains or services.
  4. Configuring SNI in AWS ALB:
    1. Create Certificates using AWS Certificate Manager (ACM) or import SSL certificates for each domain/subdomain you want to secure.
    2. Create ALB by following the usual setup process for a load balancer.
    3. In the Listeners tab, choose HTTPS (Port 443) as the listener protocol.
    4. Create multiple HTTPS listeners, each with its own SSL certificate, using SNI to match certificates to domains.
    5. add multiple certificates in listener configuration.
    6. AWS ALB uses SNI to match the correct certificate based on the requested hostname.
  5. Wildcard SSL Certificate:
    1. While it can support multiple subdomains, it does not cater well to different domains (e.g., mycorp.com and yourcorp.com).
    2. It also lacks flexibility compared to SNI, especially if additional domains need to be added later.

9. Registered and DeRegistered targets

By default, the Application Load Balancer waits 300 seconds before the completion of the deregistration process, which can help in-flight requests to the target become complete. To change the amount of time that the Application Load Balancer waits, update the deregistration delay value.

https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html#deregistration-delay

10. Cross-Zone Load Balancing

Cross-Zone Load Balancing ensures that traffic is evenly distributed across instances in all configured Availability Zones, improving fault tolerance and scalability.

  1. Application Load Balancer (ALB): By default, cross-zone load balancing is enabled.
  2. Network Load Balancer (NLB): By default, cross-zone load balancing is disabled.

11. Question: ALB and NLB

A company's HTTP application is behind a Network Load Balancer (NLB). The NLB's target group is configured to use an Amazon EC2 Auto Scaling group with multiple EC2 instances that run the web service. The company notices that the NLB is not detecting HTTP errors for the application. These errors require a manual restart of the EC2 instances that run the web service. The company needs to improve the application's availability without writing custom scripts or code. What should a solutions architect do to meet these requirements?

  1. Enable HTTP health checks on the NLB, supplying the URL of the company's application.
  2. Replace the NLB with an Application Load Balancer. Enable HTTP health checks by supplying the URL of the company's application. Configure an Auto Scaling action to replace unhealthy instances. (Correct Ans)

*Explanation: Option 1 is incorrect because NLB supports HTTP and HTTPS Health Checks, BUT you can't put any URL (as proposed), only the node IP addresses.