Cloud-Engineering für Behörden: Was wir aus dem parallelen Betrieb von AWS, Azure und GCP gelernt haben

„Multi-Cloud“ wird als Strategie verkauft. Meistens ist es aber keine – sondern eine Folge. Eine Abteilung verfügt bereits über eine Azure-Tenancy aus ihrem M365-Bestand, ein Implementierungspartner hat den letzten Dienst auf AWS aufgebaut, und ein Data-Science-Team möchte BigQuery nutzen. Niemand hat das so geplant. Aber irgendjemand muss das Ganze trotzdem betreiben.

Nachdem ich ein Jahrzehnt lang Plattformen auf AWS, Azure und Google Cloud für Kunden aus dem öffentlichen Sektor entwickelt habe, möchte ich hier darlegen, worauf es wirklich ankommt, wenn man die Debatte um die „beste Cloud“ hinter sich gelassen hat und sich nun darauf konzentriert, Produktions-Workloads sicher, konform und kostengünstig zu betreiben.

1. Souveränität und Klassifizierung haben Vorrang vor der Architektur

Bei kommerziellen Projekten ist die Wahl des Standorts eine leistungsbezogene Entscheidung. Bei staatlichen Projekten ist sie in erster Linie eine rechtliche Entscheidung.

Bevor auch nur ein einziges Terraform-Modul geschrieben wird, legen wir Folgendes fest:

• Welcher Geheimhaltungsstufe unterliegen diese Daten – „OFFICIAL“, „OFFICIAL-SENSITIVE“ oder höher?
• Welche Region(en) erfüllen die Wohnsitzvoraussetzung, und entspricht das Modell der geteilten Verantwortung des Anbieters tatsächlich dieser Voraussetzung oder wird dies nur behauptet?
• Wer verwahrt die Verschlüsselungsschlüssel – der Anbieter, oder sieht der Vertrag vor, dass die Schlüssel vom Kunden verwaltet werden (CMK/BYOK)?

# Encryption key ownership is a decision, not a default
resource "aws_kms_key" "official_sensitive" {
  description             = "CMK for OFFICIAL-SENSITIVE workloads"
  deletion_window_in_days = 30
  policy                  = data.aws_iam_policy_document.key_admins.json
  # Key never leaves customer control — no provider-managed fallback
}

Wenn man hier einen Fehler macht, kann das später auch mit noch so viel technischem Know-how nicht mehr behoben werden. Wir haben schon erlebt, dass Migrationen monatelang ausgesetzt wurden, weil die Datenlokalisierung lediglich angenommen, aber nicht überprüft wurde.

2. Wählen Sie für jede Arbeitslast die passende Cloud aus – statt eine einzige Cloud für alles zu nutzen

Die Teams, die mit Multi-Cloud-Lösungen zu kämpfen haben, sind diejenigen, die versuchen, jede Arbeitslast überall portabel zu machen. Die Teams, die erfolgreich sind, wählen für jede Arbeitslast einen Hauptanbieter aus, je nachdem, worin dieser tatsächlich gut ist, und standardisieren die Schnittstellen zwischen ihnen.

Der Fehler besteht nicht darin, drei Wolken zu verwenden. Der Fehler besteht darin, drei Wolken zu verwenden, ohne sich zu entscheiden. warum für jeden einzelnen.

3. Kubernetes ist das Einzige, was Multi-Cloud erträglich macht

Die APIs für Rechenleistung, IAM und Netzwerke unterscheiden sich bei AWS, Azure und GCP in einer Weise, die sich nie vollständig abstrahieren lässt. Kubernetes kommt einer gemeinsamen Basis am nächsten und ist die einzige Investition, die sich unabhängig davon auszahlt, für welche Anbieter Sie sich letztendlich entscheiden.

# Same manifest, three managed control planes
# EKS, AKS and GKE all accept this without modification
apiVersion: apps/v1
kind: Deployment
metadata:
  name: claims-api
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: claims-api
          image: registry.internal/claims-api:1.4.2
          resources:
            requests: { cpu: "250m", memory: "256Mi" }
            limits:   { cpu: "500m", memory: "512Mi" }

