What “Pay As You Go” Actually Means

Every cloud provider describes its pricing as pay as you go, and every one of
them means something slightly different by it. The phrase is accurate in the
sense that you are not signing a fixed contract. It is misleading in the sense
that it implies you pay only for what you actively use, which is not how most of
it works.

You pay for allocation, not utilisation

This is the distinction that matters most, and it is the one the phrase
obscures. A virtual machine bills for existing, not for working. An instance
sitting at two percent CPU costs exactly what the same instance costs at ninety
percent. You are renting the allocation, not the work done inside it.

The same applies to a provisioned disk, a reserved IP address, a load
balancer and a managed database. All of them bill for being available. Genuine
usage-based billing, where idle really does mean free, exists mainly in
serverless products and in object storage request charges.

Granularity varies, and it is a real difference

Some providers bill compute per second, some per hour, some per month with no
sub-monthly proration at all. For steady production workloads this barely
matters, because the server runs all month either way. For development and
experimentation it matters quite a lot.

If you spin a machine up for twenty minutes to test something, per-second
billing charges you for twenty minutes, hourly billing charges you for an hour,
and monthly billing may charge you for a month. Someone who creates and destroys
test environments frequently will notice the difference; someone running three
permanent servers will not. DigitalOcean’s per-second billing is a genuine
advantage for the first kind of user, which is covered in its
provider guide.

What is actually metered

A typical deployment is metered along several axes at once, and the pricing
page you read probably described only the first:

• Compute time, by instance size, for as long as the instance
  exists.
• Storage capacity, by provisioned size rather than used
  size. A hundred gigabyte volume with two gigabytes on it bills for a hundred.
• Storage operations, on object storage, where requests
  themselves carry a small charge that only becomes visible at high volume.
• Outbound data transfer, by volume, sometimes with an
  included allowance.
• Addresses and endpoints, where a reserved IP not attached
  to anything is often charged specifically because it is idle.
• Managed service overhead, such as the control plane fee on
  managed Kubernetes, which is charged regardless of what you run on it.

The parts that are not pay as you go at all

Several common charges are fixed regardless of usage. Support plans are
typically a monthly fee or a percentage of spend. Reserved capacity bills
whether used or not, by definition. Some managed services have a minimum
duration, so creating and immediately destroying one still costs something.

None of this is hidden. It is simply not what most people picture when they
read the phrase.

A more accurate mental model

Think of it as renting rather than metering. You are renting a set of
resources by the second, hour or month. The rent is due for as long as you hold
them, whether or not you are using them, and it stops when you give them back
properly. Most unexpectedly large bills are the result of holding something you
had stopped thinking about.

That framing also tells you where the savings are. They are not in using your
servers more efficiently, at least not at first. They are in not holding
resources you have no use for. Deleting an idle volume saves more than tuning
the application running beside it.

Flat pricing is the honest alternative

Several providers sell servers at a flat monthly price with a bundled
transfer allowance and no per-request meters. You lose fine granularity and the
ability to pay nothing for a machine you ran for ten minutes. You gain an
invoice you can predict exactly, which for a small team is often worth more than
the theoretical optimisation.

Neither model is better in the abstract. The question is whether your usage
actually varies. If it genuinely does, metered pricing rewards you for that. If
it does not, you are paying the complexity cost of a flexibility you never
use.