AWS-Ausfall vom 21.02.2026: Direct Connect Routing-Probleme nach US-EAST-1 – was ist passiert?
Am 21. Februar 2026 (CET) gab es bei AWS Direct Connect in der Region US-EAST-1 (N. Virginia) eine Störung, die für einige Kunden sehr konkret spürbar war: zuvor annoncierte Routen zwischen VPC und On-Prem waren zeitweise nicht (mehr) verfügbar. Das Resultat: Verbindungsprobleme von Workloads in der VPC zurück ins eigene Rechenzentrum bzw. zu On-Prem-Netzen.
Das ist einer dieser Incidents, die nicht spektakulär nach „alles ist down“ aussehen – aber in Hybrid-Architekturen trotzdem sofort echten Schaden anrichten, weil Connectivity die Grundlage von allem ist: Datenbanken, Auth, Legacy-Integrationen, VPN-Fallback, Monitoring, Deployments.
Quelle: Symbolische Darstellung von Cloud- und Netzwerk-Infrastruktur – passend zu Direct Connect & Routing-Themen.
Kurze Zusammenfassung
- Was: Konnektivitätsprobleme bei AWS Direct Connect zur Region US-EAST-1.
- Wann: 21.02.2026 (CET; Nacht/Frühmorgen).
- Symptom: Bei einigen Kunden fehlten zuvor annoncierte Routen zwischen VPC und On-Prem, was zu Verbindungsabbrüchen/Timeouts führte.
- Scope: Betroffen waren einige Direct-Connect-Kunden / nicht „AWS als Ganzes“.
- Status (laut Updates): Ursache identifiziert; AWS arbeitete parallel an Mitigations, stellte Routen wieder her und beobachtete deutliche Erholung.
- Dauer: grob ~1–2 Stunden (je nach Kunde/Route; Status-Updates zeigen schrittweise Recovery).
- Takeaway: Hybrid-Resilienz braucht DX-Redundanz und einen VPN-Fallback, plus saubere Routing-Strategie.
Was ist passiert?
Laut den öffentlich einsehbaren Status-Updates wurde zunächst eine Störung der Direct-Connect-Konnektivität in US-EAST-1 untersucht. Kurz danach bestätigte AWS, dass einige Kunden betroffen sind. Konkret: „missing previously advertised routes“ – also Routen, die vorher verfügbar waren, wurden nicht mehr (korrekt) announced. AWS identifizierte die Ursache und arbeitete „on multiple parallel paths“ an der Behebung, inkl. Restore der betroffenen Route-Advertisements.
Timeline (aus den Status-Updates)
Hinweis: Zeitangaben sind aus öffentlich sichtbaren Status-Updates übernommen; je nach Anzeige können sie in unterschiedlichen Zeitzonen dargestellt werden.
| Zeit (Status-Update) | Update | Praktische Bedeutung |
|---|---|---|
| 21.02.2026 00:38 | Investigating (Direct Connect Connectivity Issues) | Erste Bestätigung: Problem liegt in der DX-Konnektivität nach US-EAST-1. |
| 21.02.2026 00:59 | Confirmed – fehlende zuvor annoncierte Routen | Hybrid-Traffic (VPC → On-Prem) kann ausfallen, obwohl interne AWS-Services „grün“ wirken. |
| 21.02.2026 01:22 | Restore der nicht mehr anunciaten Routen läuft, Ursache identifiziert | Recovery ist Route-/Control-Plane-getrieben: es kann pro Connection/VIF unterschiedlich schnell zurückkommen. |
| 21.02.2026 01:33 | Early signs of recovery | Erste Kunden sehen Stabilisierung – andere sind ggf. noch betroffen. |
| 21.02.2026 01:50 | Significant recovery | Meiste Pfade/Announcements scheinen zurück zu sein; Monitoring weiterlaufen lassen. |
Technische Einordnung: Warum „fehlende Routen“ so gefährlich sind
Direct Connect ist am Ende Routing (BGP) plus physische/virtuelle Pfade. Wenn Routen „verschwinden“ oder nicht mehr richtig announced werden, wirkt das im Betrieb häufig wie ein klassischer Netzwerk-Fehler: Timeouts, sporadische Failures, asymmetrisches Routing, Blackholing – und die Symptome sind je nach Anwendung sehr unterschiedlich.
Wichtig ist: Solche Events können auftreten, ohne dass deine EC2-Instanzen oder AWS-Managed-Services selbst kaputt sind. Deine Workloads laufen, aber sie erreichen das, was sie brauchen (z. B. On-Prem-DB, AD/LDAP, Legacy-APIs, MPLS-Netze) zeitweise nicht.
Was du (jetzt) konkret tun kannst – Checkliste
- VPN-Fallback aktiv haben: Site-to-Site VPN als „Break-Glass“-Pfad, der bei DX-Issues übernehmen kann (automatisiert via Routing-Prioritäten).
- Direct-Connect-Redundanz: Zwei physische Verbindungen/Locations, getrennte Geräte/Provider, getrennte VIFs. Single-Cable-Fate vermeiden.
- Routing-Design prüfen: BGP-Communities/LocalPref/AS-Path-Prepending sauber definieren, damit Failover nicht „klebt“.
- Blackbox-Monitoring: Nicht nur CloudWatch, sondern synthetische Checks über den Hybrid-Pfad (VPC → On-Prem und zurück).
- Incident-Runbook: „DX down / Routes missing“ als eigene Runbook-Kategorie – inkl. schneller Umschaltung und klaren Kommunikationsbausteinen.
Wenn du häufiger Hybrid fährst: Es lohnt sich, Routentabellen, Propagation und Failover einmal bewusst zu testen (Chaos-Style, aber kontrolliert). Denn genau da entscheiden Minuten – nicht Stunden.
Einordnung: Was in der Vergangenheit schon passiert ist
Der gestrige Direct-Connect-Incident ist eine andere Klasse als die großen „Internet brennt“-Ausfälle – aber er passt in ein Muster: Viele Störungen sind nicht „Compute down“, sondern Netzwerk-/Control-Plane-Probleme, die dann sekundär überall Symptome erzeugen.
Beispiele (kurz) – zum Vergleich
| Datum | Scope | Was war grob das Thema? |
|---|---|---|
| 21.02.2026 | AWS Direct Connect (US-EAST-1) | Fehlende zuvor annoncierte Routen (VPC ↔ On-Prem) → Hybrid-Konnektivitätsprobleme. |
| Okt 2025 | Mehrere AWS-Services (US-EAST-1) | Großer Multi-Service-Incident mit Kaskadeneffekten (u. a. DNS/Load-Balancer-Abhängigkeiten) – breit spürbar. |
| Dez 2025 | Ein einzelner Service (China-Regionen) | Berichtete Störung eines Cost-Management-Features; Diskussion um interne AI-Coding-Tools (Kiro) & Prozess-/Berechtigungsfragen. |
Diese Rückblicke sind nicht dazu da, Drama zu machen – sondern um zu zeigen: Resilienz ist fast immer Architektur. Und bei Hybrid-Setups ist „Network + Routing“ der Bereich, wo ein scheinbar kleiner Incident sofort groß wirkt.
Häufig gestellte Fragen
War „AWS down“ oder nur Direct Connect?
Die öffentlichen Updates beschreiben ein Problem bei AWS Direct Connect zur Region US-EAST-1. Betroffen waren einige Kunden/Verbindungen – nicht zwangsläufig alle AWS-Services weltweit.
Warum merkt man fehlende Routen so stark?
Weil viele Hybrid-Systeme zentrale Abhängigkeiten On-Prem haben (AD/LDAP, Legacy-DB, Fileshares, zentrale APIs). Wenn BGP-Announcements fehlen, laufen Anwendungen weiter, aber erreichen ihre Abhängigkeiten nicht zuverlässig.
Was ist die beste Absicherung?
Redundanter Direct Connect (getrennte Pfade) plus VPN-Fallback, dazu synthetisches Monitoring über den tatsächlichen Hybrid-Pfad und ein klares Runbook für Umschaltung.
Hat das etwas mit „KI-Tools“ zu tun?
Für den Direct-Connect-Incident gibt es in den öffentlichen Updates keinen Hinweis auf KI-Tooling. Der KI-Bezug stammt aus separaten Berichten zu anderen Vorfällen (z. B. Dez 2025) und ist hier nur Kontext.
Schlussfolgerung
Der Incident vom 21.02.2026 ist ein gutes Beispiel dafür, warum man Ausfälle nicht nur als „Service down“ verstehen darf: In Hybrid-Architekturen reicht eine Störung bei Route-Advertisements, und plötzlich steht ein kompletter Business-Flow. Wenn du aus diesem Vorfall genau eine Sache mitnimmst, dann diese: Plane den Weg (Routing) genau so redundant wie die Workloads.