Design Cost-Optimized Compute Solutions for SAA-C03

Cover right sizing, Spot, Reserved Instances, Savings Plans, Lambda, Fargate, and scaling trade-offs for SAA-C03 compute-cost scenarios.

Compute-cost questions on SAA-C03 are about avoiding over-provisioning without breaking the workload. AWS wants you to choose the right combination of purchasing model, runtime model, instance family, and elasticity based on how predictable and interruption-tolerant the workload actually is.

What AWS is explicitly testing

The current exam guide points to cost-management tools, AWS purchasing options, distributed and hybrid compute strategies, instance families and sizes, compute-utilization optimization, and scaling strategies such as Auto Scaling and hibernation.

Cost-aware compute chooser

Requirement Strongest first fit Why
Steady long-running usage Savings Plans or Reserved-style commitment model Reduces cost for predictable usage
Interruption-tolerant batch or flexible workloads Spot Instances Lowest-cost compute when interruption is acceptable
Bursty event-driven execution Lambda Pay-per-use can beat always-on servers
Container runtime without idle EC2 fleet management Fargate Can lower operational overhead and overprovisioning risk

Purchasing model chooser

Pattern Usually strongest fit What SAA-C03 is really testing
Predictable baseline production load Savings Plans or committed usage strategy Whether you notice stable usage is being paid for inefficiently
Elastic batch or background work Spot Whether interruption tolerance is part of the architecture
Spiky short-lived event processing Lambda Whether idle capacity should disappear entirely
Mixed production fleet with steady base and burst capacity On-Demand base plus Spot or scaling policy Whether one pricing model alone is too simplistic

The cost question behind the instance choice

Ask three things:

  1. Is the workload steady or bursty?
  2. Can it survive interruption or restart?
  3. Is the team paying mostly for compute itself, or for idle headroom and management overhead?

That usually gets you to Spot, Savings Plans, Lambda, Fargate, or standard EC2 sizing more cleanly than memorizing product marketing.

Example: mix On-Demand baseline with Spot burst capacity

 1Resources:
 2  WebAsg:
 3    Type: AWS::AutoScaling::AutoScalingGroup
 4    Properties:
 5      MinSize: '2'
 6      MaxSize: '10'
 7      DesiredCapacity: '2'
 8      VPCZoneIdentifier:
 9        - subnet-a
10        - subnet-b
11      MixedInstancesPolicy:
12        LaunchTemplate:
13          LaunchTemplateSpecification:
14            LaunchTemplateId: lt-1234567890abcdef0
15            Version: '1'
16          Overrides:
17            - InstanceType: m7g.large
18            - InstanceType: m6i.large
19        InstancesDistribution:
20          OnDemandBaseCapacity: 2
21          OnDemandPercentageAboveBaseCapacity: 20
22          SpotAllocationStrategy: price-capacity-optimized

What to notice:

  • the architecture protects a small steady baseline with On-Demand capacity
  • burst scale can shift toward Spot instead of paying full On-Demand cost everywhere
  • SAA-C03 often prefers cost reduction that respects workload tolerance instead of blindly minimizing price

Failure patterns worth recognizing

Symptom Strongest first check Why
Cost is high even when CPU stays low for long periods Right sizing and scaling policy Idle headroom may be the real issue
A production system cannot tolerate interruption Spot suitability The cheapest compute is still wrong if the workload cannot survive interruption
Bursty traffic keeps paying for always-on servers Runtime model fit Lambda or Fargate may be cheaper than oversized EC2
Discounts exist but are not being captured Usage predictability Stable baseline usage often points to commitment options

Common traps

  • using On-Demand for predictably steady workloads forever
  • choosing Spot for workloads that cannot tolerate interruption
  • choosing EC2 because it feels flexible even when Lambda or Fargate fits the pattern better
  • right-sizing the instance but ignoring the scaling policy that keeps it oversized most of the time

Quiz

Loading quiz…

Continue with 4.3 Database Solutions to apply the same cost lens to database engine, type, capacity, and retention choices.