Peak-to-Average Ratio Is Your Real Cloud Bill: Reading the Load Duration Curve

A server bill is not a price per CPU. It is a price per unit of headroom, and the amount of headroom you are forced to buy is set by the shape of your load curve rather than by how busy you are on average.

That distinction explains a pattern most infrastructure teams have seen and few have quantified. Two services run the same amount of total work per month. One pays three times what the other pays. Nothing is misconfigured, nobody is overselling, and both providers are charging honestly. The difference is that one workload spreads its demand evenly and the other concentrates it into a few hours — and capacity is bought in steps, not in litres, so a concentrated workload has to hold a much larger step open for a much smaller amount of work.

This article is about the measurement that makes that difference visible: the load duration curve, and the single derived number — peak-to-average ratio — that decides whether a fixed instance is efficient or whether you are renting standby. It covers five workload shapes and what each one genuinely costs, the three ways to stop paying for headroom, why burstable credit tiers are a discount for some curves and a surcharge for others, the three ways people misread their own data, and a procedure you can run in an afternoon that ends with a number rather than an opinion.

The Number You Provision For Is Not the Number You Average

Almost every monitoring dashboard put in front of an infrastructure owner leads with average utilisation. It is the wrong number for a purchasing decision, and the reason is structural rather than statistical.

Average utilisation is a continuous quantity. Provisioned capacity is not. You buy 2 vCPU or 4 or 8, and the amount of work the machine can absorb in any given second is fixed at that size. You cannot buy 1.7 vCPU and you cannot buy 2 vCPU on Tuesday and 6 on Wednesday without doing something about it. So the quantity that matters for the bill is not the mean of your demand, it is the maximum of it, because that is the size of the step you have to hold open.

Once you accept that, the arithmetic of a fixed instance becomes simple and slightly uncomfortable. A server provisioned to clear its own peak delivers, over a month, only the area under its actual demand curve. Everything between the demand curve and the provisioned ceiling is capacity that exists, is billed, and does nothing. The share of it is trivial to compute: if a workload averages 30% utilisation and you sized the box for its peak, then roughly 70% of what you are paying for is standby.

That is not a moral failing on anyone's part, and it is not always avoidable. A payment API that must answer in 40 milliseconds during a flash sale genuinely has to hold that capacity open, and holding it open for the 99% of the month when it is quiet is the price of being ready during the 1% when it is not. What is avoidable is paying that price without knowing you are paying it — which is the normal state of affairs, because an average-utilisation dashboard will happily report 30% and let you conclude the machine is wasted.

The right question is not "how busy am I". It is "how peaked am I". A load duration curve answers that.

Reading a Load Duration Curve

A load duration curve takes every utilisation sample in a period, sorts them from highest to lowest, and plots them against the cumulative share of time. The x-axis is not time — it is the share of the period spent at or above a given level. The y-axis is the utilisation level itself.

The shape carries information that the average destroys.

• A curve that starts high on the left and stays high across most of the width describes a workload that is genuinely busy. There is no trough to exploit, and paying for it is not waste.
• A curve with a tall narrow spike on the left that collapses within the first few percent describes a workload whose demand is concentrated. Most of the width sits near the bottom.
• The height at x = 0 is what you must provision. Nothing else on the chart sets the purchase.
• The area under the curve is the compute you actually consume. It is the only part of the bill that bought work.
• The point where the curve crosses your provisioning line is the share of time you are capacity-constrained. If that crossing sits at 2% of the month, you were throttled — or would have been — for about fourteen hours out of 730.

The last point is the one that changes decisions. Two workloads can have identical averages and identical peaks and still be completely different purchases. If the peak lasts four minutes, a scheduler that starts an extra instance in ninety seconds can absorb it. If the peak lasts four hours, the same scheduler absorbs it three minutes in and then competes with it for the remaining 237. The duration of the excursion — not its height, and not the average — determines whether time-metered capacity can substitute for owned capacity at all.

Peak-to-Average Ratio: The One Number That Sets Your Headroom Bill

Divide the maximum utilisation sample by the mean. The result is dimensionless, so it survives a change of instance size, a change of provider, and a change of units. Call it the peak-to-average ratio.

