Multi-Cloud

In der Realität oft aus Versehen. Team A startete mit AWS. Team B lieber mit Azure. Plötzlich hat die Firma eine "Multi-Cloud-Strategie" (aka Chaos). Echtes Multi-Cloud (eine App läuft gleichzeitig auf beiden) ist extrem schwer. Meistens nutzt man: Kubernetes. Kubernetes läuft überall gleich. Es abstrahiert den Unterbau weg.

1. Data Egress Fees

Die Kostenfalle. Daten in die Cloud sind kostenlos. Daten aus der Cloud (oder zwischen Clouds) kosten Geld. Wenn App A (AWS) ständig Daten von Datenbank B (Azure) liest, wirst du arm. Man versucht meistens, datenintensive Workloads in einer Cloud zu halten.

2. Abstraktionsschichten

Tools wie Terraform oder Crossplane helfen. Du beschreibst Infrastruktur generisch ("Ich will 1 VM"). Terraform übersetzt das in "AWS EC2" oder "Azure VM".

1. Data Gravity und Egress-Ruination

Ein fundamentales Theorem in Multi-Cloud Strategien ist "Data Gravity" – Datenmassen ziehen Applikationen magisch an sich (durch Latenz und Kosten). Die größte Architektonische Todesfalle ist das "Cross-Cloud-Chattering". Wenn Microservice A (AWS us-east-1) in jedem API-Call die MongoDB in (Azure Central) pingt, entsteht ein Katastrophenszenario. Cloud-Anbieter gewähren kostenlosen Traffic hinein (Ingress), aber bestrafen Datapumping hinaus (Egress) mit rund 0.09 $ pro Gigabyte. Ein kleiner Analytics-Scan zwischen zwei Clouds kann in Echtzeit Hunderttausende Dollar Egress-Kosten im Monat erzeugen. Die brutale physikalische Limitierung (Speed of Light) durch öffentliche Peering-Points (Internet Exchanges) treibt die Latenz zusätzlich von 1ms auf 30ms hoch, was O-Record DB-Reads sofort terminiert. Wer Multi-Cloud baut, darf niemals Storage und Compute zwischen Providern fragmentieren!

2. Der "Lowest Common Denominator" Fail

Manager lieben Terraform, weil es "Provider agnostic" wirkt. Die Praxis-Hölle liegt im Code-Erzwingen des kleinsten gemeinsamen Nenners. Wenn Dev-Teams nur Features nutzen dürfen, die es auf AWS und Azure und GCP exakt gleich gibt, verbieten sie sich selbst extrem mächtige native Services (AWS Aurora, Spanner) und fallen auf stupide "VMs + rohes MySQL" Architektur zurück (Cloud-Agnostic IaaS). Das zerstört den fundamentalen ROI (Return of Investment) der Cloud. Man verliert managed-Backups, globale Autoscaling-Ressourcen und Serverless-Paradigm. Profi-Camps bauen stattdessen auf Polyglot Cloud: Nutze best-of-breed Features hard-gekoppelt (Terraform AWS Modules tief nativ ausreizen) pro Subprojekt, statt die App krampfhaft portabel wie ein 2005er Linux-Image zu schnüren.

3. Identity Brokerage & Federated IAM

Wie authentifiziert der AWS-Lambda-Script den Zugriff auf die Azure-Cosmos-DB? Credentials (Access Keys) hart in den Source Code oder Vaults der Gegenseite zu kopieren, verletzt gnadenlos die Zero Trust Vorgaben. Enterprise Multi-Cloud löst das Problem elegant durch OIDC (OpenID Connect) Federation. Der AWS IAM Server und das Azure Entra ID trusten einander via OIDC-Endpoints. Die AWS Lambda zieht einen temporären JWT-Token in AWS aus ihrem Execution Role Context. Diesen "fremden" JWT feuert sie an die Azure API. Azure verifiziert die kryptografische Signatur des JWT am öffentlichen AWS-Keyset (JWKS URI). Stimmt diese, tauscht Azure den AWS-Token nahtlos in einen kurzlebigen Azure Auth-Token um. Niemals wurden statische Passwörter zwischen den Mega-Rechenzentren synchronisiert!