Im Vergleich: Hybride Netzwerke der großen Hyperscaler

Anthos und Kubernetes-Cluster

Anthos definiert Kubernetes als zentrales Objektmodell. Cluster, Namespaces, Deployments und Policies bilden die operative Ebene. Config Management synchronisiert Konfigurationen aus Git-Repositories, der Policy Controller validiert Admission Requests auf API-Ebene. Service-Mesh ergänzt die Plattform um L7-Steuerung, mTLS und Telemetrie. Der Plattformgedanke greift somit tief in den Lebenszyklus containerisierter Anwendungen ein. Persistenz bleibt extern, doch die Nutzung erfolgt deklarativ über StorageClasses, die Cluster-übergreifend identische fachliche Bedeutungen tragen müssen.

Azure Arc setzt nicht beim Cluster an, sondern beim Azure Resource Manager. Ressourcen außerhalb von Azure erhalten eine Azure Identität und erscheinen als reguläre Azure-Objekte. Richtlinien, Tags, RBAC (Role Based Access Control) und Monitoring greifen auf dieser Ebene. Arc verändert den internen Aufbau eines Kubernetes-Clusters nicht. Der Cluster behält seinen eigenen Lifecycle. Arc ergänzt eine Verwaltungs- und Governance-Schicht, die Server, Kubernetes-Cluster und Datenbankdienste in ein gemeinsames Modell überführt.

AWS verfolgt keinen einheitlichen Plattformkern. EKS betreibt Kubernetes in der AWS Cloud. EKS Anywhere bringt diese Distribution in das eigene Rechenzentrum. Systems Manager verwaltet Knoten und Automationsläufe über Agenten. Control Tower strukturiert Multi-Account-Landschaften und setzt Guardrails durch. AWS Config überwacht Konfigurationszustände, CloudTrail protokolliert API-Aktivitäten. Die Steuerung verteilt sich somit auf mehrere spezialisierte Dienste. Eine durchgehende Plattforminstanz existiert nicht, sondern ein zusammengesetztes Steuerungsgefüge.

Azure Arc-enabled Kubernetes als Managementschicht über fremde Cluster

Azure Arc-enabled Kubernetes bindet Kubernetes-Cluster unabhängig von deren Laufzeitumgebung in das Azure-Ressourcenmodell ein. Nach der Installation der Arc-Agenten baut der Cluster eine ausgehende Verbindung zu Azure auf und registriert sich als eigenständige Ressource im Azure Resource Manager. Der Cluster erscheint anschließend in Resource Groups, erhält Tags und unterliegt Azure RBAC sowie Azure Policy. Die interne Kubernetes-Distribution bleibt unverändert, da Arc keine eigene Laufzeit ersetzt, sondern eine Verwaltungs- und Governance-Ebene ergänzt.

Arc unterstützt CNCF-konforme Kubernetes-Distributionen auf Public Clouds wie AWS oder Google Cloud ebenso wie On-Premises-Umgebungen auf VMware oder Bare Metal. Über GitOps-gestützte Konfigurationsverwaltung lassen sich Anwendungen aus einem Repository ausrollen. Azure Monitor sammelt Telemetriedaten für Container, Microsoft Defender for Kubernetes erweitert Bedrohungserkennung, Azure Policy prüft Richtlinien auf Namespace- und Cluster-Ebene. Darüber hinaus lassen sich Datenservices, Event Grid oder App Services direkt auf angebundenen Clustern bereitstellen. In Verbindung mit Azure Kubernetes Fleet Manager entsteht ein Steuerungsrahmen für Multi-Cluster-Landschaften, der Governance, Zugriffskontrolle und Workload-Bereitstellung über Azure konsolidiert, ohne die zugrunde liegenden Kubernetes-Plattformen technisch zu vereinheitlichen.

Anthos als verbindende Steuerungsebene zwischen Azure und AWS

Google Anthos fungiert in einer Multi-Cloud-Architektur auch als zentrale Steuerungsinstanz, die Kubernetes-Cluster in Microsoft Azure und Amazon Web Services unter einem gemeinsamen Kontrollrahmen zusammenführt. Die Plattform nutzt die Anthos Multi-Cloud API und die Connect-Komponente, um externe Cluster an die Managementebene anzubinden.

Über die Google Cloud Console oder gcloud greifen Administratoren auf Azure- und AWS-Cluster zu, ohne deren nativen Kontrollmechanismus zu ersetzen. Ressourcenbereitstellung erfolgt weiterhin über Azure REST API oder AWS REST API, doch Konfigurationszustand, Policy-Durchsetzung und Observability laufen zentral über Anthos. Identitätsintegration bindet Azure AD und AWS IAM über Service Accounts und App-Registrierungen ein, sodass API-Aufrufe autorisiert bleiben und Kubernetes-Operationen Cluster-übergreifend konsistent ablaufen. Anthos wirkt damit als übergeordnete Orchestrierungsschicht, die Deployments, GitOps-Workflows und Richtlinien über verschiedene Cloud-Infrastrukturen hinweg synchronisiert, ohne die jeweiligen Provider-spezifischen Laufzeitumgebungen technisch zu vereinheitlichen.

