Amazon: bug geautomatiseerd DNS-database zorgde voor kettingreactie AWS-storing

Amazon laat in een blogpost weten wat er op 19 oktober bij de clouddienst AWS fout ging, waardoor wereldwijd talloze websites en diensten offline waren. Een bug in de NoSQL-database DynamoDB zorgde voor een kettingreactie van problemen.

Het zou een probleem in de DNS-records van het datacenter US-East-1 geweest zijn. Op 19 oktober, lokaal midden in de nacht, bleek dat er een racecondition was ontstaan in het DynamoDB-database waardoor alle IP-adressen uit het DNS-record verdwenen. Hierdoor kregen gebruikers veel api-foutmeldingen te zien als zij met DynamoDB wilden verbinden.

De racecondition was het gevolg van een conflict tussen twee DNS-enactors. Deze geautomatiseerde systemen proberen het probleem op te lossen, maar het ene systeem maakt de oplossing van het andere ongedaan en vice versa. Specifiek werden er door de DNS-planner constant nieuwe plannen geproduceerd. De ene enactor registreerde dit met vertraging en paste het plan toe, terwijl de tweede het intussen verouderde plan verwijderde. Dit zorgde voor lege DNS-records.

Andere geautomatiseerde systemen zijn weer afhankelijk van DynamoDB. Onder meer het EC2-cloudcompute-ecosysteem en de Network Load Balancer functioneerden daardoor niet meer naar verwachting, waardoor ook deze systemen met opstapelende problemen te maken kregen. Het laatstgenoemde systeem constateerde daardoor veel fouten en verwijderde daardoor weer nodes, wat het hele enactorprobleem versterkte.

Verbeteringen

Amazon claimt dat er sinds de grote storing voorzorgsmaatregelen genomen zijn om deze problemen voortaan te voorkomen. Specifiek zou het bedrijf maatregelen genomen hebben om de omstandigheden waarin een racecondition kan ontstaan, te voorkomen. Verder is het EC2-systeem voortaan begrensd op basis van de wachtrij, zodat er bij een vertraagde werking geen opstapeling van verzoeken kan ontstaan. Het NLB-systeem heeft voortaan een beperking van de hoeveelheid capaciteit die het per gefaalde gezondheidscheck kan verwijderen.

Update, zaterdag: De functie van DynamoDB is toegelicht. Er stond foutief in het artikel dat het om een beheersysteem zou gaan.

Reacties (59)

[edwinjm]

Je kan wel redundante systemen hebben, maar DNS is globaal. Als het systeem dat DNS bijwerkt faalt, dan faalt alles.

Het systeem dat DNS bijwerkt, draait blijkbaar op us-east-1.

Korte samenvatting van wat er is gebeurd, zoals ik het begrijp:

Er is een systeem dat constant wijzigingen aanbrengt in DNS. Op een gegeven moment was die overbelast. Dit leidde ertoe dat een deel dat langer in de wacht stond DNS overschreef met verouderde gegevens. Een ander systeem dat steeds oude gegevens verwijderd, verwijderde deze verouderde gegevens. Nu was de DNS data helemaal verwijderd.

Lees Summary of the Amazon DynamoDB Service Disruption in Northern Virginia (US-EAST-1) Region

[ACM]

Jouw samenvatting is op zich wel correct, maar mist denk ik een belangrijk punt. Het ging om het interne DNS-beheer van het databasesysteem DynamoDB.

Ik heb hem zelf zo gelezen:

• DynamoDB is een belangrijk databasesysteem binnen AWS
• Dat systeem heeft een heel uitgebreide intern DNS-beheersysteem voor loadbalancing en self-healing
• Dat DNS-beheersysteem sloopte zichzelf door een race condition: Er was 1 proces begonnen een versie van de DNS-opzet uit te rollen, wat ongebruikelijk lang duurde. Ondertussen ging een 2e proces een veel nieuwere versie uitrollen. Daarbij ging de 1e door en was juist weer al het werk van de 2e ongedaan aan het maken. En zoals het 'hoort' gooide de 2e alle oude versies weg, waaronder de net door de 1e geactiveerde opzet. En toen waren er ineens helemaal geen DNS-records meer voor de DynamoDB-nodes.
• Het automatische beheer van EC2 (de 'servers') leunen weer op DynamoDB en faalde daardoor ook
• De Network Load Balancing leunt weer op EC2 en faalde daarmee dus ook

[Houtenklaas]

Geen kennis hiervan, maar is het nu zo dat het 2e proces niet had mogen beginnen zolang de 1e niet was gestopt? Dat los je normaal op met "semaforen", een vlag die wordt gezet zodra proces 1 begint en aangeeft dat proces 2 niet mag starten. Pas als de vlag gestreken is - omdat proces 1 klaar is, of afgebroken door een fout - kan proces 2 aan de slag. Omgekeerd zal dan ook gelden vermoed ik dat proces 1 dan niet mag starten. Of is dat te simpel gedacht?

[ACM]

Ik ken de interne details niet, dus kan alleen maar raden. Maar ja, ik denk dat je te simpel denkt :)

