Azure Arc vs. Azure Local: Die Terminologie der hybriden Infrastruktur von Microsoft im Überblick

Von Mirko Peters · 2026-08-22

Willkommen zurück zum Podcast! Wenn Sie unsere letzten Folgen zur modernen Enterprise-IT-Architektur verfolgt haben, wissen Sie, dass wir oft über hybride Cloud-Strategien sprechen…

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Willkommen zurück zum Podcast! Wenn Sie unsere letzten Folgen zur modernen Enterprise-IT-Architektur verfolgt haben, wissen Sie, dass wir oft über hybride Cloud-Strategien sprechen. Vor Kurzem erhielt ich eine großartige E-Mail von einem Hörer namens Marcus aus Chicago. Marcus schrieb: "Ich versuche, die nächste Generation der Infrastruktur unseres Unternehmens zu planen, aber jedes Mal, wenn ich ein Whitepaper von Microsoft lese, verliere ich mich in den Schlagwörtern. Was ist der tatsächliche Unterschied zwischen Azure Arc und Azure Local? Sind das konkurrierende Produkte? Brauche ich beide?"

Marcus, Sie sind damit definitiv nicht allein. Microsoft bietet heute eines der umfassendsten hybriden Ökosysteme am Markt, doch mit dieser Breite geht eine erstaunliche Menge an Terminologie einher. Begriffe werden umbenannt, Akronyme verschieben sich, und plötzlich grübeln IT-Administratoren und Cloud-Architekten darüber, welches Tool wofür gedacht ist. Genau deshalb möchte ich diesen Blogbeitrag den beiden zentralen Säulen der hybriden Strategie von Microsoft widmen. Am Ende dieses Beitrags wissen Sie genau, was Azure Arc ist, was Azure Local ist, worin sie sich unterscheiden und – das ist am wichtigsten – wie sie zusammenarbeiten können, um Ihre Infrastruktur entscheidend voranzubringen.

Die Entwicklung der hybriden Infrastruktur bei Microsoft

Um zu verstehen, wo Azure Arc und Azure Local heute einzuordnen sind, müssen wir kurz zurückblicken. Jahrzehntelang war Enterprise-IT binär: Ihre Workloads liefen entweder auf eigenen physischen Servern im lokalen Rechenzentrum oder im Rechenzentrum eines Dienstleisters. Dann kam die Public-Cloud-Revolution, angeführt von Microsoft Azure, Amazon Web Services und Google Cloud Platform. Plötzlich beeilten sich Organisationen, alles in die Cloud zu verlagern, mit dem Versprechen unbegrenzter Skalierbarkeit und geringerer Investitionsausgaben.

Die Realität holte sie jedoch schnell ein. Unternehmen erkannten, dass nicht alles in die Public Cloud gehört. Regulatorische Anforderungen, Datensouveränitätsgesetze, extrem niedrige Latenzanforderungen am Netzwerk-Edge und Altanwendungen, die sich nicht ohne Weiteres umstrukturieren lassen, sorgten dafür, dass die lokale Infrastruktur nicht verschwand. Gleichzeitig wollten Organisationen aber nicht auf die hervorragenden Verwaltungsfunktionen, Sicherheitswerkzeuge und Entwicklerproduktivität verzichten, die sie in Azure schätzen gelernt hatten.

Diese Erkenntnis leitete das Zeitalter der hybriden Cloud ein. Microsoft erkannte früh, dass die Zukunft nicht rein in der Public Cloud liegt, sondern in einem durchgängigen Kontinuum vom Edge über das Rechenzentrum bis in die Cloud. Im Laufe der Jahre entwickelte Microsoft verschiedene Werkzeuge, um diese Lücke zu schließen. Manche sollten bestehende Hardware verwalten, andere diese Hardware vollständig modernisieren. Damit kommen wir zu den beiden Themen dieses Beitrags: Azure Arc, das für Verwaltung und Steuerung zuständig ist, und Azure Local, das die eigentliche hyperkonvergente Infrastruktur als Fundament bereitstellt.

Die Terminologie entschlüsselt: Was ist Azure Arc?

Beginnen wir mit Azure Arc. Wenn Sie aus diesem Abschnitt nur einen Satz mitnehmen, dann diesen: Azure Arc ist eine Steuerungsebene, kein Infrastrukturprodukt.

Stellen Sie sich Azure Arc wie einen Zauberstab vor, der die Steuerungsebene von Azure erweitert, also genau die Verwaltungsoberfläche, mit der Sie virtuelle Maschinen, Datenbanken und Kubernetes-Cluster in der Azure Public Cloud verwalten. Diese Ebene reicht bis in Ihre eigenen Rechenzentren und Edge-Standorte und sogar bis zu Wettbewerbern wie AWS und Google Cloud Platform.

