Die Cloud war lange Zeit ein Ort in einem fernen Hyperscaler-Rechenzentrum. Daten flossen über das WAN hoch, Ergebnisse wieder zurück. Wer niedrige Latenzen benötigte oder Daten aufgrund von Compliancevorgaben lokal vorhalten musste, konnte die Vorteile einer zentralisierten Cloudverwaltung oft nicht nutzen und betrieb klassische In- frastrukturen weiter.

Diese Trennung löst sich derzeit auf. Das liegt weniger an neuen Marketingslogans, sondern an zwei markanten Entwicklungen im Markt: Die Übernahme von VMware durch Broadcom zwingt IT-Verantwortliche, ihre Virtualisierungsstrategie grundlegend zu überdenken. Gleichzeitig ist Datensouveränität zum geopolitischen Architekturzwang gereift. Der US CLOUD Act und nationale Initiativen erzeugen einen Druck, den Organisationen immer häufiger durch die Infrastrukturarchitektur statt durch reine Policydokumente lösen müssen.

Microsoft reagiert darauf mit einem Ansatz, den das Unternehmen als "Adaptive Cloud" bezeichnet. Azure soll nicht mehr exklusiv in den Rechenzentren des Herstellers laufen, sondern im eigenen Serverraum, auf der Werksebene oder am Filialstandort – zukünftig sogar vollständig offline. Die Werkzeuge hierfür sind zwei eng verzahnte Produkte: Azure Arc fungiert als universelle Steuerebene, während Azure Local on-premises als Infrastrukturplattform dient. Wir erläutern im Folgenden, wie beide Komponenten zusammenspielen und wo die technischen Grenzen liegen.

Die Architektur der Adaptive Cloud bringt eine Steuerebene (Azure Resource Manager; ARM, Azure Policy, Defender for Cloud, Monitor und das zugehörige API), die von den Compute-Ressourcen entkoppelt ist. ARM verwaltet dadurch Ressourcen, die physisch außerhalb der Microsoft-Rechenzentren liegen, etwa lokale Server, Kubernetes-Cluster in der Produktion oder Datenbanken in Filialen.

Das Verbindungsglied ist Azure Arc. Dabei registriert ein Agent auf dem Zielsystem (Windows Server, Linux, Kubernetes oder Datenbank) die Ressource in ARM. Danach erscheint die Instanz im Azure-Portal wie eine native Ressource. Admins können Azure Policy zuweisen, Extensions installieren, Updates steuern und das RBAC-Modell anwenden. Während die physische Ressource vor Ort bleibt, liegt die Verwaltungsebene in Azure.

Dieses Verfahren ist in der Praxis oft effizienter als alternatives Tooling, setzt jedoch eine dauerhafte Verbindung zu Azure voraus. Für Systeme mit stabiler WAN-Anbindung ist dies unproblematisch. In Werkshallen mit intermittierender Konnektivität, auf Offshore-Plattformen oder in klassifizierten Umgebungen stößt dieses Modell jedoch an Grenzen. An dieser Stelle setzt Azure Local an.

Vielen Administratoren ist Azure Stack HCI als hyperkonvergente Umgebung bekannt, die Hyper-V mit Storage Spaces Direct (S2D) auf validierten Hardware-Clustern kombiniert. Im November 2024 benannte Microsoft das Produkt in Azure Local um. Dabei handelt es sich um mehr als ein Rebranding: Microsoft vereinheitlicht damit den Namensraum für sämtliche verteilte Infrastrukturprodukte. Azure Stack Edge, Azure Stack Hub und Azure Stack HCI gehen unter dem Dach von Azure Local auf. Operativ ändert sich für Bestandskunden wenig: PowerShell-Cmdlets, das API, die Cluster-Konfigurationen und der Betriebssystem-Unterbau bleiben identisch. Neu sind vor allem die einheitliche Verwaltung und ein erweitertes Serviceangebot. Azure Local fungiert heute als Grundlage für Microsofts "Sovereign Private Cloud".

