Cloud bills rarely surprise anyone because a server cost more than expected. Server prices are on a public page and people read them. Bills surprise people because of the things that are metered but not visible: data leaving the platform, resources nobody deleted, and per-request charges that were rounding errors in testing and are not in production.
Two pricing models
Flat-rate. A stated monthly price for a stated machine, with a bandwidth allowance attached. You know the bill in advance. This is how Hetzner, Linode, DigitalOcean and UpCloud largely work. The trade-off is that idle capacity still costs full price.
Metered. Everything is a meter — compute time, provisioned storage, requests, and data transfer. This is how AWS, Google Cloud and Azure work. You pay for what you use, and you discover what you used afterwards.
Metered billing is not a trick; it is the honest model for elastic workloads. But it moves the cost estimate from the price page into your own head, and that is where estimates go wrong.
Egress: the line item that dominates
The single most common cause of a shocking bill is data transfer out of the platform. Traffic in is typically free. Traffic between zones and regions is usually charged. Traffic out to the internet is charged, and at scale it dominates everything else.
Three things make it worse than people expect:
- It is invisible during development. Your test suite moves megabytes. Production moves terabytes.
- It is charged per gigabyte with no natural ceiling. A compute instance has a maximum monthly cost. Egress does not.
- Chatty architectures multiply it. Microservices talking across zones can generate more internal transfer than user-facing traffic.
If your product serves media, backups, or large API responses, model egress before you model anything else. It is also the clearest advantage of flat-rate providers: a generous included allowance turns the scariest variable into a fixed one.
The resources that quietly keep charging
A predictable list, in rough order of how often they appear on a bill nobody expected:
- Unattached storage volumes. Deleting a server frequently does not delete its disk. The disk carries on billing.
- Snapshots and backups. Automatic, incremental, and accumulating for as long as the retention policy allows.
- Reserved public IP addresses. Most platforms charge for an address that is allocated but not attached — deliberately, to discourage hoarding.
- Load balancers and gateways. Hourly charges that continue whether or not anything is behind them.
- Managed database instances left running after a migration. Often the largest single item on the list.
- Log retention. Verbose logging is cheap per gigabyte and expensive per year.
None of these are traps. They are all resources that exist because someone created them. But they survive the thing they were created for, which is why a quarterly sweep of what exists — against what is actually in use — pays for itself.
Burstable instances and the performance cliff
A billing-adjacent surprise worth knowing. Burstable instance types give a baseline fraction of a CPU plus credits earned while idle. Run sustained load and the credits deplete; performance then drops to the baseline, which can be a fraction of what you benchmarked.
Some platforms let you exceed the baseline anyway and bill for the surplus. That mode turns a performance problem into a cost problem silently. If you use burstable types, know which mode you are in. See what vCPU actually means for the mechanics.
Keeping it predictable
- Budget alerts on day one. Free, and they convert a month-end shock into a same-week question.
- Tag everything. A bill you cannot break down by project is a bill you cannot act on.
- Model egress explicitly. Estimate gigabytes out per month before launch, not after.
- Commit once the baseline is stable. Reserved and committed-use pricing is a large discount for capacity you were going to buy anyway.
- Sweep for orphans quarterly. Unattached disks, idle addresses, forgotten snapshots.
- Or take the model out of play. If predictability is worth more than optimality, flat-rate pricing is a legitimate answer rather than a compromise.
Every configuration in the catalog is listed with its price, and the comparison view puts the ranges next to each other — which is the easy half. The hard half is the meters, and those live on the provider’s side.