components of Load Balancers

• Load Balancer - Single point of contact for traffic. Routes traffic to target groups or targets.

• Listener - Checks for the requests from clients using protocol & port. Routing is based on the listener rules and priority.

• Target Group - Group of targets like EC2 instances, IP addresses, Lambda functions or Docker containers etc., registered in a target group. One target can be registered with multiple target groups. Each target group uses a specific protocol and port (e.g., HTTP:80, HTTPS:443).

LOAD BALANCER

• The entry point that receives incoming traffic.

• Distributes traffic among registered targets.

• To ensure that ELB service can scale ELB nodes in each AZ, ensure that the subnet for the load balancer is at least /27 in size and at least 8 free IP addresses available.

• Always associate 2 or more subnets in different AZs with the load balancer.

• By default, ELB distribute traffic evenly between the AZ it is defined in, without consideration to the number of registered EC2 instances in each AZ.

• ELB can be configured with the Latency and Utilization metrics with CloudWatch.

• CloudWatch can trigger a notification to Autoscaling and a new instance can be launched as part of Autoscaling.

Listener

• A listener checks for connection requests from clients, using the protocol and port that you configure. 

• The rules that you define for a listener determine how the load balancer routes requests to its registered targets. 

• Each LB needs at least one listener to accept incoming traffic. Support up to 10 listeners.

• Sometimes for security purposes, applications listen on port 8080, this routing (from port 80 to 8080) is done by the listener.

• Routing rules are defined on listeners. Rules can forward requests to a specific target group.

• Rules provide the link between listeners and target groups and consists of conditions and actions. When a request meets the condition of the rule, the associated action is taken.

• Conditions can be specified in the path pattern format.

Target Group

• Logical grouping of targets behind load balancer, which can be EC2 instance, container-based application, microservice.

• EC2 instances can be registered with the same target group using multiple ports.

• A single target can be registered with multiple target groups.

• Target group can be associated with an Auto Scaling Group.

• Target group that contains up to 200 instances.

Health Checks

• By default, AWS uses ping HTTP (Port 80) for health checks.

• Support for TCP, HTTP/S health checks. Can be changed.

• Response timeout is 5 Seconds by default.

• Health Check Interval: Period of time between health checks. Default is 30 Seconds.

• Unhealthy Threshold: Number of consecutive failed health checks that should occur before the instance is declared unhealthy. Default: 2 (Range: 2-10)

• Healthy Threshold: Number of consecutive successful health checks that must occur before the instance is considered unhealthy. Default: 2 (Range: 2-10)

How ELB works?

1. Client request → ELB receives traffic on a specified port.

2. Listener rules → Determines how the request should be routed.

3. Health check → Ensures only healthy targets receive traffic.

4. Traffic forwarding → ELB distributes the request to an available and healthy target in the target group.

5. Response to client → The target processes the request and sends a response.

• If cross-zone load balancing is enabled, each of the 10 targets receives 10% of the traffic. This is because each load balancer node can route its 50% of the client traffic to all 10 targets.

• If cross-zone load balancing is disabled:

  • Each of the two targets in Availability Zone A receives 25% of the traffic.

  • Each of the eight targets in Availability Zone B receives 6.25% of the traffic.

• This is because each load balancer node can route its 50% of the client traffic only to targets in its Availability Zone.

• With Application Load Balancers, cross-zone load balancing is always enabled.

• With Network Load Balancers, cross-zone load balancing is disabled by default. After you create a Network Load Balancer, you can enable or disable cross-zone load balancing at any time.

Application Load Balancer

• Load Balancer - The main component that receives incoming HTTP/HTTPS requests. Distributes traffic to registered targets in one or more target groups. 

• Listeners - Defines how ALB checks and forwards incoming requests. Each listener listens on a specific protocol (HTTP/HTTPS) and port (80, 443, etc.). Listeners contain rules to determine how traffic is routed. 

  • Example: Listener: HTTP 80 → Redirect to HTTPS 443 