The ratio is a direct read on how much standby you are forced to buy. A ratio of 1.0 means demand is flat and fixed sizing is nearly optimal — you are paying for headroom you also use. A ratio of 5.2 means that for every hour of work delivered, you hold about five hours of provisioned capacity open, and the great majority of it is idle by construction.

Five archetypes, computed over a synthetic but realistic 730-hour month, show how wide the spread gets. Each is assumed to be provisioned on 4 vCPU to clear its own peak.

The steady API is the case where the ratio argues for owning capacity. It is busy 55% of the time, which sounds mediocre, but there is no trough to exploit and no schedule to ride — the capacity has to exist at every moment, and the only lever is making the box the right size. The nightly batch is the opposite extreme: it runs hot for four hours and is nearly silent for twenty, so 82% of what a peak-sized box costs is standby. Two services, same provider, same region, and the batch workload is carrying four times the idle overhead per unit of work.

None of this is a defect in either workload. It is a description of what each one needs, and the ratio is simply the size of the mismatch between what the workload needs and what fixed capacity can express.

Five Workload Shapes and What Each One Actually Costs

The ratio tells you how much standby you are buying. What you do about it depends on a second property that the ratio alone does not capture: whether the peak is repeatable.

The nightly batch is the most instructive row. Its peak-to-average ratio is the worst of the five, and it is also the easiest one to fix, because a batch job is the one workload that tells you in advance exactly when it will need capacity. When the schedule is known, the capacity does not have to be owned continuously — it only has to be available at the moment the job starts. That is the entire argument for time-metered capacity, and it applies to a batch job with almost no caveats.

The month-end spike is subtler. Its ratio is high, and its peak is predictable, but it arrives once per cycle, which means any scheduling machinery you build has exactly one rehearsal per month. A scheduling mistake that costs nothing on a daily job costs a whole cycle on a monthly one. For those shapes, the pragmatic answer is usually a smaller baseline plus a queue that absorbs the spike, rather than automation that has to be correct on the first attempt every time.

The Two Ways to Stop Paying for Headroom

There are only two honest levers, and they solve different halves of the problem.

The first is to reshape the load. Peak-to-average is a property of the workload's schedule, not a law of nature, and a surprising share of peaks are self-inflicted. A backup job that starts at midnight is competing with the traffic that also peaks at midnight. A cache that expires on the hour sends a synchronised thundering herd at every hour boundary. Concurrency limits that are set per connection rather than per origin let one call path saturate the box while everything else waits. Moving a batch window, staggering cache expiry, or capping per-origin concurrency all reduce the peak without buying anything, and they are usually cheaper than the capacity they replace. They are also permanent: the peak stays down next month, unlike a discount.

The second lever is to stop owning capacity during the hours you do not need it. This is where hourly billing earns its place, and the arithmetic is narrower than the marketing suggests. Time-metered capacity only wins when the idle window is long enough that the per-hour savings across the quiet hours exceed any premium you pay during the busy ones. An instance that runs continuously belongs on a monthly or annual rate; an instance that runs four hours a night belongs on an hourly one, because you are paying for 120 hours a month instead of 730. The break-even is a comparison you can run on the back of an envelope, and it is worth running rather than assuming, because the answer flips at a specific number of idle hours rather than at a vague feeling about flexibility. There is a full worked comparison of which workload shapes actually save money under hourly billing, including the shapes where it quietly loses.

A third option, horizontal scaling, is worth naming because it is often proposed as a universal answer and is not. Splitting a load across several smaller units does reduce the granularity of the step you have to buy, which is a genuine advantage — the marginal unit is small, so over-buying the peak costs less. But it requires the workload to be stateless, it requires a load balancer and a health-check path that does not itself become the bottleneck, and it converts a proven single-machine peak into a distributed one you now have to measure across N nodes. For a stateful service with a database behind it, horizontal scaling moves the constraint rather than removing it.

A Third Option: The Credit Ledger

Between owning the peak and renting by the hour sits a third structure that most hyperscalers offer and most documentation describes badly: the burstable tier, where you buy a baseline and a bank of credits, and the bank pays for excursions above the baseline.

