AWS-gebruikers schrikken van bug die factuurbedragen van miljarden dollars toont

Amazon Web Services heeft een storing waardoor het verkeerde factuurbedragen toont in de AWS Billing Console. De omvang van het probleem is onduidelijk, maar gebruikers melden dat ze kosten van honderdduizenden tot miljarden euro's zien en schrikken daar, niet heel verrassend, behoorlijk van.

AWS bevestigt dat op een ondersteuningspagina. Het probleem ontstond in de nacht van donderdag op vrijdag Nederlandse tijd en speelt nog steeds. AWS zegt het probleem nog te onderzoeken.

Veel details zijn er niet bekend over het probleem. Amazon zegt zelf dat er 'incorrecte factuurinformatie in de Billing and Cost Management Console' in AWS verschijnt.

Het gaat niet om een paar tientjes. Onder een bericht van de klantenservice op X schrijven sommige gebruikers dat ze honderdduizenden tot zelfs een biljoen dollar zien. Er staat dan ook bij hoe groot de stijging van die factuur is ten opzichte van eerder. Dan gaat het om een stijging van miljarden procenten.

Downtime

Dat stelt wellicht ook weer gerust, omdat zo'n stijging komisch absurd is. Toch lijken veel gebruikers er in ieder geval flink van te zijn geschrokken. Van de andere kant is de kans ook groot dat sommige organisaties direct belangrijke diensten hebben uitgeschakeld uit voorzorg, wat voor gemiste inkomsten en downtime kan leiden.

Het probleem zit overigens niet alleen in de AWS-console. Verschillende tweakers melden dat ze ook waarschuwingsmails hebben gekregen van Amazon. Een tweaker toont bijvoorbeeld een screenshot van zo'n mail waarin het maandbudget met twee miljard dollar zou zijn overschreden.

Reacties (83)

[JustVodka]

