Most cloud estimates are wrong in the same direction, because they count the servers and stop. A defensible estimate takes about an hour and needs four inputs.
The four inputs
- Compute: how many instances, of what size, running how many hours a month. Non-production environments count.
- Storage: block volumes at provisioned size, object storage at expected volume with a growth rate, plus snapshots and their retention.
- Traffic out: average response size × requests per month, plus a multiplier for retries, prefetch and bots.
- Managed services: the database, the load balancer, the queue, the DNS zone, the certificate manager, the logging pipeline. Each has its own meter.
The third input is the one people leave out, and on a public site it is often the largest. See egress and bandwidth charges.
What is consistently forgotten
- Non-production environments. A staging environment that mirrors production doubles the compute line unless it is scheduled off.
- NAT gateways and their per-gigabyte processing charge, on platforms that have them.
- Snapshots accumulating under a schedule with no retention limit.
- Log ingestion and retention, which is metered by volume on most managed logging services.
- Inter-zone traffic from replicated databases.
- Support plans, which are a paid add-on on several platforms.
- Backups stored off-platform, which cost egress every time they are written.
Estimate against both billing models
Run the same numbers against a metered hyperscaler and against a flat-rate provider. For a small, traffic-heavy, steady workload the flat-rate answer is frequently much lower and much more predictable. For a spiky workload that is idle most of the time, metering wins. The estimate is what tells you which situation you are in — not a preference for one kind of provider.
The comparison pages set out the structural differences between providers for exactly this decision.
Produce a range, not a number
Give three figures: a low case with the traffic assumption halved, an expected case, and a high case with traffic doubled and one unplanned environment added. A single number will be wrong and will be quoted back to you; a range communicates what is actually known.
Validate in month one
Set a budget alert at the expected figure before you deploy. The first month then tells you whether the model was right, while the workload is still small enough to change cheaply. Compare the actual bill line by line against the estimate — the line that is most wrong is the assumption worth revisiting.
Where to go next
- On-demand, reserved and spot
- Cutting cloud costs without downtime
- Browse cloud accounts — each listing states its configuration and price
Questions
Frequently asked
What is most often missing from a cloud cost estimate?
Outbound traffic, and non-production environments. Both are easy to overlook and both can be the largest line on the final bill.
Should I estimate with a calculator or from experience?
Use the provider's calculator for unit prices and your own numbers for volumes. The volumes are where estimates go wrong, not the unit prices.
How accurate should a first estimate be?
Aim for a defensible range rather than a number. Halve and double the traffic assumption to produce a low and high case, and validate against the first real invoice.