EBS-Snapshots, Verschlüsselung und RAID

EBS-Snapshots sind Backups von EBS-Volumes zu einem bestimmten Zeitpunkt, die dauerhaft in Amazon S3 gespeichert werden (sie werden jedoch von EBS verwaltet und sind nicht direkt über die S3-Konsole zugänglich). Der erste Snapshot ist eine vollständige Kopie; nachfolgende Snapshots sind inkrementell – gespeichert werden nur die Blöcke, die seit dem letzten Snapshot geändert wurden. Trotz der inkrementellen Speicherung können Sie jeden einzelnen Snapshot in einem vollständigen Volume wiederherstellen. Snapshots sind der primäre Mechanismus für Backups, Migration und Disaster Recovery von EBS-Volumes.

Abgerechnet wird der tatsächlich verbrauchte Speicher durch inkrementelle Snapshot-Blöcke über alle Snapshots eines Volumes hinweg – nicht die Volume-Größe. Wenn Sie zwischenliegende Snapshots löschen, konsolidiert S3 die Daten, sodass die verbleibenden Snapshots weiterhin vollständige Wiederherstellungspunkte darstellen. Um Kosten in großem Maßstab zu verwalten, verwenden Sie den Amazon Data Lifecycle Manager (DLM), um Snapshot-Zeitpläne und Aufbewahrungsrichtlinien zu erstellen – beispielsweise tägliche Snapshots zu erstellen, die letzten 7 täglichen, 4 wöchentlichen und 12 monatlichen Snapshots aufzubewahren und ältere Snapshots automatisch zu löschen.

Snapshots können für Disaster Recovery und die geografische Verteilung regionsübergreifend kopiert werden. Sie können Snapshots auch für bestimmte AWS-Konten freigeben (oder öffentlich machen), um EBS-Daten kontenübergreifend zu übertragen, ohne das Netzwerk zu verwenden. Beim Kopieren eines Snapshots können Sie den Verschlüsselungsschlüssel ändern – so übertragen Sie Daten von einem unverschlüsselten Volume auf ein verschlüsseltes oder von einem Schlüssel in einem Konto auf einen Schlüssel in einem anderen Konto.

Das Erstellen eines Volumes aus einem Snapshot ist unkompliziert, es gibt jedoch einen Performance-Aspekt: Aus Snapshots wiederhergestellte Volumes beginnen mit allen in S3 gespeicherten Blöcken, die beim ersten Zugriff verzögert geladen werden. Dies kann bei Blöcken, die noch nicht in das Volume geladen wurden, zu einer höheren Latenz führen. Verwenden Sie für Produktionsdatenbanken Fast Snapshot Restore (FSR) – eine kostenpflichtige Funktion, die den Snapshot vorwärmt, sodass Volumes sofort die volle Performance erreichen. Alternativ können Sie das Volume nach der Wiederherstellung vorwärmen, indem Sie mit dd oder fio alle Blöcke lesen.

EBS-Verschlüsselung verwendet AES-256, um Daten im Ruhezustand (auf dem Volume), während der Übertragung zwischen Volume und EC2-Instance sowie in Snapshots zu verschlüsseln. Die Verschlüsselung wird transparent vom EC2-Hypervisor durchgeführt – Ihre Anwendung stellt keinen Unterschied fest. Für die Verschlüsselung werden AWS-KMS-Schlüssel verwendet: Sie können den von AWS verwalteten Schlüssel (aws/ebs) oder einen kundenverwalteten Schlüssel (CMK) verwenden. Sobald ein Volume verschlüsselt ist, werden auch alle darauf geschriebenen Daten und alle daraus erstellten Snapshots verschlüsselt.

Sie können ein vorhandenes unverschlüsseltes EBS-Volume nicht direkt verschlüsseln. Die Umgehungslösung besteht aus mehreren Schritten: (1) Erstellen Sie einen Snapshot des unverschlüsselten Volumes, (2) kopieren Sie den Snapshot mit --encrypted, um einen verschlüsselten Snapshot zu erstellen, (3) erstellen Sie aus dem verschlüsselten Snapshot ein neues verschlüsseltes Volume, (4) stoppen Sie die Instance, trennen Sie das alte Volume, verbinden Sie das neue verschlüsselte Volume und starten Sie die Instance neu. Dieser Prozess kann skriptiert werden und wird in der SAA-C03-Prüfung als Migrationsszenario behandelt.