Technisch basiert das System auf Win- dows-Server-Technologie mit einem gehärteten Image. Hyper-V übernimmt die Virtualisierung, während S2D die direkt am Server angeschlossenen NVMe- oder SSD-Laufwerke zu einem hochverfügbaren Speicher ohne externes SAN zusammenfasst. Die Knoten kommunizieren über RDMA-fähige Netzwerkadapter. Eine Arc Resource Bridge läuft als virtuelle Appliance auf dem Cluster und projiziert die Ressourcen automatisch in den Azure Resource Manager.

Hardwareseitig unterstützt Azure Local Cluster von einem bis zu 16 Knoten. Mit dem Release zur Ignite 2025 wurde zudem ein Multi-Rack-Deployment angekündigt, das Umgebungen mit hunderten Servern ermöglichen soll. Parallel dazu existiert seit 2025 die "Low Capacity"-Hardwareklasse. Diese kompakten Geräte mit reduzierten Mindestanforderungen sind für Edge-Szenarien konzipiert, sodass die Software auch auf industriellen Kleingeräten ohne vollständige Serverausstattung lauffähig ist.

OEM-Partner wie Dell, HPE, Lenovo, Fujitsu oder Supermicro bieten validierte Hardware aus dem "Azure Local Catalog" [1] an. Der Katalog unterscheidet drei Kategorien:

- Validated Nodes (geprüfte Einzelserver zur Eigenmontage)

- Integrated Systems (abgestimmte Hardware-Software-Kombinationen mit gemeinsamem Support)

- Premier Solutions (vorinstallierte Systeme für den direkten Rollout)

Admins können vorhandene Hardware nutzen, sofern diese einem Katalogeintrag entspricht. TPM 2.0 und Secure Boot sind zwingende Voraussetzungen. Seit Version 12.2510 (Oktober 2025) ist zudem Software-defined Networking (SDN) via Azure Arc allgemein verfügbar. Network Security Groups (NSGs) lassen sich damit auch für virtuelle Netzwerke auf Azure Local nutzen. Inbound- und Outbound-Regeln werden über das Azure- Portal konfiguriert und greifen direkt am virtuellen Switchport, sodass das Betriebsmodell konsistent zu Azure bleibt.

Microsoft nutzt für Azure Local ein cloudtypisches Abrechnungsmodell: Die Infrastruktur kostet zehn US-Dollar pro physischem Prozessorkern und Monat, abgerechnet über das Azure-Abonnement. Da die Kosten ausschließlich auf der Anzahl physischer Kerne basieren – unabhängig von VMs, vCPUs oder Arbeitsspeicher –, vereinfacht dies die Planung und begünstigt eine hohe Virtualisierungsdichte. Admins, die viele VMs pro Host betreiben, zahlen denselben Preis wie bei geringerer Auslastung. Inhaber von Windows-Server-Datacenter-Lizenzen mit aktiver Software Assurance können den Azure Hybrid Benefit nutzen, wodurch die Hostgebühr entfällt. Ein erheblicher Kostenvorteil ergibt sich zudem bei AKS auf Azure Local, das seit Version 2402 (Januar 2025) ohne Aufpreis enthalten ist.

IT-Verantwortliche müssen jedoch beachten, dass die Gebühren pro physischem Kern anfallen, solange die Azure-Local-Ressource in Azure existiert. Dies gilt unabhängig davon, ob der Cluster aktiv ist. Bei einer Dekommissionierung müssen Sie die Ressource explizit löschen. Bleibt sie bestehen und ist der Cluster länger als 31 Tage nicht mit Azure verbunden ("disconnected"), pausiert die Abrechnung erst nach Ablauf dieser Frist.

Im Februar 2026 verkündete Microsoft die allgemeine Verfügbarkeit von "Disconnected Operations" für Azure Local. Die Funktion ist das Herzstück der neuen Sovereign Private Cloud. In diesem Modus benötigt eine Azure-Local-Instanz keine permanente Verbindung zur Public Cloud. Eine lokale Control Plane repliziert das Azure-Portal und das ARM-API direkt auf einer virtuellen Management-Appliance im Cluster. Admins nutzen die vertraute Azure-Oberfläche, ohne dass Traffic in das öffentliche Netzwerk fließt. Funktionen wie Policy-Enforcement, das Deployment von VMs und Kubernetes-Clustern sowie die Key-Vault-Integration laufen vollständig lokal ab. Das Angebot bündelt drei Produkte für den Offlinebetrieb:

- Azure Local für die Infrastruktur

- Microsoft 365 Local für Produktivität

- Foundry Local für KI-Inferenz auf NVIDIA-Hardware

Diese Strategie zielt auf Behörden, kritische Infrastrukturen und regulierte Branchen ab, die aufgrund gesetzlicher Vorgaben keine Daten in die Public Cloud übertragen dürfen.

Trotz der Fortschritte zeigen die Release- Notes vom März 2026 noch technisches Optimierungspotenzial [2]. Bekannt sind etwa Instabilitäten beim HIMDS-Dienst, Darstellungsfehler im Policyportal und Probleme bei der SSH-Key-Generierung für Linux-VMs. Microsoft empfiehlt derzeit, nicht mehr als 20 Workload-Cluster zu betreiben. Der Zugang zum Disconnected-Modus setzt ein "Microsoft Customer Agreement for Enterprises" sowie eine explizite Freischaltung voraus. Für klar definierte Szenarien wie lokale Behörden oder Industriestandorte ist die Technik jedoch bereits einsatzbereit.

Für ein stabiles Deployment sollten Sie folgende Punkte berücksichtigen:

- Nutzen Sie ausschließlich validierte Hardware aus dem Azure Local Catalog.

- RDMA-fähige Netzwerkadapter für den Storage-Traffic sind zwingend erforderlich. Planen Sie mindestens zwei dedizierte Adapter pro Knoten ein.

- Verwenden Sie den ODIN Sizer [3] vor der Hardwarebestellung. Planen Sie eine Kapazitätsreserve von n+1 für Updates und Knotenausfälle ein.

- Lizenzierung: Prüfen Sie den "Azure Hybrid Benefit". Windows Server Datacenter mit aktiver Software Assurance eliminiert die Hostgebühr vollständig.

- Arc-Onboarding: Setzen Sie in Umgebungen mit restriktivem Internetzugang das Arc Gateway ein. Dies verhindert, dass jeder Agent einzeln direkt nach außen kommunizieren muss.

- Disconnected-Modus: Klären Sie mit Microsoft, ob der Zugang freigeschaltet ist und ob die Cluster-Größe innerhalb der aktuellen GA-Grenzen liegt.

Azure Arc ermöglicht das standortübergreifende Management und unterteilt sich in mehrere Säulen: "Arc-enabled Servers" für Systeme außerhalb von Azure, "Arc-enabled Kubernetes" für CNCF-kompatible Cluster, "Arc-enabled Data Services" sowie "Arc-enabled VMware vSphere". Die "Arc Resource Bridge" fungiert dabei als Vermittler zum Azure Resource Manager. Seit September 2025 ist der indirekte Verbindungsmodus abgekündigt. Alle verbundenen Systeme müssen direkt mit Azure kommunizieren – entweder über öffentliche Endpunkte, das Arc Gateway oder Azure Private Link.

Auf der Ignite 2025 stellte Microsoft die letzten Erweiterungen vor: Arc unterstützt nun GCP-Ressourcen im Public Preview, was eine Multi-Cloud-Inventarisierung über AWS, GCP und Azure hinweg erlaubt. Die Workload Identity Federation für Arc-enabled Kubernetes ist nun verfügbar, sodass Pods über Entra ID auf Azure-Ressourcen zugreifen können, ohne statische Secrets zu nutzen.

Ein wichtiges Werkzeug für dezentrale Infrastrukturen ist der Site Manager. Er bildet physische Standorte als hierarchische Einheiten ab. Admins gruppieren Ressourcen nach Standorten, nutzen entsprechende Monitoringdashboards und rollen Konfigurationen gezielt für einzelne Werke oder Filialen aus. Damit bildet das Managementwerkzeug erstmals die organisatorische Realität verteilter Unternehmen ab.

