Wenn die (AWS) Cloud von den Kosten explodiert – ein S3-Bucket-Fall der schief gegangen ist

Irgendwie dumm gelaufen: Ein Software-Entwickler hat vor einigen Wochen ein privates AWS S3 Bucket aufgesetzt, aber leer gelassen. Als er zwei Tage später die AWS-Abrechnungsseite überprüfte, um sicherzustellen, dass das aufgesetzte S3-Bucket kostenlos bleiben würde, sah er sich mit aufgelaufenen Kosten von 1.300 US-Dollar konfrontiert. Dumm gelaufen, die Cloud kann schon echte "Schmerzen" bereiten.


Anzeige

Kostenschock bei der AWS-Cloud

Ich bin die Tage auf X über einen Tweet von Laura Wendel auf den betreffenden Sachverhalt gestoßen, den der Betroffene auf Medium im Beitrag How an empty S3 bucket can make your AWS bill explode geschildert hat.

In ganz kurz: Vor einigen Wochen begann der Entwickler mit der Arbeit an einem PoC für ein Dokumentenindizierungssystem für seinen Kunden. Dazu erstellte der gute Mann einen einzelnen S3-Bucket in der Region eu-west-1 und lud einige Dateien zu Testzwecken dorthin hoch. So weit so normal – wobei ich bei solchen Konstruktionen schon Bauchschmerzen hätte. Diese "Test-Cloud-Konten" sind sowohl bei Amazons AWS S3-Service als auch bei Microsofts Azure kostenlos. Ich erinnere mich, dass ich bei Microsoft Azure sogar zeitweise Konten mit 150 US-Dollar-Guthaben hatte. Aber Du weißt nie, ob Du mit dem Traffic im Rahmen dessen bleibst, was kostenlos ist.

Als der Entwickler zwei Tage später auf seiner AWS-Abrechnungsseite überprüfte, ob er noch im Rahmen Free-Tier-Grenzen läge, kam der Schock. Auf dem S3-Bucket waren bereits Kosten von 1.300 $ aufgelaufen. Obiger Tweet zeigt in der Grafik, dass an einem Tag fast 100.000.000 S3 PUT-Anforderungen auf die betreffende Instanz durchgeführt worden waren.

Woher kamen diese Anforderungen?

Standardmäßig protokolliert AWS keine Anforderungen, die für Ihre S3-Buckets ausgeführt werden. Solche Protokolle können jedoch mit AWS CloudTrail oder S3 Server Access Logging aktiviert werden. Nachdem der Software-Entwickler die CloudTrail-Protokolle aktiviert hatte, stellte er sofort Tausende von Schreibanforderungen fest, die von mehreren Konten oder von außerhalb von AWS stammten.

Erste Vermutung: Es ist eine Art DDoS-ähnlichen Angriff gegen das AWS-Konto, was aber keinen Sinn macht. Es stellte sich heraus, dass ein beliebtes Open-Source-Tools standardmäßig so konfiguriert war, dass es seine Backups in Amazon Web Services S3 speicherte. Als Platzhalter für einen Bucket-Namen wurde der gleiche Name verwendet, den der Entwickler für seinen S3-Bucket benutzt hatte. Das bedeutete, dass jede Bereitstellung dieses Open-Source-Tools mit Standardkonfigurationswerten versuchte, seine Sicherungen im S3-Bucket des Entwicklers zu speichern!

Der Fall hat gleich einige Implikationen, die einem beim Lesen des Beitrags hier so durch den Kopf gehen. So wird sofort der Sicherheitsaspekt auftauchen: Jemand krallt sich das AWS S3-Bucket mit dem Namen, der Default im Open Source-Tool verwendet wurde. Und schon bekommt er Backups von allen Benutzern, die die Standardkonfiguration nicht angepasst haben, auf sein S3-Bucket geliefert.

Der zweite Aspekt ist das Thema Kosten. Hier rät ein Nutzer: Erste Regel, die bei Cloud-Lehrgängen vermittelt wird: Namen für alle Ressourcen, deren Namespace global ist, zufällig (randomized) vergeben und Tags verwenden, um sie zu finden/zu organisieren. In Azure haben die Entwickler Ressourcengruppen festgelegt, um Dinge zu organisieren, schreibt der Betreffende.


