Zwei Jahre nach der Migration von AWS auf Bare Metal: Antworten auf Fragen zum AWS-Ausstieg

• Ein Bericht mit Antworten im Nachgang auf verschiedene Fragen aus der Community, nachdem vor zwei Jahren die Erfahrung geteilt wurde, durch die Migration von AWS auf Bare Metal jährlich 230.000 US-Dollar einzusparen Mit Veröffentlichung von Praxiskennzahlen aus zwei Jahren wurde erklärt, dass inzwischen mehr als 1,2 Mio. US-Dollar jährliche Einsparungen erzielt wurden
• Durch den produktiven Betrieb stiegen die Einsparungen auf über 1,2 Mio. US-Dollar pro Jahr. Dieses Geld wurde in Server für KI-gestützte Incident-Zusammenfassungen und automatische Code-Korrekturen reinvestiert, was die Servicequalität verbesserte
• Auf Basis des MicroK8s- + Ceph-Stacks wurden 99,993 % Verfügbarkeit gehalten und durch eine Architektur mit zwei Rechenzentren Single Points of Failure beseitigt
• Zentrale Themen wie tatsächliche Betriebskosten, Störungsbehebung, Hardware-Lebensdauer, Sicherheitszertifizierungen und Cloud-Alternativen werden mit konkreten Zahlen erläutert
• Das Ergebnis: Sowohl Stabilität als auch Kosteneffizienz wurden verbessert, und für Systeme mit dauerhafter Last ab einer gewissen Größenordnung sei Bare Metal die sinnvollere Wahl

---

Zusammenfassung der Betriebsergebnisse nach 2 Jahren

• Der MicroK8s- + Ceph-Stack lief 24 Monate in Produktion und erreichte 99,993 % Verfügbarkeit
  • Um ein einzelnes Rack als Problemquelle zu vermeiden, wurde in Frankfurt ein zweites Rack ergänzt und mit dem Hauptrack in Paris per redundanter DWDM-Anbindung verbunden
  • Durch lokales NVMe und die Beseitigung von Noise-Interference sank die Latenz für Kunden um 19 %
• Die eingesparten Kosten wurden in Bare-Metal-KI-Server reinvestiert, um OneUptimes LLM-basierte Alert-Zusammenfassungen und automatische Code-Korrekturfunktionen auszubauen

Einsparungen und Kostenvergleich

• Die anfänglich erwartete Einsparung lag bei 230.000 US-Dollar pro Jahr, inzwischen sind es mehr als 1,2 Mio. US-Dollar
  • Das entspricht gegenüber AWS einer Ersparnis von etwa 76 %
  • Bezogen auf globale Gehaltsniveaus entspricht das den Jahresgehältern von 2 bis 5 Engineers
• Selbst mit Savings Plans / Reserved Instances bleibt Bare Metal im Vorteil
  • Savings Plans gelten nicht für Kosten von S3, Egress oder Direct Connect
  • Auch Kosten wie 1.260 US-Dollar/Monat für die EKS Control Plane oder 600 US-Dollar/Monat für NAT Gateways lassen sich dadurch nicht senken
  • Bei 24/7-Dauerlast-Workloads (steady) war der Nutzen von Reserved Instances begrenzt

Migration und Betriebskosten

• Die anfängliche Migration war mit etwa einer Woche Engineering-Aufwand abgeschlossen
  • Ein Großteil davon waren ohnehin nötige Arbeiten wie die Bereinigung von IaC und die Stärkung der Backup-Richtlinien
• Die aktuellen Betriebskosten sehen wie folgt aus:
  • Direkte Verwaltung: etwa 24 Stunden pro Quartal (inklusive Patches und Firmware-Updates)
  • Remote Hands: In 24 Monaten waren nur 2 Eingriffe nötig (vor allem wegen Festplattenproblemen), mit einer durchschnittlichen Reaktionszeit von 27 Minuten
  • Automatisierung: PXE-Boot (Tinkerbell), Talos-Image-Management, automatisierte Konfiguration mit Flux/Terraform
