AWS Statusseite: Ausfälle prüfen und richtig einordnen

AWS Statusseite: Ausfälle prüfen und richtig einordnen

Dein Shop antwortet nicht, die Console lädt zäh, im Chat tippt jemand „Ist AWS down?“. Der erste Reflex führt zur AWS Statusseite. Das ist richtig. Nur beantwortet sie eine engere Frage, als man im Stress annimmt: Gibt es ein Problem, das AWS selbst bestätigt hat? Ob dein Dienst erreichbar ist, steht dort nicht.

Wo du die AWS Statusseite findest

AWS betreibt die Seite unter dem Namen AWS Health Dashboard. Lange hieß sie „Service Health Dashboard“ und lag unter status.aws.amazon.com. Namen und Adressen bei Drittanbietern ändern sich gelegentlich, deshalb ist die Suche nach „AWS Health Dashboard“ verlässlicher als ein gespeichertes Lesezeichen. Prüfe das Lesezeichen ab und zu.

Die öffentliche Ansicht listet Dienste, gegliedert nach Regionen. Pro Dienst und Region siehst du, ob AWS dort ein Ereignis führt, und bei laufenden Vorfällen einen Verlauf mit Zwischenmeldungen.

Öffentliche Ansicht und Konto-Ansicht

Hier steckt ein Unterschied, den viele übersehen. Es gibt zwei Perspektiven:

• Öffentlich: die allgemeine Lage für alle Kunden, ohne Login.

• Konto-bezogen: Ereignisse, die Ressourcen in deinem eigenen Account betreffen. Dazu zählen geplante Wartungen oder die Stilllegung der Hardware unter einer EC2-Instanz.

Für den Betrieb ist die zweite Ansicht oft nützlicher. Eine Mail über eine auslaufende Instanz-Hardware liest man leicht als Routine und merkt erst nach dem Neustart, dass sie einen produktiven Server betraf. Wer mehrere Accounts betreibt, sollte klären, wer diese Meldungen überhaupt bekommt.

Die Region richtig lesen

Die Statusseite ist eine Matrix aus Dienst und Region. Läuft dein Setup in Frankfurt (eu-central-1), ist ein Eintrag für us-east-1 für dich zunächst Hintergrundrauschen. Das klingt banal, trotzdem entstehen daraus Fehlalarme im Team: Jemand sieht eine rote Zeile und vermutet sofort die eigene Anwendung betroffen.

Umgekehrt gibt es Dienste mit globalem Charakter, etwa IAM oder Route 53. Bei ihnen lohnt ein Blick in die AWS-Dokumentation, in welcher Region die Verwaltungsebene liegt. Ein Problem dort kann sich auswirken, ohne dass in deiner Region etwas auftaucht.

Warum eine grüne Zeile nicht heißt, dass alles läuft

Statusseiten werden von Menschen gepflegt oder zumindest freigegeben. Ein Eintrag erscheint oft erst, wenn der Anbieter ein Problem bestätigt und eingeordnet hat. Dazwischen liegt eine Lücke, in der Nutzer bereits Fehler sehen und die Seite noch ruhig bleibt.

Dazu kommen Fehlerbilder, die dort nie auftauchen werden, weil sie nicht bei AWS liegen:

• Das Zertifikat ist abgelaufen oder wurde nicht erneuert.

• Ein DNS-Eintrag zeigt nach einer Migration auf die falsche IP.

• Eine Security Group blockiert nach einer Änderung einen Port.

• Die Datenbank-Platte ist voll, die Anwendung antwortet mit Fehlern.

• Ein Teil der Anfragen scheitert, weil nur eine Availability Zone gestört ist.

In all diesen Fällen zeigt die AWS Statusseite Grün, und dein Dienst ist trotzdem unten. Wer sich darauf verlässt, sucht zuerst beim Anbieter und verliert Zeit.

Benachrichtigung statt Dauer-Reload

Seite neu laden ist keine Alarmierung. Besser ist, Ereignisse automatisch zu bekommen. AWS Health-Ereignisse lassen sich laut AWS-Dokumentation über Amazon EventBridge weiterleiten, etwa an SNS oder einen Chat-Kanal. Welche Funktionen und Schnittstellen in welchem Support-Plan enthalten sind, ändert sich mit der Zeit. Schau deshalb in die aktuelle Dokumentation, bevor du darauf eine Prozedur baust.

Auch die öffentliche Seite hat in der Vergangenheit Abo-Möglichkeiten wie Feeds angeboten. Ob das heute noch so ist, prüfst du am besten selbst.

Von außen messen, was Nutzer sehen

Meine Meinung: Die Statusseite des Anbieters ist eine Quelle für die Ursachensuche, kein Ersatz für eigene Messung. Ein externer Check fragt nicht, was AWS meldet, sondern was bei einem Besucher ankommt. Je nach Setup bieten sich verschiedene Prüfungen an:

• Ein API- und HTTP-Check auf einen Endpunkt, der wirklich etwas tut, nicht nur die Startseite ausliefert.

• Eine DNS-Prüfung, wenn Route 53 oder ein anderer Resolver Einträge verwaltet. Ein falscher Record fällt sonst oft erst durch Kundenmails auf.

• Ein Blick auf langsame Antworten. Teilstörungen zeigen sich häufig zuerst als Trägheit und nicht als Totalausfall.

So lässt sich eine Frage schnell beantworten: Sind alle Prüfungen rot und AWS meldet ein Ereignis in deiner Region, liegt der Verdacht auf AWS. Sind nur deine Checks rot und die Statusseite bleibt grün, such zuerst bei dir.

Ablauf bei Verdacht auf einen AWS-Ausfall

1. Prüfe, in welcher Region deine betroffenen Ressourcen liegen.

2. Öffne das AWS Health Dashboard, schau in die öffentliche Ansicht für genau diese Region und danach in die Konto-Ansicht.

3. Vergleiche mit deinen externen Checks: Was fällt aus, was nicht?

4. Teste gezielt die Ebenen, die nicht zu AWS gehören: Zertifikat, DNS, eigene Deployments der letzten Stunden.

5. Dokumentiere Zeitpunkt und Beobachtung. Das hilft später bei einem Support-Fall oder bei der Frage, ob du Ausfallzeiten mit einem Kunden besprechen musst.

Fazit für den Alltag

Lege die AWS Statusseite als festen Anlaufpunkt ins Runbook, mit Hinweis auf Region und Konto-Ansicht. Ergänze sie um Messungen von außen, die unabhängig vom Anbieter laufen. Wie so ein Setup aussehen kann, zeigt dir die Demo von Uptime Alien. Dort siehst du, wie Prüfungen und Meldungen zusammenspielen, bevor du etwas einrichtest. Mehr zu Uptime Alien findest du auf uptimealien.de.