Het gaat in dit geval om een databasedienst verspreid over duizenden (tienduizenden?) servers. Ook deze processen, het toekennen van een nieuw 'DNS plan' is daar weer onderdeel van.

Het zijn dus sowieso losse servers die dit soort onderhoudstaken uitvoeren, juist bedoeld om al die andere servers goed te laten samenwerken en aan de rest van de AWS-diensten te laten waar ze moeten zijn.

En die onderhoudstaak moet er ook weer tegen kunnen dat zo'n proces of de server zelf er onverwachts mee uitscheidt. Hun hele opzet is daar zelfs op gericht, dat je gewoon een server kan uitzetten en dat het vanzelf wel weer een keertje ontdekt wordt en de workload en onderhoudsprocessen over de resterende systemen wordt verdeeld.

Maar ik vermoed dat je in zo'n opzet ook nooit helemaal zeker kan weten dat er inderdaad uitval is, of een onverwachts iets. Zoals nu deze vertraging.

[NielsFL]

Vaak krijgt een semafoor een timeout mee. Na die timeout wordt de semafoor als niet bestaand beschouwt. Dat is op zich geen vreemde werkwijze.

Wat je dan echter wel moet doen, en men vaak vergeet, is tijdens het proces de semafoor af en toe te vernieuwen. Want hoe onwaarschijnlijk het ook is dat een actie van 2 seconden opeens 2 uur duurt, het kan gebeuren.

[Argantonis]

Ik denk dat je in dit geval juist geen semafoor had willen hebben, maar juist dat het starten van het tweede proces het eerste proces zou cancellen en volledig reverten. Die data was niet meer relevant zoals ik het lees. Het was zonde van de capaciteit geweest om proces 1 nog af te maken. Daarnaast wil je zoiets denk ik niet blocking maken.

[fuzzyIon]

&&

[CommanderWes]

Toen het AWS-controlvlak eerder deze week uitviel, onderbrak het niet alleen de dienstverlening, het had diepgaande cyberbeveiligingsimplicaties die branche-analisten omschrijven als een systemische kwetsbaarheid in moderne cloudarchitectuur. De storing vond waarschijnlijk zijn oorsprong in een mislukte interne DynamoDB API-update en een synchronisatiefout in het controlvlak, NIET een willekeurige DNS-storing. DNS was slechts het enige zichtbare symptoom voor de buitenwereld.

Dat heeft natuurlijk grote implicaties:

1. Tijdens de storing verloren veel organisaties hun observeerbaarheid omdat hun monitoringtools (CloudWatch, CloudTrail, GuardDuty, SIEM-pipelines en IAM-diensten) zich in dezelfde AWS-regio bevonden die uitviel. Dit betekende dat aanvalsdetectie, incidentrespons en credentialtracking allemaal zwart werden. Systemen konden de logintegriteit niet verifiëren of laterale beweging binnen workloads niet detecteren omdat de identiteits- en logsystemen die ontworpen waren om ze te verdedigen ook uitvielen.
2. Experts bij Wheelhouse IT en King's College London benadrukten dat geavanceerde tegenstanders, door staten gesponsord of crimineel, storingscascades zoals deze storing kunnen bestuderen om zwakke controlvlak-afhankelijkheden in kaart te brengen. Wetende dat een enkele regionale storing in US-EAST-1 wereldwijd de authenticatie kan lamleggen, biedt een blauwdruk voor supply-chain-aanvallen.
3. Er is geen geloofwaardig bewijs dat de AWS-storing zelf wachtwoorden lekte, maar er is sterk bewijs dat aanvallers de chaos van de storing exploiteerden om massale credential-phishing- en credential-stuffing-golven te lanceren in Noord-Amerika en Europa.
   a. Beveiligingsonderzoekers bij Penta Security en Cybernews documenteerden een gecoördineerde spamcampagne die uren nadat AWS-diensten offline gingen begon, waarbij bedrijven zoals Reddit, PayPal, Coinbase en zelfs AWS zelf werden geïmiteerd.
   b. Tijdens de storing waren login-throttling en anomaliedetectiesystemen (meestal aangedreven door AWS) aangetast, wat betekende dat aanvallers gestolen wachtwoorden konden testen zonder onmiddellijk geblokkeerd te worden.

Jeff Bezos en het AWS-leiderschap zijn er spectaculair in gefaald om een van de meest catastrofale storingen van het internet te voorkomen, waarbij hun roekeloze overafhankelijkheid van een enkel controlevlak in de US-EAST-1-regio en hun totale gebrek aan zinvolle multi-regio failover-paraatheid werden blootgelegd. Hun poging om de ramp af te doen als een louter "DNS-fout" grenst aan beledigend onoprecht, waarbij een diepere systemische kwetsbaarheid en operationele incompetentie wordt gemaskeerd die miljoenen gebruikers en kritieke bedrijven urenlang machteloos liet.

Misschien zie je de causaliteit niet, maar ik ben er vrij zeker van dat onverantwoorde integratie van AI in hun systemen om operationele kosten te verlagen waarschijnlijk een van de belangrijkste redenen is dat dit überhaupt mogelijk was. Meerdere nieuwsartikels beginnen nu ook die link te leggen (aankondiging van lay-offs voor AI automation was in juli van dit jaar)

