AWS ELB and Application Load Balancers Explained

Elastic Load Balancing (ELB) is AWS's family of managed load balancers that distribute incoming traffic across targets such as EC2 instances, containers, IP addresses, and Lambda functions. When developers search for AWS ELB, they usually need to pick among Application Load Balancer (ALB), Network Load Balancer (NLB), and Gateway Load Balancer (GWLB)—or understand how an existing ALB listener rule affects their app.

This article explains each ELB type, common architecture patterns, and the configuration details that cause late-night pages.

Why load balancing exists in AWS

A single EC2 instance has one Availability Zone footprint and a finite CPU budget. Load balancers:

• Spread requests across healthy targets.
• Terminate TLS so backends speak HTTP internally.
• Integrate with Auto Scaling for replacement during failures.
• Expose stable DNS names while instances churn underneath.

AWS ELB is fully managed: AWS patches the data plane, scales capacity, and exposes metrics in CloudWatch.

The three load balancer types

Application Load Balancer (ALB)

Layer 7 (HTTP/HTTPS). Supports path-based routing (/api → service A, /static → service B), host-based routing (api.example.com), WebSockets, and HTTP/2.

Use ALB for: web apps, REST APIs, microservices behind path prefixes, containers on ECS/EKS.

Network Load Balancer (NLB)

Layer 4 (TCP/UDP/TLS). Ultra-low latency, static IP per AZ, preserves client IP, handles millions of requests per second.

Use NLB for: gaming, VoIP, high-throughput TCP services, TLS passthrough, when you need fixed IPs for firewall allowlists.

Gateway Load Balancer (GWLB)

Deploys third-party virtual appliances (firewalls, intrusion detection) transparently in the path. Niche but important for regulated network inspection.

Use GWLB for: centralized security appliances, not typical CRUD APIs.

Classic Load Balancer (CLB) is legacy—new designs should start with ALB or NLB.

How an ALB routes traffic

Key objects:

Object	Role
Listener	Port and protocol on the ALB (443 HTTPS)
Rules	Match host, path, headers; forward to target group
Target group	Collection of targets sharing health check settings
Target	EC2 instance ID, IP, Lambda ARN, or ECS task

Default action sends traffic to one target group. Rules evaluate by priority number (lower first).

Example rule set:

1. Host = api.example.com AND Path = /v2/* → tg-api-v2
2. Host = api.example.com → tg-api-v1
3. Default → fixed 404 response

Health checks that actually work

Unhealthy targets stop receiving traffic. Common misconfigurations:

• Health check path hits / which redirects to login (302 counted as failure).
• Check port mismatches application port.
• Threshold too aggressive during slow startup (increase healthy threshold or use slow start on target group).

For containers, point checks at a dedicated /healthz that verifies database connectivity if that defines "healthy" for your SLA.

TLS and certificates

ALB terminates HTTPS with ACM certificates. Attach multiple certs with SNI for multi-domain routing. Redirect HTTP listener 80 → 443 with a simple rule.

Internal ALBs use private subnets and internal DNS names—still encrypt between client and ALB even inside a VPC when required by policy.

AWS ELB with ECS and EKS

ECS: Service connects to target group; tasks register automatically. Set deregistration delay so in-flight requests finish during deploys.

EKS: AWS Load Balancer Controller creates ALB/NLB from Ingress or Service annotations. Annotation typos are a frequent source of "Ingress pending forever."

Auto Scaling integration

Register Auto Scaling groups with target groups. On instance launch, lifecycle hooks can delay registration until boot scripts finish. Scale on ALB RequestCountPerTarget for better signal than CPU alone on I/O-bound APIs.

NLB specifics developers overlook

• NLB can target ALB in some architectures (NLB for static IP → ALB for path routing).
• Client IP preservation uses Proxy Protocol v2—your app must parse it if you log real client addresses.
• TLS listeners on NLB terminate TLS at layer 4; you lose HTTP-level routing unless you chain to ALB.

Observability

CloudWatch metrics: TargetResponseTime, HTTPCode_Target_5XX_Count, UnHealthyHostCount, RejectedConnectionCount.

Enable access logs to S3 when debugging routing rules or abusive clients. ALB access logs are verbose; lifecycle policies prevent runaway storage bills.

Security groups and networking

ALB security groups must allow inbound 443 from the internet (or CloudFront). Target security groups must allow inbound only from the ALB security group on the application port—not from 0.0.0.0/0.

For internal services, place ALB in public subnets (if internet-facing) or private subnets (internal ALB) per your topology; targets usually live in private subnets without public IPs.

Cost levers

Charges include LCU (Load Balancer Capacity Units) consumption based on connections, rules evaluated, and bandwidth. Reduce cost by:

• Consolidating micro-ALBs where routing rules suffice.
• Deleting unused target groups and listeners.
• Choosing NLB only when ALB features are unnecessary—NLB LCUs differ from ALB LCUs.

Troubleshooting checklist

1. Target shows unhealthy → curl health path from a bastion in the same VPC.
2. 502 Bad Gateway → target closed connection; check app listening port and idle timeout (ALB default 60s).
3. 504 Gateway Timeout → app too slow; tune target timeout or fix backend.
4. Wrong service → rule priority or Host header mismatch; use curl -H "Host: ..." to reproduce.
5. Intermittent failures after deploy → deregistration delay too low or connection draining skipped.

Weighted routing and gradual cutovers

Pure blue-green is a 100/0 flip, but ALB weighted target groups allow 90/10 then 50/50 before full promotion—a poor person's canary without a service mesh. Start sending internal QA traffic to green via a separate listener rule (Header: X-Internal-Test: 1) before external users move.

Document weight changes in IaC pull requests so every traffic shift has review history.

Connection idle timeouts and WebSockets

ALB idle timeout defaults to 60 seconds. Long-polling and WebSocket apps need aligned timeouts on ALB, target group, and application server (Nginx proxy_read_timeout, Node HTTP keep-alive). Mismatch manifests as random disconnects that look like application bugs.

For WebSockets, enable stickiness on the target group if your app keeps connection state in memory—otherwise connections jump targets mid-session.

IPv6 and dual-stack setups

Internet-facing ALBs can expose AAAA records. Ensure security groups and backend apps listen on IPv6 if you enable dual-stack publicly. Mixed IPv4-only targets behind IPv6 listeners cause confusing partial outages.

WAF integration

AWS WAF attaches to ALB or CloudFront. Place rate-based rules before traffic hits expensive compute. Log sampled requests to analyze false positives before switching from count mode to block mode.

Multi-account and shared VPC patterns

Enterprise landing zones often deploy ALBs per account with centralized networking. RAM-shared subnets and centralized DNS (Route 53 profiles) complicate security group references—use prefix lists or security group referencing consistently in Terraform modules so platform teams do not hand-edit rules per service.

Hands-on lab suggestion

In a sandbox VPC:

1. Launch two EC2 instances with a simple HTTP server returning distinct version strings.
2. Create target groups tg-a and tg-b.
3. Add ALB listener rules to switch default forward action.
4. Observe CloudWatch UnHealthyHostCount when you stop nginx on one instance.

Twenty minutes of this lab prevents hours of production confusion later.

FAQ

What is the difference between AWS ELB and ALB?
ELB is the product family; ALB is one member optimized for HTTP routing.

Can ALB invoke Lambda?
Yes, as a target type—useful for lightweight APIs without always-on compute.

Should I use one ALB per microservice?
Often one ALB per environment with path/host rules is simpler and cheaper unless blast-radius isolation demands separation.

How does AWS ELB relate to CloudFront?
CloudFront caches at the edge; ALB routes to origin compute. Many stacks use CloudFront → ALB → ECS/EC2.

Closing notes

AWS ELB is the traffic steering layer most production web stacks depend on. Pick ALB for HTTP semantics, NLB for raw throughput and static IPs, and invest time in health checks, security group least privilege, and observable access logs. Those boring details separate smooth deploys from mysterious 502s.