• Das Betriebsteam konnte im Vergleich zur AWS-Zeit sogar die Release-Geschwindigkeit steigern; zudem entfiel die Last ständiger „Kostenoptimierungs-Meetings“

Ausfallschutz und Verfügbarkeit

• Durch ein zweites Rack in Frankfurt und redundante DWDM-Pfade wurden Single Points of Failure eliminiert
  • Dazu kommen Ceph-Mirroring auf Basis asynchroner Replikation und eine doppelte Control Plane
  • Ein zusätzlicher 4G-/satellitengestützter Managementpfad ermöglicht Remote-Zugriff bei Netzwerkausfällen
• Der Wechsel von MicroK8s zu Talos ist im Gange
• Ein AWS-Failover-Backup-Cluster wird weiterhin vorgehalten; außerdem gibt es vierteljährliche Disaster-Recovery-Proben
• Mit Anycast- + BGP-basiertem Ingress wurde auch die Verzögerung bei DNS-Umschaltungen auf unter 1 Minute reduziert
• Über zwei Jahre hinweg wurde eine Verfügbarkeit von 99,993 % gehalten, ohne von jüngsten AWS-Region-Ausfällen betroffen zu sein

Hardware und CapEx-Management

• Die Server werden auf Basis von 5 Jahren Abschreibung betrieben (2×EPYC 9654, 1 TB RAM, NVMe-Konfiguration)
  • Bei Leistungssättigung werden sie in einen Analyse-Cluster verschoben und durch neue Server ersetzt
  • Dank der Einsparungen ist nun alle 2 Jahre ein 40-%-Refresh möglich, bei weiterhin geringeren Jahreskosten als bei AWS
• Es gibt eine verlängerte Supermicro-Garantie sowie 3 Reserve-Server
  • Die reale Lebensdauer liegt bei 7 bis 8 Jahren, konservativ wird aber mit 5 Jahren gerechnet

Logik hinter dem Ersatz gemanagter Services

• Die Produktphilosophie von OneUptime setzt auf Self-Hosting-Fähigkeit, weshalb derselbe Stack beibehalten werden muss
  • Konsistenz eines offenen Stacks mit Kubernetes, Postgres, Redis, ClickHouse usw. bleibt erhalten
• Die Architektur entwickelte sich von Terraform + EKS + RDS zu MicroK8s + Argo Rollouts + Ceph
  • Genutzt wird reines Open Source ohne eigene Forks
• Cloud wird weiterhin parallel genutzt: AWS Glacier (Backups), CloudFront (Edge-Caching), temporäre Instanzen für Lasttests
• Die Cloud eignet sich eher für Elastizität, Bare Metal eher für Grundlast

Netzwerk und Sicherheit

• Zwei Leitungen mit 5 Gbit/s (95th percentile) stehen zur Verfügung und sind beim AWS-Egress 8-mal günstiger
• Der DDoS-Schutz wird durch eine vollständige Vorschaltung von Cloudflare umgesetzt
• Ein separates 4G-/satellitengestütztes Managementnetz ermöglicht Remote-Zugriff im Störfall

Compliance und Audit-Fähigkeit

• Die Zertifizierungen SOC 2 Type II und ISO 27001 werden aufrechterhalten
  • Dabei werden Unterlagen des Colocation-Rechenzentrums zu Tier-III-Zertifizierung, Zutrittslogs und CCTV genutzt
  • Terraform-/Talos-Konfigurationslogs dienen als Nachweis für Änderungshistorien
• Auditoren hätten dies als vertrauenswürdiger bewertet als Screenshots aus der AWS-Konsole

Vergleich mit Cloud-Alternativen

