Cost-Optimized Architecture Design practice questions

EC2 Instance Savings Plans commit to one instance family in one Region and are flexible across size, OS and tenancy inside it, for a deeper discount than Compute Savings Plans.

The fleet is fixed to m7i in eu-west-1 but varies by size and operating system. An EC2 Instance Savings Plan covers exactly that flexibility and gives a larger discount than a Compute Savings Plan, whose extra flexibility (other families, Regions, Fargate, Lambda) the company does not need. Zonal Reserved Instances do not follow size changes, and Convertible Reserved Instances require exchanges.

1. Identify what stays fixed (family and Region) and what changes (size, OS).
2. Match the commitment whose flexibility covers only the changing dimensions.
3. Prefer the deeper discount when the extra flexibility is not needed.

Exam tip: Fixed family and Region with changing sizes or OS: an EC2 Instance Savings Plan gives the deepest Savings Plan discount.

Savings Plans are scoped by service: Compute (EC2, Fargate, Lambda), EC2 Instance (one EC2 family in a Region), SageMaker AI (SageMaker AI instances) and Database.

Two different commitment products are needed. The EC2 baseline across several families is best matched by a Compute Savings Plan. The SageMaker AI endpoints are SageMaker AI instance usage, which only a SageMaker AI Savings Plan discounts, and that plan stays flexible across ml instance families, sizes, Regions and components. Sizing either plan to the combined $65 commits money the other service's usage cannot consume, because Savings Plans commitments are per hour and unused commitment is lost.

1. Split the spend by billing service: EC2 and SageMaker AI.
2. Recall which Savings Plan type covers each service.
3. Size each plan to its own steady hourly baseline.

Exam tip: Compute Savings Plans do not cover SageMaker AI; buy a SageMaker AI Savings Plan for ml instance usage and size each plan to its own baseline.

Match each slice of usage to its purchase option: commitment for the always-on floor, On-Demand for uninterruptible variable peaks, Spot for interruptible work.

A Savings Plan pays off only for usage present every hour of its term, so it should cover the 120-instance floor. The 10-hour weekday peak would leave extra commitment idle most of the week, so On-Demand is cheaper for it, and Spot is ruled out because web requests must not be interrupted. The nightly job checkpoints to S3 and restarts, so Spot is its cheapest option. A Spot maximum price controls what you pay, not whether capacity is reclaimed.

1. Separate the steady floor, the variable peak and the interruptible job.
2. Commit only to the floor that is present every hour.
3. Use On-Demand where interruptions are not allowed and Spot where they are.

Exam tip: Commit to the floor, pay On-Demand for uninterruptible peaks, and put interruption-tolerant work on Spot.

Savings Plans commitments are hourly and use-it-or-lose-it, and their terms cannot be modified, exchanged or resold after the short return window.

The plan was sized to an average, so it is under-used in low-usage hours. Its commitment cannot be lowered, exchanged or sold, and the 5-month-old plan is well outside the short window in which a recent purchase can be returned. Because the discount applies automatically to eligible usage in each hour, the lever left is to move time-flexible usage into the hours where commitment is idle. The tempting twist is Spot: it is cheaper than On-Demand on its own, but Savings Plans never apply to Spot usage, so running the moved job on Spot leaves the night commitment idle and adds a Spot bill on top. Kept On-Demand, the job is absorbed by commitment the company pays for anyway. Future purchases should be sized to the steady hourly floor, not the average.

1. Note that commitment is measured per hour and unused hours are lost.
2. Rule out changing, exchanging or reselling the plan.
3. Move flexible usage into the under-used hours.
4. Keep that usage on a pricing model the Savings Plan actually covers (not Spot).

Exam tip: Size Savings Plans to the hourly floor; if a plan is over-sized, shift flexible work into the hours where commitment is idle.

EC2 Capacity Blocks for ML reserve GPU instances for a defined future window, paid for that window only.

The requirements are guaranteed GPU capacity at a known future time, for a short duration, without a lasting commitment. Capacity Blocks for ML exactly fit: you book the instance count, start date and duration in advance. On-Demand Capacity Reservations also guarantee capacity but bill from creation whether used or not. Spot breaks the no-interruption requirement, and a Savings Plan discounts usage without reserving any capacity.

1. Identify the need: guaranteed GPU capacity, future start, fixed short duration.
2. Rule out options that discount without reserving (Savings Plans) or that can be interrupted (Spot).
3. Choose the reservation that bills only for the booked window.

Exam tip: Short, scheduled GPU runs that must start on time: book an EC2 Capacity Block for ML.

Spot availability comes from many capacity pools (instance type x Availability Zone); flexibility across pools plus price-capacity-optimized allocation reduces interruptions.

A single instance type in a single Availability Zone is one Spot capacity pool, and lowest-price allocation chases the cheapest pools regardless of how deep they are. Adding instance types and Availability Zones multiplies the pools available, and price-capacity-optimized steers launches to pools that are both deep and cheap. A higher maximum price does not stop capacity reclaims, and moving to On-Demand gives up the Spot discount.

1. Recognise that interruptions come from shallow capacity pools.
2. Increase the number of pools by diversifying types and Availability Zones.
3. Use price-capacity-optimized so launches favour pools with spare capacity.

Exam tip: For Spot, be flexible across many instance types and AZs and use price-capacity-optimized allocation.