EC2-Speicher: Instance Store vs. EBS

EC2-Instanzen können zwei Arten von lokalem Speicher verwenden: Instance Store und Amazon EBS (Elastic Block Store). Instance Store ist physisch am Hostserver angeschlossen und bietet sehr hohe IOPS und hohen Durchsatz, allerdings mit einem entscheidenden Nachteil: Die Daten gehen verloren, wenn die Instanz gestoppt oder beendet wird. EBS bietet persistenten, netzwerkbasierten Blockspeicher, der das Stoppen, Starten oder Beenden einer Instanz übersteht. Zu verstehen, wann welcher Speichertyp eingesetzt wird, ist ein wiederkehrendes Thema in der SAA-C03-Prüfung.

Instance Store (auch als flüchtiger Speicher bezeichnet) besteht aus NVMe-SSDs, die physisch an die Hardware des Hosts angeschlossen sind, auf der Ihre EC2-Instanz ausgeführt wird. Daten im Instance Store gehen verloren, sobald die Instanz gestoppt, in den Ruhezustand versetzt oder beendet wird oder wenn die zugrunde liegende Hardware ausfällt. Bei einem Neustart bleiben die Daten jedoch erhalten. Instance Store eignet sich ideal für Puffer-, Cache- und Scratch-Daten, temporäre Dateien sowie Daten, die über eine Flotte repliziert werden (z. B. Cassandra-Knoten). Nicht alle Instance Types enthalten Instance Store. Achten Sie auf das Suffix d (z. B. i3.xlarge, m5d.large).

Amazon EBS-Volumes sind netzwerkbasierte Speicher, die unabhängig vom Lebenszyklus der EC2-Instanz persistent bleiben. Ein EBS-Volume befindet sich in einer bestimmten Availability Zone und kann jeweils an eine EC2-Instanz angehängt werden (außer bei io1/io2 Multi-Attach). Wenn Sie eine Instanz stoppen und neu starten, bleiben alle Daten auf dem EBS-Volume erhalten. Sie können das Volume von einer Instanz trennen und in derselben AZ an eine andere Instanz anhängen oder einen Snapshot erstellen, um es in eine andere AZ oder Region zu kopieren.

AWS bietet vier EBS-Volume-Typen. gp3 (General Purpose SSD): Baseline von 3.000 IOPS und 125 MB/s, unabhängig konfigurierbar auf bis zu 16.000 IOPS und 1.000 MB/s – die Standardoption mit dem besten Preis-Leistungs-Verhältnis für die meisten Workloads. gp2: älteres General Purpose SSD, bei dem die IOPS mit der Größe skalieren (3 IOPS/GB, maximal 16.000) und das zugunsten von gp3 schrittweise abgelöst wird. io2 Block Express: Provisioned-IOPS-SSD mit bis zu 256.000 IOPS und 4.000 MB/s – für I/O-intensive Datenbanken wie SAP HANA oder Oracle. io1: veraltetes Provisioned-IOPS-SSD-Volume.

Die beiden HDD-basierten EBS-Typen sind auf Durchsatz und nicht auf IOPS optimiert. st1 (Throughput Optimised HDD): Baseline von 40 MB/s/TB, Burst bis zu 250 MB/s/TB – ideal für Big Data, Protokollverarbeitung und Data Warehouses mit großen sequenziellen Lesezugriffen. sc1 (Cold HDD): Baseline von 12 MB/s/TB, Burst bis zu 80 MB/s/TB – die kostengünstigste EBS-Option für sequenzielle Daten, auf die selten zugegriffen wird. HDD-Volumes können nicht als Boot-Volumes (Root-Gerät) verwendet werden. Wählen Sie st1 oder sc1 nur dann, wenn der Durchsatz wichtiger ist als die IOPS und das Zugriffsmuster aus großen sequenziellen Lese- und Schreibvorgängen besteht.

EBS-Snapshots sind zeitpunktbezogene Backups eines Volumes, die dauerhaft in Amazon S3 gespeichert werden (Sie greifen jedoch über die EC2-API und nicht direkt über S3 darauf zu). Snapshots sind inkrementell: Der erste Snapshot erfasst das vollständige Volume, während nachfolgende Snapshots nur die Blöcke aufzeichnen, die seit dem letzten Snapshot geändert wurden. Dadurch werden die Speicherkosten reduziert. Sie können aus jedem Snapshot in jeder AZ innerhalb derselben Region ein neues EBS-Volume erstellen oder den Snapshot für die regionsübergreifende Notfallwiederherstellung in eine andere Region kopieren.

