Multi-Cloud: Wann sich zwei Anbieter rechnen und wann sie nur Aufwand erzeugen

Die wichtigste Zeile ist die dritte. Ein vollständiger Ausfall eines Hyperscalers über Regionsgrenzen hinweg ist selten, ein Ausfall einzelner Dienste in einer Region dagegen regelmäßig. Genau dagegen hilft eine zweite Region, und sie hilft mit denselben Identitäten, denselben Vorlagen und demselben Betriebswissen. Wer stattdessen einen zweiten Anbieter aufbaut, hat im Ernstfall eine Umgebung, die niemand im Bereitschaftsdienst wirklich bedienen kann, weil sie im Alltag keine Last trägt.

aws ce get-cost-and-usage \
  --time-period Start=2026-06-01,End=2026-07-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost UsageQuantity \
  --group-by Type=DIMENSION,Key=USAGE_TYPE \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["EC2 - Other"]}}' \
  --output json | jq -r '
    .ResultsByTime[].Groups[]
    | select(.Keys[0] | test("DataTransfer-Out"))
    | [.Keys[0], .Metrics.UnblendedCost.Amount] | @tsv'

Der ausgehende Datentransfer versteckt sich bei AWS im Dienst EC2 - Other und wird erst über den Nutzungstyp sichtbar. Vergleiche die Summe mit dem, was ihr für Rechenleistung zahlt. Wenn der Transfer zweistellig zur Gesamtrechnung beiträgt, ist eure Architektur über die Anbietergrenze hinweg zu eng gekoppelt.

SUB=$(az account show --query id -o tsv)

az costmanagement query \
  --type ActualCost \
  --scope "/subscriptions/$SUB" \
  --timeframe MonthToDate \
  --dataset-aggregation '{"totalCost":{"name":"Cost","function":"Sum"}}' \
  --dataset-grouping name="MeterCategory" type="Dimension" \
  --output table

# Detailtiefe erhoehen: der Zaehlername nennt die Transferrichtung
az costmanagement query --type ActualCost --scope "/subscriptions/$SUB" \
  --timeframe MonthToDate \
  --dataset-aggregation '{"totalCost":{"name":"Cost","function":"Sum"}}' \
  --dataset-grouping name="MeterSubCategory" type="Dimension" -o table

Achte auf die Zählerkategorie Bandwidth. Beide Anbieter gewähren ein monatliches Freikontingent für ausgehenden Verkehr ins Internet und rechnen darüber hinaus gestaffelt ab, in der Größenordnung einiger Cent je Gigabyte. Das klingt harmlos, bis eine Analyseabfrage täglich mehrere Terabyte über die Anbietergrenze zieht.

# AWS: Objektspeicher
resource "aws_s3_bucket" "daten" {
  bucket = "beispiel-daten-prod"
}

resource "aws_s3_bucket_versioning" "daten" {
  bucket = aws_s3_bucket.daten.id
  versioning_configuration { status = "Enabled" }
}

# Azure: derselbe Zweck, anderer Aufbau, andere Begriffe
resource "azurerm_storage_account" "daten" {
  name                     = "beispieldatenprod"
  resource_group_name      = azurerm_resource_group.prod.name
  location                 = "germanywestcentral"
  account_tier             = "Standard"
  account_replication_type = "ZRS"

  blob_properties {
    versioning_enabled = true
  }
}

Terraform und OpenTofu vereinheitlichen den Weg, nicht das Ziel. Portabel ist das Werkzeug, die Sprache und euer Prozess, nicht der Code. Wer sich für ein Werkzeug entscheiden muss, findet die Argumente in Terraform oder OpenTofu.

# Was in den Manifesten haengt fest an einem Anbieter?
grep -rEn \
  'storageClassName|ingressClassName|service\.beta\.kubernetes\.io|eks\.amazonaws\.com|azure\.workload\.identity|aks|gke-' \
  k8s/ | sort

# Welche StorageClasses existieren im Cluster ueberhaupt?
kubectl get storageclass -o custom-columns=NAME:.metadata.name,PROVISIONER:.provisioner

# Load-Balancer-Annotationen sind fast immer anbieterspezifisch
kubectl get svc --all-namespaces -o json \
  | jq -r '.items[] | select(.spec.type=="LoadBalancer")
           | [.metadata.namespace, .metadata.name,
              (.metadata.annotations // {} | keys | join(","))] | @tsv'

Die Ausgabe ist die ehrlichste Antwort auf die Frage nach Portabilität. Speicherklassen, Lastverteiler-Annotationen und Identitätsanbindung sind die drei Stellen, an denen ein Manifest den Anbieter kennt. Alles andere ist meist übertragbar.

Ordne jede Arbeitslast danach in drei Gruppen ein. Zustandslose Anwendungen in Containern sind portabel und bilden die Gruppe, die einen Parallelbetrieb überhaupt sinnvoll macht. Anwendungen mit Zustand sind übertragbar, aber nur mit Datenmigration und Ausfallzeit. Alles, was auf verwalteten Diensten aufsetzt, also verwaltete Datenbanken, Nachrichtendienste, Identitätsverwaltung oder KI-Plattformen, wird bei einem Wechsel nicht verschoben, sondern neu gebaut. Wie sich diese Bindung bei Datenbanken konkret auswirkt, steht in Welche Datenbank in der Cloud.

Dieser Weg deckt die üblichen Anforderungen ab. DORA verlangt im Finanzsektor dokumentierte Ausstiegsstrategien und die Bewertung von Konzentrationsrisiken, keinen Parallelbetrieb. Der EU Data Act verlangt Wechselunterstützung durch den Anbieter und lässt Wechselentgelte auslaufen. Beides zielt auf Handlungsfähigkeit, nicht auf doppelte Infrastruktur. Wer den Nachweis einmal jährlich übt, hat gegenüber dem Anbieter zugleich das bessere Argument in der Vertragsverhandlung, und zwar ohne die laufenden Kosten eines zweiten Betriebs.