Elastic Load Balancing (ELB): Distribute Traffic — ALB, NLB, CLB Types | Focus: Elastic Load Balancing

Elastic Load Balancing (ELB): Distribute Traffic — ALB, NLB, CLB Types

Focus Keyword: Elastic Load Balancing

Short URL / slug: /elastic-load-balancing-alb-nlb-clb

Introduction to Elastic Load Balancing (ELB)

Elastic Load Balancing (ELB) is AWS’s managed service family that automatically distributes incoming application or network traffic across multiple targets — such as EC2 instances, containers (ECS/EKS), IP addresses, and Lambda functions — to provide high availability and fault tolerance.

Key points

ELB supports ALB (Layer 7), NLB (Layer 4) and the legacy CLB.
Integrates with Auto Scaling, ECS, EKS, AWS Lambda, WAF, and Shield.
Automates scaling and health checks; it’s regional and can work across Availability Zones.

Internal link: Learn more on our site: Elastic Load Balancing resources at cloudknowledge.in.

Why Load Balancing is Critical

Load balancing is the backbone of resilient distributed systems. It prevents single points of failure, improves response times, centralizes TLS termination, and enables deployment strategies such as blue/green and canary rollouts.

Key points

Prevents single point of failure by routing around unhealthy targets.
Improves throughput & latency through efficient connection management.
Makes operational tasks (cert rotation, scaling, deployment) simpler.

Types of AWS Elastic Load Balancers

AWS ELB family has three main types: Application Load Balancer (ALB), Network Load Balancer (NLB), and Classic Load Balancer (CLB). Choose the right type based on protocol layer, routing needs, and performance.

Application Load Balancer (ALB) — Layer 7

ALB operates at HTTP/HTTPS (Layer 7). It is designed for modern application architectures—microservices and containerized apps—providing advanced routing and authentication features.

ALB Key points

Host-based & path-based routing: route by hostname and URL path.
Native WebSocket & HTTP/2 support.
Integrates with OIDC, AWS Cognito, and third-party identity providers for authentication.
Works with target groups that include EC2, IP, and Lambda targets.
Supports WAF and per-rule evaluation (affects LCUs).

When to use ALB: REST APIs, microservices, modern web apps, containerized services on ECS/EKS, WebSocket apps.

ALB — Frequently Asked Questions (FQUs)

Q: Can ALB terminate TLS? A: Yes — ALB can terminate TLS and forward traffic to targets over HTTP or HTTPS.
Q: Does ALB support sticky sessions? A: Yes — cookie-based stickiness is supported per target group.

Network Load Balancer (NLB) — Layer 4

NLB operates at the transport layer (TCP/UDP). It delivers extremely high performance with ultra-low latency and static IP support.

NLB Key points

Handles millions of requests per second with low latency.
Provides static IP addresses / Elastic IP per AZ.
Supports TLS pass-through or TLS termination (with TLS listeners).
Source IP preservation enables client IP visibility on targets.

When to use NLB: Real-time systems (gaming, VoIP), high-throughput workloads, hybrid/on-prem connectivity, and use cases requiring static IPs or direct client IP preservation.

NLB — Frequently Asked Questions (FQUs)

Q: Can NLB preserve the client source IP? A: Yes — NLB preserves source IP (useful for IP-based filtering at the target).
Q: Is there TLS support? A: NLB supports TLS termination (TLS listeners) in addition to pass-through mode.

Classic Load Balancer (CLB) — Legacy

CLB was the original AWS load balancer that supports both HTTP(S) and TCP. AWS recommends migrating workloads from Classic to ALB or NLB depending on requirements.

CLB Key points

Supports both Layer 4 and Layer 7 but lacks modern routing features.
Best kept only for legacy apps that cannot be replaced immediately.

CLB — Frequently Asked Questions (FQUs)

Q: Should I still use CLB? A: Only for legacy workloads. For new projects use ALB/NLB.

Key Features Across ELB

Health checks (HTTP, HTTPS, TCP) — automatic detection and removal of unhealthy targets.
Cross-zone load balancing — evenly distributes traffic across AZs.
Connection draining (deregistration delay) — gracefully remove targets.
Security integrations — IAM, security groups, TLS termination, AWS WAF (ALB), AWS Shield.
Access logs and metrics via CloudWatch and S3.
IPv6 support — dual-stack listeners where supported.

Quick tip: Use per-target-group health checks tuned to the app’s readiness endpoint (e.g., /healthz) to avoid false positives.

Common Use Cases

ALB Use Cases

Routing requests to microservice endpoints (host/path based).
Authenticating users via OIDC / Cognito before forwarding to services.
Serverless HTTP endpoints routing to Lambda functions.

