Azure bietet eine breite Palette an Hochverfügbarkeits- und Redundanzmechanismen. Das ist ein grosser Vorteil – und zugleich eine Quelle für Missverständnisse. Viele Architekturentscheidungen verbessern die Verfügbarkeit eines Dienstes, aber sie garantieren noch keinen belastbaren Wiederanlauf eines gesamten Geschäftsprozesses.
Business Continuity und Disaster Recovery werden in der Praxis oft vermischt. Hochverfügbarkeit reduziert ungeplante Unterbrechungen im laufenden Betrieb. Disaster Recovery adressiert dagegen den Fall, dass ein Workload, eine Plattformkomponente, eine Region oder ein übergeordneter Betriebszustand nicht mehr wie vorgesehen nutzbar ist. Dafür braucht es mehr als Redundanz-Häkchen.
Wo Azure-native Resilienz endet
Verfügbarkeitszonen, geo-redundanter Storage oder replizierte Datenbanken sind wichtige Bausteine. Sie beantworten aber nicht automatisch Fragen wie: In welcher Reihenfolge werden abhängige Systeme wieder gestartet? Wie werden Identität, DNS, Zertifikate und Secrets bereitgestellt? Welche manuellen Schritte bleiben notwendig? Welche Datenstände sind im Krisenfall akzeptabel?
Gerade in mittelständischen Architekturen ist der kritische Punkt selten ein einzelner Dienst, sondern das Zusammenspiel aus Azure-Ressourcen, Microsoft 365, lokalen Anwendungen, Netzwerken und Drittanbietern. Resilienz scheitert daher oft nicht an fehlenden Cloud-Features, sondern an ungeklärten Abhängigkeiten.
BCDR braucht Architektur plus Betrieb
- Priorisierung: Nicht jeder Workload braucht dieselbe Wiederanlaufzeit.
- Abhängigkeiten: Identität, Netzwerk, DNS, Zertifikate, Monitoring und Schnittstellen müssen mitgedacht werden.
- Automation: IaC und Runbooks reduzieren Fehler unter Druck.
- Tests: Failover-Pläne sind nur so gut wie ihre regelmässige Verifikation.
Ein häufiger Denkfehler
Unternehmen investieren oft in technische Redundanz, ohne Mindestbetriebsfähigkeit und Geschäftsprioritäten klar zu definieren. Das Resultat: Viel Aufwand auf Infrastruktur-Ebene, aber Unsicherheit darüber, welche Prozesse im Ernstfall zuerst wieder laufen müssen und ob die Reihenfolge technisch überhaupt umsetzbar ist.
Nemonicon-Perspektive
Ein gutes Azure-BCDR-Konzept beginnt nicht beim Feature-Vergleich, sondern bei den Geschäftsprozessen. Erst daraus lassen sich sinnvolle Entscheidungen zu Regionen, Replikation, Runbooks, Backup, Identity Design und Krisenabläufen ableiten. Hochverfügbarkeit ist wertvoll – aber Wiederanlauffähigkeit entsteht erst dann, wenn Technik, Betrieb und Priorisierung zusammenpassen.