AWS Raised GPU Prices Twice in 2026: What to Do About It

AWS Raised GPU Prices Twice in 2026: What to Do About It#

Cloud compute prices go down. That has been the reliable direction for long enough that most capacity plans assume it implicitly. GPU capacity broke the pattern this year: AWS raised EC2 Capacity Blocks for ML by roughly 15% in January, then by roughly 20% again on 1 July for the P5, P5e, P5en and P4de families. Current Capacity Block rates put P6-B300 at about $14.04 per accelerator-hour and P6-B200 at about $12.355. If you budgeted accelerator spend in late 2025 and have not revisited it, your plan is wrong by a wide margin.

What actually drove it#

The increases are not a pricing experiment. They track the same component shortage that is repricing ordinary server memory, and accelerators are the sharp end of it. High-bandwidth memory sits on the accelerator package, and HBM is exactly what memory manufacturers have been redirecting fab capacity toward because it earns multiples of what conventional DDR5 earns. The result is that the scarce input is not the GPU die, it is the memory stacked next to it.

That matters for how you plan, because it means the increase does not behave like a demand spike that eases when the current wave of model training finishes. We wrote up the broader supply picture in what the RAM shortage does to your cloud bill; the short version is that provider guidance points at 2028 before prices stabilize, not next quarter.

Why Capacity Blocks took the hit first#

Capacity Blocks are the product where AWS sells scarcity directly. You reserve a defined block of accelerators for a defined window, with the guarantee that they will be there. When supply tightens, that guarantee is the thing that gets more expensive, because it is the thing customers are actually buying.

On-demand GPU instances did not move identically, which produces an odd situation worth checking against your own usage: for some workloads the gap between reserving capacity and taking your chances on demand narrowed enough that the reservation stopped paying for itself. That is a calculation to run with your real utilization numbers rather than a rule of thumb, because it turns entirely on how much of the reserved window you actually keep busy.

# Utilization on a block you are already paying for.
# If the p50 here is under ~70%, the reservation is subsidising idle time.
$ aws cloudwatch get-metric-statistics \
    --namespace AWS/EC2 --metric-name GPUUtilization \
    --dimensions Name=InstanceId,Value=i-0abc123 \
    --start-time "$(date -u -d '30 days ago' +%Y-%m-%dT%H:%M:%SZ)" \
    --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
    --period 3600 --statistics Average

The comparison that matters is not AWS against AWS#

The practical effect of two increases in one year is that the spread between AWS and the specialist GPU clouds widened. Hourly rates for the same class of accelerator already varied by a factor of around three across providers before this year, and the gap moved in the specialists' favour. We keep the detailed numbers in the GPU cloud comparison.

The reason teams stay on AWS anyway is usually not the accelerator price. It is data gravity, egress, the VPC the rest of the system lives in, and compliance boundaries that are genuinely expensive to move. Those reasons remain valid. What changed is the size of the premium you are paying for them, which means the answer deserves a fresh calculation rather than the one you did in 2024.

Two distinctions do most of the work:

Training is portable. Inference usually is not. A training run is a batch job with a dataset and a checkpoint. Moving it to a cheaper provider costs a data transfer and some pipeline work, and it runs on someone else's hardware without the rest of your architecture noticing. Production inference sits behind your API, inside your network, next to your feature store, and moving it is a real migration.

Reserved capacity is a bet on your own forecast. At current prices, committing to a block you fill 60% of the time is worse than paying on demand or renting elsewhere for the peaks. Our notes on when reserved, savings plans and spot each pay apply directly, with the caveat that the break-even utilization moved up as the prices rose.

What to do about committed capacity#

If you hold Capacity Blocks that renew in the next two quarters, the sequence that works is: measure real utilization per block, split the workload into training and inference, price the training half at two specialist providers, and only then decide what to renew. Teams that do this in the other order, renewing first and optimizing later, end up paying the higher rate for capacity they have already proved they do not fill.

For spiky training demand specifically, interruptible capacity is worth revisiting even if you dismissed it before, because the price gap it exploits got wider. Checkpoint discipline is the whole game there, and our guide to spot instances covers the patterns that make interruption survivable.

The decision, concretely#

• Holding Capacity Blocks with average utilization under about 70%? Do not renew at the new rate. Either consolidate workloads onto fewer blocks or move the flexible half off them.
• Running training jobs that touch nothing but a bucket and a checkpoint? Price them elsewhere this quarter. This is the portable half of the workload and the spread is now large enough to be worth the pipeline work.
• Running production inference inside an AWS-native architecture? Stay, and optimise utilization instead. The migration cost will not clear the price gap for most teams.
• Budgeting accelerator spend for 2027? Model flat-to-rising, not the historical decline. Two increases in one year on a supply-constrained component is a trend, not noise.

The call we'd make#

Split the workload before you shop. Nearly every team we have seen react to these increases either moved nothing, because inference was clearly stuck, or tried to move everything, because training was clearly portable, and both answers leave money on the table. Move the batch work where it is cheap, keep the latency-sensitive work where your data already lives, and raise your utilization floor before you sign anything for another year.