Jeff’s Insights #
“Unlike generic exam dumps, Jeff’s Insights is designed to make you think like a Real-World Production Architect. We dissect this scenario by analyzing the strategic trade-offs required to balance operational reliability, security, and long-term cost across multi-service deployments.”
While preparing for the AWS SAP-C02, many candidates get confused by Aurora Auto Scaling configurations and load balancer selection for stateful applications. In the real world, this is fundamentally a decision about read scalability vs. write bottlenecks and session persistence vs. distributed state management. Let’s drill into a simulated scenario.
The Architecture Drill (Simulated Question) #
Scenario #
TechFlow Analytics runs a legacy two-tier web analytics platform in their on-premises data center. The application tier consists of a single server running a stateful Java application that maintains user session data in memory. This application connects to a PostgreSQL database running on a separate physical server for persistent storage.
The company has secured Series B funding and anticipates a 400% increase in concurrent users over the next six months. The CTO has mandated a cloud migration to AWS to support this growth trajectory. The architecture team has selected Amazon Aurora PostgreSQL for the database layer, EC2 Auto Scaling for the application tier, and Elastic Load Balancing for traffic distribution.
The Requirement #
Design a migration architecture that:
- Maintains session consistency for the stateful application during horizontal scaling
- Supports both application-tier and database-tier scaling to handle traffic spikes
- Provides a consistent user experience without session loss during scale events
- Minimizes architectural complexity while maintaining cloud-native best practices
The Options #
- A) Enable Aurora Auto Scaling for Aurora Replicas; use Network Load Balancer (NLB) with least outstanding requests routing algorithm and enable sticky sessions.
- B) Enable Aurora Auto Scaling for the Aurora Writer instance; use Application Load Balancer (ALB) with round-robin routing algorithm and enable sticky sessions.
- C) Enable Aurora Auto Scaling for Aurora Replicas; use Application Load Balancer (ALB) with round-robin routing algorithm and enable sticky sessions.
- D) Enable Aurora Auto Scaling for the Aurora Writer instance; use Network Load Balancer (NLB) with least outstanding requests routing algorithm and enable sticky sessions.
Correct Answer #
Option C.
The Architect’s Analysis #
Correct Answer #
Option C — Enable Aurora Auto Scaling for Aurora Replicas; use Application Load Balancer (ALB) with round-robin routing algorithm and enable sticky sessions.
The Winning Logic #
This solution optimally addresses both the database scalability constraint and the application statefulness requirement:
-
Aurora Replicas Auto Scaling (Database Layer)
- Aurora’s architecture uses a single Writer instance for all write operations and up to 15 Read Replicas for read operations
- Auto Scaling works only with replicas, not the writer instance
- For analytics workloads (typically read-heavy with 80:20 read/write ratios), horizontal replica scaling provides the needed capacity elasticity
- Replicas share the same storage layer (cluster volume), ensuring read-after-write consistency within ~20ms
-
Application Load Balancer with Sticky Sessions (Application Layer)
- ALB operates at Layer 7 (application layer), understanding HTTP/HTTPS protocols
- Sticky sessions (session affinity) ensure that a user’s requests are consistently routed to the same EC2 instance, preserving in-memory session state
- Round-robin distributes new sessions evenly across healthy instances
- ALB’s native integration with Auto Scaling groups enables automatic target registration/deregistration
- ALB supports health checks at the application level (e.g., checking
/healthendpoint)
-
Trade-off Optimization
- Cost: Aurora Replicas cost the same per instance as the writer (e.g., db.r6g.xlarge at ~$0.26/hour), but you only add capacity when needed via Auto Scaling
- Performance: Replicas can serve reads with <20ms lag, sufficient for analytics dashboards
- Operational simplicity: ALB sticky sessions require zero application code changes, whereas migrating to distributed session management (ElastiCache, DynamoDB) would require significant refactoring
The Trap (Distractor Analysis) #
-
Why not Option A (NLB + Aurora Replicas)?
- Partially correct on the database side (Aurora Replicas Auto Scaling is correct)
- NLB operates at Layer 4 (transport layer), which means sticky sessions are based on source IP, not application-layer cookies
- Source IP stickiness fails when users are behind NAT gateways, corporate proxies, or mobile networks with dynamic IPs
- Least outstanding requests is not a supported NLB routing algorithm (this is an ALB feature); NLB uses flow hash algorithm
- Exam trap: Tests whether you know ALB vs. NLB capabilities and routing algorithms
-
Why not Option B (ALB + Aurora Writer Auto Scaling)?
- ALB configuration is correct (Layer 7, sticky sessions, round-robin)
- Fatal flaw: Aurora Writer instances cannot be auto-scaled horizontally—you can only scale them vertically (change instance class)
- You can have only one writer in a standard Aurora cluster
- Exam trap: Tests understanding of Aurora’s fundamental architecture constraint—this is a professional-level distinction
-
Why not Option D (NLB + Aurora Writer)?
- Double failure: Combines both incorrect elements
- Wrong load balancer type (NLB lacks application-layer sticky sessions)
- Wrong Aurora scaling target (Writer cannot horizontally scale)
- Exam trap: This is the “worst of both worlds” option designed to catch candidates who are guessing
The Architect Blueprint #
Diagram Note: The architecture separates write traffic (routed to the single Aurora Writer) from read traffic (distributed across auto-scaled Aurora Replicas), while ALB sticky sessions maintain session affinity to preserve in-memory application state during horizontal scaling.
The Decision Matrix #
| Option | Est. Complexity | Est. Monthly Cost | Pros | Cons |
|---|---|---|---|---|
| A: NLB + Aurora Replicas | Medium | $1,850/mo (NLB: $16, 2×EC2 t3.large: $120, Writer db.r6g.xlarge: $187, 2×Replicas: $374/mo avg with scaling, Data transfer: ~$1,153) |
✅ Correct Aurora scaling strategy ✅ Low NLB latency (~100μs) ✅ Static IP support |
❌ Source IP sticky sessions fail with NAT/proxies ❌ No application-layer routing ❌ “Least outstanding requests” not supported on NLB |
| B: ALB + Aurora Writer Scaling | Low | $2,100/mo (ALB: $24, 2×EC2 t3.large: $120, Writer db.r6g.2xlarge over-provisioned: $374, No replicas, Data transfer: ~$1,582) |
✅ Correct load balancer choice ✅ Application-layer sticky sessions work correctly |
❌ Fatal: Cannot horizontally scale Aurora Writer ❌ Single point of failure ❌ Must vertically over-provision writer (expensive) |
| C: ALB + Aurora Replicas ✅ | Medium | $1,858/mo (ALB: $24, 2×EC2 t3.large: $120, Writer db.r6g.xlarge: $187, 2×Replicas: $374/mo avg with scaling, Data transfer: ~$1,153) |
✅ Correct Aurora scaling (Replicas) ✅ Application-layer sticky sessions ✅ Layer 7 routing flexibility ✅ Native Auto Scaling integration ✅ Best cost-performance ratio |
⚠️ Requires application to separate read/write queries (common pattern) ⚠️ ~20ms replica lag (acceptable for analytics) |
| D: NLB + Aurora Writer | Low | $2,108/mo (NLB: $16, 2×EC2 t3.large: $120, Writer db.r6g.2xlarge over-provisioned: $374, No replicas, Data transfer: ~$1,598) |
⚠️ Simple architecture | ❌ Cannot scale Aurora Writer horizontally ❌ Source IP sticky sessions unreliable ❌ Most expensive option ❌ Single database bottleneck |
Cost Calculation Notes:
- EC2: t3.large (2 vCPU, 8GB) at $0.0832/hour × 730 hours × 2 instances
- Aurora Writer: db.r6g.xlarge at $0.256/hour × 730 hours
- Aurora Replicas: Assumes average of 2 replicas with Auto Scaling (scales 1-4 based on CPU)
- ALB: $0.0225/hour + ~$0.008/LCU for moderate traffic
- Data transfer: Estimated at ~5TB/month cross-AZ reads at $0.01/GB
FinOps Insight: Option C delivers identical infrastructure costs to Option A ($8/month difference is negligible) but with vastly superior session management reliability. The cost difference versus over-provisioned Writer options (B, D) is ~$250/month (12% savings), while providing better fault tolerance.
Real-World Application (Practitioner Insight) #
Exam Rule #
For the SAP-C02 exam, when you see:
- “Stateful application” → Always choose sticky sessions
- “Aurora Auto Scaling” → It’s always Replicas, never the Writer
- “HTTP/HTTPS application” → Prefer ALB over NLB for application-layer features
- “Consistent user experience” → Session affinity is required
Real World #
In production environments, we would likely refactor this architecture within 6-12 months:
-
Short-term (Exam Solution): Option C is correct and pragmatic for immediate migration with minimal code changes.
-
Medium-term Evolution (3-6 months):
- Migrate session state to Amazon ElastiCache (Redis) or DynamoDB for distributed session management
- This eliminates sticky session dependency, enabling true stateless horizontal scaling
- Cost: Add ~$50/month for cache.t3.micro ElastiCache cluster
- Benefit: Survive instance failures without session loss, enable cross-region failover
-
Long-term Optimization (6-12 months):
- Implement Aurora Global Database for multi-region DR (RPO <1 second, RTO <1 minute)
- Consider Aurora Serverless v2 if traffic patterns are unpredictable (scales in 0.5 ACU increments)
- Implement connection pooling (RDS Proxy) to reduce database connection overhead during scaling events
- Cost: RDS Proxy adds ~$15/month but reduces replica count needs by ~30%
-
Architectural Alternatives Not Mentioned:
- AWS Global Accelerator in front of ALB for static anycast IPs (adds $0.025/hour + data transfer costs)
- Aurora Multi-Master for write scalability (more complex, requires application-level conflict resolution)
- DynamoDB instead of Aurora if the data model is key-value suitable (different cost model, potentially 40% cheaper at scale)
Why the Exam Doesn’t Test This: SAP-C02 focuses on immediate technical correctness and AWS service capabilities. Real-world decisions involve business timeline constraints, team skill gaps, and incremental modernization strategies that can’t be captured in a multiple-choice question.
Disclaimer
This is a study note based on simulated scenarios for the AWS SAP-C02 exam. It is not an official question from the certification body. The scenario, company name, and specific details have been rewritten to provide educational value while respecting intellectual property rights. All technical logic and AWS service behaviors reflect accurate cloud architecture principles as of 2025.