The Meter Counts Seconds, the Budget Counts Instance-Hours
Cloud compute is metered in seconds and reasoned about in hours. A usage export gives you a column of vCPU-seconds, GiB-seconds and function-seconds with eight-figure totals in it; the rate card next to it is priced per hour, the capacity plan is written in instance-hours, and the finance team wants to know how many machines' worth of running time last month actually was. Getting from one to the other is a division by 3 600, done often enough that it is worth doing carefully.
What the Second Totals Are Really Counting
Resource-seconds, not wall-clock seconds
A minimum duration under the meter
Memory is metered the same way
Hours make fleets comparable
Rolling a Usage Export Up Into Instance-Hours
The steps below follow a monthly cost review: a CSV of metered seconds on one side, a rate card and a capacity plan quoted in hours on the other.
Paste the metered total straight in
Drop the eight-figure second count from the export into the left field. Spaces used as thousands separators are ignored and a comma is accepted for the decimal point, so a value copied out of a spreadsheet needs no cleaning.
Divide the hours by the resource multiplier
Resource-seconds carry a core or a gigabyte in them. Convert first, then divide the hours by the vCPU count or the GiB allocation to get the wall-clock hours a machine or a function actually ran.
Compare it against 720
A 30-day month holds 720 hours. Dividing the result by 720 turns an abstract usage figure into "we ran the equivalent of six instances all month", which is the sentence a commitment decision is made on.
Reverse it to price a single job
The swap button (↔) gives h → s, which is how an hourly rate becomes a per-second one and how a "two-hour nightly job" becomes the 7 200 seconds a quota or a timeout is expressed in. The copy control hands over bare digits for the spreadsheet.
Usage Lines and the Hours They Roll Up To
Typical rows from a monthly export, each with the seconds the meter recorded and the hours the same usage becomes once divided by 3 600. The month is taken as 30 days, or 720 hours.
| Usage line | Seconds consumed | Hours | Note |
|---|---|---|---|
| One vCPU running the whole month | 2 592 000 vCPU-s | 720 vCPU-h | The reference figure every export should divide into |
| A 2-vCPU VM, same month | 5 184 000 vCPU-s | 1 440 vCPU-h | 720 wall-clock hours × 2 cores |
| Autoscaling group averaging six instances | 15 552 000 instance-s | 4 320 instance-h | 4 320 ÷ 720 = six machines' worth of running |
| One million function calls at 250 ms | 250 000 s | 69.44 h | Duration charges only; requests are priced separately |
| Those calls at 2 GiB allocated | 1 000 000 GiB-s | 277.78 GiB-h | Memory is metered on the same clock |
| 500 000 jobs of 8 s, 60-second floor | 30 000 000 billed s | 8 333.33 h | Actual runtime was 4 000 000 s, or 1 111.11 h |
| CI runners, 12 000 build-minutes | 720 000 s | 200 h | Build minutes are just seconds with a friendlier label |
| One core-day of spot batch work | 86 400 s | 24 h | Interruptions end the meter mid-job |
The sixth row is where most cost surprises live. Half a million eight-second jobs represent 1 111 hours of real work, but a 60-second floor bills 8 333 — seven and a half times the runtime, for a workload whose logs all look healthy. Batching those jobs so each container start covers a full minute of work removes the penalty without touching a single line of business logic.
What This Pair Does During a Cost Review
Export totals go in as they come
Both fields stay live while you type and spacing is ignored, so a raw eight-figure total from a billing CSV becomes hours before the next slide is up.
Read a rate card backwards
Swapping the pair turns an hourly price or an hourly quota into the per-second figure the meter, a timeout setting or a concurrency limit is written in.
Days and months for the commitment view
Every time unit is searchable on both sides, so a usage total can be read in days when the argument is about a one-year commitment rather than about last night's batch window.
Fleet-scale totals stay legible
Thousands are spaced apart in the result, and totals above ten billion seconds switch to scientific notation instead of filling the field with digits.
Questions From the Cloud Cost Review
Why does a 60-second floor cost so much more than the jobs actually run?
Because the floor is charged per start, not per workload. Per-second billing on the major providers begins after a one-minute minimum, so an eight-second job is billed as sixty — seven and a half times its runtime. Half a million of them come to 30 000 000 billed seconds, 8 333.33 hours, against 4 000 000 seconds of real work, or 1 111.11 hours. Anything that starts a fresh instance or container for a job shorter than a minute is paying this tax, and the fix is always the same: batch the work so each start earns its minute.
What is a GiB-second and how does it turn into an hourly figure?
It is allocated memory multiplied by the time it was allocated for — 2 GiB held for half a second is one GiB-second. Divide by 3 600 and you have GiB-hours, which is what a rate card prices. A million invocations at 2 GiB and 500 ms each produce 1 000 000 GiB-seconds, or 277.78 GiB-hours. Note the lever: memory allocation multiplies the whole bill, so doubling a function's memory to make it finish slightly faster is usually a net loss unless the runtime more than halves.
Is per-second billing genuinely cheaper than paying by the hour?
For short and bursty work, dramatically. Under hourly rounding a 20-minute job is billed as a full hour, three times its 1 200 seconds; under per-second billing it is 0.33 hours and the arithmetic stops there. For anything running longer than an hour the two converge and the difference disappears into rounding. The real saving is behavioural: when a machine can be switched off for eleven minutes and cost eleven minutes, teams start switching machines off.
Our export says 2 592 000 vCPU-seconds — one instance or many?
The meter cannot tell you, and that is the point. It is 720 vCPU-hours, which fits a single one-core machine left up for a 30-day month, a two-core machine up for half the month, or 720 short-lived one-core workers each running an hour. Look at the instance count and the per-resource breakdown alongside the total: an even 720 usually means something is permanently on, while a jagged shape across the same total means autoscaling is doing its job and the number is a genuine average.
Why don't the invoice hours match the runtime in our own logs?
Several small gaps, all in the same direction. The meter starts before your application does — image pull, boot and initialisation are billed while your logs are still silent — and it keeps running through shutdown. Minimum durations top up every short start. Storage attached to a stopped instance is charged even though the compute meter has paused. And the billing period is cut on the provider's clock, usually UTC, so a job spanning midnight is split across two lines. Reconcile the totals first and only chase individual lines when the gap is larger than the minimum-duration effect can explain.
No comments yet. Be the first to comment!