Differences: ALB vs. NLB vs. CLB

Compare ALB (Application Load Balancer), NLB (Network Load Balancer), and CLB (Classic Load Balancer) based on their key components

Today, Let's Deep Dive into the differences between ALB, NLB, and CLB.

Features of All (ALB, NLB, and CLB) Load Balancer:

1. Health Checks
2. Target Group : Distribute incoming traffic to Target Group such as EC2 instance or docker containers
3. SSL Termination / TLS Termination : This offloads the encryption/decryption workload from the servers.
4. Session Stickiness
5. Access Logs and Monitoring : All of them can send important metrics to CloudWatch for monitoring and logging relevant data to CloudWatch logs.

CLB (Classic Load Balancer) / ELB (Elastic Load Balancer) :

1. Supports both Layer 4 (TCP) and Layer 7 (HTTP) protocols
2. Supports application-defined sticky session cookies, allowing users to control session persistence, unlike ALB where cookies are managed internally.
3. It can stop and restart TLS traffic, re-encrypting it if a self-signed SSL certificate is provided. End-to-end encryption is often needed to meet compliance standards.

In Simple words, It can stop and then restart secure internet traffic, making sure it follows the rules for keeping information safe. It can also double-check the security certificates that websites provide to make sure they’re genuine, adding extra protection.

Usage:

When you need to use your sticky session cookies

Key Components:

1. Listeners: Supports HTTP, HTTPS, TCP, and SSL protocols. Listeners are configured based on port numbers.
2. Target Groups: Routes traffic to instances based on EC2 instance IDs orx IP addresses.
3. Health Checks: Supports health checks at the instance level, monitoring the health of EC2 instances by sending requests to a specified port.
4. Layer of Operation: Primarily operates at Layer 4 (Transport Layer) but also includes some Layer 7 capabilities.
   Supports HTTP, HTTPS, TCP, and SSL protocols, offering flexibility but lacking some advanced features for HTTP traffic compared to ALB.
5. Instance Stickiness: Supports both cookie-based and load-balancer-generated stickiness policies to maintain session persistence.

Drawbacks of CLB:

1. Performance impact: Processing overhead for terminating and re-encrypting traffic can slow down network performance.
2. Complexity in certificate management: Managing SSL certificates adds complexity and potential administrative burden.
3. Compatibility issues: CLB may not be compatible with all applications or protocols.
4. Security risks: Misconfiguration could lead to security vulnerabilities.
5. Latency and potential points of failure: Inspecting and manipulating traffic could introduce latency and create potential points of failure in the network.

ALB (Application Load Balancer) :

1. Supports HTTP/2 and WebSockets

2. Supports a wide range of routing criteria such as hostname, path, query string parameter, HTTP method, headers, source IP, or port number. Additionally, it can route requests to Lambda functions, providing extensive control over traffic handling.

CLB only allows your routing based on port number.

3. It enables Server Name Indication (SNI), enabling it to host multiple domain names with a restriction of up to 25 certificates, plus one default certificate.

CLB only allows only one domain name.

4. It facilitates User authentication through a range of methods like OIDC, SAML, LDAP, Microsoft AD, and popular social identity providers like Facebook and Google. This feature allows the load balancer to handle user authentication instead of your application.

Usages:

1. Web Applications
2. Microservices Architecture: Front-facing entry point for microservices-based applications
3. Containerized Applications: ALB is often deployed in container orchestration platforms like Amazon ECS or Kubernetes to route traffic to containers running different parts of an application.
4. API Gateway: ALB can be used as an API gateway to manage and expose RESTful APIs.
5. Serverless Applications: ALB can also route requests to AWS Lambda functions, allowing for serverless application architectures.

Key Components:

1. Listeners: Supports HTTP, HTTPS, and WebSocket protocols. Listeners are configured to route traffic based on application-level information such as URL paths or HTTP headers.
2. Target Groups: Routes traffic to target groups based on content-based routing rules, allowing for more granular control over routing decisions.
3. Health Checks: Supports health checks at the application level, monitoring the health of targets based on response codes.
4. Layer of Operation: Operates at Layer 7 (Application Layer) of the OSI model, allowing for advanced routing based on HTTP/HTTPS content.
   Optimized for HTTP, HTTPS, and WebSocket protocols commonly used in web applications and APIs.
5. Instance Stickiness: Supports cookie-based session stickiness, enabling the same client to be directed to the same target for the duration of the session.

NLB (Network Load Balancer) :

1. Works at layer 4 only and handles TCP, UDP, as well as TCP connections with TLS.
2. High Performance, Uses static IP addresses and can be assigned EIPs, which both ALB and ELB can’t do.
3. NLB automatically retains the source IP address within TCP/UDP packets. On the other hand, ALB and ELB can be set up to include extra HTTP headers containing forwarding details, which your application must correctly interpret.

Usages:

1. The NLB automatically scales up or down based on demand to maintain optimal performance.
2. If your application uses non-HTTP protocols.
3. You would want to use an ALB for layer 7 load balancing and NLB for everything else.

Key Components:

1. Listeners: Supports TCP, TLS, and UDP protocols. Listeners are configured based on IP address and port.
2. Target Groups: Routes traffic to target groups based on IP address and port, offering simplicity and efficiency for TCP-based applications.
3. Health Checks: Supports health checks at the network level, monitoring the health of targets based on TCP connections.
4. Layer of Operation: Operates at Layer 4 (Transport Layer) of the OSI model, focusing on routing based on IP and port information.
   Suitable for TCP, TLS, and UDP protocols, it is ideal for low-latency, high-throughput applications like gaming or VoIP.
5. Instance Stickiness: This does not support session stickiness. Each request is independently routed to the appropriate target.

Thanks for spending your valuable time learning to enhance your knowledge!