Ich kehrte zu AWS zurück und verstand erneut, warum ich gegangen bin

• Ich war von Anfang an ein Unterstützer von AWS, aber mit der Zeit häuften sich Dinge wie die an die Community ausgelagerten Client-Bibliotheken, die verzögerte Umstellung auf Python 3, die komplexe Abrechnung und IAM sowie der Lock-in durch AWS Lambda, sodass ich AWS irgendwann nicht mehr mochte
• Nach der Nutzung von DynamoDB wurde mir an einem einzigen Tag 75 Dollar berechnet; die Kosten für ausgehende Datenübertragung sanken zwar von 20 Cent auf 9 Cent pro GB, aber das Modell bleibt aus meiner Sicht teuer und schwer verständlich, weil sogar interne Datenbewegungen berechnet werden
• Nachdem ich AWS verlassen hatte, schloss ich die meisten Konten, ließ aber Domains bei Route53, einige Backups in S3 und AWS WorkMail bestehen; später erhielt ich die Mitteilung, dass WorkMail innerhalb der nächsten 12 Monate eingestellt wird
• Kürzlich meldete ich mich wieder bei AWS an, um zu testen, wie Claude/Anthropic auf AWS Bedrock läuft, und um EC2-Spot-Tests mit 192 Kernen und 1 TB RAM durchzuführen; Bedrock funktioniere zwar ähnlich, sei aber langsamer und deutlich teurer als ein Anthropic-Abonnement
• Während eines etwa dreistündigen EC2-Spot-Tests wurde mein Konto nach einer Warnung über einen Suspected security breach eingeschränkt, wodurch geschäftliche E-Mails über WorkMail und das Erstellen von Ressourcen blockiert wurden; auch nach Maßnahmen und Chat-Support blieb die Sperre vier Tage lang bestehen, weshalb ich nun auch AWS WorkMail und Route53 migrieren will

---

Von der frühen AWS-Begeisterung bis zum Abschied

• Ich war ein starker Unterstützer von AWS, seit es noch ein kleinerer Dienst rund um SQS, S3, EC2 und SimpleDB war, und organisierte in Melbourne die erste Veranstaltung, bei der AWS in den USA zuständige Mitarbeiter vorbeikamen, um AWS vorzustellen
• Cloud Computing war ein großer Umbruch, weil Startups damit in wenigen Minuten ihre eigenen Computersysteme betreiben konnten, ohne Systeme in Rechenzentren installieren und betreiben zu müssen
• Etwa 15 Jahre lang glaubte ich fest an AWS, doch mit der Zeit sammelten sich störende Aspekte an, bis ich AWS irgendwann nicht mehr mochte

Unzufriedenheit mit AWS, die sich über die Zeit aufbaute

• Client-Bibliotheken und die Python-Umstellung

  • 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

  • Nach der Nutzung von DynamoDB wurden am Ende eines Tages 75 Dollar berechnet, und nicht nur die Kosten, sondern auch das System selbst fühlte sich für mich wie die denkbar schlechteste Umsetzung an

• Datenübertragungskosten und komplexe Abrechnung

  • Die Kosten für ausgehende Datenübertragung 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
  • Auch Datenbewegungen zwischen internen AWS-Systemen werden berechnet, und je nach Fall wirkt die Struktur wie eine doppelte oder dreifache Abrechnung, sodass es ohne tiefes Verständnis schwer ist, in Kostenfallen nicht hineinzulaufen

• IAM und allgemeine Komplexität

  • IAM ist das System für Authentifizierung und Zugriffsregeln, wird aber als übermäßig komplex wahrgenommen
  • AWS-Befürworter sagen oft, man müsse AWS nutzen, weil der Betrieb eigener Linux-Systeme, Hardware, Netzwerke und Sicherheit zu komplex sei; aus meiner Sicht besitzen jedoch fast alle Bereiche von AWS selbst eine gewaltige Komplexität, sodass am Ende ebenfalls ein teures Spezialistenteam nötig ist

• AWS Lambda und Lock-in

  • AWS Lambda verspricht Skalierbarkeit, brachte aber lange Startzeiten und große Entwicklungs­komplexität mit sich
  • Im Vergleich zum Betrieb eines eigenen Webservers sah ich keinen echten Vorteil, aber viele Nachteile, und als ich AWS verließ, war AWS Lambda der Teil, der sich am schwersten rückgängig machen ließ
  • Die Nutzung von AWS Lambda hinterließ bei mir die Erfahrung, dass Vendor Lock-in real ist und sich wie eine Entscheidung anfühlt, bei der man sich immer wieder selbst einreden muss, dass sie besser sei

