Azure-Ausfall in West US: Wie ein Wartungsfehler AKS, Teams & Co. lahmlegte
Ein Fehler in Microsofts automatisierter Wartungssoftware hat die Azure-Region West US am 23. Juli fast fünf Stunden lang vom Rest des Netzes abgeschnitten. Betroffen waren AKS, App Service, Datenbanken und auch Microsoft 365. Was Sie daraus für Regionswahl, Redundanz und versteckte Abhängigkeiten lernen sollten.
Was ist passiert?
Am 23. Juli 2026 um 14:44 UTC (16:44 Uhr deutscher Zeit) begann eine geplante Wartung an Netzwerkgeräten in West US. Die Wartung sollte einzelne Geräte isolieren, ohne die Verfügbarkeit zu beeinträchtigen. Laut dem vorläufigen Post Incident Review von Microsoft markierte jedoch ein Fehler in dem System, das Wartungsanfragen in konkrete Arbeitsschritte übersetzt, zusätzliche Geräte als Teil der Wartung. Dadurch wurden auf deutlich mehr Geräten IP-Routen entfernt als vorgesehen, und zwar genau auf dem Weg zwischen Rechenzentrum und Weitverkehrsnetz (WAN).
Die Folge: Datenverkehr in die Region hinein und aus ihr heraus brach weitgehend ein. Workloads, die ausschließlich innerhalb von West US miteinander kommunizierten, liefen weiter. Das Problem zeigte sich zunächst als Routing-Instabilität im WAN, was die Ursachensuche erschwerte. Gegen 17:45 UTC begann Microsoft, die Wartungsänderungen zurückzurollen. Um 18:26 UTC war das Netzwerk wiederhergestellt, um 19:41 UTC meldete Microsoft alle Dienste als erholt.
Auf der Liste der betroffenen Dienste stehen unter anderem App Service, Azure Kubernetes Service (AKS), Cosmos DB, Azure Database for PostgreSQL, Azure Monitor, Application Gateway, VPN Gateway, Virtual WAN, Microsoft Sentinel und Microsoft Graph. Zusätzlich meldeten Nutzer in Nordamerika Probleme mit Microsoft-365-Diensten wie Outlook und Teams.
Die Fehlerkette im Überblick:
Warum betrifft Sie das?
Die meisten deutschen Azure-Kunden betreiben ihre Workloads in Germany West Central oder West Europe und waren nicht direkt betroffen. Trotzdem lohnt der Blick auf diesen Vorfall, denn er zeigt drei typische Schwachstellen.
Erstens die Regionswahl: In vielen Subscriptions finden sich Ressourcen in US-Regionen, die einmal zum Testen, aus Kostengründen oder wegen der Verfügbarkeit bestimmter Dienste dort angelegt wurden und inzwischen produktiv genutzt werden.
Zweitens die Grenzen von Availability Zones: Zonen schützen vor dem Ausfall einzelner Rechenzentren innerhalb einer Region. Wenn aber, wie hier, die Anbindung der Region nach außen gestört ist, hilft eine Verteilung über mehrere Zonen derselben Region nur begrenzt. Microsoft selbst empfiehlt für geschäftskritische Anwendungen eine Bereitstellung über mehrere Regionen.
Drittens versteckte Abhängigkeiten: Ihre eigene Infrastruktur mag in Europa laufen, doch Dienste wie Microsoft 365, Microsoft Graph oder die Tools Ihrer SaaS-Anbieter können von Rechenzentren in anderen Regionen abhängen. Teams mit Standorten oder Kunden in Nordamerika spüren solche Störungen unmittelbar.
Was Sie jetzt tun sollten
- Ressourcen nach Region inventarisieren: Prüfen Sie, wo Ihre Ressourcen tatsächlich laufen:
az resource list --query "[].location" -o tsv | sort | uniq -c
az resource list --query "[?location=='westus'].{Name:name, Typ:type, RG:resourceGroup}" -o table
- Kritische Workloads bewerten: Legen Sie für jede wichtige Anwendung fest, welche Ausfallzeit tragbar ist, und leiten Sie daraus ab, ob Zonenredundanz genügt oder eine zweite Region nötig ist.
- Abhängigkeiten dokumentieren: Erfassen Sie, welche externen Dienste, APIs und SaaS-Werkzeuge Ihre Anwendungen und Prozesse brauchen und wo diese betrieben werden. Dazu gehören auch CI/CD-Pipelines und Monitoring.
- Service Health Alerts einrichten: Konfigurieren Sie in Azure Service Health Benachrichtigungen für die Regionen und Dienste, die Sie nutzen, damit Ihr Team nicht erst über Kundenbeschwerden von einer Störung erfährt.
- Notfallpläne testen: Ein Failover in eine zweite Region, das nie geprobt wurde, funktioniert im Ernstfall selten reibungslos. Planen Sie regelmäßige Tests ein.
- Eigene Änderungsprozesse prüfen: Auch automatisierte Wartung bei Ihnen selbst, etwa per Terraform oder Pipeline, braucht Schutzmechanismen gegen einen zu großen Wirkungsradius.
Fazit
Der Ausfall in West US war kein Angriff, sondern ein Fehler in der Automatisierung, wie er in jeder komplexen Infrastruktur passieren kann. Entscheidend ist, ob Ihre Architektur einen solchen Regionsausfall verkraftet und ob Sie Ihre Abhängigkeiten kennen. Wenn Sie Ihre Azure-Umgebung auf Ausfallsicherheit prüfen lassen möchten, sprechen Sie uns an.