AWS Load Balancer Explained: ALB, NLB, and Traffic

Quick Answer

An AWS load balancer automatically distributes incoming client traffic across multiple targets, such as EC2 instances and containers, across single or multiple Availability Zones. To use one effectively, you provision an Application Load Balancer (ALB) for HTTP/HTTPS traffic requiring URL path or host-based routing, or a Network Load Balancer (NLB) for high-throughput, low-latency TCP, UDP, or TLS traffic. You define listeners to inspect incoming connection requests on specific ports and protocols, forward traffic to target groups, and rely on automated health checks to bypass unresponsive endpoints seamlessly. This setup decouples your public entry points from backend application servers, ensuring zero-downtime deployments, automatic failover, and scalable cloud application performance.

What Is an AWS Load Balancer?

AWS Elastic Load Balancing (ELB) is a fully managed service that automatically distributes incoming application traffic across multiple targets. At a high level, the load balancer accepts client connections, evaluates request parameters or connection streams against listener rules, and forwards the packets to registered backend targets within designated virtual private cloud (VPC) subnets.

From a developer and DevOps architecture perspective, ELB removes the operational burden of managing software-based proxies like Nginx or HAProxy on standalone virtual machines. It provides automatic scaling, integrated security features, robust monitoring via Amazon CloudWatch, and native integration with Auto Scaling groups. When traffic spikes due to flash sales or viral usage, the load balancing infrastructure scales transparently to absorb the load without manual intervention.

Furthermore, an AWS load balancer acts as a security boundary. By centralizing incoming traffic handling, you can enforce strict security groups, integrate AWS Web Application Firewall (WAF) to block malicious traffic patterns, and offload resource-intensive cryptographic tasks such as SSL/TLS handshake processing away from your core backend application servers.

ALB vs NLB

Choosing the right load balancer variant is critical for application performance. AWS offers distinct load balancer types tailored to specific network layers and use cases. Understanding the differences between an application load balancer and a network load balancer prevents architectural bottlenecks down the line.

ALB

The Application Load Balancer operates at Layer 7 (the application layer) of the OSI model. It is specifically designed for HTTP and HTTPS traffic, offering advanced routing and load-balancing features that are aware of application content. With an application load balancer, you can inspect incoming headers, query parameters, host names, and URI paths to direct traffic intelligently.

