Cargando...
Cargando...
Automatically distribute incoming application traffic across multiple targets for fault tolerance, scalability, and zero-downtime deployments
Elastic Load Balancing (ELB) automatically distributes incoming application traffic across multiple targets — such as EC2 instances, containers, Lambda functions, and IP addresses — in one or more Availability Zones. ELB offers four load balancer types: Application (ALB), Network (NLB), Gateway (GWLB), and Classic (CLB, legacy), each optimized for different use cases and OSI layers. ELB continuously monitors the health of registered targets and routes traffic only to healthy ones, making it the foundational building block for highly available and scalable AWS architectures.
Eliminate single points of failure by distributing traffic across healthy targets in multiple AZs, enabling horizontal scaling, blue/green deployments, and seamless integration with Auto Scaling Groups.
Use When
Avoid When
Application Load Balancer (Layer 7 — HTTP/HTTPS/gRPC/WebSocket)
Supports content-based routing: path, host, HTTP header, HTTP method, query string, source IP. Ideal for microservices and container-based architectures.
Network Load Balancer (Layer 4 — TCP/UDP/TLS)
Handles millions of requests per second, preserves source IP, supports static Elastic IPs per AZ, ultra-low latency. Best for gaming, IoT, financial trading.
Gateway Load Balancer (Layer 3/4 — IP packets via GENEVE)
Transparent bump-in-the-wire for third-party virtual appliances (firewalls, IDS/IPS, deep packet inspection). Uses GENEVE protocol on port 6081.
Classic Load Balancer (Layer 4 and 7 — legacy)
LEGACY — AWS recommends migrating to ALB or NLB. Lacks advanced routing, WAF integration, and Lambda targets.
Sticky Sessions (Session Affinity)
ALB uses application-based or duration-based cookies. NLB uses 5-tuple (source IP, source port, destination IP, destination port, protocol) hashing. CLB uses duration-based cookies only.
SSL/TLS Termination
ALB and NLB support TLS termination. ALB integrates with ACM for free certificate management. NLB supports TLS passthrough (no termination) as well.
Server Name Indication (SNI)
ALB and NLB support SNI — multiple certificates on one listener. CLB does NOT support SNI.
AWS WAF Integration
ALB only. NLB and GWLB do NOT natively integrate with WAF. For WAF on NLB traffic, route through CloudFront + WAF first.
Lambda Targets
ALB only. Allows serverless backends for HTTP workloads. One Lambda function per target group.
IP Targets (on-premises via Direct Connect / VPN)
ALB and NLB support IP-based targets, enabling hybrid architectures where on-premises servers are registered as targets.
PrivateLink (NLB as endpoint service)
NLB can be exposed as a VPC Endpoint Service via AWS PrivateLink, enabling private connectivity between VPCs without VPC peering or internet access.
Request Tracing (X-Forwarded headers)
ALB adds X-Forwarded-For, X-Forwarded-Proto, X-Forwarded-Port, and X-Amzn-Trace-Id headers. NLB preserves source IP natively (no header injection needed).
Slow Start Mode
ALB gradually increases traffic to newly registered targets over a configurable warm-up period. Prevents overwhelming freshly launched instances.
Weighted Target Groups (ALB)
Route a percentage of traffic to different target groups — enables blue/green and canary deployments without Route 53 changes.
Connection Draining / Deregistration Delay
ELB waits a configurable period (1–3600 seconds, default 300s) before completing deregistration, allowing in-flight requests to finish. Set to 0 to disable.
Dual-Stack (IPv4 + IPv6)
ALB and NLB support dualstack DNS names and can accept both IPv4 and IPv6 client connections.
Health Checks
Configurable per target group: protocol, path (ALB), port, healthy/unhealthy threshold, interval, timeout. ALB supports HTTP/HTTPS health checks; NLB supports TCP/HTTP/HTTPS.
Deletion Protection
Prevent accidental deletion of load balancers. Must be explicitly disabled before deletion.
Dynamic Port Mapping for Containerized Microservices
high freqALB or NLB integrates with ECS via dynamic port mapping. Each container task gets a random host port, and ECS automatically registers/deregisters the task's IP:port with the ALB target group. This enables running multiple tasks of the same service on a single EC2 host. With AWS Fargate, IP-based target groups are required since there is no host port concept.
Blue/Green Deployment with Traffic Shifting
high freqCodeDeploy integrates with ALB and NLB to perform blue/green deployments for EC2, ECS, and Lambda. CodeDeploy registers the new (green) target group with the load balancer, shifts traffic (all-at-once, canary, or linear), and deregisters the old (blue) group after validation. For ECS, this is the primary deployment strategy for zero-downtime releases.
Internal vs. Internet-Facing Load Balancers
high freqInternet-facing load balancers have public DNS names and IPs, routing traffic from the internet to targets. Internal load balancers have only private IPs, used for service-to-service communication within a VPC or between peered VPCs. Subnet selection determines whether the LB is internal or internet-facing — subnets must be in the LB's VPC.
CloudFront + ALB for Global HTTPS Acceleration
high freqCloudFront sits in front of an ALB to provide global edge caching, DDoS protection (Shield Standard), and WAF integration at the edge. The ALB is configured as a CloudFront custom origin. To prevent direct ALB access bypassing CloudFront, use a custom HTTP header in CloudFront that the ALB listener rule checks for — or restrict ALB security groups to CloudFront managed prefix lists.
Web Application Firewall on ALB
high freqAWS WAF WebACLs can be associated directly with an ALB to filter malicious traffic (SQL injection, XSS, rate limiting, IP reputation lists) before it reaches targets. WAF is NOT supported on NLB or GWLB natively. For NLB-fronted workloads requiring WAF, place CloudFront + WAF in front of the NLB.
Elastic Scaling with Health-Based Replacement
high freqELB health checks integrate with EC2 Auto Scaling Groups. When ELB marks a target unhealthy, Auto Scaling can terminate and replace it. The ASG registers new instances automatically with the target group. This is the foundational pattern for self-healing, auto-scaling architectures in AWS.
Read Replica Routing via ALB (Anti-Pattern Awareness)
medium freqELB should NOT be placed in front of RDS directly (RDS has its own endpoint). However, ALB CAN route to RDS Proxy or application-tier instances that then connect to RDS. The common pattern is: Client → ALB → EC2/ECS App Tier → RDS. Never use ELB as a direct database proxy.
Access Logs Archival to S3
medium freqELB access logs are delivered to an S3 bucket you specify. The bucket policy must grant ELB the PutObject permission (using the ELB service account for the Region or the aws-elasticloadbalancing service principal). Logs are useful for security auditing, traffic analysis, and feeding into Athena for SQL-based querying.
NLB as VPC Endpoint Service
medium freqAn NLB can be the backend for a VPC Endpoint Service (PrivateLink). Consumer VPCs create Interface VPC Endpoints that connect privately to the NLB. This enables SaaS-style service sharing across VPCs and accounts without VPC peering, transit gateways, or internet exposure. The NLB must be in the same Region as the endpoint service.
Static Anycast IPs with Regional ALB/NLB Backends
medium freqGlobal Accelerator provides two static anycast IPs that route to ALB or NLB endpoints in multiple AWS Regions. Unlike CloudFront (caching CDN), Global Accelerator is for non-HTTP or latency-sensitive TCP/UDP workloads requiring static IPs and intelligent failover across Regions. Use Global Accelerator + NLB for gaming, VoIP, and financial applications.
ALB operates at Layer 7 (HTTP/HTTPS/gRPC); NLB at Layer 4 (TCP/UDP/TLS); GWLB at Layer 3 (IP) using GENEVE. Memorize this OSI layer mapping — exam questions frequently hinge on which LB type to choose based on protocol requirements.
NLB preserves the client's source IP address natively at Layer 4. ALB replaces the source IP with its own and adds X-Forwarded-For header. If a question asks about a backend needing the real client IP without header parsing, choose NLB.
Only NLB supports static Elastic IP addresses per Availability Zone. ALB does NOT have static IPs (its IPs can change). If a question mentions firewall whitelisting by IP or a requirement for static IPs, the answer is NLB (or Global Accelerator in front of ALB).
AWS WAF can ONLY be associated with ALB (and CloudFront, API Gateway, AppSync) — NOT with NLB or GWLB. If a question requires WAF + NLB, the correct architecture is CloudFront + WAF in front of NLB.
For ECS Fargate with a load balancer, you MUST use IP-based target groups (awsvpc network mode assigns each task its own ENI and IP). Instance-based target groups do not work with Fargate tasks.
Static IP requirement = NLB. WAF requirement = ALB. Layer 4 TCP/UDP = NLB. Layer 7 HTTP routing = ALB. Security appliance inspection = GWLB. Memorize this decision matrix cold.
NLB preserves source IP natively; ALB does NOT (uses X-Forwarded-For). ECS Fargate requires IP-based target groups (awsvpc mode). WAF works ONLY with ALB, not NLB.
Cross-zone load balancing: ALB = always on, always free. NLB/GWLB = off by default, costs money when enabled. This distinction drives cost-optimization and architecture questions.
ALB supports weighted target groups natively — you can send X% of traffic to target group A and Y% to target group B on the same listener rule. This enables canary deployments without DNS changes. NLB does NOT support weighted target groups.
Cross-zone load balancing behavior differs by type: ALB — always enabled, no charge. NLB — disabled by default, enabled per target group, incurs inter-AZ data transfer charges. GWLB — disabled by default, charged when enabled. This pricing distinction appears in cost-optimization questions.
Connection Draining (CLB) = Deregistration Delay (ALB/NLB). Both serve the same purpose: allow in-flight requests to complete before a target is deregistered. Default is 300 seconds. Set to 0 to skip draining immediately (useful for stateless services during rapid deployments).
ALB supports Lambda functions as targets (one Lambda per target group). The request is transformed into a JSON event. ALB can invoke Lambda synchronously for HTTP workloads — this enables fully serverless backends without API Gateway.
GWLB uses the GENEVE protocol (port 6081) and operates as a transparent bump-in-the-wire. Traffic flows: Client → GWLB → GWLB Endpoint → Virtual Appliance → GWLB → Original Destination. It does NOT terminate connections — it passes packets through for inspection.
For HTTPS listeners, the SSL/TLS certificate must be in ACM (or IAM certificate store) in the SAME Region as the load balancer. ACM certificates are Region-specific — a certificate in us-east-1 cannot be used by an ALB in eu-west-1.
ALB access logs require an S3 bucket policy granting PutObject to the ELB service. The bucket must be in the same Region as the load balancer. Logs are NOT real-time — use CloudWatch metrics or X-Ray for near-real-time observability.
Slow Start Mode (ALB only) gradually ramps up traffic to a newly registered target over 30–900 seconds. Use this for targets that need warm-up time (e.g., JVM-based applications, ML inference servers). It is configured per target group, not per listener.
Common Mistake
NLB cannot have security groups, so you cannot restrict inbound traffic to NLB-fronted applications.
Correct
While historically NLB did not support security groups (traffic filtering was done at the target's security group using NLB's static IPs), AWS added security group support for NLB in 2023. Even before that, you could restrict traffic at the target's security group by allowing only the NLB's static Elastic IPs or the client IP (with Proxy Protocol v2 enabled). Always check the current exam guide, but know that targets behind NLB can and should have restrictive security groups.
Exam questions often present NLB as a security risk because 'it has no security groups' — this was the old reality. The nuanced answer is that security is enforced at the target layer, and the NLB's static IPs make whitelisting straightforward. Modern NLB also supports security groups directly.
Common Mistake
You can put an Elastic Load Balancer directly in front of Amazon RDS to distribute database read traffic across read replicas.
Correct
ELB cannot be placed directly in front of RDS instances. RDS has its own DNS endpoints (primary endpoint, reader endpoint for Aurora). For distributing reads across Aurora read replicas, use the Aurora Reader Endpoint. For non-Aurora RDS, use application-level read/write splitting or RDS Proxy. Placing ELB in front of database instances is an anti-pattern that breaks connection state.
This trap appears in database scaling questions. The correct AWS-native solution for read distribution is Aurora Reader Endpoint, not ELB. ELB is for stateless application tier scaling.
Common Mistake
ALB and NLB both support AWS WAF for web application firewall protection.
Correct
AWS WAF can ONLY be associated with ALB (not NLB or GWLB). NLB operates at Layer 4 and does not inspect HTTP content, making WAF integration architecturally impossible at the NLB layer. To add WAF to NLB-fronted workloads, place Amazon CloudFront (with WAF WebACL) in front of the NLB.
Security architecture questions frequently test WAF placement. Remembering that WAF requires Layer 7 (HTTP) inspection — which only ALB and CloudFront provide — eliminates wrong answers quickly.
Common Mistake
ALB has static IP addresses that can be whitelisted in external firewalls.
Correct
ALB does NOT have static IP addresses. ALB's IP addresses can change as AWS scales the load balancer nodes. Only NLB supports static Elastic IPs (one per AZ). If a requirement mentions IP whitelisting, firewall rules, or static IPs, the answer is NLB — or use AWS Global Accelerator (which provides two static anycast IPs) in front of an ALB.
This is one of the most common ALB vs. NLB selection mistakes. The static IP requirement is a clear signal to choose NLB. Memorize: 'NLB = Static IP, ALB = Dynamic IP'.
Common Mistake
Enabling cross-zone load balancing on NLB is always the right choice for even traffic distribution and has no downside.
Correct
Cross-zone load balancing on NLB incurs inter-AZ data transfer charges (unlike ALB where it is free). For cost-sensitive architectures or workloads where AZ affinity is acceptable, leaving cross-zone disabled on NLB saves money. The trade-off is uneven distribution if target counts differ across AZs. ALB always has cross-zone on with no charge.
Cost-optimization questions in SAA-C03 and SAP-C02 test awareness of data transfer costs. Cross-zone on NLB is a hidden cost that candidates overlook.
Common Mistake
Classic Load Balancer (CLB) is equivalent to ALB for HTTP workloads and should be chosen for simplicity.
Correct
CLB is a legacy service. It lacks: content-based routing (path/host), WebSocket support (limited), Lambda targets, WAF integration, SNI (multiple certificates), weighted target groups, and modern health check capabilities. AWS actively recommends migrating CLBs to ALB or NLB. CLB should NEVER be chosen for new architectures.
Exam questions sometimes include CLB as a distractor answer. Knowing CLB's limitations helps you immediately eliminate it for any scenario requiring modern features.
Common Mistake
Sticky sessions (session affinity) on ALB guarantee that a user always hits the same EC2 instance, making the application effectively stateful and eliminating the need for a shared session store.
Correct
Sticky sessions are a temporary workaround, not a proper stateful architecture. If the sticky target becomes unhealthy, the user is routed to a different instance and loses session state. The correct architecture for stateful applications is to externalize session state to ElastiCache (Redis) or DynamoDB, making all instances stateless and interchangeable.
Architecture best practice questions frequently test whether candidates understand that sticky sessions break horizontal scaling and fault tolerance. The right answer is always: externalize state, not sticky sessions.
Common Mistake
An internal load balancer can only route traffic to targets within the same VPC.
Correct
Internal load balancers route traffic within the VPC's private address space, but targets can include IP addresses reachable via VPC peering, Transit Gateway, or Direct Connect (on-premises IPs). IP-based target groups allow registering any routable IP address, enabling hybrid and multi-VPC architectures behind an internal ELB.
Hybrid architecture questions test whether candidates know that ELB supports IP-based targets beyond the local VPC. This enables on-premises servers to be load-balanced targets.
ALB = 'A'pplication = 'A'dvanced routing = 'A'rchitect's choice for HTTP (Layer 7). NLB = 'N'etwork = 'N'eed for speed + 'N'o dynamic IPs (static). GWLB = 'G'ateway = 'G'uardian (security appliances). CLB = 'C'lassic = 'C'onsider migrating.
WAF only on ALB: 'WAF Loves ALB' — W-A-L-A. WAF needs Layer 7 to read HTTP, and only ALB speaks Layer 7 among ELB types.
Static IP? Think NLB. 'N' for 'N'ailed-down IPs. 'A' for 'A'lways changing (ALB).
Cross-zone pricing: 'ALB = Always free, NLB = Not free' — A=Always, N=Not.
ECS Fargate target group type: 'Fargate = IP' — Fargate tasks get their own IP (awsvpc mode), so you MUST use IP-based target groups, never instance-based.
HTTP error codes from ALB: 502 = Bad response from target. 503 = No healthy targets. 504 = Target too slow (timeout). Remember: 502=Bad, 503=None, 504=Slow.
CertAI Tutor · SAA-C03, SAP-C02, DOP-C02 · 2026-02-21
In the Same Category
Comparisons
Guides & Patterns