Reserved capacity portfolio management: running commitments like a book

Quick answer

Treat commitments as a portfolio, not a series of purchases. Set a coverage target (typically 70 to 85 percent of steady-state usage), maintain a maturity ladder so no more than 20 to 30 percent of the book expires in any quarter, track utilization above 97 percent as a hard constraint, and hold the remainder flexible for growth and architecture change. Review monthly with a standing agenda: expirations in the next 90 days, coverage drift, utilization exceptions, and workload changes that invalidate existing commitments.

The first reservation purchase is easy. So is the tenth. Somewhere past twenty or thirty commitments across multiple accounts, instance families, regions, and expiry dates, ad hoc buying breaks down. Coverage drifts, expirations cluster, and one architecture change strands capacity nobody is tracking. At that point the job changes from buying discounts to managing a portfolio.

Define the three portfolio metrics

Metric	Definition	Target
Coverage	Share of eligible usage covered by commitments	70 to 85%
Utilization	Share of purchased commitment actually consumed	Above 97%
Weighted maturity	Average remaining term across the book	12 to 20 months

Coverage and utilization pull against each other: buying more raises coverage and risks lowering utilization. Utilization is the hard constraint because unused commitment is pure loss, while uncovered usage merely pays on-demand rates. If utilization drops below about 97 percent, stop buying and investigate before adding anything. The distinction is explained incoverage versus utilization.

Why 100 percent coverage is the wrong goal

Full coverage looks maximally efficient and is usually a mistake. Real estates have seasonal traffic, migrations, instance family changes, and workloads that get refactored away. A portfolio covering every hour of current usage will strand capacity the moment any of that happens. The uncovered tail is deliberate optionality: it absorbs changes without penalty and it is where spot capacity and burst usage live.

Consider an estate with 1,000 steady compute units and 300 units of variable daily peak. Covering 850 units at a 32 percent discount saves roughly 272 unit-equivalents. Covering 1,300 saves more on paper but strands commitment every night when the peak recedes, and the effective discount collapses. Model coverage against the minimum sustained level, not the average and never the peak.

Build the maturity ladder

Clustered expirations are the portfolio's biggest operational risk. If 60 percent of the book expires in the same quarter, that quarter carries a sudden cost spike, a rushed repurchase decision, and no negotiating room. Ladder purchases so no more than 20 to 30 percent of committed value matures in any single quarter.

In practice this means buying in tranches rather than annually: quarterly purchases of one-year and three-year commitments layered on top of each other. Over two or three cycles the book self-levels, with something expiring every quarter and a steady repurchase rhythm. The approach is developed further incommitment laddering.

Run a monthly portfolio review

Put a 45-minute meeting on the calendar with a fixed agenda. Expirations in the next 90 days and the repurchase recommendation for each. Coverage by family and region against target, with any drift over 5 points explained. Utilization exceptions, any commitment below 97 percent, with the root cause. Upcoming workload changes from engineering that would invalidate existing commitments, such as a Graviton migration, a region move, or a service being decommissioned. Then the buy list for the month.

The fourth item is the one most portfolios skip and the one that causes the most damage. A team migrating from x86 to Arm instances can strand a year of commitment if nobody tells procurement. That conversation has to be a standing agenda item, not an accident.

Segment the book by confidence

Not all usage deserves the same commitment term. Split the estate into three tiers. Stable core workloads that have run unchanged for over a year and are not on any roadmap for change take three-year commitments. Steady but evolving workloads take one-year commitments or flexible instruments. Everything volatile, experimental, or roadmap-threatened stays on demand or spot.

A typical split is 45 percent three-year, 35 percent one-year, and 20 percent uncommitted. That structure captures most of the discount while keeping the average maturity short enough to absorb change.

Track the portfolio's realized rate

The single best health metric is effective discount rate: total amortized commitment cost divided by what the same usage would have cost at on-demand rates. A portfolio with 78 percent coverage, 98 percent utilization, and a mix of one and three-year terms should land somewhere around 22 to 28 percent effective savings. If the theoretical discount is 32 percent and realized is 19 percent, the gap is waste, and it is almost always unused commitment or coverage aimed at the wrong families.

Keep engineering in the loop

Portfolio decisions depend on knowing what engineering will deploy next. Cost estimates at the pull request stage give procurement early sight of new instance families, new regions, and workload retirements before they land. C3X prices Terraform changes before merge, so a shift in compute shape shows up as a reviewable diff rather than a stranded reservation discovered three months later. Pair that with theutilization management routine and the book stays healthy.

FAQ

What coverage target should a commitment portfolio have?

Typically 70 to 85 percent of eligible steady-state usage, measured against the minimum sustained level rather than the average or peak. The uncovered tail is deliberate: it absorbs seasonal variation, migrations, instance family changes, and workload retirements without stranding capacity, and it is where spot and burst usage live. Full coverage looks efficient on paper and strands commitment the moment anything changes.

Why is utilization a harder constraint than coverage?

Unused commitment is pure loss, while uncovered usage merely pays on-demand rates. That asymmetry means utilization should be treated as a floor: if it falls below roughly 97 percent, stop buying and find the cause before adding anything. Coverage can be improved later at modest cost; a stranded three-year commitment cannot be undone.

How do I avoid clustered commitment expirations?

Ladder purchases so no more than 20 to 30 percent of committed value matures in any single quarter. Buy in quarterly tranches with a mix of one-year and three-year terms layered over each other rather than making one large annual purchase. After two or three cycles the book self-levels and repurchase becomes a steady monthly rhythm instead of an annual scramble.

What should a monthly commitment review cover?

Five standing items: expirations in the next 90 days with a repurchase recommendation for each, coverage by family and region against target with drift over 5 points explained, utilization exceptions below 97 percent with root causes, upcoming engineering changes that would invalidate commitments such as an architecture or region migration, and the resulting buy list for the month.

How should I split commitments across terms?

Segment by confidence. Stable core workloads unchanged for over a year and absent from any change roadmap take three-year commitments. Steady but evolving workloads take one-year or flexible instruments. Volatile, experimental, or roadmap-threatened workloads stay on demand or spot. A common split is roughly 45 percent three-year, 35 percent one-year, and 20 percent uncommitted.

How do I measure whether the portfolio is healthy?

Effective discount rate: total amortized commitment cost divided by what the same usage would have cost at on-demand rates. A well-run book with high coverage and utilization typically realizes 22 to 28 percent. A large gap between theoretical and realized discount, for example 32 percent available versus 19 percent achieved, indicates unused commitment or coverage aimed at the wrong instance families.

What to do next

Stop stranding commitments on architecture changes nobody flagged. C3X shows compute shape changes in the pull request. See the quickstart.