So funktioniert Azure Arc im Detail

Im Kern arbeitet Azure Arc, indem es auf Ihren bestehenden Ressourcen, egal wo diese stehen, leichtgewichtige Agenten installiert. Ob Sie einen physischen Linux-Server im Rack in Frankfurt betreiben, eine VMware-Virtual-Machine in Ihrem lokalen Büro in Chicago oder eine Amazon-EC2-Instanz: Azure Arc verbindet diese Ressource mit Azure. Danach wird die externe Ressource in Azure Resource Manager (ARM) abgebildet. Ihre Nicht-Azure-Server erscheinen damit plötzlich direkt neben Ihren nativen Azure-VMs im Azure-Portal.

Durch diese Abbildung stehen auch für Infrastruktur, die nie die Azure Cloud berührt, umfangreiche cloudnative Funktionen zur Verfügung:

• Einheitliche Governance und Compliance: Sie können Azure Policy auf Ihre lokalen Server anwenden, damit Konfigurationen im gesamten Bestand konform bleiben.
• Erweiterte Sicherheit: Microsoft Defender for Cloud lässt sich erweitern, um Bedrohungen und Schwachstellen auf Ihren Nicht-Azure-Servern und Kubernetes-Clustern zu überwachen.
• Cloud-native Überwachung: Azure Monitor kann Protokolle und Metriken aus Ihrer lokalen Infrastruktur erfassen und bietet Ihnen so eine zentrale Ansicht für die Beobachtbarkeit.
• Arc-fähige Dienste: Sie können sogar Azure SQL Managed Instance und Azure PostgreSQL auf Ihrer eigenen lokalen Infrastruktur betreiben, vollständig verwaltet über die Azure-Steuerungsebene.

Entscheidend ist: Azure Arc spielt keine Rolle, welcher Hypervisor darunter läuft. Es ersetzt weder Ihr VMware-, Hyper-V- noch Ihr physisches Bare-Metal-Setup. Es legt lediglich eine intelligente Verwaltungsebene um das, was Sie bereits haben.

Die Terminologie entschlüsseln: Was ist Azure Local?

Nachdem wir Azure Arc als Verwaltungsebene verstanden haben, wechseln wir auf die Infrastrukturseite: Azure Local. Wenn Azure Arc die softwaredefinierte Steuerungsebene ist, die überall hinreicht, dann ist Azure Local eine Hyper-Converged-Infrastructure-(HCI)-Lösung, die Workloads lokal im Rechenzentrum oder am Edge ausführt.

Sie kennen diese Technologie vielleicht unter ihrem früheren Namen: Azure Stack HCI. Microsoft hat dieses Angebot kürzlich unter dem Namen Azure Local neu benannt und gestrafft, um es besser auf seine Kernmission auszurichten. Azure Local bietet eine moderne, softwaredefinierte Plattform für Rechenleistung, Speicher und Netzwerk, die Sie auf validierten Hardware-Appliances direkt in Ihren eigenen Räumlichkeiten betreiben.

Die Architektur von Azure Local

Azure Local kombiniert Windows-Server-Technologien mit fortschrittlicher hyperkonvergenter Software, um Virtualisierung und Speicherfunktionen auf Unternehmensniveau bereitzustellen. Dafür nutzt es Hyper-V für die Virtualisierung und Storage Spaces Direct für softwaredefinierten Speicher mit hoher Leistung.

Was Azure Local wirklich einzigartig macht, ist die tiefe, native Integration in die Azure Public Cloud von Grund auf. Während klassische Virtualisierungsplattformen Drittanbieter-Tools benötigen, um sich mit der Cloud zu verbinden, ist Azure Local von vornherein cloudverbunden. Sie können damit vertraute Windows- und Linux-virtuelle-Maschinen sowie Azure Kubernetes Service (AKS)-Cluster lokal auf Hardware betreiben, die Sie physisch besitzen und verwalten.

Zu den wichtigsten Funktionen von Azure Local gehören:

• Hohe Verfügbarkeit und Ausfallsicherheit: Integriertes Clustering und Speicherreplikation sorgen dafür, dass Ihre lokalen Workloads auch bei Hardwareausfällen weiterlaufen.
• Flexible Formfaktoren: Von robusten Edge-Knoten in Filialen oder Fabriken bis hin zu großen Multi-Node-Clustern in Unternehmensrechenzentren: Azure Local skaliert passend zu dem physischen Platz, den Sie haben.
• Vertraute Virtualisierung: Wenn Ihr Team bereits Hyper-V oder allgemeine Virtualisierungskonzepte kennt, ist die Einarbeitung in Azure Local sehr unkompliziert.

