Interruptible capacity reservations only pay off if you know your workloads

AWS's reservation options have been multiplying for years: On-Demand Capacity Reservations, Savings Plans, Reserved Instances, Capacity Blocks for ML, and now interruptible Capacity Reservations. Each one exists to solve a real problem, but the cumulative effect is a stack of overlapping capacity and pricing commitments that's genuinely hard to reason about, let alone optimize across, without building custom tooling just to keep track of what you've committed to and where.

The latest change doesn't reduce that list. It makes it easier to use all of it at once.

What actually changed

Capacity Reservation Resource Groups used to hold only standard On-Demand Capacity Reservations. Now they can also hold Capacity Blocks for ML and interruptible Capacity Reservations, and — this is the part that matters — EC2 Fleet and Auto Scaling groups can prioritize across all of them and fall back to On-Demand automatically when the reserved capacity in the group runs out.

Mechanically, that's a real improvement. Instead of writing your own logic to say "try the reclaimable or time-boxed capacity first, fall back to the guaranteed reservation, and land on unplanned On-Demand only as a last resort," you can now express that as a priority order and let AWS handle it. There's no additional charge for using the resource group itself; you still pay whatever each underlying reservation type costs.

I don't think this is a transformative feature. It's one more tool in the box, and it has a narrower use case than the announcement makes it sound. But for the workloads it fits, it can genuinely save money.

Who this is actually for

Capacity Blocks are GPU/ML-training capacity, so that piece is obviously for teams doing large training runs on a schedule. The interruptible reservation piece is the more interesting one, and it's not for everything — it's for workloads that can tolerate being stopped and restarted without drama.

The use case I keep coming back to is migration. If you're moving off on-prem and you've got workloads that can't be modernized on the current timeline — legacy batch jobs, things that run on a schedule, anything that was never built to survive an interruption gracefully but also doesn't strictly need to run continuously — that's exactly where interruptible capacity fits. You're not getting a cheaper per-hour rate; interruptible reservations bill at On-Demand rates like everything else. What you get is capacity you can draw on at no additional charge and only pay for when you actually run something, in exchange for accepting that the owner can reclaim it on two minutes' notice. If you'd otherwise be holding standard reservations that sit half-idle, moving that workload onto capacity you only pay for on use is a real saving. If it genuinely doesn't care about being paused, it's close to free.

If your workload needs to be up all the time, or a stop/restart cycle causes real damage — state loss, SLA breaches, whatever — this isn't for you, and no amount of automatic fallback logic changes that.

The fallback is not automatically good news

The automatic fallback to On-Demand when reserved capacity runs out is the feature AWS is clearly proudest of here, and it cuts both ways. For a team that understands its own workloads and has instrumented for this, it's exactly the safety net you want: reserved or reclaimable capacity when it's available, plain On-Demand when it isn't, no manual intervention required.

What the fallback costs you depends on what's in the group. If you're leaning on Capacity Blocks for ML, dropping to On-Demand is a real rate increase — you go from a pre-purchased block price for scarce accelerated capacity to paying full On-Demand for it, assuming there's On-Demand capacity to be had at all. If you're leaning on interruptible or standard reservations, the rate doesn't move on fallback; On-Demand is On-Demand either way. What moves is volume. You set this up so the workload runs when the cheap-to-you capacity is there and pauses when it isn't. Instead it keeps running, at full price, straight through the gap — and because nothing breaks, nothing tells you. If your monitoring doesn't specifically watch for reclaim and fallback events, the first sign isn't an outage — it's a bill that's quietly larger than you planned for.

That's not a flaw in the feature so much as a property of it. Capacity that can be taken away, with a safety net under it, will always behave this way. The question is just whether you built the visibility to know when you've fallen through the net.

What "understanding your workload" actually means here

This isn't a vague caveat — it's a specific, answerable question for each workload you're considering: what fraction of the time does this actually need to be running, and does it survive being stopped and started without consequence? If a workload needs to be available 80% of the time and can tolerate being paused and resumed the other 20%, that's a workload where an interruptible reservation is doing real work for you. If you can't answer that question with confidence, you're not ready to put that workload on interruptible capacity yet — you're ready to go find out.

Start narrow and measure

Identify the services in your architecture where you can state the interruption tolerance with confidence — not the ones where it sounds plausible. Put one of them on interruptible capacity, at low risk, and confirm the savings actually show up before you touch anything else. The operational work of monitoring fallback events and rolling this out further only earns its place once that first result is on the board.

The tool is fine, and for the right workload the economics genuinely work out. But nothing here does the workload-classification work for you, and skipping that step is exactly how a savings feature turns into a surprise line item.