[consenso]

Is er voor deze overwegingen ook een verifieerbare bron? Wil het gerust geloven maar leest voor mij even waarachtig als AI, het zou zomaar kunnen maar toch even vragen wat de bron is.

[CommanderWes]

Fair enough, ik baseer mijn mening - geen absoluut feit - op de track record en uiteindelijk verschillende bronnen die duidelijk aangeven dat er honderden ontslagen waren enkele maanden geleden. Dat zal geen onmiddellijke impact hebben op een geautomatiseerd DNS systeem, maar wel op de reactiesnelheid en het overzicht van issues en remediatie ervan gezien AWS en Amazon bekend staan om hun doorgedreven automatisatie via AI en robotica (en mensen als robots behandelen maar dat is een andere discussie).

Het probleem is dan ook de tijd tussen detectie en oplossing voor de duidelijkheid, een organisatie die 30+% van het internet van een platform voorziet, moet mitigatie veel sneller kunnen opleveren maar het is duidelijk dat daar serieus in de kosten is gesnoeid, wat de voornaamste aanleiding van deze post is. Dit legt een systemisch probleem bloot, namelijk onze afhankelijkheid van deze cloudplatformen die net zoals de meeste diensten veel enshittification kennen.

https://www.reuters.com/business/retail-consumer/amazons-aws-cloud-computing-unit-cuts-least-hundreds-jobs-sources-say-2025-07-17/

https://futurism.com/artificial-intelligence/aws-outage-amazon-fired-workers-ai

https://www.latimes.com/business/story/2025-10-23/amazons-big-outage-reminds-us-that-we-trust-big-tech-companies-far-too-much

https://www.forbes.com/sites/christerholloman/2025/10/20/aws-outage-billions-lost-multi-cloud-is-wall-streets-solution/

Het is daarom dat enkel de laatste alinea van mijn reactie een vermelding maakt van de mogelijke oorzaak AI en dat ik daar ook duidelijk stel "ik ben er vrij zeker van".

Edit: bron van Forbes toegevoegd.

[Reactie gewijzigd door CommanderWes op 24 oktober 2025 15:47]

[Fishbeast]

Ik geloof nooit dat ze dit soort kritsche systemen, de backbone van de hele AWS propositie, laten managen door AI; dat zou heel onverstandig zijn. Neemt niet weg dat ze vast heel veel AI geintroducveerd hebben om commodity processen te vervangen door gen AI etc.

[beerse]

Even geheel los van de hier genoemde punten: Buiten AWS heeft iedere klant gefaalt door zelf zo geheel afhankelijk te zijn van 1 (één) leverancier.

De gemiddelde systeembeheerder weet dat meervoudig uitvoeren van systemen er voor zou kunnen zorgen dat niet alles in 1 keer omvalt.

Er zijn systemen die in de documentatie waarschuwen voor problemen met 2-voudig uitgevoerde systemen: Wegens 1-tegen-1 situaties waar het systeem niet automatisch uit komt, dat het beter is om het systeem enkelvoudig uit te voeren en te accepteren dat het onderuit kan gaan of anders 3-voudige (of nog meer) implementaties te gebruiken.

En zo zit het met dns-servers, dns-systemen En ook met cloud-providers.

[NLxDoDge]

Ik snap niet waarom dit geen +1 krijgt, bij ons op werk draaien we alles in 2 datacenters, en sommige software zelfs in 3. Wij moeten vanuit de overheid maar maximaal 2 dagen downtime per jaar hebben anders krijgen we dikke boetes.

Nu vraag ik me wel af, stel je draait een replica in de EU, had je dan ook downtime? Ik kan mijzelf niet voorstellen dat bijna half het internet alleen in US East 1 draait toch?

[sprankel]

Redundatie lost ook maar problemen op tot een bepaald niveau en redudantie kan net zelf voor nieuwe risico's verantwoordelijk zijn. Begrijp mij niet verkeerd, ik ben niet anti redudantie maar uit het beheren van zeer kritische systemen waar een downtime van 500 miliseconden problemen veroorzaakt heb ik al genoeg gezien.

Als een systeem of software faalt en het is simpel gezegd dood, dan werken al die redundantie maatregelen heel goed.

Als het verhaal echter is alles werkt nog maar doet functionieel iets foutief, dan heb je meestal 2 keer niets aan je redundantie omdat die simpelweg niet door heeft dat er een probleem is.

Om in jou verhaal te komen, je mag jij nog 10 failover's hebben voor een database, als de applicatie foute zaken naar de database begint te schrijven dan repliceert zich dat door al je redundante database systemen. Het resultaat is hetzelfde voor de bussiness, de boel werkt niet meer terwijl ze veel betalen om dat net niet te laten gebeuren.

Een ander probleem is dat als je redunant systeem aan het flippen is dat deze compleet ten onrechte kan proberen de boel over te nemen terwijl het hoofd systeem weigert omdat die compleet functionieel is. Kan ook omgekeerd, het hoofdsysteem weigert toe te staan dat het redundant systeem overneemt.