Kubernetes-Betrieb und Lifecycle-Kontrolle

Anthos integriert den Cluster-Betrieb in die Plattform. Upgrades, Addon-Verwaltung, Policy-Durchsetzung und Mesh-Integration greifen ineinander. Mehrere Cluster in unterschiedlichen Umgebungen lassen sich über denselben Kontrollrahmen steuern. Die Betriebslogik bleibt unabhängig vom Standort der Infrastruktur.

Azure Arc bindet Cluster an Azure an, ersetzt jedoch keinen Lifecycle-Manager. Upgrade-Strategien, CNI-Auswahl und CSI-Integration verbleiben beim jeweiligen Kubernetes-Stack. Arc steuert GitOps-Konfigurationen und prüft Richtlinien, greift jedoch nicht in grundlegende Cluster-Mechanismen ein.

AWS trennt diese Ebenen. EKS in der Cloud ist verwaltet. EKS Anywhere verlangt kundenseitige Steuerung. Systems Manager ergänzt operative Kontrolle, ersetzt jedoch keinen Kubernetes-Lifecycle-Manager. Control Tower wirkt auf Kontoebene, nicht auf Cluster-Ressourcen. Diese Aufteilung verlangt ein internes Plattformkonzept, das Zuständigkeiten eindeutig definiert.

Amazon EKS Hybrid Nodes als Erweiterung des Kubernetes-Betriebs in AWS

Amazon EKS Hybrid Nodes erweitert Amazon EKS um die Möglichkeit, Worker Nodes außerhalb der AWS-Cloud in bestehende EKS-Cluster einzubinden. Die Steuerung des Kubernetes-Control-Planes verbleibt vollständig in AWS, während die Rechenknoten im eigenen Rechenzentrum oder an Edge-Standorten betrieben werden. Dieses Modell entlastet lokale Infrastruktur von Control-Plane-Aufgaben und vereinheitlicht Betrieb, Monitoring, Logging und Identitätsintegration über AWS-Dienste.

Die Einbindung erfolgt über eine gesicherte Netzwerkverbindung zwischen dem entfernten Standort und der VPC des EKS-Clusters, häufig über Transit Gateway in Kombination mit Direct Connect oder Site-to-Site-VPN. Der hybride Knoten registriert sich im Cluster und verhält sich wie ein regulärer Worker, ohne dass eine eigene Control-Plane-Komponente lokal betrieben werden muss. AWS übernimmt Hochverfügbarkeit und Skalierung der Control-Planes, wodurch sich der Betriebsaufwand für verteilte Kubernetes-Umgebungen reduziert.

Im Zusammenspiel mit Systems Manager, CloudWatch und IAM integriert sich EKS Hybrid Nodes nahtlos in das bestehende AWS-Ökosystem. Identität und Zugriff bleiben IAM-basiert, Logs und Metriken fließen zentral in AWS-Dienste. Dieses Modell unterscheidet sich strukturell von Anthos und Azure Arc, da es keine separate Multi-Cloud-Verwaltungsebene etabliert, sondern die AWS-Kontrollinstanz auf externe Rechenressourcen ausdehnt.

Governance und Richtlinienmodell

Anthos setzt auf Kubernetes-nahe Richtlinien. Admission-Kontrollen blockieren fehlerhafte Konfigurationen bereits bei der Erstellung. Richtlinien wirken unmittelbar auf Workloads und Namespaces. Governance ist applikationsnah und technisch eng mit dem Cluster verbunden.

Azure Arc nutzt Azure-Policy. Regeln prüfen Ressourcen auf Azure-Ebene. Compliance-Status, Tagging-Vorgaben und Konfigurationszustände erscheinen zentral im Azure-Portal. Arc eignet sich daher für Organisationen, die Governance als Ressourcenkontrolle über heterogene Systeme definieren.

AWS nutzt Guardrails in Control Tower als präventive und erkennende Mechanismen. AWS Config erkennt Konfigurationsabweichungen. Systems Manager führt automatisierte Runbooks aus. Governance entsteht durch Zusammenspiel dieser Dienste. Der Fokus liegt stärker auf Konto- und Ressourcengrenzen als auf applikationsnahen Admission-Kontrollen.

Identitätsmodell und Zugriff

Anthos nutzt Kubernetes-RBAC und externe Identitäts-Provider. Workload-Identitäten innerhalb des Clusters stehen im Mittelpunkt. Die Identitätslogik bleibt Cluster-zentriert. Azure Arc integriert Ressourcen in Azure-RBAC. Entra ID steuert Zugriff auf Server, Cluster und Datenservices. Die Identität folgt dem Azure-Modell, unabhängig vom Standort.

AWS stützt sich auf IAM als globales Identitätsfundament. Rollen, Policies und Service Control Policies definieren Grenzen. Für hybride Szenarien erweitert IAM Roles Anywhere die Identitätsverwendung auf externe Workloads. Die Identität bleibt AWS-orientiert.

Netzwerk und Servicekommunikation

