A Cloud Bill Is Not a Price. It Is Three Clocks.

A cloud bill is not a price list. It is a clock, and the clock is not the same clock in every provider's contract.

That distinction sounds philosophical until you try to predict a bill. Two providers can quote the same hourly rate for the same vCPU and RAM and produce invoices that differ by a factor of three for identical work, because what you are buying is not a quantity of computing. It is time on a meter, and the meter has three separate mechanisms: an increment that decides how a fractional unit is rounded, a floor that sets the smallest charge the provider will accept, and a set of counters that keep running after you have stopped the thing you thought you had stopped.

Almost every "why is my cloud bill higher than my estimate" conversation traces back to one of those three, and almost none of them trace back to the headline rate. The headline rate is the one number providers compete on and the one number buyers compare. The other three are printed on the same pages, in footnotes and lifecycle documents, and they are where the money actually goes.

This article takes the three mechanisms apart using the published billing terms of mainstream providers as of November 2026, works out the arithmetic for each, and closes with a fifteen-minute procedure for reading your own invoice as a clock rather than as a price. It ends with the one workload shape where metering granularity stops mattering at all - which is the shape most buyers are actually running.

The Direct Answer: A Bill Has Three Clocks, Not One

A cloud VM bill is determined by three independent settings, and the hourly rate is only the first of them. The increment is the smallest slice of time the provider measures - one hour at the coarse end, one second at the fine end, with one minute as the common compromise. The floor is the smallest amount the provider will charge for a single run, regardless of how briefly that run lasted, and it applies per usage cycle rather than per day. The persistence is the list of counters that continue to bill after the compute unit has stopped, which typically includes block storage, snapshots, and public addresses.

Of the three, the floor is the least understood and the most expensive at scale, because floors are additive. Each new usage cycle earns a fresh minimum, so a workload that cycles more often pays more minimums, and the minimums can exceed the wall-clock hours that exist. The persistence counters matter for the opposite reason: they are invisible in the console, because a stopped instance looks like a stopped bill.

The Increment: Why a Short Job Costs More Than It Computes

The increment is a rounding rule, and rounding rules behave like a tax on short work. If the provider measures in one-hour blocks, an eight-second job is billed as an hour. The same job on a per-second meter is billed as eight seconds. Nothing about the work changed; the meter did.

The published terms in November 2026 span both ends of that range. Amazon EC2 bills in per-second increments with a sixty-second minimum on the compute clock. DigitalOcean announced that effective January 1, 2026 its Droplets move to per-second billing with a minimum charge of sixty seconds or one cent, whichever is higher. Public IPv4 addresses at AWS are metered the same way - one-second increments, sixty-second minimum - a detail worth noting because it means the address meter and the compute meter round identically, so you cannot reason about one from the other.

What the rounding costs, in multiples of the work actually performed:

The table contains the whole decision. Below roughly an hour of runtime, the increment is the dominant cost term and the hourly rate is almost irrelevant - a provider at half the rate with a one-hour increment loses to a provider at full rate with a per-second one on every job in the top three rows. Above an hour, the increment washes out and the rate reasserts itself, which is why the same two providers can be the right answer for two different teams.

There is a second-order effect that catches people optimising a batch pipeline. If you split one large job into many small parallel jobs to finish faster, you multiply the number of billing cycles rather than the amount of work. Twenty four-second workers on a sixty-second floor cost the same as twenty full minutes of compute, for eight seconds of useful output apiece. Parallelism is free on the compute and expensive on the clock.

The Floor: One Minute That Can Bill Twenty-Four Hours

The floor is a separate mechanism from the increment, and the two are frequently conflated. The increment rounds a single unbroken run. The floor sets a minimum for each cycle, and a cycle begins every time the resource transitions into a billable state. That means floors accumulate.

AWS documents this precisely for EC2: each time an instance transitions from stopped to running, a new billing period starts and a minimum of one minute applies. Restarting an instance that was already running does not - a reboot continues per-second billing with no additional minimum. That single sentence is the most useful fact in this article, because it tells you that a restart is free and a stop-then-start is not.

Put a number on the floor and the shape of the problem appears:

• 100 stop/start cycles per day earns 100 minimums, which is 100 minutes, or 1.67 hours, of billed time per calendar day. Over a 30-day month that is 50 billed hours - 6.85 percent of the 730 hours in an average month - paid for time the instance spent off.
• 1,440 stop/start cycles per day earns 1,440 minimums, which is exactly 1,440 minutes, or 24 hours of billed floor against a 24-hour clock. The floor alone saturates the day.
• 2,000 cycles per day bills 33.3 hours of floor into a day that contains 24. The meter is no longer tracking time; it is counting events.