Vaak moet in zulk scenario een mens tussen beide komen, de probleem veroorzaker aanduiden en die vervolgens de nek omdraaien. En voor je denkt dat enkel software dit soort scenario's kan veroorzaken, ooit heb ik een CPU module zonder padon uit een excotisch server rack getrokken om vervolgens te zien dat het systeem dat al heel de tijd stond te flippen plots wel een automatisch zonder onderbreking fail overs begon te doen naar andere racks + backup datacenters.

En om terug bij het bron artikel uit te komen, tussen de lijnen lees ik dat we het hier hebben over redundantie systemen die tegen elkaar zijn beginnen vechten.

[joker1977]

Redundatie lost ook maar problemen op tot een bepaald niveau en redudantie kan net zelf voor nieuwe risico's verantwoordelijk zijn. Begrijp mij niet verkeerd, ik ben niet anti redudantie maar uit het beheren van zeer kritische systemen waar een downtime van 500 miliseconden problemen veroorzaakt heb ik al genoeg gezien.

Als een systeem of software faalt en het is simpel gezegd dood, dan werken al die redundantie maatregelen heel goed.

Als het verhaal echter is alles werkt nog maar doet functionieel iets foutief, dan heb je meestal 2 keer niets aan je redundantie omdat die simpelweg niet door heeft dat er een probleem is.

Om in jou verhaal te komen, je mag jij nog 10 failover's hebben voor een database, als de applicatie foute zaken naar de database begint te schrijven dan repliceert zich dat door al je redundante database systemen. Het resultaat is hetzelfde voor de bussiness, de boel werkt niet meer terwijl ze veel betalen om dat net niet te laten gebeuren.

Dit is zeker waar - maar dit zijn niet situaties waar redundantie an-sich voor gedesigned is. Op het moment dat je "applicatie foute zaken naar de database schrijft" helpt redundantie / fail-over op dat niveau niet. Maar dan zit de "bug" dus in de applicatie en daar zou een redundantie wel kunnen worden gedesigned om dat te voorkomen. Je kunt bv. een vorige versie (na een update) of iets dergelijks parallel hebben draaien die de boel verifieert. Ook kunnen checks op de database e.d. dit voorkomen.

Een ander probleem is dat als je redunant systeem aan het flippen is dat deze compleet ten onrechte kan proberen de boel over te nemen terwijl het hoofd systeem weigert omdat die compleet functionieel is. Kan ook omgekeerd, het hoofdsysteem weigert toe te staan dat het redundant systeem overneemt.

Vaak moet in zulk scenario een mens tussen beide komen, de probleem veroorzaker aanduiden en die vervolgens de nek omdraaien. En voor je denkt dat enkel software dit soort scenario's kan veroorzaken, ooit heb ik een CPU module zonder padon uit een excotisch server rack getrokken om vervolgens te zien dat het systeem dat al heel de tijd stond te flippen plots wel een automatisch zonder onderbreking fail overs begon te doen naar andere racks + backup datacenters.

En om terug bij het bron artikel uit te komen, tussen de lijnen lees ik dat we het hier hebben over redundantie systemen die tegen elkaar zijn beginnen vechten.
[/quote]

Dit probleem wordt een zg. "Split-brain"-situatie genoemd. Deze situatie kun je voorkomen door een zg.quorum-consensus approach te gebruiken. In de praktijk gebruik je dan vaak een derde systeem die mee moet doen in de "verkiezing" om te bepalen wie de (nieuwe) master wordt.

Maar eerlijk is eerlijk, in de meeste gevallen is er geen budget beschikbaar om redundantie tot dat niveau te verheffen. En dan worden er hoekjes afgesneden en kom je uiteindelijk vroeg of laat in een situatie waar een Split-brain achtige situatie gaande is.

[supersnathan94]

Je kunt bv. een vorige versie (na een update) of iets dergelijks parallel hebben draaien die de boel verifieert.

Dat is dus precies wat er mis ging.

Dit probleem wordt een zg. "Split-brain"-situatie genoemd. Deze situatie kun je voorkomen door een zg.quorum-consensus approach te gebruiken. In de praktijk gebruik je dan vaak een derde systeem die mee moet doen in de "verkiezing" om te bepalen wie de (nieuwe) master wordt.

Split-brain situatie kan alleen opdoen in een systeem waar consensus based decisions worden gemaakt. Als er geen majority vote gebruikt wordt is dat dus kansloos.

Een derde systeem had hier dus niks uitgehaald want dit is niet een consensus based system.

Race condities zijn veel basaler en vaak een issue op systemen waar consensus based systems veel te complex zijn en juist meer problematiek toevoegen dan ze oplossen.

[joker1977]

Lees eerst even waar ik op reageer, ik reageer expliciet niet in de context van het nieuws, maar in de context van @sprankel zijn relaas.

[supersnathan94]

ja en daar zijn dus expliciet dat soort systemen niet van toepassing omdat ze juist extra complexiteit toevoegen die de kans op andere fouten weer vergroot.

