The Doppler Quarterly (DEUTSCHE) Frühjahr 2017 | Page 9

Die Ruhe nach dem Cloud-Sturm:
die CTP-Interpretation des
AWS S3-Ausfalls
Mike Kavis
Der AWS-Ausfall vom Februar zeigt, warum Sie sich
auf Fehler vorbereiten müssen – unabhängig von
Ihrem Cloud-Provider.
Ich nutze die Public Cloud seit 2008. In den frühen Jahren war es nicht unge-
wöhnlich, dass es bei AWS zu zwei oder drei größeren Ausfällen pro Jahr kam.
In letzter Zeit sind Ausfälle sehr selten geworden. Hier finden Sie eine Liste
der größeren Ausfälle der letzten Jahre:
• 2013 war die EBS-API (Elastic Block Store) nicht mehr verfügbar und
legte damit viele Anwendungen und Unternehmen für einige Stunden
lahm.
• 2015 war DynamoDB nicht mehr verfügbar und verursachte damit Aus-
fälle für Unternehmen, die diese API nutzten.
• 2016 war Dyn von einer DDoS-Attacke betroffen. AWS stoppte die Nut-
zung schnell und leitete den Verkehr auf andere Provider um. Die Benut-
zer erlitten minimale Kollateralschäden.
• Am 28. Februar 2017 kam es durch einen Bedienerfehler zu einer
umfangreichen Störung von S3 (Simple Storage Service von Amazon) und
nachfolgenden Leistungsproblemen bei einer Reihe anderer AWS-APIs.
Viele Unternehmen verzeichneten dadurch Ausfälle.
Dieser letzte Ausfall hatte die größten Auswirkungen auf Kunden in vier Jah-
ren. Natürlich legten die Reaktionen in Social Media und der Blogosphäre nahe,
dass Hybrid Clouds oder Rechenzentren die Lösung seien. Server-Fans alleror-
ten freuten sich und fühlten sich bestätigt, während sie sich daran machten,
Infrastruktur im Wert von Millionen Dollar zu recyclen, ohne dem Unterneh-
men damit Mehrwert zu bieten.
Ich bin da gänzlich anderer Meinung. Die Lösung ist immer, sich durch das
Design auf Ausfälle des Cloud-Providers vorzubereiten, auf den Sie setzen:
„Design for Failure“.
FRÜHJAHR 2017 | THE DOPPLER | 7