Study guide
4.1 Compute Cost Optimization — Right-Sizing, RIs, Savings Plans, and Spot
AWS Solutions Architect Associate SAA-C03
Track your progress as you read
Finished sections get a check mark.
1 Introduction
About the AWS Solutions Architect Associate (SAA-C03) Exam Study Strategies and Exam Tips for SAA-C03 The AWS Well-Architected Framework
2 Domain 1: Design Secure Architectures (30%)
1.1 IAM Fundamentals — Users, Groups, Roles, and Policies 1.2 AWS Organizations, SCPs, and Multi-Account Strategy 1.3 VPC Security — Security Groups, NACLs, and VPC Endpoints 1.4 Encryption, KMS, and Secrets Management 1.5 AWS WAF, Shield, and Network Firewall 1.6 GuardDuty, Inspector, Macie, and Security Hub 1.7 The Shared Responsibility Model for Solutions Architects 1.8 Data Protection, Compliance, and Audit Services
3 Domain 2: Design Resilient Architectures (26%)
2.1 Elastic Load Balancing (ELB) — ALB, NLB, and GWLB 2.2 EC2 Auto Scaling — Dynamic, Predictive, and Scheduled 2.3 Multi-AZ and Multi-Region Architectures 2.4 Disaster Recovery Strategies — RTO and RPO 2.5 Decoupling with SQS, SNS, and EventBridge 2.6 AWS Step Functions and Workflow Orchestration
4 Domain 3: Design High-Performing Architectures (24%)
3.1 EC2 Instance Types, Purchasing Options, and Placement Groups 3.2 Lambda, Serverless Compute, and Container Services 3.3 Amazon S3 - Storage Classes, Lifecycle, and Performance 3.4 Block and File Storage - EBS, EFS, and FSx 3.5 Database Services - RDS, Aurora, DynamoDB, and More 3.6 CloudFront, Route 53, and Global Accelerator 3.7 Data Ingestion and Transformation - Kinesis, Glue, and EMR
5 Domain 4: Design Cost-Optimized Architectures (20%)
4.1 Compute Cost Optimization — Right-Sizing, RIs, Savings Plans, and Spot 4.2 Storage Cost Optimization — S3 Tiers, EBS, and Data Transfer 4.3 Database Cost Optimization 4.4 AWS Cost Management and Monitoring Tools
6 VPC and Networking Deep Dive
5.1 VPC Architecture — Subnets, Route Tables, and Gateways 5.2 VPC Connectivity — Peering, Transit Gateway, and Direct Connect 5.3 Amazon API Gateway 5.4 CloudFormation and Infrastructure as Code 5.5 AWS PrivateLink and Endpoint Services
7 Migration, Transfer, and Hybrid Services
6.1 The 7 Rs of Cloud Migration 6.2 AWS Snow Family — Snowball Edge Devices 6.3 CloudWatch, CloudTrail, and AWS Config 6.4 Amazon Cognito and Identity Federation 6.5 AWS DataSync and Transfer Family
8 Serverless Architecture and Application Services
7.1 Serverless Architecture Patterns 7.2 Advanced SQS Patterns — DLQ, Backpressure, and FIFO 7.3 Analytics Services — Athena, OpenSearch, and QuickSight 7.4 Container Orchestration — ECS, EKS, and ECR
9 Advanced Topics and Exam Scenarios
8.1 Advanced IAM — Permission Boundaries, Federation, and Cross-Account 8.2 Caching Strategies and ElastiCache Patterns 8.3 Hybrid Architecture — DNS, Storage, and Compute 8.4 SAA-C03 Scenario Practice — Putting It All Together
4.1 Compute Cost Optimization — Right-Sizing, RIs, Savings Plans, and Spot
Key Takeaways Explain This Topic AI
Domain 4 is 20% of the SAA-C03 exam (65 questions, 130 minutes, 720/1000 to pass) — roughly 11-13 scored questions test cost-optimized design.
Right-size first (AWS Compute Optimizer), then auto-scale, then apply a pricing model — never buy commitments for an unmeasured workload.
Reserved Instances and Savings Plans both save up to 72% on EC2; Savings Plans are the more flexible answer for mixed EC2/Lambda/Fargate fleets.
Spot Instances save up to 90% but can be reclaimed with a 2-minute warning — only correct for fault-tolerant, stateless, or checkpointable work.
Lambda and Fargate Spot eliminate idle compute charges entirely for bursty or sporadic workloads where steady EC2 would sit unused.
Last updated: June 2026
Why Domain 4 Matters
Design Cost-Optimized Architectures is 20% of the SAA-C03 exam. With 65 questions in 130 minutes (15 unscored, 50 scored) and a scaled passing score of 720/1000 , roughly 11-13 scored items live here. Questions rarely ask "what is cheapest" in the abstract — they describe a traffic shape (steady, spiky, interruptible, or part-time) and ask for the cheapest model that still meets stated availability or latency requirements.
The Optimization Order (Memorize This)
Apply these in sequence — buying a commitment before right-sizing locks in waste:
Right-size — stop over-provisioning vCPU/RAM.
Auto Scale — never pay for idle capacity.
Pricing model — match commitment to the workload's predictability.
Architecture — move bursty work to serverless (Lambda, Fargate).
Right-Sizing Tools and Signals
- Tool What it inspects
- AWS Compute Optimizer ML right-sizing for EC2, Auto Scaling groups, EBS, Lambda memory, Fargate
- AWS Cost Explorer RI/Savings Plan recommendations from billing + utilization
- CloudWatch CPU, network, disk; memory needs the CloudWatch agent
- Trusted Advisor Flags idle/underutilized EC2 (full checks need Business support)
- Signal Right-sizing action
- CPU steadily under 20% Drop one instance size
- Memory under 30% on R-series Move to compute-optimized C-series
- T-series CPU credits piling up Instance is oversized for its bursty load
Trap: CloudWatch does not report memory by default. If a question says "right-size based on memory," the answer involves installing the CloudWatch agent first.
Pricing Model Comparison
- Model Max discount Commitment Best for
- On-Demand 0% None Spiky, short-lived, unpredictable
- Reserved Instance Up to 72% 1 or 3 yr 24/7 steady workloads (databases)
- Savings Plan Up to 72% 1 or 3 yr ($/hr) Mixed EC2/Lambda/Fargate fleets
- Spot Up to 90% None Fault-tolerant batch, CI/CD, analytics
- Dedicated Host Varies On-Demand/Reserved BYOL socket-based licensing
- Reserved Instances vs. Savings Plans
Standard RI — highest discount, locked to instance family/Region; can change AZ and size within the family.
Convertible RI — slightly lower discount, exchangeable for a different family, OS, or tenancy.
Compute Savings Plan — most flexible: covers EC2 and Lambda and Fargate across any family, size, OS, and Region.
EC2 Instance Savings Plan — higher discount than Compute SP but locked to one family + Region.
On the Exam: "Most flexible compute savings" → Compute Savings Plan. "Steady database, highest discount, won't change instance" → 3-year Standard RI, All Upfront.
Worked Example: Choosing a Commitment
Suppose a fleet runs a constant baseline of about 20 m6i instances plus daytime bursts. The cheapest layered design is: cover the always-on baseline with a Compute Savings Plan sized to that 20-instance floor, let Auto Scaling add On-Demand or Spot above the floor for daytime peaks, and never commit to the peak. Committing to the peak (a common wrong answer) pays full price for capacity that exists only a few hours a day. A second classic mistake is buying RIs before right-sizing — if Compute Optimizer later recommends a smaller family, a Standard RI is stranded while a Convertible RI or Compute Savings Plan would have adapted.
Spot and Serverless
Spot capacity is reclaimed when AWS needs it back, with a 2-minute interruption notice delivered through CloudWatch Events and instance metadata. Spot is correct only for fault-tolerant, stateless, or checkpointable work: batch processing, big-data analytics, CI/CD runners, rendering, and containerized jobs that can restart. It is the wrong answer for a primary database, a stateful session server, or anything that cannot tolerate sudden loss.
Reduce interruption impact with three techniques the exam expects:
Diversification — request many instance types across many Availability Zones so AWS can fulfill capacity from the deepest pools.
EC2 Fleet / Spot Fleet — declare a target capacity and mix On-Demand baseline with Spot burst in one request.
capacity-optimized allocation — let AWS place Spot in the pools least likely to be interrupted, rather than purely cheapest.
For sporadic event-driven work, Lambda bills per request plus per-millisecond GB-second of memory-time, so you pay zero while idle — unlike an always-on EC2 box that bills 24/7 even at 1% CPU. Fargate removes server management for containers, and Fargate Spot brings up-to-70%-style discounts to interruption-tolerant tasks. A useful rule: as request volume climbs and becomes steady, the cost lines cross and committed EC2 (with RIs or a Savings Plan) eventually beats per-invocation Lambda — so very high, predictable throughput is a signal to move back toward reserved EC2 or containers, not to scale Lambda indefinitely.
Common Compute-Cost Traps
- Tempting wrong answer Why it fails
- Spot for a production database 2-minute reclamation breaks durability/availability
- Standard RI before right-sizing Locks in oversized instances; cannot exchange
- Committing to peak capacity Pays full price for capacity used a few hours/day
- Lambda for steady high-volume compute Per-invocation cost eventually exceeds reserved EC2
- Larger instance to fix bursty T-series CPU Burst credits accruing means it is already oversized