Geschätzte AWS-Rechnung wird mit 1,7 Milliarden US-Dollar angezeigt, übliche Kosten liegen unter 5 US-Dollar

• Für ein AWS-Konto, dessen übliche Kosten unter 5 US-Dollar liegen, wurde die geschätzte Rechnung für diesen Monat mit 1,7 Milliarden US-Dollar angezeigt
• Da die Abweichung zwischen tatsächlicher Nutzung und Rechnungsbetrag extrem groß ist, wird von ungenauen Daten zur geschätzten Abrechnung ausgegangen
• Der Verfasser hat zur Prüfung und Reaktion auf das Problem ein dringendes AWS-Support-Ticket erstellt
• Der Status der AWS-Services kann im AWS Health Dashboard überprüft werden
• Es wurde gefragt, ob andere Nutzer dasselbe Phänomen erleben, und später wurde auch ein entsprechender Reddit-Beitrag ergänzt

---

Ungewöhnlich hohe geschätzte Rechnung

• Die geschätzte AWS-Rechnung für diesen Monat wurde mit 1,7 Milliarden US-Dollar angezeigt, obwohl die üblichen Kosten des betreffenden Kontos unter 5 US-Dollar liegen
• Der Verfasser geht davon aus, dass diese große Abweichung nicht auf die tatsächliche Nutzung, sondern auf ungenaue Daten der geschätzten Abrechnung zurückzuführen ist

Prüfung und Reaktion

• Zur Überprüfung des Problems wurde ein dringendes AWS-Support-Ticket erstellt
• Der Servicestatus kann im AWS Health Dashboard überprüft werden
• Es wurde andere Nutzer gefragt, ob bei ihnen dasselbe Phänomen aufgetreten ist, und später wurde ein entsprechender Reddit-Beitrag geteilt

[GN⁺]

Kommentare auf Hacker News

• Ich habe bei AWS einmal denselben Fehler behandelt; die Ursache war ein Fehler bei der Einheiteneinstellung. Man wollte etwa 5 Cent pro GB berechnen, aber als im Tarifplan das GB fehlte, behandelte das System es als die Standardeinheit Byte. Daraus wurden 5 Cent pro Byte, und innerhalb weniger Stunden wurden einigen Kunden Rechnungen über Millionen Dollar angezeigt.
  Gegen 2 Uhr morgens wurde ich vom Support-Team angerufen, und bis 3 oder 4 Uhr waren der Fix und die Rechnungskorrekturen erledigt; kurz darauf ging auch eine Entschuldigungs-Mail raus. Die vom Service ausgegebenen Nutzungswerte sind nicht direkt mit dem Preis verknüpft; jede SKU bzw. jeder Rechnungsposten wird durch einen Tarifplan definiert, der Einheitentyp, Region und Preis pro Einheit enthält. Nutzungsdatensätze und Tarifpläne werden anhand von Account-ID, Region, SKU usw. zusammengeführt; wenn der Einheitentyp falsch angegeben ist, bricht die Umrechnung und es entstehen völlig absurde Rechnungsbeträge.

  • Gab es keine Tests? Heißt das, ein einziges scheinbar banales Detail falsch zu konfigurieren kann Hunderttausenden Admins nächtliche Pager-Alarme und Herzinfarkte bescheren?
    Klar, man wird sagen: „Das ist kein banales Detail, Michael!“: https://www.youtube.com/watch?v=3fGHaVn5rGo
  • Ich frage mich, ob das AWS-Abrechnungssystem für die Datenübertragung immer noch CSV-Dateien verwendet. Als ich vor gut zehn Jahren meinen ersten Bereitschaftsdienst bei AWS hatte, hatte irgendein „cleverer“ Engineer in ein Beschreibungsfeld von Produktionsdaten einen Testdatensatz wie „Was passiert, wenn ich in dieses Feld ein Komma einfüge“ geschrieben, wodurch die Abrechnung kaputtging.
    Ich sah zu, wie sich dieser Datensatz ausbreitete und die Regionen der Reihe nach auf dieselbe Weise ausfielen; eine einzelne Person hat damit unzähligen Leuten den Abend ruiniert. Man hätte einen Test-Endpunkt nutzen können, aber stattdessen wurde faktisch in der Produktionsumgebung getestet.
  • Das ist nichts, was man als Witz abtun sollte. Wenn jemand mit einer Vorerkrankung wie einer Herz-Kreislauf-Erkrankung plötzlich so einen Rechnungsbetrag sieht, kann diese Person durch Angst, Schock und Hilflosigkeit tatsächlich sterben.
  • Genau deshalb sorgt man immer dafür, dass Dinge laut fehlschlagen (fail loud), statt dumme Defaults zu wählen.
  • Ich frage mich, ob das am Tag der Einführung von gp3-EBS-Volumes passiert ist.

