Wer dem offiziellen AWS-Amplify-Leitfaden folgte, bekam eine Rechnung über 1.100 $

 (elliott-king.github.io)
1 Punkte von GN⁺ 2024-11-15 | 1 Kommentare | Auf WhatsApp teilen
  • Nach einem Experiment mit dem offiziellen Leitfaden zur OpenSearch-Integration von AWS Amplify stiegen die Kosten für Amazon OpenSearch Service trotz geringer Nutzung innerhalb eines Monats auf 1.124,88 $
  • Die Kosten summierten sich, weil die von npx ampx sandbox erstellte OpenSearch domain auch nach dem Beenden und Löschen der Sandbox bestehen blieb und beim nächsten Lauf eine neue Domain hinzukam
  • Die offizielle Konfiguration erstellt standardmäßig eine r5.large.search-Instanz; der Standardwert von mindestens 134 $ pro Monat war weder im Boilerplate-Code noch im Leitfaden ersichtlich
  • AWS Support gewährte für OpenSearch und Storage einmalige Credits und verlangte zur Vermeidung einer Wiederholung die Einrichtung von AWS Budgets
  • Wer Amplify zusammen mit OpenSearch nutzt, sollte nach dem Löschen der Sandbox verbliebene Ressourcen und den standardmäßigen Instanztyp selbst prüfen, um unerwartete Kosten zu vermeiden

Unerwartete OpenSearch-Kosten

  • Nachdem in AWS Amplify nach dem offiziellen Leitfaden zur OpenSearch-Integration gearbeitet wurde, lag die AWS-Rechnung einige Wochen später bei über 1.200 $
  • Der im Support-Fall erfasste Dienst war Amazon OpenSearch Service, mit einer Monatssumme von 1.124,88 $
  • Es gab bereits 2020 Erfahrung mit Amplify und OpenSearch; für private Nutzung galt das mit etwa 50 $ pro Monat zwar als teuer, aber nicht in der Größenordnung von 1.200 $
  • AWS Customer Support prüfte den Fall im Detail und nahm für die unerwarteten Kosten eine Billing Adjustment in Form einer one time courtesy vor
  • Im Support-Prozess wurden Credits für OpenSearch und Storage-Dienste gewährt, außerdem wurde die Einrichtung von AWS Budgets verlangt
    • AWS Budgets kann künftige Ausgaben für bestimmte Dienste oder für AWS insgesamt prognostizieren und Benachrichtigungen senden, wenn eine Budgetüberschreitung erwartet wird

Ressourcen, die der offizielle Leitfaden erstellt

  • Der Amplify-Quickstart erstellt mit von AWS bereitgestelltem Code eine kleine TODO-Notiz-App; Amplify erzeugt dabei eine DynamoDB-Datenbank und authentifizierte CRUD-Requests
  • Lokales Ausführen ist ebenfalls möglich, aber Amplify erstellt zusätzlich eine erreichbare Domain
  • Im Schritt zur OpenSearch-Konfiguration wird TypeScript-Boilerplate geschrieben, um Amplify-Ressourcen zu deklarieren
    • Die DynamoDB-Tabelle wird als Variable erfasst und in der Pipeline referenziert
    • Eine OpenSearch-Instanz, ein Index und ein indexMapping werden erstellt
    • Es wird eine Query geschrieben, die auf Daten in OpenSearch zugreift
    • Eine OpenSearchIngestionService pipeline wird erstellt, die Daten von DynamoDB nach OpenSearch kopiert
  • Die zugehörige Konfiguration wird zusammen mit dem Frontend-Code als TypeScript/JavaScript im Repository verwaltet
  • npx ampx sandbox startet AWS-Dienste und erkennt Konfigurationsänderungen, um bestehende AWS-Dienste automatisch anzupassen

