SAA-C03 cheat sheet
112 key facts across 4 exam domains, distilled from the full SAA-C03 revision notes — with the exam pattern behind each topic. Skim it the week of your exam.
Updated
Design Secure Architectures
30% of the examDesigning Secure Access: IAM Best Practices, Roles, and AWS Organizations
- SCPs never grant permissions — they cap the maximum; effective access is the intersection of SCPs, boundaries, and IAM policies, and an explicit deny always wins.
- SCPs bind member accounts including their root users, but never affect the management account.
- Anything running on AWS compute gets an IAM role, never access keys — temporary STS credentials eliminate rotation and leakage.
- Cross-account: assume a role for broad access; use a resource-based policy when the caller must keep its own permissions (the Lambda pattern).
- Third-party vendor access = cross-account role + external ID (confused-deputy defense) — never shared access keys.
- Workforce across many accounts = IAM Identity Center federated to the corporate IdP; app customers = Cognito; neither gets IAM users.
- Permissions boundaries cap what a delegated identity can do — the answer to "let developers create roles without privilege escalation."
- Control Tower = managed landing zone on top of Organizations: preventive controls are SCPs, detective controls are Config rules, Account Factory vends compliant accounts.
How the exam tests this
SAA-C03 tests this task with constraint-qualified scenarios: a working architecture plus "MOST secure," "LEAST operational overhead," or "following the principle of least privilege," where several options technically function and one best fits the qualifier. Classic shapes include the organization-wide restriction that must bind administrators (SCP), the application holding access keys (replace with a role), the cross-account Lambda or S3 access choice (role vs resource policy), the third-party vendor request (role plus external ID), and the workforce-at-scale question (IAM Identity Center over IAM users). Trap patterns to expect: options that use an SCP to grant access, claim SCPs restrict the management account, rotate access keys instead of eliminating them, or solve a many-account human-access problem by minting IAM users. When two options both work, the one that removes long-lived credentials or centralizes the control above the affected accounts usually wins.
Securing Workloads: VPC Design, Security Groups vs NACLs, WAF and Shield
- A route table defines the subnet: internet gateway route = public, NAT route = private, neither = isolated; only load balancers and NAT gateways belong in public subnets.
- Security groups are stateful, allow-only, per-resource; NACLs are stateless, ordered allow/deny, per-subnet — explicit deny of an IP means NACL.
- Reference security groups by ID between tiers (ALB SG → app SG → DB SG) instead of CIDRs — least privilege that survives Auto Scaling.
- Gateway endpoints (S3, DynamoDB only) are free route-table entries; interface endpoints (PrivateLink) cover most other services at a cost — prefer gateway for S3/DynamoDB in-VPC.
- Shield = DDoS at layers 3/4 (Advanced adds response team + cost protection); WAF = layer 7 (SQL injection, XSS, rate limiting) on CloudFront/ALB/API Gateway.
- GuardDuty detects threats from CloudTrail/flow/DNS logs; Macie finds sensitive data in S3 — behavior vs data.
- Cognito user pool = app sign-in and JWTs; identity pool = temporary AWS credentials (incl. guest access) — never ship access keys in an app.
- Secrets Manager when rotation or cross-account sharing is required; Parameter Store when cost-effective config/secret storage suffices; Direct Connect is private but unencrypted — add a VPN over it for encryption.
How the exam tests this
SAA-C03 probes this task by naming an exposure or a threat and demanding the design that closes it under a qualifier: a database in a public subnet (move it inward, reference security groups by ID), traffic to S3 that must avoid the internet and cost (gateway endpoint), SQL injection or DDoS (WAF vs Shield, split by OSI layer), hard-coded credentials (roles plus Secrets Manager or Parameter Store, split by the word rotation). Classic shapes include the three-tier VPC with one misplaced component, the stateful-vs-stateless connectivity mystery where responses never return (a NACL missing ephemeral ports), and the hybrid link requiring encryption (VPN over Direct Connect). Traps swap services across layers or purposes — WAF for a SYN flood, GuardDuty for finding PII, an interface endpoint for S3 when cost matters, a hardened bastion when Session Manager is on offer. Match the layer, the watched surface, and the qualifier, and one option remains.
AWS Data Security Controls: KMS Encryption, S3 Encryption, and Key Management
- Requirement mentions controlling key policies, rotation, disabling keys, or cross-account access → customer managed KMS key; AWS managed keys allow none of those.
- "Single-tenant," "dedicated hardware," or "AWS must never access key material" → CloudHSM; a plain audit/control requirement → KMS (CloudHSM loses every LEAST-operational-overhead contest).
- SSE-S3 for baseline encryption; SSE-KMS (customer managed key) when you must audit or control key usage; client-side encryption only when AWS must never see plaintext; Bucket Keys cut KMS costs at scale.
- EBS/RDS encryption is set at creation — encrypting existing resources is always snapshot → copy with encryption → restore/create new → cut over; in-place toggles are distractor bait.
- ACM certificates are regional and must match the resource's Region — except CloudFront, which always requires the certificate in us-east-1; ACM auto-renews its own DNS-validated certs, never imported ones.
- KMS automatic rotation keeps old key material, so nothing is re-encrypted and applications keying off the alias never change; imported key material can only be rotated manually via a new key + alias repoint.
- Enforce transit encryption explicitly: ALB HTTP→HTTPS redirect, CloudFront viewer protocol policy, and S3 bucket policies denying aws:SecureTransport=false.
- Retention language maps directly: "no one can delete, regulatory" → Object Lock compliance mode (+versioning); "recover from mistakes" → versioning/backups; "copy in another Region" → CRR; "find PII" → Macie; "never public" → Block Public Access.
How the exam tests this
SAA-C03 turns Task 1.3 into elimination problems: a scenario states an encryption requirement with one qualifying phrase — audit every key use, share with another account, AWS must never see plaintext, dedicated single-tenant hardware — and only one rung of the key-ownership ladder (SSE-S3 → SSE-KMS with AWS managed key → customer managed key → client-side/CloudHSM) satisfies it, while cheaper rungs appear as distractors. Procedural traps test whether you know encryption is fixed at creation: any option that enables encryption in place on an existing EBS volume or RDS instance is wrong, and the snapshot → encrypted-copy → restore sequence is the correct chain. Certificate questions hinge on placement (regional ACM certs vs the CloudFront us-east-1 rule) and on what renews itself (DNS-validated ACM certs) versus what you must re-import. Compliance and retention stems reward literal reading: "no user, including administrators" means Object Lock compliance mode, "identify PII" means Macie, "never traverse the public internet" means VPC endpoints, and "prevent any bucket from being public" means account-level Block Public Access.
Design Resilient Architectures
26% of the examScalable, Loosely Coupled Architectures: SQS, SNS, EventBridge, Step Functions
- A queue between tiers turns a traffic spike into a backlog: SQS plus a worker Auto Scaling group scaling on queue depth is the default spike-absorption redesign.
- SQS standard maximizes throughput with at-least-once delivery; FIFO trades throughput for strict ordering and exactly-once processing — pick FIFO only when the scenario demands order or no duplicates.
- Messages processed twice usually means the visibility timeout is shorter than processing time; messages that always fail belong in a dead-letter queue.
- One event, many independent consumers = SNS-to-SQS fan-out — every subscriber gets its own durable buffer, retries, and scaling signal.
- EventBridge wins when the scenario needs content-based routing, SaaS or AWS service events, or cross-account buses; SNS wins simple high-volume fan-out.
- Multi-step processes with retries, branching, or human approval are Step Functions — never chain Lambda functions synchronously.
- Lambda for short event-driven work (15-minute cap); Fargate for long-running containers with no servers to manage; ECS or EKS on EC2 only when you need instance-level control or Kubernetes itself.
- Scale horizontally behind an ELB across AZs with target tracking as the default policy; offload reads with ElastiCache and read replicas, and offload globally with CloudFront.
How the exam tests this
SAA-C03 tests this task with redesign scenarios: a tightly coupled architecture that loses requests during spikes, times out on a slow downstream, or requires code changes for every new consumer, plus a qualifier like MOST cost-effective or LEAST operational overhead. Classic shapes include the web-tier-to-worker-tier queue insertion, the SNS-to-SQS fan-out, choosing EventBridge for SaaS events or content-based routing, replacing chained Lambda functions with Step Functions, and picking Lambda vs Fargate vs ECS on EC2 against a stated runtime or control requirement. Trap patterns to expect: vertical scaling offered as the fix for a coupling problem, a single shared SQS queue where every consumer needs its own copy, FIFO queues chosen without an ordering requirement, and Lambda proposed for jobs that exceed 15 minutes. When two options both function, the one that adds a managed intermediary, keeps consumers independent, and scales each tier on its own signal usually wins.
AWS High Availability and Disaster Recovery: RTO, RPO, and the Four DR Levels
- High availability recovers quickly and may blip; fault tolerance never interrupts — "no interruption" or "no downtime" in the stem demands the costlier active-redundancy design.
- RPO is the data you can afford to lose, RTO is the downtime you can afford — extract both numbers before reading the options, then pick the cheapest strategy that meets them.
- The DR ladder trades cost for speed: backup and restore (hours) → pilot light (tens of minutes) → warm standby (minutes) → multi-site active-active (near zero).
- Pilot light replicates the data layer live with compute off; warm standby already serves at reduced capacity — "can it handle requests right now" is the boundary.
- RDS Multi-AZ is synchronous, automatic, in-Region availability with a standby that is NOT readable; read replicas are asynchronous, readable, and promoted manually for read scaling or cross-Region DR.
- Route 53 failover routing plus health checks moves users between Regions; weighted routing is the blue-green and canary lever.
- SPOFs hide in the setup: single instance (ASG + ELB), single AZ (span two), single NAT gateway (one per AZ), state on the instance (move it out).
- Raise service quotas in the recovery Region before you need failover capacity, and answer throttling errors with exponential backoff and jitter.
How the exam tests this
SAA-C03 tests this task with numbers-first scenarios: an RTO, an RPO, and a cost qualifier that together select exactly one of the four DR strategies — expect at least one question where two strategies meet the objectives and MOST cost-effective picks the cheaper rung. Classic shapes include the Multi-AZ vs read-replica choice (automatic synchronous failover vs readable asynchronous scaling), the Region-failover design built from Route 53 health checks plus failover routing, and the single-point-of-failure hunt where the flaw — one instance, one AZ, one NAT gateway, state on the server — is buried in the setup sentences. Trap patterns to expect: reading from the non-readable Multi-AZ standby, offering Multi-AZ as the answer to a Region-failure requirement, using cross-Region replication to defend against accidental deletion (that is versioning's job), and jumping to active-active when warm standby meets the stated numbers. When two options both satisfy the availability requirement, the one that recovers automatically, loses no data within the stated RPO, and runs the least idle infrastructure wins.
Design High-Performing Architectures
24% of the examHigh-Performing Storage: S3 vs EBS vs EFS, Volume Types, and Hybrid Options
- Classify by access pattern first: mounted raw disk = EBS (block), shared directories across instances = EFS/FSx (file), API-accessed web-scale data = S3 (object).
- EBS ladder: gp3 by default; io2 only when sustained high IOPS or consistent sub-millisecond latency exceeds gp3; st1 for cheap sequential throughput; sc1 for cold data. HDDs never boot.
- gp3 decouples performance from capacity — provision more IOPS or throughput without a bigger volume.
- Instance store is the fastest storage EC2 can touch and vanishes on stop or failure — correct only for replaceable or replicated data (caches, scratch, replicated cluster nodes).
- EFS = shared POSIX across AZs with elastic capacity; provisioned throughput fixes the small-but-busy file system. Windows/SMB/AD → FSx for Windows; HPC over S3 data → FSx for Lustre.
- S3 optimizations map to bottlenecks: multipart upload and byte-range fetches for large objects, Transfer Acceleration for long-distance uploads, prefix spreading for extreme request rates, CloudFront for global reads.
- Hybrid: Storage Gateway when on-premises needs ongoing low-latency access to cloud data (local cache); DataSync when data needs one-time or scheduled movement into AWS.
- Under MOST cost-effective, pick the cheapest option that still meets the stated performance; under MOST performant, meet the requirement — an overshoot like io2 for a modest database is the trap either way.
How the exam tests this
SAA-C03 tests Task 3.1 with scenario questions that describe an application's I/O behavior — random versus sequential, shared versus single-instance, temporary versus durable, local versus long-distance — and attach a qualifier like MOST performant, MOST cost-effective, or LEAST operational overhead. Classic shapes include the EBS volume-type ladder for a database with a stated IOPS or latency requirement, the S3-vs-EFS-vs-EBS choice for shared access across instances and AZs, the S3 optimization matched to its bottleneck (multipart, Transfer Acceleration, prefixes), and the Storage Gateway-vs-DataSync hybrid split. Expect traps that overshoot on cost (io2 where gp3 suffices), ignore the access pattern (S3 where a POSIX mount is required, EBS shared across AZs), or put irreplaceable data on instance store. When two options both work, the one that meets the stated requirement at the lower cost — or removes a provisioning task entirely — usually wins.
Elastic Compute: Auto Scaling Policies, Lambda Tuning, and Compute Selection
- Pick the compute service by duration, trigger, and management appetite: event-driven and under 15 minutes = Lambda; containers with least overhead = Fargate; hardware control = EC2; queued heavy jobs = AWS Batch; named big-data frameworks = EMR.
- The Batch-vs-Lambda-vs-EMR two-step: over 15 minutes rules out Lambda; a named framework (Spark/Hadoop) means EMR; otherwise batch jobs mean AWS Batch — with Spot for cost-sensitive, interruption-tolerant work.
- Choose EC2 families by the bottleneck resource — C for CPU, R/X for memory, I/D for local storage I/O, P/G for accelerators, M as the balanced default — and remember T-family credit exhaustion explains sustained-load slowdowns.
- Lambda's memory setting scales CPU proportionally: more memory can make a function faster AND cheaper if duration drops; the 15-minute cap is the universal eliminator; provisioned concurrency answers cold-start latency.
- Target tracking is the default scaling policy (hold a metric at a value); step scaling for custom thresholds and magnitudes; scheduled for fixed clocks; predictive for recurring patterns where reactive scaling lags slow-to-ready instances.
- Scale worker fleets on backlog per instance (SQS visible messages ÷ instances) as a custom metric with target tracking — capacity follows work, not CPU.
- Decouple tiers with queues (or SNS fan-out) so each scales independently on its own signal and bursts buffer instead of failing.
- ECS vs EKS is decided by whether Kubernetes is a stated requirement; Fargate vs EC2 launch type is decided by whether anything demands host control — and offloading reads to CloudFront can beat adding instances.
How the exam tests this
SAA-C03 tests Task 3.2 with traffic-shaped scenarios: a workload description, a pain point (lag during ramps, lost requests in bursts, slow functions, budget pressure), and a qualifier like LEAST operational overhead or MOST cost-effective. The most repeatable shapes are the scaling-policy match — recurring-but-variable patterns to predictive, fixed clocks to scheduled, steady utilization goals to target tracking, queue depth to a custom backlog-per-instance metric — and the compute-selection two-step, where a job's duration eliminates Lambda at 15 minutes and the presence or absence of a named big-data framework splits EMR from AWS Batch. Expect distractors that scale on CPU when the real signal is a queue, hand-build what Batch or Fargate provides managed, pick EKS with no Kubernetes requirement in sight, or reject Lambda memory increases on cost grounds without noticing the shorter duration. When two options both work, the one that acts on the workload's native signal — or removes infrastructure management entirely — usually wins.
High-Performing Databases: Aurora vs RDS, DynamoDB, DAX and ElastiCache
- Read replicas scale reads (asynchronous, readable, cross-Region capable); Multi-AZ is availability only — its synchronous standby cannot serve reads.
- Aurora's shared storage across three AZs enables up to 15 low-lag replicas behind one reader endpoint; Global Database adds cross-Region local reads and DR, Serverless v2 fits variable load.
- DynamoDB: on-demand for unpredictable or spiky traffic, provisioned (with auto scaling) for steady traffic at lower cost — throttling with capacity to spare means a hot partition, not a capacity problem.
- Fix hot partitions with key design — high-cardinality keys or write sharding — never by buying more capacity.
- GSI = new partition key, add anytime, eventually consistent; LSI = same partition key with an alternate sort key, table-creation time only. Default to the GSI.
- DAX is the microsecond, API-compatible cache purpose-built for DynamoDB; ElastiCache is the general cache for everything else.
- Redis brings persistence, replication with Multi-AZ failover, and data structures like sorted sets; Memcached is the simple, multi-threaded cache with no durability.
- Lazy loading risks stale data (bound it with TTLs); write-through keeps data fresh at the cost of doubled writes; RDS Proxy pools connections for Lambda and connection-heavy apps.
How the exam tests this
SAA-C03 tests this task with workload-shaped scenarios plus a qualifier: a read-heavy, write-heavy, spiky, or global workload and MOST cost-effective, LEAST operational overhead, or a hard latency word (milliseconds vs microseconds). Classic shapes include the read-offload choice (read replicas vs Multi-AZ vs ElastiCache — pick by whether reads are repeated, analytical, or an availability requirement in disguise), the Aurora upgrade pitch (15 low-lag replicas, reader endpoint, Global Database for global reads, Serverless v2 for variable load), the DynamoDB capacity-mode call (unpredictable → on-demand; steady → provisioned + auto scaling), the hot-partition diagnosis (throttling despite spare capacity → fix the key, not the capacity), DAX vs ElastiCache (microseconds + DynamoDB + no rewrite → DAX), and Redis vs Memcached (durability, failover, sorted sets → Redis). Trap patterns: Multi-AZ offered for read scaling, more capacity offered for a hot partition, ElastiCache offered where DAX's API compatibility is the stated need, and relational engines offered for fixed key-value access at scale. Latency and consistency words eliminate fastest — read them before the answer options.
Scalable Networks: CloudFront vs Global Accelerator, Transit Gateway, ALB vs NLB
- CloudFront caches and accelerates HTTP content; Global Accelerator provides two static anycast IPs for TCP/UDP with near-instant cross-Region failover — protocol and static-IP requirements decide between them.
- ALB for HTTP routing (path/host rules, Lambda targets); NLB for TCP/UDP at extreme scale, ultra-low latency, static IP/EIP, and source-IP preservation; GWLB for inline third-party security appliances.
- Size VPC CIDRs for future growth and keep every range non-overlapping — overlap permanently blocks peering and hybrid routing; secondary CIDRs relieve IP exhaustion.
- Placement groups: cluster = lowest latency, one AZ (HPC); spread = max seven instances per AZ on distinct hardware (critical few); partition = failure-isolated groups for large distributed systems (Kafka, Hadoop).
- VPC peering is never transitive — hub-and-spoke or many-VPC connectivity means Transit Gateway; a few stable VPC pairs stay on peering.
- PrivateLink exposes one NLB-fronted service to many consumer VPCs without merging networks — and it tolerates overlapping CIDRs, which peering and TGW cannot.
- Direct Connect buys consistent latency and bandwidth for steady heavy transfer (weeks to provision, not encrypted by default); Site-to-Site VPN is fast, cheap, encrypted, internet-variable — and the standard DX failover.
- Route 53 latency-based routing sends each user to the fastest Region; same-AZ placement minimizes latency and cross-AZ data charges, but multi-AZ spread wins whenever availability is the stated priority.
How the exam tests this
SAA-C03 tests this task as constrained selection: several networking options genuinely work, and one stem detail — a UDP protocol, a static-IP allowlist, a hundred-VPC estate, an overlapping CIDR — makes exactly one correct. Classic shapes include CloudFront vs Global Accelerator (protocol and static IPs decide, not "global users"), ALB vs NLB (fixed IP, UDP, extreme throughput, or source-IP preservation flips it to NLB; inline security appliances mean GWLB), the non-transitive peering trap (traffic routed "through" a hub VPC over peering never flows — the fix is Transit Gateway), peering vs Transit Gateway vs PrivateLink by scale and scope (pairs → peering; many-to-many plus hybrid → TGW; one service to many consumers or overlapping CIDRs → PrivateLink), Direct Connect vs VPN by the words "consistent" and "predictable" versus "quickly" and "cost-effective," and placement groups by workload keyword (HPC → cluster; critical few → spread; Kafka/Hadoop → partition, remembering spread's seven-per-AZ cap). Expect qualifiers to arbitrate between two working rows of the decision table, and expect distractors that ignore a hard limit — transitive peering, an ALB with an Elastic IP, a spread group holding forty instances — which one memorized fact eliminates.
Data Ingestion & Transformation: Kinesis, Glue, Athena, and Lake Formation
- Kinesis Data Streams = real-time with custom consumers, replay (up to 365-day retention), and per-shard ordering via partition key; on-demand mode when throughput is unpredictable.
- Amazon Data Firehose = fully managed near-real-time delivery to S3, Redshift, or OpenSearch with buffering, inline Lambda transforms, and built-in conversion to Parquet — no consumers, no shards, no replay.
- "Kafka" in the scenario means Amazon MSK; the classic composite is Data Streams for real-time consumers with Firehose archiving the same stream to S3.
- Transfer selection: DataSync = one-time or scheduled copies into S3/EFS/FSx; Storage Gateway = ongoing hybrid access; Transfer Family = managed SFTP/FTPS into S3; Snow family = offline bulk.
- The data lake is S3 plus the Glue Data Catalog; Lake Formation centralizes database/table/column-level permissions enforced across Athena, Redshift Spectrum, EMR, and Glue.
- Glue crawlers infer schemas into a catalog shared by Athena, EMR, and Redshift Spectrum; Glue jobs are the serverless (LEAST-overhead) way to run ETL like CSV-to-Parquet.
- Query selection: Athena for serverless ad hoc SQL on S3 (pay per data scanned), Redshift for repeated heavy BI on loaded data, EMR for custom Spark/Hadoop control; QuickSight for dashboards.
- Columnar Parquet/ORC plus compression plus date partitioning is THE Athena cost/performance fix — via a Glue job for existing data or Firehose format conversion for new streams.
How the exam tests this
SAA-C03 tests this task as service selection under qualifiers: a streaming requirement plus "no consumer code / deliver to S3 / near-real-time / least overhead" selects Firehose, while "real-time processing," "replay," or "ordering" selects Data Streams and the word "Kafka" selects MSK. Transfer questions hinge on frequency and access clues — scheduled copy (DataSync), ongoing hybrid access (Storage Gateway), partner SFTP (Transfer Family), offline bulk (Snow). Expect the Athena cost/performance scenario where CSV-to-Parquet conversion plus date partitioning beats capacity-shaped distractors like migrating to Redshift, and a governance question where Lake Formation's centralized column-level permissions beat hand-built bucket-policy sprawl. Traps to expect: Data Streams offered where nobody will write a consumer, EMR offered for a routine transformation Glue handles serverlessly, and Redshift offered for occasional ad hoc queries that Athena serves without infrastructure.
Design Cost-Optimized Architectures
20% of the examCost-Optimized Storage: S3 Classes, Lifecycle Policies, and EBS Economics
- Match S3 class to stated access frequency and retrieval tolerance, then veto any option whose minimum duration (IA 30 days, Glacier Instant/Flexible 90, Deep Archive 180) or retrieval fees conflict with the scenario's retention or access pattern.
- One Zone-IA is only correct for re-creatable or secondary-copy data — never the sole copy of anything important.
- Unknown or changing access patterns = S3 Intelligent-Tiering: monitoring fee, but no retrieval fees and no minimum-duration charges.
- Versioned buckets need noncurrent-version expiration, and every upload bucket needs AbortIncompleteMultipartUpload — both are lifecycle rules, not manual cleanup.
- gp3 beats gp2: lower per-GB price plus a free 3,000 IOPS / 125 MiB/s baseline independent of size — never oversize a volume to buy IOPS; use st1/sc1 for cheap sequential throughput.
- Audit for the four leaks: unattached EBS volumes, stale snapshots (incremental — old ones are safe to delete; automate with DLM, archive long-keep ones), noncurrent versions, incomplete multipart uploads.
- Cheapest service by requirement: S3 whenever object access works, EBS only for single-instance block, EFS only when many instances must mount a shared file system — and enable EFS lifecycle to IA either way.
- Archive tier = retrieval tolerance (ms → Glacier Instant, hours → Flexible, ~12h+ → Deep Archive); migrate by bandwidth math — DataSync when the link can carry it or sync is ongoing, Snowball when shipping is faster.
How the exam tests this
SAA-C03 tests this task almost exclusively with MOST cost-effective scenarios: several storage designs work, and the correct one is the cheapest that still meets every stated number — retention period, retrieval-time tolerance, access frequency, resilience. Classic shapes include the lifecycle waterfall (pick transitions and expirations that respect minimum durations), the class choice where a stated access frequency makes the IA or Glacier option a retrieval-fee trap, One Zone-IA offered for a sole copy of important data, the EBS audit (gp2 to gp3, unattached volumes, snapshot pruning), and the migration bandwidth-math question (DataSync vs Snowball). Watch for options that save money by breaking a requirement — deleting compliance data, archiving below the needed retrieval speed, or single-AZ storage for irreplaceable data — and for tool swaps in cost-visibility questions (Budgets alerts; Cost Explorer analyzes; the CUR details; tags attribute).
Cost-Optimized Compute: Spot vs Reserved vs Savings Plans, and Lambda vs EC2
- Layer the purchase mix: Savings Plans/RIs sized to the steady baseline (up to 72% off), On-Demand behind Auto Scaling for the variable layer, Spot (up to 90% off) for interruptible work — never commit to peak, never put un-interruptible work on Spot.
- Expecting instance needs to change selects the flexible commitment: Compute Savings Plan (follows family, size, Region, OS — and covers Fargate and Lambda) or Convertible RIs; Standard RIs and EC2 Instance Savings Plans lock the family for the deepest discount.
- Spot is only for stateless, fault-tolerant, or checkpointable work — and only safe in an ASG mixed instances policy: On-Demand base, Spot percentage, many instance types across AZs, price-capacity-optimized allocation.
- Right-size before you discount: Compute Optimizer flags over-provisioned instances (and Lambda memory); newer generations and Graviton deliver better price-performance for compatible workloads.
- Pick compute by utilization: Lambda wins at low or spiky volume (pay per request; 15-minute cap), EC2 with commitments wins at sustained high utilization, Fargate wins for containers without cluster management — until high sustained density makes EC2-backed containers cheaper.
- Scale-in is the savings half of Auto Scaling: target tracking and scheduled scaling remove capacity off-peak, and non-production environments should stop outside working hours — never buy production availability for dev/test.
- Hibernation resumes with RAM intact — you pay storage, not compute, while hibernated — for intermittently used workloads with expensive warm-up.
- Offload before you scale: CloudFront caching shrinks the origin fleet; one ALB with path-based routing replaces per-service load balancers; NLB is for raw layer-4 throughput, not HTTP routing.
How the exam tests this
SAA-C03 tests this task with MOST cost-effective scenarios where several designs run the workload and one pays least without breaking a requirement. The flagship shape is the layered purchase mix: a described baseline, a variable peak, and a batch tier, graded on matching Savings Plans/RIs, On-Demand with Auto Scaling, and Spot to the right layers. Expect the Spot admission test (interruption tolerance) with mixed-instances resilience details — On-Demand base, diversified pools — deciding between options, and Lambda-vs-EC2-vs-Fargate choices decided by stated utilization plus constraints like the 15-minute Lambda ceiling. Distractor patterns: committing to peak demand, Reserved capacity for spiky or part-time workloads, Spot under stateful or baseline tiers, serverless for sustained hot workloads, and per-service load balancers where one ALB with path routing would do. When two options both work, the one that right-sizes first, commits only to the steady floor, and pushes interruptible work to Spot wins.
Cost-Optimized Databases: DynamoDB vs RDS, Aurora Serverless, and Caching
- Workload shape decides the pricing model: idle-heavy or unpredictable load belongs on serverless (Aurora Serverless v2, DynamoDB on-demand); steady 24/7 load belongs on provisioned capacity with Reserved Instances.
- RDS bills instance-hours whether or not queries arrive; DynamoDB bills requests and storage — an idle DynamoDB table costs almost nothing, an idle RDS instance costs full price.
- On-demand and serverless carry a per-unit premium: steady, well-utilized workloads are cheaper on provisioned capacity — never reserve an instance that sits idle, and never run steady high volume on on-demand.
- Repetitive read load plus staleness tolerance means cache (ElastiCache/DAX) — a cache node is cheaper than a bigger instance or full-price read replicas; diverse or must-be-fresh reads mean a replica.
- Open-source engines (MySQL, PostgreSQL, Aurora) carry no license cost; when a scenario complains about Oracle/SQL Server licensing, the answer is SCT + DMS heterogeneous migration — one-time effort for a permanent saving.
- Backup storage equal to your provisioned storage is included free for active databases — align retention to the stated RPO, delete stale manual snapshots, and archive long-term history via snapshot exports to S3/Glacier.
- Provisioned IOPS is for measured, sustained IOPS needs only — gp3 covers most databases; over-provisioned IOPS and oversized instance classes are planted waste in scenarios.
- Aurora's premium buys shared-storage replicas (up to 15 without duplicating storage) and pay-per-use storage — cheaper than RDS at replica-heavy scale, costlier for small single-instance workloads.
How the exam tests this
SAA-C03 tests this task with a workload description and a MOST cost-effective qualifier: the traffic-shape adjective in the first sentence — steady, spiky, intermittent, unpredictable, read-heavy — is usually the key that unlocks the answer. Classic shapes include the business-hours database burning 24/7 instance-hours (Aurora Serverless v2), the capacity-mode choice for a described DynamoDB traffic pattern, the read-heavy database where a cache beats replicas and instance upgrades, the Oracle licensing complaint (SCT + DMS to an open-source engine), and the retention or stale-snapshot audit. Trap patterns to expect: Reserved Instances offered for idle-heavy workloads, on-demand DynamoDB offered for steady high volume, a DynamoDB migration offered where relational features are required, and answers that cut cost by breaking a stated RPO or compatibility requirement. When two options both work, the one that stops paying for idle time — or serves the same reads from cheaper capacity — wins.
Cost-Optimized Networking: NAT Gateways, VPC Endpoints, and Data Transfer
- Price the path before the fix: inbound is free, same-AZ private traffic is free, cross-AZ is charged both directions, cross-Region and internet egress are charged — the right answer moves traffic onto a free segment.
- Gateway VPC endpoints for S3 and DynamoDB are free and eliminate NAT processing charges for that traffic — the single most-tested network cost fix; interface endpoints for other services cost less than NAT only at volume.
- NAT gateways bill hourly plus per GB processed: single shared NAT for cost-first environments (accepting cross-AZ charges and AZ risk), per-AZ NATs when an availability requirement or heavy multi-AZ egress justifies the extra hourly fees.
- A NAT instance is the cheap, self-managed, legacy option — right only when the scenario accepts operational burden for minimum cost, wrong whenever managed or highly available is stated.
- CloudFront cuts egress twice: edge caching collapses origin fetches, and AWS-origin-to-CloudFront transfer is free — reach for it when an egress bill grows with content popularity, not Global Accelerator (a performance premium).
- VPN is low fixed cost, quick to deploy, ~1.25 Gbps per tunnel (scale with multiple tunnels + ECMP); Direct Connect is high fixed cost with a lower per-GB rate at steady volume and weeks to provision — volume and timeline decide.
- VPC peering has no hourly or processing fees — cheapest for a few stable VPCs; Transit Gateway's per-attachment and per-GB fees buy transitive routing and manageability that pay off at many VPCs; PrivateLink is for exposing one service to many VPCs.
- Never buy cost with a stated requirement: consolidating to one AZ or one NAT is only correct when the scenario imposes no availability requirement — MOST cost-effective always means cheapest among designs that still meet every requirement.
How the exam tests this
SAA-C03 tests this task by describing a traffic path and asking for the MOST cost-effective change that still meets every stated requirement — the requirements sentence usually decides between the cheap option and the resilient one. The banner question is the NAT bill inflated by S3 or DynamoDB traffic from private subnets, answered by a free gateway VPC endpoint; close behind are the single-versus-per-AZ NAT decision (the availability requirement flips the answer), VPN versus Direct Connect selected on volume and provisioning timeline, peering versus Transit Gateway selected on VPC count, and the growing egress bill answered by CloudFront. Trap patterns to expect: resizing or multiplying NAT gateways to cut a per-GB charge, an interface endpoint for S3 where the free gateway endpoint exists, Global Accelerator offered as a transfer cost saver, single-AZ consolidation offered despite a high-availability requirement, and Transit Gateway proposed for three stable VPCs. Annotate each hop as charged or free, then pick the option that moves the biggest charged flow onto a free path without breaking a requirement.