Elastic Load Balancing

First PublishedMar 30, 2026Last UpdatedApr 6, 2026ByAtif Alam

Elastic Load Balancing (ELB) distributes incoming traffic across targets in one or more Availability Zones.

VPC basics and security groups are in Networking. TLS attachment patterns are in TLS and Certificates. HTTP semantics at the edge are in HTTP for Operators. DNS in front of load balancers is in Route 53.

Load Balancer Types

Type	Layer	Typical use
ALB (Application Load Balancer)	HTTP/HTTPS (L7), WebSocket	Path/host routing, gRPC, Lambda targets, integration with WAF
NLB (Network Load Balancer)	TCP, UDP, TLS (L4)	Extreme throughput, low latency, static IPs per AZ, preserve client IP
GWLB (Gateway Load Balancer)	IP (L3)	Inline virtual appliances (firewalls, IDS) via GENEVE encapsulation

Classic Load Balancer (CLB) is legacy; prefer ALB or NLB for new designs.

Choosing Between ALB and NLB

ALB terminates and routes HTTP/HTTPS traffic (L7). NLB forwards TCP and UDP (and TLS at the listener) with an L4 mindset. Use ALB when the load balancer must understand requests; use NLB when ports, throughput, latency, or stable IPs matter most.

Application Load Balancer

Choose ALB for HTTP-aware behavior at the edge.

• Listener rules for host, path, header, method, and query string.
• HTTPS termination, HTTP/2, gRPC, and WebSockets for typical web and API stacks.
• Targets: instances, IP addresses, Lambda functions, or another ALB.
• AWS WAF integration on the load balancer.

ALB is a poor fit for arbitrary non-HTTP TCP/UDP workloads (prefer NLB) and does not offer static Elastic IPs on the balancer itself—clients resolve DNS to nodes that can change; use NLB when you need fixed public IPs per AZ.

Network Load Balancer

Choose NLB for connection-level distribution and peak L4 performance.

• TCP and UDP listeners; TLS on the listener when you terminate encryption at the NLB.
• Very high connection volume, low latency, and optional Elastic IP per AZ for allowlists.
• Preserve client IP to targets when your design enables it.
• Targets: instances, IP addresses, or an ALB (NLB in front of ALB is a common split).

You do not get path- or host-based HTTP routing on the NLB itself. WAF is not attached to NLB the way it is to ALB—front with ALB or CloudFront if you need L7 filtering. Lambda is not a direct NLB target type.

Rule of thumb

HTTP routing or WAF at the edge → ALB. L4 traffic, static IPs, or non-HTTP protocols → NLB.

Core Concepts (ALB / NLB)

Concept	Meaning
Listener	Accepts connections on a port/protocol (e.g. HTTPS:443).
Rule (ALB)	Evaluates host, path, header, etc., and forwards to a target group.
Target group	Set of targets (instance ID, IP, Lambda, ALB) + health check settings.
Health check	LB probes targets; unhealthy targets stop receiving new connections.
Deregistration delay	Time to drain in-flight requests before removing a target.

Place the load balancer in public subnets (internet-facing) or private subnets (internal). Subnets must span at least two AZs for a standard ELB setup.

Security Groups

• Internet-facing ALB/NLB — Listener SG allows 443/80 from the internet (or known CIDRs).
• Targets (EC2/ECS tasks) — Allow traffic from the load balancer’s security group on the application port, not from 0.0.0.0/0.
• Misconfigured egress on targets or ingress on the LB is a top cause of 502/504 or timeouts.

ALB Setup Outline (CLI Sketch)

1. ALB — Create an application load balancer in at least two subnets with a security group for the listener.
2. Target group — Create a target group (protocol, port, VPC, target type) and configure the health check (for example path and interval).
3. Targets — Register targets (instances, IPs, etc.) with the target group.
4. Listener — Create an HTTPS listener (or HTTP for lab use) with a certificate and a default action that forwards to the target group.

# Application load balancer in two public subnets
aws elbv2 create-load-balancer --name my-alb --type application \
  --subnets subnet-a subnet-b --security-groups sg-alb

aws elbv2 create-target-group --name my-tg --protocol HTTP --port 8080 \
  --vpc-id vpc-xyz --target-type ip \
  --health-check-path /health --health-check-interval-seconds 30

aws elbv2 register-targets --target-group-arn arn:aws:... \
  --targets Id=i-abc Id=i-def

aws elbv2 create-listener --load-balancer-arn arn:aws:...alb \
  --protocol HTTPS --port 443 \
  --certificates CertificateArn=arn:aws:acm:...cert \
  --default-actions Type=forward,TargetGroupArn=arn:aws:...tg

Add listener rules for path- or host-based routing beyond the default action.

NLB Setup Outline (CLI Sketch)

1. NLB — Create a network load balancer in at least two subnets; set scheme to internet-facing or internal as needed.
2. Target group — Create a TCP or UDP target group (VPC, target type) and configure health checks (for example TCP to the traffic port, or HTTP(S) where you use those probe types).
3. Targets — Register targets (instances, IPs, etc.) with the target group.
4. Listener — Create a TCP or TLS listener on the client-facing port; for TLS, attach an ACM certificate in the region and use a default forward action to the target group.