The mechanics are worth setting out precisely, because the arithmetic decides whether the tier is a discount or a surcharge. Using the pricing model Amazon documents for its T-family instances — the clearest published description of the pattern — one credit equals one vCPU-minute at full utilisation, and credits accrue at a rate set by the instance's baseline percentage. A two-vCPU instance with a 10% baseline earns 12 credits per hour. The same instance burning at 100% for one hour consumes 120 credits. That ratio is the whole story: ten hours of accrual fund one hour of full-rate work.

The bank is capped, and that cap is the part people miss. Accrual stops at a maximum per 24-hour period regardless of how idle the instance was, so you cannot save up a month of quiet and spend it on one busy Tuesday. A two-vCPU instance on a 20% baseline can accumulate at most 576 credits in a day, which funds 4.8 hours at full rate even if the machine did nothing else at all. A workload that needs six hours of maximum throughput is already past the ceiling.

Above the ceiling, the model switches from a bank to a meter. When utilisation stays above baseline, the instance cannot earn enough to repay what it spent, and the unpaid surplus is charged at a fixed per-vCPU-hour rate. The mechanism is designed so that being busy is never free, only deferred — and it stops being a good deal at a computable point.

Where the Credit Ledger Stops Paying Off

That point is the break-even utilisation, and it is published rather than hidden. Amazon documents it for its own tiers: a two-vCPU burstable instance on a 30% baseline costs the same as an equivalent fixed instance at an average utilisation of 42.5%, and more above it. At sustained full rate, the burstable option is documented to land around 1.5 times the cost of the fixed one of the same size.

Three consequences follow, and all three are checkable against your own duration curve.

First, a workload whose duration curve sits above the baseline for more than a few hours a day is not buying flexibility, it is paying a surcharge in instalments. If the curve's shoulder is thick — if a quarter of the month sits above the baseline rather than a few percent of it — the credit ledger was the wrong instrument and the fixed tier was cheaper and more predictable from day one.

Second, the baseline is a per-vCPU average, and averaged capacity hides serialisation. A four-vCPU machine with one thread pinned at 100% and three idle averages 25%, which is at or below many baselines — so it accrues credits while the one thing the user is waiting on is capacity-starved. The average looks healthy and the latency is terrible. This is the same trap as the utilisation dashboard, moved one layer down.

Third, exhaustion has a timing, and the timing is unhelpful. The bank drains fastest during the exact period it was bought for — the busy run — which means the moment the workload most wants headroom is the moment it starts paying the metered rate. For a short, occasional excursion that is fine. For a long one, the metered rate applies to precisely the hours you would have wanted to pre-pay.

The rule that comes out of this is compact. Burstable credit tiers pay off when the duration curve has a thin shoulder: a low baseline most of the time, with excursions that are short, occasional, and separated by long quiet periods. They stop paying off when the excursion becomes the workload — when the busy period is long enough that you would have been better off simply buying the fixed tier, where the top of the curve is a line item you can read in advance instead of a meter you discover afterwards.

Three Ways You Will Misread Your Own Curve

Measuring the curve is easy. Measuring it correctly is where most of the value sits, because three specific errors are both common and self-concealing.

The third error is the most expensive, because it produces confident conclusions. A machine reported at 25% CPU looks like it should be halved, and halving it will make the service slower, not cheaper — if the actual constraint was disk latency or network throughput, reducing CPU alongside it removed capacity the workload was quietly depending on. Sizing is a multi-resource measurement problem before it is a cost problem, and the reliable way to get it right is to measure each bound resource separately and treat the worst one as the one that decides the step.

Two smaller traps are worth naming. The first is measuring a period that does not contain your actual peak — a representative week sampled in a quiet month will report a comforting ratio that the next month-end invalidates, so the window has to include a billing close, a release, or whatever event sits at the top of your year. The second is trusting an infra-level average for a workload that runs inside a container. When a container is throttled at its CPU limit, the host can look calm while the application experiences latency; the throttling shows up in the container's own accounting, not in the host's utilisation numbers. If your service runs in a cgroup, read that cgroup's throttling counters rather than the machine average.

How to Build Your Own Duration Curve in an Afternoon

The procedure is short enough to run before you buy anything, and it produces a number instead of an impression. It needs one window that contains your real peak, sampled finely enough to see your shortest busy period.

