Vinay Kumar
ELB
LearningTree ยท AWS ยท Networking

Elastic Load Balancing โ€”
Traffic Distribution Layer

AWS's managed load balancing service โ€” distributes incoming traffic across multiple targets, performs health checks, enables zero-downtime deployments, and acts as the intelligent entry point to your system. Not just traffic spreading โ€” it's your traffic control layer.

โšก ELB in 30 Seconds

  • Distributes traffic โ€” routes incoming requests across multiple healthy targets (EC2, ECS, Lambda)
  • Health checks โ€” automatically detects unhealthy targets and stops routing traffic to them
  • Three types โ€” ALB (Layer 7, HTTP), NLB (Layer 4, TCP/UDP), GWLB (Layer 3, appliances)
  • Multi-AZ โ€” spans Availability Zones for fault tolerance and high availability
  • Fully managed โ€” AWS handles scaling, patching, and availability of the load balancer itself
01
Chapter One

What is Load Balancing

The Problem โ€” Why Load Balancers Exist Introductory

You deploy your application on one server. Traffic grows. That single server handles 100 requests/secondโ€ฆ then 1,000โ€ฆ then it crashes. Users see 503 errors. Your app is down. You can scale vertically (bigger server), but there's a ceiling โ€” and a single point of failure remains.

๐Ÿ‘‰ The fundamental problem: One server = one point of failure + limited capacity. You need multiple servers โ€” but someone needs to decide which server handles each request. That's what a load balancer does.

What is a Load Balancer Introductory

A load balancer sits between clients and your servers. It receives all incoming requests and distributes them across multiple backend servers (called targets). No single target gets overwhelmed. If one target dies, the load balancer stops sending traffic to it โ€” users never notice.

๐Ÿ’ฅ

Without Load Balancer

  • Single server handles everything
  • Server crashes โ†’ entire app goes down
  • Can't scale beyond one machine's capacity
  • Deployments require downtime
  • No health monitoring
  • No traffic distribution
โš–๏ธ

With Load Balancer

  • Traffic distributed across multiple targets
  • One target dies โ†’ others handle traffic seamlessly
  • Scale horizontally by adding more targets
  • Rolling deployments with zero downtime
  • Continuous health checks on all targets
  • Smart routing (path, host, headers)
Horizontal Scaling โ€” The Key Concept Introductory

There are two ways to handle growth:

๐Ÿ“

Vertical Scaling (Scale Up)

  • Make one server bigger (more CPU, RAM)
  • Simple โ€” no architecture change
  • Hard limit โ€” eventually max out
  • Single point of failure remains
  • Downtime to resize
๐Ÿ“Š

Horizontal Scaling (Scale Out)

  • Add more servers of the same size
  • Virtually unlimited capacity
  • No single point of failure
  • Add/remove servers without downtime
  • Requires a load balancer to distribute traffic

Horizontal scaling is how modern cloud architectures work. Auto Scaling adds EC2 instances; the load balancer automatically includes them in traffic distribution. This is elastic computing โ€” grow and shrink with demand.

Concept Diagram โ€” How Load Balancing Works Introductory
Concept โ€” Load balancer distributes traffic to healthy targets
๐Ÿ‘ฅ Clients 1000s of requests LOAD BALANCER โš–๏ธ Distributes traffic Health checks targets Routes intelligently All traffic Target 1 โœ… Healthy โ€” receives traffic Target 2 โœ… Healthy โ€” receives traffic Target 3 โœ… Healthy โ€” receives traffic Target 4 โŒ Unhealthy โ€” NO traffic โœ— stopped
AWS Diagram โ€” ELB in a VPC Core
AWS Architecture โ€” ELB distributes traffic across EC2 instances in multiple AZs
VPC (10.0.0.0/16) ๐ŸŒ Internet ELB Elastic Load Balancer Listener: port 443 Health checks every 30s Spans all AZs AZ-a EC2-1 t3.medium ยท healthy EC2-2 t3.medium ยท healthy AZ-b EC2-3 t3.medium ยท healthy EC2-4 t3.medium ยท unhealthy Auto Scaling Adds/removes targets
Architecture Diagram โ€” Multi-AZ High Availability Core
High Availability โ€” ELB ensures traffic flows only to healthy targets across AZs
Route 53 DNS โ†’ ELB ELB Cross-zone balancing Multi-AZ AZ-a (us-east-1a) ๐Ÿ–ฅ๏ธ 2 healthy targets 50% of traffic AZ-b (us-east-1b) ๐Ÿ–ฅ๏ธ 2 healthy targets 50% of traffic HIGH AVAILABILITY If AZ-a fails entirely: โ†’ ELB routes 100% to AZ-b Zero downtime for users
Mental Model โ€” The Traffic Controller Analogy Introductory
๐Ÿšฆ

Without Load Balancer = One-Lane Road

  • All cars (requests) take the same single road
  • Traffic jam at peak hours (server overloaded)
  • Road closed for repair โ†’ no one gets through (downtime)
  • No alternative route
  • Accident = total shutdown
๐Ÿ›ฃ๏ธ

With Load Balancer = Traffic Controller + Highway

  • Multiple lanes (targets) available
  • Traffic controller (ELB) directs cars to least-busy lane
  • One lane closed โ†’ controller re-routes to open lanes
  • New lanes added during rush hour (Auto Scaling)
  • Smart routing โ€” trucks to one lane, cars to another (ALB rules)
  • Controller never sleeps (managed service, always available)
๐Ÿง  Key Insight

ELB is not just "traffic spreading" โ€” it's your traffic control layer. It routes intelligently, monitors health continuously, enables zero-downtime deployments, and acts as the single entry point that decouples clients from your backend architecture.

What Makes ELB Special Core

AWS ELB is a fully managed service โ€” you don't run load balancer software on EC2. AWS handles:

๐Ÿ“ˆ

Auto-Scaling

ELB itself scales automatically. Handles 10 req/s or 10M req/s โ€” no pre-provisioning needed (ALB). AWS manages the underlying fleet.

๐Ÿ”„

Health Checks

Pings targets every 10-30 seconds. Unhealthy target? Traffic immediately re-routed to healthy ones. Auto-heals when target recovers.

๐ŸŒ

Multi-AZ

Spans multiple Availability Zones. If an entire AZ goes down, ELB routes 100% to remaining AZs. True fault tolerance.

ELB in the Request Flow Core

Understanding where ELB sits in the full AWS request flow:

โ‘  Route 53 โ†’ DNS resolution (domain โ†’ IP)
โ‘ก CloudFront โ†’ Edge caching (optional, reduces latency)
โ‘ข ELB โ†’ Distributes traffic to targets
โ‘ฃ EC2 / ECS / Lambda โ†’ Processes the request
โ‘ค RDS / DynamoDB โ†’ Data layer