• Verglichen wurden Hetzner, OVH, Leaseweb, Equinix Metal und AWS Outposts
  • Bei Hyperscalern sind die Egress-Kosten weiterhin hoch
  • Europäische Hoster erfüllen die Anforderungen an große Ceph-Cluster und SLA-Vorgaben nur schwer
  • Bei Equinix Metal besteht ein Premium von 25–30 % gegenüber CapEx
  • Der Betrieb eigener Hardware ist bei Leistungsdichte und Upgrade-Freiheit im Vorteil
• Insgesamt war Colocation dank 15-kW-Rack-Konfiguration und Wiederverwendung von Komponenten sowohl bei Kosten als auch Performance überlegen

Messung des operativen Mehraufwands (TOIL)

• Wöchentlich: Kernel-/Firmware-Patches und Ceph-Prüfungen (1 Stunde)
• Monatlich: Canary-Upgrades der Kubernetes Control Plane (2 Stunden)
• Vierteljährlich: DR-Übungen, Kapazitätsplanung, Prüfung von Carrier-Verträgen (12 Stunden)
• Insgesamt rund 14 Stunden pro Monat — ähnlich wie zu AWS-Zeiten, aber mit einem Fokuswechsel von „Kostentracking“ zu „Betriebsautomatisierung“

Wann Cloud weiterhin sinnvoll ist

• Wenn Workloads spitzenlastig sind oder saisonalen Mustern folgen
• Wenn die Abhängigkeit von gemanagten Services wie Aurora Serverless, Kinesis oder Step Functions hoch ist
• Wenn die Kapazität fehlt, Kubernetes, Ceph, Monitoring und Incident Response selbst zu betreiben
• Das heißt: Für frühe Phasen oder Geschäftsmodelle mit stark variabler Last hat die Cloud weiterhin Vorteile

Ausblick

• Geplant ist die Veröffentlichung eines Terraform-Moduls und eines Runbooks für die Budgetprognose von Colocation
• Außerdem ist ein technischer Deep-Dive zum Betrieb auf Talos in Vorbereitung
• Man will weiterhin auf Feedback aus HN und Reddit reagieren und praxisnahe Beispiele mit realen Zahlen teilen

[xguru]

Zwei Jahre nach der Migration von AWS auf Bare Metal: Antworten auf Fragen zum AWS-Ausstieg

[okxrr]

Ich arbeite bei einem Unternehmen, das AWS mit großer Begeisterung nutzt, obwohl wir keinerlei Services verwenden, die nur bei AWS verfügbar sind.

Eine zugleich bittere und absurde Geschichte darüber, wie ich miterlebt habe, dass auf diese Entscheidung stark ein äußerst persönliches Motiv einiger Führungskräfte einwirkte: ihre eigene Karriereentwicklung.

[GN⁺]

Hacker-News-Kommentare

• AWS ist zu teuer. Es gibt seltener als gedacht einen guten Grund, ein komplettes System vollständig auf AWS aufzubauen. Früher konnte praktisch jedes Team Bare-Metal-Server selbst betreiben, heute scheint das fast vergessen. Unser Team hat über 730 Tage hinweg 99,993 % Verfügbarkeit gehalten und ist auch den jüngsten AWS-Region-Ausfällen entgangen. Wir nutzen zwar Cloudflare zur DDoS-Abwehr, und ich verstehe, dass DNS oder Ingress-Management zu einem Fulltime-Job werden kann. Aber ein paar Microservices und eine DB kann man durchaus selbst betreiben. Für die meisten Unternehmen ist AWS schlicht überteuert

  • Das eigentliche Problem bei AWS ist die AWS-Abhängigkeit der Mitarbeiter. Man macht AWS-Zertifikate und arbeitet in einem Umfeld, in dem man sich nach dem AWS Well-Architected Framework richten soll, und hört irgendwann auf, selbst zu denken. Die Lock-in-Services von AWS sind absichtlich so bepreist, dass sie günstig wirken, binden einen am Ende aber nur noch tiefer. Wenn man zum Beispiel PostgreSQL nach DynamoDB migriert, sieht das kurzfristig wie eine Ersparnis aus, langfristig wächst aber die AWS-Abhängigkeit
  • On-Premises ist günstiger, aber geeignete Fachkräfte zu finden ist schwierig. Für einfache Produkte passt das gut, bei komplexen Systemen steigen Personalkosten und Betriebsrisiken eher an. AWS/Azure/GCP sind nicht perfekt, aber On-Prem-Experten sind heute extrem selten
  • Wenn man AWS kritisiert, gibt es erstaunlich viele Leute, die seltsam defensiv reagieren. Auf Reddit sieht man ein ähnliches Muster. Es wirkt fast so, als würden manche dafür bezahlt, AWS zu verteidigen
  • Erfolgsberichte über Self-Hosting unterliegen einem Bestätigungsfehler. Der Eigenbetrieb von Servern sieht anfangs gut aus, aber nach etwa einem Jahr weichen Dokumentation und tatsächliche Konfiguration voneinander ab, und wenn die zuständige Person kündigt, wird das Chaos groß. Am Ende kehren viele Startups wieder zu AWS zurück. Über solche Fehlschläge wird nur selten gesprochen
  • Um Bare Metal gut zu betreiben, braucht man erfahrene Engineers. Mit Berufseinsteigern oder „Cloud-Experten“ aus Beratungsfirmen ist das schwer

