While preparing for the AWS SAP-C02, many candidates get confused by when to choose Aurora over RDS MySQL and how much high availability is enough. In the real world, this is fundamentally a decision about availability tier vs infrastructure cost vs operational complexity. Let’s drill into a simulated scenario.
The Scenario #
GlobalRetail Inc., an e-commerce platform, operates a three-tier .NET web application in their on-premises data center. During a recent flash sale event, unexpected traffic spikes caused complete system outages, resulting in $780,000 in lost revenue over 6 hours. The executive team has mandated cloud migration to AWS with strict requirements: the platform must handle 200,000 daily active users with zero downtime during traffic surges.
The application stack consists of:
- Frontend/middleware: Custom .NET Framework 4.8 application
- Database: MySQL 5.7 with approximately 2TB of transactional data
- Traffic pattern: Predictable baseline with unpredictable 5-10x spikes during promotions
Key Requirements #
Design a scalable, highly available AWS architecture that eliminates single points of failure, automatically handles traffic fluctuations, and minimizes operational overhead for the 200K daily user base.
The Options #
A) Deploy using AWS Elastic Beanstalk with a .NET web server environment backed by Amazon RDS MySQL Multi-AZ database instance. Configure an Auto Scaling group across multiple Availability Zones with a Network Load Balancer (NLB) in front. Use Route 53 alias records to route the company domain to the NLB.
B) Use AWS CloudFormation to provision an Application Load Balancer (ALB) fronting an Auto Scaling group distributed across three Availability Zones. Deploy an Amazon Aurora MySQL database cluster with Multi-AZ configuration using a “Retain” deletion policy. Configure Route 53 alias records pointing to the ALB.
C) Create an Elastic Beanstalk environment with auto-scaling web servers deployed across two separate AWS Regions, each with an Application Load Balancer. Implement an Amazon Aurora MySQL Multi-AZ cluster with cross-Region read replicas. Use Route 53 geoproximity routing to distribute traffic between regions.
D) Deploy via CloudFormation with an Application Load Balancer fronting an Amazon ECS cluster running on Spot Instances across three Availability Zones. Launch an Amazon RDS MySQL database instance with “Snapshot” deletion policy. Configure Route 53 alias records to the ALB.
Correct Answer #
Option B.
Quick Insight: The FinOps Imperative #
At the Professional level, you’re expected to distinguish between necessary resilience (Multi-AZ Aurora across 3 AZs) and over-engineered solutions (multi-Region for a single-geography user base). Option B delivers 99.95%+ availability at ~40% lower cost than multi-Region designs while eliminating the operational complexity of cross-Region data synchronization for a scenario that doesn’t require sub-second global failover.
💎 The Architect’s Deep Dive: Why Options Fail #
Correct Answer #
Option B - CloudFormation + ALB + Aurora MySQL Multi-AZ across 3 AZs.
Step-by-Step Winning Logic #
This solution represents the optimal trade-off for a Professional-level migration requiring enterprise-grade availability without unnecessary complexity:
-
Infrastructure as Code Maturity: CloudFormation enables version-controlled, repeatable deployments with explicit resource dependencies—critical for change management at scale.
-
Database Technology Selection: Aurora MySQL delivers:
- 5x throughput compared to standard RDS MySQL (critical for traffic surge handling)
- Sub-10-second automated failover (vs 60-120s for RDS Multi-AZ)
- 15 read replicas (vs 5 for RDS) for horizontal read scaling during flash sales
- Continuous backup to S3 with point-in-time recovery
-
Application-Layer Intelligence: ALB provides Layer 7 routing (vs NLB’s Layer 4), enabling:
- Path-based routing for microservices evolution
- Slower connection draining (important for .NET session state)
- Native WAF integration for security
-
Cost-Effective HA: Three-AZ deployment provides 99.95% availability SLA without the 2.5x cost multiplier and data synchronization complexity of multi-Region architecture.
-
Retain Deletion Policy: Prevents accidental database destruction during stack updates—a production-grade safety measure.
The Traps (Distractor Analysis) #
Why not Option A (Elastic Beanstalk + RDS MySQL)?
- Performance Ceiling: RDS MySQL cannot scale read capacity beyond 5 replicas—insufficient for 200K users with spike patterns
- Slower Failover: 60-120 second RDS Multi-AZ failover vs Aurora’s sub-10s means 2-12 minutes of downtime during database failures
- Load Balancer Mismatch: NLB lacks Layer 7 features needed for .NET applications (sticky sessions, health checks on HTTP codes)
- Hidden Cost: Acceptable for Associate-level thinking, but Professional scenarios expect you to recognize when standard RDS becomes a bottleneck
Why not Option C (Multi-Region Elastic Beanstalk)?
- Over-Engineering: Multi-Region adds 150% infrastructure cost for a scenario with no stated geographic distribution requirement
- Data Consistency Nightmare: Cross-Region Aurora replication has 1-5 second lag—unacceptable for transactional e-commerce (inventory conflicts, double bookings)
- Operational Burden: Requires cross-Region deployment pipelines, regional certificate management, and complex failover runbooks
- Cost Impact: Running duplicate infrastructure in 2 regions + cross-Region data transfer (~$0.02/GB) would cost $8,000-12,000/month vs $3,500/month for Option B
Why not Option D (ECS Spot + RDS)?
- Spot Instance Risk: Spot interruptions (2-minute notice) are inappropriate for stateful web applications handling user sessions
- Snapshot Deletion Policy: Loses point-in-time recovery capability—unacceptable for transactional systems
- Container Overhead: ECS adds complexity for a lift-and-shift .NET Framework migration (requires Windows containers, larger images, longer cold starts)
- Standard RDS Limitations: Same performance constraints as Option A
The Architect Blueprint #
graph TB
subgraph "DNS Layer"
R53[Route 53
Alias Record]
end
subgraph "AWS Region us-east-1"
subgraph "VPC - Multi-AZ Design"
subgraph "Public Subnets"
ALB[Application Load Balancer
Cross-AZ]
end
subgraph "Private Subnets - App Tier"
ASG[Auto Scaling Group
.NET EC2 Instances
Across AZ-1, AZ-2, AZ-3]
end
subgraph "Private Subnets - Data Tier"
Aurora[(Aurora MySQL Cluster
Multi-AZ: Writer in AZ-1
Readers in AZ-2, AZ-3)]
end
end
CF[CloudFormation Stack
Retain Deletion Policy]
end
User([200K Daily Users]) --> R53
R53 --> ALB
ALB --> ASG
ASG --> Aurora
CF -.Manages.-> ALB
CF -.Manages.-> ASG
CF -.Manages.-> Aurora
style Aurora fill:#FF9900,stroke:#232F3E,stroke-width:3px,color:#fff
style ALB fill:#3F8624,stroke:#232F3E,stroke-width:2px,color:#fff
style ASG fill:#527FFF,stroke:#232F3E,stroke-width:2px,color:#fff
Diagram Note: The architecture achieves high availability through cross-AZ resource distribution while maintaining a single-Region deployment for cost efficiency, with Aurora’s automated failover providing sub-10-second database recovery.
The Decision Matrix #
| Option | Est. Complexity | Est. Monthly Cost (200K Users) | Pros | Cons |
|---|---|---|---|---|
| A: Beanstalk + RDS MySQL + NLB | Low (Managed platform, simple setup) | $2,800/mo - RDS db.r5.2xlarge Multi-AZ: $1,100 - EC2 (4x m5.large): $560 - NLB: $240 - Data transfer: $900 |
✅ Fastest to deploy (24 hours) ✅ Lower learning curve ✅ Built-in platform monitoring |
❌ RDS read replica limit (5 max) ❌ 60-120s failover time ❌ NLB lacks Layer 7 routing ❌ Limited scaling for traffic spikes |
| B: CloudFormation + ALB + Aurora Multi-AZ | Medium (IaC setup, requires CloudFormation expertise) | $3,650/mo - Aurora db.r5.2xlarge Multi-AZ: $1,450 - EC2 (4x m5.large): $560 - ALB: $240 - Data transfer: $900 - S3 backup: $500 |
✅ Sub-10s database failover ✅ 5x read throughput vs RDS ✅ 15 read replicas capability ✅ Continuous S3 backups ✅ Infrastructure versioning ✅ ALB Layer 7 features |
❌ 30% higher database cost than RDS ❌ Requires CloudFormation skills ❌ Initial setup time (48-72 hours) |
| C: Multi-Region Beanstalk + Aurora Global | Very High (Cross-Region orchestration, data sync) | $9,200/mo - 2x Aurora clusters: $2,900 - 2x EC2 fleets: $1,120 - 2x ALB: $480 - Cross-Region replication: $1,200 - Route 53 health checks: $500 - Data transfer: $3,000 |
✅ Geographic redundancy ✅ Sub-second regional failover ✅ Disaster recovery capability |
❌ 2.5x cost vs single Region ❌ 1-5s replication lag (data conflicts) ❌ Complex deployment pipelines ❌ Over-engineered for requirements ❌ Cross-Region data transfer costs |
| D: ECS Spot + RDS + Snapshot Policy | High (Container orchestration, Windows container complexity) | $1,950/mo - RDS db.r5.2xlarge: $1,100 - ECS Spot (avg 70% savings): $168 - ALB: $240 - Data transfer: $900 - ECR storage: $42 |
✅ Lowest compute cost (Spot savings) ✅ Container portability |
❌ Spot interruption risk (2-min notice) ❌ Loses point-in-time recovery ❌ .NET Framework container overhead ❌ RDS scaling limits ❌ Stateful app + Spot = risky |
FinOps Insight: Option B costs 30% more than Option A but delivers 600% improvement in failover speed and 300% increase in read capacity—a justifiable premium for a business that lost $780K to 6 hours of downtime. Option C’s multi-Region approach costs 152% more than Option B while introducing data consistency risks that could cause worse outages (inventory oversells, payment conflicts).
Real-World Practitioner Insight #
Exam Rule #
For the SAP-C02 exam, when you see:
- “Three-tier application” + “high availability” + “MySQL” → Think Aurora Multi-AZ
- “Traffic spikes” + “auto-scaling” → Favor ALB over NLB (better health checks, connection draining)
- “Professional-level question” + Database choice → Aurora beats RDS MySQL unless there’s a budget constraint explicitly stated
- “CloudFormation” vs “Elastic Beanstalk” → CloudFormation signals mature IaC practices expected at Professional level
Real World #
In reality, the decision would include:
-
Migration Path Consideration: We’d likely start with Option A for a 90-day “lift-and-shift” phase, then migrate to Option B after validating traffic patterns. This reduces initial risk while planning the Aurora migration.
-
Cost Optimization Tactics:
- Use Aurora Serverless v2 for non-production environments (saves $800/month)
- Implement Reserved Instance pricing for predictable baseline (20-40% savings)
- Enable Aurora Auto Scaling for read replicas only during traffic spikes
-
Observability Stack: Add CloudWatch RUM ($300/month) to measure actual user-perceived latency and correlate with database query performance—critical for justifying the Aurora premium to finance teams.
-
Session State Externalization: The exam doesn’t mention it, but we’d migrate .NET session state to ElastiCache or DynamoDB to make instances truly stateless, enabling more aggressive auto-scaling and Spot Instance usage in the future.
-
Database Right-Sizing: Monitor actual query patterns for 30 days before committing to db.r5.2xlarge—many applications over-provision by 40% initially.
-
Disaster Recovery Evolution: While multi-Region (Option C) is overkill today, we’d architect Option B to enable Aurora Global Database later if the business expands to new geographies (incremental cost: ~$1,400/month only when needed).
The Professional Difference: Associate-level thinking stops at “Aurora is better.” Professional-level architects quantify the $780K downtime cost, calculate that Option B’s $850/month premium pays for itself if it prevents just 66 minutes of additional downtime per year, and structure the solution to evolve with business growth.