Methodology

Where the prices come from

Public, documented pricing APIs — the same ones the vendors publish for exactly this purpose. Google Cloud's Cloud Billing Catalog API exposes every SKU with its tiered rates and service regions, and Google states plainly that all use of the Cloud Billing APIs is free of charge. AWS publishes a Price List API and its own price-change files; Azure's Retail Prices API needs no authentication at all.

We do not scrape pricing pages, and we do not use any customer's billing data to build the public corpus. Prices here are list prices — what a vendor publishes, not what any particular account pays.

How a snapshot works

A scheduled job walks every service and every SKU once a day, writes the complete result to object storage as compressed NDJSON, and batch-loads it into one date-partitioned table. Three properties matter:

• Idempotent by date. Re-running a day overwrites that day's partition. A retried job cannot double-count.
• Fails loudly. A run that collects far fewer SKUs than a full catalogue aborts instead of loading. A partial snapshot that looks complete would poison every future diff with false “new” and “removed” entries.
• Keeps the raw payload. The full pricing object is stored alongside the flattened columns, so when the diff engine gets smarter we can re-run it over the entire archive instead of re-collecting history that no longer exists.

How a change is detected

Each day is compared against the previous one, SKU by SKU. Three outcomes are recorded: new SKU, removed SKU, and price change.

The comparison is over the entire pricing expression, not the headline rate. Vendors restructure tiers without moving the first-tier price: a free allowance shrinks, a volume break moves, a commitment term changes. Those are exactly the changes nobody else notices, so comparing only the headline number would miss them silently. Where the tier count changes, the changelog entry says so.

What the percentages mean

• A SKU's 7/30/90/365-day change compares the price in effect today with the price in effect that many days ago — not the average over the window.
• SKUs that did not exist at the start of a window are excluded from movement rankings rather than counted as an infinite rise. They appear in the changelog as new SKUs.
• A service roll-up is the mean across that service's moving SKUs, so one dramatic outlier does not make a service look like it repriced everything.
• Charts use step-after interpolation. A list price holds until it is changed, so a sloped line between two snapshots would assert a gradual drift that never happened.

How the cross-cloud comparison works

A list price is not a measurement until you say what it measures. $0.0475 per N2 Instance Core hour and $0.192 per m5.xlarge Instance Hour look like the same kind of number and are not: the first is one core, the second is a bundle of four cores and 16 GB of memory. So the comparison normalises before it compares, in one of two ways.

• Direct — where both vendors publish the same unit, the unit prices are compared once the geography matches. Object storage and block storage per GB-month, egress per GB, a Kubernetes control plane per hour, serverless invocations per million.
• Composed — where they sell different things, a like-for-like configuration is assembled. Google prices a machine's cores and its memory as separate SKUs, so a 4 vCPU / 16 GB machine is 4 × core rate + 16 × memory rate for one series, in one geography, under one pricing model. AWS prices the bundle, so the same shape is the hourly rate of the instance type whose specification is 4 vCPU and 16 GB.

Shapes are matched exactly. A near-miss configuration scaled to fit would produce a number indistinguishable from a real one, so where nothing qualifies the page says so instead of estimating. Every comparison lists the SKUs it was built from, each linking to its own price history — the working is on the page, not behind a tooltip.

Two pivots are mandatory rather than optional. Prices are compared within a geography, because intercontinental spreads are larger than the gaps between vendors and an un-bucketed table reports whatever region mix happened to be in the corpus. And within a pricing model — on-demand, spot, or committed — because pooling them flatters whichever vendor discounts hardest.

Some line items are deliberately absent. Load balancers and NAT gateways are billed in different units by each vendor; object-storage operations are quoted per different batch sizes; and nothing is ever compared across the cloud and AI catalogues, because a SKU billed per thousand characters and a model billed per thousand tokens have no honest exchange rate between them.

What this does not cover

Committed-use discounts, enterprise agreements, private pricing, sustained-use discounts, marketplace credits, support plans and negotiated rates. If your effective rate differs from the list rate — and for most organisations of any size it does — this corpus tells you the direction and size of the vendor's move, not your invoice.

Currency is USD. The catalogue returns USD for the overwhelming majority of SKUs; non-USD billing accounts are an open question we would rather leave visible than quietly paper over.

Corrections

If something here is wrong, we would rather know: admin@costticker.com. Every SKU page shows its identifiers so a correction can name exactly what it is about.

Using the data

The changelog is free, and so are the RSS and JSON feeds and the read endpoints under /api. Cite us with a link; that is the whole licence. Prices are factual data, collected from each vendor's own public APIs. Cost Ticker is not affiliated with, endorsed by, or sponsored by Google, Amazon or Microsoft.