NLB Use Cases

High-performance TCP workloads (financial trading, gaming backends).
Preserving client IP for logging or firewall rules at the target.
Load balancing to on-prem servers using static IP targets.

CLB Use Cases

Legacy apps still running on older EC2-only setups.

ELB with the AWS Ecosystem

ELB integrates tightly with Auto Scaling, Elastic Container Service (ECS), Elastic Kubernetes Service (EKS), Route 53, AWS WAF, CloudWatch, and VPC features. This makes it possible to create end-to-end resilient deployment pipelines.

Examples:

Auto Scaling + ALB: new instances automatically register with target groups.
ECS + ALB: dynamic port mapping for tasks — ALB routes to the ephemeral ports used by containers.
Route 53 health checks + ALB for active-passive failover patterns.

Target Groups & Routing

ALB and NLB use target groups to represent logical sets of endpoints. Target groups allow per-group health checks, stickiness, and advanced routing.

Target group features

Targets: EC2, IP addresses, Lambda.
Health checks: configure protocol, path, timeout, threshold.
Weighted targets: support for traffic splitting/A-B testing via target weights (ALB supports weighted target groups in certain patterns).
Port mapping: ECS can register tasks with unique ports per task.

Target Groups FQUs

Q: How do I debug an unhealthy target? A: Check health check configuration, security group/ACL rules, and application readiness endpoints.

Sticky Sessions

Sticky sessions (session affinity) keep a client routed to the same target for a period of time.

ALB: cookie-based stickiness (application cookie or ALB-generated cookie).
NLB: source IP-based stickiness.

Use sticky sessions only when necessary — they can reduce the ability for a load balancer to evenly distribute load.

Security Enhancements

Security is a primary concern—ELB supports TLS termination, forward secrecy, integration with AWS Certificate Manager (ACM), and can be fronted by AWS WAF for layer-7 protections.

TLS offloading: terminate TLS at ALB or perform pass-through at NLB.
Use ACM for certificate lifecycle management and automatic renewals.
WAF for OWASP rule sets and custom rules to block malicious traffic.
Shield for DDoS protection with higher tiers for enterprise protections.

Pricing Considerations

ELB pricing has multiple components: per-hour load balancer charges, per-LCU charges (ALB), and data processed. NLB pricing is dominated by data processed and per-hour/GB charges; ALB uses LCUs (which measure new connections, active connections, processed bytes, and rule evaluations).

Tips to manage costs:

Right-size listeners & rules — complex rule sets increase LCU usage.
Use cross-zone balancing carefully—there may be data transfer implications.
Monitor metrics and enable cost alerts in AWS Budgets.

Performance Differences

ALB is feature-rich (Layer 7) and excellent for routing and advanced features; NLB is high-throughput and low-latency for TCP/UDP. CLB is legacy and generally less performant and flexible than ALB/NLB.

Choose NLB for raw throughput and static IP requirements.
Choose ALB for content-aware routing and modern app patterns.

Migration Recommendations

Plan migrations by mapping CLB capabilities to ALB or NLB.

For HTTP/HTTPS with routing rules → migrate to ALB.
For TCP high-throughput workloads → migrate to NLB.
For hybrid architectures consider ALB+NLB together (ALB for web routing, NLB for raw TCP/UDP).

Migration checklist

Inventory current listeners, security groups, SSL/TLS certs.
Map CLB listener ports to ALB/NLB listener types.
Test in a staging environment with production-like traffic patterns.
Validate health check endpoints and deregistration delays.

Multi-AZ and High Availability

ELB distributes traffic across AZs automatically when targets are present in each AZ — ensuring resilience against AZ-level failures. Use cross-zone load balancing to even out distributions when needed.

Always provision targets in multiple AZs for high availability.
Combine Route 53 failover policies with health checks for global failover.

Integration with Hybrid and On-Prem

NLB supports IP targets which can be on-prem servers — enabling hybrid forwarding. ALB supports internal load balancers and PrivateLink for private connectivity between VPCs & services.

Observability & Logging

Key observability tools: CloudWatch metrics (HTTP codes, latency, active connections), access logs for ALB/CLB stored in S3, and VPC Flow Logs. Use these to detect anomalies and troubleshoot.

Enable access logs for forensic and traffic analysis.
Set CloudWatch alarms on unhealthy target counts and 5xx error spikes.
Use X-Forwarded-For headers for client IP tracking (ALB inserts it).

Troubleshooting: PowerShell, AWS CLI & Scripts

This section contains practical scripts you can use to inspect ELB configuration, target health, and perform quick remediation. Replace placeholders (like my-load-balancer, my-target-group, us-east-1) with values for your environment.

AWS CLI - List load balancers and describe attributes