Die wichtigsten Unterschiede zwischen Verwaltung und Infrastruktur

Wenn mich Zuhörer bitten, Azure Arc und Azure Local zu vergleichen, besteht mein erstes Ziel immer darin, die Prämisse der Frage zu korrigieren. Azure Arc mit Azure Local zu vergleichen ist ein bisschen so, als würde man eine Fernbedienung mit einem Fernseher vergleichen. Es handelt sich nicht um konkurrierende Technologien; sie arbeiten auf völlig unterschiedlichen Ebenen des IT-Stacks.

Lassen Sie uns die grundlegenden Unterschiede anhand einiger zentraler Dimensionen aufschlüsseln:

1. Ebene im Stack

Azure Arc befindet sich vollständig auf der Verwaltungs- und Steuerungsebene. Es ist ein Cloud-Dienst, mit dem Sie Ressourcen organisieren, verwalten und absichern. Azure Local befindet sich auf der Infrastruktur- und Rechenebene. Es ist ein Betriebssystem und eine hyperkonvergente Plattform, die die physischen und virtuellen Rechen- und Speicherressourcen bereitstellt, auf denen Ihre Anwendungen tatsächlich ausgeführt werden.

2. Hardware-Abhängigkeit

Da Azure Arc lediglich ein agentenbasiertes Verwaltungstool ist, hat es praktisch keine Hardwareabhängigkeiten. Sie können den Arc-Agent auf einem fünf Jahre alten Dell-Server mit einer älteren Linux-Version installieren, auf einem brandneuen HPE-Server mit Windows oder sogar auf einer virtuellen Maschine in AWS. Azure Local hingegen erfordert spezifische, validierte Hardware von Microsofts Hardwarepartnern. Sie können Azure Local nicht einfach auf beliebiger Hardware installieren, die irgendwo in Ihrem Serverraum herumsteht. Es werden zertifizierte Clusterknoten benötigt, damit Leistung, Zuverlässigkeit und Supportfähigkeit sichergestellt sind.

3. Hauptzweck

Das Ziel von Azure Arc ist einheitliche Verwaltung – also Konsistenz in einem fragmentierten Multi-Cloud- und On-Premises-Portfolio. Das Ziel von Azure Local ist eine modernisierte lokale Infrastruktur – eine cloudnative HCI-Plattform, auf der virtualisierte und containerisierte Workloads direkt dort laufen, wo die Daten entstehen.

Wann Azure Arc und wann Azure Local einsetzen

Nachdem wir geklärt haben, was jedes Tool leistet, geht es nun um die Entscheidung. Woran erkennen Sie in Ihren Architekturplanungen, wann Sie zu Azure Arc greifen und wann Sie Azure Local bereitstellen sollten?

Wann Sie Azure Arc einsetzen sollten

Azure Arc sollten Sie einsetzen, wenn Sie Azure-Verwaltungsfunktionen für Infrastruktur nutzen möchten, die Sie bereits besitzen und vorerst nicht ersetzen wollen. Beispiele:

• Sie haben umfangreiche bestehende Investitionen in VMware- oder Bare-Metal-Linux-Server über mehrere globale Rechenzentren verteilt und möchten im Azure-Portal eine zentrale Übersicht, um Compliance zu verwalten, Protokolle zu überwachen und Richtlinien anzuwenden.
• Sie betreiben Kubernetes-Cluster in AWS oder Google Cloud und möchten Azure GitOps und Azure Policy nutzen, um Bereitstellungen über alle diese Clouds hinweg gleichzeitig zu verwalten.
• Sie möchten Azure-Datendienste wie Azure SQL Managed Instance lokal betreiben, ohne Ihren gesamten zugrunde liegenden Virtualisierungsstack zu migrieren.

Wann Sie Azure Local einsetzen sollten

Azure Local sollten Sie einsetzen, wenn Sie veraltete lokale Infrastruktur erneuern oder eine neue Edge-Computing-Umgebung aufbauen möchten und diese lokale Infrastruktur sich wie eine Erweiterung der Azure-Cloud anfühlen und verhalten soll:

• Ihre klassische SAN- und Virtualisierungsumgebung erreicht das Ende ihres Lebenszyklus, und Sie möchten sie durch eine moderne, softwaredefinierte hyperkonvergente Infrastruktur ersetzen, die sich nativ in Azure Backup, Disaster Recovery und Überwachung integriert.
• Sie benötigen Rechen- und Speicherleistung mit geringer Latenz an einem Edge-Standort – etwa in einem Krankenhaus, einer Filiale oder einem Produktionswerk –, an dem Daten lokal verarbeitet werden müssen, Sie diese Workloads aber zentral aus der Azure-Cloud verwalten möchten.
• Sie möchten Azure Kubernetes Service (AKS) lokal mit vollem Support und nahtloser Integration in Ihre bestehenden Cloud-Bereitstellungspipelines betreiben.

Wie beide im Hybridszenario zusammenwirken

Hier wird es richtig spannend. Azure Arc und Azure Local sind eigenständige Produkte, Microsoft hat sie aber so konzipiert, dass sie zusammen noch besser funktionieren. Tatsächlich sind Azure-Local-Cluster standardmäßig automatisch mit Azure Arc aktiviert!

Wenn Sie einen Azure-Local-Cluster in Ihrem Rechenzentrum bereitstellen, wird die zugrunde liegende Infrastruktur lokal verwaltet, ihre Steuerungsebene ist jedoch vollständig in Azure Arc integriert. Das bedeutet, dass Sie keine separaten Agenten installieren und keine komplexen Tunnel konfigurieren müssen, um Ihre Azure-Local-Infrastruktur zu verwalten. Sie erscheint vom Moment der Initialisierung an nativ in Ihrem Azure-Abonnement.

Schauen wir uns ein reales Hybridszenario an, um zu sehen, wie dieses Zusammenspiel in der Praxis funktioniert. Stellen Sie sich ein großes, global tätiges Logistikunternehmen vor:

1. Am Edge: Das Unternehmen betreibt weltweit Hunderte Fulfillment-Center. In jedem Center setzt es kleine Appliances mit zwei Knoten und Azure Local ein, um Versandetiketten zu verarbeiten, lokale Datenbankinstanzen auszuführen und Lagerautomatisierungssysteme mit extrem niedriger Latenz zu steuern.
2. Im gesamten Unternehmen: Außerdem betreibt es Altrechenzentren mit einer Mischung aus VMware- und physischen Servern sowie einige Workloads in AWS. In all diesen Umgebungen installiert es Azure-Arc-Agenten, um Sicherheitsbaselines durchzusetzen und die Compliance zu überwachen.
3. Einheitliche Verwaltung: Über das Azure-Portal kann das zentrale IT-Team den Zustand der Edge-Fulfillment-Center (auf Azure Local ausgeführt) direkt neben seinen AWS-Instanzen und Legacy-Servern (verwaltet über Azure Arc) einsehen. Mit Azure Policy stellt es sicher, dass Verschlüsselungsstandards überall eingehalten werden, und mit Azure Monitor verfolgt es die Leistungsmetriken weltweit.

In dieser Architektur stellt Azure Local die belastbare, leistungsstarke Basis am Edge bereit, während Azure Arc die übergreifende Governance und die Steuerungsebene liefert, die die gesamte hybride Umgebung zusammenhält.

Fazit: Ihre Hybrid-Cloud-Reise einfacher gestalten

Auf den ersten Blick kann das Hybrid-Cloud-Ökosystem von Microsoft überwältigend wirken. Sobald Sie die Begriffe jedoch bestimmten Architekturebenen zuordnen, fügt sich alles zusammen. Merken Sie sich die goldene Regel: Azure Arc ist Ihre zentrale Steuerungsebene für alles, überall, während Azure Local Ihre moderne hyperkonvergente Infrastruktur für lokale Workloads und Edge-Workloads ist.

Wenn Sie Ihre Unternehmensarchitektur für das kommende Jahr planen, betrachten Sie diese Technologien nicht als Entweder-oder-Entscheidung. Betrachten Sie stattdessen, wie sie sich gegenseitig ergänzen. Nutzen Sie Azure Arc, um Ihre bestehenden heterogenen IT-Investitionen zu vereinheitlichen und zu steuern, und setzen Sie Azure Local ein, wenn Sie Ihre lokale Infrastruktur und Edge-Infrastruktur mit cloudnativer Agilität modernisieren möchten.

Ich hoffe, dieser Deep Dive klärt die Verwirrung rund um Microsofts Hybrid-Terminologie. Wie immer freuen wir uns über Ihr Feedback. Nutzen Sie Azure Arc aktuell in Ihren Multi-Cloud-Umgebungen? Haben Sie Azure Local an Ihren Edge-Standorten bereitgestellt? Hinterlassen Sie unten einen Kommentar oder schreiben Sie uns eine E-Mail für unsere nächste Hörerpost-Folge. Bis zum nächsten Mal: Bleiben Sie zukunftsorientiert!