1. Collect samples at one-minute resolution across the window — a reporting period that includes the busiest day you have. On a Linux host, a one-minute pass over the CPU statistics, the per-CPU view, and the virtual memory and input-output counters will give you the raw material. If you are reading a provider's monitoring, set the resolution to one minute rather than the default rollup.
2. Convert to utilisation. CPU-reported idle percentage is the complement of utilisation, so take one hundred minus idle and be consistent about it across every resource you trace.
3. Sort the samples in descending order and compute, for each one, the share of samples at or above it. That pair is a point on the curve. The sorted list plotted left to right is the curve.
4. Read four numbers off it: the median, the ninety-fifth percentile, the ninety-ninth percentile, and the maximum.
5. Divide the maximum by the mean. That is your peak-to-average ratio, and it is the number the purchasing decision turns on.
6. Take the share of time above your candidate provisioning level. If that share is very small, the candidate size is defensible; if it is a tenth of the month, you are deciding to be constrained for three days.
7. Compare the top one percent of time against the top twenty-five percent. A workload whose top one percent is dramatically higher than its top quarter has a thin spike and is a candidate for temporal matching. A workload where the two are close has a thick shoulder and needs owned capacity.
8. Repeat for memory, disk and network. The resource with the highest ratio is the one that sets the size you actually need.

The output is a single page: five curves, five ratios, and the share of time above the candidate ceiling for each. That page answers the purchasing question directly, and it also tells you which of the three levers applies. A high ratio with a thin spike says reshape or schedule. A high ratio with a thick shoulder says you are buying the wrong shape of capacity. A low ratio says stop optimising and buy the instance.

The Decision Rule: Curve Shape to Billing Model

With the ratio and the shape in hand, the choice of billing model stops being a preference and becomes a lookup. The thresholds below are deliberately coarse, because false precision here is worse than a rule of thumb — the purpose is to narrow the field, not to compute a forecast.

Two cross-checks belong with that table. The first is the term question: once the shape says a fixed instance is right, the discount attached to paying further ahead is a separate calculation, and it is a financing question rather than a capacity question — the subject of its own walk-through on how to price the implied cost of committing to a longer term, which is worth doing before you sign a multi-period rate. The second is comparability: two quotes for the same curve can look wildly different because one prices the peak and the other prices the traffic, so normalise to a common unit before comparing, which is exactly what a properly constructed cross-provider price benchmark does.

The ordering matters as much as the mapping. Reshape the load first, because it is free and permanent. Then choose a billing model that matches the resulting curve. Only then negotiate the term. Teams habitually do this in the opposite order — pick the plan, then try to fit the workload to it — and the result is a commitment that prices standby as if it were work.

Why the Headroom Problem Is Getting More Expensive

The overhead a curve shape imposes is a multiplier, and a multiplier applied to a rising base grows faster than the base. Two current data points make the multiplier worth fixing now rather than later.

The first is what the headroom itself costs. TrendForce's October 2026 memory research, published on October 1, expects conventional DRAM contract prices to rise another 10% to 15% quarter-on-quarter in the fourth quarter of 2026, with NAND contract prices up 15% to 20% in the same period. Server DRAM is singled out as remaining undersupplied, held back by component supply, packaging capacity, and the flexibility of front-end process allocation rather than by demand. Memory is a direct input to the size of the instance you rent, so a curve that forces you to hold a large step open is buying that step at a rising unit price.

The second is where the demand for that memory is coming from. Gartner's forecast published on October 23, 2026 puts total global IT spending at 7.35 trillion dollars in 2027, up 15% year over year and past seven trillion for the first time, with data center systems the fastest-growing segment at 1.366 trillion dollars, up 55.5%, and infrastructure-as-a-service at 367 billion dollars, up 25.7%. The same release attributes much of that increase to memory prices having more than doubled over the previous twelve months and expects the inflation to persist through 2027 before hardware prices stabilise.

Read together, the two say something specific about standby. When memory was cheap, the cost of over-provisioning a peak was a rounding error and nobody needed a duration curve. When the unit price of the thing you over-provision is rising by double digits per quarter and the segment that consumes it is growing faster than any other, the ratio in the previous section stops being an academic exercise. The 82% of a peak-sized instance that a nightly batch leaves idle is a fixed proportion, but it is a proportion of an escalating number — which is why the measurement pays for itself in the first cycle rather than at some hypothetical future scale.