in het voorbeeld van Sprankel zijn "probleem" is er geen split brain issue want er is geen consensus based voting. dus dan moet je eerst dat weer toe gaan voegen en dan kom je weer met het probleem dat je altijd een oneven aantal voters moet hebben, ook bij uitval van een deel. En wat nou als majority uitvalt (dus 4 van de 7 bijvoorbeeld) voor de overgelbeven 3, maar omdat het een DC netwerk failure is zijn de andere 4 niet offline (en dus gaan die vrolijk door), dan krijg je dus helemaal split brain maar ook nog een fork situatie.

Veel te complex voor dergelijke dingen.

[sprankel]

Een consensus systeem kan nog altijd niet voorkomen dat een systeem koppig verder blijft doen en weigert te luisteren naar de concensus die genomen is. Been there done that.

Als je ook dat scenario wilt vermijden moet je een safety systeem ernaast bouwen welke als die wenst over te nemen het main systeem letterlijk killed met bijvoorbeeld power cuts. Been there done that.

Hoe diep je ook gaat, er blijven altijd edge cases over. Net zoals je geen 100% kan zeggen in security is dat in redundatie net hetzelfde verhaal.

Edit, reactie was bedoeld voor @joker1977

[Reactie gewijzigd door sprankel op 24 oktober 2025 19:12]

[Bedge85]

US East 1 is de achillespees van AWS. In het verleden hebben storingen in US East 1 domino effect gehad in andere regio's. Wanneer een bedrijf zelf alleen resources gebruikt in een Europese regio's is het wel mogelijk dat AWS zelf bepaalde afhankelijkheden heeft op US East 1.

[Sissors]

Ik snap niet waarom dit geen +1 krijgt, bij ons op werk draaien we alles in 2 datacenters, en sommige software zelfs in 3. Wij moeten vanuit de overheid maar maximaal 2 dagen downtime per jaar hebben anders krijgen we dikke boetes.

Makkelijke methode: Alles op AWS East 1 draaien . Die zitten qua uptime per jaar daar nog ruim boven, en dat was met een storing die wereldnieuws was. En dit laat juist zien hoe complex het is wat er op die schaal wordt gedaan.

Overigens zoals @sprankel ook schreef: Paar jaar geleden op de high tech campus lag het complete internet plat. De oplossing uiteindelijk? De redundante glasvezelkabel eruit trekken en het werkte weer. De hele redundante failsafe was de oorzaak van het probleem.

[Cartman!]

Stel je had puur in us-east-1 gedraaid dan was je misschien maximaal 6 uur down en had je prima voldaan aan de eisen met nog ruim anderhalve dag over.

Wij hosten in AWS eu-west-1 en daar hebben we geen enkel probleem ervaren die dag. We draaien single region maar wel in meerdere availability zones (fysiek gescheiden data centers) dus in die zin kun je stellen dat we ook in 2 data centers draaien zonder dat het enige moeite kost.

Extra data centers klinkt leuk op papier maar introduceert extra kosten en complexiteit, dat laatste kan juist ook zorgen voor meer storingen.

[supersnathan94]

Wij moeten vanuit de overheid maar maximaal 2 dagen downtime per jaar hebben anders krijgen we dikke boetes.

Ok, dus pak em beet 99,45%? Overheid kennende is dat vaak ook nog eens alleen kantoortijden, dus dat maakt het ook nog wel anders.

Nu vraag ik me wel af, stel je draait een replica in de EU, had je dan ook downtime?

niet per se. Als er een afhankelijkheid was in je infrastuctuur of applicatie op DynamoDB (wat kan voor data opslag, maar bijvoorbeeld ook Terraform State voor Infra) was er wel impact, maar dat bekent niet dat al je systemen impact ondervonden en dat alles direct ook stuk ging.

Maar daarom zit je ook meer met totale impact dan alleen downtime. Kan best dat maar voor een deel van de gebruikers er wel impact was, maar voor het grootste deel niet.

Dus als je maar 2 dagen downtime mag hebben, kan het bijvoorbeeld ook zo zijn dat je dat mag verdelen. Dus voor 50% van de gebruikers 4 dagen helemaal niet beschikbaar, of voor 10 van de gebruikers, 40 dagen, 50% offline.

Bedrijven maken tegenwoordig precies daarom ook "Experience Based SLO's" en niet meer alleen random uptime garanties die nergens op slaan.

[Argantonis]

Er is wel een verschil tussen 2 of 3 datacentertjes hebben of op 2 of 3 cloud providers draaien hé, dat is echt totaal niet te vergelijken qua risico’s, AWS zelf heeft uiteraard ook bergen met datacenters die prima beschermd zijn tegen de volledige uitval van 1 of meerdere daarvan. Ik ben tegen de verregaande afhankelijkheid van één bedrijf in de VS, maar zolang er geen politiek tussen gaat zitten is AWS wel aanzienlijk veiliger dan eigen beheer van een paar datacenters.

[Reactie gewijzigd door Argantonis op 25 oktober 2025 04:44]

[GeroldM]

Het punt dat je aandraagt is geheel correct: alle eieren in 1 mandje is...foutgevoelig.

