AWS Global Traffic Management — Overview
AWS provides three services for routing global traffic: Route 53 (DNS-based routing), Global Accelerator (network-layer routing with static IPs), and CloudFront (CDN with edge caching). Each solves different problems and they can be combined. Understanding when to use which — especially for failover scenarios — is a recurring SAP-C02 exam pattern.
Feature Comparison
| Feature | Route 53 | Global Accelerator | CloudFront |
|---|---|---|---|
| Layer | DNS (Layer 7) | Network (Layer 3/4) | Application (Layer 7 CDN) |
| IPs | Returns endpoint IPs (change on failover) | 2 static anycast IPs (never change) | Dynamic edge IPs (managed) |
| Protocols | Any (DNS resolves for all) | TCP, UDP | HTTP, HTTPS, WebSocket |
| Caching | DNS caching (TTL) | No caching (pass-through) | Full content caching at edge |
| Failover speed | DNS TTL (typically 60s, resolvers may cache longer) | Seconds (network-level rerouting) | Seconds (origin failover group) |
| DDoS protection | Route 53 is DDoS-resilient by design | AWS Shield Standard included | AWS Shield Standard + WAF integration |
| Client IP | Client connects directly to endpoint | Preserves client IP (ALB endpoints) | X-Forwarded-For header |
| Cost | $0.50/hosted zone + $0.40/M queries | $0.025/hr fixed + $0.015-0.035/GB | $0/hr + $0.085/GB (first 10TB) + requests |
| Best for | DNS foundation, routing policies, private DNS | Static IPs, instant failover, TCP/UDP, gaming | Caching, HTTPS acceleration, edge compute |
Route 53 Routing Policies
| Policy | How It Works | Use Case |
|---|---|---|
| Simple | Returns all values (client picks randomly) | Single resource, no health checks needed |
| Weighted | Distribute traffic by percentage (e.g., 70/30) | A/B testing, gradual migration, blue/green DNS |
| Latency | Route to region with lowest latency for user | Multi-region active-active (performance-based) |
| Failover | Primary → Secondary when health check fails | Active-passive DR |
| Geolocation | Route based on user’s geographic location | Content localization, regulatory compliance (data sovereignty) |
| Geoproximity | Route based on distance + configurable bias | Shift traffic between regions with bias adjustment |
| Multivalue | Returns up to 8 healthy records (client-side load balance) | Simple load distribution with health checks |
Global Accelerator — Deep Dive
- How it works: Client → nearest AWS edge (via anycast IPs) → AWS global backbone → endpoint in target region. Traffic enters AWS network at the closest edge, avoiding internet congestion.
- Endpoints: ALB, NLB, EC2, Elastic IP. Multiple endpoint groups (one per region).
- Traffic dials: Set percentage of traffic per endpoint group (0-100%). Use for gradual regional cutover.
- Endpoint weights: Distribute within an endpoint group (similar to ALB weighted target groups).
- Client IP preservation: Works with ALB endpoints — application sees the real client IP, not the accelerator IP.
- Custom routing: Deterministically route specific clients to specific endpoints (gaming, VoIP).
CloudFront — Failover & Edge
- Origin Failover Groups: Define primary + secondary origins. If primary returns 5xx/4xx, CloudFront automatically routes to secondary. Failover in seconds (no DNS delay).
- Lambda@Edge: Run code at edge locations (viewer request/response, origin request/response). Use for auth, header manipulation, URL rewriting, A/B testing.
- CloudFront Functions: Lightweight (1ms max), for simple tasks — header manipulation, URL redirects, cache key normalization. 10x cheaper than Lambda@Edge.
- Origin Shield: Additional caching layer between edge and origin. Reduces origin load for globally distributed requests hitting different edge locations.
Decision Guide — When to Use Which
| Requirement | Choose | Why |
|---|---|---|
| Cache content at edge for global users | CloudFront | CDN with 400+ edge locations, reduces latency + origin load |
| Static IPs that never change (allowlisting) | Global Accelerator | 2 fixed anycast IPs regardless of backend changes |
| Instant failover without DNS delay | Global Accelerator | Network-level reroute in seconds (no TTL caching) |
| Non-HTTP protocol (TCP gaming, UDP VoIP) | Global Accelerator | Supports TCP/UDP. CloudFront is HTTP(S) only. |
| Route based on user location (regulatory) | Route 53 Geolocation | Ensures users in specific countries hit specific endpoints |
| Active-passive DR with health checks | Route 53 Failover | Simple primary/secondary with health check trigger |
| A/B test between two versions | Route 53 Weighted | Split traffic by percentage (e.g., 90% old / 10% new) |
| Reduce data transfer costs | CloudFront | CF egress is cheaper than direct EC2/S3 egress |
Combining All Three
For a globally distributed, highly available application:
- Route 53: DNS foundation — latency-based routing to nearest region, alias records to CloudFront/GA
- CloudFront: Cache static + dynamic content at edge (reduces origin load, lowers latency for HTTP)
- Global Accelerator: For non-cacheable real-time traffic (APIs, WebSocket, gaming) or when you need static IPs + instant failover
Example: Route 53 alias → CloudFront (for website/API caching) + Route 53 alias → Global Accelerator (for real-time gaming servers on TCP/UDP).
Exam Tips
| Exam | Key Points |
|---|---|
| SAP-C02 | “Static IPs” → Global Accelerator. “Failover without DNS TTL delay” → Global Accelerator. “Cache at edge” → CloudFront. “Route by country” → Route 53 Geolocation. “Lowest latency” → Route 53 Latency + CloudFront. “Gradual traffic shift” → Route 53 Weighted or GA traffic dials. “Client IP preservation for auditing” → Global Accelerator with ALB. “Origin failover for 5xx errors” → CloudFront origin groups. |
AWS Certification Exam Practice Questions
Question 1:
A company runs a multi-region application. After a regional outage, some users continue hitting the failed region for up to 2 minutes because their DNS resolvers cache the old IP. The company needs failover to complete within 5 seconds for all users. Which solution achieves this?
- Reduce Route 53 TTL to 5 seconds
- Replace Route 53 failover routing with AWS Global Accelerator
- Add CloudFront in front with origin failover groups
- Use Route 53 multivalue routing with health checks
Show Answer
Answer: B — Global Accelerator routes at the network layer using anycast. When health checks detect a region failure, traffic is rerouted to the next healthy endpoint in seconds — without any DNS caching delay. The client’s IP address points to Global Accelerator’s static anycast IPs, which never change. Reducing TTL to 5s doesn’t guarantee resolvers honor it (many cache longer regardless).
Question 2:
A financial services company’s API requires static IP addresses that clients can allowlist in their firewalls. The API runs in two regions for high availability. When one region fails, traffic must automatically shift to the other region without clients changing their firewall rules. Which service provides this?
- Route 53 with Elastic IP addresses in each region
- AWS Global Accelerator with endpoint groups in both regions
- CloudFront with custom domain and origin failover
- Network Load Balancer with static IPs in each region
Show Answer
Answer: B — Global Accelerator provides 2 static anycast IPs that clients allowlist once. These IPs never change regardless of which backend region is serving traffic. If one region fails, GA reroutes to the healthy region automatically — same IPs, no client changes. Route 53 with Elastic IPs would require DNS changes (different IPs per region). NLB IPs are per-region, not global.
Question 3:
A company’s website serves both static content (images, CSS, JS) and dynamic API responses. They want to reduce latency globally for static content via caching, while ensuring dynamic API calls always reach the origin. Which architecture provides this?
- Global Accelerator for everything (static + dynamic)
- CloudFront with two cache behaviors: static (high TTL) + dynamic (TTL=0, forward all headers)
- Route 53 latency routing to ALB in each region
- CloudFront for static only + Global Accelerator for dynamic API
Show Answer
Answer: B — CloudFront supports multiple cache behaviors on the same distribution. Configure /static/* with long TTL (cached at edge) and /api/* with TTL=0 or cache disabled (always forwarded to origin). Both benefit from CloudFront’s edge network (TLS termination closer to user, optimized connections to origin) even without caching. This is simpler than using two separate services (D).
Question 4:
A company needs to route users to the nearest AWS region for lowest latency. They also need to ensure users in the EU always hit the eu-west-1 region regardless of latency (GDPR compliance). Which combination of Route 53 policies achieves this?
- Latency-based routing only (EU users naturally route to eu-west-1)
- Geolocation routing for EU (→ eu-west-1) + Latency routing for all others (→ nearest region)
- Geoproximity with bias to attract EU traffic to eu-west-1
- Weighted routing with 100% to eu-west-1 for EU clients
Show Answer
Answer: B — Geolocation routing guarantees users from specified locations (Europe) always hit the designated endpoint (eu-west-1), regardless of latency. For non-EU users, latency-based routing sends them to the closest region. You can combine policies: create a Geolocation record for EU → eu-west-1, and a Latency record as default for everyone else. Latency alone (A) might route some EU users to us-east-1 if it has lower latency.
Question 5:
A company’s CloudFront distribution returns 5xx errors when the origin ALB in us-east-1 becomes unhealthy. They want CloudFront to automatically serve from a backup ALB in us-west-2 when the primary fails. How should they configure this?
- Create a Route 53 failover record pointing to both ALBs, use as CloudFront origin
- Configure a CloudFront origin group with us-east-1 ALB as primary and us-west-2 ALB as secondary
- Add a Lambda@Edge function that detects errors and redirects to us-west-2
- Create two separate CloudFront distributions with Route 53 failover between them
Show Answer
Answer: B — CloudFront origin groups define a primary and secondary origin. If the primary returns specific HTTP error codes (5xx, 4xx), CloudFront automatically retries the request against the secondary origin. Failover is transparent to the client and happens in seconds. No DNS changes, no Lambda logic needed. This is the built-in CloudFront origin failover mechanism.
Related Posts
- Global Accelerator vs CloudFront
- Multi-Region Active-Active Architecture
- Disaster Recovery Architecture
- Hybrid Cloud Networking
References
- Route 53 Routing Policies — AWS Docs
- Global Accelerator Performance — AWS Blog
- CloudFront Origin Failover — AWS Docs
- Improve Availability with CloudFront — AWS Blog
Frequently Asked Questions
When should I use Global Accelerator vs CloudFront?
Use CloudFront when you need content caching at edge (reduces origin load, lowers latency for cacheable content). Use Global Accelerator when you need static IPs, instant failover without DNS delay, TCP/UDP protocol support, or client IP preservation. CloudFront is HTTP(S) only; GA supports any TCP/UDP protocol. For many applications, CloudFront alone is sufficient.
How do Route 53 health checks work?
Route 53 sends requests to your endpoint at configurable intervals (10s or 30s). If the endpoint fails to respond (or returns unhealthy status) for a configurable threshold, Route 53 marks it unhealthy and stops routing traffic to it. Health checks can monitor: HTTP/HTTPS endpoints, TCP connections, CloudWatch alarms, or calculated (combine other health checks with AND/OR logic).
Can I use all three services together?
Yes — this is common for complex applications. Route 53 provides the DNS foundation (alias records to CloudFront or GA). CloudFront handles cacheable HTTP traffic (website, static assets, API responses). Global Accelerator handles non-cacheable real-time traffic (gaming, IoT, financial feeds) or when static IPs are required. Each serves a different traffic type.