๐Ÿ‘‰ ELB is the gateway between the internet and your compute layer. Everything flows through it.

Chapter Summary Introductory
  • Load balancing = distributing traffic across multiple targets to prevent overload
  • Horizontal scaling = adding more servers (not bigger servers) โ€” requires a load balancer
  • Health checks = ELB monitors targets and stops routing to unhealthy ones
  • Multi-AZ = ELB spans AZs for fault tolerance โ€” entire AZ failure is handled
  • Fully managed = AWS scales ELB itself; you don't manage load balancer infrastructure
  • ELB = traffic control layer โ€” not just spreading, but intelligent routing + health + zero-downtime deployments
02
Chapter Two

ELB Types โ€” ALB, NLB & GWLB

Three Load Balancers, Three Layers Introductory

AWS offers three types of Elastic Load Balancers โ€” each operating at a different OSI layer and optimized for different workloads. Choosing the right one is a common exam question and a critical architecture decision.

๐Ÿ‘‰ The key mental model: ALB = smart routing (HTTP/HTTPS), NLB = raw speed (TCP/UDP), GWLB = security appliances (Layer 3). Most web applications use ALB. High-performance systems use NLB. You rarely need GWLB unless you're running firewalls or IDS/IPS.

Overview โ€” The Three Types Introductory
๐ŸŒ

ALB โ€” Application Load Balancer

  • Layer 7 (HTTP/HTTPS)
  • Content-based routing
  • Path, host, header, query string rules
  • WebSocket support
  • Lambda + EC2 + ECS targets
  • Best for: web apps, microservices, APIs
โšก

NLB โ€” Network Load Balancer

  • Layer 4 (TCP/UDP/TLS)
  • Ultra-low latency (~100ฮผs)
  • Millions of requests/sec
  • Static IP / Elastic IP support
  • Preserves source IP
  • Best for: gaming, IoT, financial, TCP services
๐Ÿ›ก๏ธ

GWLB โ€” Gateway Load Balancer

  • Layer 3 (IP packets)
  • Transparent to applications
  • GENEVE encapsulation
  • Inline traffic inspection
  • Third-party appliances
  • Best for: firewalls, IDS/IPS, DPI