Anthos integriert Service-Mesh als Plattformbestandteil. Traffic-Regeln, mTLS und Observability greifen auf L7-Ebene. Die Kommunikation zwischen Services lässt sich Cluster-übergreifend steuern. Azure Arc überlässt Service Mesh der Cluster-Implementierung. Azure Networking, ExpressRoute und Virtual Networks steuern Infrastrukturpfade. Arc ergänzt keine eigene L7-Kommunikationsschicht.

AWS kombiniert VPC-Architektur mit App-Mesh und Sicherheitsgruppen. Outposts und Direct Connect verbinden lokale Infrastruktur mit AWS-Regionen. Die Netzwerktopologie bleibt stark an das VPC-Modell gebunden.

Storage-Integration

Anthos verwendet StorageClasses zur Definition von Leistungsprofilen und Zugriffstypen. Persistente Volumes (PV) bleiben Backend-abhängig, doch die deklarative Nutzung bleibt identisch. Ein Profil für allgemeine Plattformdienste nutzt geteiltes Block-Storage mit Erweiterungsoption. Ein Profil für ReadWriteMany nutzt File Storage mit stabiler Semantik. Ein Profil für temporäre Zustände verzichtet auf Storage-Replikation und setzt auf applikationsseitige Wiederherstellung.

Azure Arc greift nicht direkt in Persistenzmechanismen ein. Storage bleibt Aufgabe des jeweiligen Clusters oder Servers. Arc steuert Governance, nicht IOPS oder Replikationslogik. AWS bietet EBS, EFS, FSx und S3 in der Cloud. Outposts kann lokale Varianten bereitstellen. EKS Anywhere nutzt CSI-Treiber auf vorhandener Infrastruktur. Die Storage-Architektur bleibt modulabhängig.

Ergänzende Dienste im Umfeld der Plattformen

Zu Anthos gehören Cloud Run für containerisierte Funktionen, Apigee für API-Management sowie Datenplattformdienste wie Cloud SQL oder BigQuery. Google Distributed Cloud erweitert das Modell in regulierte oder Edge-Szenarien.

Azure ergänzt Arc durch AKS als Kubernetes-Plattform, Azure Local für lokale Infrastruktur und Arc-fähige Datenservices für SQL oder PostgreSQL. Azure Monitor und Defender erweitern Governance und Security-Kontrolle.

AWS ergänzt EKS und Outposts durch Local Zones, Wavelength, Security Lake, CloudWatch, SageMaker und Bedrock. Systems Manager und Control Tower bilden dabei das Governance-Rückgrat.

Zusammenführung der Ansätze

Die Auswahl zwischen Anthos, Azure Arc und dem AWS-Portfolio richtet sich nicht nach der Anzahl der angebotenen Funktionen, sondern nach dem grundlegenden Steuerungsmodell der Architektur. Entscheidend ist, welche Ebene im Unternehmen die führende Instanz für Konfiguration, Richtlinien und Betriebsprozesse bildet.

Wenn Kubernetes selbst die zentrale Steuerungsschicht darstellt und alle Workloads konsequent containerisiert betrieben werden, dann bietet Google Anthos einen integrierten Rahmen. Cluster-Betrieb, Konfigurationsverteilung, Richtlinienkontrolle und Servicekommunikation folgen einer gemeinsamen Logik. Das Modell setzt voraus, dass die Organisation Kubernetes als strategische Plattform definiert und bereit ist, Persistenz, Netzwerk und Identität in dieses Paradigma einzuordnen.

Wenn hingegen heterogene Ressourcen aus virtuellen Maschinen, Datenbankdiensten und Kubernetes-Clustern unter ein einheitliches Cloud-Governance-Modell gestellt werden sollen, dann eignet sich Azure Arc. Die technische Führung liegt hier im Azure Resource Manager. Ressourcen außerhalb der Azure Cloud erhalten eine Azure-Identität und unterliegen Azure Policy, RBAC und Monitoring. Das Cluster selbst bleibt technisch eigenständig, doch Verwaltung und Compliance orientieren sich am Azure-Modell.

Im AWS-Umfeld verteilt sich die Steuerung auf mehrere spezialisierte Dienste. EKS und EKS Anywhere regeln den Kubernetes-Betrieb, Control Tower strukturiert Multi-Account-Umgebungen, Systems Manager steuert Automatisierung und Knotenverwaltung, AWS Config überwacht Ressourcenzustände. Die Architektur ergibt sich aus der bewussten Kombination dieser Bausteine. Unternehmen benötigen daher ein internes Plattformkonzept, das festlegt, welcher Dienst welche Steuerungsfunktion übernimmt.

Die Wahl einer Plattform folgt damit keiner Funktionsliste, sondern einer strukturellen Entscheidung. Steht Kubernetes als technisches Fundament im Zentrum, führt der Weg eher zu Anthos. Steht Governance über alle Ressourcentypen im Vordergrund, liegt Azure Arc nahe. Wird ein modularer Ansatz bevorzugt, bei dem Infrastruktur, Kubernetes und Governance getrennt aufgebaut werden, passt das AWS-Modell.