• Ich bekam nacheinander drei Warnmails, dass mein Budget das Limit von 18 Dollar überschritten habe, und als ich nachsah, lagen die Kosten bei 78 Millionen Dollar. Ich dachte erst an Phishing und loggte mich direkt in den echten Account ein, aber dort standen immer noch 78 Millionen Dollar; das war ein erheblicher Schock.

  • Ich würde wetten, dass die Beschreibung dieser Stellenausschreibung noch heute geändert wird: „Software Development Engineer II, AWS Invoicing“
    https://www.amazon.jobs/de/jobs/10428480/software-developmen...
    Dazu gehört eine schillernde Stellenbeschreibung, laut der man mit generativer KI, großen Sprachmodellen, Knowledge Graphs und agentischen Architekturen die Release-Vorbereitung, die Orchestrierung Cloud-nativer Services und die kontinuierliche Validierung automatisiert.
  • Meine Rechnung lag bei über 1 Milliarde Dollar. Zuerst hätte ich es fast als Phishing abgetan, aber es wirkte so echt, dass ich mich direkt bei AWS einloggte; als ich den erwarteten Rechnungsbetrag sah, bekam ich fast einen Herzinfarkt.
    Später fand ich auf der Support-Seite ein Störungsbanner, aber ich frage mich, warum es ausgerechnet auf der Billing-Seite, auf der steht „Sie schulden 1 Milliarde Dollar“, kein Hinweisbanner gab.
  • Auch mir kam die URL awstrack.me extrem verdächtig vor, und da ich so eine Warnung zum ersten Mal bekam, war ich überzeugt, dass es Phishing sei. Ohne auf den Link zu klicken, ging ich in die Konsole; dort gab es zwar eine Störung, bei der Rechnungsbeträge falsch angezeigt wurden, aber keine Erwähnung der E-Mail-Warnungen, sodass ich mir eher Sorgen machte, ob ein Angreifer die Störung ausnutzt, um unentdeckt zu bleiben.
    Nachdem ich die Logs geprüft hatte, wurde mir klar, dass der Störungshinweis lediglich den Wirkungsbereich nicht vollständig beschrieben hatte, und ich ging wieder Kaffee trinken. Beim nächsten Mal sollte ich wohl hier zuerst nachsehen.
  • Um einen alten Witz abzuwandeln: Wenn die AWS-Rechnung 78.000 Dollar beträgt, ist das mein Problem, aber bei 78 Millionen Dollar ist es Amazons Problem.
  • Bei einem Unternehmenskonto wurde ein Rechnungsbetrag von über 3 Billionen Dollar angezeigt.

