Haftungsfragen

Amazon garantiert keine hundertprozentige Sicherheit, sondern setzt in Sachen Haftung auf ein als Shared Responsibility bezeichnetes Konzept: Amazon haftet für die Verfügbarkeit der Cloud als Ganzes, der Kunde ist für die Sicherheit der Informationen verantwortlich, die von ihm in die Cloud übertragen werden.

Von besonderem Interesse ist für diese Fragen das SLA unter https://aws.amazon.com/s3/sla. Eine kurze Recherche ergab, dass es mit S3 in der Praxis bisher keine größeren Datenverluste gab. Angesichts der immensen Menge von in AWS gehaltenen Informationen gab es allerdings sicher den einen oder anderen Kandidaten. Es ist immer vernünftig, von wirklich wichtigen Informationen zusätzlich ein On-Site-Backup zu ziehen.

In der Datenschutz-Anleitung des Dienstes findet sich zudem der Hinweis, dass S3 darauf ausgelegt ist, bei gleichzeitigem Datenverlust in zwei verschiedenen Facilities nach wie vor Informationen zurückliefern zu können.

S3 ist zur Verwaltung größerer Datenmengen ideal, auf die man von Zeit zu Zeit zugreift. Allerdings gibt es - etwa bei den oben genannten EC2-Systemen - Situationen, in denen man einen klassischen blockorientierten Speicher benötigt. Im Hause Amazon heißt dieser Dienst Elastic Block Store (EBS). Amazon bietet Entwicklern auf SSD beziehungsweise klassischen Festplatten liegende EBS-Volumina. In beiden Fällen identisch ist der Lebenslauf, der mit der Anlage eines Snapshots in S3 beginnt und endet.

Besonders wichtig ist, dass EBS-Speicher in einer einzigen Availability Zone liegt. Daten werden zwar von Zeit zu Zeit repliziert, das eigentliche blockorientierte Volume ist aber aus Gründen der Performance nur in einer einzigen Availability Zone anzutreffen und dementsprechend verwundbar.

Bei einer EC2-Instanz wird oft ein als Amazon EC2 Instance Storage bezeichneter Speicherbereich angeworfen. Es handelt sich dabei um eine EBS-Abart, die dank geringer Latenz eine Geschwindigkeit von 365.000 Lese-Operationen und 315.000 Schreib-Operationen pro Sekunde schafft. Der wichtigste Unterschied zwischen der gewöhnlichen EBS-Instanz und der Instance-Storage-Instanz ist, dass Instance Storage nach dem Sterben des EC2-Servers, der für seine Erzeugung verantwortlich war, automatisch ebenfalls zerstört wird.

Wer Amazon AWS nutzen, sich selbst aber nicht einarbeiten möchte, kann auf die von Amazon bereitgestellten beziehungsweise zertifizierten Advisors zurückgreifen. Es handelt sich dabei um ein an Microsofts MCP- beziehungsweise MOS-Programm angelehntes Zertifizierungssystem, über das Unternehmen ihre Kompetenz in Sachen AWS unter Beweis stellen können.

Amazon unterteilt die hauseigenen Dienste auch in AWS Foundation Services und AWS Platform Services. Die bisher besprochenen Dienste waren in der Welt der Foundation Services angesiedelt, während wir uns nun in Richtung der AWS Platform Services weiterbewegen. Hinter dem zunächst seltsam klingenden Namen verbirgt sich der Gedanke, dass der Administrator beziehungsweise Entwickler von Amazon Datenbanken und andere Dienste in vorkonfigurierter Form mieten kann. Diese Vorgehensweise hat Vorteile: Erstens müssen sie sich nicht mit der oft aufwendigen Administration und Optimierung des unterliegenden Datenbank-Servers auseinandersetzen, sondern können mit der Umsetzung ihrer Applikation beginnen. Updates  erledigt Amazon, womit das regelmäßige Hinterherhecheln der aktuellsten MySQL-Version der Vergangenheit angehört.

Vorteil Nummer zwei ist, dass es eine Vielzahl von Diensten beziehungsweise EC2-Instanzen gibt, bei denen sich Amazon auch um die Lizenzierung kümmert. Ein gern genanntes Einsatzszenario ist das Ausprobieren von Servern und sonstigen Produkten, für die man nur schwer eine Lizenz bekommt: Die Instanz erspart den oft nervtötenden Verkaufsdialog mit einem Sales-Team.

Auf der Soll-Seite steht, dass man bei der Nutzung einer vorkonfigurierten Instanz im Bereich der Parametrisierung eingeschränkt ist. Wer seine Datenbank oder seinen Load Balancer von Hand extrem feingranular einstellt, wird mit AWS nicht glücklich. Er muss eine EC2-Instanz anwerfen und mit den gewünschten Informationen parametrieren.

Die einfachste Datenbank ist der Amazon Relational Database Service (RDS), die klassische Implementierung einer relationalen Datenbank. Amazon unterstützt neben der hauseigenen Datenbank Aurora auch MySQL, MariaDB, Microsoft SQL Server, Oracle und PostgreSQL.

Im Grunde genommen legen Sie eine EC2-Instanz an, die einen Datenbank-Server darstellt, der in der AWS-Cloud lebt. Innerhalb dieser Instanz können Sie eine oder mehrere Datenbanken anlegen, in der Sie die eigentlichen Nutzdaten unterbringen.

Amazon hat den hauseigenen RDS-Service mit diversen Komfortfunktionen erweitert. Erstens gibt es regelmäßige automatisierte Backups. So können Sie Ihre Datenbank schnell und unbürokratisch zurücksetzen; die Vorhaltephase für alte Versionen kann auf bis zu 35 Tage ausgedehnt werden. Alternativ dazu gibt es die Möglichkeit, von Hand das Aufnehmen eines Snapshots anzuweisen. Dieser wird so lange aufbewahrt, bis Sie ihn löschen – die Daten liegen in einem S3-Bucket, für dessen Nutzung Kosten anfallen.

Von Haus aus sitzt RDS immer nur in einer einzigen Availability Zone. Sie können alternativ auf ein Verfahren namens Multi-AZ RDS Deployment zurückgreifen, in dem die Datenbank synchron in mehreren Zonen angelegt wird. Wichtig ist, dass alle Availability Zones in derselben Region liegen müssen, da sonst für Amazon nicht tragbare Latenzen auftreten. Ist ein Datenbankverbund in diesem Betriebsmodus, kommt es im Fall eines Ausfalls einer Datenbank automatisch zu einem Fail-over. Beachten Sie aber, dass geplante Wartungsmaßnahmen zuerst auf die Stand-by-Server ausgeführt werden, bevor sie die eigentliche Haupt- und Staats-Datenbank berühren.

Amazon bietet optional auch eine Gruppe von NoSQL-Datenbanken an, die sich analog zum klassischen RDS verhalten. Die Datenbanksysteme im NoSQL-Bereich sind allerdings allesamt Eigenentwicklungen, die sich von den Marktführern mehr oder weniger stark unterscheiden.