Echter, dan krijg je als IT'er te maken met de financiele tak van het bedrijf waar je voor werkt. Die beginnen dan te brabbelen over 'budget dit, budget dat' en dragen dan aan dat 'de cloud is toch redundant uitgevoerd', 'cloud is al duur genoeg' enz. en daar zit je dan met je goede voornemens en (met AI) uitgewerkte plannen om alles good en veilig op te zetten en te beheren.

[Sissors]

Jeff Bezos en het AWS-leiderschap zijn er spectaculair in gefaald om een van de meest catastrofale storingen van het internet te voorkomen

Even los van dat dit overduidelijke door AI (gedeeltelijk) is geschreven, maar euhm, welke storing heb je het over? Er waren wat diensten een tijdje plat. Ja en Snapchat is natuurlijk een populaire dienst dus dat raakt best een hoop mensen. Maar is dat één van de meeste catastrofale storingen van het internet zelf? Dat er wat diensten plat lagen?

En lag nu echt het halve internet plat, sure. Maar ik heb bijvoorbeeld persoonlijk niks gemerkt. Want tja, ik gebruik geen Snapchat en Signal. En natuurlijk, ik snap dat een hoop dat wel doen, maar dat je chat app een paar uur niet werkt noem ik geen catastrofale storing van het hele internet.

[CommanderWes]

https://www.forbes.com/sites/christerholloman/2025/10/20/aws-outage-billions-lost-multi-cloud-is-wall-streets-solution/

Minimaliseren van het probleem en mij diskrediteren dat ik zogenaamd (gedeetelijk) AI gebruik kan altijd als je dat wenst maar in dit artikel van Forbes staat het klaar als daglicht, naast al de economische implicaties:

"Amazon has suffered major AWS outages before. But the timing and impact of this one comes just months after an eyebrow-raising personnel decision by the e-commerce giant. In July, its cloud computing unit cut at least hundreds of jobs — and perhaps more — following a warning from CEO Andy Jassy that the adoption of generative AI would lead to layoffs.

“As we roll out more Generative AI and agents, it should change the way our work is done,” Jassy said in a note to employees in June, per Reuters. “We will need fewer people doing some of the jobs that are being done today, and more people doing other types of jobs.”

It remains unclear which roles were affected by the layoffs. But if Amazon is relying on AI to pick up the slack in the wake of the AWS layoffs, it could be a stunning example of how efforts to replace human employees with unreliable AI tools and AI agents have backfired."

[Sissors]

Waar staat het klaar als daglicht dat het een catastrofale storing van het internet was, ik mis het?

Volgende vraag is, wat zou Forbes dan zo klaar als daglicht stellen? Ze schrijven ook een hoop woorden, met weinig inhoudelijks. Forbes had een goede reputatie, maar dat is vooral verleden tijd, tegenwoordig zijn ze lastig serieus te nemen (Zelfs op r/CryptoCurrency stond lange tijd een waarschuwing onder elk link naar Forbes dat de kwaliteit daarvan vaak diep triest was).

Een paar honderd banen bij AWS is dus <0.5% van het personeelsbestand. Waar is het bewijs, of iig iets van onderbouwing, dat die mensen die ontslagen zijn uberhaupt enige relatie hadden met het systeem waar het nu mis is gegaan?

[Fishbeast]

Ja, eens. ik vind het taalgebruik ook bijzonder.

wIj draaien alles op AWS, en hebben geen verstoring in dienstverlening naar onze klanten ondervonden. We konden zelf alleen geen deployment pipelines starten, want die dienst (CircleCI) had wel last van de verstoring. Dus, zeker een hele vervelende storing waar veel bedrijven/mensen last van gehad hebben, maar verder wel een beetje een storm in een glas water.

[Knallmeister]

Goed opgemerkt dat het taalgebruikt bijzonder is. Diskrediteren was voor mij al een trigger.

[Creesch]

En lag nu echt het halve internet plat, sure. Maar ik heb bijvoorbeeld persoonlijk niks gemerkt.

Op de dag van de storing stond het halve internet vol met nieuwsberichten over deze storing. Ik meen dat het zelfs op mainstream media in Nederland voorbij kwam zoals de NOS. Op diverse plekken werd het ook de grootste storing sinds crowdstrike genoemd.
Er was dus wel degelijk een flinke storing gaande waardoor veel diensten er uit hebben gelegen.

Dat je er zelf weinig van gemerkt hebt kan natuurlijk, ik heb er wel wat hinder van ondervonden, maar niet op kritieke diensten. Maar, dat zegt nog steeds niet heel veel, aangezien ik me zo kan voorstellen dat het percentage bedrijven met kritische diensten die klant zijn bij AWS hoger is in bijvoorbeeld de VS.

[Sissors]

Een redelijk impactvolle storing ben ik het mee eens. Al natuurlijk nog lang niet op het niveau van Crowdstrike storing, toen hele luchthavens dicht gingen. Maar alsnog hij had zeker wel impact. Maar een "catastrofale" storing van het internet? Kom op.

[supersnathan94]