Detailed Comparison Table Core
Feature ALB NLB GWLB
OSI Layer Layer 7 Layer 4 Layer 3
Protocols HTTP, HTTPS, gRPC TCP, UDP, TLS IP (all protocols)
Latency ~ms ~ฮผs (ultra-low) ~ms
Static IP โŒ (use DNS) โœ… (Elastic IP) โŒ
Content Routing โœ… (path, host, headers) โŒ (port only) โŒ
Security Groups โœ… โœ… (added 2023) โŒ
Lambda Targets โœ… โŒ โŒ
Source IP Preserved โŒ (use X-Forwarded-For) โœ… โœ…
Throughput High Millions req/s High
Concept Diagram โ€” Layer Differences Introductory
Concept โ€” Each ELB type operates at a different network layer
OSI LAYERS Layer 7 โ€” Application Layer 4 โ€” Transport Layer 3 โ€” Network ALB Understands HTTP requests Routes by: path, host, headers, method /api/* โ†’ Service A | /web/* โ†’ Service B NLB Sees TCP/UDP connections Routes by: port number only :443 โ†’ TG-A | :8080 โ†’ TG-B GWLB Sees raw IP packets Routes ALL traffic to appliances Firewall / IDS / DPI inline inspection ALB USE CASES Web apps ยท REST APIs ยท Microservices gRPC ยท WebSocket ยท SSO/OIDC NLB USE CASES Gaming ยท IoT ยท Financial ยท VoIP Static IP ยท Extreme throughput GWLB USE CASES Firewalls ยท IDS/IPS ยท DLP Third-party security appliances
AWS Diagram โ€” ALB vs NLB Architecture Core
AWS Architecture โ€” ALB routes by content, NLB routes by connection
ALB โ€” Layer 7 (Content-based routing) ๐Ÿ‘ค HTTP Client ALB Reads HTTP headers Path: /api/* Host: app.example.com TG: API Service ECS Fargate containers TG: Web Frontend EC2 instances (React app) TG: Auth Lambda /api/* /web/* /auth/* ALB ROUTING RULES /api/* โ†’ API containers /web/* โ†’ EC2 frontend /auth/* โ†’ Lambda function One LB โ†’ multiple services! NLB โ€” Layer 4 (Connection-based routing) ๐ŸŽฎ TCP Client NLB TCP connection passthrough Static IP: 52.1.2.3 Ultra-low latency (~ฮผs) TG: Game Servers Port 7777 (TCP) TG: DB Proxy Port 3306 (TCP) :7777 :3306 NLB ADVANTAGES Millions of connections/sec Source IP preserved Static/Elastic IP per AZ Whitelisting by IP possible!
Architecture Diagram โ€” When to Use Which Core
Decision Tree โ€” Choose the right ELB type for your workload
What type of traffic? HTTP/HTTPS โ†’ Use ALB Web apps, APIs, microservices Need path/host routing? Lambda targets? โ†’ ALB TCP/UDP โ†’ Use NLB Gaming, IoT, financial systems Need static IP? Ultra-low latency? Millions req/s? โ†’ NLB Security inspection โ†’ Use GWLB Inline firewalls, IDS/IPS Third-party virtual appliances Transparent inspection? โ†’ GWLB ๐ŸŽฏ EXAM TIP 90% of exam scenarios = ALB "Static IP" keyword = NLB "Firewall appliance" = GWLB
ALB vs NLB โ€” When to Choose Core
๐ŸŒ

Choose ALB When

  • Web application with HTTP/HTTPS traffic
  • Microservices needing path-based routing
  • Multiple domains on one load balancer (host-based)
  • Need to route to Lambda functions
  • WebSocket connections needed
  • Authentication (OIDC/Cognito integration)
  • gRPC workloads
  • Redirect HTTP โ†’ HTTPS at LB level
โšก

Choose NLB When

  • Non-HTTP protocols (TCP, UDP, TLS)
  • Need static IP for whitelisting by partners
  • Extreme performance (millions req/s)
  • Ultra-low latency required (~100ฮผs)
  • Need to preserve client source IP
  • Gaming servers, VoIP, IoT
  • PrivateLink (exposing services cross-account)
  • Long-lived TCP connections
Gateway Load Balancer โ€” Quick Overview Advanced

GWLB is the newest type (launched 2020) and the least commonly used. It's designed for a very specific use case: inserting third-party security appliances (firewalls, IDS/IPS) inline into your traffic flow without changing your application architecture.

๐Ÿ›ก๏ธ

How GWLB Works

  • Traffic is transparently diverted to appliances
  • Uses GENEVE protocol (port 6081) for encapsulation
  • Appliances inspect traffic and return it
  • Original flow continues โ€” app doesn't know
  • Scales fleet of appliances automatically
  • Deployed via Gateway Load Balancer Endpoint (GWLBE) in each VPC
โš ๏ธ

When NOT to use GWLB

  • Regular web applications โ†’ use ALB
  • Simple TCP forwarding โ†’ use NLB
  • If you don't run security appliances โ†’ skip GWLB
  • Not for direct application load balancing
  • Exam tip: rarely tested, but know it exists

GWLB โ€” Exam Quick Reference

Layer Layer 3 (IP packets) โ€” transparent to applications
Protocol GENEVE encapsulation (port 6081) โ€” wraps original packets
Use with Third-party firewalls (Palo Alto, Fortinet), IDS/IPS, DLP appliances
Deployment GWLB โ†’ Target Group (appliance fleet) โ†’ returns cleaned traffic via GWLBE
Exam triggers "inline inspection," "security appliance," "firewall," "IDS/IPS," "transparent"
NOT for HTTP routing (use ALB), high-performance TCP (use NLB), direct LB
๐Ÿง  Key Insight

For most real-world scenarios: default to ALB for web apps. Switch to NLB when you see "static IP," "TCP/UDP," "extreme performance," or "source IP preservation." GWLB only appears for security appliance scenarios.

Chapter Summary Introductory
  • ALB (Layer 7) = HTTP/HTTPS smart routing โ€” path, host, headers โ€” web apps + microservices + Lambda
  • NLB (Layer 4) = TCP/UDP raw speed โ€” static IP, ultra-low latency, millions req/s โ€” gaming + IoT + financial
  • GWLB (Layer 3) = IP packet inspection โ€” transparent inline security appliances โ€” firewalls + IDS/IPS
  • Default choice = ALB for 90% of web workloads; NLB when you need static IP or non-HTTP; GWLB only for security appliances
  • Exam keywords: "path-based" โ†’ ALB, "static IP" โ†’ NLB, "firewall appliance" โ†’ GWLB
03
Chapter Three

Application Load Balancer โ€” Deep Dive

What Makes ALB Special Introductory

The Application Load Balancer is the most commonly used ELB type. It operates at Layer 7 (HTTP/HTTPS), which means it can read and understand the content of requests โ€” URLs, headers, cookies, query strings โ€” and make intelligent routing decisions based on that content.

๐Ÿ‘‰ Key difference: NLB sees "a TCP connection on port 443." ALB sees "GET /api/users?page=2 with header Host: api.example.com and cookie session=abc123." ALB understands the request โ€” that's what makes content-based routing possible.

ALB Components โ€” Listener, Rules, Target Groups Core

Every ALB has three core components that work together:

๐Ÿ‘‚

Listener

  • Checks for connections on a port + protocol
  • Typically: port 80 (HTTP) or 443 (HTTPS)
  • You can have multiple listeners
  • HTTPS listener needs an SSL certificate
  • Entry point for all requests
๐Ÿ“‹

Rules

  • Conditions that match incoming requests
  • Path: /api/*, /images/*, /admin/*
  • Host: api.example.com, www.example.com
  • Headers, query strings, HTTP method
  • Evaluated in priority order (1โ€“50000)
  • Default rule = catch-all (required)
๐ŸŽฏ

Target Group

  • Group of targets receiving traffic
  • Can be: EC2, ECS, Lambda, or IP
  • Has its own health check configuration
  • Defines port and protocol for targets
  • One rule โ†’ one target group action
Path-Based Routing Core

Path-based routing sends requests to different target groups based on the URL path. This is the most commonly used ALB routing feature โ€” it lets one ALB serve multiple services:

GET /api/users โ†’ Target Group: API Service (ECS Fargate)
GET /web/dashboard โ†’ Target Group: Web Frontend (EC2)
GET /static/logo.png โ†’ Target Group: Static Assets (S3 via Lambda)
GET /admin/* โ†’ Target Group: Admin Service (separate EC2 fleet)

๐Ÿ‘‰ One ALB, one domain, multiple services โ€” path routing is microsservice routing without a service mesh.

Host-Based Routing Core

Host-based routing routes based on the Host header โ€” effectively serving multiple domains/subdomains from one ALB:

๐Ÿท๏ธ

Example: Multi-Tenant SaaS

  • api.example.com โ†’ API target group
  • www.example.com โ†’ Web target group
  • admin.example.com โ†’ Admin target group
  • *.customer.com โ†’ Customer-specific group
  • All served by ONE ALB
๐Ÿ’ก

Why This Matters

  • One ALB = one bill (cheaper than multiple LBs)
  • Wildcard support (*.example.com)
  • Combine with path rules for fine-grained control
  • Each domain can route to different backends
  • One SSL cert with SANs covers all domains
Concept Diagram โ€” ALB Routing Flow Introductory
Concept โ€” ALB inspects request content and routes to matching target group
Incoming Request GET /api/orders Host: api.shop.com Auth: Bearer xyz... Cookie: session=abc ALB Listener :443 (HTTPS) Rule 1: /api/* โ†’ TG-API Rule 2: /web/* โ†’ TG-Web Rule 3: /admin/* โ†’ TG-Admin Default: โ†’ 404 fixed response TG: API Service 3ร— ECS tasks (Fargate) TG: Web Frontend 2ร— EC2 (React app) TG: Admin 1ร— EC2 (internal) โœ“ MATCH โœ“ /api/orders matches Rule 1 (/api/*) โ†’ Routed to TG: API Service (ECS Fargate containers)
AWS Diagram โ€” ALB with Multiple Target Types Core
AWS Architecture โ€” ALB routing to EC2, ECS, and Lambda targets
VPC ๐ŸŒ HTTPS ALB Listener: 443 /api/* โ†’ ECS /web/* โ†’ EC2 /auth/* โ†’ Lambda ACM cert attached Target Group: API (ECS) Task 1 Task 2 Fargate ยท port 8080 ยท AZ-a & AZ-b Target Group: Web (EC2) EC2-1 EC2-2 t3.large ยท port 3000 ยท React SSR Target Group: Auth (Lambda) auth-handler Serverless ยท OIDC validation /api/* /web/* /auth/* ALB BENEFITS โœ“ One LB for all services โœ“ Mix target types freely โœ“ Independent scaling per TG โœ“ Independent health checks โœ“ Blue/green via weighted TGs โœ“ Shared SSL certificate (ACM)
Advanced Routing โ€” Headers, Query Strings, Methods Advanced

Beyond path and host, ALB can route on any HTTP attribute:

๐Ÿ”ง

Advanced Condition Types

  • HTTP Header: X-Custom-Header = "beta" โ†’ TG-Beta
  • Query String: ?version=v2 โ†’ TG-V2
  • HTTP Method: POST /orders โ†’ TG-Write-Service
  • Source IP: 10.0.0.0/8 โ†’ TG-Internal
  • Combine conditions with AND logic
๐ŸŽฏ

Advanced Actions

  • Forward: Send to target group (normal)
  • Redirect: HTTPโ†’HTTPS, oldโ†’new URL
  • Fixed Response: Return 404/503 directly from ALB
  • Authenticate: OIDC/Cognito before forwarding
  • Weighted: 90% TG-Blue + 10% TG-Green
Architecture Diagram โ€” ALB for Microservices Advanced
Production Pattern โ€” Single ALB routing to microservices with weighted deployment
CloudFront Edge cache + WAF ALB :443 HTTPS 5 routing rules ACM cert Access logs โ†’ S3 Cognito auth /api/orders โ†’ Weighted v1.2 (90%) v1.3-rc (10%) Canary deployment in progress /api/users โ†’ ECS 4ร— Fargate tasks ยท Auto Scaling /api/payments โ†’ EC2 PCI-compliant ยท dedicated instances /webhooks/* โ†’ Lambda Event-driven ยท pay per invocation ๐ŸŽฏ PATTERN One ALB = microservice router Each service scales independently Canary deploys via weighted TGs
ALB Features โ€” Deep List Advanced
โœ…

ALB Can Do

  • Path-based & host-based routing
  • HTTP โ†’ HTTPS redirect (built-in)
  • Fixed response (maintenance page from LB)
  • OIDC / Cognito authentication at LB level
  • Sticky sessions (cookie-based)
  • WebSocket and HTTP/2 support
  • gRPC support
  • Lambda targets (serverless backend)
  • Weighted target groups (canary/blue-green)
  • Access logs to S3
  • WAF integration (Web Application Firewall)
  • Slow start mode for new targets
โŒ

ALB Cannot Do

  • Static IP (use NLB or Global Accelerator)
  • Preserve source IP directly (use X-Forwarded-For)
  • Non-HTTP protocols (TCP, UDP, MQTT โ†’ NLB)
  • Ultra-low latency (ฮผs) โ€” ALB adds ~ms
  • PrivateLink / VPC endpoint service (โ†’ NLB)
  • Inline IP packet inspection (โ†’ GWLB)
ALB Operational Details Advanced
โฑ๏ธ

Idle Timeout

  • Default: 60 seconds
  • If no data sent/received for 60s โ†’ connection closed
  • WebSocket: increase to 3600 seconds or more
  • File uploads: increase for large files
  • Short APIs: decrease to 30s (frees resources)
  • Target keep-alive should exceed ALB idle timeout
๐Ÿข

Slow Start Mode

  • New targets receive gradually increasing traffic
  • Duration: 30โ€“900 seconds (configurable)
  • Protects cold-start instances from sudden full load
  • JVM warm-up, cache priming, lazy initialization
  • Traffic ramps linearly over configured duration
  • Disabled by default (set to 0)
๐Ÿ”’

Deletion Protection

  • Prevents accidental ALB deletion
  • Must be explicitly disabled before deletion
  • Enable for all production load balancers
  • Terraform: enable_deletion_protection = true
  • Console: shows error if you try to delete
๐Ÿ“

ALB Limits

  • 100 rules per listener (default, can request increase)
  • 5 conditions per rule (AND logic)
  • Up to 5 actions per rule
  • 50 target groups per ALB
  • For large microservices: chain ALBs or use NLBโ†’ALB
  • Multiple listeners on same ALB (e.g., 80 + 443)
๐Ÿง  Key Insight

ALB is your microservice router. One ALB replaces what used to require multiple load balancers or a dedicated API gateway. Path routing + host routing + weighted targets = a lightweight service mesh at the infrastructure level.

Chapter Summary Introductory
  • ALB = Layer 7 โ€” reads HTTP content and routes based on path, host, headers, cookies, query strings
  • Components: Listener (port+protocol) โ†’ Rules (conditions) โ†’ Target Groups (destinations)
  • Path routing: /api/* โ†’ Service A, /web/* โ†’ Service B โ€” one LB, multiple services
  • Host routing: api.example.com โ†’ different backend than www.example.com
  • Target types: EC2 instances, ECS tasks, Lambda functions, IP addresses โ€” mix freely
  • Advanced: weighted target groups for canary deployments, OIDC auth, fixed responses, WAF
  • Limits: 100 rules per listener, 5 conditions per rule, 50 target groups per ALB
  • Idle timeout: default 60s โ€” increase for WebSocket (3600s) and large uploads
  • Slow start: ramp up traffic to new targets over 30-900s (protects cold starts)
  • Cannot: static IP, source IP preservation (use X-Forwarded-For), non-HTTP traffic
04
Chapter Four

Network Load Balancer โ€” Deep Dive

What Makes NLB Different Introductory

The Network Load Balancer operates at Layer 4 (Transport layer) โ€” it sees TCP/UDP connections, not HTTP content. It doesn't inspect payloads, doesn't read headers, doesn't understand URLs. It simply forwards connections at wire speed. This makes it extremely fast โ€” latency measured in microseconds, not milliseconds.

๐Ÿ‘‰ The key difference: ALB is like a concierge who reads your invitation and directs you to the right room. NLB is like a high-speed highway toll booth โ€” it doesn't care what's in your car, it just routes you through as fast as physically possible.

NLB Core Characteristics Core
โšก

Performance

  • Millions of requests per second
  • Ultra-low latency: ~100 microseconds
  • Handles sudden traffic spikes without warm-up
  • No pre-provisioning needed
  • Designed for volatile, bursty workloads
  • Connection-level load balancing (not request-level)
๐Ÿ“Œ

Static IP / Elastic IP

  • One static IP per AZ (automatically assigned)
  • Can attach Elastic IP per AZ (bring your own)
  • IP never changes โ€” firewall-friendly
  • Partners can whitelist your IP
  • DNS resolves to these IPs (not rotating like ALB)
  • Critical for IP-based whitelisting scenarios
๐Ÿ”

Source IP Preservation

  • Client's real IP reaches the target
  • No X-Forwarded-For needed (unlike ALB)
  • Target sees: source IP = client IP
  • Important for logging, geo-restriction, security
  • Works by default for instance targets
๐Ÿšซ

What NLB Cannot Do

  • No content-based routing (no path/host)
  • No HTTP header inspection
  • No Lambda targets
  • No built-in authentication (OIDC)
  • No WebSocket-specific handling
  • No WAF integration directly
NLB vs ALB โ€” Protocol Handling Core

The fundamental difference in how they process traffic:

ALB sees: "GET /api/users HTTP/1.1\nHost: api.example.com\nAuth: Bearer token..."
ALB decides: path matches /api/* โ†’ forward to API target group

NLB sees: "TCP connection โ†’ destination port 443"
NLB decides: port 443 โ†’ forward to target group for port 443
(NLB doesn't open the packet โ€” just routes the connection)

Concept Diagram โ€” NLB Connection Flow Introductory
Concept โ€” NLB forwards TCP/UDP connections at wire speed without inspection
๐ŸŽฎ Client TCP SYN โ†’ port 7777 Source: 203.0.113.50 NLB Static IP: 52.1.2.3 Listener: TCP :7777 No packet inspection Flow-level decision ~100ฮผs latency added TCP Game Server 1 Port 7777 ยท AZ-a Sees client IP: 203.0.113.50 Game Server 2 Port 7777 ยท AZ-b Sees client IP: 203.0.113.50 NLB KEY FACTS โœ“ Source IP preserved (no NAT) โœ“ Connection routed in ~100ฮผs (not ms!)
AWS Diagram โ€” NLB with Static IP Core
AWS Architecture โ€” NLB with Elastic IPs for partner whitelisting
VPC ๐Ÿข Partner Firewall allows only 52.1.2.3 NLB Elastic IPs: AZ-a: 52.1.2.3 (EIP) AZ-b: 52.1.2.4 (EIP) Listener: TCP :443 TLS termination (optional) Cross-zone: enabled AZ-a API-1 c5.xlarge ยท TCP :443 API-2 c5.xlarge ยท TCP :443 AZ-b API-3 c5.xlarge ยท TCP :443 API-4 c5.xlarge ยท TCP :443 WHY STATIC IP? Partners whitelist YOUR IP IP never changes (unlike ALB) Needed for: banking, B2B APIs On-prem firewalls need IPs ALB only has DNS (IPs rotate!)
NLB Use Cases Core
๐ŸŽฎ

Gaming

  • Millions of concurrent TCP/UDP connections
  • Ultra-low latency mandatory
  • Static IP for DNS pointing
  • Long-lived connections
๐Ÿ’ฐ

Financial / Trading

  • Microsecond latency requirements
  • Static IP for partner whitelisting
  • High-frequency trading connections
  • TLS passthrough
๐Ÿ“ก

IoT / Real-time

  • MQTT over TCP (IoT devices)
  • Millions of device connections
  • UDP for telemetry/streaming
  • Source IP for device identification
Architecture Diagram โ€” NLB + PrivateLink Advanced
Advanced Pattern โ€” NLB enables AWS PrivateLink for cross-account service exposure
Provider Account (Your Service) NLB VPC Endpoint Service (PrivateLink) Service Targets EC2 ECS Your microservice Consumer Account (Customer) VPC Endpoint (Interface) Private IP in VPC No internet needed ๐Ÿ–ฅ๏ธ Consumer App AWS PrivateLink Private connectivity ยท No internet exposure
TLS on NLB โ€” Termination Options Advanced
๐Ÿ”

TLS Termination at NLB

  • NLB decrypts TLS โ€” sends plain TCP to targets
  • Attach ACM certificate to NLB
  • Offloads CPU-intensive crypto from targets
  • Targets don't need certificates
  • Use when: targets are in private subnet
๐Ÿ”„

TLS Passthrough

  • NLB forwards encrypted traffic as-is
  • Target handles TLS termination
  • NLB never sees plaintext data
  • End-to-end encryption preserved
  • Use when: compliance requires end-to-end TLS
NLB Operational Details Advanced
๐Ÿ’ฐ

Cross-Zone Load Balancing โ€” Cost

  • NLB cross-zone is OFF by default
  • When enabled: inter-AZ data transfer charges apply
  • Unlike ALB (which is free and always on)
  • Enable when: uneven target distribution across AZs
  • Disable when: traffic is evenly distributed
  • Can be expensive for high-throughput workloads
  • Exam tip: know this cost difference vs ALB
๐Ÿ“ก

NLB UDP Behavior

  • UDP is connectionless โ€” no TCP handshake
  • Does NOT support sticky sessions for UDP
  • Health checks for UDP: send UDP packet
  • Success = response received; Failure = timeout
  • Can also use TCP/HTTP health check for UDP targets
  • UDP flows tracked by 5-tuple (src/dst IP+port+proto)
  • Use for: DNS, game state, telemetry, VoIP
๐Ÿง  Key Insight

NLB is for when you need raw TCP/UDP performance, static IPs, or PrivateLink. If your question mentions "static IP," "millions of requests," "UDP," "TCP passthrough," or "PrivateLink" โ€” the answer is NLB. For everything HTTP-related, use ALB instead.

Chapter Summary Introductory
  • NLB = Layer 4 โ€” sees TCP/UDP connections, not HTTP content โ€” routes by port only
  • Ultra-fast โ€” ~100ฮผs latency, millions of req/s, no warm-up needed
  • Static IP โ€” one per AZ, supports Elastic IP โ€” critical for firewall whitelisting
  • Source IP preserved โ€” targets see real client IP (no X-Forwarded-For needed)
  • PrivateLink โ€” only NLB can back a VPC Endpoint Service (cross-account private access)
  • TLS options โ€” terminate at NLB (offload crypto) or passthrough (end-to-end encryption)
  • Cross-zone โ€” OFF by default, inter-AZ data transfer costs when enabled (unlike ALB which is free)
  • UDP โ€” connectionless, no sticky sessions, 5-tuple flow tracking
  • Use cases โ€” gaming, financial trading, IoT, B2B APIs needing static IP, PrivateLink services
05
Chapter Five

Target Groups & Health Checks

What is a Target Group Introductory

A Target Group is the logical grouping of targets (instances, containers, Lambda functions, or IPs) that receive traffic from the load balancer. Think of it as a "destination pool" โ€” the load balancer sends traffic to the group, and the group distributes it among its members.

๐Ÿ‘‰ Mental model: Listener receives traffic โ†’ Rules evaluate โ†’ Matching rule forwards to Target Group โ†’ Target Group distributes to individual targets. The target group is the bridge between routing rules and actual compute.

Target Types Core
๐Ÿ–ฅ๏ธ

Instance Targets

  • Register by instance ID
  • ELB routes to primary private IP
  • Port specified at registration
  • Used with: EC2 instances, ASG
  • Source IP: NLB preserves, ALB uses X-Forwarded-For
  • Most common target type
๐Ÿ“ฆ

IP Targets

  • Register by IP address
  • Can target IPs outside the VPC
  • On-premises servers via Direct Connect
  • Other VPCs (peered or Transit Gateway)
  • ECS tasks with awsvpc networking
  • Multiple ports on same instance
ฮป

Lambda Targets (ALB only)

  • Register a Lambda function
  • ALB converts HTTP โ†’ Lambda event
  • Lambda response โ†’ HTTP response
  • Serverless backend behind ALB
  • One Lambda per target group
  • Great for lightweight APIs
โš“

ALB Targets (NLB only)

  • Register an ALB as NLB target
  • NLB (static IP) โ†’ ALB (content routing)
  • Best of both worlds combination
  • Static IP + path/host routing
  • Exam favorite: "static IP + HTTP routing"
  • Introduced in 2021
Health Checks โ€” How They Work Core

Health checks are the heartbeat of load balancing. Without them, ELB would blindly send traffic to dead targets. Health checks continuously probe each registered target โ€” if a target fails, ELB stops routing traffic to it. When it recovers, traffic resumes.

๐Ÿ“

How It Works

  • ELB sends a probe (HTTP GET or TCP connect)
  • Target must respond within timeout
  • Success = healthy response (e.g., HTTP 200)
  • Failure = timeout or wrong status code
  • Consecutive failures = mark unhealthy
  • Consecutive successes = mark healthy again
โš™๏ธ

Configuration

  • Protocol: HTTP, HTTPS, TCP, gRPC
  • Path: /health, /status, /ping
  • Port: traffic port or custom
  • Interval: 10-300 sec (default 30)
  • Timeout: 2-120 sec (default 5)
  • Healthy threshold: 2-10 (default 5)
  • Unhealthy threshold: 2-10 (default 2)
โœ…

Success Criteria

  • HTTP: status code match (200-499)
  • TCP: connection established
  • gRPC: gRPC status code
  • Default: 200 OK
  • Can set: "200-299" or "200,302"
  • Path should be lightweight (/health)
Concept Diagram โ€” Health Check Lifecycle Introductory
Concept โ€” Health check states: Initial โ†’ Healthy โ†’ Unhealthy โ†’ Healthy (recovery)
TIME โ†’ INITIAL Target registered Waiting for first health check pass 5ร— 200 HEALTHY โœ… Receives traffic Health checks pass every 30 seconds 2ร— fail UNHEALTHY โŒ NO traffic routed Removed from rotation Still being probed 5ร— 200 HEALTHY โœ… Traffic resumes Auto-recovered Back in rotation HEALTH CHECK MATH Time to detect failure: interval(30s) ร— unhealthy_threshold(2) = 60 seconds | Time to recover: interval(30s) ร— healthy_threshold(5) = 150 seconds
AWS Diagram โ€” Target Group with Health Checks Core
AWS Architecture โ€” ELB heath checks detect failure and re-route traffic automatically
ALB Health check: GET /health Every 30s Expect: 200 Target Group: web-tg (port 80, HTTP) i-0abc123 (web-1) 10.0.1.10:80 โœ… Healthy โ€” 12 consecutive passes i-0def456 (web-2) 10.0.2.20:80 โœ… Healthy โ€” 8 consecutive passes i-0ghi789 (web-3) 10.0.1.30:80 โŒ Unhealthy โ€” HTTP 503 (2 failures) โœ— NO traffic GET /health TARGET GROUP STATUS Total targets: 3 Healthy: 2 (receiving traffic) Unhealthy: 1 (drained) โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€ Traffic split: 50/50 to healthy web-3 auto-recovers when 5 consecutive checks pass Zero user impact!
Deregistration Delay (Connection Draining) Advanced

When a target is removed (scaling down, deployment, or unhealthy), ELB doesn't kill existing connections immediately. Deregistration delay gives in-flight requests time to complete:

โฑ๏ธ

How It Works

  • Target marked for deregistration
  • ELB stops sending NEW requests to it
  • Existing connections continue until complete
  • Or until deregistration delay expires
  • Default: 300 seconds (5 minutes)
  • Can set: 0โ€“3600 seconds
๐Ÿ’ก

Best Practices

  • Short-lived requests (APIs): set to 30-60s
  • Long-lived (WebSocket, uploads): set to 300-3600s
  • Set to 0 for instant termination (testing)
  • Critical for zero-downtime deployments
  • Works with Auto Scaling scale-in
  • Works with rolling deployment updates
Architecture Diagram โ€” Failover Behavior Core
Failover โ€” When AZ-a targets all fail, cross-zone balancing routes 100% to AZ-b
ELB Cross-zone ENABLED 100% โ†’ AZ-b AZ-a โš ๏ธ ALL UNHEALTHY EC2-1 โŒ EC2-2 โŒ 0% traffic โ€” all targets failed health checks AZ-b โœ… ALL HEALTHY EC2-3 โœ… EC2-4 โœ… 100% traffic โ€” absorbs all load โœ— 100% CROSS-ZONE LOAD BALANCING Without cross-zone: 50% traffic โ†’ dead AZ With cross-zone: ELB routes ALL to healthy AZ โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€ ALB: cross-zone always ON (free) NLB: cross-zone OFF by default (enable for HA, costs data transfer)
Sticky Sessions Advanced
๐Ÿช

Duration-Based (LB Cookie)

  • ELB generates cookie: AWSALB
  • Duration: 1 second to 7 days
  • Same client โ†’ same target for duration
  • Simple โ€” no app changes needed
  • Warning: uneven load if sessions are long
๐ŸŽฏ

Application-Based Cookie

  • App generates custom cookie
  • ELB reads it to maintain affinity
  • Cookie name must NOT start with AWSALB
  • App controls session lifecycle
  • More flexible โ€” app-aware routing

โš ๏ธ Sticky Sessions + WebSocket Limitation

Sticky sessions do NOT work with WebSocket connections. WebSocket maintains a persistent connection (no new HTTP requests to route), so cookie-based affinity is irrelevant. For WebSocket, the connection itself provides affinity โ€” once established, it stays on the same target. If you need WebSocket + multiple targets, use connection ID routing at the application level, not ELB stickiness.

๐Ÿง  Key Insight

Health checks are invisible to users but critical for reliability. They're how ELB achieves "zero-downtime" โ€” failed targets are silently removed, recovered targets automatically rejoin. Combine with cross-zone balancing for true fault tolerance across AZs.

Chapter Summary Introductory
  • Target Group = logical pool of targets (EC2, IP, Lambda, or ALB) โ€” destination for routing rules
  • Target types: instance (by ID), IP (cross-VPC/on-prem), Lambda (ALB only), ALB (NLB only)
  • Health checks = continuous probes every 10-300s โ€” unhealthy targets removed from rotation automatically
  • Thresholds: unhealthy=2 failures, healthy=5 successes โ€” tune for speed vs stability
  • Deregistration delay = 300s default โ€” allows in-flight requests to complete before target removed
  • Cross-zone: ALB always on (free), NLB off by default โ€” enables failover across AZs
  • Sticky sessions: bind client to same target via cookie โ€” use sparingly (causes uneven load)
06
Chapter Six

Security & Integration

Security Groups on ELB Core

Security groups control what traffic can reach your load balancer and what traffic your targets accept. The critical pattern is: allow public traffic to ELB, but restrict targets to only accept traffic FROM the ELB.

๐Ÿ›ก๏ธ

ALB Security Group

  • Inbound: port 443 from 0.0.0.0/0 (internet)
  • Inbound: port 80 from 0.0.0.0/0 (redirect to HTTPS)
  • Outbound: port 8080 to target SG
  • ALB always has a security group
  • Can restrict by IP range (internal ALB)
๐Ÿ”’

Target (EC2) Security Group

  • Inbound: port 8080 from ALB security group
  • NOT from 0.0.0.0/0!
  • Only ELB can talk to targets
  • Targets are in private subnet
  • No direct internet access to instances

๐Ÿ‘‰ The golden rule: Targets should ONLY allow inbound traffic from the ELB security group โ€” never from 0.0.0.0/0. This ensures all traffic passes through the load balancer (health checks, routing, TLS) and targets aren't directly exposed.

NLB Security Differences Core
โš ๏ธ

NLB (Before 2023)

  • NLB did NOT have security groups
  • Traffic passed through to targets
  • Target SG had to allow client IPs directly
  • Because NLB preserves source IP
  • Made security rules complex
โœ…

NLB (After 2023)

  • NLB now supports security groups
  • Target SG can reference NLB SG
  • Same pattern as ALB now possible
  • Simplified security management
  • Exam: know both old and new behavior
Concept Diagram โ€” Security Group Chain Introductory
Concept โ€” Security groups create a trust chain: Internet โ†’ ELB SG โ†’ Target SG
๐ŸŒ Internet SG: sg-elb ALB Allow IN: 443 from 0.0.0.0/0 Allow OUT: 8080 to sg-target TLS termination here SG: sg-target EC2 Targets Allow IN: 8080 from sg-elb DENY: all from 0.0.0.0/0 Only ELB can reach targets! :443 โœ… :8080 โœ… from sg-elb โœ— Direct access BLOCKED โ€” not from sg-elb
TLS / SSL Termination Core

TLS termination means the load balancer decrypts HTTPS traffic and forwards plain HTTP to targets. This offloads CPU-intensive cryptography from your application servers.

๐Ÿ”

TLS at ALB (Most Common)

  • Attach ACM certificate to ALB
  • ALB decrypts HTTPS โ†’ HTTP to targets
  • Targets on port 80/8080 (plain HTTP)
  • SNI support (multiple certs)
  • Free ACM certificates
๐Ÿ”„

End-to-End Encryption

  • ALB decrypts, then re-encrypts to targets
  • Target group protocol: HTTPS
  • Targets need their own certs
  • Required for: PCI compliance, zero-trust
  • More CPU on targets
๐Ÿ“‹

SSL Policies

  • Choose TLS version (1.2, 1.3)
  • Choose cipher suites
  • Recommended: TLSv1.2+ only
  • ELBSecurityPolicy-TLS13-1-2-2021-06
  • Disable old protocols (SSLv3, TLS 1.0)
AWS Diagram โ€” TLS Termination Architecture Core
AWS Architecture โ€” TLS termination at ALB with ACM certificate
๐Ÿ‘ค Client HTTPS :443 ๐Ÿ”’ ENCRYPTED TLS 1.3 ALB ACM Certificate attached *.example.com TLS terminated HERE Decrypts โ†’ plain HTTP SNI: multiple domains ๐Ÿ”“ PLAIN HTTP port 8080 EC2 Targets Port 8080 (HTTP) ECS Tasks Port 3000 (HTTP) ACM Free TLS cert Auto-renews Managed by AWS Client โ†’ HTTPS (encrypted) โ†’ ALB โ†’ HTTP (plain) โ†’ Targets Targets need NO certificates โ€” ALB handles all crypto
Integration with AWS Services Core
๐Ÿ›ก๏ธ

WAF (Web Application Firewall)

  • Attach AWS WAF to ALB
  • Block SQL injection, XSS
  • Rate limiting per IP
  • Geo-blocking
  • Custom rules & managed rule groups
  • ALB only (not NLB)
๐Ÿฐ

AWS Shield

  • Shield Standard: free, auto-enabled
  • Protects against L3/L4 DDoS
  • Shield Advanced: $3000/mo
  • L7 DDoS protection + support
  • SRT (Shield Response Team)
  • Cost protection during attacks
๐Ÿ”‘

Cognito / OIDC Auth

  • ALB authenticates before forwarding
  • Cognito User Pool integration
  • Any OIDC provider (Google, Okta)
  • Auth at LB level โ€” app doesn't need auth code
  • ALB only feature
๐Ÿ“Š

CloudWatch

  • Metrics: RequestCount, TargetResponseTime
  • HealthyHostCount, UnhealthyHostCount
  • HTTPCode_ELB_5XX (LB errors)
  • HTTPCode_Target_5XX (target errors)
  • Alarms for monitoring
๐Ÿ“

Access Logs

  • Log every request to S3
  • Client IP, latency, response code
  • Target chosen, health status
  • 5/15 minute intervals
  • Free (only S3 storage cost)
๐Ÿ”

Global Accelerator

  • Static IPs + AWS backbone routing
  • Works with ALB (static IP for ALB!)
  • Improves global latency
  • Instant failover between regions
  • Alternative to NLB for static IP
Architecture Diagram โ€” Full Security Stack Advanced
Production Security โ€” Full protection stack from edge to target
๐Ÿ˜ˆ Attacker DDoS / SQLi Shield L3/L4 DDoS BLOCKED Auto โœ… WAF L7 rules SQLi / XSS Rate limit Geo-block BLOCKED ALB TLS termination Cognito auth Routing rules Health checks SG: sg-elb Targets Private subnet SG: from sg-elb only No internet access DEFENSE IN DEPTH Shield โ†’ WAF โ†’ ALB (auth+TLS) โ†’ SG โ†’ Target DDoS flood stopped here SQLi/XSS stopped here Unauthed stopped here
๐Ÿง  Key Insight

ELB is not just about load balancing โ€” it's the natural point for TLS termination, authentication, WAF enforcement, and security group chaining. A properly configured ALB + WAF + Shield + SG chain provides defense-in-depth from DDoS to SQL injection to unauthorized access.

Chapter Summary Introductory
  • Security Groups: ALB allows 0.0.0.0/0 :443, targets allow only from ALB SG โ€” never expose targets directly
  • NLB SGs: now supported (since 2023) โ€” same pattern as ALB possible
  • TLS termination: ALB decrypts HTTPS โ†’ plain HTTP to targets โ€” use ACM for free auto-renewing certs
  • WAF: attach to ALB for SQL injection, XSS, rate limiting, geo-blocking โ€” ALB only
  • Shield: Standard (free, auto) protects L3/L4 DDoS; Advanced ($3K/mo) adds L7 + support team
  • Cognito/OIDC: ALB can authenticate users before forwarding โ€” auth at infrastructure level
  • Access Logs: every request logged to S3 โ€” client IP, latency, status, target chosen
07
Chapter Seven

Architecture Patterns

Pattern 1 โ€” ALB + EC2 Auto Scaling (Classic Web App) Core

The most common AWS architecture pattern. ALB handles routing and health checks, Auto Scaling Group handles capacity. Together they create an elastic, self-healing web tier.

Pattern 1 โ€” ALB + EC2 Auto Scaling Group (classic 3-tier web application)
VPC โ€” Multi-AZ Production Setup ๐ŸŒ Route 53 โ†’ ALB DNS Public Subnets ALB HTTPS :443 /api/* โ†’ API TG /web/* โ†’ Web TG WAF attached ACM cert Access logs โ†’ S3 Multi-AZ Private Subnets โ€” Auto Scaling Group ASG: min=2, desired=4, max=8 AZ-a web-1 healthy web-2 healthy AZ-b web-3 healthy web-4 healthy โ†• Scales 2โ€“8 based on CPU/requests RDS (Multi-AZ) Primary (AZ-a) + Standby (AZ-b) Auto failover CLASSIC PATTERN โœ“ Self-healing โœ“ Auto-scaling โœ“ Multi-AZ HA โœ“ Zero downtime deploy
โœ…

Why This Pattern Works

  • ALB handles routing + TLS + health checks
  • ASG handles capacity (scales up on load)
  • Unhealthy instances auto-replaced by ASG
  • Multi-AZ = AZ failure is survivable
  • Rolling deploys via ASG instance refresh
  • Cost-effective: scale down at night
๐ŸŽฏ

Best For

  • Traditional web applications
  • Monolithic apps (before containerization)
  • WordPress / PHP / Java web apps
  • Predictable traffic patterns
  • Teams familiar with EC2
  • Exam tip: most common pattern tested
Pattern 2 โ€” ALB + ECS Fargate (Modern Containers) Core

The modern standard for running microservices on AWS. ALB routes different paths to different ECS services โ€” each service scales independently. No servers to manage (Fargate = serverless containers).

Pattern 2 โ€” ALB + ECS Fargate microservices (production-grade)
ALB /api/orders/* /api/users/* /api/payments/* /web/* HTTPS :443 WAF + Cognito ECS Cluster (Fargate) Orders Service task task task 3 tasks Users Service task task 2 tasks Payments Service task task 2 tasks Web Frontend (SSR) Data Layer RDS (orders) DynamoDB (users) Redis (cache) WHY FARGATE? No EC2 to manage Per-service scaling Deploy independently Containers = portable Modern standard โญ
Pattern 3 โ€” NLB for High-Performance Systems Advanced
๐ŸŽฎ

Gaming Architecture

  • NLB with Elastic IPs
  • UDP for game state (low latency)
  • TCP for chat/auth
  • Millions of concurrent players
  • Source IP preserved (anti-cheat)
  • Static IP for DNS (game clients)
๐Ÿ’ฐ

Financial Trading

  • NLB for microsecond latency
  • TLS passthrough (end-to-end audit)
  • Static IP for partner whitelisting
  • TCP connections for FIX protocol
  • Cross-zone disabled (data locality)
  • PrivateLink for cross-account access
Pattern 4 โ€” NLB + ALB Combo (Static IP + HTTP Routing) Advanced

When you need both a static IP (NLB) and content-based routing (ALB) โ€” the solution is chaining them. This is an exam favorite.

Pattern 4 โ€” NLB โ†’ ALB chain gives static IP + Layer 7 routing
๐Ÿข Partner Needs static IP NLB EIP: 52.1.2.3 TCP :443 Target type: ALB ALB Layer 7 routing /api/* โ†’ TG-1 /web/* โ†’ TG-2 WAF + Auth API (ECS) 3 tasks Web (EC2) 2 instances ๐ŸŽฏ Static IP + Content Routing = NLB โ†’ ALB
Pattern 5 โ€” Multi-Tier Load Balancing Advanced
Pattern 5 โ€” External ALB (public) + Internal ALB (private) for true multi-tier
๐ŸŒ Internet External ALB Public-facing Internet โ†’ here WAF + TLS โ†’ Web tier Web Tier EC2 EC2 Calls internal ALB for backend APIs Internal ALB Private only No internet access /orders/* โ†’ svc-1 /users/* โ†’ svc-2 Orders Svc ECS Fargate Users Svc ECS Fargate RDS Private subnet MULTI-TIER ISOLATION External ALB (public) โ†’ Web โ†’ Internal ALB (private) โ†’ API โ†’ DB
Pattern Summary โ€” Quick Reference Core
Pattern LB Type Best For
ALB + EC2 ASG ALB Traditional web apps, monoliths, WordPress
ALB + ECS Fargate ALB Microservices, containers, modern apps
NLB (high-perf) NLB Gaming, IoT, financial, PrivateLink
NLB โ†’ ALB chain NLB + ALB Static IP + HTTP routing (exam favorite)
Multi-tier (ext+int) 2ร— ALB Enterprise apps, service isolation, compliance
๐Ÿง  Key Insight

The "right" pattern depends on your requirements: ALB + ASG for traditional apps, ALB + Fargate for modern microservices, NLB for non-HTTP or extreme performance, NLBโ†’ALB for static IP + routing, and multi-tier ALBs for enterprise isolation. Know all five โ€” they are frequently tested across AWS exams.

Chapter Summary Introductory
  • Pattern 1 (ALB + EC2 ASG): classic self-healing web tier โ€” ALB routes, ASG scales, Multi-AZ for HA
  • Pattern 2 (ALB + ECS Fargate): modern microservices โ€” path routing to independent services, no servers to manage
  • Pattern 3 (NLB high-perf): gaming/financial โ€” static IP, microsecond latency, TCP/UDP, PrivateLink
  • Pattern 4 (NLB โ†’ ALB): best of both โ€” static IP from NLB + Layer 7 routing from ALB (exam favorite!)
  • Pattern 5 (Multi-tier): external ALB (public) โ†’ web tier โ†’ internal ALB (private) โ†’ API services โ†’ DB