Nobody runs 1,440 cycles on one instance. But the same arithmetic applies across a fleet, and that is where it stops being hypothetical. A scheduled scaler that takes a pool to zero overnight and back in the morning, a test harness that provisions per commit, an autoscaling group oscillating around a threshold - each of these multiplies floor charges by event count, and none of them shows up as a line item called "floor". It shows up as an hourly total that does not match the hours anyone remembers running.

The fix is a change of verb, and it costs nothing. AWS states that a reboot does not start a new instance billing period, while a stop and start does. So any maintenance procedure that only needs the operating system restarted - a kernel parameter, a package upgrade, a stuck process - should reboot rather than stop and start. On a hundred maintenance cycles a month, the difference between the two verbs is 1.67 hours of billed floor, and it converts an outage into a restart.

The Third Clock: What Keeps Billing After You Stop

The most expensive misunderstanding in cloud billing is the belief that stopped means free. It means partially free, and the part that remains is documented per product rather than on the compute page.

AWS states that a stopped instance incurs no instance usage charge and no data transfer charge, but that storage for any Amazon EBS volume continues to be charged. The same documentation makes the persistence explicit with a table of orphanable resources, and Microsoft's cloud security benchmark agrees, defining orphaned resources as the set to be swept: unattached disks, unused public IP addresses, idle virtual machines, and abandoned storage accounts, described in that document as consuming budget without business value.

The address clock deserves separate attention because it is the one most people have never priced. AWS charges $0.005 per public IPv4 address per hour, at the same rate whether the address is in use or idle, metered in one-second increments with a sixty-second minimum. The arithmetic over an average month:

Two properties of that table are worth fixing in memory. First, the idle rate equals the in-use rate, so releasing an address you are not using saves exactly what keeping it costs - there is no penalty tier to reason about, only a flat charge with no off state. Second, the number is small per unit and large per pattern. Four hundred and thirty-eight dollars a year is not a crisis; forty-three addresses, which is an ordinary number in an account with a decade of history, is four thousand three hundred and eighty. By comparison, AWS's own worked example prices six in-use and four idle addresses at $36.00 per month, which is more than many small production instances cost.

There is a related trap on the bandwidth side, and it is worth naming here because it is the same mistake in a different dimension. A plan that advertises unmetered traffic has not removed its limit; it has moved the limit from the invoice to the port, the shared uplink behind it, and a fair-use clause. A 10 Mbps unmetered instance transfers less in a month than a metered plan with 20 TB included, which is covered in detail in how unmetered bandwidth is a different meter rather than an absent one. The persistence counters and the port caps are the same species of hidden charge: both are limits that leave the part of the contract buyers actually read.

The generalisation is that persistence is per-product and unbounded in count, which makes it a hygiene problem rather than an architectural one. Storage volumes outlive the instances they were attached to. Snapshots outlive the volumes. Addresses outlive the instances. None of these send an email when the parent disappears.

The Stop/Start Tax Is Also a Data Tax

Everything above argues for stopping resources aggressively, and there is a real cost on the other side that belongs in the same decision.

On AWS, stopping and starting an instance migrates it to a new host. The instance keeps its private IPv4 address, but it receives a new public IPv4 address unless it has a secondary network interface or an associated Elastic IP. Data on instance store volumes is erased. The private address and any IPv6 address persist, and Elastic IP associations survive. If your DNS points at the instance's public address, or your allow-lists are keyed to it, a cost-saving shutdown is also a configuration change - and an unplanned one at 3 a.m., if the shutdown was automated.

So the honest rule is a two-part test rather than "stop everything idle". Stop a workload when two conditions both hold: the saving exceeds the floor and persistence charges the stop incurs, and nothing outside the instance depends on the identity it loses. A staging database reachable only over a private address passes both. A public API endpoint with hard-coded allow-lists passes neither, and should be resized or re-priced instead. That second case is really a pricing question rather than a scheduling one, and it belongs with the three prices a VPS advertises and the one it bills, where the entry price, the renewal price, and the effective price are separated.

Why the Waste Problem Survives Every Optimisation Round

It would be satisfying to conclude that the three clocks are a solved problem and that the people paying too much simply have not read the documentation. The evidence says otherwise, and the reason is that the clocks are not the only source of unplanned spend.

