While preparing for the AWS SAP-C02, many candidates get confused by when to modernize vs. stabilize. In the real world, this is fundamentally a decision about Time-to-Resolution vs. Refactoring ROI. The question presents four architectures spanning the entire modernization spectrum—from serverless (highest refactor) to ALB (lowest refactor). Let’s drill into a simulated scenario.
The Scenario #
NexMobile, a mid-sized mobile app platform provider, hosts a monolithic REST API backend across 5 Amazon EC2 instances deployed in a VPC public subnet. Mobile clients resolve the API endpoint through an Amazon Route 53 hosted zone configured with a multi-value answer routing policy, which returns all 5 instance IP addresses.
Recently, NexMobile launched a viral marketing campaign, causing unpredictable traffic spikes that overwhelm the current infrastructure. The API response times have degraded significantly, and the static EC2 fleet cannot adapt to variable demand.
The Solutions Architect is tasked with implementing a solution that enables the API to handle variable traffic elastically while balancing speed of implementation, cost, and operational complexity.
Key Requirements #
Enable the monolithic REST API to scale elastically in response to variable traffic, with minimal deployment risk and optimized cost-performance trade-offs.
The Options #
- A) Refactor the monolithic API into independent AWS Lambda functions; configure an Amazon API Gateway REST API integrated with Lambda as the backend; update Route 53 records to point to the API Gateway endpoint.
- B) Containerize the API logic; create an Amazon EKS cluster; run containers on EC2-backed nodes; deploy a Kubernetes Ingress controller; update Route 53 to point to the Ingress.
- C) Create an Auto Scaling group; add all EC2 instances to the group; configure CPU-based scaling policies; create a Lambda function to monitor Auto Scaling events and dynamically update Route 53 records.
- D) Deploy an Application Load Balancer (ALB) in front of the API; migrate EC2 instances to a VPC private subnet; register instances as ALB targets; update Route 53 to point to the ALB DNS name.
Correct Answer #
Option D.
Step-by-Step Winning Logic #
This solution represents the optimal pragmatic trade-off for SAP-C02 candidates to understand:
-
Immediate Elasticity: ALB natively supports Auto Scaling integration (attach the ASG as a target group). The question states the API is “overwhelmed”—this is an operational emergency, not a greenfield refactor opportunity.
-
Minimal Refactoring: The monolithic API remains unchanged. No code modification, no container migration, no function decomposition. This reduces deployment risk to near-zero.
-
Health-Aware Routing: ALB performs active health checks and removes unhealthy targets automatically—a massive improvement over Route 53 multi-value answers, which rely on client-side retry logic.
-
Security Best Practice: Moving instances to private subnets eliminates direct internet exposure while the ALB handles public ingress.
-
Cost Efficiency: ALB pricing is
$0.0225/hour ($16/mo) plus $0.008 per LCU-hour. For a small-to-medium API, total monthly cost is typically $50-100, far less than EKS control plane fees ($73/mo) or API Gateway request charges at scale. -
Implicit Auto Scaling Readiness: While not explicitly stated, adding an Auto Scaling group after deploying the ALB is trivial and completes the elasticity requirement.
💎 The Architect’s Deep Dive: Why Options Fail #
The Traps (Distractor Analysis) #
Why Not Option A (Lambda + API Gateway)? #
- Pros: Ultimate scalability, true serverless, pay-per-request.
- Cons:
- Requires complete refactoring of the monolith into discrete functions (weeks/months of effort).
- Cold start latency for mobile APIs can degrade UX.
- API Gateway cost at high scale: $3.50 per million requests (REST API) can exceed EC2 costs for sustained traffic.
- Risk: This is a rewrite, not a migration. High chance of introducing bugs.
Exam Trap: This is the “shiny object” answer. SAP-C02 tests whether you know when NOT to over-engineer.
Why Not Option B (EKS + Kubernetes Ingress)? #
- Pros: Modern, container-native, GitOps-friendly.
- Cons:
- EKS control plane: $73/mo fixed cost.
- Operational complexity: Requires Kubernetes expertise (RBAC, pod networking, persistent storage).
- Containerization effort: Must Dockerize the monolith, which is non-trivial for legacy code.
- Overkill: EKS shines for microservices orchestration at scale, not simple monolith hosting.
Exam Trap: This is the “resume-driven development” answer. Sounds impressive, but violates the simplicity principle.
Why Not Option C (Auto Scaling + Lambda + Route 53)? #
- Pros: Keeps the existing EC2 architecture.
- Cons:
- No native load balancing: Route 53 multi-value answers still distribute traffic randomly, not based on instance health or capacity.
- Lambda orchestration is brittle: Using Lambda to update Route 53 records on Auto Scaling events introduces:
- Propagation delay (DNS TTL caching).
- Race conditions if multiple instances scale simultaneously.
- Custom code maintenance (the Lambda function becomes a SPOF).
- Violates AWS best practices: ALB exists precisely to solve this problem natively.
Exam Trap: This is the “Rube Goldberg machine” answer. SAP-C02 penalizes unnecessary complexity.
The Architect Blueprint #
graph TD
User([Mobile Client]) -->|HTTPS| R53[Route 53
DNS: api.nexmobile.com]
R53 -->|Resolves to ALB DNS| ALB[Application Load Balancer
Public Subnet]
ALB -->|Health Checks & Load Distribution| TG[Target Group]
TG -->|Forwards to| EC2_1[EC2 Instance 1
Private Subnet]
TG -->|Forwards to| EC2_2[EC2 Instance 2
Private Subnet]
TG -->|Forwards to| EC2_N[EC2 Instance N
Private Subnet]
EC2_1 -.->|Auto Scaling| ASG[Auto Scaling Group
CPU-based policy]
EC2_2 -.->|Auto Scaling| ASG
EC2_N -.->|Auto Scaling| ASG
ASG -->|Registers new instances to| TG
style ALB fill:#FF9900,stroke:#232F3E,stroke-width:2px,color:#fff
style TG fill:#527FFF,stroke:#232F3E,stroke-width:2px,color:#fff
style ASG fill:#759C3E,stroke:#232F3E,stroke-width:2px,color:#fff
Diagram Note: The ALB acts as the single ingress point, distributing traffic across a dynamically-sized Auto Scaling group in private subnets, with health checks ensuring zero downtime during scale events.
The Decision Matrix #
| Option | Est. Complexity | Est. Monthly Cost | Pros | Cons |
|---|---|---|---|---|
| A) Lambda + API Gateway | High (Refactoring) | $200-800+ (depends on request volume; $3.50/M requests + Lambda invocations) | • True serverless scalability • No infrastructure management • Pay-per-use |
• Requires complete refactoring • Cold start latency • High cost at scale • Weeks/months to implement |
| B) EKS + Kubernetes | Very High (Containerization + K8s) | $300-600+ ($73 control plane + EC2 node costs + ingress controller) | • Modern, cloud-native • Microservices-ready • Portable |
• Massive operational overhead • Steep learning curve • Overkill for monolith • High fixed costs |
| C) ASG + Lambda + Route 53 | Medium-High (Custom orchestration) | $150-250 (EC2 + Lambda executions + Route 53 queries) | • Keeps existing architecture • Auto Scaling enabled |
• No true load balancing • DNS propagation delays • Fragile Lambda orchestration • Poor health awareness |
| D) ALB + ASG ✅ | Low (Infrastructure-only) | $100-180 (ALB ~$50 + EC2 instances ~$50-130) | • Fastest to deploy • Native health checks • Zero refactoring • Security improvement (private subnets) • Native ASG integration |
• Still running monolith (technical debt remains) • EC2 fixed costs (vs. serverless) |
FinOps Note: Option D delivers immediate business value at 20-40% the cost of Options A/B, with 90% less engineering risk. The monolith can be refactored incrementally after stability is restored.
Real-World Practitioner Insight #
Exam Rule #
For SAP-C02, when you see:
- Existing EC2-based application
- Need for immediate scalability
- No mention of “refactor” or “modernize” in requirements
- Route 53 multi-value routing causing issues
Always choose ALB + Auto Scaling as the first stabilization step, even if serverless/containers seem more “modern.”
Real World #
In production, Option D is exactly what we’d implement first in a P1 incident:
- Hour 0-2: Deploy ALB, migrate Route 53, move instances to private subnets.
- Hour 2-4: Attach Auto Scaling group, validate scaling policies.
- Week 2+: Refactor monolith into microservices incrementally, routing new services via ALB path-based rules.
The pragmatic CTO never chooses Option A/B during an outage. Stabilize first, modernize later. AWS Well-Architected Framework’s Reliability Pillar explicitly prioritizes “stop the bleeding” over “perfect architecture.”
We’d also add:
- CloudWatch alarms for ALB 5xx errors and target health.
- WAF on the ALB for DDoS protection.
- CloudFront in front of the ALB for edge caching (if API has cacheable endpoints).