Eens. Ik heb hem zelfs compleet gemist. hoorde het gisteren pas in een YT short.

Zo heftig kan het niet geweest zijn als je hem volledig kunt missen. Die crowdstrike storing had een veel grotere impact.

[Fishbeast]

Dit zijn behoorlijk stevige statements die je hier maakt @CommanderWes . Het zou helpen wat bronnen toe te voegen.

NIET een willekeurige DNS-storing.

Volgens mij draaien ze hier ook helemaal niet omheen.
Zie ook hun officiele post-mortem en verschillende goed geinformerde andere bronnen

waarbij hun roekeloze overafhankelijkheid van een enkel controlevlak in de US-EAST-1-regio

Voor degenen die een beetje in-to AWS zijn, weten dat deze afhankelijkheid bestaat, en er over het algemeen geen operationele afhankeljkheid is van deze regio. Maar, als je (globale) DNS onderuit gaat is het natuurlijk te verwachten dat de impact niet beperkt blijft tot deze regio ;-)

Ik zie inderdaad de samenhang met "ontslagen vanwege de inzet van AI" niet, daar dit 'gewoon' een geautomatiseerd proces is dat een hiccup had. (of je moet dat geautomatiseerde proces zien als AI)

[Reactie gewijzigd door Fishbeast op 24 oktober 2025 15:21]

[CommanderWes]

Voor jou heb ik ongeveer dezelfde reactie als voor consenso; ik heb één alinea besteed aan het feit dat ikzelf er vrij zeker van ben dat de causaliteit van de lengte van de outage ligt bij te veel doorgedreven automatisatie en dat dat de time to resolution serieus geïmpacteerd heeft.

Om mezelf te quoten:

"Dat zal geen onmiddellijke impact hebben op een geautomatiseerd DNS systeem, maar wel op de reactiesnelheid en het overzicht van issues en remediatie ervan gezien AWS en Amazon bekend staan om hun doorgedreven automatisatie via AI en robotica (en mensen als robots behandelen maar dat is een andere discussie).

Het probleem is dan ook de tijd tussen detectie en oplossing voor de duidelijkheid, een organisatie die 30+% van het internet van een platform voorziet, moet mitigatie veel sneller kunnen opleveren maar het is duidelijk dat daar serieus in de kosten is gesnoeid, wat de voornaamste aanleiding van deze post is. Dit legt een systemisch probleem bloot, namelijk onze afhankelijkheid van deze cloudplatformen die net zoals de meeste diensten veel enshittification kennen."

[Alfa1970]

Ik ben niet helemaal in-to AWS, maar vanuit mijn oogpunt was de impact redelijk beperkt.
Ja een paar triviale diensten lagen plat, maar de omvang was redelijk beperkt, in ieder geval vanuit mijn oogpunt tot de US, een gebied waarin ik niet opereer, en derhalve niets heb gemerkt van de outage in die regio. Andere AWS omgevingen in de EU/MEA regio leken voor zover ik dat kan bepalen onaangedaan.
Onze servers bleven gewoon in de lucht en bereikbaar.

En ook op gebied van DNS heb ik niks kunnen ontdekken. Zelfs na het clearen van de DNS cache kwam ik gewoon overal waar ik bij moest kunnen dus empirisch gezien was er niks mis met de AWS/DNS.
Nu weet ik wel dat DNS records over het algemeen een lange TTL hebben maar again empirisch, als er changes worden gepushed dan zie ik DNS entries redelijk snel propageren over het internet. Dus ik ben er vrij zeker van dat dit probleem redelijk beperkt was vanuit ons oogpunt.

[Fishbeast]

Dit beaam ik: Bij mijn klant is er geen operationele impact geweest, we hadden alleen last van wat 3rd party diensten die last hadden van deze outage.

[GeroldM]

Volgens C. Doctorow was het een race-conditie in Amazon's software voor het load-balanceren van hun interne systemen. Dat viel na verloop van tijd om, cascadeerde door US-East-1 heen en kreeg de software die het bijhouden van route-tabbellen bijhield te pakken. Uiteindelijk kegelde ook hun DNS server om en dat propageerde door naar andere DNS servers.

Dat had eerder gedetecteerd kunnen worden door de monitor systemen. En dat er uberhaupt een race-conditie kon ontstaan in deze software, op dit nivo, daar mogen zelfs vragen over worden gesteld door een onderzoekscommissie (welke ook daadwerkelijk kan straffen). Een beginnende programmeur, in zijn/haar eerste code kun je race-condities wel verwachten. Maar software op dat nivo waar AWS opereert, daar zou geen enkele race-conditie in voor mogen komen (want tot in den treure getest via unit-tests EN regressie-tests!). Want doorgewinterde programmeurs zouden allang slim genoeg moeten zijn om fouten zoals race-condities al op te merken voordat de code word gecommit.

[pumpidumpi]

Het AWS-controlvlak? en verderop 'een enkel controlevlak'? Wat is dat?

[Fishbeast]

AI-schmutzigkeit

[Stukfruit]

Jeff Bezos en het AWS-leiderschap zijn er spectaculair in gefaald om een van de meest catastrofale storingen van het internet te voorkomen