Domains, die nach dem Löschen der Sandbox bestehen blieben

  • Diese Konfiguration umfasst mehrere Ressourcen, darunter eine DynamoDB-Datenbank, einen OpenSearch-Service, eine OSIS pipeline und IAM-Rollen
  • Das offizielle Boilerplate erstellt standardmäßig eine r5.large.search-OpenSearch-Instanz
    • Dieser Standardwert war weder im Boilerplate-Code noch im Leitfaden ausdrücklich sichtbar
    • r5.large.search kostet mindestens 134 $ pro Monat
  • Wenn man nach einem Arbeitstag die Sandbox mit CTRL-C stoppt, erscheint eine Abfrage, ob dauerhaft gelöscht werden soll; der Nutzer kann Y auswählen
  • Dabei wird DynamoDB gelöscht, in der AWS-Konsole bleibt die OpenSearch domain jedoch bestehen
  • Wird am nächsten Tag npx ampx sandbox erneut ausgeführt, wird eine neue OpenSearch-Instanz erstellt; auch npx ampx sandbox delete löscht die ursprüngliche Instanz nicht
  • Wiederholt man diesen Vorgang, bleiben für dasselbe Projekt mehrere OpenSearch domains im Hintergrund bestehen und verursachen weiter Kosten

Möglicher Bug und standardmäßiger Instanztyp

  • Dieses Verhalten wirkte wie ein großer footgun und war zum damaligen Zeitpunkt auch nach dem AWS-Support-Ticket nicht behoben
  • Es gab ältere relevante Bug-Reports, aber innerhalb des letzten Jahres wurde kein Eintrag gefunden
  • Möglich ist, dass OpenSearch domains in v1 korrekt gelöscht wurden, in v2 aber nicht; das ist jedoch nicht als Ursache bestätigt
  • Der aktuelle Ablauf läuft nicht über die Amplify CLI, sondern über npx
  • Auch dass r5.large.search der standardmäßige Maschinentyp ist, bleibt ein Risikofaktor
    • Besser wäre es, das Feld ohne Standardwert verpflichtend zu machen
    • Wenn der Leitfaden r5.large.search als Standardwert zeigen würde, könnten Nutzer das leichter erkennen
    • Dieser Standardwert ist nicht Amplify-spezifisch, sondern Teil von AWS CDK, daher wird dies nicht allein als Verantwortung des Amplify-Teams gesehen

