Skip to content
Calcrivo

Cloud Resource Utilization Calculator

Blend CPU, memory and storage utilisation into one figure, then size the fleet the observed peak actually needs.

Inputs

vCPU
%
%

Size on the percentile, never on the average.

%
TB
TB
USD/month
%

Leaves headroom for spikes and for losing an instance.

Blended Utilisation

25.8%

CPU Utilisation

18.0%

Memory Utilisation

32.0%

Storage Utilisation

32.5%

vCPUs the Peak Needs

453vCPU

Reclaimable Monthly Spend

$16,070.31

Utilisation Grade

F — Critical

Headroom Check

The peak leaves room to shrink toward the target

Step by step

  1. Values used

    vCPUs provisioned = 640 vCPU; Average CPU utilisation = 18 %; 95th-percentile CPU utilisation = 46 %; Average memory utilisation = 32 %; Storage provisioned = 80 TB; Storage actually used = 26 TB; Monthly spend on this fleet = 55,000 USD/month; Target peak utilisation = 65 %

  2. Cloud Resource Utilization

    blended utilisation = CPU × 0.45 + memory × 0.35 + storage × 0.20; required vCPU = provisioned vCPU × peak CPU ÷ target utilisation; reclaimable spend = spend × reclaimed vCPU ÷ provisioned vCPU.

  3. Blended Utilisation

    = 25.8

  4. CPU Utilisation

    = 18.0

  5. Memory Utilisation

    = 32.0

  6. Storage Utilisation

    = 32.5

  7. vCPUs the Peak Needs

    = 453 vCPU

  8. Reclaimable Monthly Spend

    = 16,070.31

How it works

Utilisation is blended with CPU carrying the most weight because compute pricing follows vCPU, while storage is included at a lower weight since it is cheap but frequently over-provisioned. Right-sizing converts the observed peak into an absolute demand and divides by the utilisation you are prepared to run at, so the answer keeps deliberate headroom rather than fitting the peak exactly. Average utilisation below 20% is normal and is the single largest pool of recoverable cloud spend, but resizing on averages instead of percentiles causes outages. Cost does not always scale linearly with vCPU across instance families, so verify the projected saving against your provider's pricing before acting.

Formula

Cloud Resource Utilization

blended utilisation = CPU × 0.45 + memory × 0.35 + storage × 0.20; required vCPU = provisioned vCPU × peak CPU ÷ target utilisation; reclaimable spend = spend × reclaimed vCPU ÷ provisioned vCPU.

peak CPU
95th-percentile utilisation from your monitoring, not the mean
target utilisation
The peak you are willing to run at, which sets your headroom
blended utilisation
CPU-weighted composite, because CPU is what compute pricing tracks

Frequently Asked Questions

How is Cloud Resource Utilization calculated?

blended utilisation = CPU × 0.45 + memory × 0.35 + storage × 0.20; required vCPU = provisioned vCPU × peak CPU ÷ target utilisation; reclaimable spend = spend × reclaimed vCPU ÷ provisioned vCPU. Utilisation is blended with CPU carrying the most weight because compute pricing follows vCPU, while storage is included at a lower weight since it is cheap but frequently over-provisioned. Right-sizing converts the observed peak into an absolute demand and divides by the utilisation you are prepared to run at, so the answer keeps deliberate headroom rather than fitting the peak exactly.

Why does Cloud Resource Utilization matter?

Average utilisation below 20% is normal and is the single largest pool of recoverable cloud spend, but resizing on averages instead of percentiles causes outages. Cost does not always scale linearly with vCPU across instance families, so verify the projected saving against your provider's pricing before acting.

What values do I need to enter?

This calculator takes 8 inputs: vCPUs provisioned, Average CPU utilisation, 95th-percentile CPU utilisation, Average memory utilisation, Storage provisioned, Storage actually used, Monthly spend on this fleet, Target peak utilisation. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

Why not size to 100% of the observed peak?

The peak you measured is not the peak you will see. Sizing to a target such as 65% leaves room for growth, for traffic spikes and for the load that shifts onto the survivors when one instance fails — which is exactly when you least want to be at capacity.

You might also need