What if the biggest line on your 2027 cloud bill was decided by an architecture choice you made this quarter, long before anyone negotiated the price? That’s exactly how GPU workloads behave. The sticker price per GPU-hour gets all the attention, but the bill is shaped by decisions made much earlier: which GPU generation you standardize on, how your instances talk to each other, where you run them, and how you buy the capacity. Get those wrong, and a cheaper list price can still produce a more expensive year. (Graphics Processing Unit (GPU))
This piece walks through how AWS, Azure, and Google Cloud structure their GPU offerings, why the three models are not interchangeable, and which architecture decisions deserve attention now if 2027 costs matter to you. Treat the forward-looking parts as planning guidance, not confirmed prices. GPU pricing moves fast, and any specific 2027 number should be verified against provider pages before it lands in a budget.
Why GPU Pricing Is Really an Architecture Problem
Most teams compare GPU pricing the way they compare hotel rooms: same night, same city, different rates. Cloud GPUs don’t work like that. A workload that fits comfortably on one instance family may not fit at all on another, and a workload that scales well on one interconnect can lose half its throughput on another. When efficiency drops, you pay for GPU-hours that produce nothing.
Three levers drive most of the variance:
- GPU generation and memory. Older accelerators cost less per hour but may need more hours, or more of them, to finish the same job. A smaller GPU that fits the model can beat a larger one that sits half idle.
- Interconnect. Multi-GPU training depends on how fast the cards exchange data. The gap between a tightly coupled fabric and a plain PCIe layout shows up as scaling efficiency, and scaling efficiency shows up as cost.
- Region and capacity availability. The same instance type can be scarce in one region and plentiful in another. Scarcity pushes teams toward on-demand pricing when they wanted commitments, or toward interruptions when they wanted stability.
There’s a fourth lever that surprises people: data movement. Storage and egress charges can quietly rival compute costs in data-heavy pipelines, and they don’t appear in any per-GPU-hour comparison. That’s why a serious comparison has to go beyond list prices.
How AWS Structures GPU Capacity
AWS splits its accelerator lineup by workload. The P-series targets training and high-performance computing, while the G-series targets inference and graphics. The P5 instance, an eight-GPU NVIDIA H100 machine, arrived in 2023 and became the reference point for large training jobs.
The more interesting architectural shift came at re:Invent 2023, when AWS introduced capacity blocks for ML: reservable GPU capacity for a defined future window, separate from both on-demand instances and long-term commitments. For 2027 planning, this matters because it decouples “I need guaranteed GPUs next quarter” from “I need to sign a multi-year deal.” Teams that previously over-committed just to secure capacity now have a middle path.
On the purchasing side, AWS Savings Plans are spend commitments rather than instance-specific reservations. That flexibility is genuinely useful when GPU generations turn over quickly, because a commitment tied to a specific instance family can become an anchor if that family stops being the right fit.
How Azure Organizes GPU Virtual Machines
Azure’s GPU line splits into three families with different jobs. The NC series covers general GPU compute and training, the ND series targets large-scale deep learning, and the NV series handles visualization and inference. The ND H100 v5 family reached general availability in 2023 and anchors Azure’s large training tier.
The architectural detail that catches teams out is that Azure’s reserved instances and savings plans are scoped to virtual machines. That scoping is a feature when your workload is stable and a constraint when it isn’t. If a team reserves ND-series capacity and then discovers a smaller GPU fits the inference workload better, the reservation doesn’t follow them.
Azure’s strength for many enterprises isn’t the GPU itself but the surrounding estate: identity, governance, and networking that already exist. When GPU workloads live next to the rest of the corporate footprint, the integration savings can outweigh a per-hour difference. That’s an architecture argument, not a pricing one, and it deserves weight in the comparison.
How Google Cloud Positions Its Accelerators
Google Cloud’s lineup pairs the A3 family, including A3 High with eight H100 GPUs and A3 Mega, against large training workloads, while the G2 family with L4 GPUs serves inference and graphics. A3 reached general availability in 2023.
Google’s distinctive pricing mechanic is the combination of committed use discounts with sustained use discounts that apply automatically as usage crosses thresholds within a month. The automatic discount is architecturally significant: it rewards steady, predictable consumption without requiring anyone to forecast and sign. Teams with spiky GPU usage get less from it, but teams running continuous inference benefit without procurement work.
The Three Pricing Models Side by Side
The structural differences matter more than the numbers, because the numbers change and the structures persist.
| Dimension | AWS | Azure | Google Cloud |
|---|---|---|---|
| Training tier | P-series (P4d, P4de, P5) | ND series (e.g., ND H100 v5) | A3 family (A3 High, A3 Mega) |
| Inference tier | G-series (G4dn, G5, G6) | NC and NV series | G2 family (L4 GPUs) |
| Commitment mechanic | Savings Plans (spend-based) | Reserved instances and savings plans (VM-scoped) | Committed use discounts plus automatic sustained use discounts |
| Short-term capacity product | Capacity blocks for ML | Spot VMs | Spot VMs |
| Interruptible option | Spot Instances | Spot VMs | Spot VMs |
Read that table as a map of trade-offs, not a ranking. A spend-based commitment suits an organization whose GPU mix will shift. A VM-scoped reservation suits one with a fixed, well-understood workload. Automatic discounts suit teams that can’t predict usage precisely and don’t want to try.
Interruptible Capacity: The Checkpointing Tax
All three providers sell spare GPU capacity at a discount, and all three can take it back. AWS Spot, Azure Spot VMs, and Google Spot VMs all carry eviction risk, and the eviction policies differ in detail. The architecture decision hiding here is checkpointing: if a training job can’t resume from a recent checkpoint, spot capacity is a gamble rather than a saving.
In practice, teams that do well with spot treat checkpoint frequency as a cost parameter. Checkpoint too rarely and you lose work on eviction; checkpoint too often and you spend GPU time writing state instead of computing. The right interval depends on job length and eviction rates in your region, and it’s worth measuring rather than guessing. For a broader view of how these trade-offs play out across the big three, see this comparison of AWS vs Azure vs Google Cloud in 2026.
Where the Real Savings Hide
List price is the least interesting variable, because every provider will discount to win a large commitment. The savings that persist come from architecture.
Match the GPU to the workload, not to the benchmark. Inference workloads often run happily on smaller GPUs with less memory. Training workloads need the big cards and the fast interconnect. Standardizing everything on the largest available instance is the most common and most expensive mistake in GPU cloud planning.
Measure scaling efficiency before you scale out. Doubling the number of GPUs rarely doubles throughput. If interconnect or data loading becomes the bottleneck, the second batch of GPUs adds cost without adding capacity. Run a short scaling test before committing to a large cluster.
Watch the data path. Storage and egress charges accumulate quietly. Pipelines that move training data across regions, or ship model artifacts between environments, pay for that movement every time. Keeping data close to compute is an architecture decision with a price tag.
Track costs across providers if you run more than one. Multi-cloud GPU estates get messy fast, and a shared metrics approach helps; this guide to multi-cloud metrics across AWS, Azure, and Google Cloud covers what to instrument. The same discipline applies to managing cloud costs and stopping overspend, which is where most GPU budget leaks actually get fixed.
Building a 2027-Ready GPU Plan
A practical sequence looks like this:
- Classify every GPU workload as training, fine-tuning, inference, or graphics. Each has a different best-fit instance family and a different tolerance for interruption.
- Benchmark on your own model, not on published throughput numbers. Vendor benchmarks rarely match real pipelines with real data loaders.
- Test scaling at two and four times your current cluster size. Record where efficiency drops. That’s your practical ceiling.
- Choose a commitment shape that matches your uncertainty. If your GPU mix will change, prefer spend-based commitments over VM-scoped reservations.
- Set a checkpoint policy for any spot usage and measure eviction rates in your chosen regions before relying on discounted capacity.
- Re-verify prices quarterly. GPU pricing and instance availability change too often for annual reviews.
For teams spreading workloads across providers, a structured multi-cloud framework for running workloads across AWS, Azure, and Google helps keep the architecture consistent even when the pricing models aren’t.
One caution worth stating plainly: nobody can confirm 2027 GPU prices today. New accelerator generations, regional capacity shifts, and changed discount terms will all move the numbers. Any article or vendor deck quoting specific 2027 rates is projecting, not reporting. Build the architecture so that whichever way prices move, your workloads are already on the right shape of instance.
Conclusion
The AWS vs Azure vs Google Cloud GPU pricing question has a boring answer and an interesting one. The boring answer is that list prices are close enough that discounts decide most deals. The interesting answer is that architecture decides the bill: which GPU generation you standardize on, whether your interconnect scales, where your data sits, and how your commitments are shaped. Teams that get those four decisions right will pay less in 2027 regardless of which provider wins the price war, because efficiency compounds while discounts expire.
Frequently Asked Questions
Which cloud provider has the cheapest GPU instances?
There’s no stable answer, because prices change and the cheapest option depends on the workload. A GPU that’s cheapest per hour can be the most expensive per completed job if it’s the wrong size or lacks fast interconnect. Compare total cost for your own benchmark, not list price per GPU-hour.
Are spot or preemptible GPUs safe for training?
They’re safe if your job can resume from checkpoints. All three providers can reclaim spot capacity with limited notice, so any training run without recent checkpoints risks losing work. Measure eviction rates in your region and set a checkpoint interval that balances lost work against writing overhead.
What are AWS capacity blocks for ML?
They’re reservable GPU capacity for a defined future window, introduced in 2023. They sit between on-demand instances and long-term commitments, which makes them useful when you need guaranteed GPUs for a specific period without signing a multi-year deal.
Do Google Cloud’s automatic discounts apply to GPU usage?
Google’s sustained use discounts apply automatically as usage crosses monthly thresholds, and committed use discounts require a commitment. The exact treatment of GPU spend under each discount type should be confirmed against current billing documentation, since terms change.
Is a VM-scoped reservation risky for GPU workloads?
It can be. Azure’s reserved instances and savings plans are scoped to virtual machines, so a reservation doesn’t follow you if a different instance family turns out to fit better. That’s fine for stable workloads and awkward for teams still experimenting with GPU sizing.
How often should GPU pricing assumptions be rechecked?
Quarterly is a reasonable rhythm for most teams. GPU instance availability, discount terms, and new accelerator generations change often enough that annual reviews leave stale assumptions in the budget. Re-run your benchmark whenever you re-verify prices.