Die industrielle OT/IT-Konvergenz ist eines der spannendsten Einsatzfelder für Azure Arc und Azure Local. Jahrzehntelang existierten Operational Technology (OT) – also Steuerungssysteme, SPSen und Sensoren – und Information Technology (IT) in getrennten Welten. Das Purdue-Modell hielt beide Bereiche aus Gründen der Sicherheit und Betriebsstabilität strikt isoliert. Industrie 4.0 verlangt jedoch nach einem digitalen Feedback-Loop, der Maschinendaten in Echtzeit analysiert und Produktionsprozesse auf Basis von KI-Modellen anpasst. Azure IoT Operations ist Microsofts Antwort auf diesen Bedarf. Es handelt sich um eine Kubernetes-native Anwendung, die auf Arc-enabled-Kubernetes-Clustern am Edge bereitgestellt wird und eine OT/IT-Integrationsschicht bietet. Die Infrastrukt umfasst:

- Edge-native MQTT-Broker als Message Backbone

- Connector für OPC UA (IEC 62541)

- Dataflows für Datentransformation und -routing

- Webbasierte Betriebssteuerung für OT-Teams

Geräte publizieren Daten in MQTT-Topics, während Dataflows die Nachrichten kontextualisieren und an Azure Event Hub, Microsoft Fabric oder andere Endpunkte weiterleiten. Die Verarbeitung erfolgt am Edge, ohne Umweg über die Cloud. Seit Ende 2025 sind zudem Echtzeit-Datenanalysen per Data Graphs direkt am Edge möglich. Die Protokollunterstützung wurde auf ONVIF, REST/HTTP und SSE erweitert. Für Fertigungsumgebungen ist das Write-back-Feature relevant: Der OPC UA Connector schreibt Werte direkt in OPC UA-Knoten zurück und übernimmt Steuerungsaufgaben ohne Cloud-Roundtrip.

Mit dem Ignite-2025-Release bringt die "Small Form Factor Edition" AKS auf kompakte Industrie-PCs mit optionaler GPU-Unterstützung. Dazu unterstützt AKS auf Azure Local jetzt den vollständigen Offlinebetrieb: Cluster laufen ohne dauerhafte Azure-Verbindung und synchronisieren sich bei Gelegenheit.

Auch KI am Edge nimmt konkrete Formen an. Microsoft hat angekündigt, dass es ausgewählte "Azure AI Foundry"-Modelle, darunter Phi und Mistral, für den Betrieb auf Azure Local validiert. Foundry Local ermöglicht KI-Inferenz in vollständig Disconnected-fähigen Umgebungen. Der "Kubernetes AI Toolchain Operator" (KAITO) übernimmt die Orchestrierung der Modelle auf AKS-Clustern: Wenn Admins ein Inferenz-Deployment für ein Phi-4-Modell auf einem Edge-Cluster ausrollen möchten, definieren sie eine KAITO-Workspace-Custom-Resource. KAITO automatisiert den Modell-Download, die GPU-Zuteilung und den Serving-Endpunkt.

Edge RAG (Retrieval Augmented Generation am Edge) ist seit Ende 2025 im Public Preview verfügbar. Organisationen können damit Embedding-Modelle, Vektorspeicher und LLM-Serving-Endpunkte vollständig on-premises betreiben, sodass Unternehmensdaten Azure nicht verlassen.

Azure Local und Azure Arc stehen nicht im Widerspruch zur Public Cloud. Sie sind die Antwort auf architektonische Rahmenbedingungen wie regulatorische Anforderungen, Latenzvorgaben oder begrenzte Konnektivität. Die Stärke dieses Ansatzes liegt in der einheitlichen Steuerebene: Wer Azure beherrscht, kann auch Azure Local verwalten, da dieselben Policys, das identische API und dieselbe RBAC-Struktur zum Einsatz kommen.

Dennoch gibt es aktuell noch Grenzen: Die Einstufung von Disconnected Operations als allgemein verfügbar (GA) ist angesichts der Einschränkungen beim Cluster-Umfang und der bekannten Probleme in der Version vom Februar 2026 ambitioniert. Bei der Planung großer souveräner Infrastrukturen ist eine enge Abstimmung mit Microsoft ratsam.

Der Einstieg ist durch einen 60-tägigen Testzeitraum ohne Hostgebühr niederschwellig möglich. Mit dem ODIN Sizer, validierter Hardware und einem Arc-verbundenen Cluster lässt sich die Umgebung schrittweise von einem Edge- Knoten bis hin zu einem umfassenden Private-Cloud-Deployment skalieren.

(jp)