• Open-Source-Projekte und Hosting-Umsätze

  • Aus meiner Sicht trieb AWS OpenSearch, Valkey und DocumentDB voran, obwohl Projekte wie Elasticsearch, Redis und MongoDB klar signalisiert hatten, dass sie keine Kopien und Monetarisierung wollten
  • Nachdem diese Communities und Unternehmen den Markt aufgebaut hatten, nahm AWS die Umsätze aus den Hosting-Diensten mit; dadurch hätten defensive Lizenzen wie SSPL, Elastic License und RSAL sowie source-available-Modelle zugenommen

Einige Dienste, die nach dem Abschied blieben

• Nachdem meine Zuneigung zu AWS verschwunden war, verschob ich alles aus AWS heraus und schloss fast alle Konten
• Ich ließ nur einige Dienste bestehen, die ich damals tatsächlich für die passende Lösung hielt
• Das waren Domains bei Route53, einige Backups in S3 und AWS WorkMail
• Später erhielt ich die Mitteilung, dass AWS WorkMail innerhalb der nächsten 12 Monate eingestellt wird

Warum ich vorübergehend 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 läuft; bezogen auf Claude Code funktioniert es ähnlich, ist aber langsamer und deutlich teurer als ein Anthropic-Abonnement
• Die schnellste Hardware, die ich zu Hause hatte, war eine CPU mit 20 Kernen und 32 GB RAM, und ich wollte benchmarken, wie schnell mein Code auf einer Maschine mit 192 Kernen und 1 TB RAM läuft
• Ein Test mit AWS Bedrock vor etwa einem Monat endete ohne Probleme, und danach wurde alles wieder beendet
• AWS Bedrock könnte nützlich sein, wenn Privatsphäre erforderlich ist, aber wegen der Kosten würde ich Claude dort nicht noch einmal nutzen

Kontoeinschränkung während eines EC2-Spot-Tests

• Später startete ich eine EC2-Spot-Instanz mit 192 Kernen und erhielt während eines etwa dreistündigen Tests eine E-Mail von AWS mit dem Betreff „Suspected security breach of your account“
• Möglicherweise löste die Tatsache, dass ein fast inaktives Konto plötzlich teure Compute-Ressourcen nutzte, intern einen Sicherheitsalarm bei AWS aus
• Dass AWS Nutzer schützen will, kann ich grundsätzlich nachvollziehen und positiv bewerten
• AWS sperrte oder beschränkte jedoch mein Konto, wodurch auch mein geschäftliches Haupt-E-Mail-Konto über AWS WorkMail nicht mehr funktionierte
• Niemand konnte mir mehr E-Mails senden, und ich konnte keinerlei AWS-Ressourcen mehr erstellen, sodass auch der ursprünglich geplante Test nicht fortgesetzt werden konnte

Reaktion des Supports und Verzögerungen

• Ich antwortete auf die Benachrichtigung des AWS-Supports 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 Antwortzeit von 24 Stunden abwarten; selbst nach drei Tagen kam keine Reaktion vom Support
• Nachdem ich im AWS-Forum um Hilfe gebeten hatte, erhielt ich den Rat, die Anweisungen aus der E-Mail auszuführen und statt des Webformulars den Chat zu nutzen
• Ich führte alle geforderten Maßnahmen durch, etwa das Ändern des Passworts, das Löschen von Zugriffstokens und die Prüfung der Abrechnung, wartete rund 30 Minuten auf eine Chat-Verbindung und sprach dann lange mit einem AWS-Mitarbeiter
• Der Mitarbeiter wirkte zufrieden und sagte, er werde das zuständige interne Team einschalten, aber auch nach 24 Stunden wurde die Einschränkung nicht aufgehoben
• Als ich acht Stunden später erneut nachfragte, bekam ich nur die Antwort, ich solle weiter warten

Erneut bestätigte Schlussfolgerung

• Selbst vier Tage nach der Kontoeinschränkung hatte ich noch Aufgaben, die ich auf einer großen Maschine testen wollte, und machte mir Sorgen, dafür erneut einen „quota“-Antrag stellen zu müssen
• Mein geschäftliches E-Mail-System funktionierte weiterhin nicht
• Diese Rückkehr zu AWS bestätigte erneut, warum ich AWS verlassen hatte, und ich entschied, AWS WorkMail zu verlassen und auch die Domains bei Route53 umzuziehen, um nie wieder zurückkehren zu müssen
• Dass ich früher schon fast alles aus AWS herausgezogen hatte, war ein großes Glück, aber dass das E-Mail-System, dem ich noch vertraut und das ich zurückgelassen hatte, im Zuge dieser Rückkehr ausfiel, empfinde ich als Scheitern
• AWS könnte die Kontoeinschränkung irgendwann aufheben, aber wann das geschieht, ist unklar