Ik heb er inderdaad ook een budget alert binnen gekregen van $44,729,241,960.69
Normaal zijn mijn kosten rond de $1.5 (s3 backup van zo'n 400gb aan data)

Wat ik erg jammer vind is dat je geen echt budget in kan stellen bij AWS, dat boven een bepaald plafond alles stopt. Je kan wel actions instellen waarbij je bijvoorbeeld AIM credentials kan disablen of bepaalde services kan stoppen, maar zeker niet alles. Geen NAT gateways of andere zaken stoppen.

Maar in dit geval als ik actions had bij mijn alerts... waren die dan ook ge-triggerd als ik die had?

[Ablaze]

Dat kan bij geen van deze cloudaanbieders en dat maakt het ook dubieus als je de services als consument gebruikt. Want in de EU mogen bedrijven je niet blootstellen aan een moeilijk voorzienbaar financieel risico.

[Scriptkid]

Hoezo is het niet voorzienbaar dan.

Je ziet en weet toch van tevoren de bandbreedte van de kosten.

En voor heel groot gebruik moet je een reservation doen en je policies zeggen dat je maar x per user mag toevoegen.

[Reactie gewijzigd door Scriptkid op 17 juli 2026 14:17]

[Ablaze]

Totdat je Google Maps API ineens een miljoen keer is aangeroepen zonder dat je weet waarom en je 5000 euro moet aftikken, of dat je webservice online door bots wordt aangevallen en je honderden euro's moet betalen alleen al voor de audit logging.
De kosten zijn elke maand anders en ze kunnen door allerlei externe factoren zomaar hoger worden.

Ja, je kunt hier wat aan doen. En nee, dat mag je niet zondermeer van een consument verwachten volgens de wet.

[baseoa]

Infinite scale takes infinite cost. Als je dat niet wilt, moet je niet infinite scale mogelijk maken.

Mijn server thuis (lees: vijftien jaar oude laptop en een externe harde schijf) zal vast sterven als mijn site op de reddit voorpagina komt maar het kost ook niks extra. Toen iemand bij Alibaba Cloud besloot zo'n tien miljoen pagina's van een van mijn sites binnen 36 uur te downloaden, heb ik niks gemerkt, noch qua kosten noch qua performance. Achter elke pagina zitten database queries, sommige best rekenintensief (O(n) over een miljoen rows), maar blijkbaar is het robuust genoeg, ook zonder bigtech-setup

Als bedrijf zul je ergens tussen mijn setup en AWS in willen zitten. Alsog is het een keuze waar je dan gaat zitten en welke resources je bezoekers mogen aanspreken

[Reactie gewijzigd door baseoa op 17 juli 2026 15:57]

[Scriptkid]

en dat is precies wat ik zeg je weet de band breedte min en max en kunt daar gewoon aan sleutelen.

In data bases kun je gewoon rate limits zetten zelfde op je web service etc.

Jouw auto kan met je gas pedaal ook ver over de 50km/h in de bebouwde kom maar je kan van de wet niet verwachten dat ze dat technische afdwingen.

[henk717]

Komt zelfs bij dat als je geen creditcard hebt je er uberhaupt niet door kan komen. Ik gebruik al die dure providers uit princiepe al niet maar kan er dus ook niet bekend mee worden als ik dat wil. Je moet en zou in het rood moeten kunnen staan want dat geld willen ze binnen harken.

Vergelijk dat met een normale provider en daar betaal je vooruit voor de dienst die je af gaat nemen. Er is geen enkele reden dat ze het niet op die manier kunnen bieden.

[arjankoole]

alle providers waar ik diensten afneem factureren achteraf hoor, niet vooraf.

Maar goed, ik doe alleen zaken met flat-fee. Ik wil geen onvoorspelbaar element.

[henk717]

Ik doe al sinds 2009 een gameserver en heb diverse VPS partijen gehad. Het is daar altijd vooraf. Nu huur ik ook AI docker containers bij partijen als runpod, vastai, en soort gelijke providers, ook daar is het vooraf. Web hosting is normaal vooraf, domeinen zijn vooraf, je online opslag abbonement is vooraf, etc.

Wel hebben die providers ofwel een vast bedrag per maand ofwel een optie om automatisch op te hogen. Bij automatische ophoging lijkt het meer op aws. Maar je hebt het wel in de hand en je kunt jezelf dus tegen kosten beschermen.

[HenkEisDS]

Zelfde bij Azure en Google. Je kunt budgetten opgeven, maar een killswitch voor als je boven die budgetten komt moet je zelf configureren.

[Bedge85]

Een eenvoudige killswitch is ook wel erg complex voor een provider als AWS. Goed om daarbij in het achterhoofd te houden dat AWS zich richt op de zakelijke markt. Een eerste vraag bij een killswitch is natuurlijk wat moet er dan worden afgesloten, is dat enkel compute. Moeten zaken als loadbalancer ook gedeprivisioned worden, dit kan veel tijd kosten om weeropnieuw op te zetten. En tot slot opslage en backup, moet dit ook maar worden verwijderd want de kosten hiervoor gaan ook gewoon door, en mogelijk wordt je budget overschrijden juist door storage veroorzaakt en niet door compute.

Dit zijn basale vragen, maar bij de daadwerkelijk implementatie van zo'n killswitch in een complex omgeving als AWS ga je enorm veel edge cases tegenkomen waar gewoon niet echt een goede keuze gemaakt kan worden.

Op het gebied van alarm ben ik het wel eens, de opties hiervoor zijn in AWS echt wel heel basaal en verdienen verbetering.

[A Lurker]

Ja en nee. Een harde limiet zet je natuurlijk niet halfhartig in op net iets boven je maandelijkse kosten, maar een factor 10 of meer erboven, puur om niet failliet te gaan in een maand tijd. Dat er dan bepaalde dingen keihard offline gehaald worden is balen maar als je failliet bent valt er niks meer te hosten in de toekomst.

Bovendien schalen opslag doorgaans niet een factor 10+ in de kosten zonder dat je het weet. De echte risicos zitten vaak in front-facing dingen als requests op je api of andersoortig misbruik van je platform. Of een enorme bug met een loop naar je database oid.

Maar onder de streep is hufterproofheid gewoon belangrijk, tuurlijk wil je rate limits, maar toch is een algehele bescherming ook heel fijn, net zoals een aardlekschakelaar dat ook is. Ik denk dat dit foutje mensen in ieder geval aan het denken zet.

[Reactie gewijzigd door A Lurker op 17 juli 2026 14:57]

[ProvideInRoot]

Ik ben hier ook wel bang voor, wat als de website die ik heb te maken krijgt met een ddos aanval?

Overigens zou een switch waarmee je aan kan geven dat de service non critical is en dus offline mag gaan best wel fijn zijn. Vooral voor consumenten die gewoon wat kleins hebben draaien.

[Reactie gewijzigd door ProvideInRoot op 17 juli 2026 16:59]

[supersnathan94]

Ik ben hier ook wel bang voor, wat als de website die ik heb te maken krijgt met een ddos aanval?

Maar je kunt wel een limiet instellen op scaling. Onbeperkt doorschalen wil je nooit. 2x peak usage aankunnen is voldoende toch?

Ook bij serverless kun je een maximum capacity aangeven.

Met cloudfront heb je trouwens ook AWS Shield Standard. Dus dat is dan ook gelijk DDOS protectie

[HenkEisDS]

Ik ben het met je eens dat het erg complex is en de scenarios die je schetst zijn zeker valide. Je wil niet zomaar alles deprovisionen.

Ik vind echter wel dat als een klant verantwoordelijk genoeg geacht wordt om ineens een 100K factuur te mogen ontvangen die klant toch ook wel zelf mag bepalen dat vanaf 10K overal de stekker eruit moet.

Vraag me af hoeveel mensen per jaar echt het schip ingaan door slecht geconfigureerde of misbruikte resources en wat er in de praktijk gebeurt met die mensen.

[sebastienbo]

Killswitch complex? Dat is hij helemaal niet complex, als je gekoppelde visa ontoerijkend is, dan stoppen ze toch ook je services?

Ik vraag mij zelf af of dat AWS mag grotere facturen opstellen dan wat de kaart aankan.
Stel dat je VISA 2500 euro per maand limiet heeft, dan weten kan je ze toch moeilijk 3500 proberen aan te rekenen?

Als dat idee klopt, dan kan je dat gebruiken als budget limiet: je maakt een visa kaart enkel voor AWS aan en zet daar een lage kaart limiet.

[Argantonis]

Betaalmanier en wat jouw bank als limiet stelt op je credit card heeft niks te maken met wat jij een bedrijf eventueel schuldig zou zijn.

[sebastienbo]

Dat is erg beangstigend.

Ik leesde wel dat je het een beetje veiliger kan maken via een management account die dan restrictions zet op je operations account.

AWS Organizations (SCPs)

[SherlockHolmes]

Dat is een deel van hun verdienmodel

[baseoa]

Iets meer dan "een deel". Dit is de fundamentele eigenschap waardoor ze de markt hebben overgenomen van traditionele hosting waar je vooraf kiest wat je nodig hebt, dat netjes afrekent, en niet onverwachte kosten maakt

Door alles heel klein te rekenen lijkt het spotgoedkoop. Je kun voor een prikkie instappen en wennen aan hoe alles werkt. De onverwachte factuur en zich afvragen waar je moet beginnen met snijden om dit terug te dringen is iets dat elke AWS-klant kent, toevallig...

[biteMark]

Nou, even flink doorsparen dan. Chop chop!

[Gallo_Claudio]

Wat ik me dus afvraag, in de USA zijn ze verschrikkelijk fel op fraude met facturen. Die vallen onder het kopje "mailfraude" en de straffen daarop zijn niet misselijk. Zou dit nu ook iets zijn wat onder die zelfde noemer zou vallen? Of zou de bedragen daarvoor te extreem zijn?

[JustVodka]

De kosten die AWS nu weer ga waren nog geen facturen. Maar voorlopige indicatie. Dus nee, dit zal nog niet onder fraude vallen.

[arjankoole]

Nee, waarschijnlijk niet. Bij mailfraude is er sprake van doelbewust proberen op te lichten. Hier is het overduidelijk een software fout en geeft Amazon ook toe het te onderzoeken als een storing.

Aan de andere kant, Amerika…

[oks]

Tja economische oorlogsvoering in vol effect: de betrouwbaarheid en gokken op 1 paard. We zien het verlies aan diversiteit in de ict wat voor gevolg dat heeft.

[therijn]

Als je een budget had, dan was door dit voorval je 400gb waarschijnlijk verdwenen. Dan was je deze backup waarschijnlijk kwijt...

[JustVodka]

Yup, dat is een goed punt. Al is dat voor mij in dit geval niet zo'n probleem:
Laptops -> NAS -> S3

Maar iets van rate-limiting voor de diverse services en api's zou fijn zijn. In dit geval was het een bug bij AWS zelf. Maar in theorie zou je ook een applicatie kunnen hebben die door een bug compleet te keer gaat op diverse dure api's of services.
In geval van S3 iets van limiting in de richting van hoe het werkt met network i/o of cpu zoals bij de burstable ec2 node types.In mijn geval zou ik met name graag een limiet willen hebben op het lezen van de data uit s3 vanwege de hoge kosten van het lezen van s3 glacier data.

Hoe dan ook. Graag middelen om kosten in bedwang te kunnen houden. Maar goed, dat is natuurlijk niet in het belang van AWS.

[Piemol]

Ben benieuwd of de gevolgen nog heel groot gaan zijn. Bijv. door automatisch onderbreken van services omdat klanten te veel in het rood zouden staan.

[Sircuri]

Ook gelukkig dat er geen "Betaal direct met iDEAL" knop op staat

[kujinshi]

Die zal zeggen dat je bank toch niet dat op de rekening heeft staan. En niks doen.

[BlaDeKke]

Betalen met Klarna

[Reactie gewijzigd door BlaDeKke op 17 juli 2026 13:14]

[MMaster23]

Moment, even mijn app dag limiet verhogen.

[baseoa]

Hah, zeg dat wel! Als je zo'n bedrag wilt overmaken is het niet meer daglimiet maar dag limiet xD

[Reactie gewijzigd door baseoa op 17 juli 2026 16:16]

[PolarWolf]

Automatische incasso m.b.v. een creditcard is vrij normaal bij dat soort services.

[baseoa]

Toevallig bij al die diensten waar je de uitzondering bent als je niet ooit een onverwachte factuurbedrag hebt gekregen. Heel normaal!

[R_Zwart]

Voor de echt grote klanten (waarvan de impact groot is als die uitvallen) werkt dat ongetwijfeld anders. Die hebben geen standaard contracten)

