When fixed instance sizes waste money

Almost every cloud provider sells compute in fixed shapes. A general-purpose instance gives you four gigabytes of memory per vCPU, a compute-optimised one gives you two, a memory-optimised one gives you eight. You choose the closest fit and move on.

The problem is that “closest fit” often means paying for a substantial amount of something you do not need, because your workload’s actual ratio sits between the offered shapes.

Where the waste comes from

Consider a workload that genuinely needs two vCPUs and twenty gigabytes of memory. That is a ratio of one to ten, which is more memory-heavy than a standard memory-optimised shape.

On a fixed-size catalogue you have two options. Take a memory-optimised instance with enough memory, and accept the extra vCPUs that come with it. Or take a smaller instance and add swap, which will perform badly.

Either way you pay for capacity you do not use. The overshoot is frequently thirty to fifty percent for workloads whose ratio sits awkwardly between the standard shapes.

The same happens in the other direction. A single-threaded application that needs a lot of CPU and very little memory pays for memory it never touches.

Which workloads sit awkwardly

Some shapes are unusually common among the awkward cases.

In-memory caches want a great deal of memory and almost no CPU. A cache is mostly moving bytes; the ratio can be one vCPU to sixteen or more gigabytes.

Single-threaded legacy applications want fast cores rather than many, and modest memory. Buying more vCPUs does nothing at all for a workload that cannot use them.

Build and compile machines want many cores, lots of I/O, and a moderate amount of memory. They also want it only while a build is running.

Small databases with large working sets want memory well out of proportion to their CPU use.

Development environments want enough of everything to be comfortable and are rarely busy, which makes any standard shape an overpayment.

What granular sizing changes

Providers that let you specify CPU and memory independently, Kamatera among them, remove the rounding entirely. You ask for two cores and twenty gigabytes and you pay for two cores and twenty gigabytes.

For the awkward shapes above the difference is real. For workloads that happen to match a standard ratio it is negligible, which is worth saying plainly: this is not a universal saving, it is a saving for a specific and reasonably common class of workload.

Granular sizing also changes how you scale. Rather than jumping to the next instance size and doubling everything, you can add memory alone when memory is the constraint. That turns a doubling into an increment.

How to find your actual ratio

You cannot size accurately from a guess. The procedure is short.

1. Run the workload on something comfortably oversized for a representative period, ideally including a peak.
2. Record peak CPU utilisation and peak memory utilisation separately, as absolute figures rather than percentages of the oversized machine.
3. Add headroom to each independently. Memory wants more headroom than CPU, because exhausting memory is catastrophic while exhausting CPU is merely slow. Twenty five percent on memory and fifteen on CPU is a reasonable starting point.
4. Express the result as a ratio and compare it against the standard shapes available to you.

If the ratio lands close to a standard shape, use the standard shape; the operational familiarity is worth more than a few percent. If it lands well away from one, granular sizing is genuinely worth pursuing.

The other half of the saving

Right-sizing the shape is one lever. Not running the machine at all is the other, and it is usually larger.

Development environments, build machines and batch processing often need to exist for a fraction of the week. A machine that runs eight hours on weekdays costs roughly a quarter of one that runs continuously, and no amount of shape optimisation competes with that.

Combine the two: size to the real ratio, and run only when needed. For non-production workloads together they routinely halve the bill.

A caution about over-optimising

There is a point at which sizing precision stops paying for itself. Squeezing the last ten percent out of a small instance is an afternoon of work to save a trivial sum, and it removes the headroom that absorbs an unexpected spike.

Spend the effort where the numbers are large: the machines that run continuously, the ones that are clearly oversized, and the fleets where a per-machine saving multiplies. Leave the small stuff comfortable.

For the vendor’s own reference on the services involved here, see the Kamatera support library.

Questions people ask