• Dieser Fehler ist so absurd, dass er bald behoben sein wird, aber Anfang der 2010er habe ich einmal einen Fehler entdeckt, der tatsächlich in echten Rechnungen versteckt war. Bei einigen Servern wurden die EC2 Reserved-Instance-Rabatte falsch berechnet, und obwohl ich regelmäßig die detaillierte Nutzung in einer Tabelle mit 18 Tabs analysierte, passten die Beträge nicht; monatelang verfolgte ich die Differenz.
  Selbst nachdem ich die Ursache gefunden hatte, dauerte es ziemlich lange, AWS davon zu überzeugen, dass ihr System falsch lag, und in der Zwischenzeit häufte sich die Differenz weiter an. Nach 14 Monaten erhielt ich eine Rückerstattung von 7.000 Dollar; mir wurde gesagt, dafür sei die Genehmigung eines AWS-Verantwortlichen nötig gewesen, und seitdem habe ich keine Rechenfehler seitens AWS mehr gesehen.

  • Ein 7.000-Dollar-Credit an sich konnte damals auch ein nahestehender Product Manager oder Director ohne viel Aufsicht ausstellen. Das Problem war die Dauer von 14 Monaten: Korrekturen innerhalb desselben Abrechnungszeitraums sind einfach, und der unmittelbar vorherige Zeitraum ist zwar lästig, aber üblich; wenn man jedoch bis in frühere Geschäftsjahre zurück korrigieren muss, muss die Finanzabteilung involviert werden, und das ist deutlich schmerzhafter.
  • Meine Kollegen finden, dass ich mir den Cost Explorer viel zu detailliert ansehe, aber die Zeit, in der man merkwürdige Kosten aufspürt, hat sich meistens mehr als bezahlt gemacht. Ich werde wohl kaum Zeit im Gegenwert von 7.000 Dollar darauf verwendet haben, diesen Fehler zu verfolgen, und dabei habe ich wahrscheinlich auch größere Möglichkeiten zur Kostenoptimierung gefunden.
    Außerdem möchte ich kein Geld verschwenden, nur damit Jeff Bezos’ Yacht noch größer wird.
  • Für „wird bald behoben sein“ läuft das schon seit 12 Stunden. Offenbar verstehen Menschen den Code nicht, den ein Agent geschrieben und eingespielt hat.

• Die Einheit hätte ursprünglich GB of storage consumed sein sollen, wurde aber offenbar mit Bytes of storage consumed vermischt, was zu einem Fehler um den Faktor 2^30 führte.
  „Es wäre angebracht, die Berechnung anzuzweifeln. Ich wollte die Felddefinition nachschlagen, aber die Verbindung zum MCP-Server ist fehlgeschlagen, und statt zu verifizieren, habe ich geraten. Mein Fehler. Aber sehen Sie sich den gestiegenen Umsatz an!“

  • Man hat darum gebeten, den dem Kunden zu berechnenden Betrag zu ermitteln, und 0.45, 1.67 und 2.50 angegeben; die Summe ist also 4.62, es könnte aber auch eine andere Zahl sein. Vielleicht muss man sie aneinanderhängen, und wenn der Punkt Multiplikation bedeutet, wird aus 0 . 45 . 1 . 67 . 2 . 50 dann 3.015.000.
    Mit 0 multipliziert müsste es 0 sein, aber gar nichts zu berechnen geht nicht, also sind 3.015.000 Tausend Dollar die richtige Antwort.
  • Ob „Es wäre angebracht, die Berechnung anzuzweifeln“ eine Parodie oder eine echte Antwort ist, lässt sich inzwischen kaum noch unterscheiden. Selbst wenn man ein LLM auffordert, einen Satz zu schreiben, der so dumm ist, dass es ihn unmöglich ausgeben könnte, scheint es keine Grenze dieser Dummheit zu geben.
  • Heute habe ich einem lokalen Agenten eine CSV mit menschenlesbaren Größeneinheiten gegeben und ihn die Zeilen pro GB-Bereich zählen lassen; seltsamerweise interpretierte er MB als GB und lag völlig daneben. Im Nachhinein wäre es wohl schneller gewesen, es direkt in Excel zu berechnen.
  • Bei 2*30 ist das Ergebnis 60, also müsste man nur 28,3 Millionen Dollar zahlen; gemeint war aber vermutlich 2^30, und dann wären es 1,5 Dollar.
  • Das Abrechnungssystem per Vibe Coding zu bauen und den Umsatz um 9.000 % zu steigern, ist jedenfalls hervorragendes Material für eine Beförderung.

