SAP-C02
Deep Dive
The SAP-C02 expects you to design complex high-availability architectures by correctly choosing between load balancer types, scaling policies and EC2 purchasing strategies to optimize cost and performance.
Contents
| Feature | ALB (Application) | NLB (Network) | GWLB (Gateway) |
|---|---|---|---|
| OSI Layer | L7 — HTTP/HTTPS/gRPC | L4 — TCP/UDP/TLS | L3 — IP (all protocols) |
| Routing | Path, host, headers, query, HTTP method | IP:Port, TCP/UDP only | N/A — appliance injection |
| Latency | Milliseconds (L7 processing overhead) | Ultra-low (<1ms), L4 passthrough | Variable depending on the appliance |
| Static IPs | No (uses DNS) | Yes — static IP or Elastic IP | Not applicable |
| WebSocket | Native support | Yes (TCP) | Not applicable |
| gRPC | Native support | Not native | Not applicable |
| Preserves client IP | X-Forwarded-For header | Native support (PROXY Protocol) | Native support |
| Target Types | EC2, ECS, Lambda, IP | EC2, ECS, IP (on-prem with PrivateLink) | 3rd-party security appliances |
| Main use case | HTTP microservices, advanced routing, APIs | Extreme low latency, TCP/UDP, fixed IPs | Traffic inspection with 3rd-party appliances |
ALB — advanced features for the exam
NLB — advanced features for the exam
Scaling policy types
Simple Scaling
Adds/removes N instances when an alarm triggers. Has a cooldown period — won't scale again until it ends. Most basic option.
Step Scaling
Scales in steps based on alarm magnitude. e.g.: CPU 70-80% → +1 instance, CPU 80-90% → +2, CPU >90% → +3. No mandatory cooldown.
Target Tracking
Keeps a metric at a target value (e.g., 50% CPU). ASG scales up/down automatically. Smarter and simpler to configure.
Predictive Scaling
ML analyzes usage history and scales proactively before predictable spikes. Combines with Target Tracking for cyclical workloads.
Scheduled Scaling
Scales at specific times (e.g., +10 instances at 8am). For workloads that are predictable by time of day.
Advanced ASG configuration
Cluster Placement Group
Instances grouped on the SAME physical rack. Ultra-low network latency and maximum throughput between instances.
Spread Placement Group
Instances spread across DIFFERENT racks (up to 7 instances per AZ). Maximum isolation from hardware failures.
Partition Placement Group
Divides instances into partitions, each partition on a different rack. Up to 7 partitions per AZ, many instances per partition.
| Type | Discount vs On-Demand | Commitment | Best for |
|---|---|---|---|
| On-Demand | No discount (base price) | None — pay per second | Unpredictable workloads, dev/test, load testing |
| Reserved (Standard) | Up to 72% with 3-year all-upfront | 1 or 3 years, fixed family/region/OS | Stable production with predictable 24/7 usage |
| Reserved (Convertible) | Up to 54% with 3 years | 1 or 3 years, but you can change family/OS | Stable production but might change instance family |
| Savings Plans (Compute) | Up to 66% | 1 or 3 years, $ per hour commitment | Stable production, applies to EC2 + Fargate + Lambda |
| Savings Plans (EC2 Instance) | Up to 72% | 1 or 3 years, fixed family in a region | Production EC2 in a specific family/region |
| Spot Instances | Up to 90% | None — can be interrupted | Batch, CI/CD, ML training, tolerant stateless workloads |
| Dedicated Instances | ~10% more expensive than On-Demand | None | Compliance requiring dedicated (non-shared) hardware |
| Dedicated Hosts | More expensive — you pay for the physical host | On-Demand or Reserved (up to 70% discount) | BYOL licenses (SQL Server, Oracle), strict compliance |
Spot Fleet
Requests a mix of instance types and AZs to meet a target capacity. Maximizes Spot availability by diversifying across multiple pools.
Spot Interruption — how to handle it
On-Demand Capacity Reservations
Reserves EC2 capacity in a specific AZ with no time commitment. Guarantees availability for critical launches (DR drills, planned traffic spikes).
Dedicated Hosts vs Dedicated Instances
Dedicated Instances
Instances on hardware dedicated to your account, but the physical server can change across restarts. You can't see or control host placement. Basic compliance.
Dedicated Hosts
An entire physical server dedicated to you. Visibility into socket and core counts. Placement control. Required for BYOL of Oracle, SQL Server, Windows Server (per-core/per-socket licensing).
Multi-AZ design rules
Common anti-patterns
Trap: "Cluster Placement Group guarantees high availability"
Reality: FALSE. Cluster Placement Group maximizes network performance by grouping instances on the same rack — the opposite of HA. If the rack fails, every instance fails. For HA, use Spread Placement Group.
Trap: "Reserved Instances automatically apply to any EC2 instance"
Reality: Depends on the type. Standard Reserved Instances only apply to instances that match exactly (family, AZ, OS). Convertible RIs have more flexibility. Savings Plans Compute apply more broadly (EC2 + Fargate + Lambda).
Trap: "Dedicated Instances and Dedicated Hosts are equivalent"
Reality: They're different. Dedicated Instances guarantee there are no other tenants on the same physical server, but you don't control which server. Dedicated Hosts give you the specific physical server — required for BYOL that licenses per socket/core.
Trap: "ALB Cross-Zone Load Balancing has an extra cost"
Reality: ALB has Cross-Zone LB enabled by default and at NO extra cost. NLB has Cross-Zone LB disabled by default and incurs data transfer cost between AZs if enabled.
Did you get this topic?
Test what you just learned
A financial analysis firm runs 6-hour ML jobs that process historical data. The jobs can resume from checkpoints saved in S3 if interrupted. The team wants to minimize costs while keeping high availability to complete the jobs. What is the optimal EC2 configuration?
Put what you learned to the test with original SAP-C02 exam questions.
Start SAP-C02 mock examUnlimited mock exams with the Pro plan
Log in to track your progress.