Where This Lands in Practice

Run the procedure on a typical nightly batch and the answer arrives with unhelpful clarity. Its peak-to-average ratio sits above five. It is genuinely busy for roughly four hours in twenty-four. A fixed instance sized for its peak therefore spends about 82% of the month being paid for and unused, and no amount of tuning removes that, because the shape is not a mistake — it is what the job is.

This is the point where the structure of the offer starts to matter more than the CPU model printed on it. The decision the curve hands you is: hold the peak open continuously at dedicated rates, or pay only for the window in which the work actually happens. Which of those is available to you depends on whether the provider sells a plan whose billing period can be shorter than the workload's idle period, and whether the configuration can be adjusted later without a migration when the shape changes.

SurferCloud runs two plan families side by side for exactly this reason, and the plan comparison page places them next to each other so the trade-off is visible rather than buried in a specifications list. The simple application server family is the cheaper shape: fixed configuration, shared bandwidth, no resizing, which makes it a good fit for a workload whose curve you have already measured and do not expect to change. The elastic compute family is the adjustable one: it is billed hourly, monthly or yearly, its configuration ranges far wider, and it can be resized without rebuilding the instance, which matters when the measured shape is provisional rather than settled. Both are on the combined plan and pricing page alongside the current promotion.

One honest limit is worth repeating, because a duration-curve decision is a decision about change. The promotional tiers on that page are fixed as to region and configuration, and their published terms state that resources deleted mid-term are refunded at list price rather than at the discounted rate. If your measurement says the workload will grow or move, read those terms before the discount, and price the elastic family instead — the plan that can be resized is worth more than the plan that is cheaper, for a curve you expect to shift.

Frequently Asked Questions

Is a high peak-to-average ratio bad?

No. It is a property of the workload, not a defect in it. A nightly batch is supposed to be concentrated. The ratio only becomes expensive when you buy fixed capacity for it, because the standby hours are then billed as if they were working hours. The same workload on time-metered capacity has the same ratio and a much smaller bill.

Does autoscaling remove the need to measure this at all?

Only when the excursion is long enough for the scale-out to complete. A new instance typically takes tens of seconds to a couple of minutes to become ready. A spike that lasts ninety seconds is over before the replacement capacity joins, so the shape still decides the outcome: thin spikes cannot be scheduled away and have to be absorbed by headroom or by queueing.

Can I lower the ratio without changing anything about how I buy?

Yes, and it is usually the cheapest step. Move batch windows out of the traffic peak, stagger cache expiry so it does not fire on the hour, and cap concurrency per origin rather than per connection. Each of these reduces the peak without provisioning anything, and unlike a discount the reduction persists next month.

How fine does my sampling need to be?

Finer than your shortest busy period. If some part of the workload runs on a thirty-second cycle, a five-minute rollup will report an average that never shows it, and the curve will look smoother than reality. One-minute samples are the practical floor for most services; if you know a component cycles faster than that, sample it separately.

Does the average matter at all, then?

It matters a great deal on a time-metered plan, where the average sets the hours you pay for, and almost not at all on a fixed plan, where the peak sets the line item and the average only tells you how much of the purchase went unused. Which is another way of saying the same thing: measure the curve first, because it tells you which quantity your bill is actually made of.

The Short Version

A server bill is a price per unit of headroom, and headroom is set by the shape of the load curve rather than its average. Build the curve by sorting every utilisation sample from highest to lowest and plotting it against the share of time; read the height at the top, the area underneath, and how long the excursion lasts. Divide the peak by the mean to get the ratio that decides whether a fixed instance is efficient or whether you are renting standby. Reshape the load first because it is free, match the billing model to the resulting shape second, and negotiate the term third. Burstable credit tiers are the right answer for a thin shoulder and a metered surcharge for a thick one. Do the measurement once, properly, and the purchase decision stops being a matter of opinion.

Further reading on the same selection questions: the five measurements to take before buying a server, including how to identify which resource actually binds; which workload shapes genuinely save money on hourly billing; how to price the implied interest rate of a prepayment discount once the shape points to a fixed instance; and the October 2026 cross-provider pricing benchmarks that normalise unlike tiers to a comparable unit before you compare them.