Andy Jassy

[JeroenED]

Nog steeds fout: AWS word geleid door Matt Garman volgens wikipedia. Waarschijnlijk rapporteert die wel aan Andy Jassy voor heel belangrijke zaken maar Jassy is volgens mij niet de "verantwoordelijke". En dan zit je nog met de vraag in hoeverre Bezos nog in het bad zit.

[Fishbeast]

Waarschijnljk alleen als aandeelhouder die graag divident ontvangt (en er verder day-to-day niets mee te maken wil hebben)

[Keypunchie]

Experts bij Wheelhouse IT en King's College London benadrukten dat geavanceerde tegenstanders, door staten gesponsord of crimineel, storingscascades zoals deze storing kunnen bestuderen om zwakke controlvlak-afhankelijkheden in kaart te brengen. Wetende dat een enkele regionale storing in US-EAST-1 wereldwijd de authenticatie kan lamleggen, biedt een blauwdruk voor supply-chain-aanvallen.

Of gewoon een ICBM op US-East.

[supersnathan94]

Jeff Bezos en het AWS-leiderschap zijn er spectaculair in gefaald om een van de meest catastrofale storingen van het internet te voorkomen

ehm ... wat?

Ik ben AWS certified. Heb ook wat spul in AWS draaien zelf, maar ik heb deze storing zelfs compleet gemist.

Ik hoorde er toevallig van via een YT short. Dus zo heel "catastrofaal" was dit allemaal niet.

Verder ben ik wel met je eens dat de werking AWS echt bizar afhankelijk is van US-EAST-1. Als ik ooit een oorlog zou starten met de wereld: De eerste kernbom gaat daarnaartoe.

heel IAM is afhankelijk van die regio. Dus zonder die DCs kan niemand meer iets. Je hebt geen log in, je hebt geen service2service auth, geen RBAC, geen IDP, Niks noppes nada. Heel AWS en alle achterliggende zaken plat.


Nee een DNS issue met DynamoDB is echt een klein dingetje hoor. het kan allemaal veel problematischer.

[ctrl-tab]

Controlvlak?

Waarom een stuk kopieren van een generator?

En dan afgeven op de AI van AWS?

[Anonymoussaurus]

Link naar bron: https://aws.amazon.com/message/101925/

[Cybje]

“DNS-beheersysteem DynamoDB” voelt wat onlogisch omschreven. DynamoDB is een database, niet een DNS beheersysteem. Maar ik kan me wel voorstellen dat het DNS beheersysteem bij AWS op de achtergrond gebruik maakt van DynamoDB.

[pumpidumpi]

Idd. En om de API van Dynamo te gebruiken heb je DNS nodig. Goed daar zullen ze wel wat voor bedacht hebben met en soort van bootstrap DNS ofzo. Anders kun je bij een cold start nooit up komen.

[Danfoss]

Het artikel leest als een slechte vertaling.
"Een bug in het DNS-beheersysteem DynamoDB zorgde voor een kettingreactie van problemen."
"bleek dat er een racecondition was ontstaan in het DynamoDB-DNS-beheersysteem"

DynamoDB is niet een DNS-beheersysteem maar een NO-SQL database.
De bug zat in het DNS-beheersysteem dat gebruikt maakt van DynamoDB en de DNS van een endpoint van DynamoDB werd verwijderd waardoor heel veel andere diensten ook omvielen.

[djwice]

De bug zat in ... dat gebruikt maakt van DynamoDB

Ook niet. Route53 maakt geen gebruik van DynomoDB. De race conditie zat ik de aansturing van het script dat DNS-records in Route53 update. Een script dat het DynamoDB team intern gebruikt voor het managen van de database IP-adressen. Recent was daar een wijziging in gemaakt voor IPv6.

[Reactie gewijzigd door djwice op 25 oktober 2025 11:13]

[Danfoss]

En waar haalt dat update script de data vandaan met welke diensten bestaan en wat er geupdate moet worden? Uit een dynamoDB zoals ik het lees.

[iqcgubon]

Dus het "DNS probleem" was helemaal geen DNS probleem. Tale as old as time. Shit goes in, shit comes out, maar DNS doet gewoon wat het moet doen :P

[marzman95]

"It isn't DNS"

"Nope, I've checked, it isn't DNS"

"I'm sure. It is not DNS"

Twee dagen later:

"Het was DNS"

[Kun]

Best knap dat ze in twee dagen Nederlands hebben geleerd.

[Alfa1970]

Een AI kan prima als universal translator operereren. In feite zijn ze daar heel erg goed in, gezien het voornamelijk op taal gebaseerde modellen zijn.

[Argantonis]

“Een bug in het DNS-beheersysteem DynamoDB”

Dit is toch echt gênant voor een site als Tweakers. Nee DynamoDB is zelf geen DNS-beheersysteem. Misschien iets minder copy-paste en slechte vertalingen?

[bantoo]

Zijn journalisten he, geen techneuten.

[HSG]

Gewoon AI uitrollen. Dan gaat het beter en sneller en kun je alle beheerders op straat gooien.