Was IT-Entscheider aus dem AWS-Ausfall lernen sollten

Ein AWS-Ausfall legte tausende Unternehmen an der Ostküste der USA lahm. Wir zeigen, wie sich Firmen gegen solche Ausfälle wappnen können. [...]

Die Probleme von Amazon Web Services (AWS) Anfang Dezember mit APIs in der Region US-East-1 führte vielen Amerikanern und Kanadiern drastisch vor Augen, wie sehr alle auf AWS angewiesen sind. Selbst Consumer, die noch nie etwas von AWS gehört hatten, waren plötzlich betroffen, weil Disney+ und Netflix nicht mehr funktionierten, der Roomba-Saugroboter den Dienst quittierte, oder die intelligente Lampe einfach dunkel blieb.

Noch härter traf es viele Unternehmen, die für ihren IT-Betrieb auf AWS angewiesen sind. Oder die feststellen mussten, dass sie selbst zwar keine Geschäftsbeziehung zu AWS haben, aber viele ihrer Services – etwa Trello, Smartsheet, Slack etc. – die sie nutzen, nicht mehr funktionierten, weil sie auf AWS basieren.

Lehren aus der AWS-Panne

Doch welche Lehren sollten wir aus dem Vorfall ziehen? Im privaten Umfeld ist das noch einfach: Wir sollten aufhören, uns auf so viele IoT-Devices zu verlassen. Müssen Geschirrspüler, Weihnachtsbeleuchtung, Kühlschrank und Zahnbürste wirklich von der Cloud abhängig sein? Anders sieht es im Business-Umfeld aus. Der Gedanke, dass die IT-Abteilung wieder alle ihre Server selbst betreibt, wird ein frommer Wunsch bleiben. Ein einfacher Vergleich zwischen damals und heute zeigt, wie absurd diese Idee ist.

Und egal, was das C-Level-Management will, die IT kann nicht etwas zum Laufen bringen, das außerhalb ihrer Kontrolle liegt. Zumal es einen Grund gibt, warum jetzt vieles oder alles in der Cloud läuft: In der Regel kostet es weniger, als entsprechende Services On-Premises zu betreiben. Zumal die Downtime in der Cloud bislang sicher geringer war als die der eigenen IT.

Multi-Cloud als Ausfallschutz?

Doch was tun, um Problemen wie dem ASW-Ausfall vorzubeugen? Könnte ein Wechsel zu einer Multi-Cloud-Konfiguration die Lösung sein? In der Theorie vielleicht, aber dazu wären mindestens zwei öffentliche Cloud-Anbieter und möglicherweise ein eigenesRechenzentrum erforderlich. Das wird sehr, sehr teuer. Zudem werden Multi-Clouds als Sicherheitsnetz gegen Ausfälle wie den von AWS nicht funktionieren, davon ist Lydia Leong, Gartner Distinguished VP Analyst, überzeugt.

Oder wie sie es ausdrückt: „Multi-Cloud-Failover erfordert eine vollständige Portabilität zwischen zwei Anbietern. Dies stellt eine enorme Belastung für die Entwickler dar. Die grundlegende Compute-Runtime (ob VMs oder Container) ist dabei nicht das Problem, so dass ‚Ich kann meine Container verschieben‘-Lösungen von OpenShift, Anthos oder anderen nicht wirklich helfen.“ Das Problem seien all die Unterscheidungsmerkmale, so Leong, die unterschiedlichen Netzwerkarchitekturen und -funktionen, die unterschiedlichen Speicherkapazitäten, die proprietären PaaS-Funktionen, die völlig unterschiedlichen Sicherheitsfunktionen etc.

Sie sehen gerade einen Platzhalterinhalt von YouTube. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.

Mehr Informationen

Inhalt entsperren Erforderlichen Service akzeptieren und Inhalte entsperren

Tipps gegen Cloud-Ausfall

Doch genug lamentiert. Gartner-Analystin Leong ist überzeugt, dass es durchaus gelingen kann, ein Unternehmen am Laufen zu halten, selbst wenn die primäre Cloud ausfällt. Hierzu hat sie zwei Tipps auf Lager:

1. Unternehmen sollten ihre aktiven Anwendungen in mindestens zwei, besser drei Availability Zones (AZ) in jeder von ihnen genutzten Region betreiben. Sicher: Drei sind viel schwieriger zu erreichen als zwei AZs, aber dies ist immer noch einfacher als der Versuch, eine Multi-Cloud-Failover-Lösung aufzubauen.
2. Ferner sollten die aktiven Anwendungen in mindestens zwei, besser drei Regionen betrieben werden. Auch hier gilt: Zwei sind viel einfacher als drei, aber wenn eine geschäftskritische Anwendung wirklich geschäftskritisch ist, kann es die Mühe wert sein. Falls das nicht realisierbar ist, könnte ein schnelles und vollautomatisches regionales Failover eine Option sein – unter der Voraussetzung, dass ein Unternehmen dazu bereit ist, für eine solchen Dienst zu bezahlen.

*Steven schreibt für unsere US-Schwesterpublikation Computerworld. Er beschäftigte sich bereits mit Business und Technologie als 300bps noch Highspeed war.