Guides

How to read a cloud bill on Azure, AWS and Google Cloud

Updated 27 Oct 2026

An estimate tells you what something should cost. The bill tells you what it did cost. Comparing the two each month is the simplest way to catch mistakes early: a forgotten test VM, logs nobody reads, or data moving between regions.

Where to find your costs

Where to look Detailed export
Azure Cost Management + Billing → Cost analysis Scheduled exports to a storage account
AWS Billing and Cost Management → Cost Explorer Data Exports (formerly Cost and Usage Report) to S3
Google Cloud Billing → Reports Billing export to BigQuery

The dashboards are fine for a monthly look. Set up the detailed export early (it only collects data from the day you switch it on), so you have history when you need to investigate.

Anatomy of a bill line

Every cloud breaks the bill into lines with roughly the same fields, under different names:

Field What it means Azure name AWS name Google name
Service The product Service name Product / service Service
Meter The specific thing being charged Meter Usage type SKU
Region Where it ran Region / location Region (also in the usage type) Location
Quantity and unit How much was used Quantity, unit of measure Usage amount, unit Usage amount, unit
Rate Price per unit Unit price Rate Unit price
Cost Quantity × rate, after discounts Cost Cost Cost

The meter is the important field. One service often has many: AWS IoT Core shows separate lines for messages, connectivity, rules triggered and actions executed. These are the same meters our pricing data matches, which is why our compare pages list each component separately.

Comparing the bill with an estimate

  1. Group the bill by service and meter for one month.
  2. Divide cost by quantity to check the rate. If it doesn’t match the list price, you have a discount, a different tier, or a different region.
  3. Compare quantities with your assumptions. If the bill shows twice the messages you expected, check how devices batch their data (see message size and batching).
  4. List anything that isn’t in the estimate. That’s usually where the surprises are.

Our estimator shows each cloud’s breakdown by component, so you can line it up against these groups directly.

Common surprises

  • Data transfer. Traffic out to the internet, between regions, and on some clouds between zones, is charged per GB. It’s left out of most estimates, including ours.
  • Logs and monitoring. Verbose application logs and metrics can cost more than the service they describe. Set retention periods.
  • Idle resources. Test clusters, unattached disks, old snapshots and stopped-but-not-deleted resources that still bill for storage.
  • Public IP addresses. Clouds now charge for public IPv4 addresses, including ones that aren’t in use.
  • Minimum footprints. Clusters with a minimum node count (see time-series database costs) bill fully even when quiet.
  • NAT gateways and load balancers, which charge per hour and per GB processed.
  • Taxes. GST in India or VAT elsewhere appears on the invoice but not in cost dashboards or estimates.

Keeping it under control

  • Tag everything with at least the site, environment and owner, so costs can be split by factory or team.
  • Set budgets and alerts at 50%, 80% and 100% of the expected monthly spend. They’re free on all three clouds.
  • Review monthly, not quarterly. Most waste is easiest to fix in the first few weeks.
  • Check commitments (reservations, savings plans) once usage is stable. On-demand prices, which we compare, are the most you should pay.

See the cloud billing glossary for any unfamiliar terms.