While preparing for the AWS SAP-C02, many candidates get confused by multi-region failover strategies for CloudFront distributions. In the real world, this is fundamentally a decision about RPO/RTO requirements vs. Infrastructure Duplication Costs. Let’s drill into a simulated scenario.
The Scenario #
GlobalStreamMedia operates a video analytics platform serving customers across six continents. The platform delivers personalized dashboards generated dynamically by a fleet of Amazon EC2 instances. These instances run in an Auto Scaling group behind an Application Load Balancer (ALB) in the us-east-1 region. To optimize global latency, the company uses an Amazon CloudFront distribution with the ALB as the origin. DNS is managed through Amazon Route 53, with a simple A record (analytics.globalstreammedia.io) pointing to the CloudFront distribution.
The CTO has mandated that the architecture must withstand a complete regional failure without customer-facing downtime exceeding 2 minutes.
Key Requirements #
Design a solution that provides automatic regional failover with minimal RTO (Recovery Time Objective), while optimizing for operational simplicity and cost efficiency.
The Options #
-
A) Deploy a complete duplicate application stack (ALB, Auto Scaling group, EC2 instances) in
eu-west-1. Create a second CloudFront distribution pointing to the EU ALB. Convert the Route 53 A record to a failover routing policy with both CloudFront distributions as targets, and configure Route 53 health checks on each distribution. -
B) Deploy a duplicate application stack (ALB, Auto Scaling group, EC2 instances) in
ap-southeast-1. Update the existing CloudFront distribution to add the new ALB as a secondary origin. Create a CloudFront origin group with the US ALB as the primary origin and the Asia-Pacific ALB as the failover origin. -
C) Deploy an Auto Scaling group and EC2 instances in
eu-central-1. Register the new Auto Scaling group as a second target group in the existing US-based ALB. Configure the ALB to use a failover routing algorithm to direct traffic to the EU target group when the US targets are unhealthy. -
D) Deploy a complete duplicate application stack in
ca-central-1. Create a second CloudFront distribution with the Canadian ALB as the origin. Provision an AWS Global Accelerator with both CloudFront distributions as endpoints, and update the Route 53 A record to point to the Global Accelerator static IPs.
Correct Answer #
Option B: Deploy a duplicate application stack (ALB, Auto Scaling, EC2) in a second region and configure CloudFront origin groups with primary/failover origins.
Step-by-Step Winning Logic #
This solution exploits CloudFront’s origin group failover mechanism, which automatically routes requests to a secondary origin when the primary returns specific HTTP status codes (5xx errors) or fails health checks. Key advantages:
- Single CloudFront Distribution: No need to duplicate edge infrastructure or manage DNS failover logic.
- Native Failover: CloudFront handles detection and rerouting at the edge, achieving sub-minute RTO without Route 53 health check latency (typically 30s intervals).
- Cost Efficiency: You pay only for the standby application stack (ALB + warm pool EC2s), not duplicate CloudFront request fees.
- Operational Simplicity: One distribution to manage, one cache behavior to configure, one SSL certificate to maintain.
đź’Ž The Architect’s Deep Dive: Why Options Fail #
The Traps (Distractor Analysis) #
-
Why not A (Duplicate CloudFront + Route 53 Failover)?
- Unnecessary Layer Duplication: CloudFront is already a globally distributed service; creating two distributions doesn’t improve availability—it adds cost ($0.0075/10,000 requests Ă— 2) and cache fragmentation (each distribution maintains separate edge caches, reducing hit ratios).
- Slower Failover: Route 53 health check intervals (minimum 30s, typically 60s with grace periods) delay detection compared to CloudFront’s origin-level health checks.
- DNS TTL Risk: Even with failover records, clients may cache the old CloudFront distribution’s DNS for the TTL duration.
-
Why not C (Cross-Region ALB Target Groups)?
- Architectural Impossibility: ALBs cannot have target groups in different regions. This option violates AWS service constraints entirely.
- Exam Trap Pattern: SAP-C02 frequently includes options that sound plausible but contradict fundamental service limitations.
-
Why not D (Global Accelerator + Dual CloudFront)?
- Service Misapplication: Global Accelerator excels at TCP/UDP acceleration and anycast IP stability, but it doesn’t add value when CloudFront already provides edge routing and caching.
- Cost Stacking: You’d pay for:
- 2Ă— CloudFront distributions
- 2Ă— Global Accelerator endpoints ($0.025/hour each = $36/month base)
- Data transfer through both services
- Complexity: Three layers of routing (DNS → Global Accelerator → CloudFront → Origins) increase troubleshooting difficulty.
The Architect Blueprint #
graph TB
User([Global Users]) -->|DNS: analytics.globalstreammedia.io| CF[CloudFront Distribution]
CF -->|Origin Group| OG{Origin Group Failover Logic}
OG -->|Primary Origin
Status: Healthy| ALB1[ALB us-east-1]
OG -.->|Failover Origin
Triggered on 5xx/Timeout| ALB2[ALB ap-southeast-1]
ALB1 --> ASG1[Auto Scaling Group
us-east-1]
ASG1 --> EC2_1[EC2 Instances
Video Analytics App]
ALB2 --> ASG2[Auto Scaling Group
ap-southeast-1]
ASG2 --> EC2_2[EC2 Instances
Video Analytics App]
style CF fill:#FF9900,stroke:#232F3E,color:#FFF
style OG fill:#3F8624,stroke:#232F3E,color:#FFF
style ALB2 stroke-dasharray: 5 5
Diagram Note: CloudFront’s origin group evaluates primary origin health in real-time; upon consecutive failures (configurable threshold), traffic automatically shifts to the failover origin without DNS changes.
The Decision Matrix #
| Option | Est. Complexity | Est. Monthly Cost (1M Requests, 10TB Egress) | Pros | Cons |
|---|---|---|---|---|
| B (Origin Groups) | Medium | $2,850 (CF: $850, ALBĂ—2: $500, EC2Ă—2 regions: $1,500) |
âś… Native CloudFront failover âś… Single distribution management âś… Fast failover (< 1 min) |
⚠️ Requires duplicate compute stack ⚠️ No active-active load distribution |
| A (Dual CF + R53) | High | $3,700 (CFĂ—2: $1,700, ALBĂ—2: $500, EC2Ă—2: $1,500) |
✅ Independent distributions | ❌ Cache fragmentation ❌ Slower failover (DNS TTL) ❌ 2× CloudFront costs |
| C (Cross-Region ALB) | N/A | N/A | None | ❌ Architecturally invalid ❌ ALB doesn’t support cross-region targets |
| D (Global Accelerator) | Very High | $4,200 (CFĂ—2: $1,700, GA: $72, ALBĂ—2: $500, EC2Ă—2: $1,500, GA data: $430) |
✅ Static anycast IPs | ❌ 47% cost premium over B ❌ Unnecessary service layering ❌ Complex troubleshooting |
Cost Assumptions:
- CloudFront: $0.085/GB (first 10TB) + $0.0075/10k requests
- ALB: $0.0225/hour + $0.008/LCU-hour (~$25/month per ALB)
- EC2: t3.large Ă— 3 instances Ă— $0.0832/hour Ă— 730 hours = $750/region
- Global Accelerator: $0.025/endpoint-hour + $0.015/GB DT-Premium
Real-World Practitioner Insight #
Exam Rule #
“For the SAP-C02, when you see CloudFront + multi-region failover + dynamic content, immediately look for origin groups. Avoid answers that duplicate CloudFront itself or introduce Global Accelerator without clear anycast IP requirements.”
Real World #
In production, we’d enhance Option B with:
- Active-Active Origins: Instead of primary/failover, configure origin groups with weighted distribution (80/20) to validate the standby region continuously.
- Database Replication: The scenario omits data layer strategy—real implementations need DynamoDB global tables or Aurora Global Database with sub-second replication lag.
- Cache Key Normalization: Ensure both regions generate identical cache keys (same headers, query strings) to maintain hit ratios during failover.
- Monitoring: Deploy CloudWatch alarms on
OriginLatencyand5xxErrorRatemetrics with SNS notifications to the on-call team.
When Global Accelerator Does Make Sense:
- Applications requiring static IP whitelisting (corporate firewalls)
- Non-HTTP protocols (TCP/UDP gaming, VoIP)
- Anycast-based DDoS protection at the network layer
For this HTTP/HTTPS workload, CloudFront’s built-in capabilities are sufficient—adding Global Accelerator would be over-engineering.