• Die frühe Cloud begann als einfacher und kosteneffizienter Service, heute ist sie ein Geflecht aus mehr als 200 komplexen Diensten. Wenn man es nicht aktiv steuert, explodieren die Kosten

  • Eigentlich war AWS nie vor allem „günstig“, sondern in erster Linie schnell skalierbar. Anfang der 2010er war es teuer, aber flexibel. Auch heute ist das Preis-Leistungs-Verhältnis weiter hoch. Wenn man die Grundlagen des Serverbetriebs beherrscht, sind dedizierte Server deutlich besser
  • AWS ist inzwischen auf mehr als 200 Services überdehnt. Man sollte sich wieder auf die Grundfunktionen konzentrieren
  • Jedes Mal, wenn ich die AWS-Konsole öffne, überkommt mich ein Gefühl von Komplexität und Ermüdung. Das Ganze ist viel zu aufgebläht
  • Je nach AWS-Service gibt es große Unterschiede beim Preis-Leistungs-Verhältnis. Vor allem einige ältere Kerndienste haben nach wie vor ihren Wert

• Die eigentliche Funktion von AWS ist: (1) Es ermöglicht organisatorische Skalierung und Machtstrukturen, (2) es erlaubt, statt als CapEx als OpEx zu bilanzieren, und (3) es kaschiert inkompetente Personalstrukturen. Früher konnte man ein Rechenzentrum mit 5 bis 10 Leuten betreiben, heute entstehen DevOps-Organisationen mit 3000 Mitarbeitern

  • Ich verstehe nicht, warum der Unterschied zwischen OpEx und CapEx so wichtig sein soll. Am Ende ist Geld doch Geld, oder?
  • Für frühe Startups ist die Cloud nützlich. Man kann schnell wachsen, ohne sich um Kapazitätsplanung zu kümmern. Aber wenn ein Unternehmen nur langsam wächst und dauerhaft in der Cloud bleibt, wird das ineffizient
  • On-Premises ist oft so stark angepasst, dass Personal nur schwer austauschbar ist. AWS-Fachkräfte dagegen findet man überall
  • Erfahrene Systemadministratoren sind tatsächlich schwer zu finden und teuer. Ich habe erlebt, dass aus Spargründen zwei Jahre lang keine Backups gemacht wurden

