Multi-Cloud-Strategien mit Azure

Multi-Cloud bezeichnet den Betrieb von Workloads über mehrere Cloud-Anbieter hinweg – beispielsweise die Nutzung von Azure für die meisten Dienste und AWS für eine bestimmte Machine-Learning-Plattform oder Google Cloud für BigQuery-Analysen. Organisationen setzen auf Multi-Cloud, um Vendor Lock-in zu vermeiden, die jeweils besten Dienste der einzelnen Anbieter zu nutzen, vertragliche oder regulatorische Anforderungen zur Vermeidung der Abhängigkeit von einem einzigen Anbieter zu erfüllen oder weil durch Fusionen und Übernahmen Unternehmen zusammengeführt wurden, die unterschiedliche Clouds als Standard eingesetzt haben. Multi-Cloud ist heute in großen Unternehmen der Regelfall.

Multi-Cloud bringt erhebliche betriebliche Herausforderungen mit sich: Verzettelung bei den Kompetenzen – Teams benötigen Fachwissen zu mehreren Cloud-Plattformen. Uneinheitliche Governance – jede Cloud verfügt über unterschiedliche Tools für IAM, Richtlinien und Compliance. Komplexität der Sicherheit – unterschiedliche Bedrohungsmodelle, Sicherheitsdienste und Auditprotokolle. Kostenmanagement – separate Abrechnungsportale, unterschiedliche Abrechnungseinheiten und keine einheitliche Kostenübersicht über alle Anbieter hinweg. Netzwerkkomplexität – Datenverkehr zwischen Clouds verursacht Egress-Kosten und Latenz. Microsoft begegnet vielen dieser Herausforderungen mit Azure Arc und der Multi-Cloud-Unterstützung in Defender for Cloud.

Der gleiche Agent für verbundene Computer von Azure Arc, der auch lokale Server integriert, funktioniert außerdem auf VMs in AWS EC2, Google Cloud Compute Engine und jeder anderen Cloud. Sobald diese VMs bei Arc registriert sind, werden sie im ARM-Portal neben nativen Azure-Ressourcen angezeigt. Sie können Azure Policy anwenden, Azure Monitor mit denselben KQL-Abfragen verwenden und Sicherheitsempfehlungen von Defender for Cloud für AWS- und GCP-VMs anzeigen – ohne das Azure-Portal zu verlassen oder AWS-spezifische Tools zu erlernen.

Microsoft Defender for Cloud unterstützt native Konnektoren für AWS und Google Cloud Platform. Durch die Verbindung Ihres AWS-Kontos oder GCP-Projekts kann Defender for Cloud die Sicherheitslage von EC2-Instanzen, S3-Buckets, RDS-Datenbanken und GCP-Ressourcen mithilfe desselben Secure-Score-Frameworks bewerten, das auch für Azure verwendet wird. Die Lösung ordnet Ergebnisse Standards wie dem CIS AWS Foundations Benchmark zu und erkennt Fehlkonfigurationen (öffentlich zugängliche S3-Buckets, zu weit gefasste IAM-Rollen) zusammen mit Azure-Empfehlungen in einem einzigen Dashboard.

Azure Cost Management + Billing kann AWS-Kosten übernehmen, indem Sie Ihren AWS Cost and Usage Report (CUR) mit einem Azure-Connector verbinden. Dadurch werden AWS-Ausgaben neben Azure-Ausgaben in einer einheitlichen Kostenanalyseansicht dargestellt, was cloudübergreifende Kostenvergleiche und -zuordnungen ermöglicht. Sie können Budgets und Warnungen erstellen, die beide Anbieter umfassen, und dieselbe Tagging-Strategie für Showback/Chargeback anwenden. Diese cloudübergreifende Kostentransparenz ist für FinOps-Teams wertvoll, die Ausgaben bei mehreren Anbietern über eine zentrale Oberfläche verwalten.

Viele Multi-Cloud-Strategien verwenden Kubernetes als Abstraktionsebene, die in jeder Cloud identisch betrieben wird. AKS in Azure, EKS in AWS und GKE in GCP führen alle standardmäßiges Kubernetes aus. Azure Arc-enabled Kubernetes kann sie alle von Azure aus verwalten und dabei GitOps-basierte Bereitstellungen sowie Azure Policy (OPA Gatekeeper) einheitlich anwenden. In Azure Container Registry gespeicherte Containerimages können aus dem Kubernetes-Cluster jeder Cloud abgerufen werden, wodurch Azure ACR zu einem naheliegenden Hub für eine cloudübergreifende Image-Registry wird.