• Listener Rules - Define how ALB processes requests. Each rule consists of:

  • Conditions (Host headers, Path, Query strings, Source IP, etc.).

  • Actions (Forward to a target group, Redirect, Return fixed response).

  • Example:

    • If request path is /images → Forward to Image Service Target Group

    • If request path is /videos → Forward to Video Service Target Group

• Target Groups - A logical grouping of targets (EC2 instances, IPs, Lambda functions, ECS services). ALB routes traffic to healthy targets within the group. Each target group has: 

  • Protocol & Port (e.g., HTTP:80, HTTPS:443).

  • Health checks to monitor availability.

  • Example:

    • Target Group A → EC2 instances running Web App

    • Target Group B → ECS Containers for API Service

    • Target Group C → AWS Lambda Function

• Targets - The actual resources receiving traffic. Can be EC2 Instances, Containers (ECS, EKS), Lambda Functions, Private IP Addresses.

• Health Checks - ALB automatically checks the health of targets. If a target is unhealthy, ALB removes it from routing. Configurable parameters:

  • Path: /healthcheck

  • Interval: How often to check (default: 30s).

  • Success Codes: HTTP 200, 301, etc.

  • Unhealthy Threshold: Number of failed checks before marking a target unhealthy.

  • Example:

    • Health Check: HTTP GET /health → Success: HTTP 200

• Security Features 

  • SSL/TLS Termination: ALB can handle SSL certificates (HTTPS traffic) via AWS Certificate Manager (ACM).

  • AWS WAF (Web Application Firewall): Protects against web attacks like SQL injection, XSS.

  • Security Groups & IAM Policies: Controls access to and from the load balancer.

• Cross-Zone Load Balancing - ALB distributes traffic evenly across multiple Availability Zones (AZs). Ensures high availability and fault tolerance. 

• Logging & Monitoring - Access Logs stores detailed request logs in Amazon S3.

  • Metrics & Monitoring:

    • Amazon CloudWatch: Tracks request count, response time, error rates.

    • AWS X-Ray: Traces requests for debugging.

• Sticky Sessions (Session Persistence) - Uses Application Cookies to send repeat users to the same backend. Useful for stateful applications (e.g., shopping carts).

• Works at Layer 7 (Application Layer).

• Supports HTTP and HTTPS traffic.

• Uses content-based routing (routes requests based on URL, headers, host, etc.).

• Ideal for microservices and container-based applications.

• Ability to evaluate application level content apart from IP and port. 

• Evaluates listener rules in priority order before routing to target groups.

• You can load balance any application hosted in AWS or on-premises using IP addresses of the application backends as targets. This allows load balancing to an application backend hosted on any IP address and any interface on an instance. Each application hosted on the same instance can have an associated security group and use the same port. You can also use IP addresses as targets to load balance applications hosted in on-premises locations (over a Direct Connect or VPN connection), peered VPCs and EC2-Classic (using ClassicLink). The ability to load balance across AWS and on-prem resources helps you migrate-to-cloud, or failover-to-cloud.

• An Application Load Balancer requires you to specify more than one Availability Zone. You can distribute incoming traffic across your targets in multiple Availability Zones. An Application Load Balancer automatically scales its request handling capacity in response to incoming application traffic.

• Supports sticky sessions using load balancer generated cookies. If you enable sticky sessions, the same target receives the request and can use the cookie to recover the session context. Stickiness is defined at a target group level.

• You can create a listener with rules to forward requests based on the URL path. This is known as path-based routing. If you are running microservices, you can route traffic to multiple back-end services using path-based routing. For example, you can route general requests to one target group and requests to render images to another target group.

• You can use fixed-response actions to drop client requests and return a custom HTTP response. You can use this action to return a 2XX, 4XX, or 5XX response code and an optional message. When a fixed-response action is taken, the action and the URL of the redirect target are recorded in the access logs.

