While preparing for the SAA-C03, many candidates get confused by which AWS load balancer supports UDP and which database scales without intervention. In the real world, this is fundamentally a decision about low-latency transport compatibility (UDP) vs. operational simplicity and cost under spiky demand. Let’s drill into a simulated scenario.
The Scenario #
A startup called NeonArena Studios is building a real-time multiplayer arena game. Clients send fast, latency-sensitive state updates to game servers using UDP. The servers run in an EC2 Auto Scaling group and traffic predictably spikes during daytime hours.
The engineering team also needs a place to store player scores and other non-relational key-value data, and they want the database to scale automatically without manual capacity planning.
Key Requirements #
- Support UDP traffic from clients to game servers (Layer 4 requirement).
- Elastic scaling for compute (Auto Scaling already in use).
- Non-relational data store for scores and metadata.
- No-ops scaling for the database (minimal administration).
- Cost-aware for variable peak patterns (FinOps: avoid over-provisioning).
The Options #
- A) Use Amazon Route 53 for traffic distribution, and Amazon Aurora Serverless for storage.
- B) Use a Network Load Balancer (NLB) for traffic distribution, and Amazon DynamoDB On-Demand for storage.
- C) Use a Network Load Balancer (NLB) for traffic distribution, and Amazon Aurora Global Database for storage.
- D) Use an Application Load Balancer (ALB) for traffic distribution, and Amazon DynamoDB Global Tables for storage.
Correct Answer #
B
The Winning Logic #
- UDP requires Layer 4 load balancing: NLB supports UDP (and TCP/TLS) and can front an EC2 Auto Scaling group with very low overhead.
- Scores + non-relational + auto scaling: DynamoDB On-Demand is purpose-built for spiky workloads where you don’t want to manage capacity. It scales read/write throughput automatically.
- FinOps fit for daytime peaks: On-Demand aligns cost with actual usage during peaks and dips, avoiding paying for provisioned capacity you don’t consistently need.
💎 Professional-Level Analysis #
This section breaks down the scenario from a professional exam perspective, focusing on constraints, trade-offs, and the decision signals used to eliminate incorrect options.
🔐 Expert Deep Dive: Why Options Fail #
This walkthrough explains how the exam expects you to reason through the scenario step by step, highlighting the constraints and trade-offs that invalidate each incorrect option.
Prefer a quick walkthrough before diving deep?
[Video coming soon] This short walkthrough video explains the core scenario, the key trade-off being tested, and why the correct option stands out, so you can follow the deeper analysis with clarity.
🔐 The Traps (Distractor Analysis) #
This section explains why each incorrect option looks reasonable at first glance, and the specific assumptions or constraints that ultimately make it fail.
The difference between the correct answer and the distractors comes down to one decision assumption most candidates overlook.
- Why not A (Route 53 + Aurora Serverless)?
- Route 53 is DNS-based routing, not a real-time connection-aware load balancer for UDP flows.
- Aurora (even Serverless) is relational, while the requirement explicitly calls for non-relational data and hands-off scaling for that access pattern.
- Why not C (NLB + Aurora Global Database)?
- Aurora Global Database is for cross-region low-latency reads and DR, not required here.
- Still relational, and typically higher operational/cost footprint than needed for simple score storage.
- Why not D (ALB + DynamoDB Global Tables)?
- ALB does not support UDP (ALB is Layer 7 HTTP/HTTPS/gRPC).
- Global Tables are great for multi-region active-active, but that requirement is not stated—extra complexity/cost.
🔐 The Solution Blueprint #
This blueprint visualizes the expected solution, showing how services interact and which architectural pattern the exam is testing.
Seeing the full solution end to end often makes the trade-offs—and the failure points of simpler options—immediately clear.
graph TD
Player([Game Client
UDP]) --> NLB["Network Load Balancer
(UDP listener)"]
NLB --> ASG[EC2 Auto Scaling Group
Game Servers]
ASG --> DDB["DynamoDB
On-Demand"]
- Diagram Note: UDP packets flow through an NLB to an EC2 Auto Scaling fleet, while game servers persist scores to DynamoDB On-Demand for automatic scale.
🔐 Real-World Practitioner Insight #
This section connects the exam scenario to real production environments, highlighting how similar decisions are made—and often misjudged—in practice.
This is the kind of decision that frequently looks correct on paper, but creates long-term friction once deployed in production.
Exam Rule #
When you see UDP + load balancing, default to Network Load Balancer. When you see non-relational + “scales without intervention” + spiky traffic, default to DynamoDB On-Demand.
Real World #
If the game later needs multi-region active-active gameplay or ultra-low-latency global writes, you’d revisit:
- DynamoDB Global Tables (active-active multi-region)
- AWS Global Accelerator (global anycast entry, often paired with NLB) But for a single-region, spiky UDP game backend, NLB + DynamoDB On-Demand is the cleanest operational and cost-aligned baseline.