While preparing for the AWS SAA-C03, many candidates get confused by when to choose serverless vs. container vs. EC2 architectures. In the real world, this is fundamentally a decision about operational complexity vs. control, and pay-per-use vs. baseline costs. Let’s drill into a simulated scenario.
The Scenario #
A retail startup, FlashDeal365, is launching a “Deal of the Day” platform where they feature a single heavily-discounted product for exactly 24 hours. Marketing projections indicate traffic will spike to millions of requests per hour during peak times (lunch hours and evenings), with sub-100ms latency expectations from their mobile app and web users.
The engineering team is small (3 developers) and the CTO has mandated “minimal operational overhead” — no dedicated DevOps team will be available for the first 6 months. The product catalog changes daily, and order volume is unpredictable but bursty.
Key Requirements #
Design an AWS architecture that:
- Handles millions of requests per hour during peak traffic
- Delivers millisecond-level latency to end users
- Requires minimum operational management (no manual scaling, patching, or infrastructure babysitting)
The Options #
-
A) Host the entire website using Amazon S3 across multiple buckets, add Amazon CloudFront distribution with S3 as the origin, and store order data in Amazon S3.
-
B) Deploy the entire website on Amazon EC2 instances within an Auto Scaling group spanning multiple Availability Zones, add an Application Load Balancer (ALB) to distribute website traffic, add another ALB for backend APIs, and store data in Amazon RDS for MySQL.
-
C) Migrate the entire application to containers, host them on Amazon Elastic Kubernetes Service (Amazon EKS), use Kubernetes Cluster Autoscaler to scale pods based on traffic bursts, and store data in Amazon RDS for MySQL.
-
D) Use Amazon S3 to host static website content, deploy an Amazon CloudFront distribution with S3 as the origin, use Amazon API Gateway and AWS Lambda functions to handle backend API requests, and store data in Amazon DynamoDB.
Correct Answer #
D.
The Architect’s Analysis #
Correct Answer #
Option D — Serverless architecture with S3, CloudFront, API Gateway, Lambda, and DynamoDB.
Step-by-Step Winning Logic #
This solution achieves the optimal trade-off for the constraints:
-
Minimal Operational Overhead (Primary Constraint)
- No servers to patch or manage: S3, CloudFront, Lambda, API Gateway, and DynamoDB are all fully managed services
- Auto-scaling is built-in: Lambda concurrency scales automatically to thousands of concurrent executions; DynamoDB on-demand mode scales read/write capacity automatically
- No capacity planning required: Serverless architecture eliminates the need to predict traffic and pre-provision infrastructure
-
Millisecond Latency Requirement
- CloudFront CDN: 450+ edge locations deliver static content (product images, HTML, CSS, JS) with <50ms latency globally
- DynamoDB single-digit millisecond reads: Perfect for high-velocity product lookups and order writes
- Lambda@Edge capability: Can execute custom logic at CloudFront edge locations for even lower latency (though not explicitly required here)
-
Millions of Requests Per Hour
- Lambda concurrent execution limits: Default 1,000 concurrent executions (can request increases to 10,000+), handling ~3,000 requests/second per function
- API Gateway throttling: 10,000 requests/second default (increasable)
- DynamoDB: Virtually unlimited throughput with on-demand mode
-
FinOps Optimization
- Pay-per-use pricing: No cost during off-peak hours (unlike EC2/EKS which bill for running instances)
- CloudFront free tier: 1TB data transfer out per month for the first year
- Lambda free tier: 1M requests/month and 400,000 GB-seconds of compute time
- DynamoDB on-demand: No charge for idle capacity, only for actual reads/writes
The Traps (Distractor Analysis) #
Why not Option A?
- S3 is not a compute platform: Storing “order data” in S3 implies treating it like a database, which violates the requirement for millisecond-level transactional processing
- No backend logic execution: Pure S3 hosting cannot execute order processing logic, inventory checks, or payment processing
- CORS and API limitations: While S3 can host static sites, it cannot handle POST requests for order submissions without Lambda or another compute layer
- Exam Trap: This tests whether you understand S3’s role as object storage vs. a transactional database
Why not Option B?
- High operational overhead: Requires managing EC2 instances (patching, security hardening, monitoring)
- Auto Scaling lag: EC2 Auto Scaling takes 3-5 minutes to launch new instances, which may miss the traffic spike
- Baseline costs: You pay for minimum capacity even during idle hours (violates “minimal overhead”)
- RDS operational burden: Requires parameter tuning, backup management, read replica setup for high read throughput
- Exam Trap: This is the “traditional” approach that works but violates the “minimal operational overhead” constraint
Why not Option C?
- Maximum operational complexity: EKS requires Kubernetes expertise (cluster management, pod networking, RBAC configuration)
- Cluster management overhead: Control plane upgrades, node group patching, CNI plugin updates
- Cost inefficiency: EKS charges $0.10/hour for the control plane alone (~$73/month) plus EC2 worker nodes running 24/7
- Overkill for this use case: Kubernetes shines for complex microservices architectures, not simple flash sale sites
- Exam Trap: AWS loves to include EKS as a distractor for scenarios where serverless is simpler and cheaper
The Architect Blueprint #
Diagram Note: Static content is cached at CloudFront edges globally for <50ms delivery, while dynamic API requests flow through API Gateway to Lambda for business logic execution against DynamoDB, achieving the required millisecond-level performance with zero operational overhead.
Real-World Practitioner Insight #
Exam Rule #
“For the SAA-C03 exam, when you see ‘minimal operational overhead’ + ‘bursty/unpredictable traffic’ + ‘millisecond latency’, always favor serverless architectures (Lambda + API Gateway + DynamoDB) over EC2/EKS. CloudFront is the default choice for global low-latency content delivery.”
Real World #
In production, we would likely enhance this design with:
- DynamoDB Global Tables for multi-region failover and lower latency for international users
- Lambda Reserved Concurrency to prevent one function from exhausting the account-level concurrent execution limit during traffic spikes
- API Gateway caching to reduce Lambda invocations for frequently accessed product data (additional cost savings)
- CloudWatch Alarms for Lambda throttling, API Gateway 5xx errors, and DynamoDB consumed capacity
- AWS WAF on CloudFront to protect against DDoS attacks and bot traffic (flash sales are common targets)
- Step Functions for complex order workflows (payment processing, inventory locking, notification sending) instead of monolithic Lambda functions
- Cognito User Pools for user authentication if account creation is required
The exam simplifies these scenarios to test core architectural principles — in reality, flash sale architectures require sophisticated strategies for:
- Inventory management (preventing overselling when 10,000 users click “buy” simultaneously)
- Payment processing idempotency (ensuring duplicate clicks don’t charge customers twice)
- Rate limiting per user (preventing single bots from consuming all inventory)