EBS-Volumes und Snapshots können mit AWS-KMS-Schlüsseln verschlüsselt werden. Die Verschlüsselung erfolgt für die Instance transparent: Daten werden bei der Übertragung zwischen Instance und Volume sowie im Ruhezustand auf dem Speicher verschlüsselt. Sie können die standardmäßige Verschlüsselung auf Kontoebene aktivieren, sodass jedes neue EBS-Volume, das im Konto erstellt wird, automatisch verschlüsselt wird, ohne dass dies für jedes Volume einzeln konfiguriert werden muss. Um ein unverschlüsseltes Volume zu verschlüsseln, müssen Sie einen Snapshot erstellen, eine verschlüsselte Kopie des Snapshots anlegen und anschließend aus dem verschlüsselten Snapshot ein neues Volume erstellen.

EBS Multi-Attach ermöglicht es, ein io1- oder io2-Volume gleichzeitig mit bis zu 16 EC2-Instances zu verbinden, die sich in derselben Availability Zone befinden. Alle verbundenen Instances verfügen über vollständigen Lese- und Schreibzugriff. Dies wird für geclusterte Linux-Anwendungen wie Oracle RAC oder Teradata verwendet, die die Nebenläufigkeit auf Anwendungsebene mithilfe eines clusterfähigen Dateisystems verwalten. Multi-Attach ist kein Ersatz für EFS als gemeinsam genutztes Dateisystem, sondern speziell für den clusterfähigen Zugriff auf Blockebene mit von der Anwendung verwalteter Koordination vorgesehen.

Wichtige Entscheidungskriterien: Ist Persistenz erforderlich? → Verwenden Sie EBS. Können die Daten neu erstellt werden oder sind sie repliziert? → Der Instance Store ist geeignet und bietet eine höhere Leistung. Handelt es sich um eine Datenbank mit kritischen Daten? → Verwenden Sie immer EBS (mit Snapshots und Verschlüsselung). Benötigen Sie temporären Speicherplatz für ML-Training oder Sortiervorgänge? → Verwenden Sie den Instance Store für maximalen Durchsatz ohne zusätzliche Kosten. In der Prüfung werden häufig Szenarien vorgestellt, in denen Sie bestimmen müssen, ob für einen bestimmten Workload flüchtiger oder persistenter Speicher geeignet ist.

EBS-optimierte Instances stellen eine dedizierte Netzwerkbandbreite zwischen der EC2-Instance und EBS bereit, die von der allgemeinen Netzwerkbandbreite der Instance getrennt ist. Dadurch wird eine Konkurrenz um Netzwerkressourcen zwischen Anwendungsdatenverkehr und Storage-I/O verhindert. Die meisten Instance-Typen der aktuellen Generation sind standardmäßig und ohne zusätzliche Kosten EBS-optimiert. Bei älteren Instance-Typen muss die EBS-Optimierung möglicherweise manuell aktiviert werden (gegen eine zusätzliche Gebühr pro Stunde). Bei Datenbank-Workloads mit hohem I/O sollten Sie immer überprüfen, ob Ihr Instance-Typ EBS-optimiert ist, damit die vollständig für Ihr Volume bereitgestellten IOPS erreicht werden.

Amazon Data Lifecycle Manager (DLM) automatisiert die Erstellung, Aufbewahrung und Löschung von EBS-Snapshots und AMIs. Sie definieren Lebenszyklusrichtlinien, in denen festgelegt wird, welche Volumes gesichert werden (nach Tag), wie häufig Snapshots erstellt werden (alle 1, 2, 3, 4, 6, 8 oder 12 Stunden oder täglich) und wie viele Snapshots aufbewahrt werden. DLM macht benutzerdefinierte Backup-Skripte überflüssig und lässt sich zur Überwachung des Richtlinienstatus in CloudWatch integrieren. Für regionsübergreifende Snapshots konfigurieren Sie eine Kopierrichtlinie in derselben DLM-Definition.

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

In dieser Lektion haben Sie gelernt: Der Instance Store bietet die höchste lokale I/O-Leistung, ist jedoch flüchtig – Daten gehen beim Stoppen oder Beenden verloren, EBS stellt persistenten, netzwerkgebundenen Blockspeicher mit vier Volume-Typen bereit, die entweder auf IOPS (gp3, io2) oder auf Durchsatz (st1, sc1) optimiert sind, und EBS-Snapshots ermöglichen zeitpunktbezogene Backups, die in S3 gespeichert werden und für die Wiederherstellung über AZ- oder Regionsgrenzen hinweg verwendet werden können. Als Nächstes befassen wir uns mit den Grundlagen des S3-Objektspeichers.