Was hat den AWS-Ausfall verursacht?

Ein Fehler in den internen Load-Balancing- und Health-Monitoring-Systemen von AWS löste Kaskadenfehler in mehreren Diensten aus, störte die Konnektivität und führte zu Ausfällen bei zahlreichen globalen Plattformen.

Waren die Systeme von higroup betroffen?

Nein. Die Infrastruktur von higroup läuft überwiegend in der AWS-Region EU, die nicht betroffen war. Unsere Architektur umfasst zudem Redundanz und Isolation über Regionen hinweg, um Kaskadeneffekte zu verhindern.

Wie können sich Unternehmen vor ähnlichen Ausfällen schützen?

Indem sie auf Resilienz hin entwerfen, Multi-Region-Deployments, automatisierte Failover-Mechanismen und leistungsfähige Observability-Tools einsetzen, um Fehler schnell zu erkennen und darauf zu reagieren.

Ist Multi-Cloud immer nötig, um Zuverlässigkeit zu sichern?

Nicht immer, aber bei geschäftskritischen Systemen bietet ein Multi-Cloud- oder Hybrid-Ansatz zusätzliche Absicherung gegen Ausfälle auf Anbieterebene. Die richtige Wahl hängt von der Risikotoleranz und dem Budget Ihres Produkts ab.

Was können Teams aus diesem Vorfall lernen?

Dass Zuverlässigkeit nicht von der Cloud kommt – sie wird gebaut. Kontinuierliches Testen, Monitoring und Vorbereitung sind der Schlüssel, um Downtime zu minimieren und das Vertrauen der Nutzer zu erhalten.

Als AWS ausfiel: Lehren für Cloud-Resilienz

Der Tag, an dem AWS ausfiel

Am 20. Oktober 2025 kam es bei AWS zu einem großflächigen Ausfall, der Dienste weltweit beeinträchtigte. Websites, mobile Apps und ganze Infrastrukturen gingen innerhalb von Minuten offline. Der Vorfall ging von der AWS-Region US-EAST-1 aus und zeigte, wie abhängig moderne Unternehmen von zentralisierten Cloud-Systemen geworden sind – und warum Resilienz in der Architektur nicht länger optional ist.

Introduction

Was ist wann passiert?

In den frühen Morgenstunden meldeten AWS-Nutzer Verbindungsabbrüche und Dienststörungen. Das Problem ging von einem der größten und am stärksten vernetzten Rechenzentren von Amazon aus. Innerhalb von Minuten wirkte es sich auf globale Traffic-Routen aus und legte Plattformen wie Snapchat und Fortnite sowie Teile der eigenen Amazon-Dienste lahm. AWS bestätigte, dass erhöhte Fehlerraten und Latenzen durch einen Fehler in den Subsystemen für Load Balancing und Health Monitoring verursacht wurden, der zu Kaskadenausfällen in mehreren internen Diensten führte.

What happened

Warum ist es passiert?

Im Kern des Vorfalls stand ein Fehler im internen Network-Load-Balancing-System von AWS, das eingehenden Traffic auf Server verteilt, damit Anwendungen reibungslos laufen. Als dieses Subsystem ausfiel, löste es einen Dominoeffekt aus – Health Checks schlugen fehl, Routing-Tabellen wurden instabil und abhängige Dienste liefen in Timeouts.

Weil viele AWS-Dienste auf gemeinsame interne Komponenten angewiesen sind, breitete sich die Störung schnell über die gesamte Plattform aus. Selbst Anwendungen in anderen Regionen liefen zeitweise langsamer, da globale DNS- und Authentifizierungssysteme betroffen waren.

Wie higroup online blieb

Auswirkungen auf higroup

Während der Ausfall viele globale Plattformen lahmlegte, blieben die Systeme von higroup uneingeschränkt funktionsfähig. Unsere Infrastruktur läuft überwiegend in der AWS-Region EU, die von dem Vorfall nicht betroffen war. Bewusst trennen wir Umgebungen nach Geografie und Zweck – damit eine Störung in einer Region nie auf eine andere übergreift.

Zur regionalen Isolation kommt eine redundante Architektur: automatisierte Backups, unabhängige Service-Cluster und Failover-Mechanismen, die Kernsysteme auch dann reaktionsfähig halten, wenn externe Abhängigkeiten langsamer werden. Das gehört zu unserem übergeordneten Anspruch an resiliente Entwicklung – wir planen für den Ausfall, damit Kunden online bleiben, wenn die Cloud ausfällt.

Eine Karte mit den AWS-Regionen der Rechenzentren.

Why did it happen?

Wie lassen sich solche Probleme verhindern?

Cloud-Ausfälle sind unvermeidlich, Downtime muss es aber nicht sein. Der Schlüssel liegt in einer Architektur, die auf Resilienz ausgelegt ist, nicht auf Bequemlichkeit. Systeme sollten Störungen auf Regions- oder Service-Ebene einkalkulieren und bei einem Ausfall die Last automatisch umverteilen können. Bei higroup entwerfen wir Infrastrukturen mit Multi-Region-Redundanz, Auto-Scaling-Gruppen und Load Balancern, die den Traffic in Echtzeit in intakte Zonen umleiten. Für geschäftskritische Plattformen setzen wir zusätzlich Disaster-Recovery-Umgebungen bei mehreren Cloud-Anbietern ein – AWS, Azure und GCP.

Lehren für Software-Teams

Echte Resilienz beruht auf Vorbereitung, nicht auf Reaktion. Entwerfen Sie Systeme mit geografischer und infrastruktureller Redundanz, sodass mehrere Regionen oder Availability Zones übernehmen können, wenn eine ausfällt. Legen Sie klare Failover-Verfahren fest und proben Sie sie, damit sie im Ernstfall sofort greifen. Kombinieren Sie das mit konsequentem Monitoring – nicht nur für die Verfügbarkeit, sondern für die Performance jedes Dienstes und jeder Abhängigkeit. Wer weiß, wann und wo Fehler auftreten, kann schnell reagieren, Störungen begrenzen und das Vertrauen der Nutzer erhalten. Kurz gesagt: Resilienz heißt nicht nur, Ausfälle zu vermeiden, sondern auf sie vorbereitet zu sein.

Lessons

Über den Ausfall hinaus: Resilienz, die Bestand hat

Cloud-Ausfälle wird es wieder geben – die Frage ist nicht ob, sondern wann. Der Unterschied liegt darin, wie gut Teams auf den Ernstfall vorbereitet sind. Jeder Vorfall wie der AWS-Ausfall erinnert uns daran, dass Resilienz eine Haltung ist und nicht nur eine Konfiguration.

Bei higroup ist Zuverlässigkeit ein kontinuierlicher Prozess – aufgebaut auf kluger Architektur, Observability und Vorbereitung. Von Multi-Region-Setups über proaktives Monitoring bis zu getesteten Failover-Plänen: Unser Ziel ist es, Downtime für die Nutzer unsichtbar zu machen.

Denn am Ende beweist sich gutes Engineering nicht darin, Ausfälle zu vermeiden, sondern darin, wie schnell man sich davon erholt.

Wenn AWS ausfällt