SkarpSkarp

Chapter 10 of 26

Elastic Load Balancing, Amazon Route 53, and Traffic Management for High Availability

Traffic distribution and intelligent routing are key to building fault-tolerant systems. This module connects Elastic Load Balancing with Amazon Route 53 to implement resilient front ends and failover strategies.

27 min readen

Big Picture: Traffic Management for High Availability

The Request Journey

A user request takes two main steps: Route 53 DNS chooses which endpoint (Region/load balancer/IP), then Elastic Load Balancing chooses which specific target (instance, IP, Lambda) handles it.

Why This Matters

This topic is central to the Reliability pillar: keeping workloads available and consistent, even during failures. You will design multi‑AZ front ends and DNS‑level failover using ELB and Route 53.

Your Learning Goals

You will learn to choose ELB types, configure health checks and cross‑zone load balancing, pick Route 53 routing policies, and combine them for multi‑AZ and multi‑Region high availability.

Elastic Load Balancing Types and Core Behaviors

Regional Scope

Elastic Load Balancing is a Regional service. A load balancer lives in one Region and can span multiple Availability Zones, distributing traffic across registered targets.

Application Load Balancer

ALB is Layer 7 (HTTP/HTTPS/WebSocket). It supports path and host‑based routing, integrates with WAF and Cognito, and sends traffic to target groups of EC2, IPs, or Lambda.

Network Load Balancer

NLB is Layer 4 (TCP/UDP/TLS). It offers static IPs, very high throughput and low latency, and is used for non‑HTTP protocols or extremely high performance needs.

Classic Load Balancer

CLB is legacy. It supports basic Layer 4/7 but is not recommended for new designs. In exam questions, ALB or NLB is usually the better answer unless legacy is required.

Targets, Target Groups, Health Checks, and Cross‑Zone Load Balancing

Target Groups

Target groups group your EC2 instances, IPs, or Lambdas. Listeners on ALB/NLB forward requests to one or more target groups based on rules like path or host.

ELB Health Checks

Each target group has health checks. Unhealthy targets are removed from rotation. For ALB, HTTP checks like `GET /health` must return 200‑399 to be considered healthy.

Cross‑Zone Load Balancing

Cross‑zone balancing lets each LB node send traffic to targets in all AZs, avoiding per‑AZ imbalance. ALB has it always on; NLB can enable or disable it per load balancer.

Exam Angle

Watch for scenarios with uneven instances per AZ. If cross‑zone is off, traffic splits by AZ, not by instance count. With cross‑zone on, traffic spreads evenly across all healthy targets.

Visualizing a Multi‑AZ ALB Setup (with TLS and Security Context)

Architecture Picture

Imagine Route 53 resolving `app.example.com` to an ALB in `us-east-1` spanning two AZs. Each AZ has EC2 web instances in private subnets behind the ALB.

Request Flow

1) Browser resolves DNS via Route 53. 2) Route 53 returns ALB alias. 3) Browser makes HTTPS to ALB (ACM cert). 4) ALB forwards to healthy instances, using cross‑zone load balancing.

Health and Security

If one AZ’s instances fail health checks, ALB shifts traffic to the other AZ. TLS termination at ALB plus security groups aligns with the Security and Reliability pillars.

Amazon Route 53 Fundamentals and Alias Records

Route 53 as DNS

Route 53 is a global, managed DNS service. Hosted zones store records for domains like `example.com`, including A, AAAA, CNAME, and alias records.

Alias Records

Alias records are Route 53 specific. They behave like A/AAAA records but can point to AWS resources (ELB, CloudFront, S3, API Gateway) and can be used at the zone apex.

Alias vs CNAME

CNAME cannot be used at `example.com` itself and cannot point to some AWS endpoints as cleanly. Alias records are preferred for mapping to load balancers in exam scenarios.

DNS vs Load Balancing

Route 53 only answers DNS queries; it does not inspect HTTP headers. Use Route 53 to pick an endpoint (Region/LB), then ELB to balance across instances inside that endpoint.

Route 53 Routing Policies: Simple, Weighted, Latency, Failover, Geolocation

Simple and Weighted

Simple routing: one record per name, no health checks or splitting. Weighted routing: multiple records with weights (e.g., 80/20) for traffic shifting or A/B tests, with optional health checks.

Latency‑Based Routing

Latency‑based routing sends users to the Region with the lowest latency according to AWS measurements. Each record is associated with a specific Region.

