Azure Availability Zones: Resilienz ohne falsche Sicherheit planen

Ein Unternehmen verschiebt eine Anwendung nach Azure, wählt eine Region und erwartet, dass die Cloud jeden Ausfall automatisch löst. Diese Abkürzung ist gefährlich. Azure stellt eine resiliente Plattform und in vielen Regionen Availability Zones bereit. Die Resilienz einer konkreten Anwendung hängt jedoch von gewählten Diensten, Betriebsart, Instanzzahl, Datenreplikation, Routing, Tests und Wiederherstellung ab.

Eine Availability Zone ist eine logische Gruppe eines oder mehrerer physisch getrennter Rechenzentren innerhalb einer Azure-Region. Jede Zone besitzt unabhängige Stromversorgung, Kühlung und Netzwerkinfrastruktur. Sie soll die gemeinsame Auswirkung eines lokalen Fehlers begrenzen, schützt aber nicht automatisch vor dem Ausfall einer gesamten Region.

Region, Zone und Rechenzentrum sind nicht dasselbe

Eine Azure-Region ist ein geografischer Bereich, in dem Microsoft Infrastruktur betreibt. Eine Region kann Availability Zones unterstützen, muss es aber nicht. Eine Zone kann aus einem oder mehreren physischen Rechenzentren bestehen. Die Zonen sind physisch getrennt und über leistungsfähige Netze verbunden, um geringe Latenz und Resilienz gegen den Ausfall einer Zone zu ermöglichen.

Daraus folgt nicht, dass jede Ressource in der Region automatisch über mehrere Zonen läuft. Die Unterstützung unterscheidet sich je nach Dienst, Region, Tarif oder SKU und Konfiguration. Vor dem Entwurf ist der Reliability Guide jedes Dienstes zu prüfen, statt sich auf eine allgemeine Eigenschaft der Region zu verlassen.

Zonal und zone-redundant: unterschiedliche Verantwortung

Zonale Ressource

Eine zonale Ressource wird in einer vom Kunden gewählten Zone bereitgestellt. Sie ist von Fehlern in anderen Zonen isoliert, ist allein aber nicht gegen den Ausfall der eigenen Zone resilient. Verwendet ein Unternehmen virtuelle Maschinen im zonalen Modus, muss es mehrere Instanzen in verschiedenen Zonen, die Verkehrsverteilung und das Failover-Verfahren entwerfen.

Zonenredundante Ressource

Bei einem zone-redundant Dienst verwaltet der Dienst Verteilung und Replikation über mehrere Zonen. Bei einem Zonenausfall steuert Microsoft das Failover dieser Ressource. Trotzdem müssen erforderlicher Tarif, Kapazität, Datenkonsistenz und Abhängigkeiten geprüft werden. Eine Anwendung ist nur so resilient wie ihr schwächstes Glied.

Eine einzelne zonenredundante Komponente macht keine Anwendung resilient, wenn Datenbank, DNS, Geheimnisse oder die einzige virtuelle Maschine weiterhin ohne Zonenstrategie bleiben.

Praktisches Beispiel einer Geschäftsanwendung

Betrachten wir ein internes Bestellportal mit Web-Schicht, API und Datenbank. Web und API laufen auf mehreren Instanzen in unterstützten Zonen; ein zonenresilienter Load Balancer verteilt den Verkehr. Die Datenbank nutzt eine unterstützte zone-redundant Konfiguration. Protokolle und Metriken überwachen die Verfügbarkeit jeder Schicht.

Ein solcher Entwurf ist nur sinnvoll, wenn das Team auch das Verhalten beim Fehler prüft: Entfernt der Health Probe eine fehlerhafte Instanz, wechselt die Datenbank auf eine gesunde Replik, verkraftet die Anwendung eine kurze Verbindungsunterbrechung und bleibt genügend Kapazität? Der Test soll in einem sicheren Nichtproduktionsszenario oder als kontrollierte Übung mit klarer Rückkehr erfolgen.

Availability Zones schützen nicht gegen den Ausfall einer kompletten Region. Für eine geschäftskritische Anwendung empfiehlt Microsoft, eine Architektur mit mehreren Zonen und Regionen zu erwägen. Verhindern Anforderungen an Datenresidenz oder Souveränität eine zweite Region, muss das Unternehmen diese Grenze benennen und die Zonenresilienz innerhalb der Region mit Backup und Wiederherstellung anhand realistischer RTO- und RPO-Werte kombinieren.

Zonenunterstützung im Abonnement prüfen

Microsoft weist darauf hin, dass logische Zonennummern in unterschiedlichen Azure-Abonnements auf unterschiedliche physische Zonen abgebildet sein können. Überspannt eine Architektur mehrere Abonnements, darf nicht angenommen werden, dass „Zone 1“ in beiden dieselbe physische Zone bezeichnet.

Aktuelle Standortzuordnungen für ein konkretes Abonnement liefert der dokumentierte Azure-CLI-Befehl:

az account list-locations --query "[?availabilityZoneMappings].{availabilityZoneMappings: availabilityZoneMappings, displayName: displayName, name: name}"

Der Befehl liest lediglich Standortmetadaten. Er beweist weder, dass ein bestimmter Dienst und eine SKU den gewünschten Modus unterstützen, noch dass die Anwendung korrekt umschaltet. Danach sind Reliability Guides aller Dienste und die tatsächliche Bereitstellung zu prüfen.

Zonen sind weder Backup noch Wiederherstellungsplan

Replikation zwischen Zonen erhöht die Verfügbarkeit, kann aber auch einen logischen Fehler, unerwünschtes Löschen oder beschädigte Daten schnell übertragen. Ein Backup erfüllt einen anderen Zweck: einen wiederherstellbaren Stand gemäß Aufbewahrungsrichtlinie zu erhalten und eine Rückkehr nach einem Vorfall zu ermöglichen. Wenn die Bedeutung des Dienstes es verlangt, braucht ein Unternehmen beides.

Ebenso wichtig sind Betriebsziele. RTO bestimmt, wie schnell ein Dienst wiederhergestellt sein muss; RPO bestimmt den noch akzeptablen zeitlichen Datenverlust. Diese Werte sind keine Eigenschaft des Produktnamens. Sie müssen aus der geschäftlichen Auswirkung abgeleitet und durch Tests bestätigt werden.

Checkliste vor der Entscheidung

• Unterstützt die gewählte Region Zonen, und unterstützt sie jeder kritische Dienst und jede SKU?
• Welche Ressourcen sind zonal, zone-redundant oder nur regional?
• Sind Compute-Instanzen, Daten, Lastverteilung, Geheimnisse und Monitoring als eine Kette entworfen?
• Was geschieht nach Verlust einer Zone mit Kapazität und Leistung?
• Läuft das Failover automatisch oder muss es die Anwendung beziehungsweise ein Administrator steuern?
• Wie wird der Ausfall der ganzen Region behandelt und welche Grenze folgt aus der Datenresidenz?
• Gibt es separates Backup, Aufbewahrung, RTO, RPO und einen getesteten Restore?
• Wurde der Fehlertest ohne Auswirkung auf Produktionsdaten dokumentiert?

Beim Entwurf einer Azure-Infrastruktur für Unternehmen kann Yenwa Anwendungsabhängigkeiten erfassen, Zonenunterstützung prüfen, Restkapazität nach einem Fehler planen und Failover sowie Wiederherstellung testen. Das Ergebnis soll kein allgemeines Versprechen „läuft in der Cloud“ sein, sondern eine Architektur mit klaren Grenzen und einem Nachweis für das vereinbarte Ziel.