Die Active-Passive-Architektur ist ein gängiges Modell für die Sicherstellung der Regionalresilienz in modernen Cloud-Umgebungen. In diesem Modell gibt es eine aktive Region, die den gesamten Datenverkehr und die Anfragen bearbeitet, während eine sekundäre, passive Region bereitsteht, um im Falle eines Ausfalls der aktiven Region deren Rolle zu übernehmen. Der Hauptvorteil einer Active-Passive-Architektur liegt in ihrer Einfachheit und Kostenwirksamkeit. Da nur eine Region aktiv den Verkehr bearbeitet, sind die Betriebskosten und die Ressourcennutzung in der passiven Region minimal, was diese Architektur zu einer attraktiven Lösung für Organisationen mit begrenztem Budget oder für diejenigen macht, die nur ein Basisniveau der regionalen Resilienz benötigen.

Active-Passive-Architekturen werden häufig im Rahmen von Disaster-Recovery-Strategien eingesetzt, wobei die passive Region als Notfallumgebung dient. Sollte die primäre Region aufgrund eines regionalen Ausfalls oder einer Katastrophe ausfallen, kann der Verkehr zur passiven Region umgeleitet werden, wodurch Ausfallzeiten minimiert und die Geschäftskontinuität gewährleistet werden. Dieser Prozess wird typischerweise durch Failover-Mechanismen orchestriert, die oft durch DNS- oder Lastenverteilungs-Konfigurationen gesteuert werden. Failover-Mechanismen sind daher ein wesentlicher Bestandteil dieser Architektur und müssen präzise definiert und implementiert werden.

Ein zentraler Bestandteil der Active-Passive-Architektur ist die Definition eines „arbeitsfähigen“ Zustands für die Anwendung oder den Service. Dies erfordert die Überwachung von Metriken wie Ressourcenverfügbarkeit, Performance und Fehlerhäufigkeit. Nur wenn eine der definierten Schwellenwerte überschritten wird, sollte ein Failover erfolgen. In diesem Zusammenhang ist es wichtig, dass die passiven Regionen vorab korrekt konfiguriert und vorbereitet werden, um den Übergang im Notfall reibungslos zu gestalten.

Zu den Vorbereitungen gehört unter anderem das Provisionieren und Konfigurieren der notwendigen Ressourcen wie Compute-Instanzen, Datenbanken, Speicher und unterstützende Dienste in der passiven Region. Durch den Einsatz von Infrastructure-as-Code (IaC) lässt sich sicherstellen, dass dieselben Komponenten sowohl in der aktiven als auch in der passiven Region vorhanden sind und fehlerfrei funktionieren. Dies umfasst unter anderem die Bereitstellung von Elastic Compute Cloud (EC2)-Instanzen oder Auto-Scaling-Gruppen (ASGs) sowie das Einrichten von Datenbankreplikation und Speicherkontingenten wie Amazon Elastic File System (EFS) oder Amazon S3.

Darüber hinaus müssen auch unterstützende Dienste wie Nachrichtenwarteschlangen (z. B. Amazon SQS), Caching-Schichten (z. B. Amazon ElastiCache) oder Lastenverteilungsmechanismen (Elastic Load Balancing) in der passiven Region vorhanden sein. Ein sorgfältiger Test der Passivregion vor einem Failover ist entscheidend, um sicherzustellen, dass sie die eingehenden Anfragen ohne Probleme verarbeiten kann.

Sobald das Überwachungssystem einen Ausfall in der aktiven Region erkennt, kann der Failover-Prozess ausgelöst werden. Dies kann entweder manuell oder automatisch geschehen, wobei es sich bewährt, den Failover-Prozess in der Praxis manuell auszulösen, um Fehler zu vermeiden. Ein häufig verwendeter Failover-Mechanismus ist DNS-Failover, insbesondere unter Verwendung von Amazon Route 53. Route 53 ermöglicht es, DNS-Datensätze so zu konfigurieren, dass sie auf die aktive bzw. passive Region verweisen. Sobald ein Ausfall erkannt wird, werden die DNS-Einträge aktualisiert, um den Verkehr zur passiven Region umzuleiten.