[egbertpot]

Ben me net he-le-maal kapot geschrokken van die mails van AWS... Ik was ervan overtuigd dat iemand op de een-of-andere manier bij een van m'n root-accounts / admin-accounts was gekomen.

Op alle accounts is MFA geconfigureerd m.b.v. een Yubikey (minimaal 2), dus ik begreep er niets van.

Heb uiteindelijk in blinde paniek m'n default VPC weggegooid met alles wat d'r in zat.

~30 minuten later was ik heel blij toen ik de de update las : https://us-east-1.console.aws.amazon.com/costmanagement/home?region=eu-north-1#/home ==> Operational issue - AWS Billing Console (Global)

Kan ondertussen weer ademhalen en weer beetje lachen.....

Voor iedereen die in de toekomst ook denkt dat zijn / haar account gehakt is. Misschien helpt dit stappenplan:


https://gist.github.com/egbertp/8c3cd61bdf04619a00f81825ec1fdfff

Mijn doel nu is om ervan te leren voor als het een keer _echt_ fout zit. Mijn les: het duurde te lang voordat ik een overzicht kon produceren van alle resources die onder mijn account actief zijn in AWS.

Alle feedback is welkom; zowel mijn response-plan in de Gist als op mijn paniek-reactie ;-)

[njitter]

