Stranded Capacity

A rightsizing report recommends halving a 32-vCPU database instance running at 22% CPU. The team takes it, the compute line falls, and the licence line does not move at all. The engine is licensed per core for a quantity that was bought for three years, so 16 cores of entitlement now sit unused. The saving is real on one line and zero on the other.

That is stranded capacity: a commitment whose quantity cannot be returned, attached to capacity the workload no longer needs. It is the reason FinOps programmes report savings that finance cannot find.

Why it matters

It separates the two halves of a cloud bill that behave in completely different ways. Metered resources respond to engineering; committed resources respond only to procurement, on its own calendar. Treating both as one pipeline produces reports that are arithmetically correct and change nothing, which is how a FinOps function loses credibility in its first year.

The magnitude is often surprising. On enterprise database engines, licence plus support - commonly high-teens to low-twenties per cent of licence value annually - can exceed the infrastructure cost several times over. A 50% compute saving on a workload whose licence dominates its cost is a single-digit percentage saving overall.

Implementation patterns

• Tag every resource with its commitment, so a rightsizing candidate list can be filtered to the metered ones.
• Pipeline the findings by commitment type: metered findings go to engineering this sprint, committed findings go to a renewal file with the evidence and the date.
• Redeploy rather than discard. Freed licensed cores can host another workload, become a reporting replica, or move to a newer core type where the vendor's factor table is favourable.
• Defragment, do not buy. For accelerator fleets, bin-pack by job width and drain nodes deliberately, because the scarce quantity is a contiguous block rather than a device count.
• Prefer shapes that can be given back when the future is uncertain: shorter commitment terms, convertible reservations, spend-based rather than instance-based commitments.
• Report coverage and utilisation of commitments separately. High coverage with low utilisation is precisely the stranded case, and one number hides it.

Industry example

The accelerator version is now the common one. Published capacity practice for GPU clusters since roughly 2023 distinguishes free devices from schedulable devices, because a gang-scheduled 8-GPU job cannot run on eight nodes with one free device each. A cluster can report 94% allocation and be unable to start a single large job, and the devices that cannot be scheduled are paid for in full. The same reasoning governs reserved instances after an architecture change: a commitment bought on last year's shape, before a move to containers or to serverless, keeps billing against a family nothing runs on.

Failure scenarios

• A booked saving that never appears, after which the next forecast is wrong and the variance is found by finance rather than engineering.
• Decomposition multiplied by a licence minimum. With a 4-core minimum per instance, eight small databases license 32 cores - the same as the one instance they replaced.
• Fragmentation presented as scarcity, so the organisation buys more capacity to work around a placement policy.
• A vendor audit in an estate that moved workloads between hosts without tracking entitlement, which can produce payment for cores no longer used and cores never licensed in the same review.
• Commitment coverage chased as a target, which buys more commitment to cover the stranded one.

Trade-offs

Commitments exist because they are cheap: discounts of 30–70% against on-demand are the reward for removing the provider's demand uncertainty. Avoiding stranding entirely means buying nothing, which is the most expensive option available. The real decision is how much optionality to buy back: shorter terms and convertible shapes cost a few percentage points of discount and are worth it exactly when the architecture is expected to change inside the term. The rule of thumb that survives contact: commit to the floor you are confident of, and meter the volatile layer on top.

When not to use it

For a small estate with no licences and no reservations, this concept has nothing to attach to - rightsize freely. It is also the wrong lens when the stranded quantity is genuinely trivial: an idle reservation worth a few hundred pounds a month does not justify a procurement project. And where a commitment's term is nearly over, waiting is usually better than restructuring, because the cheapest way to unstrand capacity is almost always to let it expire.

Interview question

Q: Your rightsizing programme reports £2M of annualised savings and finance says the bill is flat. Where do you look first, and how do you change the programme?

What a strong answer covers: separating metered from committed lines and recognising that licences, reservations and support follow entitlement rather than deployment; checking commitment utilisation alongside coverage; distinguishing a saving that was never realisable from one that was realised and consumed by growth; the governance change - findings routed by commitment type, with renewal dates as the action date; and the honest reporting fix, which is to book savings only when the invoice line moves.

Quick check

Quiz: Why can halving an instance's cores save nothing? Per-core licence and support entitlement is a committed quantity, so the compute line falls and the licence line does not.

Flashcard: What is the GPU form of stranded capacity? Fragmentation: free devices scattered across nodes cannot host a gang-scheduled job, so the useful metric is the largest contiguous block rather than the free count.