Research-backed calculator guide
GPU Cloud Region and Availability Matrix: Price Is Useless If the GPU Cannot Be Provisioned
A practical GPU cloud availability by region method for separating listed hardware, approval-gated capacity, and verified deployability before you compare price.
Quick answer
GPU cloud availability by region is not one fact. It is a chain of checks: the provider lists the GPU family, the specific region and zone support the SKU, your account has quota or approval, and capacity is actually provisionable when you need it. A price page usually proves only that a provider has published a rate. It does not prove that an H100, H200, or multi-GPU shape can be launched in your account today.
Use three labels in your comparison: listed, approval required, and verified deployable. “Listed” means a first-party catalogue or matrix names the model and location. “Approval required” means the provider flags limited capacity, restricted access, a reservation process, or an account-team gate. “Verified deployable” means you tested the exact GPU shape, region or zone, tenancy mode, quota, and image or networking requirements with the relevant console, API, or provider confirmation. Keep the evidence date beside every label because capacity changes faster than a guide can be revised.
Google’s GPU location table is a good example of why the distinction matters. It maps GPU machine types to zones, but separately identifies limited-capacity H100 configurations that require contact with an account team. [1] CoreWeave makes a similar distinction: its instance matrix shows where an instance type is deployed, not current availability, and actual provisioning depends on capacity and quota. [4] Those are not exceptions to the rule; they are the rule for expensive accelerators.
What “available” should mean
A region is not a checkbox. Define the claim before you collect it. For a single-GPU inference endpoint, you may need one H100 PCIe in a supported zone, a compatible image, persistent storage, network access, and enough quota. For a training job, you may need eight or more identical GPUs, a topology that supports the required interconnect, a reservation window, and permission to use a restricted SKU. “H100 cloud availability by region” can therefore produce a different answer for one GPU than for an eight-GPU cluster.
The first state is listed. This is the weakest positive signal. It can come from a region matrix, instance catalogue, provider product page, or API documentation. It is useful for narrowing the search, but it is not a launch promise. AWS’s accelerated-instance documentation, for example, is a detailed catalogue of families such as P4, P5, and newer P6 shapes. [2] It tells you what the service supports as instance types, not whether your account can obtain a particular shape in every region at this moment.
The second state is approval required. Treat words such as limited, dedicated, reserved, waitlist, contact sales, or account-team approval as a different state from ordinary listing. Google’s documentation explicitly says some H100 locations have limited capacity and require account-team contact. [1] A dedicated-access zone can also be intentionally unavailable to ordinary customers. CoreWeave distinguishes General Access zones, which are available to customers subject to capacity, from Dedicated Access zones reserved for select customers. [4]
The third state is verified deployable. Record the exact evidence: a successful dry run, a provider API response showing stock, a reservation confirmation, or written confirmation tied to your account and requested shape. A provider’s public page can help you find candidates, but it rarely supplies all of those fields. RunPod advertises more than 30 GPU models across 31 regions, and its FAQ directs readers to the dashboard or API for the latest availability. [5] That is a useful catalogue-level signal, not a substitute for the launch check.
A practical GPU cloud regions and zones comparison
Start with the workload, not the cheapest hourly number. Write down the GPU model, memory requirement, number of GPUs, interconnect requirement, expected run window, data-residency constraint, and whether interruption is acceptable. Then evaluate candidate regions in this order:
- Geography and compliance. Remove locations that cannot host the data or violate your latency target. A nearby region can reduce network delay, but it may have less inventory.
- Exact SKU and topology. “H100” is not enough. Distinguish H100 SXM, H100 PCIe, H100 NVL, and the number of GPUs per VM or node. Azure’s ND-H100-v5 documentation describes an eight-H100 VM with 1,900 GiB of memory and 3.2 Tbps of interconnect bandwidth. [3] That is a materially different product from one standalone H100.
- Zone and access mode. A region may contain several zones with different GPU sets. Check whether the row is standard, AI-specific, general access, dedicated, or restricted.
- Quota and approval. Ask whether the account is allowed to request the shape and whether quota is sufficient for the requested count. A quota increase does not create physical capacity.
- Live provisioning. Attempt the smallest representative launch or use the provider’s capacity endpoint. For a cluster, verify the full shape rather than proving that one GPU can start.
- Operational dependencies. Confirm image support, storage placement, networking, egress, driver versions, and failure recovery in the same region. Lambda states that each instance is tied to a geographical region and that not every instance type is available in every region. [6]
Keep provider evidence separate from your own observation. A provider quote is a vendor statement about price or access terms. A successful launch is an observation about your account at a particular time. Neither one should be silently converted into a permanent availability claim.
Original availability matrix
The table below is an original decision aid. The rows are illustrative, not a live inventory report. “Listed” and “approval required” describe evidence states, while “verified deployable” requires a fresh check for your account. This is the visual demonstration for the guide because it makes the inputs and output inspectable without pretending that a screenshot is live capacity.
| Candidate evidence | GPU request | Region/zone evidence | Access state | Verification action | Decision output |
|---|---|---|---|---|---|
| First-party matrix names the GPU and zone | 1 × H100 | Exact zone is listed | Listed | Check quota, then launch a small test | Keep as candidate, not yet committed |
| First-party page flags limited capacity | 1 × H100 | Exact zone is listed but restricted | Approval required | Obtain account-team approval or reservation | Hold until written approval exists |
| Provider matrix names a multi-GPU shape | 8 × H100 | Region is listed; topology is described | Listed | Test the complete eight-GPU shape and network | Do not price as usable until test passes |
| Console/API returns capacity for the exact shape | 8 × H100 | Exact zone and image pass validation | Verified deployable | Record timestamp, quota, and expiry or reservation | Eligible for cost comparison |
| Catalogue names the GPU but no zone or API result exists | 1 × H200 | Broad region claim only | Unknown | Find zone-level documentation and run a live check | Exclude from final shortlist for now |
This structure also prevents a common error in a GPU provider capacity by region comparison: treating the number of advertised locations as the number of locations where your exact workload can run. A region count can be a useful discovery metric. It is not a capacity guarantee.
Worked cost example
Assume a team needs eight H100-class GPUs for a 30-day inference benchmark. The requested shape must be available in one zone, and the team wants a warm deployment for 24 hours per day. The following rate is an illustrative planning input, not a vendor quote and not a claim about any provider’s current price:
- GPU count: 8
- Hours per month: 30 × 24 = 720
- Illustrative compute rate: $3.99 per GPU-hour
- Reserve for restart, failed placement, and short validation runs: 5%
- Storage, egress, support, taxes, and host-level premiums: excluded
Base compute is:
8 GPUs × 720 hours × $3.99/GPU-hour = $22,982.40 per month
The planning reserve is:
$22,982.40 × 5% = $1,149.12
So the planning total is:
$22,982.40 + $1,149.12 = $24,131.52 per month
That number is useful only after the eight-GPU shape is verified. If the provider lists the GPU but the shape is approval-gated, the correct output is not “$24,131.52 available in region X.” It is “$24,131.52 if approval and capacity are confirmed.” If the launch fails because only four GPUs can be placed, recalculate the feasible design rather than treating the shortfall as a minor price variance.
You can also compare a fallback plan. Suppose a verified four-GPU shape can run two identical workers, but the application can tolerate a lower batch size. The same hourly assumption gives 4 × 720 × $3.99 = $11,491.20 for one four-GPU worker. Two workers cost $22,982.40 before the reserve, but their actual performance and operational risk may differ from one eight-GPU node. Compare throughput, failure recovery, storage movement, and latency, not only the arithmetic.
For a fuller ownership view, put GPU-hour assumptions into the Self-hosted GPU inference cost calculator. Use the Model pricing comparison when you are deciding whether rented GPU inference is cheaper than an API baseline. If retrieval is part of the workload, include the vector and embedding side with the RAG, embedding and vector database cost calculator. If the GPU is one component of a larger delivery, compare implementation scope with the AI agent development cost estimator.
Run your scenario
Turn this framework into an editable estimate.
Use dated, source-linked assumptions and see cost per request, successful task and month.
How to maintain the matrix
Give every row a checked date, source URL, exact model, exact region and zone, access state, quota state, and verification method. Record negative results carefully. “The API rejected this request on November 2” is evidence about that test. It is not proof that the provider never offers the GPU in that region. Likewise, “a console showed a deploy button” is not proof that an eight-GPU placement will succeed under peak demand.
For changing facts, prefer first-party tables and APIs over copied provider roundups. Google’s matrix is particularly useful because it exposes zone-level rows and a separate limited-availability section. [1] AWS’s catalogue is useful for identifying instance families before you look for regional placement. [2] Azure’s SKU page is useful for understanding the shape’s hardware and topology before you check the product-by-region listing. [3] CoreWeave’s documentation is useful for interpreting access classes and the warning that footprint is not current capacity. [4]
Do not combine prices from one region with availability evidence from another. Normalize billing units first: per GPU-hour, per VM-hour, per node-hour, per-second, reserved commitment, or spot. Then add storage, network transfer, support, taxes, and idle time where they apply. RunPod, for example, presents hourly display rates while explaining that compute is metered at a finer time unit and that current spot availability is shown in the UI/API. [5] Those are product-specific billing details, not a generic rule for every GPU provider.
If latency or residency matters, test the fallback before production. A two-region plan can be more resilient, but it may double warm capacity or introduce data-transfer costs. If a provider requires approval, ask whether approval covers a GPU family, a specific shape, a zone, a quantity, or a time window. Those are different permissions and should occupy different columns in your matrix.
FAQ
Is GPU availability by region the same as GPU pricing by region?
No. Pricing is a commercial input; availability is a provisioning outcome. A provider can publish an hourly rate for an H100 while your account lacks quota, the exact zone is restricted, or the requested multi-GPU shape has no capacity. Keep the price column and the evidence-state column separate.
How do I check H100 cloud availability by region?
First find the provider’s exact H100 SKU and zone matrix. Then check whether the row is standard or limited, whether approval or reservation is required, and whether your account has quota. Finally test the exact shape through the console or API and record the result with a timestamp. A provider-wide region list is only the first filter.
Does a listed GPU mean I can launch it now?
No. “Listed” means the provider documents the model and location. It does not prove current capacity, account eligibility, quota, or successful placement. Google and CoreWeave both document this distinction directly in their region guidance. [1] [4]
Where can I rent an H200 by region?
Use provider pages and official documentation to build a candidate list, then verify the exact H200 SKU, region, zone, access mode, and quantity in the provider’s current dashboard or API. Do not infer that a provider’s global H200 page means every listed region can provision the same shape. Record “unknown” until the exact test passes.
Should I choose the cheapest region for inference?
Only after the region passes your feasibility gates. A lower rate can be more expensive if it adds failed deployments, cross-region data movement, extra warm replicas, or unacceptable latency. Compare effective cost per successful, compliant deployment rather than the displayed GPU-hour alone.
How often should a GPU availability matrix be refreshed?
Refresh before a production reservation, after a model or region change, and whenever a launch fails unexpectedly. For volatile on-demand capacity, a daily or per-deployment check may be appropriate. Preserve historical rows so a later reader can distinguish a changed market from an inconsistent claim.
What is the difference between a region and a zone?
A region is a geographic area that can contain multiple zones; a zone is a more specific placement location. GPU models may differ between zones in one region. CoreWeave also uses regions and availability zones as separate scheduling concepts, and its documentation says CKS clusters are single-AZ. [4] Always record both when the provider exposes both.
Can a quota increase guarantee GPU capacity?
No. Quota controls what your account is allowed to request. Physical capacity controls what can be placed. You need both. Treat quota approval as a gate before live capacity verification, not as evidence that the GPU is reserved.
Primary sources checked
Pricing and product behavior can change. These sources support the time-sensitive claims in this guide; verify current provider terms before committing spend.