RAID 0 (Striping) verteilt Daten auf mehrere EBS-Volumes, um deren IOPS und Durchsatz zu aggregieren. Zwei gp3-Volumes mit jeweils 16.000 IOPS bieten in RAID 0 ungefähr 32.000 IOPS. Der Nachteil besteht darin, dass beim Ausfall eines der beiden Volumes alle Daten verloren gehen – es gibt keine Redundanz. RAID 0 eignet sich für temporäre oder einfach neu erstellbare Daten, bei denen maximaler Durchsatz Priorität hat, etwa für Cache-Schichten, Verarbeitungswarteschlangen oder temporären Speicherplatz. EBS-Snapshots des gesamten RAID-Arrays erfordern eine Koordination zur Sicherstellung der Konsistenz.

RAID 1 (Spiegelung) schreibt identische Daten gleichzeitig auf zwei EBS-Volumes. Wenn ein Volume ausfällt, enthält das andere eine vollständige Kopie. RAID 1 bietet die Redundanz von zwei Volumes, jedoch nur die Kapazität eines Volumes. Bei EBS-Volumes ist dies jedoch im Allgemeinen redundant zur integrierten AZ-weiten Replikation von EBS. AWS empfiehlt, statt RAID 1 auf EBS EBS-Architekturen über mehrere AZs zu verwenden (über Multi-AZ RDS oder eine ASG über mehrere AZs hinweg), da EBS bereits innerhalb einer AZ repliziert. RAID 1 auf EBS wird in modernen Architekturen selten eingesetzt.

Ein Amazon Machine Image (AMI) ist eine Vorlage zum Starten von EC2-Instances und wird durch einen oder mehrere EBS-Snapshots unterstützt – einen Snapshot pro im AMI enthaltenem Volume (typischerweise einen für das Root-Volume). Wenn Sie aus einer laufenden Instance ein benutzerdefiniertes AMI erstellen, stoppt AWS die Instance (oder verwendet unter Windows VSS), erstellt Snapshots aller verbundenen EBS-Volumes und hinterlegt die Zuordnung im AMI. Das Deregistrieren eines AMI löscht die zugehörigen Snapshots nicht automatisch – Sie müssen die Snapshots separat löschen, damit dafür keine weiteren Kosten anfallen.

Best Practices für Snapshots in Produktions-Workloads: Frieren Sie das Dateisystem ein oder versetzen Sie es in einen konsistenten Zustand, bevor Sie Datenbanken per Snapshot sichern, um Konsistenz zu gewährleisten (die meisten verwalteten Datenbanken wie RDS erledigen dies automatisch). Versehen Sie Snapshots mit Tags, die Umgebung, Volume-ID und Datum enthalten, damit Lebenszyklusverwaltung und Kostenzuordnung einfach möglich sind. Testen Sie Wiederherstellungsverfahren regelmäßig – ein Snapshot, aus dem Sie noch nie wiederhergestellt haben, ist kein Backup. Speichern Sie regionsübergreifende Kopien für Disaster Recovery. Verwenden Sie AWS Backup für eine zentrale Richtlinienverwaltung über EBS, RDS, DynamoDB und andere Services hinweg.

Die EBS Snapshot Recycle Bin schützt vor dem versehentlichen Löschen von Snapshots und AMIs. Wenn sie mit einer Aufbewahrungsregel aktiviert ist, werden gelöschte Snapshots in die Recycle Bin verschoben, anstatt dauerhaft gelöscht zu werden. Sie können sie während des Aufbewahrungszeitraums (1 Tag bis 1 Jahr) wiederherstellen. Dies ist besonders in Compliance-Szenarien wichtig, in denen Sie sich von der versehentlichen Löschung durch einen Administrator oder ein außer Kontrolle geratenes Automatisierungsskript erholen können müssen, ohne aus einer älteren Backup-Stufe wiederherzustellen.

Testen Sie Ihr Verständnis der AWS-Solutions-Architect-Konzepte (SAA-C03) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: EBS-Snapshots sind inkrementell und werden in S3 gespeichert, wobei DLM die automatisierte Lebenszyklusverwaltung übernimmt, für die Verschlüsselung ist ein Snapshot-Kopierworkflow erforderlich, um unverschlüsselte Volumes zu konvertieren, und RAID 0 verteilt Volumes zur Aggregation der Performance, während RAID 1 sie aus Redundanzgründen spiegelt (obwohl EBS bereits innerhalb einer AZ repliziert). Als Nächstes sehen wir uns EFS für gemeinsam genutzten Linux-Dateispeicher an.