Design Cost-Optimized Architectures
Most cost questions are really asking which lever fits the workload
AWS billing has four main levers, and the exam is testing whether you can pick the right one from the workload's shape, not whether you can recite discount percentages. There's capacity commitment (Reserved Instances, Savings Plans, Reserved Nodes) for steady usage that runs continuously; interruption tolerance (Spot) for fault-tolerant batch that can restart; access-frequency tiering (the S3, EFS, and FSx storage classes) for data that cools off over time; and right-sizing plus waste removal (Compute Optimizer, caching, VPC endpoints) for everything else. The mental model: read the workload's predictability, its tolerance for interruption, and how its access or traffic pattern changes; those three signals point straight at the lever.
The domain unfolds across four resource types, same levers each time
The subtopics walk the levers across the four big spend categories in turn. Compute comes first and is where all three discount levers appear together: commitment for the steady baseline, Spot for interruptible work, and Compute Optimizer to right-size what's left. Storage is the tiering lever in pure form: match the storage class to how often data is read, automate it with lifecycle rules, and watch the minimum-size and minimum-duration traps that make a 'cheaper' tier cost more. Database reuses the commitment-vs-variable split (RDS RIs versus Aurora Serverless and DynamoDB on-demand) and adds caching to shrink the tier you need. Network is the lever students forget: egress dominates the bill, so the move is to keep data from travelling (backbone routing and VPC endpoints, edge caching with CloudFront, and AZ affinity to avoid paying twice for cross-AZ hops).
Remove waste first, satisfy hard constraints always, then commit
Two instincts guide every answer in this domain. First, the cheapest resource is the one you switch off: right-size over-provisioned instances and volumes, delete idle resources, schedule non-production to shut down, and only then layer commitment discounts on the steady-state baseline that's left. Commit before you clean up and you lock in your waste for one to three years. Second, cost is only the goal when nothing outranks it: if the scenario carries a hard requirement (availability, latency, durability, compliance), the correct answer satisfies that first and optimizes within it. The cheapest option that violates a stated constraint is always the distractor.
The four cost levers, and where each shows up across the domain
| Lever | What it does | When it fits | Where it shows up |
|---|---|---|---|
| Capacity commitment | Trade a 1- or 3-year commitment for a deep discount on steady-state usage | Predictable baseline that runs continuously | Compute (RIs, Savings Plans), Database (RDS RIs, Reserved Nodes) |
| Interruption tolerance | Run on AWS spare capacity for the steepest discount, accepting reclaim notices | Stateless, fault-tolerant, restartable batch | Compute (EC2 / Fargate Spot) |
| Access-frequency tiering | Move data to colder, cheaper tiers as it stops being accessed | Data whose access drops off over time | Storage (S3 classes, lifecycle, Intelligent-Tiering) |
| Right-sizing & waste removal | Match capacity to real usage, and don't move data you don't have to | Any resource with usage history; any chatty traffic path | Compute (Compute Optimizer), Database (caching, serverless), Network (endpoints, edge caching, AZ affinity) |