Stop right-sizing spreadsheets

You did not over-provision because you are bad at capacity planning. You over-provisioned because the pricing punishes you for guessing wrong, and the only cheap mistake is guessing too big.

Think about the incentives. Guess too small and your service falls over at 2 a.m., your pager goes off, and the resize means a stop, a reboot, and a window of downtime you have to schedule. Guess too big and you pay a little more every hour, forever, and nobody notices. One mistake wakes you up. The other shows up as a rounding error in a bill nobody reads line by line. So everyone rounds up. The 30% headroom on every box is not laziness — it is the rational response to asymmetric pain.

The catalog maze

Then there is the catalog. You do not pick CPU and RAM. You pick a shape: some letter, some number, some generation suffix that encodes a memory-to-core ratio you have to reverse-engineer from a pricing table. You need 6 cores and 40 GB. There is no 6-and-40. There is an 8-core/32 box and an 8-core/64 box, so you take the 64 and eat the cores you do not need, or you take a memory-optimized family and eat the cores you do need at a markup.

The catalog exists to make a continuous problem — “how much compute do I want” — look like a menu. Menus are easier to price and harder to optimize. That is the point. Every shape you cannot get is a shape that pushes you up to the next one that costs more.

Hourly billing rewards the round-up

Hourly billing finishes the job. A box that runs for 70 minutes bills two hours. A batch job that takes 12 minutes bills an hour. So you stop spinning things up and tearing them down, because the granularity makes ephemeral work expensive. You leave the box running. You keep the headroom. The billing increment quietly trains you to treat throwaway compute as permanent.

And then autoscaling, to fix the thing pricing broke

Autoscaling is sold as the answer, but look at what it actually is: a control loop you now operate to dodge a pricing model. You write scaling policies. You tune cooldowns so you do not thrash. You model warm-up time so new instances are ready before the load arrives, which means you are pre-provisioning to scale, which is the round-up wearing a costume. You add a load balancer, health checks, and a dashboard to watch the autoscaler you built to watch the load. The complexity tax is real, and you pay it in engineering hours to save money the pricing took in the first place.

What we did instead

We think most of this disappears if the pricing stops punishing accuracy. So Kaligon bills per second, and the per-second meter is capped monthly — after roughly 730 hours the meter stops, so a box you leave running just settles into a flat monthly price. A 12-minute job costs 12 minutes. No two-hour rounding, no reason to leave things on.

There is no instance catalog. You set cores and RAM where you want them — 1 to 96 vCPUs, 1 to 512 GB — and you can hot-resize a running box instead of guessing at create time and living with it. Move the sliders on the pricing configurator and the estimate updates as you go, so you size against a real number, not a spreadsheet you rebuild every quarter.

One flat price per resource. No reserved tiers, no spot bidding, no committed-use discounts to forecast three years out. The point is not to be clever about cost — it is to make the honest guess the cheap one. Provision what you need, resize when you are wrong, and pay for what you used instead of what you were afraid you might need.

You can delete the right-sizing spreadsheet. We were never going to read it anyway.