Vorsicht bei der Nutzung von Amplify und OpenSearch

  • Es war zu erwarten, dass Tools, die die Entwicklung mit neuer Technologie beschleunigen, teurer sein können als bare metal; diese Kosten gingen jedoch darüber hinaus
  • Über die budget console von AWS kann man Warnungen erhalten, wenn die erwarteten Ausgaben das Budget überschreiten
  • Schon das Befolgen nur des OpenSearch-Abschnitts erstellt ein IAM-Konto, eine OpenSearch domain, eine OSIS pipeline, eine log group und S3 storage, sodass viele versteckte Ressourcen entstehen
  • OpenSearch wird häufig von Unternehmenskunden genutzt und kann daher als „fortgeschrittener“ Dienst gelten; von Nutzern wird möglicherweise erwartet, das AWS-Ökosystem besser zu verstehen
  • OpenSearch wurde wegen der Unterstützung von geo_point-Bounding-Box-Queries verwendet, aber es ist unklar, ob dies auch mit einem einfacheren Produkt möglich gewesen wäre
  • Laut Update wurde der AWS-Leitfaden später korrigiert; drei Monate zuvor, als das Problem erstmals gemeldet wurde, war er noch nicht aktualisiert, aber vor Veröffentlichung des Beitrags scheinen Arbeiten an einem Dokumentations-PR begonnen zu haben

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-11-15
Meinungen auf Hacker News

  • Abrechnungsbenachrichtigungen sind ein schlechter Witz; tatsächlich braucht es harte Ausgabenlimits.
    Beim Onboarding sollte auch gezeigt werden, wie man diese Limits setzt.
    Ein Geschäft auf Blankoschecks und versehentlichen Gebühren aufzubauen, ist fragwürdig und erhöht die Einstiegshürde erheblich.
    Je häufiger Entwickler Fälle sehen wie „Ich habe ein 20-Minuten-Tutorial befolgt und wurde um meine gesamten Ersparnisse abgerechnet; dieses eine Mal hat der Support es erlassen, aber beim nächsten Mal hätten sie mir wohl noch das Haus weggenommen“, desto weniger Lust haben sie, AWS-Produkte auszuprobieren.

    • Das ist kein reines AWS-Problem; Cloud-Anbieter scheinen im Großen und Ganzen nur in zwei Kategorien zu fallen:
      Anbieter wie AWS oder DigitalOcean, die das Risiko auf die Kunden abwälzen, und Anbieter, die dubiose „unbegrenzte“ bzw. „nicht gemeterte“ Tarife verkaufen.
      Beides ist nicht das, was man will.
      Wünschenswert wäre ein Anbieter, bei dem man mit klaren, dokumentierten Limits sauber Kapazitäten planen kann, bei dem die Kunden das Verfügbarkeitsrisiko tragen, das finanzielle Risiko aber der Anbieter.
      Wenn es nicht übertrieben ist, wäre ich auch bereit, dafür eine höhere feste Gebühr zu zahlen.
    • Harte Ausgabenlimits wären für AWS’ Kernkunden, also Enterprise-Kunden, fast schon kontraproduktiv.
      Es gibt kaum versehentliche Gebühren, die schlimmer wären als Downtime oder Datenverlust bei einer wichtigen Anwendung.
      Selbst wenn es nur eine Option wäre, könnte die Buchhaltung Druck machen, sie zu nutzen, und wenn dann etwas schiefgeht, könnte daraus ein Datenverlustvorfall werden.
      Für Cloud-Anbieter, die sich an Indie-Entwickler oder kleine und mittlere Unternehmen richten, kann das sinnvoll sein.
    • In HN-Kommentaren hieß es mehrfach, der AWS-Abrechnungscode sei riesiger Spaghetti-Code, weshalb intern große Angst bestehe, größere Änderungen daran anzufassen.
      Das gehört zu den interessanteren internen Einblicken, die ich dort erfahren habe.
    • Ich hatte Interesse an AWS, habe mich aber genau aus solchen Gründen nie wirklich darauf eingelassen.
      Es ist sicherer, einen günstigen VPS mit Festpreis zu nutzen, als es später zu bereuen.
    • Das sollte reguliert werden.
      Amazon darum zu bitten, etwas zu tun, bringt wenig.
      Amazon und andere Anbieter müssen gesetzlich dazu gezwungen werden, das Geld der Nutzer zu respektieren.
      Unternehmen tun grundsätzlich nicht das, was ethisch oder volkswirtschaftlich gut ist, sondern das, womit sich Geld verdienen lässt.

  • Im Vergleich ist das zwar Kleinkram, aber nachdem ich versucht hatte, eine App auf ECS bereitzustellen, eine 100-Dollar-Rechnung bekam, habe ich beschlossen, AWS nie wieder zu nutzen.
    Dass der Service nicht hochkam, lag zwar an meiner App, aber in CloudWatch erschienen nur etwa 20 % der Logs, sodass ich fünfmal neu deployen und Änderungen vornehmen musste, nur um Logs zu bekommen, und danach noch einmal fünf Deployments brauchte.
    Jede fehlgeschlagene Bereitstellung wurde berechnet, und nach etwa zwei Tagen Frust löschte ich das Konto und deployte auf der DigitalOcean App Platform.
    Auch dort scheiterte das Deployment wegen des App-Fehlers, aber die Logs erschienen jedes Mal; ich konnte es innerhalb von 10 Minuten beheben und starten, und die Gesamtrechnung betrug nur ein paar Cent.
    Seit diesem Tag habe ich mir geschworen, AWS niemals zu nutzen und auch nicht zu empfehlen, wenn es irgendeine Alternative gibt.

    • Ich habe nur Azure genutzt, aber ECS scheint Azure Container Apps zu entsprechen.
      Für Entwicklung und Tests war das verbrauchsbasierte Abrechnungsmodell sehr günstig.
      Ich weiß nicht, wie es bei großen Workloads aussieht, aber pro Deployment abzurechnen wirkt seltsam.
    • Als ich erfuhr, dass man Container nicht wie bei GCP direkt auf EC2 deployen kann, habe ich AWS aufgegeben.
      Bei großen Projekten ist der Support vielleicht besser, aber für kleine bis mittlere Größenordnungen ist GCP deutlich besser.
      Es hat die passenden Grundbausteine für die heutige Container-Nutzung und außerdem BigQuery.

  • In dem Skript, das dieser npx-Befehl ausführt, scheint es einen offensichtlichen Bug zu geben.
    Der Autor hat recht: Bei einem Tutorial sollten zu 100 % die billigsten Ressourcen ausgewählt werden, und wenn man das delete-Unterskript ausführt, sollten die Ressourcen aufgeräumt werden.
    Es ist nicht fair zu erwarten, dass Entwickler nach so etwas paranoid ihr gesamtes AWS-Konto durchkämmen müssen, um verwaiste Ressourcen zu finden.
    Wenn ein Startup sich so verhalten würde, würde man das dann auch mit „So etwas passiert eben, man muss vorsichtig sein“ abtun?
    Ich verstehe nicht, warum für AWS ein anderer Maßstab gelten soll.

    • Genau das ist einer der nervigsten Punkte an AWS.
      Es gibt keine einfache Möglichkeit, alle Ressourcen zu sehen, für die ich gerade bezahle.
      Falls es sie doch gibt, habe ich sie nicht gefunden.
      Ohne eine leicht verständliche Übersicht fühlt es sich an, als hätte ich mein Konto nicht vollständig unter Kontrolle.
    • Wenn ich etwas Neues nutzen muss, prüfe ich als Erstes, ob ich eine feste monatliche Rechnung bekommen kann.
      Außerdem schaue ich, was passiert, wenn ich darüber hinausgehe, und ob sich unerwartete Kosten begrenzen lassen.
      Wenn nicht, suche ich etwas anderes.
      Seit der Änderung der Google-Maps-Abrechnung vor einigen Jahren bin ich auch sehr vorsichtig geworden, uns tief an „kostenlose“ Google-Dienste zu binden; am Ende wurde das teuer.
    • Gibt es überhaupt eine einfache Möglichkeit, alle Ressourcen in einem AWS-Konto aufzulisten?
      Ich musste immer nach Service und Region prüfen, was mühsam und fehleranfällig war.
    • Aus Amazons Sicht ist das kein Bug, sondern ein Feature, weil sie damit leicht 1000 Dollar verdienen können.
      Selbst wenn sie es als Bug betrachten, wird es eine viel niedrigere Priorität haben als andere Dinge, die ihre eigene Gewinn- und Verlustrechnung direkt treffen.
    • Ich stimme zu, dass es nicht fair ist, von Entwicklern paranoide Prüfungen zu erwarten.
      Realistisch betrachtet ist es aber vernünftig.
      Wenn ich auf AWS etwas baue, behandle ich AWS wie ein außer Kontrolle geratenes, feindseliges Finanzinstitut.

  • Wegen solcher Fälle schiebe ich es seit Jahren auf, mich wirklich in AWS einzuarbeiten.
    Es sollte einen standardisierten Lehrgang geben, in dem Leute kostenlos experimentieren können, ohne Kreditkartendaten anzugeben.
    Stattdessen scheint es Büroangestellte zu geben, die kalkulieren, dass man hier und da durch „Benutzerfehler“ Tausende Dollar herausziehen kann.
    Solche Abrechnungen anzufechten ist schwierig, in manchen Fällen sogar unmöglich.
    Ich werde nicht der Einzige sein, der AWS-Umgebungen meidet, aus der berechtigten Angst heraus, mit einer riesigen Rechnung aufzuwachen.

    • Dass AWS in so einer Situation keine Erstattung gewährt, ist sehr ungewöhnlich; daher ist es schwer, das als Strategie zu sehen, aus Benutzerfehlern Tausende Dollar zu pressen.
      Wahrscheinlich halten sie Erstattungsabwicklung für weniger aufwendig, als korrekte und günstige Tutorials bereitzustellen.
      Das rechtfertigt das Verhalten nicht, aber ich habe sogar schon eine rechtmäßig entstandene Rechnung über 600 Dollar für AWS Textract storniert bekommen.
      Damals arbeitete ich bei einem Unternehmen im Milliarden-Dollar-Bereich.
    • Ich glaube, der Grund, warum Leute in solche Zahlungssituationen geraten, ist, dass sie sich eben nicht wirklich tief mit AWS beschäftigen.
      Die Preistabellen sind leicht zugänglich und nicht immer einfach zu verstehen, aber die meisten Kosten steigen nahezu linear und sind daher relativ leicht zu testen.
      Wrapper-Services wie AWS Amplify, CloudFormation und diverse Stack-Dienste sollte man besser meiden.
      Man kann die Kernservices direkt verwenden.
      Jeder Service hat eine API, und einen an einen IAM-Benutzer gebundenen API-Key zu bekommen, ist so einfach wie ein Buttonklick.
      Der Rest lässt sich durch geeignetes Caching und dadurch steuern, dass man das Kostenmodell an das Umsatzmodell anpasst.
      Man muss die Kosten automatisch skalierender Services so gestalten, dass sie unabhängig von der aktuellen Nachfrage nahezu ein fester Anteil des Umsatzes bleiben.
      Bandbreite ist bei AWS der wahre Albtraum, aber in der Konsole gibt es automatisch langfristige Rabatte, und über einen Vertriebsansprechpartner kann man etwas bessere Vertragsrabatte bekommen.
      Deshalb würde ich EC2 meiden; da auch die interne Bandbreite von EC2 teurer ist, halte ich es für besser, Lambda + S3 + CloudFront direkt zu nutzen.
      Nach etwa drei Monaten konnte ich bei der Umsetzung neuer nutzerseitiger Funktionen ziemlich leicht vorhersagen, welche Servicekombination am kosteneffizientesten ist.
    • A Cloud Guru / Pluralsight hat Funktionen, die „Cloud Playground“ oder „sandboxes“ heißen.
      Das könnte für solche Zwecke geeignet sein, aber ich habe es nicht selbst ausprobiert und bin mir daher nicht sicher.
    • Das Geld, das durch Benutzerfehler dieser Art entsteht, dürfte für AWS insgesamt Peanuts sein.
      Meiner Erfahrung nach neigte AWS eher dazu, Probleme zu vermeiden, die durch Reputationsschäden teurer werden könnten.
      AWS ist nicht billig, und in manchen Fällen – besonders bei Datenübertragungskosten – extrem teuer, aber ich glaube nicht, dass es ihre Art ist, Kunden auszutricksen, damit sie versehentlich ein paar Hundert Dollar mehr ausgeben.

  • Klingt typisch nach AWS.
    Vor ein paar Monaten bin ich dem offiziellen SageMaker-Quick-Start-Guide gefolgt, um Llama 2 laufen zu lassen. Es war tatsächlich sehr schnell eingerichtet, aber am nächsten Tag sah ich, dass pro Tag 400 Dollar anfielen.
    Die Rechnung wurde storniert, aber ich habe definitiv gelernt, dass man offiziellen Guides nicht trauen sollte.

    • SageMaker gehört aus Produktsicht zu den enttäuschendsten Dingen und ist ein klares Beispiel für enshittification.
      In der frühen Produktphase 2017–2018 war die Einrichtung ziemlich intuitiv.
      Notebook-Instanzen, Inferenz, eine REST API fürs Serving, etwas EFS und die Tatsache, dass S3 im Zentrum des Services stand, waren klar verständlich.
      Auch die Preise waren in sich geschlossen, sodass es keine Überraschungen gab.
      Insgesamt fühlte es sich wie DigitalOcean an, und auch Data Scientists mit Grundwissen und Neugier für Infrastruktur konnten günstige, vorhersehbare und einfache Setups bauen.
      Heute gibt es Wrangler, Feature Store und RStudio, die User Experience der Notebook-Konsole ist furchtbar, und intern verschieben mehrere Services Daten und stellen das in Rechnung.

  • Statt des aufgeblähten AWS-SDK musste ich notgedrungen rohe HTTP-Requests senden; mit dem Header content-type: application/json schlug es fehl, mit content-type: application/x-amz-json-1.0 funktionierte es.
    Mit so einem nonsense sollten sie wirklich aufhören.

    • Bei fast allem von AWS, das ich in meiner Karriere angefasst habe, hatte ich ein ähnliches Gefühl.
      Ohne klaren Nutzen ist es übermäßig aufgebläht, übermäßig komplex oder voller seltsamer Eigenimplementierungen.
    • Ehrlich gesagt sind das durchgesickerte interne Details.
      Intern nutzen die meisten Apps das alte Coral-Framework und dieses JSON-Format mit klar definierten Formen für Eingaben, Ausgaben und Fehler.

  • Alle offiziellen AWS-Guides sind darauf ausgelegt, einen dazu zu bringen, möglichst viele AWS-Services zu verwenden, und entsprechend steigt auch das Ausgabenrisiko.
    Man muss alles, was AWS empfiehlt – also GUI-Defaults, CLI-Tools, Guides, empfohlene Architekturen usw. –, extrem kritisch betrachten.
    Es gibt einen Grund, warum Unternehmen hoch bezahlte Stellen dafür haben, Kolleginnen und Kollegen dabei anzuleiten, AWS kosteneffizient und risikoarm zu nutzen.

    • Stimmt.
      Bei kleinen Deployments oder Tests sind die teuersten Teile fast immer Nebensächlichkeiten oder die neuesten empfohlenen Services anstelle einfacherer Alternativen.

  • Wenn du OpenSearch wegen geo_point-Bounding-Box-Queries verwendest: Wie wäre es mit PostgreSQL + PostGIS?
    https://postgis.net/docs/using_postgis_query.html

  • Ich glaube, diese reibungslose Einrichtung, die wenig intuitive User Experience und Oberfläche, die geringe Hemmschwelle bei der Kreditkartenregistrierung und die gebündelte Abrechnung zwischen Services wie AWS Batch + Lambda + EC2 sind Teil des Geschäftsmodells.
    Ich weiß nicht genau, wie ich es ausdrücken soll, aber es ist wie ein moderner Freizeitpark, bei dem man Eintritt zahlt und danach für jede Attraktion und sogar für die Toilette separat bezahlen muss.

    • So fühlt es sich für mich auch an.
      Das Cloud-Abrechnungsmodell schiebt die Verantwortung unter dem Deckmantel von „Flexibilität“ und „Anpassbarkeit“ auf die Nutzer ab.
      Man stelle sich eine Autovermietung vor, die jedes Bauteil millisekundengenau abrechnet – Nockenwellenumdrehungen, Reifenumdrehungen, Scheibenwischerbetätigung, Sitzheizungszeit – und dann sagt, der Kunde habe „Kontrolle“ über Nutzung und Budget, weil man für jeden Posten Benachrichtigungen einrichten kann.
      Schon die Defaults sind ein nutzerfeindliches und gefährliches Kostenmodell.