A database runs on a 32-vCPU instance at 22% average CPU. The rightsizing report recommends 16 vCPU for a 50% compute saving. The engine is licensed per core with a 4-core minimum per instance and the contract has three years left. What happens if you take the recommendation?

What happens, in order

The infrastructure line falls by about half and the licence line does not move at all. Perpetual and term licences are bought in core packs for a quantity, not metered by use: the entitlement for 32 cores is already paid for the next three years. Dropping to 16 cores leaves 16 cores of unused entitlement, which is stranded capacity - money already committed against capacity now idle.

Then the second-order effects arrive:

• Support is usually priced as a percentage of licence value, typically in the high teens to low twenties per cent a year, and it follows the entitlement rather than the deployment. The annual support invoice does not change either.
• Headroom disappears. At 22% of 32 vCPU the service uses about 7 vCPU; on 16 it uses 44% and the peak may exceed what one core-pack boundary allows, so the next growth step is a licence purchase rather than an instance resize.
• The minimum bites on consolidation. With a 4-core minimum per instance, splitting one 32-core database into eight small ones licenses 32 cores whatever their size. Licence minimums penalise exactly the microservice-shaped decomposition teams want to make.

So the saving is real but is roughly the compute half of a bill whose licence half often dominates it. On enterprise engines the licence plus support can exceed the infrastructure cost several times over, which inverts the usual rightsizing intuition.

What to do with the finding instead

• Compute the whole number before acting: infrastructure, licence, support, and any discount tier the change would drop you out of.
• Use the freed entitlement rather than discarding it. Consolidate another workload onto the same instance, stand up the licensed cores as a reporting replica, or move the entitlement to a newer core type where the vendor's factor table is favourable.
• Time the change to the renewal. The only moment a licence quantity is genuinely negotiable is renewal, so take the measurement now, bank it as evidence, and make the resize part of the renewal conversation.
• Check the vendor's virtualisation rules before any move. Licensing on shared infrastructure sometimes counts the host rather than the guest, which can make a smaller instance more expensive.

The general rule

Rightsize what is metered; renegotiate what is committed. Compute, storage and transfer are metered and respond to engineering, because the meter stops when the resource stops. Licences, reserved capacity and support contracts are committed and respond only to procurement, on its own calendar. A FinOps programme that treats both as one pipeline produces reports that are arithmetically correct and change nothing.

The failure this produces is specific and common: a team books a saving that never appears on the bill, the next forecast is built on the booked figure, and the variance is discovered at quarter end by finance rather than by engineering. Vendor audits are the sharper version - an estate that moved workloads between hosts without tracking entitlement can find itself paying for cores it stopped using and cores it never licensed in the same review.

When not to wait for renewal

Choose to act now, not at renewal, if the licence is subscription-priced per core per month, where the entitlement really does follow the deployment, or if the engine is open source and the only commitment is a support contract with a tier wide enough to absorb the change. Act now too if the instance is one of hundreds: at fleet scale the compute half alone is worth the work, and the stranded entitlement can be redeployed somewhere in the estate. It flips back the moment the saving depends on a quantity you cannot return - a perpetual core pack bought in 2024 for three years is sunk, and an engineering change cannot unspend it.