Eine Azure Landing Zone ist eine vorkonfigurierte Umgebung, die Best Practices für Governance, Identität, Sicherheit und Netzwerke umsetzt. Bei der Einführung von Multi-Cloud erweitern Organisationen das Konzept der Landing Zone, um Standards zu definieren, die für alle Anbieter gelten. Das Microsoft Cloud Adoption Framework (CAF) enthält Anleitungen für Multi-Cloud, unter anderem zur Strukturierung von Verwaltungshierarchien, Namenskonventionen und Tagging-Strategien, die einheitlich funktionieren, unabhängig davon, ob sich die Ressource in Azure, AWS oder lokal befindet.

Die Verbindung von Azure- und AWS- (oder GCP-)Workloads erfordert cloudübergreifende Netzwerke. Gängige Muster: VPN-Tunnel zwischen Azure VPN Gateway und einem AWS Virtual Private Gateway oder GCP VPN – unkompliziert, aber mit begrenzter Bandbreite und schwankender Latenz. SD-WAN von Drittanbietern (z. B. Megaport, Equinix Fabric) – erstellt private cloudübergreifende Verbindungen ähnlich wie ExpressRoute. Integration auf Anwendungsebene – Dienste kommunizieren über HTTPS über öffentliche Endpunkte (die einfachste Option, bei der jedoch das Internet verwendet wird). Die Kosten für ausgehende Bandbreite in AWS und GCP machen umfangreiche cloudübergreifende Datenübertragungen teuer.

Microsoft Entra ID kann als Identitätsanbieter (IdP) für den Multi-Cloud-Zugriff dienen. Für AWS können Sie Entra ID as the SAML 2.0 IdP for AWS IAM Identity Center konfigurieren. Dadurch können Benutzer mit ihren Entra-ID-Anmeldeinformationen und MFA auf die AWS-Konsole zugreifen – ohne separate AWS-IAM-Benutzer. Für GCP ist eine ähnliche Föderation möglich. Dadurch wird die Identitätsgovernance zentralisiert: Neue Benutzer, Rollenwechsel und ausscheidende Benutzer werden in Entra ID verwaltet, und die Zugriffsrechte werden automatisch an alle Cloud-Anbieter weitergegeben.

FinOps-Praktiken (Cloud Financial Operations) werden in Multi-Cloud-Umgebungen komplexer, da jeder Anbieter unterschiedliche Preismodelle, Rabattmechanismen und Abrechnungsgranularitäten verwendet. Best Practices sind: das Tagging bei allen Anbietern für die Kostenzuordnung zu standardisieren; den AWS-Connector von Azure Cost Management + Billing für eine einheitliche Übersicht zu verwenden; ein FinOps-Team aufzubauen, das Reserved Instances (Azure), Savings Plans (AWS/Azure) und Committed Use Discounts (GCP) versteht; und regelmäßig cloudübergreifende Kostenprüfungen durchzuführen, bei denen die Kosten gleichwertiger Workloads verglichen werden.

Multi-Cloud kann zu Problemen führen, wenn sie nicht sorgfältig verwaltet wird. Häufige Anti-Patterns, die Sie vermeiden sollten: Unbeabsichtigte Multi-Cloud-Nutzung – die Verwendung mehrerer Clouds ohne Strategie führt zu unkontrollierter Ausbreitung und steigenden Kosten. Überforderung bei den Kompetenzen – von allen Ingenieuren zu verlangen, Experten für jede Cloud zu sein; bestimmen Sie stattdessen Cloud-Verantwortliche für die jeweiligen Plattformen. Uneinheitliche Sicherheit – unterschiedliche Sicherheitsbaselines pro Cloud anzuwenden; verwenden Sie Azure Arc und Defender for Cloud, um Einheitlichkeit durchzusetzen. Ignorieren von Egress-Kosten – cloudübergreifende Datenübertragungen werden zu den Egress-Tarifen der Anbieter abgerechnet und können FinOps-Teams überraschen.

Testen Sie Ihr Verständnis der Konzepte aus Microsoft Azure Fundamentals (AZ-900) in dieser Lektion.

In dieser Lektion haben Sie gelernt: Azure Arc erweitert die Azure-Verwaltung auf AWS- und GCP-VMs, wobei derselbe Agent für verbundene Computer verwendet wird. Die Multi-Cloud-Konnektoren von Microsoft Defender for Cloud stellen cloudübergreifende Sicherheitsergebnisse in einem einheitlichen Secure Score dar, und die Föderation mit Microsoft Entra ID ermöglicht die einmalige Anmeldung bei AWS- und GCP-Konsolen über eine zentrale Unternehmensidentität. Damit ist der Kurs zu Azure Hybrid und Multi-Cloud abgeschlossen – als Nächstes folgt das Well-Architected Framework zur Bewertung und Verbesserung Ihrer Azure-Architekturen.