Anzeige

Es dauerte nicht lange, bis diese Geschichte auch von Amazon bemerkt wurde, da der Beitrag auf Medium geteilt wurde. AWS-Chefevangelist Jeff Barr schrieb daraufhin in einem Tweet mit, dass das Unternehmen etwas gegen die Situation unternehmen werde:

Vielen Dank an alle, die uns auf diesen Artikel aufmerksam gemacht haben. Wir stimmen zu, dass Kunden nicht für unautorisierte Anfragen zahlen sollten, die sie nicht initiiert haben. Wir werden in Kürze mehr darüber berichten, wie wir diese Gebühren verhindern werden.

Was AWS genau unternehmen will, ist mir nicht klar. Aber der Fall zeigt, welche Fallen in der Cloud schlummern, und dass man sehr schnell als Entwickler oder Nutzer die Kontrolle über seine Daten verlieren kann.


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Cloud abgelegt und mit , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

9 Antworten zu Wenn die (AWS) Cloud von den Kosten explodiert – ein S3-Bucket-Fall der schief gegangen ist

  1. Hobbyperte sagt:

    Wie immer wenn man "Neuland" betritt … geht auch Schülern so, die nach dem Abschluss ins kalte Wasser fallen. Das wahre Leben, eigene Wohnung Mieten, Telefon-Verträge, (Verbraucher)-Kredite, Verkehrs-Recht, Zivil-Recht, Handelsrecht …. das Leben hält überall Fallen bereit und wartet nur darauf, das ein unbedarfte/r hinein tappt… Das ist bislang ja auch Teil des Geschäftsmodells unserer Binnen-Wirtschaft.

    • Bernd B. sagt:

      Nein.
      Der Entwickler hat bis auf die Namensgebung (und auch das konnte er vor her nicht wissen) wenig falsch gemacht – Amazon berechnete aber unauthotisierte Zugriffsversuche und die gab es eben zu Millionen.

  2. rpr sagt:

    Na das erinnert doch an die Zeiten als ausgehende Anrufe auch bei Besetzt Geld kosten sollten.
    Ist ewig her.

    • Pau1 sagt:

      was inzwischen aber durch eine, für den Angerufenen, kostenpflichtige SMS ersetzt wurde. Wenn der keinen Einzelnachweis hat, merkt er nicht einmal etwas davon.
      Und natürlich auch nicht Online abbestellbar.
      Es ist überall dasselbe.

      Das die Anbieter so jedes Vertrauen verspielen scheint unwichtig zu sein. Nur der -sehr kurzfristige- Gewinn zählt.

  3. OwenBurnett sagt:

    Also was kostenlos ist mus kostenlos bleiben,
    es muss der default bei allen kostenlosen angeboten sein das keine kosten anfallen können nur der dienst ab dreht wen man das kostenlose contingent ausreizt.
    Und bei bezahl angeboten müssen zwingend kosten Schranken einstellbar und by default auf nur ein paar 100€/$ gestellt sein.

    Unerwartete Rechnungen von tausenden von €/$ sollten als sittenwidrig zum schaden der Anbieter annulliert werden.

    • Pau1 sagt:

      Es geht ja seit ein paar Jahren durch die Gesetzgebung, dass man ein Limit von 40 Euro auf sein Handy setzen kann.
      Natürlich nicht aktiv beworben und nur durch den Operator einstellbar…
      Kaum jemand nutzt es…

  4. Daniel sagt:

    Der eigentliche Skandal aus meiner Sicht ist, dass 1) der Inhaber des Bucket für nicht authorisierte Zugriffe zahlen muss und 2) Regionen, die für das Bucket nicht freigeschaltet wurde, trotzdem kostenpflichtig an das Bucket weitergeleitet werden. Damit kann ein kleiner Betreiber eins Buckets in den Ruin getrieben werden, wenn er Klarnamen seiner Produkte oder Services als Bucketname verwendet. Ganz zu schweigen von Expressungen.

    • Bernd B. sagt:

      Ich habe es nicht weiter verfolgt, aber Amazon wollte sich drum kümmern:

      Siehe
      twitter .com/jeffbarr/status/1785386554372042890

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.