Design Cost-Optimized Architectures
Cost-Optimized Compute and Purchasing
CoreChoose purchase model, size/family, scaling, availability, and compute platform from utilization and interruption tolerance.
Aligned to the current SAA-C03 exam guide, verified August 16, 2026.
Why this matters
Compute savings are valid only after runtime, performance, availability, and interruption constraints are met. The architect should remove idle capacity, select the right execution model and resource shape, then apply commitments or spare-capacity discounts to the eligible baseline.
Must Know
- On-Demand capacity avoids long commitments and fits new, short-term, spiky, or uncertain instance workloads.
- Spot uses spare EC2 capacity at deep discount but can be interrupted; design checkpoints, queues, diversification, and fallback only for interruption-tolerant work.
- Reserved Instances provide term-based discounts and, for eligible zonal choices, capacity reservation characteristics; Savings Plans provide commitment-based savings with broader compute flexibility depending on plan type.
- Savings Plans are a spend commitment, not an instance reservation or capacity guarantee.
- Rightsize from observed CPU, memory, storage, network, and accelerator demand. Compute Optimizer recommends rightsizing from supported utilization data, but architects validate business context.
- Auto Scaling removes sustained overprovisioning for variable demand; scheduled/predictive/target-based approaches fit different demand evidence. Hibernation can preserve supported instance memory state but is not general autoscaling.
- Lambda can be economical for event-driven intermittent execution; Fargate for container workloads without host management; EC2 for sustained or control-heavy workloads. Compare total utilization and operations.
- Production and non-production may justify different availability and schedules. Never reduce required failure isolation solely to lower cost.
- ALB, NLB, and Gateway Load Balancer must first meet Layer 7, Layer 4, or appliance requirements; then optimize target/capacity architecture.
Compare and Distinguish
- On-Demand vs Spot: flexibility without interruption versus spare capacity with interruption. Spot loses immediately when work cannot retry or checkpoint.
- Reserved Instances vs Savings Plans: RI characteristics can fit stable EC2 configuration/capacity needs; Savings Plans win when commitment flexibility across eligible compute is more valuable.
- Commitment vs Auto Scaling: commitments discount a baseline; scaling changes consumption. Commit only after understanding the stable floor.
- EC2 vs Lambda vs Fargate: host/runtime control and sustained capacity, event functions, or managed container capacity. Total cost includes idle time and administration.
- Horizontal vs vertical scaling: horizontal elasticity and resilience versus a larger single resource with a ceiling.
- ALB vs NLB vs Gateway Load Balancer: Layer 7 routing, Layer 4/static-IP/transport behavior, or appliance insertion.
Scenario examples
- Scenario: A new service has unknown demand. Think: start flexible and measure before committing.
- Scenario: A rendering queue can retry jobs and checkpoint output. Think: Spot capacity can reduce cost because interruption is explicitly tolerated.
- Scenario: A stable compute baseline runs continuously but instance families may change. Think: evaluate the Savings Plan type whose flexibility matches that change.
- Scenario: Development instances are idle nights and weekends. Think: schedules or stop/start patterns can remove idle cost without weakening production.
- Scenario: A brief event handler runs only when events arrive. Think: Lambda may beat always-on instances if runtime and downstream constraints fit.
Exam traps
- Spot is not appropriate merely because it is cheap.
- Savings Plans do not reserve capacity.
- Reserved pricing does not automatically mean a stopped instance has no commitment cost.
- Auto Scaling does not guarantee lower cost if policies hold excess capacity or chase a bad metric.
- Serverless is not universally cheaper for sustained compatible workloads.
- A non-production cost decision must not silently weaken a stated availability requirement.
Key takeaways
- Satisfy runtime, performance, interruption, and availability before applying discounts.
- Rightsize and eliminate idle use before buying commitments.
- Use Spot only for resilient, interruptible work.
- Commit against a measured steady baseline and retain flexibility for the variable portion.
- Choose compute model from total cost and operational burden, not headline rate.
How it works
- EC2 billing and discounts apply according to capacity and purchase model; Auto Scaling changes the number of resources requested.
- Lambda meters function use and Fargate meters requested task capacity according to their service models.
- Compute Optimizer analyzes supported utilization signals and suggests options that still require workload-owner validation.
- Load balancers distribute traffic but also affect availability, cross-zone paths, and target utilization.
When to use it
- Use On-Demand for uncertainty, Spot for interruption-tolerant work, and commitments for measured steady demand.
- Use Auto Scaling for variable fleet capacity and schedules for predictable idle periods.
- Use Lambda for compatible event functions, Fargate for managed containers, and EC2 for host control or sustained fleets.
- Use Outposts/Snow edge compute only for hard hybrid or disconnected locality requirements.
Security and governance implications
- Do not sacrifice production redundancy, patching, or isolation for utilization.
- Use roles and immutable images/templates for elastic capacity.
- Protect Spot interruption handling and queues from duplicate side effects.
- Use cost allocation across accounts/tags without exposing financial data broadly.
Operational and diagnostic signals
- For low utilization, distinguish required failover headroom, idle waste, and wrong resource family.
- For Spot failures, verify checkpoint/retry, diversified capacity, queue visibility, and fallback design.
- For unexpected commitment waste, compare purchased scope with actual eligible use.
- For serverless cost spikes, inspect invocation rate, duration, memory, retries, and downstream inefficiency.
More detail
- Cost decisions should consider utilization distribution, not only averages; peaks, memory pressure, and latency objectives can justify headroom.
- Instance family choice follows the dominant bottleneck, while size follows required amount of that resource.
- Managed/serverless options exchange some unit economics for reduced administration and fine-grained scaling.
- Hybrid compute such as Outposts or Snow edge capabilities is chosen for locality/disconnected constraints, not as a generic discount.
Ready for the quiz?
- What makes Spot safe?
- How do Savings Plans differ from capacity reservation?
- Why rightsize before committing?
- When might Lambda or Fargate beat EC2?
- How do scaling and purchasing models complement each other?
Related objectives
- D4.2.K1
- D4.2.K2
- D4.2.K3
- D4.2.K4
- D4.2.K5
- D4.2.K6
- D4.2.K7
- D4.2.K8
- D4.2.K9
- D4.2.S1
- D4.2.S2
- D4.2.S3
- D4.2.S4
- D4.2.S5
- D4.2.S6