# List all load balancers
aws elbv2 describe-load-balancers --region us-east-1

# Describe listeners for a specific load balancer
aws elbv2 describe-listeners --load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/my-alb/50dc6c495c0c9188 --region us-east-1

# Describe target health
aws elbv2 describe-target-health --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-targets/73e2d6bc24d8a067 --region us-east-1

PowerShell using AWS Tools for PowerShell

# Requires AWS Tools for PowerShell (Install-Module -Name AWSPowerShell.NetCore)
# List Load Balancers
Get-ELB2LoadBalancer -Region us-east-1

# Get Listeners for ALB
Get-ELB2Listener -LoadBalancerArn 'arn:aws:elasticloadbalancing:us-east-1:...:loadbalancer/app/my-alb/...' -Region us-east-1

# Get target health
Get-ELB2TargetHealth -TargetGroupArn 'arn:aws:elasticloadbalancing:us-east-1:...:targetgroup/...' -Region us-east-1

Bash script: Check target health and unhealthy targets

#!/bin/bash
REGION="us-east-1"
TG_ARN="arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-targets/..."
aws elbv2 describe-target-health --target-group-arn $TG_ARN --region $REGION \
  --query 'TargetHealthDescriptions[?TargetHealth.State!=`healthy`]' --output table

Common troubleshooting steps (checklist)

Verify security groups: allow traffic from load balancer to target ports and from clients to the load balancer listeners.
Check target group health checks: ensure the correct protocol, path, port and thresholds.
Check application logs for errors on the target instances.
Use access logs and CloudWatch metrics to find spikes of 5xx errors.
Ensure TLS certificates are valid in ACM if TLS termination is used.

Advanced: Simulate traffic with curl (quick health probe)

# From a bastion host inside your VPC, simulate the health check
curl -I http://10.0.1.24:8080/healthz
# Expect HTTP/200 to be returned for a "healthy" endpoint

Programmatic checks using Python (boto3)

import boto3

client = boto3.client('elbv2', region_name='us-east-1')
tg_arn = 'arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/example/abc'
resp = client.describe_target_health(TargetGroupArn=tg_arn)
for t in resp['TargetHealthDescriptions']:
    print(t['Target']['Id'], t['TargetHealth']['State'], t['TargetHealth'].get('Reason',''))

If targets are unhealthy, check application responsiveness, port binding, and firewall rules (security groups / NACLs).

Example: Re-register a failed target using AWS CLI

aws elbv2 register-targets --target-group-arn $TG_ARN --targets Id=i-0123456789abcdef0,Port=80 --region us-east-1

Frequently Asked Questions (FAQs)

Q1: What ELB type should I choose for a REST API?

A: ALB is usually the right choice due to path-based and host-based routing, built-in HTTP features and WAF integration.

Q2: How do I preserve client IPs?

A: Use NLB for source IP preservation, or configure proxy protocol on CLB if needed (and supported by your application).

Q3: Can I use ALB + NLB together?

A: Yes. A common pattern is ALB for Layer 7 routing and NLB for low-level TCP traffic or when static IPs are required.

Q4: How are ELB health checks charged?

A: Health checks themselves are not billed separately but are factored into LCU calculations for ALB and data processing for NLB. Monitor costs with AWS Cost Explorer.

Applied SEO Checklist (this content implements the requirements)

Focus Keyword placed in SEO title, meta description, URL slug (/elastic-load-balancing-alb-nlb-clb), and at top of content.
Keyword density: approximate — aim for ~1% across the page (you can use Content AI or SEO plugin to fine-tune).
Content length: This is a long-form comprehensive article — expand sections to reach your target word count (15,000+ if needed) by adding deeper labs, diagrams, and real-world case studies.
Headings: H1, multiple H2/H3/H4 used — focus keyword used in H1 and several H2/H3s.
Images: Add images with alt="Elastic Load Balancing" (example placeholders below).
Internal links: Provided to cloudknowledge.in keyword pages.
External links: Provided to AWS official documentation (DoFollow links).
Readability: Short paragraphs, bullet lists, FAQ, and TOC added for UX.

Image placeholders (add real royalty-free images in WP media library):

Alt text: Elastic Load Balancing

Suggested image captions & alt texts

Diagram: ELB architecture — alt="Elastic Load Balancing architecture diagram"
ALB routing example — alt="Application Load Balancer routing example"

Conclusion & Next Steps

Elastic Load Balancing is a core building block for resilient, scalable cloud architectures. Choose ALB for Layer-7 routing & web apps; choose NLB for high-performance Layer-4 workloads; avoid planning new work on CLB. Use the troubleshooting scripts above, tune health checks, and instrument your system with CloudWatch and access logs.