Für eine noch effizientere Verwaltung der Failover-Prozesse können Lösungen wie der AWS Application Recovery Controller (ARC) genutzt werden. ARC ermöglicht es, Wiederherstellungspläne zu definieren, die die Provisionierung von Ressourcen, die Datenreplikation und DNS-Aktualisierungen automatisieren. Dies ist besonders vorteilhaft, wenn mehrere AWS-Regionen betroffen sind. Mit ARC lässt sich der Failover-Prozess durch Integration mit anderen AWS-Diensten wie Lambda oder CloudFormation weitgehend automatisieren, was die Flexibilität und Effizienz des Systems erhöht.

Ein wichtiger Aspekt, der ebenfalls regelmäßig überprüft und getestet werden muss, ist die Konsistenz zwischen der aktiven und der passiven Region. Die Konfigurationen, Ressourcenspezifikationen und Versionen der Anwendung sollten in beiden Regionen identisch sein, um Probleme beim Failover zu vermeiden. Dies schließt auch die Sicherstellung ein, dass alle Daten in der passiven Region auf dem neuesten Stand sind und jederzeit auf die Bedürfnisse des Failovers reagieren können.

Zusätzlich zur Vorbereitung und dem Testen von Failover-Mechanismen sollten regelmäßige Failover-Übungen durchgeführt werden. Hierbei können Dienste wie der AWS Fault Injection Simulator zum Einsatz kommen, um simulierte Ausfälle zu erzeugen und die Reaktion des Systems unter realistischen Bedingungen zu überprüfen. Solche Übungen tragen dazu bei, mögliche Schwachstellen zu identifizieren und die Resilienz des Systems weiter zu stärken.

Ein weiterer Punkt, den Unternehmen bei der Implementierung einer Active-Passive-Architektur bedenken sollten, ist die langfristige Wartung und Skalierbarkeit des Systems. Während die Active-Passive-Architektur im Hinblick auf Kosten und Einfachheit attraktiv ist, muss sie möglicherweise angepasst oder erweitert werden, wenn sich die Anforderungen an die Skalierbarkeit oder die Komplexität der Anwendungen ändern. In solchen Fällen kann es notwendig werden, auf eine Active-Active-Architektur umzusteigen, bei der beide Regionen gleichzeitig aktiv sind, was höhere Anforderungen an die Verwaltung und die Ressourcenbereitstellung stellt.

Wie AWS-Regionen und Multi-AZ-Redundanz die Verfügbarkeit und Resilienz von Anwendungen sichern

Die AWS-Architektur ist so ausgelegt, dass sie hohe Verfügbarkeit und Resilienz für Anwendungen gewährleistet, selbst bei Ausfällen oder unvorhergesehenen Problemen wie Hardwarefehlern oder Naturkatastrophen. Eine der zentralen Mechanismen, die diese Resilienz unterstützen, ist die Multi-AZ-Redundanz, die durch das Design von mehreren Availability Zones (AZs) innerhalb einer AWS-Region bereitgestellt wird. Jede dieser Zonen ist isoliert, sodass ein Ausfall in einer Zone nicht zu einer Beeinträchtigung der anderen Zonen führt. Diese isolierten AZs bieten eine effektive Möglichkeit, Anwendungen robust und ausfallsicher zu gestalten.

Trotz dieser starken Infrastrukturvorkehrungen ist AWS nicht gegen technische Ausfälle wie Netzwerk-, Hardware- oder Stromprobleme immun. Solche Ausfälle werden jedoch durch gezielte Überwachungs- und Automatisierungsprozesse schnell erkannt und adressiert. Der Nutzer von AWS muss sicherstellen, dass seine Anwendungen so entwickelt werden, dass diese Infrastruktur im besten Fall maximal ausgenutzt wird. AWS übernimmt die Verantwortung für die Aufrechterhaltung der Hardware und Infrastruktur, jedoch liegt es in der Verantwortung des Kunden, Anwendungen zu entwickeln, die diese Infrastruktur optimal nutzen und so die bestmögliche Verfügbarkeit gewährleisten.