[GN⁺]

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.

  • Eines der Dinge, die ich an Azure mag, ist, dass beim Erstellen einzelner Elemente der Preis nicht übermäßig aufgedrängt wird, es aber bei potenziell teuren Elementen meist eine ausgewogene Anzeige des Preises gibt.
    Ich wurde dort bisher noch nie von Gebühren überrascht.
  • Ich habe den Eindruck, dass die Engineering-Kultur bei Amazon ziemlich stark eine ingenieurgetriebene Produktkultur ist, sodass Entwickler oft auch für UX und Abläufe verantwortlich sind.
    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.
  • Der richtige Ansatz ist, einen Infrastruktur-Anbieter zu wählen, der den Launch unterstützt.
    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.
  • AWS hat einen ziemlich guten Preisrechner und brauchbare Presets, aber natürlich ist das eine komplett separate App.
    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.
  • Ich stimme teilweise zu, aber AWS-Preise sind nicht so einfach, dass man mit einer statischen Zahl im UI berechnen könnte, was man zahlen wird.
    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.

  • Viele solcher Projekte funktionieren nach einem Geschäftsmodell, bei dem das Kernprodukt als Open Source veröffentlicht wird und Geld mit Premium-Services, Installation, Wartung und Managed Services verdient wird.
    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.
  • Die Lizenzänderung selbst war eine Reaktion darauf, dass AWS ihre Arbeit auf eine für das Upstream-Projekt nicht nachhaltige Weise monetarisiert hat.
  • Ich frage mich, wie stark Amazon treffen würde, wenn sie den Erstellern und Maintainers der von ihnen verkauften Open-Source-Software pro Abrechnungszeitraum nur 1 Cent zahlen würden.
    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.
  • Seit ich meinen ersten Patch an Redis geschickt habe und ein Committer nicht auf meine Nachricht geantwortet, den Patch aber unter seinem eigenen Namen übernommen hat, ist viel von meiner Sympathie für die Philosophie vieler Open-Source-Projekte verschwunden.
    Valkey haben sie verdient.
    An JBoss und Marc Fleury erinnere ich mich auch noch.
  • Dass AWS den Fork erst erstellt hat, nachdem die Lizenz so geändert worden war, dass AWS mit dem Code des Projekts kein Geld mehr verdienen konnte, ist doch selbstverständlich.
    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.

  • Das, was Cloudflare anbietet, kommt dem näher, was ich mir von AWS gewünscht hatte.
    Einfache Full-Stack-Apps und Dateibereitstellung sind dort viel einfacher, während AWS inzwischen sogar schwieriger geworden ist als Self-Hosting.
  • Ich frage mich, ob Docker die Verwaltung von PostgreSQL wirklich erleichtert hat.
    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.
  • Ich wollte Cloudflare Workers mögen, und technisch gibt es sicher gute Gründe dafür, aber dass man für Dinge wie die Aktivierung von E-Mail ein Wrangler-Projekt verwenden muss, fühlte sich an wie kurz vor vollständigem Plattform-Lock-in.
    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.

  • DynamoDB ist ziemlich gut, wenn man es so verwendet, wie es gedacht ist.
    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.
  • Viele Dienste wie DynamoDB und Lambda haben sehr spezifische Anwendungsfälle.
    Man sollte einen fröhlichen Key-Value-Store nicht als Datenbank verwenden.
  • Ich habe vor ein paar Jahren eine App gebaut und brauchte eine Datenbank für etwa 50 Millionen Datensätze, rund 10.000 Reads+Writes pro Monat und einen Index.
    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 interner Sicht hat IAM tausende Optionen, aber im Kern geht es nur um „Worauf darf diese Rolle zugreifen und was darf sie damit tun (Aktion + Ressource)?“ und „Wer darf auf diese Rolle zugreifen?“.
    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.
  • Dieses Muster, etwas mit „X ist zu komplex“ abzulehnen und am Ende X doch in schlechter Form neu zu erfinden, ist in Technik und Software erstaunlich verbreitet.
    Manche Dinge sind inzwischen ganz klar Standard, und trotzdem weigern sich viele, Zeit zu investieren, um sie richtig zu lernen.
  • AWS kann teurer sein als Self-Hosting, aber diese Einsparung ist klein im Vergleich zu den Engineering-Kosten.
    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.

  • Starte einfach einen rohen VPS auf EC2 oder Lightsail, hänge eine öffentliche IP dran, und fertig.
    Man muss nicht jedes Enterprise-Muster umsetzen.
  • Es ist erstaunlich, wie genau Heroku schon vor fast 20 Jahren das getroffen hat, was die meisten Web-Apps brauchen.
  • Wenn man Azure nicht benutzt hat, kann einem AWS allein schon wie ein Albtraum vorkommen.
  • Ich bin zu Cloudflare gewechselt und konnte endlich wieder durchatmen.
    Alles, was ich brauche, ist da, und die Preise sind vernünftig.
  • AWS richtet sich nicht an private Projekte, sondern an Enterprise.
    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.

  • ElastiCache ist definitiv einer der Dienste, bei denen man Self-Hosting ernsthaft in Betracht ziehen sollte.
    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.