Harness surveyed 700 engineering leaders and practitioners across five countries for its 2026 State of AI in FinOps report and found that organisations estimate 26 percent of all AI spend is wasted, consistently across infrastructure, software, models, and services. In the same dataset, 67 percent of organisations spend more than $250,000 a month on AI and 20 percent have crossed a million; 72 percent have hit an unexpected bill in the past year; and 52 percent report no clear owner of AI cost, with accountability split across engineering, FinOps, finance, and IT.

The ownership gap is what makes the waste durable. On the same survey, 79 percent of organisations need a full day or longer to trace a cost spike back to its source, and roughly a third need a full week. A week of not knowing is a week of the meter running, which is the persistence problem from the previous section wearing a different hat: the charge continues while the explanation is assembled.

The spend is not only arriving through compute, either. Flexera's research published in November 2026 reports that only 31 percent of organisations have visibility into AI software, and cites EY's 2026 AI Pulse survey finding that 87 percent of organisations are piloting or deploying AI-built software internally, with 34 percent naming shadow IT as the biggest barrier to scaling it. Duplicate AI-generated tooling does not just duplicate licences; it duplicates token consumption, downstream data movement, and compute - which is to say it duplicates all three clocks at once, in accounts where nobody has a complete view.

There is a hardware-side version of the same story. TrendForce reported on October 30, 2026 that server DRAM contract prices continued to climb through the month with suppliers holding strong bargaining power, and repeated on November 4, 2026 that server DRAM contract prices are rising with gains varying by RDIMM capacity. Memory is the input that decides how many instances a given spend buys, so a rising input price makes every idle hour more expensive in absolute terms than the same idle hour cost a year ago. Waste compounds against a rising floor.

Reading Your Own Invoice as a Clock: Fifteen Minutes

The three clocks are all measurable from your own billing data, and the procedure does not require a cost-management platform.

1. Count your cycles, not your hours. Pull the usage records for one representative resource for one month and count how many distinct usage events it has. If that count multiplied by your provider's floor exceeds the resource's runtime, the floor is your dominant cost and the hourly rate is decoration.
2. Find the floor in writing. Read the lifecycle or billing documentation, not the pricing page, and write down two numbers: the increment and the per-cycle minimum. If either is absent, treat the meter as hourly, because that is the conservative assumption.
3. Test the reboot path. Take one non-production resource and reboot it instead of stopping and starting it. If nothing downstream breaks, the maintenance procedure was costing you a floor every time and can stop doing so.
4. Sweep the persistence counters. Query for unattached volumes, volumes whose parent instance no longer exists, snapshots older than your retention policy, and public addresses not associated with any resource. The four categories are the ones the benchmark documents name.
5. Price the sweep before deleting it. Multiply the count by the unit rate and by 730 hours. If the answer is under a dollar a month, the sweep is not worth the change window; if it is over ten, it is worth an afternoon.
6. Check whether your address is the identity. For every resource you plan to stop, confirm that nothing outside it depends on a public address that will change. If something does, the stop is a configuration change disguised as a saving.

Run those six steps once and you will know which of the three clocks is charging you. The distribution is not uniform: compute-heavy teams usually find the floor, storage-heavy teams find the persistence counters, and short-job teams find the increment. Very few find that the headline rate was the problem.

Where Fine-Grained Metering Stops Mattering

There is a shape of workload for which all of this analysis collapses to a single line, and it is the shape most production systems have: a service that runs continuously and is meant to.

If a workload runs 24 hours a day, every day, then the increment is irrelevant because there are no fractional periods to round; the floor is irrelevant because one cycle covers the month; and the only clock that matters is the rate times the hours. That is the arithmetic behind the tier table for a pay-as-you-go hourly plan, where the smallest tier at $0.05 per instance-hour works out to $36.50 for a 730-hour month at continuous load, and the largest at $0.49 per instance-hour works out to $357.70. Those are honest extrapolations of the published hourly rates, and they are also the reason a page that lists hourly prices will usually point you elsewhere for steady load: the same page states plainly that hourly billing is not discounted, and directs buyers who want savings to its monthly deals.

That is not a flaw in the product; it is the correct pricing for the shape it serves. Hourly metering exists to make intermittent and unpredictable workloads affordable, and it deliberately does not compete on price for continuous ones. The three clocks are what you are buying, and a plan that meters in hours with a thirty-second deploy is a plan whose clock matches a workload that starts and stops.