• Der Schlüssel zu diesem Erfolg ist eine konstante 24/7-Grundlast. Die meisten Unternehmen haben in der Praxis ein sehr ähnliches Muster

  • Tatsächlich war es anfangs Glück, mit nur einem Rack und einem einzigen Rechenzentrum zu starten. Man musste die Kosten für Zuverlässigkeit nicht vorab tragen
  • Verwandter Artikel: One Big Server
  • AWS zwingt einen mitunter zu Reserved Instances, weil angeblich „kein Bestand“ verfügbar sei. Am Ende landet man bei ähnlichen Kosten wie im Dauerbetrieb
  • Anbieter wie Hetzner liefern dieselbe Leistung für ein Zehntel des Preises von AWS. Die „Elastizität“ der Cloud ist ein übertriebener Mythos

• Elastizität vs. Grundlast ist der Kernpunkt. Nur wenn es wie bei der Datenerfassung zu explosionsartigen Traffic-Spitzen kommt, spielt die Cloud ihre Vorteile aus. In den meisten Fällen ist Bare Metal besser

• In den 2010ern waren Hardware und Netzwerk langsam, heute haben sich CPU-Leistung und Effizienz um Hunderte Male verbessert. Wofür früher 64 Server nötig waren, reicht heute einer. Künftig könnte das Verhältnis sogar 100:1 erreichen. Unter solchen Bedingungen schwinden die Vorteile der Cloud immer mehr

• Aus Sicht eines Amazon-Mitarbeiters ist selbstverwaltetes Kubernetes viel zu riskant. Komponenten wie etcd sind instabil, und wir mussten sogar selbst patchen. Das im Artikel beschriebene Self-Hosting unterschätzt die Risiken

  • Auch andere Hyperscaler hatten große Ausfälle durch fehlgeschlagenes Kubernetes-Management. Einfachere Alternativen für ein einzelnes Rack wie Microk8s sind besser. Verwandter Artikel: Microk8s 6 Months Later
  • Komplexe Umgebungen sind überall schwierig, und am Ende braucht man Spezialisten. Bei AWS ist es genauso wenig einfach. Selbst wenn es Cloud-Ausfälle gibt, dreht sich die Welt weiter
  • Leichtgewichtigere Varianten wie k3 sind deutlich einfacher
  • Kubernetes sollte man nur einsetzen, wenn es wirklich nötig ist. Als Standard ist es eine Verschwendung von Zeit und Geld

• Viele Startups hätten bei den AWS-Preisen vermutlich gar nicht erst existieren können. Etwas wie kostenlose GeoIP-Downloads (Link) wäre zum Beispiel unmöglich gewesen. Die Cloud ist langsam, und Disk-Latenz sowie CPU-Überbelegung sind gravierend. Unter 10.000 Dollar im Monat ist das noch okay, darüber ist Bare Metal viel effizienter

  • Wer sich an die langsame Cloud-Performance gewöhnt, entwickelt eine seltsame Form der Anpassung. Man sollte immer mit Bare Metal als Maßstab vergleichen

• Auch das Unternehmen, in dem ich gearbeitet habe, hatte wenig Traffic und wollte trotzdem zu AWS migrieren. Der Grund war simpel: Man wollte AWS im Lebenslauf stehen haben. Das galt nicht nur für Entwickler, sondern auch für das Management. „Leitung einer AWS-Migration“ sah eben gut im CV aus. Am Ende wurde das Unternehmen verkauft und das Büro stand leer. Vielleicht wird „AWS hinter sich gelassen“ jetzt der nächste Karrierepunkt

  • Wenn Entwickler AWS wollen, kennt die nächste Generation irgendwann nur noch AWS. Die Diskussion wird dadurch verzerrt
  • Letztlich hängt die Entscheidung vom Willen der Führungsebene ab

• Am Ende zählt vor allem, was man eigentlich erreichen will

  • Für eine interne, datengetriebene Website reicht ein Server-Rack völlig aus
  • Bei großem, unregelmäßigem und nicht cachebarem Traffic ist die Cloud im Vorteil
  • Wenn DNS oder Ingress komplex werden, ist ein hybrider Ansatz sinnvoll
  • Je größer die Datenmenge wird, desto stärker spielt die langfristige Abschreibungsstruktur der Cloud ihre Vorteile aus