Les 1 bij mogelijke problemen: geen paniek!

En zeker niet allerlei zaken wegooien voordat je een mogelijke oorzaak weet.

[RiDo78]

Precies, eerst eens kijken naar de significante getallen. Als je ineens een ton moet ophoesten maakt een paar 100 euro geen verschil meer. Natuurlijk kan ik niet in jouw portemonnee kijken, maar of ik nou 100.000 euro of 100.500 euro moet aftikken, dat is voor mij allebei niet mogelijk.

Dus dan kun je beter even kijken wat nu het probleem is.

[slijkie]

Niet lullig bedoeld, maar ging er geen lampje branden toen je een bedrag van een paar miljard zag staan? Ik zou direct weten dat het om een bug gaat. (Niet aanvallend ofzo hoor, gewoon een vraag)

[Evert de Wit]

Wellicht is een aantal miljard niet aannemelijk, maar 100.000 misschien wel; zeker als je bepaalde verhalen leest over AWS.

[NEK]

AWS Billion Console

[joyrider3774]

hoe gaan klanten er nu zeker van zijn dat het bedrag dat er staat, nadit gecorrigeerd wordt correct is ? services blijven draaien en rekenen verder aan met wsl verkeerde prijzen of zo dus hoe kan je er zeker van zijn dat dit correct gaat zijn ? Amazon moet vind ik alle prijzen terug draaien tot voor de moment dat het probleem zich stelde om dit te voorkomen en de kosten voor de overige duur op zich nemen zolang dit probleem zich stelde

[Htbaa]

Ik schrok ook wel even ja. Heb er alleen maar SES draaien voor een paar accountjes (nu niet meer) en dat is echt maar een paar cent per maand. Daar doet Amazon de moeite niet voor om dat in rekening te brengen. En zo ineens bijna $100.000,- aan verbruik. Het verbruik komt ook niet overeen met wat het budget dashboard aantoont. Maar wel een bizarre fout dit.

[PtrO]

Altijd al een rekening willen betalen van een paar miljard en nog beter, daarvoor met alle (r)egards aangemaand te worden.

Bekend gegeven is dat je beter €100M schuld kunt hebben dan €100 rood staan. In het eerste geval zal de schuldeiser haar uiterse best doen de schade te beperken tot €10M door je desnoods €1M extra krediet te geven. In het tweede geval je vervolgen en desnoods €1000 uitgeven om dat bedrag via een woekerproces te incasseren.

update: Nog even gechekt dat ik niet in de prijzen ben gevallen:
Estimated grand total: USD 1.64

[Reactie gewijzigd door PtrO op 17 juli 2026 13:05]

[RainOfAshes]

Nu zijn dit belachelijke bedragen, maar wat als het verschil minder opvallend is? Wat zijn ze aan het doen achter de schermen dat dit kan gebeuren?

[ctrl-tab]

Van mij krijgen ze ook nog 85 miljard blijkbaar.
Arme Jeff moet natuurlijk ook de rekeningen blijven betalen.

[GameNympho]

Kan je dan nu even een miljoentje overmaken naar een andere rekening?