- Wegen Datensouveränität und GDPR-Compliance-Problemen bei US-Cloud-Diensten entstand die Notwendigkeit, in eine europäische Cloud zu migrieren
- Trotz des vollständigen Verzichts auf den Komfort und die integrierten Services von AWS wurden mit europäischem Hosting wie Hetzner sofortige Kostensenkungen und mehr Klarheit bei den Daten erreicht
- Zur effizienteren Infrastrukturverwaltung wurden Ansible-basierte Automatisierung und ein selbst betriebenes Monitoring-System aufgebaut
- Durch den Eigenaufbau entstand eine Struktur mit strengerem Security-by-Design und einfacherer transparenter Auditierbarkeit
- Auch geschäftlich ergaben sich strategische Vorteile wie 90 % geringere Kosten und ein reduziertes Risiko durch US-Überwachung
Der Umstieg von AWS auf eine europäische Cloud (Hetzner) und die Strategie zur Aufrechterhaltung von ISO 27001
Das Dilemma eines europäischen CTOs: Compliance-Probleme jenseits von AWS
- Eine typische Sorge vieler Tech-Führungskräfte entsteht aus den Grenzen US-amerikanischer Cloud-Anbieter
- Zwar war man mit den leistungsfähigen, ISO-27001-zertifizierten Services von AWS zufrieden, doch durch den US CLOUD Act und FISA ließ sich nicht vermeiden, dass Kundendaten in Europa der US-Gerichtsbarkeit ausgesetzt waren
- Unabhängig vom tatsächlichen Serverstandort entstand damit eine Situation, in der sich GDPR-Zusagen nur schwer einhalten ließen
- Es wurde erkannt, dass die jährlichen Cloud-Kosten von 24.000 US-Dollar im Verhältnis zum tatsächlichen Bedarf überhöht waren
- Zudem wurde spürbar, dass es strategisch riskant ist, die Zukunft des Unternehmens von einem einzelnen US-Anbieter abhängig zu machen
Ein konkretes Praxisbeispiel von Datapult
- Datapult ist ein dänisches Unternehmen für Workforce-Management-Software, bei dem Mitarbeiterplanung, Ausgleich von Überstunden und Verwaltung von Anwesenheitsdaten ein finanzmarktnahes Maß an Zuverlässigkeit erfordern
- Die rechtlichen Anforderungen waren auf den AWS-basierten Workflow abgestimmt, doch ein Wechsel zu On-Premises oder unabhängigen Alternativdiensten erforderte zusätzliche juristische Prüfung
Bedenken beim Verlassen von AWS und die tatsächlichen Verluste
- Der Verzicht auf den integrierten Komfort von AWS stellt psychologisch eine hohe Einstiegshürde dar
- Man verliert die Einfachheit und Automatisierung von Lambda, One-click RDS und diversen eingebauten Compliance-Tools
- Der Wechsel von Managed Services führt zu mehr direkter Kontrolle, aber auch mehr Verantwortung
Erwartete Effekte europäischer Cloud-Anbieter und reale Vorteile
- Durch die Migration zu europäischen Anbietern (Hetzner, OVHcloud) ergeben sich sofortige Vorteile bei Datensouveränität, GDPR und ISO 27001
- Echte Data Residency nachweisbar machen, was transparente Kommunikation mit Kunden und Audits erleichtert
- Unerwartete Kostensenkung um 90 % und mehr Budgettransparenz erreichen
- Trotz des Verzichts auf den AWS-Komfort technisch stärkere Automatisierungsprozesse (Ansible-Konfiguration) und verbesserte Sicherheit aufbauen
- Gegenüber vorher wurden mehr Autonomie, Innovationsspielraum und überprüfbare Infrastruktur gewonnen
Konkrete Migrationsstrategie und wichtigste Erkenntnisse
- Compliance-Automatisierung mit Ansible
- Eine selbstdokumentierende Infrastrukturverwaltung, bei der jede Serverkonfiguration direkt auf die Controls aus Annex A von ISO 27001 verweist
- Aufbau eines Monitoring-Systems als AWS-Alternative
- Mit Prometheus, Grafana und Loki ist Monitoring auf Enterprise-Niveau ähnlich AWS CloudWatch sowie schnelle Incident-Reaktion möglich
- Security by Design zur Stärkung der Sicherheitsarchitektur
- In einer Umgebung ohne gemanagte Security-Tools wurde durch Ansible-Automatisierung das ISMS gestärkt und die Compliance für Entwickler vereinfacht
Strategische Effekte über die Technik hinaus
- Minimierung von Compliance-Risiken durch US-Überwachungsgesetze
- Nutzung einer europäischen Hosting-Infrastruktur als Differenzierungsmerkmal im Vertrieb zur Stärkung von Vertrauen und Markenwert
- Schaffung einer Struktur, in der die eingesparten Cloud-Kosten (90 %) wieder in das Kerngeschäft investiert werden können
Leitfaden zur Anwendung der Migrationsstrategie
- Auf Basis der Erfahrungen mit der Migration von bestehender AWS-Infrastruktur in eine souveräne europäische Cloud bei gleichzeitiger Beibehaltung von ISO 27001 lassen sich reproduzierbare Leitlinien bereitstellen
- CTOs und Gründer, die einen Wechsel von AWS in eine europäische Cloud erwägen, können individuelle Beratung zu Kostenanalyse, Compliance-Risiken und Umsetzungszeitplan erhalten
- Innerhalb einer Stunde lassen sich Kostenunterschiede, zentrale rechtliche Risiken und die ersten Schritte der Migration strukturieren
1 Kommentare
Hacker-News-Kommentare
Wir haben Kosten gespart, indem wir zentrale AWS-Funktionen selbst nachgebaut haben, aber viele übersehen die echten Kosten von DIY-Hosting, insbesondere Dinge wie 24/7-Support. Wenn man so etwas intern aufbauen will, kann es am Ende ziemlich teuer werden. AWS-Kosten von 24.000 $ pro Jahr entsprechen 1–2 Monaten eines hervorragenden DevOps-Freelancers oder etwa 1/3 FTE eines günstigen Entwicklers, und mit diesem Budget kann man kaum ernsthaft 24/7-Bereitschaft erwarten. Natürlich kann diese Entscheidung sinnvoll sein, aber ich finde es schade, dass nicht ehrlich alle Kosten offengelegt werden, etwa Entwicklungszeit und Verwaltungsaufwand. Ich prüfe selbst eine ähnliche Entscheidung, allerdings eher wegen geschäftlicher Anforderungen wie deutschen Kunden als nur zur Kostensenkung. Es wird aber komplexer und wir müssten das Team erweitern. Als CTO ist meine Zeit begrenzt, und mich direkt in solche Arbeit einzuklinken, ist die schlechteste Nutzung meiner Zeit. Ich sollte mich stärker auf die Weiterentwicklung von Firma und Produkt konzentrieren. Persönlich halte ich Terraform in dieser Größenordnung für übertrieben, und Ansible wirkt hier wie ein besser passender YAGNI-Fall (You Ain’t Gonna Need It).
Viele glauben fälschlicherweise, große Cloud-Anbieter wie AWS, Azure oder GCP würden tatsächlich 24/7-Anwendungssupport leisten, aber in Wirklichkeit ist das nicht so. Die Infrastruktur läuft nur „meistens“ zuverlässig, und um sie wirklich gut zu nutzen, braucht man weiterhin Fachleute, die Kostenexplosionen oder Integrationsprobleme im Blick behalten. Die Vorstellung, dass die Cloud-Rechnung den tatsächlichen TCO (Total Cost of Ownership) abbildet, ist ein kompletter Mythos.
Wenn man AWS-Funktionen zu 100 % nachbildet, kann das teuer werden, aber wenn man nur 80 % braucht, sieht die Sache anders aus. Außerdem darf man den Aufwand nicht unterschätzen, AWS überhaupt einzurichten und das nötige Know-how dauerhaft aktuell zu halten. Statt des AWS-Dashboards kann man zum Beispiel auch bessere Tools wie Grafana nutzen. Letztlich hängt alles von Größe und Vielfalt der Anforderungen ab. Nicht immer ist der teuerste Hammer die richtige Antwort.
Rein rechnerisch entspricht die Einsparung 90 % von ursprünglich 24.000 $, also 21.600 $ pro Jahr. Mit diesem Budget bekommt man in Europa aber keinen SRE-/DevOps-Ingenieur eingestellt. Ich denke eher, dass die gesamten Betriebskosten langfristig steigen werden, weil man mit der Zeit die gesamte Infrastruktur selbst verwalten muss. Trotzdem drücke ich die Daumen.
Wenn man das Risiko bedenkt, dass die US-Regierung Amazon zur Sperrung eines Accounts zwingen könnte, kann AWS riskant sein. In einer Lage, in der zuletzt sogar von Krieg zwischen den USA und Europa (Grönland) gesprochen wird, gilt das umso mehr.
Diese einfache Rechnung mit 24.000 $ pro Jahr wirkt auf mich zu naiv. Es fehlt eine konkrete Kalkulation der Personalkosten: wie viele Leute man braucht, um diese Services auf AWS aufzubauen, und wie viel Personal nötig ist, um beispielsweise 48.000–100.000 $ auf 24.000 $ zu senken.
Ich denke, dass sich mit der Kombination aus Prometheus, Grafana und Loki das Monitoring-Niveau von AWS nicht nur nachbauen, sondern teilweise sogar übertreffen ließ. Es überrascht mich immer wieder, dass diese Tools so gut sind, während die Monitoring-Services von AWS teuer, langsam und in der UX enttäuschend sind. Tatsächlich waren die Monitoring-Kosten immer der schnellste und unerquicklichste Teil der AWS-Erfahrung.
Die größten Nachteile von Hetzner sind aus meiner Sicht die durch missbräuchliche Nutzer belastete IP-Reputation sowie mögliche Hardwareausfälle bzw. nötige Upgrades. Mich würde interessieren, ob das kein Problem war. Außerdem würde mich interessieren, wie das Problem des explodierenden Speicherverbrauchs von Loki gelöst wurde und ob es andere Alternativen gibt.
Das Problem mit der IP-Reputation lösen wir, indem wir den Benutzerzugriff über Cloudflare proxien und in der Firewall (
ufw) sowie über erlaubte Cloudflare-IP-Quellen nur diese Zugriffe zulassen, sodass externer Direktzugriff komplett blockiert ist. Hardwareausfälle und Upgrades lassen sich mit einem Terraform-Setup in kurzer Zeit durch Austausch und Kapazitätserweiterung bewältigen. Wir überwachen die Hardware mit Prometheus und node exporter und erhalten frühzeitig Warnungen; in 9 Monaten gab es keinen Ausfall. Die App hat fast keine Daten, und die Datenbank wird regelmäßig auf Wiederherstellbarkeit getestet. Das Speicherproblem von Loki lösen wir durch eine Kombination aus Aufbewahrungsrichtlinien und Index-Trennung, Tuning von Query-Konkurrenz und Speichergrenzen, Einführung von promtail-artigen Labels und strukturiertem Logging sowie Ersatz älterer Daten durch Object-Storage-Backups odergrep.Die Loki-Probleme, die wir erlebt haben, lagen daran, dass die Standard-Deployment-Einstellungen, etwa über Helm, nicht ausreichend optimiert sind. Nachdem wir die im Blog erwähnten Performance-Tipps wie Index-Reset, zusätzliche Read-only-Instanzen und weitere Empfehlungen umgesetzt haben, sahen wir eine deutliche Leistungssteigerung. Ich denke, man will eher in den eigenen Cloud-Service lenken, deshalb muss man am Anfang etwas herumprobieren.
Als Alternative zu Loki empfehle ich Victoria. Es ist deutlich schneller und hat einen guten Ruf, aber wir haben uns wegen der größeren Vielfalt an Projekt-Maintainern für Loki entschieden. Die oben genannten Methoden gleichen die Nachteile aus.
Teilen des Links: https://en.wikipedia.org/wiki/Sybil_attack. Ein Vorteil teurer Cloud-Anbieter ist, dass sie sich gewissermaßen über etwas Ähnliches wie PoW (Proof of Work) eine IP-Reputation aufbauen.
ISO 27001 ist ein internationaler Standard für Sicherheitsmanagement und in Europa eine beliebte Richtlinie. In den USA wird er kaum angewendet, und viele europäische Unternehmen können mit diesem Unterschied oft nicht gut umgehen. Der grundlegende Sicherheitsstandard in den USA ist SOC 2, der weniger streng ist als ISO 27001 und dem US-Markt vertrauter.
ISO 27001 ist an sich kein besonders starres oder übermäßig hartes Regelwerk, sondern verlangt im Allgemeinen die grundlegenden Dinge, die man beim Einsatz von Software ohnehin tun sollte. Schwierig ist nur, das Ganze sauber zu dokumentieren; im Vergleich dazu ist der Dokumentationsaufwand bei SOC 2 deutlich geringer.
Aus meiner Erfahrung mit sowohl SOC 2 als auch ISO 27001 ist es schade, dass SOC-2-Audits oft stärker von Kompetenz und Intuition des Prüfers abhängen als von den tatsächlichen operativen Kontrollen. ISO 27001 wirkt für mich viel klarer und fairer.
Bitte nenn mir nur einen großen US-Cloud-Anbieter, der keine ISO-27001-Zertifizierung hat.
Ich habe mit Azure eine ähnliche Konfiguration umgesetzt und ebenfalls 90 % eingespart. Es fühlt sich so an, als würden große Anbieter absichtlich immer komplexere Service-Abstraktionen aufzwingen, sodass einfacher Betrieb zunehmend schwieriger wird.
Einer der Gründe, warum man für AWS bezahlt, ist die geringere Betriebsbelastung, und seit ich die Managed DB von AWS nutze, habe ich nicht mehr den Stress wie früher bei Upgrades eines mysql-Clusters. Natürlich rechtfertigt das allein die hohen Kosten nicht, aber ich halte es für einen erheblichen Wert.
Die Zahlen verstehe ich nicht. Wenn man bei 24.000 $ pro Jahr 90 % spart, bleiben 200 $ pro Monat übrig, das entspricht ungefähr dem Preis eines einzelnen Hetzner-Servers. In so einer Situation müsste doch vermutlich schon ein einzelner Server ohne verteiltes System reichen. Mich würden die tatsächlichen Requests pro Sekunde oder die Nutzerzahlen interessieren.
Für ISO-27001-Compliance reicht ein einzelner Server nicht aus; man braucht auch einen separaten Server nur für Logging und Monitoring. Unabhängig von der Last entsteht dadurch zwangsläufig Komplexität. Die Mitarbeitenden loggen sich nicht täglich ein, und wegen der Natur einer Scheduling-App schauen manche nur ein- oder zweimal pro Woche hinein. Die DAU liegen bei 10.000–20.000, die gleichzeitigen Spitzenzugriffe bei 1.500–2.000 Nutzern, die durchschnittliche gleichzeitige Last bei 50–150. Die hohen Cloud-Kosten kommen daher, dass Echtzeitfunktionen und komplexe Arbeitsregeln in der App die Datenverarbeitung stark belasten. Zum Beispiel unterscheiden sich Regeln für Bonusberechnungen bei Schichtzuweisungen, und auch die Optimierung von Dienstplänen ist rechnerisch aufwendig.
Korrektur: nicht 2.400 $, sondern 200 $.
Ich frage mich, wie die Festplattenverschlüsselung umgesetzt wird. Bei AWS läuft das automatisch, aber bei gewöhnlichen Hosting-Anbietern habe ich noch keine wirklich gute Umsetzung gesehen. Es wurde auch darauf hingewiesen, dass es sinnlos wäre, den Schlüssel auf der Boot-Partition zu speichern.
Ich mag Hetzner wirklich sehr, deshalb betreibe ich dort auch meine Suchmaschine. Ich finde physische Server einfach am besten.
Neben OVH und Hetzner möchte ich unter den europäischen Clouds auch UpCloud empfehlen. Ein Vorteil von UpCloud scheint zu sein, dass alle CPU-Kerne echte Kerne sind und nicht vCPU-basiert auf Threads. Schade ist nur, dass es an offizieller Referenzdokumentation mangelt. Ein Vergleich zwischen OVH, Hetzner und Hyperscalern ist nicht ganz einfach; bei Hetzner ist der Unterschied unter anderem, dass dort größtenteils Consumer-Hardware verwendet wird. UpCloud Einführung
upcliund Ähnliches nutzen muss. OpenStack Service Users OpenStack Federation UpCloud Crossplane Leitfaden UpCloud Unterkonto-Verwaltung UpCloud Berechtigungs-Einstellungen