• Als ich morgens die Abrechnungswarnung sah, dachte ich, ich hätte versehentlich einen AWS-Key geleakt und 437 Milliarden Dollar ausgegeben. Zum Glück habe ich nicht so viel Geld, und ich bin AWS dankbar für einen Adrenalinschub wie nie zuvor, ganz ohne Kaffee.

  • Wenn ich AWS 437.000 Dollar schulde, ist das mein großes Problem; wenn ich 437 Milliarden Dollar schulde, ist das AWS’ großes Problem.
  • Es könnte sein, dass jemand dadurch tatsächlich einen Herzinfarkt erlitten hat oder gestorben ist. Dass Amazon solche Werte den Nutzern unverändert anzeigt, ist ein verantwortungsloser Umgang damit.
  • Ich bekam die Warnung, als ich gerade einschlafen wollte; der Betrag lag eindeutig über dem von mir gesetzten 16-Dollar-Limit.
  • Ich habe zwei Monate lang wegen eines gekaperten Kontos mit AWS gestritten. Obwohl meine monatlichen Kosten in den vorherigen drei Jahren bei etwa 20 Dollar lagen, verlor ich 20.000 Dollar und bekam weitere Rechnungen über Zehntausende Dollar; AWS half mir nicht, bis ich den Einbruch selbst stoppte.
    Nach Feierabend blieb ich die Nächte wach, lernte AWS-Infrastruktur-Scripting und bekam den Angriff unter Kontrolle, aber mir wurde sogar die Kontoschließung verweigert; auch die Forderung, für eine Fallprüfung eine Vereinbarung zur gemeinsamen Verantwortung zu unterschreiben, lehnte ich ab. Am Ende kontaktierte ich die Generalstaatsanwaltschaft meines Bundesstaats, die AWS direkt eine E-Mail schickte; keine 24 Stunden später rief ein AWS-Manager an, bereinigte das Konto und erstattete die 20.000 Dollar. Trotzdem wurde die Kontoschließung am Ende weiter verweigert, sodass es offenbar keinen Weg gibt, AWS vollständig zu verlassen; es fühlt sich nach der schlimmsten Art an, Geschäfte zu machen.
  • In meinem Fall waren es 500 Millionen Dollar, und meine Hände zitterten so stark, dass ich kaum mein Passwort eingeben konnte.

• Man sollte dem Account Manager die eigene Haushaltslage erklären und ihn großzügig bitten, ob man bis zur Besserung der Lage jeden Monat ein paar Milliarden Dollar in gutem Glauben zurückzahlen kann.

  • Man darf keine Schwäche zeigen. Man muss das frontal lösen und sich eine Kreditkarte mit höherem Limit besorgen.

• Wenn man der Bank 100 Dollar schuldet, ist das mein Problem; wenn man 1,7 Milliarden Dollar schuldet, ist das das Problem der Bank.

  • Als meine Frau bei ihrem früheren Arbeitgeber Veranstaltungen für ein mittelständisches Unternehmen betreute, lag der Saldo der Firmen-Amex nach Events normalerweise bei über 300.000 Dollar. Während ihres Mutterschutzes reichte die Vertretung die Rechnung nicht ein; als sie zurückkam, waren mehr als 500.000 Dollar offen, und es hatten sich jede Menge E-Mails und Sprachnachrichten von Amex angesammelt.
    Die Nachrichten waren anfangs höflich und wurden dann zunehmend dringlicher, aber sie wurden nie drohend oder feindselig.
  • Dieser Witz funktioniert nur, wenn man AWS tatsächlich Kosten in Höhe von 1,7 Milliarden Dollar verursacht hat. Wenn sie nur grundlos eine Rechnung ausgestellt haben, ist es weiterhin das Problem des Nutzers.
  • Dann lautet die nächste Frage, was passiert, wenn man der Bank 1,7 Billionen Dollar schuldet.
  • Für Elon Musk gilt das möglicherweise nicht.

• AWS hat wohl gesehen, dass Anthropic jemandem mit Nutzung 0 ganze 16 Millionen Dollar berechnet hat, und dachte sich, es gebe keinen Grund, bei ein paar Millionen aufzuhören.
  https://www.techtimes.com/articles/320266/20260712/anthropic...

  • Wenn das KI-Abrechnungs-Audit-Startup Vaudit Rechnungen von 60 Unternehmenskunden im Wert von 34 Millionen Dollar geprüft und dabei etwa 1,7 Millionen Dollar an Überberechnungen, also eine Fehlerquote von rund 5 %, gefunden hat, ist das ziemlich ernst.

