Rented machine sizes usually step by doubling — what does rounding a service up to the next size buy?
answer
- the ladder is coarse
- double the machine, double the charge
- headroom is bought, not free
- utilisation falls as you round up
- two smaller rungs against one larger
basics
~20 sRounding up buys roughly double the resources for roughly double the hourly charge — a purchase, not a free safety margin. A service measured just past one rung spends most of the next rung idle, which is where a fleet's bill quietly grows.
solid answer
~50 sThe size ladder inside a family is coarse: each rung is usually about twice the previous one on the dimensions the family scales, and the charge rises roughly in step. So rounding up is a purchase of about twice the machine, not a small allowance for error. A service measured at 2.3 cores that lands on a four-core rung runs at roughly 58% utilisation and pays about twice the rung below it. That is sometimes exactly right — a single process whose working set must sit in one address space, or a peak whose overshoot costs customer requests — and it should be a stated decision with a number attached rather than a reflex. The alternative the coarse ladder makes attractive is spreading the same work across two smaller rungs, which fits the measurement more closely and puts the work in more than one failure domain.
go deeper
Know that rented sizes come as a coarse ladder rather than a dial, and that stepping up one rung is normally about twice the machine at about twice the hourly charge.
Compute the two numbers that make it a decision: the utilisation you will actually run at on the chosen rung, and the multiple of the rung below that you are agreeing to pay every hour.
Show when you take the round-up anyway — an unsplittable working set, an expensive peak, a disruptive resize — and when you would instead spread the work across two smaller rungs in separate failure domains.
The fleet-level question is the habit, not the instance: everyone rounding up is individually defensible and collectively a systematic multiple of measured demand. Decide what a round-up must record before it ships.
## The ladder is coarse on purpose Inside a machine family, providers sell a **ladder of sizes** rather than a continuous dial. The usual shape is a doubling: each rung roughly doubles cores, memory and the throughput allowances that come with them, and the hourly charge rises roughly in proportion. Providers differ in the details — some ladders step by less than a factor of two at the small end, some publish fractional rungs, some attach local disk only from a certain rung upward — but the coarseness is common to all of them, and it is what makes "just round up" an expensive habit. The illustrative shape, stated as relative charges rather than real prices: | Rung | Cores | Memory | Relative hourly charge | |---|---|---|---| | small | 2 | 8 units | 1x | | medium | 4 | 16 units | about 2x | | large | 8 | 32 units | about 4x | ## What rounding up actually buys Three things, and it is worth separating them: 1. **Headroom you have paid for.** The gap between the measurement and the rung is real capacity, available immediately, with no resize to perform. That has genuine value when a peak is unpredictable and overshooting it is expensive. 2. **A lower utilisation number.** A service measured at 2.3 cores on a four-core rung runs at about 58% of it. The unused 42% is not waste in a moral sense; it is capacity you bought and may need. 3. **Roughly twice the hourly charge of the rung below.** This is the part that gets skipped, because the rung below was affordable and the phrase "just one size up" sounds proportionate to the overshoot rather than to the ladder. What it does **not** buy is speed per unit of work. A larger rung supplies more resources, not faster ones: a single-threaded job that cannot use a second core finishes in about the same time on either rung while costing twice as much on the larger. Where a larger rung does help, the mechanism is usually that a throughput allowance or a memory limit stopped binding, not that any individual operation became quicker. ## When rounding up is the right call - The work is **one process** whose working set must live in a single address space, so it cannot be split across two smaller machines. - The peak is **unpredictable and expensive to miss** — a customer-facing tier where exceeding the size shows up as failed requests rather than as a slower batch. - The **resize itself is disruptive** on your platform, so buying a rung of margin is cheaper than a stop-and-resize during the next growth cycle. - The measurement is **new and untrusted**, in which case say so and attach a review date, rather than letting the round-up become permanent by silence. ## When it is the wrong call - The work **splits cleanly**. Two rungs below often cost about the same as one rung above while fitting the measurement more closely and placing the work in more than one failure domain. - The overshoot is **tiny and one-off** — a single unrepresentative spike in the samples, which a percentile should have excluded in the first place. - The service is really on **the wrong family**, and the round-up is buying the resource you need by also buying a pile of the one you do not. ## Why this is where a fleet's bill grows One rounded-up service is a rounding error. The pattern that matters is organisational: everyone rounds up, every round-up is individually defensible, nobody records the reason, and the fleet ends up carrying a systematic multiple of its measured demand. The countermeasure is not a rule against rounding up — it is making the round-up an explicit, recorded decision with a number and a review date, so the next person can see whether the reason still holds. ## Checking the arithmetic Two numbers make the trade-off concrete. First, the utilisation you will run at: measured demand divided by the rung you chose. Second, the multiple you are paying: the chosen rung's charge divided by the charge of the rung below. Both are qualitative here — the exact ratios come from the provider's published ladder — but stating them turns a reflex into a decision. In the worked example, 2.3 cores on a four-core rung is about 58% utilisation at about twice the charge of the two-core rung, which would have been asked for more than it has and failed.
- When is rounding up to the next rung clearly the right call?When the work is one process whose working set must sit in a single address space, so it cannot be split; when the peak is unpredictable and overshooting it shows up as failed customer requests; or when a resize on your platform is disruptive enough that a rung of margin is cheaper than performing one under pressure. Say which of those applies and attach a review date.
- Does moving up one rung make an individual request or job finish faster?Not by itself. A rung supplies more resources, not faster ones, so a single-threaded job that cannot use a second core finishes in about the same time at roughly twice the charge. Where a larger rung genuinely helps, it is usually because a memory limit or a throughput allowance stopped binding, not because any one operation became quicker.
Buying shoes from a rack that stocks only even sizes: there is no half-size, so you either squeeze into the smaller pair or pay for a pair you rattle around in.
saying these in an interview costs you the question
- Treats rounding up as free insurance rather than roughly double the charge.
- Assumes the next rung gives slightly more, not about twice as much.
- Believes a larger rung raises per-core speed rather than resource quantity.
- Rounds every service up by default, then reports the fleet as right-sized.
- Expects a steep volume discount for one large rung over two small ones.