Im Hintergrund nutzen wir nach wie vor die nativen Dienste der Anbieter – RDS, Cosmos DB, Cloud SQL –, da sich die Neuimplementierung verwalteter Datenbanken auf Kubernetes nur selten lohnt. Die Anwendungsebene bleibt jedoch portabel, und genau diese Portabilität ermöglicht es einer Abteilung, eine Arbeitslast zu verlagern, wenn sich die Rahmenbedingungen ändern.

4. FinOps ist eine wöchentliche Routine, keine jährliche Überprüfung

Kostenüberschreitungen im Cloud-Bereich im öffentlichen Sektor sind selten auf eine einzige Fehlentscheidung zurückzuführen. Sie entstehen vielmehr dadurch, dass niemand einen Blick darauf wirft, bis die Rechnung auf dem Schreibtisch eines Leiters landet.

# What an unmanaged multi-cloud bill actually looks like after 12 months
AWS:   forecast £18k/mo → actual £31k/mo  (orphaned EBS volumes, over-provisioned RDS)
Azure: forecast £9k/mo  → actual £14k/mo  (dev/test resources never torn down)
GCP:   forecast £4k/mo  → actual £4.2k/mo (tagged and budget-alerted from day one)

Die GCP-Linie sticht aus gutem Grund hervor – dort wurden Budgetwarnungen und die obligatorische Kennzeichnung bereits ab dem Start durch Richtlinien durchgesetzt. Bei den beiden anderen war dies nicht der Fall, bis wir diese Funktion hinzugefügt haben.

# Tag enforcement at the policy layer, not the honour system
resource "aws_organizations_policy" "require_cost_tags" {
  content = jsonencode({
    tags = {
      "cost-centre" = { tag_key = { "@@assign" = "cost-centre" }, enforced_for = { "@@assign" = ["ec2:instance", "rds:db"] } }
    }
  })
}

Die Einhaltung von Tags, Budgetwarnungen und eine wöchentliche Kostenüberprüfung machen den Unterschied zwischen einer Prognose und einer Fantasie aus.

5. „Infrastructure as Code“ ist die einzige verlässliche Informationsquelle – oder gar nichts

Multi-Cloud ohne IaC bedeutet drei Konsolen, drei verschiedene Wissensinseln und einen Änderungsverlauf, der nach dem Ausscheiden der Mitarbeiter in niemandes Kopf mehr vorhanden ist. Terraform (oder OpenTofu) mit anbieterbezogenen Modulen hinter einer gemeinsamen Schnittstelle ist das, was Audits überhaupt erst durchführbar macht.

module "network" {
  source   = "./modules/network/${var.cloud_provider}"
  cidr     = var.network_cidr
  env      = var.environment
}

Jede Änderung durchläuft denselben PR-Prüfungsprozess, dieselbe „Plan-before-Apply“-Prüfung und denselben Prüfpfad – unabhängig davon, auf welche Cloud sie abzielt. Diese Konsistenz ist für einen ISO 27001- oder Cyber Essentials Plus-Prüfer wichtiger als die Frage, welchen Anbieter Sie ausgewählt haben.

Die wichtigsten Erkenntnisse

• Zuerst klassifizieren, dann entwerfen — Souveränität und Eigentumsverhältnisse sind rechtliche Entscheidungen, keine infrastrukturellen
• Wählen Sie je nach Arbeitslast bewusst aus — Eine zufällige Multi-Cloud-Umgebung ist ein Risiko; eine bewusst geplante Multi-Cloud-Umgebung ist eine Stärke
• Kubernetes ist die Portabilitätsschicht — dort investieren, anstatt überall eine vollständige Cloud-Unabhängigkeit anzustreben
• FinOps ist ein kontinuierlicher Prozess — Die Durchsetzung von Tags und Budgetwarnungen sind einer vierteljährlichen Tabellenkalkulation jedes Mal überlegen
• IaC ist Ihr Prüfpfad — Was nicht im Code steht und nicht überprüft wurde, ist nicht passiert

Multi-Cloud ist an sich weder eine gute noch eine schlechte Strategie. Es handelt sich um eine Reihe von Vorgaben, die Ihnen bereits von anderen auferlegt wurden. Die Aufgabe der Entwickler besteht darin, diese Vorgaben „langweilig“ zu machen – also vorhersehbar, überprüfbar und kostengünstig im Betrieb.