This blog is a part of my journey “Embarking on the AWS Solution Architect Associate SAA-CO3 Certification Journey”

Table of Content

• Introduction
• Health Checks
• Types of Load Balancers on AWS
  • Classic Load Balancers (CLB)
  • Application Load Balancer (ALB)
  • Network Load Balancer (NLB)
  • Gateway Load Balancer
• Sticky Sessions
• Cross Zone Load Balancing
• SSL – Server Name Indication (SNI)
• Connection Draining

Introduction

1. Load balancers serve as essential components that distribute incoming traffic across multiple servers downstream.
2. They effectively spread the load among various downstream instances.
3. Load balancers provide a single point of access (DNS) to your application.
4. They adeptly manage failures of downstream instances, ensuring seamless operation.
5. Health checks are conducted on instances to ascertain their availability.
6. Load balancers offer SSL termination for your websites.
7. They support stickiness through cookies.
8. High availability across different zones is ensured.
9. Managed load balancers come with AWS guarantees, handling upgrades, maintenance, and high availability.
10. While cost-effective, setting up your own load balancer requires more management effort and integrates with many AWS offerings:
    1. EC2, EC2 Autoscaling groups, Amazon ECS
    2. AWS Certificate Manager, CloudWatch
    3. Route 53, AWS WAF, AWS Global Accelerator

Health Checks

1. Health checks are pivotal for load balancers to determine instance availability.
2. They enable load balancers to know whether the instances they forward traffic to are functional.
3. Typically, health checks are conducted on a port with a common route like /health.
4. If the response is not satisfactory (e.g., not 200 OK), the instance is marked as unhealthy.

Types of Load Balancers on AWS

1. AWS provides four types of managed load balancers:
   1. Classic Load Balancers (CLB, v1 – old generation) – Supports HTTP, HTTPS, TCP, SSL (since 2009).
   2. Application Load Balancers (ALB, v2 – new generation) – Supports HTTP, HTTPS, WebSocket (since 2016).
   3. Network Load Balancers (NLB, v2 – new generation) – Supports TCP, UDP, TLS (since 2017).
   4. Gateway Load Balancers (since 2020) – Operates at Layer 3 (Network Layer).
2. It’s recommended to use newer generation load balancers due to enhanced features.
3. Load balancers can be set up as internal or external.

Application Load Balancer (ALB)

1. ALB operates at Layer 7 (HTTP) and balances traffic across multiple applications on the same machine.
2. It supports HTTP/2 and WebSocket.
3. ALB offers features like redirects and routing tables based on URL, hostname, query string, or headers.
4. ALB is ideal for microservices and container-based applications.
5. It supports routing to various target groups, including EC2 instances, ECS tasks, Lambda functions, and IP addresses.
6. Health checks are conducted at the target group level.
7. ALB ensures client IPs are not directly visible to applications, using the X-Forwarded-For header for the true client IP.

Network Load Balancer (NLB)

1. NLB operates at Layer 4 and forwards TCP and UDP traffic to instances.
2. It handles millions of requests per second with low latency (around 100ms).
3. NLB has a static IP per Availability Zone and supports Elastic IP assignment.
4. It excels in extreme performance for TCP or UDP traffic.
5. NLB can route traffic to EC2 instances, IP addresses, Application Load Balancers, and more.
6. Health checks support TCP, HTTP, and HTTPS protocols.

Gateway Load Balancer

1. Gateway Load Balancer manages third-party network virtual appliances in AWS.
2. Examples include firewalls, intrusion detection/prevention systems, and deep packet inspection systems.
3. It operates at Layer 3 (Network Layer) with IP packets.
4. Gateway Load Balancer combines transport network gateway and load balancing functionalities.
5. It uses the geneve protocol and supports EC2 instances and IPs.

Sticky Sessions

1. Sticky sessions ensure that the same client is consistently routed to the same instance behind a load balancer.
2. Supported by CLB, ALB, and NLB.
3. Stickiness is implemented using cookies, which have configurable expiration.
4. Commonly used for maintaining session data, but may lead to load imbalance.

Cross Zone Load Balancing

1. Cross Zone Load Balancing evenly distributes traffic across all registered instances in all Availability Zones.
2. Enabled by default for Application Load Balancers.
3. No charges apply for inter-AZ data transfer.
4. Network and Gateway Load Balancers must be explicitly enabled.
5. Charges may apply for inter-AZ data transfer in these cases.

Elastic Load Balancer – SSL Certificates

1. SSL certificates encrypt traffic between clients and load balancers during transit.
2. SSL refers to Secure Socket Layer, often replaced with TLS (Transport Layer Security).
3. SSL certificates have expiration dates and can be renewed.
4. AWS offers ACM (AWS Certificate Manager) for certificate management.
5. HTTPS listeners require a default certificate, and multiple certificates can be added to support various domains.

SSL – Server Name Indication (SNI)

1. SNI resolves the challenge of accommodating multiple SSL certificates on a single server.
2. It’s a modern protocol that mandates the client to specify the target server’s hostname during the initial SSL handshake.
3. Consequently, the server can identify the appropriate certificate or revert to the default one.
4. Important Considerations:
   1. SNI functionality is exclusive to ALB and NLB.
   2. It’s not compatible with CLB.
5. In the case of Classic Load Balancer (CLB):
   1. CLB supports only one SSL certificate.
6. For ALB and NLB:
   1. They support multiple listeners, each with numerous SSL certificates.
   2. SNI is utilized to enable this functionality.

Connection Draining

1. Connection Draining, also known as Deregistration Delay in ALB and NLB, serves a vital role.
2. ELB (Elastic Load Balancer) grants sufficient time for in-flight requests to conclude when an instance is deregistered or unhealthy.
3. During this period, ELB refrains from directing new requests to the EC2 instance undergoing deregistration.
4. You can configure this time interval within the range of 1 to 3600 seconds, with a default value of 300 seconds.
5. Disabling connection draining is feasible by setting the value to 0.
6. For shorter requests, it’s advisable to opt for a lower connection draining duration.