This makes ALB the ideal choice for modern microservices and containerized applications running on Amazon ECS, EKS, or standard EC2 instances. For instance, you can route requests matching /api/users* to a dedicated user service target group, while routing requests matching /images/* to an object-storage proxy or a separate media rendering service. Additionally, ALB supports HTTP/2 and WebSocket protocols natively, enabling bi-directional communication channels for real-time dashboards and chat applications.

NLB

The Network Load Balancer operates at Layer 4 (the transport layer) of the OSI model. When your workload demands handling millions of requests per second with ultra-low latencies while maintaining jitter-free packet delivery, the Network Load Balancer is the definitive choice.

Unlike its Layer 7 counterpart, NLB can handle sudden and volatile traffic spikes without warming up. It utilizes a flow hash algorithm based on protocol, source IP, source port, destination IP, and destination port to route TCP, UDP, and TLS traffic. Because it operates at the transport layer, NLB preserves the original client source IP address through to your backend targets, which is vital for security auditing, compliance logging, and geo-location tracking in high-performance networking stacks.

Listeners and Target Groups

An AWS load balancer cannot forward traffic in a vacuum; it requires configured listeners and target groups to function correctly. A listener is a logical process that checks for connection requests using the port and protocol you configure. Rules you define for a listener determine how the load balancer routes requests to its registered targets.

When a client sends a request to your load balancer endpoint, the listener evaluates the rules in priority order. If a rule matches—such as a specific host header or URL path—the load balancer forwards the request to the designated target group associated with that rule. If no custom rules match, a default action rule takes over, typically forwarding traffic to a fallback target group or returning an HTTP error code.

Target groups

Target groups route requests to one or more registered targets using specified protocols and port numbers. Every target group you create acts as a logical pool of backend resources, which can include EC2 instances, IP addresses within your VPC, Lambda functions, or containers managed by ECS tasks.

Key configuration parameters for target groups include:

• Protocol and Port: Define how the load balancer communicates with backend targets (e.g., forwarding HTTP traffic on port 80 or secure gRPC on port 50051).
• Target Type: Specify whether targets are registered by instance ID, IP address, or Lambda function ARN.
• Deregistration Delay: Control the grace period (ranging from 0 to 3600 seconds) that allows ongoing in-flight requests to complete before an instance is deregistered or terminated.
• Routing Algorithm: Choose between Round Robin for equal distribution or Least Outstanding Requests for unevenly sized workloads.

Health Checks

Automated health checks are the heartbeat of a reliable load-balanced architecture. An AWS load balancer continuously monitors the health of all registered targets within its target groups by sending periodic probe requests to each target's designated health check endpoint.

If a target fails to respond successfully within the configured timeout threshold or returns an unexpected HTTP status code, the load balancer marks that target as unhealthy. It immediately stops routing new client connections to that compromised instance until it recovers and passes subsequent health checks. This self-healing mechanism ensures that broken application nodes or crashing container tasks never impact end-user experience.

Health checks

Configuring robust health checks requires tuning several granular parameters to prevent false positives while ensuring rapid failure detection:

• Health Check Path: The URI endpoint queried by the load balancer (e.g., /healthz or /status). Ensure this endpoint performs lightweight validation without hitting heavy database queries.
• Interval: The approximate time interval (in seconds, typically 30s) between health checks.
• Timeout: The amount of time (in seconds) during which no response from a target means a failed check.
• Healthy Threshold: The number of consecutive health check successes required before an unhealthy target is declared healthy.
• Unhealthy Threshold: The number of consecutive health check failures required before a healthy target is marked unhealthy.
• Matcher: The acceptable HTTP status codes (e.g., 200-299) that indicate a successful response.

TLS

Securing data in transit is non-negotiable for production cloud environments. AWS load balancers provide native TLS (Transport Layer Security) offloading and termination, simplifying certificate management and reducing computational overhead on backend servers.

When clients establish an HTTPS connection with your load balancer, the load balancer handles the complex cryptographic TLS handshake, negotiates cipher suites, and decrypts incoming traffic before forwarding unencrypted or re-encrypted packets to backend targets. This centralization eliminates the need to install, renew, and manage SSL certificates across dozens of individual EC2 instances or container fleets.

TLS listener

Setting up a secure TLS listener involves attaching an SSL/TLS certificate managed by AWS Certificate Manager (ACM) or imported into IAM. ACM provides free public SSL/TLS certificates with automated renewal, making certificate lifecycle management effortless.

When configuring a TLS listener on your ALB or NLB, you define:

• Port: Typically port 443 for secure web traffic.
• SSL Certificate: The primary ACM certificate ARN attached to the listener.
• Security Policy: A predefined set of cipher suites and protocols (such as ELBSecurityPolicy-TLS13-1-2-2021-06) that restrict weak cryptographic algorithms and enforce modern security baselines.
• SNI (Server Name Indication): The ability to attach multiple SSL certificates to a single listener, allowing a single load balancer to serve different domains securely.

Deployment Example

Implementing an AWS load balancer via the AWS CLI allows DevOps teams to automate infrastructure provisioning reliably. Below is a complete, step-by-step walkthrough for creating a secure Application Load Balancer, setting up a target group, registering an EC2 instance, and verifying connectivity.

First, create your application load balancer within your target VPC subnets:

aws elbv2 create-load-balancer \
    --name production-web-alb \
    --subnets subnet-0123456789abcdef0 subnet-0fedcba9876543210 \
    --security-groups sg-0123456789abcdef0 \
    --scheme internet-facing \
    --type application

Next, create a target group configured for HTTP traffic on port 80:

aws elbv2 create-target-group \
    --name web-app-tg \
    --protocol HTTP \
    --port 80 \
    --vpc-id vpc-0123456789abcdef0 \
    --target-type instance \
    --health-check-path /healthz \
    --health-check-interval-seconds 30

Register your backend EC2 instance with the newly created target group:

aws elbv2 register-targets \
    --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/web-app-tg/abcdef123456 \
    --id i-0123456789abcdef0

Finally, create a listener on port 80 to forward incoming traffic to your target group:

aws elbv2 create-listener \
    --load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/production-web-alb/abcdef123456 \
    --protocol HTTP \
    --port 80 \
    --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/web-app-tg/abcdef123456

Verify that your targets are healthy by running the target health description check:

aws elbv2 describe-target-health \
    --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/web-app-tg/abcdef123456

Expected output should display TargetHealth.State as healthy once your application service successfully responds to probe requests.

Common Mistakes

Misconfiguring an AWS load balancer can lead to silent downtime, security vulnerabilities, and difficult troubleshooting sessions. Being aware of these common pitfalls helps engineering teams maintain robust cloud infrastructure.

One frequent mistake is using overly broad security group permissions, such as allowing inbound traffic on all ports from 0.0.0.0/0 directly to backend EC2 instances instead of restricting traffic exclusively to the load balancer's security group. Another common error is configuring health check paths that query heavy database operations or external APIs; if dependencies fail, the health check fails, causing the load balancer to deregister healthy instances in a cascading failure loop.

Additionally, developers often forget to configure idle timeout settings correctly for long-lived WebSocket connections, leading to premature connection drops. Finally, failing to monitor load balancer error metrics (like HTTP 5xx spikes) in Amazon CloudWatch leaves teams blind to underlying application performance degradation.