GPU Regions, Availability and Price: Why the Same Card Costs Different Amounts
The same GPU can carry a different price, different availability, and different egress rules in every region a provider runs. This guide explains why, how to read the trade-offs, and how to design a workload that can move when the region you wanted sells out.
All figures in this guide are illustrative examples for education. Real GPU prices, cloud rates and throughput vary by provider, region, model and time. Confirm current numbers with a provider before budgeting. The point here is the method; plug in your own numbers.
On this page
Why the same card has several prices
A GPU in a data centre costs the provider the same to buy wherever it is installed. What differs by region is everything around it: electricity, land and building costs, cooling needs, local taxes, network costs, and above all the balance of supply and demand in that region. A region with many customers near a large tech hub tends to be fully booked and priced accordingly; a newer region with spare capacity may be cheaper and emptier.
Some providers publish one price and let availability vary; others vary the price itself. Spot prices in particular move with regional demand, so the cheapest region for spot on Monday may not be the cheapest on Friday. Our provider directory links to the pages where current regional pricing is published.
Availability is the real constraint
For in-demand GPU types, the problem is often not price but whether you can get one at all. Capacity errors (“no instances of this type available in this zone”) are a normal part of life during periods of high demand. Three things determine how badly this affects you:
- How specific your request is. One GPU type in one zone is the most likely request to fail. Several acceptable types across several zones rarely all fail at once.
- How long you need the machine. Short jobs can wait for a gap; long jobs need a reservation or a resumable design that can migrate.
- Whether you have a reservation. Reserved or committed capacity guarantees the machine; everything else is best-effort.
The trade-offs of a farther region
| Factor | Nearby, popular region | Farther, quieter region |
|---|---|---|
| Price | Often higher, especially spot | Often lower |
| Availability | Frequently constrained | Usually better |
| Latency to your users | Low | Higher; matters for real-time serving, not for training |
| Data transfer | Data may already be there | Moving data in costs time; moving results out may cost egress |
| Compliance | May be required for regulated data | May be prohibited for regulated data |
For training and batch work, latency to users is irrelevant and the farther region often wins outright, provided the dataset can be staged there once. For real-time serving, the region is chosen by where the users are, and the price difference is a secondary consideration.
Designing for mobility
- Keep data in a form that can be copied. Datasets in object storage with a documented layout can be replicated to another region in hours. Data on a single instance’s disk cannot.
- Make jobs resumable. A checkpointed job can be stopped in one region and restarted in another. See checkpointing for spot instances; the same design serves regional moves.
- Script the environment. If starting a job in a new region takes a day of manual set-up, you will not move. If it takes a command, you will.
- Accept several GPU types. Code that runs on more than one card can use whichever is available.
- Keep a list of fallback regions in order of preference, with the egress and compliance notes already worked out, so the decision during an outage is mechanical.
Compliance and data residency
Some data must stay within a jurisdiction. Personal data of residents of certain countries, health records, financial records and government work commonly carry residency requirements. If your training data or your users’ requests fall into those categories, the region is chosen by the lawyer before the engineer, and the cheaper region across a border is not an option however good its price. Settle this question first; it removes regions from the list before any cost comparison begins.
A worked example
Illustrative: a team needs 200 GPU-hours for a fine-tune on a public dataset of about 300 GB. Their usual region has the card at $3.20 per hour but shows no capacity for the next several days. A region two time zones away has the same card at $2.60 and available now. Moving the dataset costs about an hour of transfer time and, in this illustration, no egress because the source is already in the provider’s object storage with free inter-region replication for that service. The run costs $520 instead of $640 and starts today instead of next week. The result, a few gigabytes of weights, is copied back for a small egress charge.
Had the dataset been private medical data with a residency requirement, none of this would have been possible, and the right answer would have been a reservation in the required region. Both answers are correct; what differs is the constraint.