Een geruisloze wijziging in het Amazon Web Services (AWS) catalogus heeft opnieuw de aandacht gevestigd op een onaangename realiteit voor vele bedrijven: de infrastructuur voor AI is niet alleen schaars, maar wordt ook steeds duurder om te plannen. Verschillende gespecialiseerde media melden dat AWS de prijs van haar EC2 Capacity Blocks for ML (reserveringsblokken voor machine learning workloads) met ongeveer 15% zou hebben verhoogd, vooral voor geavanceerde instances gebaseerd op NVIDIA H200-technologie.
Volgens deze berichten zou de p5e.48xlarge — configuratie met 8 NVIDIA H200 GPU’s — zijn gestegen van $34,61 naar $39,80 per uur in de meeste regio’s, terwijl de p5en.48xlarge van $36,18 naar $41,61 per uur zou zijn gegaan. Als deze verandering zich langdurig doorzet, is de impact niet gering: bij intensieve trainings- of inferentieprojecten kan een stijging van 15% het budget voor een heel kwartaal beïnvloeden, vooral voor teams met krappe marges of verplichtingen qua capaciteit bij mijlpalen.
Wat wordt precies duurder: GPU-reserveringen, niet alleen “GPU-gebruik”
De kern ligt in het product dat getroffen wordt: Capacity Blocks for ML zijn niet de klassieke on-demand diensten, maar een mechanisme om GPU-capaciteit vooraf te reserveren met een planningsvenster. Dit is bedoeld om het “geen voorraad” probleem te voorkomen bij kritieke momenten zoals lange trainingen, pieken in inferentie, lanceringen of grootschalige tests. AWS presenteert deze blokken als een manier om GPU-instances vooraf te reserveren met vaste periodes, variërend van korte tot langere verplichtingen, om zekerheid te bieden in dynamische vraagomgevingen waar capaciteitsschaarste een reëel risico is.
Tegelijkertijd maakt AWS duidelijk dat de prijzen van deze blokken kunnen worden aangepast. In hun openbare prijzingsdocumenten staat dat tarieven geregeld worden (en worden weergegeven als een combinatie van reservation fee en operating system fee), een belangrijk nuancepunt dat aangeeft dat prijsaanpassingen normaal zijn zonder dat er een officiële persbericht nodig is.
Waarom is het in 2026 vooral pijnlijk: het “premium tier” van AI is geen optionele keuze meer
De relevante factor is niet alleen het percentage, maar ook het soort instantie. De P5e en P5en-families zijn uitgegroeid tot referenties voor high-end AI workloads. AWS positioneert ze als infrastructuur voor het trainen en inzetten van LLM’s en generatieve modellen, met configuraties die tot wel 8 H200 GPU’s per instance omvatten en een focus op prestaties, netwerken en schaalbaarheid in clusters (UltraClusters). Dit is niet langer “laboratoriummateriaal”: het vormt de basis van veel commerciële producten.
Bovendien onderscheidt AWS P5e en P5en in belangrijke aspecten voor gedistribueerde prestaties. Volgens hun eigen productbeschrijving wordt de P5en aangeduid met verbeteringen in platform (CPU, connectiviteit en latentie) die gericht zijn op het optimaliseren van gedistribueerde training en communicatie. Met andere woorden: je betaalt niet alleen voor de GPU, maar voor het hele ecosysteem dat knelpunten voorkomt bij het trainen van grote modellen in parallel.
Het pijnpunt: de prijs kan bewegen op het moment dat je het het meest nodig hebt
De grootste bron van irritatie binnen de community — en die de toon zet van “hopelijk heb je het niet door” — is niet dat er pricing power bestaat, maar hoe verandering wordt waargenomen: prijsaanpassingen in het weekend, door derden opgemerkte variaties en het gevoel van gebrek aan transparantie. In markten met zoveel concentratie vreest de klant dat de provider de prijs verhoogt terwijl het project “vastzit”: getrainde modellen, pipelines, dependencias met managed services, data in een specifiek ecosysteem en strakke deadlines.
Hier treedt een patroon naar voren dat steeds meer in de sector wordt besproken: AI creëert een “toegangsprijs” per capaciteit. Niet alleen door verbruik, maar ook door gegarandeerde beschikbaarheid. En wanneer er wordt gestreden om dezelfde energie, ruimte en toeleveringsketen, waarden hyperscalers deze kosten meer door naar de producten waar de vraag minder elastisch is.
Wat moeten bedrijven vanaf nu in de gaten houden
- Scheiding van kosten per uur en kosten per resultaat: in AI is het cruciaal om te kijken naar de kosten per voltooide training, per miljoen inferentie-tokens of per bruikbaar experiment. Een stijging van 15% is wellicht acceptabel als het risico op geen capaciteit krijgen wordt verminderd, maar kan desastreus zijn voor projecten die al overgefinancierd zijn.
- Herzien van de strategie “reserveren versus elasticiteit”: Capacity Blocks bieden rust, maar brengen ook afhankelijkheid mee van de prijs van de provider bij het reserveren. In onzekerheidssituaties kan het zinvol zijn om minimale reserves te combineren met elasticiteit (of multi-provider opties).
- Voortdurende prijscontrole: omdat prijzen kunnen veranderen, moet de governance worden aangepast. FinOps wordt dan niet alleen een dashboard, maar een proces met alerts, dynamische budgetten, limieten en alternatieve scenario’s.
- Vergelijken met andere opties: zoals vergelijkbare instances van andere hyperscalers, bare metal-oplossingen of capacity-ovspraken met regionale providers. Het is niet altijd goedkoper, maar kan wel voorspelbaarder zijn.
Veelgestelde vragen
Wat zijn de EC2 Capacity Blocks for ML en hoe verschillen ze van on-demand?
Het zijn capaciteitspassen waarmee je GPU-instances vooraf kunt reserveren voor machine learning workloads. In tegenstelling tot on-demand verminderen ze het risico dat capaciteit niet beschikbaar is wanneer dat nodig is.
Welke GPU’s gebruiken de instances p5e.48xlarge en p5en.48xlarge?
AWS meldt dat P5e en P5en gebaseerd zijn op NVIDIA H200 en dat deze configuraties kunnen oplopen tot 8 GPU H200 per instance.
Betekent een prijsverhoging voor Capacity Blocks dat de prijzen voor andere GPU-instances ook stijgen?
Niet noodzakelijk. Capacity Blocks zijn specifiek voor reservatie en capaciteitsgarantie. Echter, in een gespannen markt kunnen prijsaanpassingen indirect doorwerken naar andere prijsniveaus afhankelijk van de vraagontwikkeling.
Hoe kunnen projecten de impact van prijsstijgingen beperken?
Door het gebruik van FinOps-praktijken (alerts, dynamische budgetten, resultaatgerichte metrics), het optimaliseren van efficiëntie (batching, quantization, betere pipelines) en martkstrategieen zoals multi-regie, multi-provider of alternatieve contracten.