- Dieser Ausfall in der AWS-Region US-EAST-1 wird nicht als bloßer technischer Defekt, sondern als Signal einer organisatorischen Schwächung durch den Abfluss von Schlüsselpersonal analysiert.
- Als Ursache des Ausfalls wurde erneut ein klassisches DNS-Problem festgestellt; durch einen Fehler im DynamoDB-API-Endpunkt fielen weitere Services kaskadenartig aus.
- Nachdem Veteranen-Ingenieure, die sich an frühere Fehlermuster des Systems erinnerten, das Unternehmen verlassen haben, zeigte sich, dass die Identifizierung des Problems und die Wiederherstellung deutlich langsamer verliefen.
- Umfangreiche Entlassungen bei Amazon und eine hohe „bedauerte Fluktuationsrate“ von 69–81 % wirken zusammen und erschüttern die betriebliche Stabilität von AWS.
- Dabei geht es nicht um veraltete Technik, sondern um das Fehlen von Menschen; der Vorfall wird nicht als „ein einzelner Unfall“, sondern als Vorzeichen eines anhaltenden Vertrauensverlusts bei AWS gedeutet.
DNS-Ausfall und Service-Unterbrechungen
- Wie der unter Systemadministratoren seit Langem verbreitete Witz "It's always DNS" sagt, stehen bei vielen Service-Ausfällen letztlich DNS-Probleme im Zentrum.
- Am 20. Oktober 2025 um 12:11AM (PDT) wurde ein sprunghafter Anstieg der Fehlerrate bei AWS-Services in der Region US-EAST-1 gemeldet.
- Um 1:26AM begannen Anfragen an den DynamoDB-Endpunkt in größerem Umfang zu scheitern.
- Um 2:01AM wurde ein DNS-Resolution-Fehler des DynamoDB-API-Endpunkts als Ursache bestätigt, woraufhin zahlreiche abhängige Services in eine Kaskade von Ausfällen gerieten.
- DynamoDB ist ein Basisdienst der AWS-Infrastruktur; wenn Services in dieser Region ausfallen, wirkt sich das auf weite Teile des Internets aus.
- Banken, Spiele, soziale Netzwerke, Regierungsdienste und Amazon.com-Shopping waren großflächig betroffen.
- Von der Erkennung des Problems bis zur Ursachenermittlung vergingen 75 Minuten; gemessen an der Tradition von AWS, als Vorbild für schnelle Wiederherstellung zu gelten, war das eine ungewöhnlich langsame Reaktion.
- Dass die Erkennung des Ausfalls und die Identifizierung der Ursache so viel Zeit beanspruchten, wird eher auf mangelnde Erfahrung als auf fehlende Transparenz zurückgeführt.
- Auf der Statusseite erschien in diesem Zeitraum lediglich die Meldung „normaler Betrieb“, was Kritik aus der Community auslöste.
Die Erfüllung der „Prophezeiung“: Warnungen ehemaliger Mitarbeiter
- Traditionell war AWS für seine hochgradige Fähigkeit zum Betrieb großer Infrastrukturen bekannt, sodass selbst ein Ausfall in nur einer Region große Aufmerksamkeit erzeugte; doch je höher die Komplexität und je häufiger sich ähnliche Probleme wie in der Vergangenheit wiederholen, desto wichtiger wird Erfahrung aus dem praktischen Betrieb.
- Der ehemalige AWS-Ingenieur Justin Garrison warnte bei seinem Abschied im Jahr 2023, dass „große Ereignisse (LSE) zunehmen“.
- Er sagte voraus, dass es 2024 zu einem schwerwiegenden Ausfall kommen werde; die aktuelle Lage gilt als Bestätigung dieser Warnung.
- Während ranghohe technische Fachkräfte AWS in Serie verließen,
ging auch über Jahrzehnte angesammeltes Tribal Knowledge (internes erfahrungsbasiertes Wissen) verloren.
- Gerade bei einem DNS-Ausfall reicht es nicht, nur Menschen zu haben, die die technische Ursache kennen;
nötig sind auch diejenigen, die sich erinnern, ob dieses System in der Vergangenheit schon einmal ähnliche Probleme verursacht hat.
- Doch genau jene, die dieses Wissen hatten, verließen das Unternehmen wegen Widerstands gegen RTO (Rückkehrpolitik ins Büro) und Entlassungen.
Belege für den Talentabfluss
- Zwischen 2022 und 2025 wurden mehr als 27.000 Amazon-Mitarbeiter entlassen;
die Quoten pro Bereich sind nicht öffentlich, doch es wird davon ausgegangen, dass auch AWS direkt getroffen wurde.
- Laut internen Unterlagen lag die „bedauerte Fluktuationsrate“ bei 69–81 %;
das bedeutet, dass gerade jene Mitarbeiter gingen, die das Unternehmen eigentlich halten wollte.
- Als der Unmut über die Return-to-Office-Anordnung explodierte,
häuften sich Berichte, wonach erfahrene Veteranen-Ingenieure in großer Zahl kündigten.
- In der Folge wurde AWS mit kostengünstigeren, aber weniger erfahrenen Teams neu aufgestellt,
wodurch die Fähigkeit zum Betrieb komplexer Infrastrukturen allmählich nachließ.
Strukturelles Problem: die Entstellung von „Frugality“
- Der frühere Amazon-Kernwert Frugality (Sparsamkeit)
stand für die Philosophie, mit wenig Ressourcen maximale Effizienz zu erzielen.
- In jüngerer Zeit hat sich das jedoch zu der Haltung verzerrt, mit praktisch gar keinen Ressourcen alles erledigen zu müssen.
- Durch den Personalabbau sei sogar grundlegende Wartung schwer geworden.
- Das ist kein Problem, weil die Technik alt ist, sondern weil die Menschen, die sie betreuen, neu sind.
Ausblick
- Der Markt wird diesen Ausfall wohl als Einzelereignis betrachten, doch die Struktur des Problems bleibt bestehen.
- Erfahrene Kräfte gehen, die Komplexität der Systeme wächst,
und so entsteht ein Kreislauf, in dem die Wahrscheinlichkeit des „nächsten Vorfalls“ immer weiter steigt.
- AWS wird den Vorfall vermutlich als „isolierten Einzelausfall“ darstellen,
doch wenn sich die internen Lücken weiter aufsummieren, steigt das Risiko ähnlicher großflächiger Ausfälle erheblich.
- Wie es in der Redewendung „chickens are coming home to roost“ heißt,
erweist sich nicht die Technik, sondern der Verlust an Humankapital als größtes Risiko für AWS.
8 Kommentare
Menschen sind wohl überall gleich..
Das ist wohl eine Geschichte, die auf jedem Markt gilt.
Man sollte das Know-how der IT-Technik wohl ähnlich behandeln wie das Know-how erfahrener Schweißer.
Unter den Beiträgen, die ich vor Kurzem gesehen habe,
kommt mir irgendwie die Aussage wieder in den Sinn, dass es bei Amazon wirklich schwer ist, von Senior Engineer Level 2 in die nächste Stufe aufzusteigen.
Ich vermute, dass solche bedauerlichen Kündigungen gerade in diesem Abschnitt besonders häufig vorkommen.
Umgekehrt könnte man oben auch denken: „Sie haben so viele Leute entlassen, und trotzdem lässt sich das noch in diesem Maß in den Griff bekommen ...“
In Korea werden Ingenieure ab einem gewissen Punkt alle zu Managern, und dann reißt es ab...
In den USA ist es ein Problem, dass unter dem Vorwand der Effizienzsteigerung alle Seniors entlassen werden...
Es ist wirklich nicht einfach...
Multi-AZ haben wir zwar eingerichtet, aber müssen wir jetzt wohl auch auf Ausfälle auf Regionsebene vorbereitet sein..
Ich denke, man sollte auch berücksichtigen, ob diese Kosten wirklich höher sind als die Verlustkosten.
Hacker-News-Kommentar
Sowohl bei den angestellten Ingenieuren als auch bei den Lagerarbeitern habe ich inzwischen das Gefühl, dass der Tag nicht mehr fern ist, an dem durch die ständigen Entlassungen selbst die Leute verschwinden, die früher einmal hier gearbeitet haben.
Selbst wenn es Hunderttausende H-1B-Ingenieurskandidaten und zig Millionen illegale Einwanderer als Lagerarbeiter gibt, kann einem Unternehmen dieser Größe bei schnellen Massenentlassungen am Ende trotzdem das Personal ausgehen.
Die Situation erinnert mich an die Star-Wars-Parodie-Folge von Robot Chicken. Dort tun imperiale Offiziere so, als würde Darth Vader sie mit dem Machtwürgegriff töten, und stellen sich tot, um nicht vom Lichtschwert zerlegt zu werden; später kommen sie unter anderem Namen zurück. Amazon ist noch schlimmer. Niemand will zurückkommen.
https://www.youtube.com/watch?v=fFihTRIxCkg
Ehrlich gesagt habe ich noch keinen halbwegs fähigen Ingenieur gesehen, der jemals wieder bei Amazon arbeiten wollte.
Gibt es in den Lagern wirklich so viele illegale Einwanderer? Soweit ich weiß, gleicht Amazon Identitäten ab und prüft Unterlagen gründlich. Es mag gelegentlich Identitätsdiebstahl geben, aber ich glaube nicht, dass das in großem Umfang passiert.
Nicht nur die Entlassungen waren das Problem; ich erinnere mich auch daran, direkt nach der vollständigen RTO-Einführung bei Amazon mit Recruiter-Mails bombardiert worden zu sein.
Es scheint eine Stimmung zu geben, in der allein das Stichwort H-1B schon Vorurteile über die Fähigkeiten eines Ingenieurs auslöst.
Ich selbst habe früher mit H-1B gearbeitet und bin inzwischen nach Indien zurückgekehrt, wo ich mein eigenes Geschäft aufbaue. Ich komme von Amazon. Es war ein harter Laden, aber Mitte der 90er lohnte sich die Arbeit dort wegen der Stock Options.
Ich bin ziemlich sicher, dass ich besser programmieren kann als viele hier. Und viele H-1B-Leute in meinem Umfeld waren tatsächlich sehr stark.
Man sollte keine Vorurteile haben, sondern die Fähigkeiten direkt bewerten. Wer die Konkurrenz unterschätzt, schadet am Ende sich selbst.
Jetzt wäre genau der richtige Zeitpunkt, die Mitarbeiter zu halten und ihnen die bestmöglichen Werkzeuge zu geben, damit sie gute Arbeit leisten können.
Entwicklungswerkzeuge werden jeden Tag besser, und auch wenn man kurzfristig Personal abbauen kann, treten die Effekte nicht sofort ein.
Man verpfändet die künftige Entwicklung und die Nachhaltigkeit der Organisation, um die Gegenwart zu überstehen. Sich etwas vorzumachen macht das Downsizing nicht erfolgreicher.
In der Praxis scheint die Strategie aber zu funktionieren. Ein Viertel der Junior-Principal-Engineers wurde entlassen, der Aktienkurs stieg, und selbst nach dem großen Ausfall stieg er wieder. Kurzfristig sieht es so aus, als würde ihre Strategie aufgehen.
Selbst die früheren „jungen“ Big-Tech-Unternehmen treten jetzt in ihre Phase als gealterte Großkonzerne à la IBM ein.
Es ist nicht so, dass man nicht wüsste, dass hohe Fluktuation schlecht ist; es wirkt eher so, als würde das Spielfeld von Anfang an so geplant, dass die Belegschaft insgesamt auf ein durchschnittliches Niveau eingeebnet und zu austauschbaren menschlichen Ressourcen gemacht wird.
Inzwischen wird selbst bloße Exzellenz schon als „Cowboy-Kultur“ abgetan.
Es war ziemlich verdächtig, dass der Beginn der eigentlichen Störungsbehebung genau mit dem Arbeitsbeginn an der US-Westküste zusammenfiel.
Davor lauteten die Updates nur „wir überwachen die Situation, Minderungsmaßnahmen laufen“, ohne konkrete Informationen.
Soweit ich weiß, begann die Wiederherstellung gegen 4 Uhr morgens Seattle-Zeit. Der Arbeitstag beginnt normalerweise um 9, vielleicht ging es nach New Yorker Zeit gegen 6 Uhr los.
Ein Beitrag, den ich heute Morgen auf Reddit gelesen habe, wirkt im Nachhinein deutlich bedeutungsvoller.
AWS ist immer noch meine bevorzugte Cloud, und ich nutze sie wirklich sehr effizient.
Ich habe auch schon darüber nachgedacht, einmal bei AWS zu arbeiten, aber solange ich nicht sicher bin, dass einige Bedenken ausgeräumt wurden, bin ich unschlüssig.
Wenn ein künftiger Manager Kandidaten nicht einmal in diesem Prozess schützen kann, entsteht die Sorge, dass er sie bei schwerwiegenderen kulturellen Problemen erst recht nicht schützen kann.
Ich glaube, es gibt eine Idee, die man aktuell auf das gesamte FAANG-Umfeld anwenden könnte: Man muss das Bild immer wieder erneuern, dass dies Orte sind, an die wirklich fähige Leute gehen wollen.
Meta hat sich vor allem über höhere Bezahlung sowie Open-Source- und Open-Hardware-Veröffentlichungen gebrandet, und Google hat technische Überlegenheit und eine warme Unternehmenskultur betont (a.k.a. Kultur der Einarbeitung von Berufseinsteigern, heute eher formalistisch).
AWS hat bereits viel vorzeigbares technisches Talent, und ich denke, man sollte mehr investieren, um diese Leute anzuziehen und zu halten, und dieses Bild in der Branche aktiv verbreiten.
Dasselbe habe ich auch in Startups gesehen.
Nach einer Übernahme gehen oft die zentralen Talente, entweder weil ihre Aktien gevestet sind oder weil der Großkonzern sie hinausdrängt, um andere auf ihre Plätze zu setzen.
Die Leute, die die Technik wirklich verstehen, sind dann weg, und übrig bleibt nur eine unwartbare, chaotische Codebasis, bei der niemand mehr weiß, wie man die Probleme behebt.
Ich mag sehr, wie El Reg den Kern der Sache präzise trifft.
Mir ist erst jetzt aufgefallen, dass der Autor Corey Quinn ist, der schon viel über AWS geschrieben hat.
Ich mag auch, dass die Autoren mit Witz und Persönlichkeit schreiben.
Diese Leute treffen bei allem den Kern.
„Innerhalb von 75 Minuten nach Auftreten des Problems wurde die Ursache auf einen bestimmten Service-Endpunkt eingegrenzt.“
Ist das wirklich so langsam? Ich mache zwar keine Webentwicklung, aber wenn man in 75 Minuten herausfindet, wo das Problem liegt, wirkt das auf mich ziemlich schnell.
Als ich früher als Firmware-Ingenieur gearbeitet habe, dauerte es oft Wochen, bis man überhaupt herausfand, wo etwas kaputtgegangen war.
Wenn ein Problem tatsächlich nur mit einer Häufigkeit von 0,01 % auftritt, mit nichts korreliert und nach einem Retry verschwindet, kann es wirklich Wochen dauern.
Aber solche Dinge haben meist keine hohe Priorität; echte dringende Vorfälle sind reproduzierbar und treten plötzlich auf, obwohl vor einer Stunde noch alles in Ordnung war.
In einem ordentlich entworfenen geschäftskritischen System sollte die Diagnose normalerweise nicht länger als 75 Minuten dauern. Die Behebung kann natürlich länger brauchen.
Wobei man nicht behaupten kann, dass solche idealen Systeme in der Realität häufig wären.
Für ein gewöhnliches Unternehmen mögen 75 Minuten nicht lang sein. Aber wenn bei der größten Cloud der Welt große Teile des Internets lahmgelegt sind, ist das etwas anderes.
In der offiziellen Mitteilung stand zwar, dass noch ermittelt werde, aber intern könnte man die Ursache tatsächlich schon früher vermutet haben.
Es ist vernünftig, mit voreiligen Updates vorsichtig zu sein, weil Nutzer sie sonst unnötig missverstehen könnten.
Meiner Meinung nach sind 75 Minuten für die Diagnose eines gravierenden Problems fast Spitzenklasse.
Amazon gilt als Betreiber einer Infrastruktur auf höchstem Branchenniveau.
Da praktisch alle anderen Unternehmen Amazons Infrastruktur nutzen, erwartet man, dass SRE-Kaliber solche Vorfälle wirklich sehr schnell eingrenzen.
Das Erfahrungswissen und die Kompetenz, die innerhalb einer Organisation verloren gehen, sind der wirklich wichtige Wert, den man nicht einfach in eine Excel-Tabelle schreiben kann.
In der Organisation werden zunehmend Menschen bevorzugt, die ihre eigene Marke pflegen oder für Schaufenster-Rekrutierung taugen, statt wirklich starke Leute und langfristig erfahrene Fachkräfte, während der technische Kern, der das System tatsächlich versteht, verdrängt wird.
Wenn dieses Ungleichgewicht in einer Organisation von der Größe AWS’ wächst, überrollen LinkedIn-Promis und checklistengetriebene DEI-Personalpolitik die echten Builder, und Ausführungsqualität, Verantwortungsbewusstsein und technische Solidität erodieren allmählich.
Es scheint langsam klar zu werden, dass Andy Jassys Führung nicht funktioniert, und es würde mich nicht wundern, wenn die Wall Street bald offiziell seinen Austausch fordert.
Wenn Leute sagen, The Register sei ein angesehenes Medienhaus, habe ich das Gefühl, dass sie selbst wahrscheinlich gar nicht so genannt werden wollen …