While preparing for the AWS SAP-C02, many candidates get confused by storage performance optimization versus architectural refactoring. In the real world, this is fundamentally a decision about origin architecture economics and user experience at scale. Let’s drill into a simulated scenario.
The Scenario #
MediaStream Labs operates a content publishing platform with a growing community of video creators. The platform runs on a cluster of Amazon EC2 instances behind an Application Load Balancer (ALB), with Auto Scaling enabled to handle variable traffic. All user-generated content—articles, images, and videos—is stored on an Amazon EFS file system shared across all instances.
After launching a video monetization feature, user engagement spiked 10x. During peak evening hours (7-10 PM EST), users experience:
- Video buffering and playback stuttering
- HTTP 504 gateway timeouts when accessing content
- Slow page load times
Current architecture:
- 15-50 EC2 instances (t3.large) in Auto Scaling group
- Application Load Balancer (ALB)
- Amazon EFS (General Purpose mode) with 500 GB stored data
- All static and dynamic content served directly from EC2 instances
Key Requirements #
Design a solution that:
- Eliminates buffering and timeout issues during peak traffic
- Scales cost-effectively with unpredictable traffic patterns
- Minimizes operational complexity
The Options #
- A) Reconfigure the Amazon EFS file system to enable Maximum I/O performance mode.
- B) Migrate to instance store volumes on each EC2 instance; sync content from Amazon S3 at launch and back to S3 at termination.
- C) Deploy Amazon CloudFront distribution pointing to an S3 bucket; migrate video files from EFS to S3.
- D) Deploy Amazon CloudFront distribution pointing to the Application Load Balancer for all content.
Correct Answer #
Option C.
The Architect’s Analysis #
Correct Answer #
Option C - Deploy Amazon CloudFront distribution pointing to an S3 bucket; migrate video files from EFS to S3.
Step-by-Step Winning Logic #
This solution addresses the root cause rather than symptoms:
1. Architecture Pattern Shift
- Separates static content (videos) from dynamic content (application logic)
- Videos represent 95%+ of bandwidth but 0% of computational logic
- S3 is purpose-built for static object delivery (11 9’s durability, unlimited scale)
- CloudFront provides edge caching, reducing origin requests by 85-95%
2. Performance Impact
- EFS throughput is constrained by provisioned capacity (burst credits exhaust under sustained load)
- CloudFront cache hit ratio of 80-90% for video content means only 10-20% of requests hit origin
- Global edge network reduces latency from single-region EFS (150-300ms) to edge locations (15-50ms)
3. Cost Efficiency
- EFS costs: $0.30/GB storage + $0.30/GB data transfer + I/O operations
- S3 Standard: $0.023/GB storage + CloudFront data transfer ($0.085/GB)
- For 500 GB with 10x traffic: EFS = ~$5,400/mo; S3+CloudFront = ~$1,200/mo
4. Operational Simplicity
- No EFS capacity planning or performance mode tuning
- CloudFront handles burst traffic automatically
- S3 lifecycle policies automate cost optimization (move to Glacier for old content)
The Traps (Distractor Analysis) #
Why not Option A (EFS Maximum I/O mode)?
- Technical limitation: Max I/O trades latency for throughput (higher per-operation latency)
- Cost trap: Doesn’t reduce data transfer costs (still $0.30/GB out)
- Scaling ceiling: Still bound by EFS throughput limits (eventual bottleneck at higher scale)
- Misdiagnosis: Treats symptom (I/O contention) not cause (wrong storage tier for static content)
Why not Option B (Instance store + S3 sync)?
- Complexity explosion: Custom sync logic introduces failure modes (sync failures, partial writes)
- Data consistency risk: Instance terminations during Auto Scaling could lose user uploads
- Cost inefficiency: Instance store requires larger instance types (io-optimized) = 40% cost increase
- Latency unchanged: Still serving from origin (no edge caching)
- Anti-pattern: Reinventing a CDN poorly
Why not Option D (CloudFront → ALB for all content)?
- Partial solution: Improves latency but doesn’t address EFS bottleneck
- Inefficient caching: Dynamic content (user dashboards, personalized feeds) has low cache hit ratios
- EFS still overloaded: Origin (EC2 + EFS) still serves cache misses at high volume
- Higher origin costs: ALB + EC2 fleet must handle all cache misses (expensive compared to S3 GET requests)
The Architect Blueprint #
Diagram Note: CloudFront serves 85% of video requests from edge cache; only cache misses and uploads interact with S3 origin, completely bypassing the EFS bottleneck.
The Decision Matrix #
| Option | Est. Complexity | Est. Monthly Cost (500GB, 10TB transfer) | Pros | Cons |
|---|---|---|---|---|
| A: EFS Max I/O | Low (config change) | $5,400 (EFS storage $150 + transfer $3,000 + I/O $2,250) | Quick implementation; no code changes | Doesn’t solve root cause; high latency persists; linear cost scaling |
| B: Instance Store Sync | Very High (custom logic) | $6,800 (EC2 upsize $2,200 + S3 $115 + transfer $4,485) | Theoretically fastest local reads | Data loss risk; operational nightmare; no global performance improvement |
| C: CloudFront + S3 ✅ | Medium (migration effort) | $1,285 (S3 $115 + CloudFront $1,020 + ALB $150) | 76% cost reduction; global <50ms latency; automatic scaling | One-time migration effort; requires code changes to upload flow |
| D: CloudFront + ALB | Low (CDN setup) | $4,950 (EFS $150 + EC2/ALB $2,800 + CloudFront $2,000) | Improves edge latency | EFS bottleneck remains; cache efficiency low for mixed content; 8% cost reduction only |
Cost Assumptions:
- 500 GB storage, 10 TB monthly data transfer (10x traffic)
- CloudFront pricing: $0.085/GB (US/EU weighted average)
- EFS: General Purpose mode, $0.30/GB storage + $0.30/GB transfer + $0.0045/10K I/O ops
- S3 Standard: $0.023/GB + $0.0004/1K GET requests
Real-World Practitioner Insight #
Exam Rule #
For SAP-C02, apply this decision tree:
- Static content at scale → S3 + CloudFront
- Global user base + latency requirement → CloudFront
- “Cost-effective” + “scalable” + video/media → Never EFS, always S3
Keyword triggers:
- “Video buffering” = CDN problem
- “Peak traffic” + “timeout” = Origin capacity problem
- “10x growth” = Architecture needs to change, not scale
Real World #
In production, we would:
-
Implement Option C with enhancements:
- Use S3 Intelligent-Tiering for automated cost optimization (videos older than 30 days move to cheaper tiers)
- Enable CloudFront Origin Shield to collapse requests to S3 (reduces origin load by additional 50%)
- Implement signed URLs for CloudFront to protect premium content
-
Hybrid approach for gradual migration:
- Keep EFS for user-uploaded thumbnails and metadata (small files, frequent updates)
- Migrate only video files (>10 MB) to S3 initially
- Use Lambda@Edge for URL rewrites during transition
-
Advanced optimizations:
- S3 Transfer Acceleration for global upload performance
- MediaConvert for adaptive bitrate streaming (HLS/DASH)
- CloudWatch + Lambda to auto-archive videos with <100 views/month to Glacier
-
Additional considerations not in exam:
- DRM requirements might need AWS Elemental MediaPackage
- Live streaming would require MediaLive, not just S3/CloudFront
- GDPR/data residency might require CloudFront geo-restriction + regional S3 buckets
The exam simplifies reality - but Option C remains the correct foundation even in complex enterprise scenarios.