While preparing for the AWS SAP-C02, many candidates get confused by serverless container options. In the real world, this is fundamentally a decision about operational simplicity vs. cost efficiency vs. architectural flexibility. Let’s drill into a simulated scenario.
The Scenario #
TechWave Solutions, a B2B SaaS provider, currently runs a monolithic inventory management application on EC2 instances. The engineering team has decided to refactor the application into containerized microservices to improve deployment velocity and resource utilization.
The company maintains two isolated environments: Production (serving 50,000+ active users) and Staging (used for QA and load testing). Traffic patterns are variable but predictable: baseline usage is consistent during business hours, with known peak loads during month-end reporting cycles.
The CTO has mandated: “Adopt a serverless-first approach to eliminate server patching, reduce operational overhead, and align with our cloud-native strategy.”
Key Requirements #
Design a container orchestration solution that:
- Minimizes operational complexity (no server management)
- Supports independent production and staging environments
- Handles variable load with known min/max capacity requirements
- Maximizes cost-efficiency while meeting performance SLAs
The Options #
-
A) Upload container images to AWS Lambda as functions. Configure reserved concurrency limits for Lambda functions to handle expected peak load. Set up two separate Lambda integrations in Amazon API Gateway for production and staging environments.
-
B) Upload container images to Amazon Elastic Container Registry (ECR). Configure two Amazon ECS clusters with auto-scaling using Fargate launch type to handle expected load. Deploy tasks from ECR images. Configure two separate Application Load Balancers to route traffic to the ECS clusters.
-
C) Upload container images to Amazon Elastic Container Registry (ECR). Configure two Amazon Elastic Kubernetes Service (EKS) clusters with auto-scaling using Fargate launch type to handle expected load. Deploy tasks from ECR images. Configure two separate Application Load Balancers to route traffic to the EKS clusters.
-
D) Upload container images to AWS Elastic Beanstalk. Create separate Elastic Beanstalk environments for production and staging with independent deployments. Configure two separate Application Load Balancers to route traffic to the Elastic Beanstalk deployments.
Correct Answer #
Option B.
The Architect’s Analysis #
Correct Answer #
Option B — Amazon ECS with Fargate launch type.
Step-by-Step Winning Logic #
This solution optimally balances the three competing priorities:
-
Operational Simplicity: Fargate eliminates EC2 instance management entirely (no patching, no AMI updates, no capacity planning at the host level). ECS provides native container orchestration without Kubernetes complexity.
-
Cost Predictability: With known min/max load, Fargate’s per-task vCPU/memory pricing model allows accurate cost forecasting. You pay only for running tasks (no idle EC2 instances), and auto-scaling ensures you’re not over-provisioned during low-traffic periods.
-
Workload Suitability: Traditional web applications refactored into microservices typically have:
- Long-running HTTP connections
- Session affinity requirements
- Variable request processing times (potentially >15 minutes for batch operations)
ECS Fargate handles these gracefully, whereas Lambda has hard 15-minute limits and isn’t optimized for persistent connections.
-
Environment Isolation: Two separate ECS clusters (or task definitions with different tags) provide clean production/staging separation with independent scaling policies and deployment pipelines.
The Traps (Distractor Analysis) #
-
Why not Option A (Lambda)?
- Architecture Mismatch: Lambda is designed for event-driven, short-burst workloads. A refactored monolith is still likely handling HTTP request/response cycles that may exceed Lambda’s 15-minute timeout.
- Cost Explosion Risk: For a web application with consistent baseline traffic, Lambda’s per-invocation + GB-second pricing becomes expensive compared to Fargate’s task-hour pricing. If your “minimum load” means 24/7 baseline traffic, you’re paying for millions of Lambda invocations monthly.
- Connection Limits: Lambda functions behind API Gateway face concurrency limits and aren’t ideal for WebSocket or long-polling scenarios common in traditional web apps.
- Cold Start Impact: Even with reserved concurrency, Lambda cold starts (especially for container images >1 GB) can cause latency spikes unacceptable for production web traffic.
-
Why not Option C (EKS Fargate)?
- Unnecessary Complexity: EKS introduces Kubernetes overhead (control plane management, YAML manifests, RBAC, pod scheduling logic) that adds no value for this use case. The scenario doesn’t mention requirements for advanced Kubernetes features (StatefulSets, DaemonSets, custom schedulers).
- Higher Control Plane Cost: EKS charges $0.10/hour (~$73/month) per cluster for the control plane alone. With two clusters (prod + staging), that’s $146/month before running a single container. ECS has no control plane charges.
- Steeper Learning Curve: Requires Kubernetes expertise, which contradicts the “minimize operational complexity” requirement.
-
Why not Option D (Elastic Beanstalk)?
- Not Fully Serverless: Elastic Beanstalk abstracts EC2/Auto Scaling management but still provisions underlying EC2 instances (even in “Docker” platform mode). You’re still responsible for platform updates and security patches at the OS level.
- Limited Container Orchestration: Beanstalk’s multi-container Docker platform uses ECS under the hood but lacks fine-grained control over task definitions, service discovery, and deployment strategies (blue/green, canary).
- Legacy Positioning: AWS now positions Elastic Beanstalk as a legacy PaaS for lift-and-shift scenarios, not modern microservices architectures.
The Architect Blueprint #
Diagram Note: Each environment maintains complete isolation with dedicated ECS clusters and ALBs, while sharing the centralized ECR repository for image management. Auto-scaling policies react to CloudWatch metrics (CPU/memory/request count) to adjust task counts dynamically.
The Decision Matrix #
| Option | Est. Operational Complexity | Est. Monthly Cost (Medium Workload) | Pros | Cons |
|---|---|---|---|---|
| A. Lambda Containers | Low (Serverless) | High ($4,500+) Assuming 10M requests/mo, 2GB memory, 5s avg duration |
✅ Zero server management ✅ Automatic scaling ✅ Pay-per-invoke model |
❌ 15-min timeout limit ❌ Cold start latency ❌ Expensive for baseline traffic ❌ Not optimized for HTTP workloads |
| B. ECS Fargate | Low-Medium (Serverless orchestration) | Medium ($1,800) Assuming 4 vCPU, 8GB RAM, 2 tasks 24/7 + staging |
✅ No EC2 management ✅ Predictable pricing ✅ Native ALB integration ✅ No control plane fees |
❌ Less flexible than Kubernetes ❌ Fargate task startup ~30s |
| C. EKS Fargate | High (Kubernetes + Serverless) | High ($2,800+) ECS cost + $146/mo control plane + k8s complexity tax |
✅ Kubernetes ecosystem ✅ No EC2 management ✅ Advanced orchestration |
❌ $73/mo per cluster ❌ Requires k8s expertise ❌ Overkill for simple microservices |
| D. Elastic Beanstalk | Medium (Managed PaaS) | Medium ($2,200) EC2 instances + ALB + hidden mgmt overhead |
✅ Simple deployment interface ✅ Integrated monitoring |
❌ Still manages EC2 instances ❌ Limited container features ❌ Legacy platform positioning |
Cost Assumptions:
- Lambda: 10M requests/month, 2GB memory, 5-second average execution = ~$4,500/month (GB-seconds + request charges)
- ECS Fargate: 4 vCPU (0.25 vCPU per task × 8 tasks across 2 environments), 8GB RAM, 730 hours/month = ~$1,800/month
- EKS Fargate: Same compute as ECS + $146/month for 2 control planes = ~$2,800/month
- Elastic Beanstalk: 4× t3.medium instances (2 per env) + ALB = ~$2,200/month
Real-World Practitioner Insight #
Exam Rule #
“For SAP-C02, when you see ‘serverless + containers + minimal operational complexity’, prioritize ECS Fargate unless the scenario explicitly requires Kubernetes features (multi-cloud portability, custom schedulers, Helm charts). If the workload is event-driven with <15min runtime, choose Lambda containers.”
Real World #
In production environments, we often implement a hybrid approach:
-
ECS Fargate for Core Services: User-facing APIs, session-heavy workloads, and long-running transactions run on ECS Fargate for cost predictability.
-
Lambda for Event Processing: Asynchronous tasks triggered by SQS, S3 events, or scheduled jobs use Lambda to avoid idle container costs.
-
Cost Optimization Layer:
- Use Fargate Spot for staging environments (70% cost reduction, acceptable interruption risk)
- Implement ECS Service Auto Scaling with target tracking on ALB request count
- Leverage Compute Savings Plans if baseline capacity is stable (up to 50% discount vs. on-demand Fargate pricing)
-
Operational Enhancements:
- Deploy AWS X-Ray for distributed tracing across microservices
- Use ECS Exec (similar to
kubectl exec) for emergency container debugging - Implement blue/green deployments with CodeDeploy for zero-downtime updates
The Hidden Trade-off: While ECS Fargate wins on cost and simplicity, vendor lock-in is real. If your organization prioritizes multi-cloud portability (running identical workloads on GCP GKE or Azure AKS), the Kubernetes tax (Option C) becomes a strategic investment rather than wasteful complexity. This nuance rarely appears in certification exams but dominates real-world architectural debates.