Es ist von großer Bedeutung, dass bei der Planung von Anwendungen die Ressourcen nicht nur auf eine einzelne AZ angewiesen sind. Ein Beispiel hierfür ist der Fall, dass ein Rechenzentrum in einer AZ aufgrund einer Naturkatastrophe wie Feuer, Überschwemmung oder Erdbeben ausfällt. Wenn eine Anwendung ausschließlich in dieser AZ gehostet wird, wird sie ebenfalls nicht mehr verfügbar sein. Um diesem Risiko zu begegnen, ist es entscheidend, Anwendungen so zu gestalten, dass sie auf mehreren AZs basieren. Der erste Schritt hierzu ist der Aufbau von Virtual Private Cloud (VPC)-Netzwerken, bei denen Subnetze auf verschiedene AZs verteilt sind. Eine größere Anzahl genutzter AZs verbessert die Verfügbarkeit weiter.

Ein paar wesentliche Überlegungen bei der Gestaltung von Anwendungen für hohe Verfügbarkeit und Resilienz sind:

  • Der Einsatz eines Load Balancers, der den Datenverkehr über mehrere AZs verteilt, stellt sicher, dass bei einem Ausfall einer AZ der Traffic auf andere AZs umgeleitet wird.

  • Die Speicherung von Daten in mehreren AZs ist entscheidend, um den Verlust von Daten im Falle eines Ausfalls zu verhindern.

  • Der Einsatz einer hochverfügbaren Datenbank stellt sicher, dass die Anwendung auch bei einem Ausfall eines Datenbank-Servers weiterhin verfügbar bleibt.

  • Testen Sie Ihre Anwendung auf Verfügbarkeit, indem Sie sicherstellen, dass sie den Ausfall einer oder mehrerer AZs überstehen kann.

Neben den technischen Aspekten der Infrastruktur muss auch die Softwareentwicklung mit Bedacht erfolgen, um die Resilienz zu gewährleisten. Oftmals ist eine Anwendung nicht widerstandsfähig, weil sie bei der Programmierung nicht effizient und ausfallsicher entwickelt wurde. Der Entwickler ist verantwortlich für das Schreiben von performantem und sicherem Code, um eine optimale Benutzererfahrung zu gewährleisten. Dabei hilft es, bewährte Designprinzipien zu befolgen, wie die Entwicklung von stateless, horizontal skalierbaren Microservices. Solche Architekturen ermöglichen eine bessere Resilienz, da sie Redundanz, Isolation und automatisierte Verwaltung bieten.

Darüber hinaus ist es entscheidend, sicherheitsbewussten Code zu schreiben, um die Integrität und Resilienz der Anwendung zu gewährleisten. Dies umfasst die Verwendung sicherer Programmiersprachen und -bibliotheken sowie die Vermeidung häufig auftretender Sicherheitslücken durch Methoden wie Eingabevalidierung und Ausgabesäuberung. Das regelmäßige Testen auf Sicherheitslücken, durch statische und dynamische Codeanalyse sowie Penetrationstests, ist ebenfalls unerlässlich. Die Einhaltung von internationalen Sicherheitsstandards, wie den ISO-Normen 27001, 27002 und 27005, sorgt für eine systematische Herangehensweise an Informationssicherheit und Risikomanagement.

Ein weiteres wichtiges Element für die Sicherheits- und Resilienzaspekte einer Anwendung ist das Software Bill of Materials (SBOM). Ein gut gestaltetes SBOM listet alle Softwarekomponenten, deren Versionen und Abhängigkeiten auf, sodass Sicherheitsrisiken und Schwachstellen leichter identifiziert werden können. Dabei ist es wichtig, ein standardisiertes Format für SBOMs zu verwenden, regelmäßig zu aktualisieren und die Herkunft der Softwarekomponenten nachzuvollziehen. Dies hilft nicht nur bei der Erkennung von Sicherheitslücken, sondern reduziert auch die Angriffsfläche und schützt vor Risiken aus der Softwarelieferkette.

Durch die Kombination aus einer robusten Infrastruktur, redundanter Architektur und bewährten Sicherheitspraktiken können Entwickler resilientere Anwendungen erstellen, die auch in Krisenzeiten stabil bleiben. Anwendungen, die auf mehrere AZs verteilt sind und hochverfügbare Datenbanken nutzen, bieten eine deutlich höhere Resilienz gegenüber Ausfällen. Darüber hinaus sollten Entwickler sicherstellen, dass sie nicht nur funktionale Anforderungen erfüllen, sondern auch die notwendigen Schritte unternehmen, um die Anwendungen gegen interne und externe Bedrohungen zu schützen.