While preparing for the AWS SAA-C03, many candidates overthink static content hosting by defaulting to compute-based solutions. In the real world, this is fundamentally a decision about Resource Right-Sizing vs. Operational Overhead. Let’s drill into a simulated scenario.
The Scenario #
A digital marketing agency, BrightPath Creative, is building an internal design system portal that will be accessed by multiple product teams across the organization. The portal contains static assets only: HTML documentation pages, CSS stylesheets, client-side JavaScript for interactive components, and brand imagery. The content is updated weekly through a CI/CD pipeline. Expected traffic is moderate (approximately 5,000 requests per day), with predictable access patterns during business hours.
Key Requirements #
Minimize hosting costs while ensuring reliable access and simple maintenance for the DevOps team.
The Options #
- A) Containerize the website and deploy it on AWS Fargate with an Application Load Balancer
- B) Create an Amazon S3 bucket, enable static website hosting, and serve content directly
- C) Launch an Amazon EC2 t3.micro instance with Apache/Nginx to serve the static files
- D) Configure an Application Load Balancer with AWS Lambda targets running an Express.js framework
Correct Answer #
Option B.
The Architect’s Analysis #
Correct Answer #
Option B - Amazon S3 Static Website Hosting.
Step-by-Step Winning Logic #
This solution achieves optimal cost-efficiency through serverless architecture alignment with workload characteristics:
- Zero Compute Waste: No idle server capacity. You pay only for storage ($0.023/GB) and GET requests ($0.0004 per 1,000 requests).
- Built-in Scalability: S3 automatically handles traffic spikes without provisioning or auto-scaling configuration.
- Operational Simplicity: No OS patching, no server monitoring, no container orchestration—just object storage with HTTP delivery.
- CloudFront Integration Path: Easy upgrade path to CDN for global performance (not required here, but architecturally clean).
Cost Calculation for Scenario:
- Storage: 500MB content × $0.023 = $0.01/month
- Requests: 5,000/day × 30 days = 150,000 requests × $0.0004/1K = $0.06/month
- Total: ~$0.07/month (excluding data transfer)
The Traps (Distractor Analysis) #
-
Why not Option A (Fargate)?
- Introduces container overhead for static files—architectural anti-pattern. Minimum cost: 0.25 vCPU × $0.04048/hour × 730 hours = ~$29.55/month + ALB costs (~$16/month) = $45+/month—that’s 642x more expensive than S3 for identical functionality.
-
Why not Option C (EC2)?
- Even a t3.micro ($0.0104/hour = ~$7.59/month) requires patching, monitoring, and manual scaling. You’re paying for 24/7 uptime when traffic is business-hours only. Total waste of compute during nights/weekends (~70% idle time).
-
Why not Option D (Lambda + ALB)?
- Lambda makes sense for dynamic content, not serving static files. You’d pay for ALB ($16/month) + Lambda invocations + unnecessary cold start latency. Architecture complexity with zero functional benefit.
The Architect Blueprint #
Diagram Note: Content flows from CI/CD directly to S3, which serves requests via its built-in HTTP endpoint—no intermediary compute layer required.
The Decision Matrix #
| Option | Complexity | Est. Monthly Cost | Pros | Cons |
|---|---|---|---|---|
| B - S3 Static Hosting | Low | $0.07 | Native HTTP serving, auto-scaling, no maintenance, 99.99% SLA | No server-side processing capability |
| A - Fargate + ALB | High | $45-60 | Container portability, easy migration if logic needed later | 600x cost premium, over-engineered for static content |
| C - EC2 (t3.micro) | Medium | $8-12 | Full server control, familiar to traditional ops teams | Patching burden, idle capacity waste, manual scaling |
| D - Lambda + ALB | High | $20-30 | Serverless compute, auto-scaling | Unnecessary for static files, ALB costs, cold start latency |
Real-World Practitioner Insight #
Exam Rule #
For the AWS SAA-C03, always choose S3 static website hosting when you see these keywords:
- “Static content” / “HTML, CSS, JavaScript, images”
- “Cost-effective” / “Minimize cost”
- “No server-side processing”
Real World #
In production environments, we’d typically enhance this with:
-
CloudFront CDN in front of S3 for:
- Global edge caching (reduce S3 GET request costs)
- HTTPS with custom domain (S3 website endpoints don’t support HTTPS natively)
- DDoS protection via AWS Shield Standard
-
Route 53 for DNS with health checks if using multi-region failover.
-
S3 Versioning + Lifecycle Policies for rollback capability and cost optimization of old assets.
However, for the exam scenario with internal-only access and moderate traffic, the base S3 solution is architecturally correct. The question is testing your ability to avoid over-engineering—a critical skill for both the exam and real-world cost governance.