# Data sources

> The first-party price feeds GPUQuant reads: the AWS EC2 Price List archive, the Azure Retail Prices API, the Google Cloud Billing Catalog and the Oracle price list, with what each one can and cannot tell you.

Updated 2026-09-06. Canonical: https://gpuquant.com/docs/data-sources

Every hyperscaler price is read from a first-party feed, 4 of them, all reached directly. No aggregator sits between GPUQuant and the provider, because a number that cannot be traced to a primary source cannot be defended.

The feeds differ more than they look. One archives its full price list every month, one answers historical questions a calendar month at a time, and two publish only what is true today. That asymmetry shapes the whole product, and it is why provider coverage of any given month is uneven. Each source below carries the ways it misleads a naive reader; every one of them cost a day.

## Amazon Web Services (EC2 Price List bulk files)

AWS publishes the complete EC2 price list as public, unauthenticated bulk files, and keeps every historical version. That archive is what gives GPUQuant a genuine multi-year AWS series rather than a series that starts today.

Each version carries an effective date. GPUQuant takes one version per calendar month, the latest published in that month, so the monthly series has exactly one AWS point per month by construction. Files are read region by region and streamed rather than buffered: a single current region file is around 290 MB, and the global file is several gigabytes and never fetched.

> **The GPU column is a count, not a vendor**
>
> g4ad is AMD, inf2 is Inferentia and trn1 is Trainium, all with a non-zero GPU count. Without an explicit allowlist, non-NVIDIA silicon lands in an NVIDIA benchmark.

> **Duplicate rows, some priced at zero**
>
> AWS ships more than one row for the same instance, operating system and tenancy, and some are $0.0000. Taking the first match silently produces a free GPU. Zero rows are dropped and the highest remaining rate is kept.

> **The column set changes by era**
>
> The schema grows from 61 columns in 2015 to 93 today. A filter on a column that does not exist yet matches nothing, which looks identical to a source with no GPU data. Filters are applied only where the column is present.

[Provider documentation](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/price-changes.html)

## Microsoft Azure (Azure Retail Prices API)

The Azure Retail Prices API is public and needs no subscription, account or key. It returns the current price of every meter, paginated. GPUQuant keeps consumption-type records for VM sizes on an explicit NVIDIA list, excluding Windows, Spot, Low Priority and dedicated hosts.

**Azure publishes no price history at all.** There is no version index and no historical endpoint. That is a permanent limitation, not a gap to be filled: the Azure series begins with the first GPUQuant snapshot and grows one month at a time from there. Nothing earlier can be recovered, and nothing earlier is invented.

> **Filtering is case sensitive and fails silently**
>
> A region filter of EastUS returns zero rows with no error; eastus returns the data. A typo looks exactly like an empty result.

> **effectiveStartDate is not a time series**
>
> It records when the current price took effect. It says something useful about how long a standing price has held, but stringing those dates together would not produce a history, so GPUQuant shows it as metadata and never as a chart point.

> **Linux has no positive marker**
>
> Windows rows are identifiable by product name; Linux is everything that is left. The filter has to work by exclusion.

[Provider documentation](https://learn.microsoft.com/en-us/rest/api/cost-management/retail-prices/azure-retail-prices)

## Google Cloud (Cloud Billing Catalog API)

The Cloud Billing Catalog API returns every Compute Engine SKU, and accepts a plain API key restricted to the Billing API. Historical pricing works through a start and end time, provided the window sits inside a single calendar month, so a multi-year backfill is one request set per month.

Google is the only provider here that prices accelerators as their own SKUs, separate from the vCPU and memory of the machine they attach to. That makes the accelerator price easy to read and easy to misuse: on its own it is not the price of renting the machine. GPUQuant rebuilds the complete machine price from its published components before dividing by GPU count, as set out under [the Google Cloud rebuild](https://gpuquant.com/docs/normalization#google).

> **On-demand includes several discounted products**
>
> Dynamic Workload Scheduler, Calendar mode and Reserved rows all carry usageType OnDemand, at roughly half list price, and some at zero. Trusting the usage type alone understates Google Cloud by around half.

> **Newer SKUs dropped the word Nvidia**
>
> The H200 accelerator is described as “H200 141GB GPU”, with no vendor name. A filter looking for “Nvidia” silently loses it, and the GPU looks absent from Google Cloud when it is not.

> **A historical window must not cross a month boundary**
>
> A window spanning two calendar months returns an error rather than a merged result.

[Provider documentation](https://docs.cloud.google.com/billing/docs/reference/rest/v1/services.skus/list)

## Oracle Cloud Infrastructure (OCI Cost Estimator price list)

Oracle publishes one current price list with a single lastUpdated date and no archive of any kind, so the Oracle series can only accumulate forward from the first GPUQuant reading.

It is structurally unlike the other three. Oracle already prices per GPU-hour and bills its bare-metal GPU shapes as a whole shape, with no separate OCPU or memory SKU for any GPU family, and $10.00 multiplied by eight reconciles to the documented $80 per hour of BM.GPU.H100.8. The published figure is therefore already a complete per-GPU number and GPUQuant does not divide it.

> **The price list carries no region at all**
>
> The other three publish a row per region, and GPUQuant treats “the provider published a price that applies here” as the availability signal. Oracle publishes one price and states separately that it offers every service in every public region at uniform pricing. The same signal exists, split across two documents rather than carried on one row.

> **Every Oracle region is inferred, never verified**
>
> Because the region comes from that statement rather than from a price row, every Oracle observation is recorded as inferred. What this does not claim is shape-level capacity at a moment, which no cloud publishes and which GPUQuant has never asserted for any provider.

[Provider documentation](https://apexapps.oracle.com/pls/apex/cetools/api/v1/products/?currencyCode=USD)

## What the asymmetry means

Because some providers can be backfilled and some cannot, a step in the reference price is not always a price move. Check the provider count in the tooltip, and see [coverage changes](https://gpuquant.com/docs/history#coverage-changes) for how the charts mark a month where the provider set changed.

## The neocloud sources

The specialist GPU clouds are read the same way, each from its own published price page or API, and each is listed with its source, its normalization and its caveats under [the neocloud index](https://gpuquant.com/docs/neocloud-index#providers). None of them publishes a price archive; their history is Internet Archive captures parsed by the same code as the live page.