Failover Routing

Failover routing uses primary and secondary records. If the primary’s health check fails, Route 53 returns the secondary, enabling DNS‑level failover.

Geolocation Routing

Geolocation routes based on user location (country, continent, default). It is used for localization or compliance, not for minimizing latency.

Designing Multi‑Region Routing with Route 53 and ELB

Scenario Setup

You have a stateless web app in us‑east‑1 and eu‑west‑1. Each Region has an ALB across two AZs with Auto Scaling behind it. You need global HA and good performance.

Latency‑Based Solution

Create two latency‑based alias records for `app.example.com`, each pointing to its Regional ALB with health checks. Users go to the lowest‑latency Region; unhealthy Regions are removed.

Failover Solution

Create failover alias records: primary → us‑east‑1 ALB with health check, secondary → eu‑west‑1 ALB. Secondary only receives traffic when the primary is unhealthy.

Choosing on the Exam

Performance for global users → latency‑based. Clear active/DR Regions → failover. Always remember: Route 53 picks the Region; ALB balances inside the Region.

Thought Exercise: End‑to‑End Failover Design

Work through this scenario mentally to solidify how ELB and Route 53 interact.

Scenario

You host `shop.example.com` with these requirements:

  • Highly available web tier.
  • Primary Region: `ap-southeast-1` (Singapore).
  • Disaster recovery Region: `ap-south-1` (Mumbai), warm standby.
  • If the entire primary Region is down, users should be redirected to a static "maintenance" page hosted in the DR Region.

Your design task

Pause and, in your own words, decide:

  1. What AWS resources do you deploy in each Region?
  2. How do you configure ELB and health checks?
  3. Which Route 53 routing policy do you choose, and how do you wire the records?

Hint path (do this step‑by‑step)

  • Step 1: In `ap-southeast-1`, imagine an ALB across at least two AZs, with Auto Scaling instances behind it.
  • Step 2: In `ap-south-1`, imagine an S3 static website bucket (or CloudFront) serving a "maintenance" page, optionally also fronted by an ALB if you want dynamic capacity later.
  • Step 3: Decide whether you want active‑active or active‑passive behavior. The requirement says "DR Region" and "maintenance page" → active‑passive.
  • Step 4: Ask: which Route 53 routing policy directly models primary vs secondary? (Answer in your head before reading on.)

Self‑check

You should end up with something like:

  • Primary: alias to ALB in `ap-southeast-1` with a health check on `/health`.
  • Secondary: alias to S3/CloudFront or ALB in `ap-south-1`.
  • Routing policy: failover (primary and secondary records).

If your design matches this logic, you are correctly combining ELB, health checks, and Route 53 failover.

Quiz 1: ELB and Route 53 Basics

Check your understanding of core concepts before moving on.

You are designing `example.com` where users should be routed to the closest Region by network latency. Each Region has an ALB across multiple AZs. Which combination is MOST appropriate?

  1. Use a single ALB in one Region and Route 53 simple routing with an alias to that ALB.
  2. Use Route 53 latency-based routing with alias records pointing to each Regional ALB.
  3. Use Route 53 weighted routing with equal weights for each Regional ALB.
  4. Use Route 53 geolocation routing with records pointing to each Regional ALB.
Show Answer

Answer: B) Use Route 53 latency-based routing with alias records pointing to each Regional ALB.

Latency-based routing is designed to send users to the Region with the lowest network latency. You create latency-based alias records, each pointing to a Regional ALB. Simple routing does not consider latency. Weighted routing splits traffic by weight, not latency. Geolocation uses user location (country/continent), not measured latency.

Quiz 2: Health Checks and Cross‑Zone Load Balancing

Test how well you understand health behavior and traffic distribution.

An ALB in `us-west-2` spans two AZs: AZ‑A with 2 healthy instances, AZ‑B with 8 healthy instances. Cross‑zone load balancing is ENABLED. Roughly what percentage of total traffic does each instance receive?

  1. Instances in AZ‑A get 25% each; instances in AZ‑B get 6.25% each.
  2. All 10 instances receive about 10% of the traffic each.
  3. Instances in AZ‑A get 50% each; instances in AZ‑B get 5% each.
  4. AZ‑A receives all traffic because it has fewer instances.
Show Answer

Answer: B) All 10 instances receive about 10% of the traffic each.

