1. Eine 1,7-Milliarden-Dollar-Rechnung — bei einer Monatsgebühr von unter 5 Dollar
Am 17. Juli 2026 postete ein AWS-Nutzer namens nprateem auf Hacker News: Seine geschätzte monatliche AWS-Rechnung wies 1.700.000.000 Dollar aus — 1,7 Milliarden. Dabei lag seine normale Monatsgebühr bei unter 5 Dollar.
Er dachte, er hätte sich verlesen, und rieb sich die Augen. Hatte er nicht.
Der Nutzer eröffnete umgehend ein Notfall-Ticket und fragte im Beitrag: „Hat das noch jemand erlebt?“
Die Antwort lautete: Ja, und zwar sehr viele.
Auf Reddit und X (ehemals Twitter) tauchten binnen kurzem zahllose Screenshots auf. Ein Nutzer, der im Vormonat lediglich 0,19 Dollar ausgegeben hatte, erhielt eine Schätzung von knapp 25 Milliarden Dollar. Ein anderer schrieb auf X: „Ich habe gerade 1,5 Billionen Dollar auf meiner AWS-Rechnung gesehen — meine Seele hat meinen Körper verlassen.“ Der Post erreichte 1,3 Millionen Aufrufe und fast 19.000 Likes.
Wieder andere löschten in ihrer Panik kurzerhand sämtliche Ressourcen des Kontos — „Kurz gesagt: Ich geriet in Panik und zerstörte alles auf diesem Konto.“
Diese Zahlen entsprachen jedoch keinen echten Abbuchungen. AWS bestätigte schnell, dass das Problem bei der „geschätzten Rechnung“ lag, nicht bei der tatsächlichen Abrechnung. Trotzdem: In dem Moment, in dem man diese Zahl sieht, verliert niemand die Fassung.
2. Was ist eigentlich passiert?
AWS lieferte 90 Minuten nach dem Vorfall die Ursachenbeschreibung: „Ein Problem mit der Einheitenpreisgestaltung im Subsystem zur Berechnung der geschätzten Rechnungen.“ Klingt verschlungen — auf Deutsch gesagt: Es war ein falsch angegebenes Maß.
Wirklich erklärt hat den Sachverhalt ein ehemaliger AWS-Ingenieur namens donavanm. In den Kommentaren auf Hacker News schrieb er Folgendes (vom Autor übersetzt):
„Als ich bei AWS war, habe ich exakt denselben Fehler behandelt. Es ist ein Einheitenfehler. Wir wollten eigentlich 0,05 Dollar/GB berechnen, haben aber die Einheit (GB) weggelassen, woraufhin das Abrechnungssystem standardmäßig pro Byte abrechnete. 0,05 Dollar pro Byte an Datenübertragung bedeuteten, dass einige Kunden innerhalb weniger Stunden Millionenbeträge auf ihrer Rechnung sahen. Ich wurde um 2 Uhr morgens vom Support-Team angerufen, der Fix war zwischen drei und vier Uhr fertig und ausgerollt, danach folgte eine Entschuldigungsmail.“
Dieser Abschnitt offenbart mehrere wichtige Punkte:
Erstens: Das ist nicht das erste Mal. Derselbe Fehlertyp trat bereits früher auf — und zwar, wie der Autor anmerkt, möglicherweise mehr als einmal.
Zweitens: Der Verstärkungsfaktor ist gewaltig. 1 GB = 1.073.741.824 Byte. Wer das „GB“ vergisst, lässt das System standardmäßig pro Byte abrechnen — die Rechnung schwillt augenblicklich um eine Milliarde an. Aus 0,05 Dollar Nutzungsgebühr werden 53.687.091,20 Dollar.
Drittens: Dieser Fehler wird vor dem Release nicht automatisch erkannt. Er passierte ungehindert durch alle Phasen von Entwicklung, Test und Deployment — bis die Nutzer die Screenshots sahen, in Panik gerieten und Postings verfassten.
3. Warum schlüpfte ein „fehlendes Maß“ durch all die Sicherheitsbarrieren?
Hier liegt der eigentlich beunruhigende Teil.
donavanm erläuterte weiter, wie das AWS-Abrechnungssystem funktioniert. Die Nutzungsdaten (wie viele Ressourcen verbraucht wurden) und die Preisinformationen (wie viel pro Einheit) werden getrennt voneinander gespeichert. Jede SKU — man kann sie sich als einzelne Abrechnungsposition vorstellen — ist in einem „Preisplan“ definiert, der Einheitentyp, gültige Region, Stückpreis und weitere Angaben enthält. Die Messdatensätze und die Preispläne werden über Felder wie Account-ID, Region und SKU-Nummer einander zugeordnet.
Ist der Einheitentyp im Preisplan falsch angegeben — eigentlich GB, aber leer gelassen oder auf Byte gesetzt —, dann schlägt die Umrechnung zwischen Messdaten und Preis fehl. Und keinerlei automatisierte Prüfung hält diesen Fehler auf.
Ein anderer Hacker-News-Kommentator brachte es auf den Punkt:
„Keine Tests? Man vertippt sich einfach in einem völlig unauffälligen Detail — und dann erhalten hunderttausende Administratoren eine Rechnung, die ihnen einen Herzinfarkt beschert?“
Ein weiterer Nutzer antwortete auf diese Frage:
„Tests gibt es natürlich. Test 1 verifizierte, dass der Dienst die Messdaten korrekt aussendet (‚Wir haben eine Operation über 100 Byte ausgeführt, bestätigt, dass das Abrechnungssystem 100 Byte erhalten hat — bestanden‘). Test 2 bestätigte die Rechenlogik des Abrechnungssystems (‚SKU#12345 mit 100 GB-Einheiten füttern, 17 Dollar berechnet — bestanden‘). Aber niemand hat diese beiden Tests gemeinsam laufen lassen — denn das betrifft unterschiedliche Teams, unterschiedliche Management-Ebenen, und es ist schwerer umzusetzen.“
Der Autor findet diese Erklärung aufschlussreich. Sie legt ein bekanntes Problem des Engineering-Managements offen: Jedes Glied für sich funktioniert richtig, aber zusammengesetzt geht es schief. Ein HN-Nutzer lieferte noch einen ergänzenden Gedanken: „Irgendjemand hat in einem Meeting gesagt, wir sollten die Tests wirklich einmal durch den Abrechnungsprozess laufen lassen, worauf jemand erwiderte, echte Abbuchungen durch Tests zu erzeugen könnte ein rechtliches oder finanzielles Problem sein, vielleicht sogar strafbar — und danach hat niemand mehr gefragt, was die zweitbeste Alternative wäre.“
4. Der wahre „Bösewicht“: die Komplexität der Cloud-Abrechnung
Wer dieses Ereignis allein als „ein Ingenieur hat sich in einer Konfiguration vertippt“ versteht, verfehlt das Wesentliche.
Der wahre Bösewicht ist die Komplexität des Cloud-Abrechnungssystems selbst.
AWS verfügt über rund 300.000 verschiedene SKUs (Abrechnungseinheiten). Nicht 300, sondern 300.000. Jede SKU besitzt ihre eigene Preislogik — nach Zeit, nach Datenvolumen, nach Anzahl der Requests, nach Speicherkapazität, nach Region. Sie schichten sich zudem übereinander: Ein simpler Web-Request kann gleichzeitig Compute-Gebühren, Netzwerkübertragungskosten, Speicherlesegebühren, Logging-Kosten und Monitoring-Datenkosten auslösen — jeder Posten mit eigenem Maß und eigenen Regeln.
Die Erzeugung der Nutzungsdaten und die Konfiguration der Preisdaten sind zwei völlig getrennte Systeme. Ihre Zuordnung erfolgt über Feldverknüpfungen, nicht über hartcodierte Validierung. An diesem Design ist an sich nichts falsch — es gibt AWS enorme Flexibilität, Preise ohne Änderung des Messsystems anzupassen. Der Preis dafür lautet: Niemand kann vollständig verstehen, was ein bestimmter Vorgang letztlich kostet.
Tatsächlich ist die AWS-Rechnung so komplex, dass es einen eigenen Berufsstand gibt, der sie entschlüsselt — den Cloud-Cost-Optimierungsberater. Dass in einem Geschäft mit über 100 Milliarden Dollar Jahresumsatz eigene „Übersetzer“ nötig sind, um Kunden zu erklären, wie viel sie ausgegeben haben, sagt an sich schon einiges.
Sogar AWS-Ingenieure räumten in der HN-Diskussion Unbehagliches ein. Ein Selbstbezeichner als ehemaliger AWS-Mitarbeiter schrieb: „Das ganze Unternehmen gleicht einer Rube-Goldberg-Maschine — kaum jemand schert sich um das, was außerhalb seines kleinen Ausschnitts passiert, weil er keinen Anreiz dazu hat.“
Ein anderer Ex-Mitarbeiter ergänzte: „Ich wurde in einen Focus-Plan (Performance Improvement Plan) gesteckt, weil meine ‚Beiträge für das Management nicht sichtbar‘ waren. In einem solchen Umfeld habe ich keinerlei Anreiz, einen versteckten Fehler im Code eines Kollegen von mir aus zu finden und zu beheben — wenn ich ihn behebe, lande ich am Jahresende trotzdem in dem Prozentsatz der ‚ineffizienten‘ Mitarbeiter. Warum also sollte ausgerechnet der Kollege mit dem Bug nicht derjenige sein?“
Es gibt selbstverständlich auch Gegenstimmen. Ein ehemaliger AWS-Manager hielt dagegen: „Jede Kundenwirkung in dieser Größenordnung löst einen COE-Bericht (Correction of Errors) aus, also eine Reihe zwingender Verbesserungsmaßnahmen, die mindestens einen Personenmonat verschlingen. Ein COE ist für das ganze Team ein gewaltiger Ärger — und das allein bildet einen starken Anreiz, Probleme gar nicht erst entstehen zu lassen.“
Der Autor bezieht nicht Stellung. Beide Sichtweisen können zugleich zutreffen — die Kulturunterschiede zwischen Abteilungen und Hierarchieebenen sind gewaltig. Aber genau das zeigt: In einer Organisation mit Zehntausenden Ingenieuren können systematische Lücken auch dann durchrutschen, wenn alle ihr Bestes wollen.
5. Wie hat AWS reagiert?
Der öffentliche Zeitverlauf aus dem AWS Health Dashboard:
- 17. Juli, 3:52 Uhr PDT: AWS bestätigt als Ursache „ein Problem mit der Einheitenpreisgestaltung im Subsystem zur Berechnung der geschätzten Rechnungen“ und stoppt die Berechnung der Rechnungsschätzung.
- 4:58 Uhr: Zwei Reparaturwege werden parallel versucht — das Zurückrollen der letzten Änderung oder die Wiederherstellung der zuletzt korrekten Daten.
- 5:54 Uhr: Interne Überwachung zeigt, dass das Abrechnungssubsystem korrekte Schätzungen erzeugen kann; weitere Validierung läuft.
- 7:53 Uhr: Schlechte Nachrichten — das Rollback hat das Problem nicht gelöst; beide Reparaturwege werden weiterverfolgt. Die Aktualisierung der Rechnungsschätzung bleibt pausiert.
- 9:59 Uhr: Ursache lokalisiert und behoben; die Neuberechnung der Rechnungsdaten für alle Kunden beginnt. Ein Teil der Kunden soll innerhalb von 3 Stunden wiederhergestellt sein, alle bis Mittag des 18. Juli.
- 12:56 Uhr: Der Fortschritt ist langsamer als erwartet. Die vollständige Wiederherstellung wird auf den frühen 19. Juli verschoben. Die Erklärung betont: „Die angezeigten Rechnungsschätzungen spiegeln keine tatsächliche Nutzung und keine tatsächlichen Gebühren wider. Kunden müssen nichts unternehmen.“
Ein „fehlendes Maß“-Bug zu reparieren kostete AWS über 24 Stunden — und der erste Reparaturversuch schlug fehl. Das zeigt wiederum: Selbst für AWS-eigene Ingenieure ist das Beheben von Fehlern im eigenen System nicht trivial.
6. Was bedeutet das?
Das Ereignis verursachte letztlich keinen echten finanziellen Schaden — niemandem wurde zu viel abgebucht. Aber die aufgedeckten Probleme reichen weit tiefer als „ein Ingenieur hat sich vertippt“.
Erstens: Die Cloud-Abrechnung ist zu einem System geworden, das „niemand vollständig versteht“. AWS ist nur das extremste Beispiel; Google Cloud und Microsoft Azure stehen vor demselben Problem. Wenn die Komplexität eines Systems die Auffassungsgabe eines einzelnen übersteigt, ist es kein kontrollierbares Werkzeug mehr, sondern eine Blackbox, die man nur „beobachten, vermuten und hoffen kann, dass sie nicht versagt“.
Zweitens: Das KI-Zeitalter erhöht den Einsatz. Erst vergangene Woche kündigte AWS an, eine Milliarde Dollar in kundenorientierte KI-Ingenieurteams zu investieren. Die Monatsrechnung einer einzelnen KI-Trainingsaufgabe kann bereits Hunderte von Millionen Dollar erreichen. Wenn die echten Rechnungsbeträge derart gigantisch werden, wiegt ein Abrechnungsfehler — selbst nur in der „Schätzanzeige“ — an gesellschaftlicher Panik und Vertrauensverlust weit schwerer als früher.
Drittens: Dieser Bug ist nicht das erste Mal und wird nicht das letzte Mal sein. Der Ex-AWS-Ingenieur donavanm erlebte exakt denselben Fehler selbst und wurde um 2 Uhr morgens hochgeholt, um ihn zu beheben. Das bedeutet, die Lücke existiert im AWS-System seit mindestens einigen Jahren, trat mindestens zweimal auf und löste beide Male massive Kundenpanik aus — wurde aber nie systematisch geschlossen.
Beim Verfassen denkt der Autor an donavanms Beschreibung der AWS-Abrechnungsarchitektur zurück: „Die Messdaten eines Dienstes sind nicht direkt mit dem Preis verknüpft.“ Frei übersetzt heißt das: Zwischen deiner Nutzung und deiner Rechnung liegen mindestens zwei manuell zu konfigurierende Abbildungsschichten. Schreibt man eine davon falsch, ist aus 5 Dollar eine Milliarde geworden.
Referenzen
- HN-Diskussionsbeitrag: Die Debatte auf Hacker News über ungenaue AWS-Rechnungsschätzungen; der ursprüngliche Poster nprateem zeigte den Screenshot einer 1,7-Milliarden-Dollar-Rechnung und löste eine lebhafte Diskussion mit 992 Punkten und 618 Kommentaren aus (item?id=48945241).
- Root-Cause-Analyse von Ex-AWS-Ingenieur donavanm: Detaillierte Erklärung, wie ein falsch konfigurierter Preiseinheitentyp (Byte statt GB) die Rechnung um das Milliardenfache aufbläht und wie die AWS-Architektur Messdaten und Preise trennt.
- AWS Health Dashboard-Meldung: Die offizielle Statusseite von AWS mit dem vollständigen Zeitverlauf des Vorfalls „Billing Console — ungenaue Rechnungsschätzdaten“, von der Ursachenbestätigung bis zum Abschluss der Reparatur.
- Bericht von The Next Web: Zusammenfassende Berichterstattung über das Ausmaß des Vorfalls, einschließlich der Reaktionen auf Reddit (0,19 Dollar Monatsgebühr werden zu 25 Milliarden) und des AWS-Reparaturplans.
- Bericht von Cyber Kendra: Zitiert den Screenshot eines 1,5-Billionen-Dollar-Betrags, den Nutzer @Bharath_uwu auf X veröffentlichte, sowie die offizielle Antwort von AWS Support.
- Bericht von TechRadar: unter dem Titel „My soul left my body“ zitiert mehrere Panikreaktionen von Nutzern, darunter den Extremfall, dass jemand sämtliche Cloud-Ressourcen löschte.
