Ich kehrte zu AWS zurück und wurde erneut daran erinnert, warum ich gegangen bin
(fourlightyears.blogspot.com)- Ich war von Anfang an ein Unterstützer von AWS, mochte AWS aber irgendwann wegen angestauter Unzufriedenheit wie dem *komplizierten Abrechnungsmodell und der allgemeinen Komplexität der Plattform nicht mehr.
- Die hohen Kosten von DynamoDB, Egress-Gebühren von bis zu 9 Cent pro Gigabyte und doppelte oder dreifache Abrechnung für interne Datenbewegungen sind aus meiner Sicht weiterhin teuer und schwer nachzuvollziehen.
- Ich kehrte zurück, um Claude auf AWS Bedrock zu testen und eine 192-Core-Maschine zu benchmarken, doch wegen plötzlicher Aktivität auf einem ruhenden Konto wurde eine Warnung wegen vermuteter Sicherheitsverletzung ausgelöst und das Konto gesperrt.
- Durch die Kontosperre wurde sogar AWS WorkMail für den geschäftlichen Einsatz unterbrochen, und unter dem kostenlosen Supportplan wurde das Konto vier Tage lang nicht wiederhergestellt.
- Ich kam zu dem Schluss, auch die bei AWS verbliebenen Dienste vollständig umzuziehen und endgültig zu gehen.
Vom frühen AWS-Befürworter bis zum Abschied
- Ich war seit der Zeit, als AWS noch ein kleinerer Dienst rund um SQS, S3, EC2 und SimpleDB war, ein starker Befürworter und organisierte in Melbourne sogar die erste Veranstaltung, bei der ein AWS-Mitarbeiter aus den USA AWS vorstellte.
- Cloud Computing war ein großer Wandel, weil Startups damit innerhalb von Minuten eigene Computersysteme betreiben konnten, ohne Systeme in Rechenzentren selbst aufzubauen und zu betreiben.
- Etwa 15 Jahre lang glaubte ich stark an AWS, doch mit der Zeit summierten sich die unangenehmen Aspekte, bis ich AWS irgendwann nicht mehr mochte.
Unzufriedenheit mit AWS, die sich im Lauf der Zeit angesammelt hat
-
Client-Bibliotheken und der Wechsel zu Python
- AWS entwickelte in den ersten sechs Jahren keine eigenen Client-Bibliotheken, sondern überließ es der Community, Bibliotheken für Sprachen wie Python zu implementieren, was so wirkte, als würde die Last auf Programmierer abgewälzt, die ihre Zeit kostenlos investierten.
- Dass AWS für den Wechsel von Python 2 auf Python 3 übermäßig lange brauchte, blieb ebenfalls ein großer Kritikpunkt.
-
DynamoDB und die Kostenerfahrung
- Schon am ersten Tag mit DynamoDB entstand eine Rechnung von 75 Dollar, und nicht nur die Kosten, sondern auch das System selbst fühlten sich wie die schlimmstmögliche Ausführung an.
-
Kosten für Datenübertragung und komplexe Abrechnung
- Die Kosten für ausgehenden Datenverkehr bei AWS lagen früher bei 20 Cent pro GB und sanken später auf 9 Cent pro GB, werden aber weiterhin als sehr teuer empfunden.
- Selbst für Datenbewegungen zwischen internen AWS-Systemen fallen Gebühren an, und die Struktur wirkt je nach Fall wie eine doppelte oder dreifache Abrechnung, sodass man ohne tiefes Verständnis Abrechnungsfallen kaum vermeiden kann.
-
IAM und die allgemeine Komplexität
- IAM (Authentifizierungs- und Zugriffssteuerungssystem) ist ein extrem komplexes System.
- AWS-Befürworter sagen, man müsse AWS nutzen, weil es zu komplex sei, eigenes Linux, eigene Hardware, Netzwerke und Sicherheit zu betreiben. Aus meiner Sicht ist aber fast jeder Bereich von AWS selbst ebenfalls von enormer Komplexität geprägt, sodass am Ende ohnehin ein teures Expertenteam nötig ist.
-
AWS Lambda und Lock-in
- Mich reizte zwar der Vorteil, dass es „skalierbar“ sei, doch langsame Cold Starts und enorme Entwicklungs-Komplexität waren problematisch.
- Gegenüber einem eigenen Webserver gibt es keinen echten Vorteil, dafür mehr Nachteile, und beim Verlassen von AWS war Lambda der am schwersten zu entwirrende Teil, so stark war der Vendor Lock-in.
-
Open-Source-Projekte und Hosting-Umsätze
- Aus meiner Sicht trieb AWS OpenSearch, Valkey und DocumentDB voran, obwohl Projekte wie Elasticsearch, Redis und MongoDB deutlich gemacht hatten, dass sie keine Kopierung und Monetarisierung wollten.
- Nachdem diese Communities und Unternehmen den Markt geschaffen hatten, nahm AWS die Umsätze aus gehosteten Diensten mit, was aus meiner Sicht zur Zunahme defensiver Lizenzen wie SSPL, Elastic License und RSAL sowie zu source-available Modellen führte.
Einige Dienste, die nach dem Abschied von AWS übrig blieben
- Nachdem meine Zuneigung zu AWS verschwunden war, verlagerte ich alles aus AWS heraus und schloss fast alle Konten.
- Ich ließ damals nur einige Dienste zurück, die ich tatsächlich noch für die richtige Lösung hielt.
- Domains blieben bei Route53, einige Backups bei S3 und geschäftliche E-Mails bei AWS WorkMail.
- Für AWS WorkMail wurde bereits eine Einstellung des Dienstes innerhalb von 12 Monaten angekündigt.
Warum ich kurzzeitig zu AWS zurückkehrte
- Kürzlich meldete ich mich für Forschung und Tests wieder bei AWS an.
- Ich wollte prüfen, wie gut Claude/Anthropic auf AWS Bedrock funktioniert. Gemessen an Claude Code funktionierte es zwar gleich, war aber langsamer und deutlich teurer als ein Anthropic-Abonnement.
- Meine schnellste Hardware zu Hause hatte eine 20-Core-CPU und 32 GB RAM, und ich wollte benchmarken, wie schnell der Code auf einem System mit 192 Cores und 1 TB RAM läuft.
- Ein Test mit AWS Bedrock vor etwa einem Monat verlief problemlos, und danach wurde alles wieder beendet.
- AWS Bedrock kann nützlich sein, wenn Privatsphäre erforderlich ist, aber wegen der Kosten werde ich Claude dort wohl nicht noch einmal nutzen.
Kontoeinschränkung während eines EC2-Spot-Tests
- Danach startete ich eine 192-Core-EC2-Spot-Instanz und testete etwa drei Stunden lang, als ich von AWS eine E-Mail mit dem Betreff „Suspected security breach of your account“ erhielt.
- Ich halte es für möglich, dass die internen Sicherheitsalarme von AWS dadurch ausgelöst wurden, dass ein fast inaktives Konto plötzlich teure Compute-Ressourcen nutzte.
- Dass AWS Nutzer schützen will, kann ich grundsätzlich nachvollziehen und positiv bewerten.
- AWS sperrte oder beschränkte das Konto jedoch, wodurch mein wichtigstes geschäftliches E-Mail-Konto über AWS WorkMail nicht mehr funktionierte.
- Niemand konnte mir mehr E-Mails schicken, und ich konnte auch keine AWS-Ressourcen mehr anlegen, sodass ich den eigentlichen Test nicht fortsetzen konnte.
Support-Reaktion und Verzögerung
- Ich antwortete auf die AWS-Supportbenachrichtigung und teilte mit, dass mein Konto nicht gehackt worden sei und es weder Probleme noch ungewöhnliche Abrechnungen gebe, erhielt aber keine Antwort.
- Da ich keinen Premium-Support nutzte, musste ich die von AWS genannte Reaktionszeit von 24 Stunden abwarten, doch auch nach drei Tagen kam keine Antwort vom AWS-Support.
- Nachdem ich in den AWS-Foren um Hilfe gebeten hatte, bekam ich den Rat, die Anweisungen aus der E-Mail zu befolgen und statt des Webformulars den Chat zu verwenden.
- Ich führte alle angeforderten Maßnahmen aus, darunter Passwortänderung, Löschen von Zugriffstokens und Prüfung der Abrechnung, wartete etwa 30 Minuten auf die Chat-Verbindung und sprach dann lange mit einem AWS-Mitarbeiter.
- Der Mitarbeiter wirkte zufrieden und sagte, er werde das zuständige interne Team einschalten, doch auch nach 24 Stunden wurde die Einschränkung nicht aufgehoben.
- Als ich acht Stunden später erneut nachfragte, erhielt ich nur die Antwort, ich solle weiter warten.
Ein erneut bestätigtes Fazit
- Selbst vier Tage nach der Kontobeschränkung hatte ich noch Aufgaben, die ich auf großer Hardware testen wollte, und machte mir Sorgen, dafür erneut eine „quota“-Anfrage stellen zu müssen.
- Das geschäftliche E-Mail-System funktionierte weiterhin nicht.
- Diese Rückkehrerfahrung hat erneut bestätigt, warum ich AWS verlassen habe, und ich bin zu dem Schluss gekommen, AWS WorkMail zu verlassen, auch die Domains von Route53 wegzuziehen und nie wieder zurückzukehren.
- Ich war sehr froh, mich früher bereits weitgehend von AWS gelöst zu haben, doch ausgerechnet das E-Mail-System, dem ich vertraut und das ich dort belassen hatte, wurde im Zuge meiner Rückkehr zu AWS unterbrochen und verursachte realen Schaden.
- AWS könnte die Kontoeinschränkung irgendwann aufheben, aber wann das sein wird, ist unklar.
1 Kommentare
Hacker-News-Kommentare
Vor ein paar Jahren bin ich in ein Unternehmen eingestiegen, habe das Entwicklungsteam übernommen und sollte innerhalb von 3 Monaten ein Produkt launchen. Als ich in AWS eine neue Maschine hinzufügen wollte, wirkte schon die Struktur, bei der der Preis im UI nicht sichtbar ist, wie ein Signal für eine feindselige und ausbeuterische Beziehung.
Ich musste die Spezifikationstabelle und die Preistabelle getrennt öffnen und abgleichen, und aus früherer Erfahrung wusste ich: Wenn ich solche Signale sehe und trotzdem nicht gehe, bin ich später selbst für die Folgen verantwortlich.
Also habe ich ein DigitalOcean-Konto erstellt, alles dorthin migriert und auch CI/CD so eingerichtet, dass dorthin deployt wird. Die verbleibenden zwei Monate habe ich mich auf das Produkt konzentriert und es einen Monat früher als versprochen veröffentlicht.
Ich habe einmal ein Video gesehen, in dem jemand am Fluss ein Loch gräbt und es mit einem Rohr mit dem Fluss verbindet, sodass die Fische von selbst in die Falle schwimmen. Seitdem ist mir stark im Gedächtnis geblieben, dass genau diese Haltung – immer den Weg des geringsten Widerstands zu wählen und Fehler nicht rückgängig zu machen – der beste Weg ist, genauso zu enden wie diese Fische.
Ich wurde dort bisher noch nie von Gebühren überrascht.
Ich habe einmal einen Junior-Entwickler eingestellt, der zuvor ein AWS-Praktikum gemacht hatte. Er zeigte mir ein Dashboard, das er im Sommer ohne Hilfe von Produktverantwortlichen oder Designern allein gebaut hatte, und es sah wirklich schrecklich aus.
Manche Entwickler haben zwar ein gutes Produkt-/UX-Gespür, aber die meisten sind in UX massiv schwach. Daher war es wahrscheinlich weniger Absicht als schlicht eine schlechte UX-Kultur.
AWS ist gut, aber nicht für alle passend, und liegt irgendwo zwischen Diensten wie Heroku und Bare Metal: viel Wartung wird abstrahiert, aber man behält noch einen Teil der Kontrolle über die skalierbare Architektur.
Anders gesagt: Als Cloud-Anbieter hilft AWS beim Skalieren, ist aber nicht das Werkzeug, um die billigste und einfachste Konfiguration zu bauen.
Wenn man VC-finanziert ist und Wachstum in den Vordergrund stellt, kann AWS eine sichere Wahl sein, und dank zweijähriger Startup-Credits über Accelerator-Programme kann man sich in den ersten 18 Monaten eher aufs Bauen als aufs Infrastruktur-Budget konzentrieren.
Wenn man bootstrapped oder Indie-Entwickler ist, sollte man etwas Einfaches wählen, das man sich leisten kann, und Hetzner oder DigitalOcean laufen dafür völlig ausreichend gut.
Amazon will vermutlich ein wenig Reibung dabei, Preisinformationen leicht abrufbar zu machen, aber der Hauptgrund scheint mir eher Conways Gesetz zu sein.
AWS exportiert immer noch sein Organigramm direkt ins Produkt.
Wenn es schon störend ist, für den Kostenvergleich zwei Tabs zu öffnen, sollte man vielleicht nicht nur AWS, sondern alle Cloud-Anbieter meiden.
Sobald NAT Gateway, CloudFront, S3, Auto Scaling und Load Balancer ins Spiel kommen, ist Kostenkalkulation eher Kunst als exakte Wissenschaft.
Wenn man solche Dinge nicht nutzt, gibt es ohnehin wenig Gründe, AWS zu verwenden, und günstige VPS-Anbieter gibt es genug.
Wenn man nur OpenSearch und Valkey betrachtet, ist die Aussage „AWS hat einen Fork erstellt und dadurch die Lizenzänderung ausgelöst“ komplett auf den Kopf gestellt.
AWS hat den Fork erst erstellt, nachdem das Upstream-Projekt die Lizenz geändert hatte, und insbesondere Valkey wurde von früheren Mitgliedern des Redis-Kernteams geschaffen.
AWS hat sie umgangen, indem es selbst Managed Services angeboten hat, deshalb stehe ich in diesem Fall auf der Seite der Leute, die das Projekt gebaut haben.
Im Grunde hat AWS ihnen das Geschäftsmodell weggenommen, und deshalb blieb ihnen gar nichts anderes übrig, als die Lizenz zu ändern.
Ich frage mich auch, ob das für Open-Source-Teams in Summe schon nennenswertes Geld wäre und ob es sie dazu bringen würde, ohne großes Risiko zur Produktverbesserung beizutragen.
Valkey haben sie verdient.
An JBoss und Marc Fleury erinnere ich mich auch noch.
Genau darum geht es ja.
Ich bin schon ein paar Mal zwischen Cloud-Services und Self-Hosting hin- und hergewechselt.
Zuerst habe ich Vercel genutzt. Da das Projekt auf Next.js basierte, war die Erfahrung okay, aber 20 Dollar im Monat für ein Projekt mit nicht einmal 100 Nutzern fühlten sich für einen Dienst mit geringen Performance-Anforderungen teuer an.
Danach habe ich mit Hetzner und Coolify einen eigenen Server aufgebaut. Da Coolify Open Source ist, musste ich nur die VPS-Kosten zahlen, und für 5 Dollar im Monat konnte ich bereits eine PostgreSQL-Instanz und einen Webserver betreiben.
Aber die Wartung von PostgreSQL und Redis war immer noch aufwendig, und selbst in Docker-Containern war es mühsam, Systemvariablen und Umgebungsvariablen zwischen Diensten weiterzureichen.
Später bin ich deshalb zu Cloudflare Workers, D1 Database und Cloudflare KV gewechselt, die man direkt innerhalb des Workers aufrufen kann, sodass keine Übergabe von Umgebungsvariablen nötig war.
Die lokale Entwicklung ist gut, die Preise sind vernünftig, und seitdem nutze ich weiter das gesamte Cloudflare-Ökosystem.
Einfache Full-Stack-Apps und Dateibereitstellung sind dort viel einfacher, während AWS inzwischen sogar schwieriger geworden ist als Self-Hosting.
Das einzige Problem, das ich mit PostgreSQL habe, ist meist ein wenig Migrationsarbeit beim Wechsel auf eine neue Hauptversion.
Ich frage mich auch, ob gerade Docker die Übergabe von System- und Umgebungsvariablen zwischen Diensten eher schwieriger gemacht hat.
Um E-Mail zu erlauben, muss man die nötigen Bindings setzen, aber in der Konsole scheint man sie weder konfigurieren zu können noch sie sehen zu können, nachdem Wrangler sie gesetzt hat.
Ich bin überrascht, dass der Autor DynamoDB nicht mag.
Für mich ist es einer meiner liebsten AWS-Dienste: hohe Verfügbarkeit, kaum Betriebsaufwand und jedes Mal, wenn ich es genutzt habe, ziemlich geringe Kosten.
Man muss allerdings Zeit in die Modellierung der Daten investieren, und dafür muss man die Doku des Dienstes lesen und verstehen.
Man sollte es im Grunde als einen relativ einfachen Key-Value-Store mit guter Persistenz und nahezu unbegrenzter Skalierung der Tabellengröße sehen, nicht als SQL-Datenbank.
Der einfachste Weg, mit Prototyp-Code eine Rechnung über 75 Dollar zu erzeugen, ist, per Vibe Coding damit umzugehen, als wäre es eine SQL-Datenbank mit JOIN und GROUP BY.
Wirklich glänzt es dort, wo man 1–2 Tabellen für kleine persistente Daten braucht, aber kein vollständiges RDBMS betreiben will, oder wenn man eine sehr große Tabelle auf einfache Weise abfragen möchte, ohne sie in ein RDBMS pressen zu müssen.
Man sollte einen fröhlichen Key-Value-Store nicht als Datenbank verwenden.
Das anfängliche Laden kostete ungefähr 50 Dollar, danach lagen die laufenden Kosten bei etwa 10 Cent pro Monat.
Solche Beiträge bringen mich immer zum Lachen.
Sie sind gleichzeitig richtig und falsch, und Systeme sollte man „so einfach wie möglich, aber nicht einfacher“ bauen.
Wenn man glaubt, Details einfach übergehen zu können, holt einen das später als noch größeres Ärgernis wieder ein.
IAM ist einfach komplex.
Mir fällt kein Beispiel ein, in dem Benutzer, Gruppen, Rollen, Policies, Identitätsanbieter und OIDC wirklich simpel umgesetzt wurden.
Ich habe einmal gesehen, wie jemand die Einführung von Kubernetes als „zu komplex“ ablehnte und am Ende mit Vault, Consul, systemd, Nomad, iSCSI, Ansible, Jenkins, Puppet, Bash, Spucke und Kaugummi Kubernetes auf schlechte und provisorische Weise neu erfunden und dabei viele Fehler gemacht hat.
Manche Funktionen hält man zunächst für unnötig, bis man sie doch braucht.
Aus Sicht von jemandem, der in einem Startup allein für Infrastruktur zuständig war: AWS ist größtenteils im Rahmen dessen, was man lernen kann, und die schlechten Teile kann man meist vermeiden.
Wenn man Lambda nicht mag, nutzt man es eben nicht, sondern EKS, ECS und EC2.
Aus 10.000 Fuß Höhe ist das alles.
IAM ist gut, weil es für außen und innen gleich gilt.
AWS-interne Teams haben nicht automatisch mehr Rechte. Wenn sie in einem Kundenkonto etwas tun dürfen, um einen bestimmten Dienst zu erbringen, dann weil der Kunde in IAM eine Vertrauensbeziehung zum Service-Prinzipal eingerichtet hat, und der Kunde kann das einsehen und auditieren.
Lambda hat zum Beispiel eine Lambda-Rolle, weil man nicht möchte, dass der Lambda-Service einfach S3-Buckets lesen kann mit der Begründung „wir sind AWS, also haben wir automatisch Zugriff“.
Selbst interner AWS-Zugriff kann vom Kunden klar eingesehen und kontrolliert werden.
Manche Dinge sind inzwischen ganz klar Standard, und trotzdem weigern sich viele, Zeit zu investieren, um sie richtig zu lernen.
Wenn ein ordentlicher Infrastruktur-Ingenieur zwei Monate in eine OVH-Konfiguration steckt, um „Geld zu sparen“, ist das teurer, als was man durch den Verzicht auf Fargate oder RDS jemals sparen könnte.
Ich frage mich, ab wann man über Firmen wie Anthropic oder OpenAI dieselben Dinge sagen wird.
Der aktuelle AI-Trend riecht sehr nach frühem AWS: Alle springen auf, und später merken sie, dass sie sich eine große Abhängigkeit aufgebaut haben, die sich nicht leicht wieder entfernen lässt.
Lambda ist wirklich großartig und meiner Meinung nach der beste Weg, einen Dienst mit kurzen Iterationszyklen zu betreiben, ohne ständig Kopfschmerzen zu haben.
Man muss nicht zwangsläufig auf Microservices gehen oder den Code auf Milliarden winziger Repositories aufteilen.
Wenn man nicht erwartet, Serverzustand zwischen Requests teilen zu können, kann man einen normalen Webserver auf Lambda verlagern.
Ich arbeite nicht in dem Bereich und fasse AWS höchstens mal für private Spaßprojekte an, aber jedes Mal ist es ein Albtraum.
Ich will nur einen experimentellen Server für ein Kartenspiel bauen und nicht ein neues Finanzinstitut gründen, aber alles wirkt so, als wäre es auf unendliche Skalierung ab morgen und auf eine Organisation mit tausend Leuten plus VC-Budget ausgelegt.
Zum Glück gibt es Dienste wie Netlify, die darüber eine Schicht legen, damit man nicht gleich das Meer zum Kochen bringen muss.
Vielleicht muss ich irgendwann IAM, VPN und irgendwelche anderen Dinge wirklich lernen, aber bis dahin treten mir bei jedem AWS-Kontakt fast die Augen aus dem Kopf.
Man muss nicht jedes Enterprise-Muster umsetzen.
Alles, was ich brauche, ist da, und die Preise sind vernünftig.
Bei privaten Projekten zählt am Ende meist nur der Preis, und damit generiert man für AWS keinen nennenswerten Umsatz.
Seit 2023 wird AWS systematisch von technischem Personal ausgedünnt.
Das geschah durch Massenentlassungen oder zwei Runden von Performance-Improvement-Plänen, und viele fähige Kollegen aus Presales oder Support sind nicht mehr bei AWS.
Stattdessen habe ich oft gesehen, dass Leute mit der unklarsten beruflichen Bilanz geblieben sind und sogar befördert wurden.
Wer AWS nutzt, tut das auf eigenes Risiko, und Paul Vixie wird nicht vorbeikommen, um euch zu retten.
Schon seit Langem finde ich ElastiCache besonders unerquicklich.
Bei RDS sehe ich den Mehrwert: Skalierung, einigermaßen optimierte Konfigurationen, Backups, um die man sich nicht kümmern muss – dafür kann ich zähneknirschend zahlen.
Aber ElastiCache bietet fast keinen Mehrwert, und der Preis wirkt ausbeuterisch.
Es ist langsamer, schlechter optimiert und weniger stabil als eine normale Redis-Installation, und normales Redis unterstützt mehrere DBs, während ElastiCache nur eine unterstützt.
Es gibt zwar gewisse Verbesserungen bei der Skalierung, aber normale Redis-Installationen sind auf ähnlichen Instanzen ElastiCache so weit voraus, dass man diese Verbesserungen in der Praxis nur sehr selten wirklich braucht.
AWS liefert dort weder bei der API noch beim Reifegrad besonders viel Mehrwert, und umgekehrt ist Redis/Valkey einer der einfachsten Dienste überhaupt, die man selbst hosten kann.