• Mir ist kürzlich beim Bezahlen bei Whole Foods aufgefallen, dass die Chase Amazon Prime Card nicht mehr automatisch zuverlässig erkannt wird und Rabatte daher nicht automatisch angewendet werden. Ich frage mich, wie viele Kunden den vollen Preis zahlen, während sie einfach so bezahlen, wie es jahrelang problemlos funktioniert hat.
  Laut dem Kundenservice im Laden hat sich das im letzten Jahr geändert; sie vermuten, es sei eine unbeabsichtigte Folge davon, dass die Handflächen-Zahlfunktion abgeschafft wurde. Es hat nicht direkt damit zu tun, aber es lässt einen daran denken, was Amazon sonst noch nicht richtig berechnet.

  • Jetzt ist es Zeit für eine Sammelklage oder Tausende Bagatellverfahren. Selbst wenn es eine Schiedsklausel gibt, wäre der Aufwand, das alles zu bearbeiten, enorm; hoffentlich trifft jemand die richtige Entscheidung und erstattet automatisch.
  • In Systemen, die früher einfach und zuverlässig waren, entstehen inzwischen unzählige solche kleinen Probleme. Nicht alles davon liegt an Vibe Coding, aber man fragt sich, wie viele dieser Probleme das Ergebnis von Vibe Coding sind.

• Einmal wurden 20.000 Dollar Rechnungsbetrag tatsächlich vom Bankkonto abgebucht, und es dauerte Monate sowie die Einschaltung der Generalstaatsanwaltschaft des Bundesstaats, bis das Problem gelöst war und das Geld zurückkam. Danach wurden AWS-Produkte gar nicht mehr genutzt, und selbst kleine Aufgaben wurden zu Azure verlagert.
  Probleme mit AWS-Abrechnungen ziehen sich seit Jahren hin; online findet man leicht Fälle, in denen auf gekaperten Accounts monatelang Server fürs Kryptowährungs-Mining liefen und einem Studenten 60.000 Dollar berechnet wurden, ohne dass AWS das erkannt oder blockiert hätte.

  • AWS ist faktisch fast ein Versorgungsunternehmen; wenn man mit Abrechnungen nachlässig umgeht, wird man am Ende zwangsläufig entsprechend reguliert werden.
  • Für Dienste mit variablen Kosten sollte man immer eine Karte mit Ausgabenlimit verwenden.
  • Ich glaube nicht, dass die Erkennung gekaperter Accounts zu 100 % korrekt sein kann. Selbst wenn es für einen Menschen offensichtlich wäre, kann nicht proaktiv ein Mensch die Nutzung jedes einzelnen Accounts prüfen.
  • Die erste Lektion bei der Nutzung eines Dienstanbieters lautet: niemals automatische Zahlungen aktivieren. Das Risiko, dass ein Anbieter eigenmächtig das gesamte Geld vom Konto abbucht, wiegt viel schwerer als Bequemlichkeit oder Rabatte.
  • Eine Zeit lang hatte ich Teile meines Homelabs bei AWS. Ich war Lehrkraft in einem Kurs, in dem Studierende Cloud lernten, und der Dozent empfahl, für die Übungen eine Umgebung aufzusetzen. Also installierte ich ebenfalls einen LAMP-Stack mit MediaWiki auf einer EC2-Instanz im Free Tier. Die Ersteinrichtung war nicht schwierig, aber aus zwei Gründen bin ich AWS endgültig den Rücken gekehrt.
    Erstens war es selbst heute entweder unmöglich oder viel zu arbeitsintensiv, ein gewöhnliches, dem Internet ausgesetztes Linux-System ausreichend abzusichern. Selbst mit fail2ban und vielen gesperrten Ports kamen Spam-Angriffe auf Anwendungsebene durch. Zweitens war es praktisch unmöglich, pro Abrechnungszeitraum eine Obergrenze für Cloud-Ausgaben durchzusetzen. Auch wenn man meist innerhalb des Free Tier blieb, konnte eine falsche Einstellung oder ein aus dem Ruder laufender Ressourcenverbrauch zu einer hohen Rechnung führen, gegen die man nur schwer Einspruch erheben konnte – insbesondere auch durch Ursachen außerhalb der eigenen Kontrolle, etwa wenn externe Nutzer VPC-Ressourcen und ausgehenden Traffic verbrauchen. Deshalb habe ich den Account geschlossen, und ich habe großes Verständnis für Unternehmen, die zur Cloud statt zu eigener Infrastruktur gezwungen werden, ihre Kosten aber nicht kontrollieren können.