With cross-zone load balancing enabled, the ALB distributes traffic evenly across all healthy targets in all enabled AZs. With 10 instances total, each gets roughly 10%. Option A describes the behavior when cross-zone is DISABLED (traffic split per AZ).

Key Term Review: ELB and Route 53

Flip through these cards to solidify terminology before you move on.

Application Load Balancer (ALB)
A Layer 7 load balancer that routes HTTP/HTTPS/WebSocket traffic based on request content (path, host, headers), integrates with WAF and Cognito, and uses target groups of EC2, IPs, or Lambda.
Network Load Balancer (NLB)
A Layer 4 load balancer optimized for TCP/UDP/TLS with ultra‑low latency, static IP support, and very high throughput, used for non‑HTTP or highly performance‑sensitive workloads.
Target group
A logical grouping of targets (EC2 instances, IPs, Lambda functions, or ALBs) that a load balancer forwards traffic to, with its own health check configuration.
Cross‑zone load balancing
A feature where each load balancer node distributes traffic across all healthy targets in all enabled AZs, not just within its own AZ, smoothing traffic across instances.
Alias record (Route 53)
A Route 53 specific record type that acts like an A/AAAA record but can point to AWS resources (e.g., ALB, NLB, CloudFront, S3) and can be used at the zone apex.
Weighted routing policy
A Route 53 policy that splits DNS responses across multiple records according to assigned weights, often used for gradual migrations, blue/green, or A/B testing.
Latency‑based routing policy
A Route 53 policy that routes users to the Region providing the lowest network latency based on AWS measurements, typically used with Regional endpoints like ALBs.
Failover routing policy
A Route 53 policy using primary and secondary records. If the primary’s health check fails, Route 53 responds with the secondary record, enabling DNS‑level failover.
Geolocation routing policy
A Route 53 policy that routes users based on their geographic location (country, continent, or default), often used for localization or compliance requirements.
Health check (Route 53 vs ELB)
ELB health checks determine which targets receive traffic inside a Region. Route 53 health checks determine which DNS records are returned to clients, enabling DNS‑level failover.

Putting It All Together and Next Steps in Your Path

Core Patterns

Remember three big patterns: single‑Region multi‑AZ with ALB; multi‑Region active‑active using latency‑based or weighted routing; and multi‑Region active‑passive using failover routing.

Typical Traps

Watch for CNAME vs alias at the zone apex, assuming Route 53 can see HTTP paths, ignoring health checks, or forgetting that ELB is Regional while Route 53 is global.

Next Steps in Skarp

Reinforce this by taking the next networking/HA mock exam, then use your gap guide and spaced review queue to drill whichever routing policies or ELB details you missed.

Key Terms

Alias record
A Route 53 specific record type that acts like an A/AAAA record but can point to AWS resources (e.g., ALB, NLB, CloudFront, S3) and can be used at the zone apex.
Health check
A probe used by ELB or Route 53 to determine whether a target or endpoint is healthy. ELB health checks control traffic distribution within a Region; Route 53 health checks control which DNS records are returned.
Target group
A logical grouping of targets (EC2 instances, IPs, Lambda functions, or ALBs) that a load balancer forwards traffic to, with its own health check configuration.
Failover routing policy
A Route 53 policy using primary and secondary records. If the primary’s health check fails, Route 53 responds with the secondary record, enabling DNS‑level failover.
Weighted routing policy
A Route 53 policy that splits DNS responses across multiple records according to assigned weights, often used for gradual migrations, blue/green, or A/B testing.
Geolocation routing policy
A Route 53 policy that routes users based on their geographic location (country, continent, or default), often used for localization or compliance requirements.
Cross‑zone load balancing
A feature where each load balancer node distributes traffic across all healthy targets in all enabled AZs, not just within its own AZ, smoothing traffic across instances.
Network Load Balancer (NLB)
A Layer 4 load balancer optimized for TCP/UDP/TLS with ultra‑low latency, static IP support, and very high throughput, used for non‑HTTP or highly performance‑sensitive workloads.
Latency‑based routing policy
A Route 53 policy that routes users to the Region providing the lowest network latency based on AWS measurements, typically used with Regional endpoints like ALBs.
Application Load Balancer (ALB)
A Layer 7 load balancer that routes HTTP/HTTPS/WebSocket traffic based on request content (path, host, headers), integrates with WAF and Cognito, and uses target groups of EC2, IPs, or Lambda.

Finished reading?

Test your understanding with a custom practice exam on this chapter.

Test yourself