Network Load Balancer

• Load Balancer - The primary entry point that receives incoming TCP/UDP/TLS traffic. Distributes traffic to registered targets in a target group. 

• Listeners - Defines how the load balancer listens for incoming traffic. Each listener has:

  • Protocol: TCP, UDP, or TLS.

  • Port: The port on which the load balancer accepts traffic.

  • Rules: NLB does not support advanced routing rules like ALB, but it forwards traffic directly to targets.

• Target Groups - A logical collection of targets (EC2 instances, IP addresses, or Lambda functions). Each target group is associated with a protocol and port. Traffic is routed to only healthy targets. 

• Targets - The compute resources that receive traffic from NLB. Types of targets:

  • EC2 Instances (in different availability zones)

  • IP Addresses (IPv4 and IPv6)

  • AWS Lambda Functions

  • PrivateLink Endpoints (for handling internal traffic)

• Health Checks - Monitors the status of registered targets. NLB continuously performs health checks to ensure traffic is only forwarded to healthy instances. Health check settings:

  • Protocol: TCP, HTTP, HTTPS.

  • Interval: Frequency of health checks.

  • Threshold: Number of consecutive failures before marking a target as unhealthy.

• Elastic IP Addresses (EIP) - NLB provides a static IP address per availability zone. Helps in stable DNS resolution and whitelisting in firewalls. Supports BYOIP (Bring Your Own IP) for custom IPs. 

• Cross-Zone Load Balancing (Optional) - By default, NLB distributes traffic within a single Availability Zone. If enabled, it spreads traffic across all healthy targets in multiple AZs. 

• Connection Tracking - NLB uses flow hashing to maintain persistent TCP/UDP connections. Ensures that subsequent packets of the same connection go to the same target. 

• AWS PrivateLink Support - Allows NLB to act as a gateway for handling private traffic between VPCs or on-premises networks. 

• Works at Layer 4 (Transport Layer).

• Supports TCP, UDP, and TLS traffic.

• Provides ultra-low latency and can handle millions of requests per second.

• Best for high-performance applications and real-time data streaming.

• If extreme performance and static IP is needed for your application.

• Distributes traffic based on IP addresses and destination ports. Does not evaluate contents of the application layer but just route the requests to target groups.

• Network Load Balancer is capable of handling millions of requests per second while maintaining ultra-low latencies

• Network Load Balancer operates at the connection level (Layer 4), routing connections to targets - Amazon EC2 instances, microservices, and containers – within Amazon Virtual Private Cloud (Amazon VPC).

• Network Load Balancer is highly available. It accepts incoming traffic from clients and distributes this traffic across the targets within the same Availability Zone. The load balancer also monitors the health of its registered targets and ensures that it routes traffic only to healthy targets. When the load balancer detects an unhealthy target, it stops routing traffic to that target and reroutes traffic to remaining healthy targets. If all of your targets in one Availability Zone are unhealthy, and you have set up targets in another Availability Zone, Network Load Balancer will automatically fail-over to route traffic to your healthy targets in the other Availability Zones.

• Network Load Balancer automatically provides a static IP per Availability Zone (subnet) that can be used by applications as the front-end IP of the load balancer.

• If there are no healthy targets registered with the Network Load Balancer or if the Network Load Balancer nodes in a given zone are unhealthy, then Amazon Route 53 will direct traffic to load balancer nodes in other Availability Zones.

• In the event that your Network Load Balancer is unresponsive, integration with Route 53 will remove the unavailable load balancer IP address from service and direct traffic to an alternate Network Load Balancer in another region.

• Sticky sessions (source IP affinity) are a mechanism to route requests from the same client to the same target. Stickiness is defined at the target group level.

Gateway Load Balancer (GWLB)

• Works at Layer 3 (Network Layer).

• Routes traffic through third-party virtual appliances (firewalls, intrusion detection systems).

• Provides high availability and auto scaling for network security solutions.