Where the mechanism becomes visible is the third clock. Pay-as-you-go cloud servers on the SurferCloud hourly plan price five tiers from $0.05 to $0.49 per instance-hour across 17 or more data centres, with 1 to 10,000 Mbps of bandwidth and unmetered traffic, dedicated CPU and dedicated bandwidth on every plan, and a Windows licence included at no extra cost. The persistence counter that this article warned about is partly defused on that page rather than left implicit: the system disk is free up to 40 GB, so the root volume does not add a storage clock on top of the compute clock, with the honest caveat that São Paulo and Dubai nodes free 20 GB instead of 40 GB. The constraints are published in the same footer as the prices - datacentre IPs with no replacement option, and port 25 blocked by default - which is the inverse of the problem this article opened with: here the terms you would otherwise discover by reading a lifecycle document are on the page you are already reading.

Which of the three clocks decides your bill is a workload question, not a provider question. A CI runner that executes eight-second steps is buying increments. A fleet that scales to zero nightly is buying floors. A storage-heavy service is buying persistence, and can buy almost none of it if the system disk is included and the volumes are swept. And a service that simply runs is buying hours, at which point the useful comparison is not the hourly rate at all, but the hourly-versus-monthly decision rule that decides which of the two meters you should be on.

FAQ

Is per-second billing always cheaper than per-hour billing? Not always, but it is never more expensive for the same work, and it is dramatically cheaper below the one-hour crossover. An eight-second job on a sixty-second floor costs 7.5 times what it computes; the same job on a one-hour increment costs 450 times. Above roughly an hour of runtime the difference falls under a few percent and the hourly rate takes over as the deciding variable.

Does a stopped instance really cost nothing? No. Stopping removes the instance usage and data transfer charges and leaves the storage charges, which are billed per volume rather than per instance. Public addresses are billed separately from the instance entirely, at the same rate whether they are in use or idle, so a released instance can leave an address that keeps charging.

Why does the floor matter more than the rate for short jobs? Because floors are additive per cycle while rates are multiplicative per hour. A hundred daily stop/start cycles earn a hundred minimum charges, which is 50 billed hours a month regardless of how little compute ran - 6.85 percent of an average month paid for powered-off time. No rate reduction can offset a charge that is levied on events rather than on time.

What is the cheapest change with the largest effect? Replacing stop-then-start with reboot where the workload permits it. A reboot starts no new billing period and therefore no new minimum, and it also avoids the host migration that changes the public address and erases instance store data. It converts a billed event and a configuration change into a restart.

How do I find resources that are billing without running? Query for the four categories the benchmark documents name - unattached disks, unused public addresses, idle virtual machines, and abandoned storage accounts - then price the result at your provider's unit rate before deleting anything. The count is usually larger than the cost, which is why the pricing step matters as much as the sweep.

Should I keep a pay-as-you-go server running around the clock? Only if you have done the multiplication and accepted it. On a metered hourly plan, continuous load is priced at the hourly rate times 730 hours, and the honest answer from the plans themselves is that hourly billing is not discounted - the savings sit in monthly commitments. Continuous work belongs on a monthly meter; intermittent work belongs on an hourly one.

The Clock You Should Read First

Cloud bills feel unpredictable because three of their four numbers are not the number anyone compares. The rate is visible, advertised, and negotiated. The increment, the floor, and the persistence counters are documented in separate places by separate teams, and each of them can dominate the invoice for a workload the other two barely touch.

The reason this matters more than it did a year ago is that the inputs are getting more expensive while the tolerance for waste is getting thinner. Server DRAM contract prices are still rising as of TrendForce's most recent bulletins, and the newest category of spend is arriving through channels that most organisations cannot even see, with 26 percent of AI spend estimated as wasted and under a third of organisations reporting visibility into the software generating it. A clock you cannot read is a clock you cannot argue with.

So read the clock, not the menu. Count your cycles before your hours, find the floor in the lifecycle document rather than the pricing page, and treat every stopped resource as a question about persistence rather than an answer about cost. The three clocks are all published, all measurable from your own usage records, and all cheaper to read than to discover.

If your workload starts and stops, the hourly plan's tiers and terms are the page where the clock is printed next to the price instead of in a footnote - starting at $0.05 per instance-hour, with the free system disk and the default port-25 block stated up front. If your workload simply runs, start with the peak-to-average ratio that decides your headroom bill instead, because that is the clock a steady service is actually paying.