GPU capacity planning changed on June 1, 2025. AWS announced up to a 45 percent price reduction for EC2 NVIDIA GPU-accelerated instances covering the P4 and P5 families, effective on On-Demand purchases and extended to Savings Plans days later. The P5 H100 on-demand rate dropped 44 percent, the deepest on-demand cut in the published table. For engineering teams in Portugal and the wider EU, the reduction cuts both ways: reserved H100-class compute is materially cheaper, and every capacity budget built on the old price list is stale. The demand side is not in question. 13.5 percent of EU enterprises with 10 or more employees used AI technologies in 2024, up from 8.0 percent in 2023, so pressure on accelerated capacity is structural rather than cyclical. This guide covers what the new pricing changes, how reservation mechanics behave, and which calculations EU teams should re-run this quarter.
What the price cut changes
The reduction is a deliberate supply-and-demand lever. AWS framed it against a market where growth in GPU demand has outpaced industry-wide supply, and applied it across every region where the affected families are sold. The published reduction table is uneven, and that unevenness is the useful signal: the newest, most contested silicon got the deepest cut. The H100-backed P5 family received 44 percent off on-demand rates, while the older A100-backed P4 families received 33 percent and the H200-backed P5en received 25 percent. When a hyperscaler discounts its flagship accelerator hardest, it is pricing to keep large training workloads from drifting to neocloud competitors — and that same discount is your negotiating baseline with every other vendor.
| Instance family | Accelerator | On-demand reduction |
|---|---|---|
| P4d | A100 | 33% |
| P4de | A100 | 33% |
| P5 | H100 | 44% |
| P5en | H200 | 25% |
The second-order effect matters more than the sticker price. Savings Plans and committed-use math all pivot off the new baseline, so a reservation modeled six months ago now overstates cost by a third or more. Teams that deferred self-hosting because per-GPU-hour economics looked hostile should rerun the comparison against a managed API bill using the new rates before renewing anything. If you are still framing the build-versus-buy decision itself, our earlier breakdown of vLLM versus TGI serving throughput covers the software side of the same equation.
How reservation mechanics work
Price is only half of capacity planning; the other half is whether you can actually get the GPUs on the date your training run starts. That is what EC2 Capacity Blocks exist for. Under this purchase model, you can reserve accelerated instances up to eight weeks in advance, in cluster sizes of one to 64 instances — 512 GPUs — for durations of up to six months, with the instances colocated in UltraClusters that provide the low-latency, high-throughput networking distributed training depends on. Reservations can be shared across multiple AWS accounts, which matters for platform teams serving several product groups from one capacity pool.
The mechanics impose a planning discipline that on-demand never demanded. Eight weeks of lead time means your experiment calendar becomes a procurement input: a fine-tuning run scheduled for November needs its block reserved by late September. The one-to-64 instance granularity also forces an honest sizing exercise, because over-reserving a block wastes the exact capacity the reservation was meant to guarantee. Treat the block calendar as part of the ML platform roadmap, not an afterthought owned by finance.
A practical reservation checklist
Use this sequence when you move a workload from on-demand experimentation to reserved capacity:
- Measure 30 days of real inference or training demand from logs — token volume, GPU-hours, and utilization — never from peak estimates.
- Rerun the managed-API versus self-hosted break-even with the new 44 percent-reduced P5 rates before committing to either side.
- Size the block to sustained need, not worst-case need; one to 64 instances is a wide range and idle reserved GPUs are pure waste.
- Book the reservation at least eight weeks before the run date, sharing it across accounts if several teams draw from the same pool.
- Place a parallel spot or on-demand pool outside the block for burst traffic, so experiments never cannibalize reserved capacity.
- Re-audit the price list quarterly; the June 2025 cut proves these rates move faster than annual budget cycles.
Region reality for EU teams
Portuguese and EU buyers should read the fine print of the announcement before assuming the discount lands in their preferred region. The at-scale on-demand expansion that accompanied the price cut added P4d capacity in Europe (London) — but the new P5 on-demand availability went to Asia Pacific and South America regions, not the EU. In practice this means an EU-resident P5 reservation may need to tolerate processing in a US or APAC region, which pulls data-residency analysis into the decision for anything touching personal or regulated data. For workloads where residency is binding, the pragmatic split is P4d in Europe (London) for data-bound jobs and P5 elsewhere for pure training throughput. The adoption context for this constraint is documented in our analysis of EU cloud AI adoption numbers: demand is compounding while the EU capacity map stays thinner than the US one.
Cost scenarios worth modeling
Three scenarios capture most real decisions after the cut. First, the deferred self-hoster: a team whose break-even math failed by 30 to 40 percent last year may now clear it, because the H100 hourly baseline fell by 44 percent while managed API prices did not move in step. Second, the renewal trap: an existing 3-year Savings Plan signed at pre-cut rates is now paying a premium over fresh on-demand pricing — model the early-exit arithmetic before auto-renewing. Third, the burst workload: if utilization sits below roughly half, discounted hourly rates still lose to per-token APIs, reservation or not, because idle GPU time bills at full rate. Run all three against your measured traffic, not vendor benchmarks.