# Network load balancer in two subnets (optional security groups where your account/VPC supports them)
aws elbv2 create-load-balancer --name my-nlb --type network \
  --scheme internet-facing \
  --subnets subnet-a subnet-b

aws elbv2 create-target-group --name my-nlb-tg --protocol TCP --port 8080 \
  --vpc-id vpc-xyz --target-type instance \
  --health-check-protocol TCP --health-check-port traffic-port

aws elbv2 register-targets --target-group-arn arn:aws:... \
  --targets Id=i-abc Id=i-def

# TLS terminates at the NLB; targets often use plain TCP on the target group port
aws elbv2 create-listener --load-balancer-arn arn:aws:...nlb \
  --protocol TLS --port 443 \
  --certificates CertificateArn=arn:aws:acm:...cert \
  --default-actions Type=forward,TargetGroupArn=arn:aws:...tg

NLB has no L7 routing rules like an ALB; optional static Elastic IPs per AZ, client IP preservation, and cross-zone load balancing are summarized in NLB Highlights.

NLB Highlights

• Static Elastic IP per AZ optional — useful for allowlists.
• TLS termination on NLB is supported in many designs; certificate management still ties to ACM in-region.
• Preserve client IP — targets see the real source when configured; differs from SNAT-heavy ALB paths.
• Cross-zone load balancing — When enabled, NLB can send traffic to targets in any AZ (data charges apply); know your team’s default.

Sticky Sessions (Session Affinity)

ALB can enable stickiness so the same client maps to the same target (cookie-based). Use when the app keeps local session state; prefer stateless apps + shared session store when possible.

Idle Timeouts

ALB has a configurable idle timeout for HTTP connections. Mismatches with client, server, or keep-alive settings cause 502 or abrupt closes. Align timeouts with HTTP for Operators guidance.

Troubleshooting

Symptom	Checks
All targets unhealthy	Health check path/port/protocol matches the app; security group target ← LB; app listens on correct interface (0.0.0.0 vs 127.0.0.1).
502 Bad Gateway	Target closed connection, wrong protocol (HTTP vs HTTPS to target), or oversized headers. Check ALB access logs and target logs.
503 / no healthy hosts	Every target failed health check — fix app or relax check temporarily for triage only.
504 Gateway Timeout	Target slow or not responding within idle window; NAT or upstream issues.
Intermittent failures	Cross-AZ routing without cross-zone enabled; AZ impairment; connection draining.
TLS errors at client	Wrong certificate, SNI, or security policy on listener.

Use CloudWatch metrics: TargetResponseTime, HTTPCode_Target_5XX_Count, RejectedConnectionCount, HealthyHostCount.

EKS and the AWS Load Balancer Controller

On EKS, front-door traffic is usually wired through one of two different Kubernetes resources. You do not set ingressClassName on a Service; that field exists only on an Ingress. A single workload might use one pattern or the other (or advanced combinations), but each line below is its own API and controller path.

Service with type: LoadBalancer (L4, Often NLB)

A Service manifest sets spec.type: LoadBalancer. The cloud integration provisions an AWS load balancer that targets that Service’s endpoints. In many EKS setups the result is an NLB (sometimes a CLB in older configurations); exact behavior depends on annotations, add-ons, and Kubernetes/AWS versions—not on Ingress.

Typical use: expose one Service on a TCP/UDP (or TLS-at-L4) front door without HTTP routing rules at the load balancer.

Ingress with ingressClassName: alb (L7, ALB)

An Ingress is a separate object. With the AWS Load Balancer Controller installed, spec.ingressClassName: alb (or the equivalent legacy annotation) tells that controller to create or update an ALB whose listeners and rules reflect the Ingress spec (host, path, TLS, and so on).

Backend Services referenced by the Ingress are usually ClusterIP; the ALB sends traffic to pod targets (or instance targets, depending on how you annotate). You are not required to also set those backends to type: LoadBalancer—that would create a second, separate cloud load balancer.

TargetGroupBinding

TargetGroupBinding is a CRD from the same controller ecosystem: attach existing ELB target groups to Kubernetes Services (migration, hybrid, or custom integration scenarios).

See Kubernetes Networking and EKS.

Global Accelerator (Brief)

Global Accelerator provides static Anycast IPs at the edge and routes traffic over the AWS backbone to regional endpoints (ALB, NLB, EC2). Compare with NLB static IPs when comparing options for global entry and DDoS resilience — different product, similar “stable front door” story.

VPC Reachability Analyzer

For “can A reach B on port X?” without packet capture, use VPC Reachability Analyzer in the console or API. It complements Flow Logs and Network RCA (what happened) vs synthetic path checks (is path possible given SG/NACL/route).

Related

• Networking — VPC, subnets, SG, NACL.
• Network troubleshooting flow — Ordered RCA.
• Monitoring — CloudWatch for ELB metrics.