Amazon EBS – Häufig gestellte Fragen

F: Ändern sich Amazon EBS Volume und Snapshot ID-Längen im Jahr 2018?

Ja, besuchen Sie die Seite Häufig gestellte Fragen zu EC2, um weitere Informationen zu erhalten.

F: Was geschieht mit meinen Daten, wenn eine Amazon EC2-Instance beendet wird?

Im Gegensatz zu Daten, die in einem lokalen Instance-Speicher gespeichert werden (der nur so lange erhalten bleibt, wie die Instance aktiv ist), können Daten auf einem Amazon EBS-Volume unabhängig von der Nutzungsdauer der Instance dauerhaft gespeichert werden. Daher empfehlen wir, den lokalen Instanzspeicher nur für temporäre Daten zu verwenden. Für Daten, die eine höhere Haltbarkeit erfordern, empfehlen wir, Amazon EBS-Volumes zu verwenden oder die Daten auf Amazon S3 zu sichern. Wenn Sie ein Amazon EBS-Volume als Stammpartition verwenden, müssen Sie das Kennzeichen Delete on termination auf "No" setzen, wenn Ihr Amazon EBS-Volume über die Nutzungsdauer der Instance hinaus bestehen bleiben soll.

F: Welche Leistung kann ich von Amazon EBS-Volumes erwarten?

Amazon EBS bietet sieben Volume-Typen: bereitgestellte IOPS-SSD (io2 Block Express, io2 und io1), Standard-SSD (gp3 und gp2), durchsatzoptimierte HDD (st1) und selten genutzte (cold) HDD (sc1). Diese Volume-Typen unterscheiden sich bei den Leistungsmerkmalen und im Preis, sodass Sie die Speicherleistung und -kosten an die Anforderungen Ihrer Anwendungen anpassen können. Die durchschnittliche Latenz zwischen EC2-Instances und EBS liegt im einstelligen Millisekundenbereich. Weitere Informationen zur Leistung finden Sie auf der Seite mit den EBS-Produktdetails. Weitere Informationen zu Leistungsrichtlinien für Amazon EBS finden Sie unter Steigerung der EBS-Leistung.

F: Welches Volume sollte ich wählen?

Amazon EBS umfasst zwei Hauptspeicherkategorien: SSD-basierten Speicher für transaktionsintensive Arbeitslasten (Leistung primär von IOPS, Latenz und Zuverlässigkeit abhängig) und HDD-basiertem Speicher für durchsatzintensive Arbeitslasten (Leistung primär von Durchsatzleistung in MB/s abhängig). SSD-basierte Volumes eignen sich für transaktions- und IOPS-intensive Datenbank-Workloads, Start-Volumes und Workloads, die einen hohen IOPS-Wert erfordern. Zu den SSD-basierten Volumes gehören bereitgestellte IOPS-SSD (io1 und io2) und Standard-SSD (gp3 und gp2). io2 und io2 Block Express der bereitgestellten IOPS-SSD-Volumes sind für eine 100-mal höhere Zuverlässigkeit von 99,999 % ausgelegt und dadurch ideal für geschäftskritische Anwendungen geeignet, die eine höhere Betriebszeit benötigen. gp3 ist die neueste Generation der Standard-SSD-Volumes, die das richtige Gleichgewicht von Preis und Leistung für die meisten Anwendungen bieten, die nicht die höchste IOPS-Leistung oder eine Zuverlässigkeit von 99,999 % benötigen. HDD-basierte Volumes eignen sich für durchsatzintensive und Big-Data-Workloads, umfangreiche I/O-Größen und sequenzielle I/O-Muster. HDD-basierte Volumes umfassen eine durchsatzoptimierte HDD (st1) und eine selten genutzte (cold) HDD (sc1).

F: Sollte ich Snapshots machen und planen, io2-Volumes über Availability Zones (AZs) hinweg zu replizieren, um eine hohe Zuverlässigkeit zu erreichen, trotzdem io2 eine höhere Zuverlässigkeit bietet?

Eine hohe Volume-Zuverlässigkeit, Snapshots und das Replizieren von Volumes über AZs hinweg schützen vor verschiedenen Ausfallmöglichkeiten und Kunden können je nach ihren Anforderungen an die Lebensdauer von Daten zwischen einem, zwei oder allen dieser Ansätze wählen. Eine höhere Volume-Zuverlässigkeit verringert die Wahrscheinlichkeit, die primäre Kopie Ihrer Daten zu verlieren. Snapshots schützen vor dem unwahrscheinlichen Fall eines Volume-Ausfalls. Das Replizieren von Volumes über AZs hinweg schützt vor einem Ausfall auf AZ-Ebene und bietet im Falle eines Ausfalls eine schnellere Möglichkeit zur Wiederherstellung.

F: Wie kann ich die Kapazität, Leistung oder den Typ eines vorhandenen EBS-Volumes ändern?

Das Ändern einer Volume-Konfiguration ist einfach. Die Elastic Volumes-Funktion ermöglicht Ihnen das Erhöhen der Kapazität, das Optimieren der Leistung oder das Ändern des Volume-Typs mit einem einzigen CLI-Aufruf, API-Aufruf oder wenigen Klicks in der Konsole.  Weitere Informationen zu Elastic Volumes finden Sie in der Elastic Volumes-Dokumentation.

F: Sind die bisherigen EBS-Standard-Volumes noch erhältlich?

Die bisherigen EBS-Standard-Volumes wurden umbenannt zu EBS-Magnetfestplatten-Volumes. Vorhandene Volumes werden davon nicht betroffen und es gibt keine funktionellen Unterschiede zwischen EBS-Magnetfestplatten-Volumes und EBS-Standard-Volumes. Der Name dieses Angebots wurde geändert, um Verwechslungen mit dem von uns empfohlenen Standard-SSD-Volume-Typ (gp2) zu vermeiden.

F: Sind bereitgestellte IOPS-SSD-Volumes (io2 Block Express, io2 und io1) für alle Amazon-EC2-Instance-Typen verfügbar?

Bereitgestellte IOPS-SSD-io1-Volumes sind für alle Amazon-EC2-Instance-Typen verfügbar und bereitgestellte IOPS-SSD-io2-Volumes sind für alle EC2-Instance-Typen verfügbar – mit Ausnahme von R5b. io2-Block-Express-Volumes können aktuell nur auf R5b-Instances verwendet werden. Verwenden Sie EBS-optimierte EC2-Instances, um konsistente und vorhersehbare IOPS auf io2- und io1-Volumes zu liefern. EBS-optimierte Instances liefern zwischen Amazon EC2 und Amazon EBS je nach verwendetem Instance-Typ einen dedizierten Durchsatz von 62,5 MB/s bis 7 500 MB/s. Um die Grenze von 64.000 E/A\Sek. und 1.000 MB/s Durchsatz zu erreichen, muss das Volume an eine Nitro System-basierte EC2-Instance angeschlossen werden.

F: Welchen Grad an Leistungsbeständigkeit kann ich von meinen bereitgestellten IOPS-SSD-Volumes (io2 und io1) erwarten?

Bei einer Anbindung an EBS-optimierte Instances können bereitgestellte IOPS-SSD-Volumes (io2 und io1) im jeweiligen Jahr 99,9 % der Zeit die von ihnen erwartete E/A\Sek.-Leistung innerhalb einer Toleranz von 10 % liefern. Die exakte Leistung hängt von den E/A-Anforderungen Ihrer Anwendung ab.

F: Welchen Grad an Leistungslatenz kann ich von meinen bereitgestellten IOPS-SSD-Volumes (io2 und io1) erwarten?

Bei Zuweisung zu für EBS optimierten Instances können bereitgestellte E/A\Sek.-Volumes Latenzen im einstelligen Millisekundenbereich erreichen. Die exakte Leistung hängt von den E/A-Anforderungen Ihrer Anwendung ab.

F: Beeinflusst die E/A-Größe der Lese- und Schreibvorgänge meiner Anwendung die E/A\Sek.-Rate, die ich von meinen bereitgestellten E/A\Sek.-SSD-Volumes (io2 und io1) erhalte?

Ja, das ist der Fall. Wenn Sie IOPS für io2- oder io1-Volumes bereitstellen, hängt die erhaltene E/A\Sek.-Rate von der E/A-Größe der Lese- und Schreibvorgänge Ihrer Anwendung ab. Bereitgestellte IOPS-Volumes haben eine Basis-E/A-Größe von 16 KB. Wenn Sie also ein Volume mit 40.000 E/A\Sek. für eine E/A-Größe von 16 KB bereitgestellt haben, werden bei dieser Größe bis zu 40.000 E/A\Sek. erreicht. Wenn die E/A-Größe auf 32 KB erhöht wird, dann erreichen Sie bis zu 20.000 IOPS und so weiter. Weitere Informationen erhalten Sie in der technischen Dokumentation zu bereitgestellten IOPS-Volumes. Sie können Amazon CloudWatch verwenden, um den Durchsatz und die E/A-Größen zu überwachen.

F: Welche Faktoren können sich auf die Leistungsbeständigkeit meiner bereitgestellten E/A\Sek.-SSD-Volumes (io2 und io1) auswirken?

Bereitgestellte IOPS-SSD-Volumes (io2 und io1), die EBS-optimierten Instances zugeordnet werden, sind auf eine konsistente Leistung ausgelegt und liefern im jeweiligen Jahr 99,9 % der Zeit die von ihnen bereitgestellte IOPS-Leistung innerhalb einer Toleranz von 10 %. Für maximale Leistungskonsistenz bei neuen Volumes, die aus einem Snapshot erstellt wurden, empfehlen wir, Fast Snapshot Restore (FSR) in Ihren Snapshots zu aktivieren. EBS-Volumes, die aus für FSR aktivierte Snapshots wiederhergestellt wurden, erhalten unverzüglich ihre volle Leistung.

Ein weiterer Faktor, der die Leistung beeinträchtigen kann, entsteht, wenn Ihre Anwendung nicht genügend E/A-Anforderungen sendet. Dies können Sie überwachen, indem Sie die Warteschlangentiefe Ihres Volumes betrachten. Die Warteschlangentiefe ist die Anzahl der ausstehenden E/A-Anfragen von Ihrer Anwendung an Ihr Volume. Für maximale Beständigkeit muss ein bereitgestelltes IOPS-Volume eine durchschnittliche Warteschlangentiefe von eins für je 1000 bereitgestellte IOPS in einer Minute beibehalten. Beispielsweise muss für ein Volume, das mit 3000 E/A pro Sekunde bereitgestellt wird, die durchschnittliche Warteschlangentiefe drei sein. Weitere Informationen zum Sicherstellen der konsistenten Leistung Ihrer Volumes finden Sie unter Increasing EBS Performance.

F: Welchen Grad an Leistungsbeständigkeit kann ich von meinen HDD-basierten Volumes erwarten?

Bei einer Anbindung an EBS-optimierte Instances können durchsatzoptimierte HDD-Volumes (st1) und selten genutzte (cold) HDD-Volumes (sc1) im jeweiligen Jahr 99 % der Zeit die von ihnen erwartete Durchsatzleistung innerhalb einer Toleranz von 10 % liefern. Die genaue Leistung hängt von den E/A-Anforderungen Ihrer Anwendung und der Leistung Ihrer EC2-Instance ab.

F: Beeinflusst die E/A-Größe der Lese- und Schreibvorgänge meiner Anwendung die Durchsatzrate, die ich von meinen HDD-basierten Volumes erhalte?

Ja. Die Durchsatzrate richtet sich nach der E/A-Größe der Lese- und Schreibvorgänge Ihrer Anwendung. HDD-basierte Volumes verarbeiten Lese- und Schreibvorgänge in E/A-Größen von 1 MB. Sequenzielle E/As werden zu 1-MB-Einheiten zusammengeführt und verarbeitet, wobei jeder nicht sequenzielle E/A auch dann als 1 MB verarbeitet wird, wenn seine tatsächliche E/A-Größe kleiner ist. Während somit eine Transaktionsarbeitslast mit kleinen, nach dem Zufallsprinzip ausgeführten E/As (z. B. bei eine Datenbank) auf HDD-basierten Volumes eine geringe Leistung erzielt, erreichen sequenzielle E/As und umfangreiche E/A-Größen die angekündigte Leistung von st1 und sc1 über einen längeren Zeitraum.

F: Welche Faktoren können die Leistungsbeständigkeit meiner HDD-basierten Volumes beeinträchtigen?

Durchsatzoptimierte HDD-Volumes (st1) und selten genutzte (cold) HDD-Volumes (sc1), die an EBS-optimierte Instances angebunden sind, bieten im jeweiligen Jahr 99 % der Zeit die von ihnen erwartete Durchsatzleistung innerhalb einer Toleranz von 10 %. Mehrere Faktoren können sich auf den Grad der Beständigkeit, den Sie erhalten, auswirken. So kann beispielsweise die relative Ausgewogenheit zwischen den nach dem Zufallsprinzip durchgeführten und sequenziellen E/A-Vorgängen auf dem Volume die Leistung beeinflussen. Zu viele kleine, nach dem Zufallsprinzip ausgeführte E/A-Verfahren brauchen rasch Ihre E/A-Guthaben auf, wodurch sich die Leistung auf die Basisrate reduziert. Auch die Durchsatzrate kann je nach ausgewählter Instance verringern. Obgleich st1 den Durchsatz auf 500 MB/s steigern kann, wird die Leistung durch die separate Begrenzung auf Instance-Ebene für den EBS-Datenverkehr eingeschränkt. Ein weiterer Faktor ist das Erstellen eines Snapshot, wodurch sich die erwartete Schreibleistung bis zu dessen Fertigstellung auf die Basisrate reduziert. Dies gilt speziell für st1 und sc1.

Die Leistung kann auch beeinträchtigt werden, wenn die Anwendung eine entsprechend hohe Anzahl von E/A-Anforderungen sendet. Dies kann anhand der Warteschlangentiefe und der E/A-Größe des Volumes überwacht werden. Die Warteschlangentiefe ist die Anzahl der ausstehenden E/A-Anfragen von Ihrer Anwendung an Ihr Volume. Für eine maximale Konsistenz müssen HDD-unterstützte Volumes eine durchschnittliche Warteschlangentiefe (auf die nächste ganze Zahl gerundet) von vier oder mehr für jeden 1 MB sequenziellen E / A beibehalten. Weitere Informationen zum Sicherstellen der konsistenten Leistung Ihrer Volumes finden Sie unter Increasing EBS Performance.

F: Kann ich mehrere Volumes mithilfe von Stripes verbinden, um die Leistung zu verbessern?

Ja. Sie können bei einer Anbindung an größere EC2-Instances mehrere Volumes mithilfe von Stripes verbinden, um bis zu 260 000 E/A\Sek. oder 60,000 MB/s (oder 7500 MB/s) zu erreichen. Die Leistung für st1 und sc1 wird jedoch linear mit der Volume-Größe skaliert, sodass ein Verbinden dieser Volumes mit Stripes möglicherweise nur von geringem Nutzen ist.

F: Wie löst Amazon EBS Probleme wie Speicherkonflikte?

EBS ist ein Mehrmandanten-Blockspeicher-Service. Wir vermeiden Ressourcenkonflikte mittels Ratenbeschränkung. Die Grundlage dafür sind genau definierte Leistungskriterien für die Volumes – all unsere Volume-Typen (gp2, PIOPS, st1 und sc1) besitzen definierte Leistungsmerkmale bezüglich IOPS und Durchsatz. Der nächste Schritt ist das Festlegen der Leistung auf Instance-Ebene. Jede EBS-optimierte Instance verfügt über eine definierte Leistung (Durchsatz sowie IOPS) für den EBS-Volume-Satz, der mit der Instance verknüpft ist. Ein Kunde kann so die Größen von Instances und Volumes festlegen, um die gewünschte Leistung zu erhalten. Zudem können Kunden unsere berichteten Metriken verwenden, um die Leistung auf Instance- und Volume-Ebene zu überwachen. Sie können Alarme festlegen, um festzustellen, ob die vorliegende Leistung mit der erwarteten Leistung übereinstimmt. Mit den Metriken können Kunden auch feststellen, ob sie den richtigen Instance-Typ mit einer geeigneten Leistung auf Volume-Ebene verwenden. Auf EBS-Seite verwenden wir die konfigurierte Leistung, um darüber zu informieren, wie wir die geeignete Instance und EBS-Infrastruktur zuweisen, um die Volumes zu unterstützen. Durch eine geeignete Infrastruktur-Zuweisung verhindern wir Ressourcenkonflikte. Zudem überwachen wir unsere Infrastruktur kontinuierlich. Durch diese Überwachung können wir Infrastrukturausfälle (oder drohende Ausfälle) erkennen und die Volumes proaktiv auf funktionierende Hardware auslagern, während die problematische Infrastruktur nach Bedarf repariert oder ausgetauscht wird.

F: Welchen Grad an Leistungsbeständigkeit kann ich von meinen Standard-SSD-Volumes (gp3 und gp2) erwarten?

Bei einer Anbindung an EBS-optimierte Instances können Standard-SSD-Volumes (gp3 und gp2) im jeweiligen Jahr 99 % der Zeit weniger als 10 % der bereitgestellten IOPS-Leistung liefern. Die exakte Leistung hängt von den E/A-Anforderungen Ihrer Anwendung ab.

F: Welchen Grad an Leistungslatenz kann ich von meinen Standard-SSD-Volumes (gp3 und gp2) erwarten?

Bei einer Anbindung an EBS-optimierte Instances können Standard-SSD-Volumes (gp3 und gp2) Latenzen im einstelligen Millisekundenbereich erreichen. Die exakte Leistung hängt von den E/A-Anforderungen Ihrer Anwendung ab.

F: Verfügen Standard-SSD-(gp3)-Volumes über Burst?

Nein. Alle Standard-SSD-(gp3)-Volumes beinhalten 3 000 IOPS und 125 MB/s konstante Leistung ohne zusätzliche Kosten. Volumes können die vollen 3 000 IOPS und 125 MB/s auf unbestimmte Zeit halten.

F: Wie funktioniert Burst auf Standard-SSD-(gp2)-Volumes?

Standard-SSD-(gp2)-Volumes, die unter 1 000 GB groß sind, erhalten eine Burst-IOPS-Leistung von bis zu 3 000 IOPS für mindestens 30 Minuten Dauerleistung. Zusätzlich liefern gp2-Volumes eine konstante Leistung von 3 IOPS pro bereitgestelltem GB. Ein 500-GB-Volume ist beispielsweise in der Lage, konstant 1 500 IOPS zu fahren und 60 Minuten lang auf 3 000 IOPS zu beschleunigen (3 000 IOPS * 60 Sekunden * 30 Minuten / 1 500 IOPS / 60 Sekunden).

F: Was ist der Unterschied zwischen io2 und io2 Block Express?

io2-Volumes bieten leistungsstarken Blockspeicher für alle EC2-Instances. Für Anwendungen mit noch höheren Leistungsanforderungen können Sie io2-Volumes an R5b-Instance-Typen anfügen, die auf Block Express betrieben werden und eine 4-mal höhere Leistung als io2 liefern. Damit können Sie mit einem einzigen io2-Volume eine Kapazität von bis zu 64 TiB, 256 000 IOPS und einen Durchsatz von 4 000 MB/s erreichen, und das bei einer durchschnittlichen I/O-Latenz von unter einer Millisekunde.

F: Was ist EBS Block Express?

EBS Block Express ist die nächste Generation von Amazon-EBS-Speicher-Serverarchitektur, speziell entwickelt zur Bereitstellung des höchsten Grads an Leistunglatenz unterhalb von Millisekunden für Blockspeicher im Cloud-Maßstab. Block Express erreicht dies durch die Verwendung von Scalable Reliable Datagrams (SRD), einem hochleistungsfähigen Netzwerkprotokoll mit geringerer Latenz, um mit Nitro-System-basierten EC2-Instances zu kommunizieren. Dies ist dieselbe Netzwerkschnittstelle mit hoher Leistung und niedriger Latenz, die für die Kommunikation zwischen Instances im Elastic Fabric Adapter (EFA) für High Performance Computing (HPC) und Machine Learning (ML)-Workloads verwendet wird. Darüber hinaus bietet Block Express modulare Software- und Hardwarebausteine, die auf viele verschiedene Arten zusammengesetzt werden können, was uns die Flexibilität gibt, verbesserte Leistung und neue Funktionen schneller zu entwickeln und bereitzustellen.

F: Welche Workloads sind für io2 Block Express geeignet?

io2 Block Express eignet sich für leistungs- und kapazitätsintensive Workloads, die von einer geringeren Latenz, höheren IOPS, einem höheren Durchsatz oder einer größeren Kapazität in einem einzigen Volume profitieren. Zu diesen Workloads gehören relationale und NoSQL-Datenbanken wie SAP HANA, Oracle, MS SQL, PostgreSQL, MySQL, MongoDB, Cassandra sowie geschäftskritische Workloads wie SAP Business Suite, NetWeaver, Oracle eBusiness, PeopleSoft, Siebel und ERP-Workloads wie Infor LN und Infor M3.

F: Woher weiß ich, ob ein io2-Volume auf Block Express betrieben wird?

Wenn ein io2-Volume an eine R5b-Instance angefügt ist, wird sie auf Block Express betrieben, was Latenzen von unter einer Millisekunde und bis zu 256 000 IOPS, 4 000 MB/s Durchsatz und 64 TiB Kapazität für ein einziges Volume ermöglicht. An andere Instances angebundene io2-Volumes werden nicht auf Block Express betrieben. Sie bieten Latenzen im einstelligen Millisekundenbereich und bis zu 64 000 IOPS, 1 GB/s Durchsatz und 16 TiB Kapazität für ein einziges Volume.

F: Wie kann ich EBS direct APIs for Snapshots verwenden?

Diese Funktion kann über die folgenden APIs verwendet werden, die mit AWS CLI oder über AWS SDK aufgerufen werden können.

• List Snapshot Blocks: Die ListSnapshotBlocks-API-Operation gibt die Blockindizes und Blocktoken für Blöcke im angegebenen Snapshot zurück.
  
• List Changed Blocks: Die ListChangedBlocks-API-Operation gibt die Blockindizes und Blocktoken für Blöcke zurück, die sich zwischen zwei angegebenen Snapshots derselben Volume-/Snapshot-Linie unterscheiden.
  
• Get Snapshot Blocks: Der GetSnapshotBlock-API-Prozess gibt die Daten in einem Block für die angegebene Snapshot-ID, den Blockindex und das Blocktoken zurück.
  
• Start Snapshot: Der StartSnapshot-Prozess startet einen Snapshot, entweder als inkrementeller Snapshot eines vorhandenen oder als neuer Snapshot. Der gestartete Snapshot verbleibt im Status „Ausstehend“, bis er mit der Aktion „CompleteSnapshot“ abgeschlossen wird.
• Put Snapshot Block: Der PutSnapshot-Prozess fügt Daten in Form einzelner Blöcke zu einem gestarteten Snapshot hinzu, der sich im Status „Ausstehend“ befindet. Sie müssen eine Base64-kodierte SHA256-Prüfsumme für den übertragenen Datenblock angeben. Der Service validiert die Prüfsumme nach Abschluss der Übertragung. Die Anfrage schlägt fehl, wenn die vom Service berechnete Prüfsumme nicht mit dem übereinstimmt, was Sie angegeben haben.
• Complete Snapshot: Der CompleteSnapshot-Prozess schließt einen gestarteten Snapshot ab, der sich im Status „Ausstehend“ befindet. Der Status des Snapshot wird dann in „Abgeschlossen“ geändert.

F: Welche Blockgrößen werden von den GetSnapshotBlock- und PutSnapshotBlock-APIs unterstützt?

Die GetSnapshotBlock- und PutSnapshotBlock-APIs unterstützen eine Blockgröße von 512 KiB.

F: Kann ich mit der normalen Amazon S3-API auf meine Snapshots zugreifen?

Nein, Snapshots sind nur über die Amazon EC2-API verfügbar.

F: Muss die Zuweisung von Volumes aufgehoben werden, damit ein Snapshot erstellt werden kann?

Nein, Snapshots können in Echtzeit erstellt werden, während das Volume bereitgestellt ist und verwendet wird. Snapshots erfassen jedoch nur Daten, die auf Ihren Amazon EBS-Datenträger geschrieben wurden. Darin sind möglicherweise nicht die Daten enthalten, die lokal von Ihrer Anwendung oder dem Betriebssystem in den Zwischenspeicher geschrieben wurden. Um die einheitliche Erstellung von Snapshots auf Datenträgern sicherzustellen, die einer Instance zugeordnet sind, wird empfohlen, die Zuordnung des Volumes sauber zu trennen, den Snapshot-Befehl auszuführen und anschließend das Volume erneut zuzuordnen. Bei Amazon EBS-Datenträgern, die als Root-Geräte dienen, wird empfohlen, den Rechner herunterzufahren, um einen sauberen Snapshot zu erstellen.

F: Dauert die Anfertigung eines Snapshots eines kompletten 16 TB-Volumes länger als die eines kompletten 1 TB-Volumes?

Nein, ein EBS-Snapshot eines kompletten 16 TB-Volumes dauert nicht länger als die eines kompletten 1 TB-Volumes. Die tatsächliche Zeit zum Erstellen eines Snapshots hängt allerdings von mehreren Faktoren ab, darunter auch die Menge der Daten, die seit dem letzten Snapshot des EBS-Volumes geändert wurden.

F: Gibt es verschiedene Versionen von Snapshots? Kann ich einen älteren Snapshot einlesen, um eine zeitpunktbezogene Wiederherstellung durchzuführen?

Jeder Snapshot verfügt über eine eindeutige Kennzeichnung. Volumes können auf Grundlage eines beliebigen vorhandenen Snapshots erstellt werden.

F: Wie finde ich Amazon EBS-Snapshots, die für mich freigegeben wurden?

Sie finden für Sie freigegebene Snapshots, indem Sie im Abschnitt "Snapshots" der AWS Management Console den Listeneintrag "Private Snapshots" auswählen. In diesem Abschnitt werden sowohl Ihre eigenen Snapshots als auch für Sie freigegebene Snapshots aufgeführt.

F: Wie finde ich heraus, welche Amazon EBS-Snapshots global freigegeben sind?

Sie können global freigegebene Snapshots finden, indem Sie über die AWS Management Console im Abschnitt "Snapshots" den Listeneintrag "Public Snapshots" auswählen.

F: Wie finde ich eine Liste der öffentlichen Amazon-Datensätze, die in Amazon EBS-Snapshots gespeichert sind?

Sie können die AWS Management Console verwenden, um öffentliche Datensätze zu finden, die als Amazon-Snapshots gespeichert sind. Melden Sie sich an der Konsole an, wählen Sie den Amazon EC2-Service aus, wählen Sie "Snapshots" aus und filtern Sie dann nach Public Snapshots. Alle Informationen zu öffentlichen Datensätzen sind in unserem AWS Public Datasets-Ressourcencenter verfügbar.

F: Wann sollte ich Fast Snapshot Restore (FSR) benutzen?

Sie sollten FSR auf Snapshots aktivieren, wenn Sie sich um die Latenz des Datenzugriffs beim Wiederherstellen von Daten aus einem Snapshot zu einer Volume Gedanken machen und die anfänglichen Leistungseinbußen während der Initialisierung vermeiden möchten. FSR ist dazu gedacht, bei Anwendungsfällen wie virtuelle Desktopinfrastruktur (VDI), Sicherung und Wiederherstellung, Test-/Entwicklungsvolume-Kopien und dem Starten von benutzerdefinierten AMIs zu helfen. Mit der Aktivierung von FSR auf Ihrem Snapshot wird Ihnen eine verbesserte und voraussehbare Leistung auffallen, wann immer Sie Daten aus einem Snapshot wiederherstellen müssen.

F: Beschleunigt die Aktivierung von FSR für meinen Snapshot die Erstellung von Snapshots?

Nein. FSR-aktivierte Snapshots verbessern die Wiederherstellung von Sicherungsdaten aus Ihrem Snapshot zu Ihren Volumes. FSR-aktivierte Snapshots beschleunigen jedoch nicht die Erstellungszeit von Snapshots.

F: Wie aktiviere ich Fast Snapshot Restore (FSR)?

Um diese Funktion zu nutzen, rufen Sie die neue "enable-fast-snapshot-restores-API" auf einem Snapshot in der Availability Zone (AZ), in der die initialisierten Volumes wiederhergestellt werden sollen, auf.

Der FSR-aktivierte Snapshot kann sich in einem der folgenden Zustände befinden: aktivieren, optimieren, aktiviert, deaktivieren, deaktiviert. Zustandsübergänge werden als CloudWatch Events veröffentlicht und der FSR-Zustand kann über die API "describe-fast-snapshot-restores" überprüft werden.

Die Aktivierung von FSR auf einem Snapshot verändert bestehende Interaktionen von Snapshot und API nicht und bestehende Workflows brauchen nicht geändert zu werden. FSR kann nur auf Snapshots, die einem Konto gehören, aktiviert oder deaktiviert werden. FSR kann nicht auf gemeinsame Snapshots angewendet werden. Sie können sich eine Liste Ihrer FSR-aktivierten Snapshots über API oder der Konsole ansehen.

F: Wie benutze ich Fast Snapshot Restore (FSR)?

Um Ihre Kredit-Bucketgröße und -Auffüllrate abzuschätzen, teilen Sie 1,024 durch Ihre Snapshotgröße. Zum Beispiel würde ein FSR-aktivierter Snapshot mit 100 GiB ein maximales Guthaben von 10 Krediten haben, mit einer Füllrate von 10 Krediten pro Stunden. Ein 4-TB-Snapshot hat ein maximales Guthaben von eins mit einer Füllrate von einem Punkt alle vier Stunden.

1. Ein erstellter Vorgang einer einzigen Volume verbraucht einen einzigen Kredit
2. Die Anzahl der Kredite ist eine Funktion der FSR-aktivierten Snapshotgröße
3. Kredite füllen sich mit der Zeit wieder auf
4. Die Maximalgröße eines Kredit-Buckets beträgt 10

Um Ihre Kredit-Bucketgröße und -Auffüllrate abzuschätzen, teilen Sie 1,024 durch Ihre Snapshotgröße. Zum Beispiel würde ein FSR-aktivierter Snapshot mit 100 GiB ein maximales Guthaben von 10 Krediten haben, mit einer Füllrate von 10 Krediten pro Stunden. Ein Snapshot mit 4 TiB würde ein maximales Guthaben von 1 mit einer Füllrate von einem Kredit alle 4 Stunden haben.

Es ist wichtig, sich darüber im Klaren zu sein, dass die Kredit-Bucketgröße eine Funktion der FSR-aktivierten Snapshotgröße ist und nicht die Größe der erstellten Volumes. Zum Beispiel ist es möglich, gleichzeitig zehn Volumes mit 1 TB aus einem Snapshot mit 100 GiB zu erstellen.

Außerdem hat jede AZ, in welcher der Snapshot FSR-aktiviert ist, unabhängig von anderen AZs ihren eigenen Kredit-Bucket.

F: Wie viele gleichzeitige Volumes kann ich erstellen und was passiert, wenn ich dieses Limit überschreite?

Die Größe des Erstellungs-Kredit-Buckets repräsentiert die Maximalanzahl und das Guthaben des Kredit-Buckets, welcher die Anzahl der verfügbaren Erstellungen repräsentiert. Bis zu 10 initialisierte Volumes können gleichzeitig von einem FSR-aktivierten Snapshot erstellt werden, sofern aufgefüllt. Sowohl die Maximalgröße und das Guthaben des Kredit-Buckets werden als CloudWatch-Metriken veröffentlicht. Erstellungen von Volumes über dieses Limit hinaus werden so behandelt, als sei FSR nicht auf dem Snapshot aktiviert.

F: Wie weiß ich, wenn eine Volume aus einem FSR-aktivierten Snapshot erstellt wurde?

Wenn FSR verwendet wird, wird ein neues EBS-spezifisches Attribut (fastRestored) zu der DescribeVolumes-API hinzugefügt, um auf den Status beim Zeitpunkt der Erstellung hinzudeuten. Wenn eine Volume aus einem FSR-aktivierten Snapshot ohne genügend Volume-Erstellungs-Kredite erstellt wird, wird zwar die Erstellung erfolgreich sein, die Volume jedoch nicht initialisiert werden.

Was passiert mit dem FSR, wenn ich einen Snapshot lösche?

Wenn Sie einen Snapshot löschen, wird FSR für Ihren Snapshot automatisch deaktiviert und die FSR-Rechnungsstellung für den Snapshot wird beendet.

F: Kann ich den FSR für öffentliche und private Snapshots aktivieren, die mit mir geteilt wurden?

Ja, Sie können FSR für öffentliche und private Snapshots aktivieren, die mit Ihrem Konto geteilt wurden. Um FSR für geteilte Snapshots zu aktivieren, können Sie den gleichen Satz von API-Aufrufen verwenden wie für die Aktivierung von FSR für Ihre eigenen Snapshots.

F: Wie wird die Aktivierung von FSR für einen mit mir geteilten Snapshot abgerechnet?

Wenn Sie FSR für Ihren geteilten Snapshot aktivieren, erfolgt die Abrechnung zu den FSR-Standardtarifen (siehe Preisseiten). Bitte beachten Sie, dass Ihr Konto für den FSR des geteilten Snapshots belastet wird. Der Eigentümer des Snapshots erhält keine Rechnung, wenn Sie FSR für den geteilten Snapshot aktivieren.

F: Was passiert mit dem FSR für den geteilten Snapshot, wenn der Eigentümer des Snapshots den Snapshot nicht länger teilt oder ihn löscht?

Wenn der Eigentümer des geteilten Snapshots diesen löscht oder nicht mehr mit Ihnen teilt, indem er Ihre Berechtigungen zur Erstellung von Volumes aus diesem Snapshot zurückruft, wird der FSR für Ihren geteilten Snapshot automatisch deaktiviert und die FSR-Rechnungsstellung für den Snapshot wird beendet.

F: Was ist EBS Snapshots Archive?

EBS Snapshots Archive ist eine günstigere Speicherebene, die eine vollständige Kopie Ihrer zeitpunktbezogener EBS-Snapshots speichert. Anders als bei einem EBS-Snapshot eines Volumes, der inkrementell ist, ist ein Snapshot-Archiv „voll“, da es alle Blocks enthält, die zu dem Zeitpunkt, als der Snapshot erfasst wurde, in das Volume geschrieben wurden. Um ein Volume aus einem EBS-Snapshots-Archiv neu zu erstellen, müssen Sie den EBS-Snapshot in das Standard-Kontingent wiederherstellen und dann ein EBS-Volume aus dem wiederhergestellten Snapshot erstellen.

F: Warum sollte ich EBS Snapshots Archive verwenden?

Sie sollten EBS Snapshots Archive verwenden, wenn Sie eine vollständige Kopie Ihrer Snapshot-Daten für Ihre langfristigen (> 90 Tage) Datenarchivierungs-Anforderungen aufbewahren möchten, um Ihre Geschäftsrichtlinien und Compliance-Anforderungen zu erfüllen. Sie können auch Snapshot-Kosten sparen, indem Sie Ihren Snapshot von der Standardebene in EBS Snapshots Archive verschieben, wenn die Reduzierung der Standardebene mehr als 25 % der Größe Ihres vollständigen Snapshots beträgt.

Sie sollten die Verwendung von EBS Snapshots Archive in den folgenden Szenarien in Betracht ziehen:

1. Ihr Volume verfügt über einen einzigen Snapshot im der EBS-Snapshot-Standardebene, und Sie planen nicht, zusätzliche Snapshots für dieses Volume zu erstellen. In diesem Fall entspricht die Größe des inkrementellen Snapshots der Größe des gesamten Archivs.
2. Aus Gründen der Geschäftspolitik oder aus Compliance-Gründen müssen Sie vollständige Snapshots speichern. EBS Snapshots Archive speichert vollständige Snapshots ohne Rückverweise auf andere Snapshots.
3. Sie möchten monatliche, vierteljährliche oder jährliche Snapshots archivieren, um Kosten zu sparen. Sie müssen sicherstellen, dass Sie eine Senkung der Speicherkosten erzielen, wenn Ihr Snapshot in der inkrementellen Standardebene für EBS-Snapshots als vollständiger Snapshot in EBS Snapshots Archive archiviert wird.
   

F: Welche Snapshots in der EBS-Snapshots-Standardebene profitieren von Kosteneinsparungen durch die Verwendung von EBS Snapshots Archive?

Q: Was ist der Papierkorb für EBS Snapshots?

Mit dem Papierkorb für EBS Snapshots können gelöschte EBS-Snapshots wiederhergestellt werden, wodurch Kunden vor versehentlichem Löschen geschützt werden. Wenn ein Snapshot in einem Kundenkonto gelöscht wird, bei dem der Papierkorb aktiviert ist, wird der Snapshot automatisch in den Papierkorb verschoben, wo er für eine vom Kunden definierte Dauer aufbewahrt wird, bevor er dauerhaft gelöscht wird.

F: Warum sollte ich den Papierkorb verwenden?

Der Papierkorb bietet Ihnen eine einfache und kostengünstige Möglichkeit, Ihre Snapshots nach versehentlichem Löschen wiederherzustellen. Der Papierkorb ist besonders wertvoll für unternehmenskritische und geschäftskritische Anwendungsdaten, die Sie vor versehentlichem Löschen durch Benutzer schützen möchten.

F: Was sind die ersten Schritte mit dem Papierkorb?

Für jedes Ihrer AWS-Konten können Sie den Papierkorb aktivieren, indem Sie eine oder mehrere Aufbewahrungsregeln erstellen, um den Aufbewahrungszeitraum für Ihre Snapshots festzulegen. Sobald eine Aufbewahrungsregel konfiguriert ist, werden gelöschte Snapshots in den Papierkorb verschoben und bleiben dort für den angegebenen Aufbewahrungszeitraum. Sie können einen Snapshot jederzeit vor Ablauf des Aufbewahrungszeitraums aus dem Papierkorb wiederherstellen. Auf den Papierkorb kann über die AWS-Managementkonsole, die AWS-Befehlszeilenschnittstelle (CLI) oder die AWS-SDKs zugegriffen werden.

Weitere Informationen entnehmen Sie bitte der technischen Dokumentation.

F: Wie hoch sind die Preise für Snapshots im Papierkorb?

Für EBS-Snapshots im Papierkorb wird der gleiche Satz wie für Amazon EBS Snapshots berechnet. Weitere Informationen finden Sie unter https://thinkwithwp.com/ebs/pricing/.

F: Kann ich die Abrechnung und Nutzung meines Papierkorbs über Cost Explorer abrufen?

Ja, Sie können mit Cost Explorer auf Ihre Abrechnung und Nutzung zugreifen. Sie können das Tag „aws:recycle-bin:resource-in-bin“ verwenden, um die Kosten von Snapshots im Papierkorb abzuschätzen.

F: Was ist die Amazon EBS-Verschlüsselung?

Die Amazon EBS-Verschlüsselung ermöglicht eine reibungslose Verschlüsselung von EBS-Daten-Volumes und -Snapshots, sodass keine sichere Infrastruktur für die Schlüsselverwaltung entwickelt und gepflegt werden muss. EBS-Verschlüsselung ermöglicht das Schützen gespeicherter Daten mithilfe der Verschlüsselung Ihrer Daten durch von Amazon verwaltete Schlüssel oder durch von Ihnen mit dem AWS Key Management Service (KMS) erstellte und verwaltete Schlüssel. Die Verschlüsselung erfolgt auf den Servern, die EC2-Instances hosten, sodass Daten verschlüsselt werden, die zwischen EC2-Instances und EBS-Speicher übertragen werden. Weitere Details finden Sie unter "Amazon EBS encryption" im Amazon EC2 User Guide.

F: Was ist der AWS Key Management Service (KMS)?

AWS KMS ist ein verwalteter Service, der das Erstellen und Kontrollieren der Verschlüsselungsschlüssel vereinfacht, die zum Verschlüsseln Ihrer Daten verwendet werden. AWS Key Management Service ist in andere AWS-Services wie Amazon EBS, Amazon S3 und Amazon Redshift integriert, um die Verschlüsselung Ihrer Daten mit von Ihnen verwalteten Verschlüsselungsschlüsseln zu vereinfachen. AWS Key Management Service ist auch in AWS CloudTrail integriert und stellt für Sie Protokolle der gesamten Schlüsselnutzung bereit, um Sie bei der Einhaltung Ihrer gesetzlichen und Compliance-Anforderungen zu unterstützen. Weitere Informationen zu KMS finden Sie auf der AWS Key Management Service-Produktseite.

F: Weshalb sollte ich die EBS-Verschlüsselung verwenden?

Sie können mithilfe der Amazon EBS-Verschlüsselung die Compliance-Anforderungen an Sicherheit und Verschlüsselung von in der Cloud gespeicherten Daten erfüllen. Die Kombination aus Verschlüsselung mit vorhandenen IAM-Zugriffskontrollrichtlinien verbessert die Hochsicherheitsstrategie unseres Unternehmens weiter.

F: Wie werden meine Amazon EBS-Verschlüsselungsschlüssel verwaltet?

Zur Amazon EBS-Verschlüsselung gehört auch die Schlüsselverwaltung. Jedes neu erstellte Volume erhält einen eindeutigen 256-Bit-AES-Schlüssel. Anhand der verschlüsselten Snapshots erstellte Volume nutzen ebenfalls diesen Schlüssel. Die Schlüssel sind durch Ihre eigene Infrastruktur zur Schlüsselverwaltung geschützt, was strenge logische und physische Sicherheitskontrollen ermöglicht, um unbefugte Zugriffe zu verhindern. Ihre Daten und dazugehörigen Schlüssel werden gemäß Branchenstandard mit einem AES-256-Algorithmus verschlüsselt.

F: Werden Start-Volumes von der EBS-Verschlüsselung unterstützt?

Ja.

F: Kann ich beim Starten einer Instance ein verschlüsseltes Daten-Volume erstellen?

Ja, mit Kundenmasterschlüsseln (CMKs), die entweder von AWS oder vom Kunden verwaltet werden. Sie können Volume-Details und Verschlüsselung über einen RunInstances-API-Aufruf mit dem Parameter BlockDeviceMapping oder mit dem Startassistenten in der EC2-Konsole angeben.

F: Kann ich beim Starten von Instances zusätzliche verschlüsselte Daten-Volumes erstellen, die nicht Teil der AMI sind?

Ja, Sie können beim Starten von Instances verschlüsselte Daten-Volumes erstellen, und zwar entweder mit der Standard- oder mit der benutzerdefinierten CMK-Verschlüsselung. Sie können die Volume-Details und -Verschlüsselung mit dem BlockDeviceMapping-Objekt im RunInstances APIS-Aufruf oder mit dem Startassistenten in der EC2-Konsole angeben.

F: Kann ich eine verschlüsselte EBS-Instance von einer unverschlüsselten AMI ausführen?

Ja. Weitere Informationen finden Sie in der technischen Dokumentation.

F: Kann ich verschlüsselte Snapshots und AMIs für andere Konten freigeben?

Ja. Sie können verschlüsselte Snapshots und AMIs mit einem vom Kunden verwalteten Masterschlüssel (CMK) für andere AWS-Konten freigeben. Weitere Informationen finden Sie in der technischen Dokumentation.

F: Kann ich sicherstellen, dass alle neu erstellten Volumes stets verschlüsselt sind?

Ja, Sie können EBS-Verschlüsselung standardmäßig aktivieren, mit nur einer Einstellung je Region. So wird sichergestellt, dass alle neu erstellten Volumes stets verschlüsselt sind. Weitere Informationen finden Sie in der technischen Dokumentation. 

F: Werden mir die E/As pro Sekunde, die mir über ein bereitgestelltes E/A-Sek.-Volume zur Verfügung gestellt werden, in Rechnung gestellt, wenn dieses von einer Instance getrennt wird?

Ja, die bereitgestellten E/As pro Sekunde werden Ihnen berechnet, wenn das Volume von einer Instance getrennt wird. Wenn ein Volume getrennt wird, empfehlen wir das Erstellen eines Snapshots und Löschen des Volumes, um Kosten zu senken. Weitere Informationen finden Sie in Trusted Advisor im Abschnitt mit der Kostenoptimierungsprüfung "Underutilized Amazon EBS Volumes". Bei dieser Prüfung werden die Konfigurationen Ihrer Amazon Elastic Block Store (Amazon EBS)-Volumes untersucht und Warnungen ausgegeben, wenn Volumes anscheinend unausgelastet sind.

F: Sind Steuern bereits in den Preisen enthalten?

Falls nicht anders angegeben, gelten unsere Preise zuzüglich anfallender Steuern und Abgaben, darunter MwSt. und Umsatzsteuer. Bei Kunden mit japanischer Rechnungsadresse unterliegt die Nutzung von AWS-Services der japanischen Verbrauchssteuer. Weitere Informationen.

F: Gibt es eine zusätzliche Gebühr für die Aktivierung von Multi-Attach?

Nein. Multi-Attach kann auf einem von EBS bereitgestellten IOPS io1-Volume aktiviert werden. Für den bereitgestellten Speicher (GB-Mo) und IOPS (IOPS-Mo) fallen Gebühren an.

F: Kann ich eine EC2-Instance mit einem Multi-Attach-fähigen Volume starten?

Nein.

F: Was passiert, wenn für alle angehängten Instances das Flag "deleteOnTermination" nicht gesetzt ist?

Das deleteOnTermination-Verhalten des Volumes wird durch die Konfiguration der zuletzt angehängten Instanz bestimmt, die beendet wird. Aktivieren oder deaktivieren Sie 'deleteOnTermination' für alle Instances, an die das Volume angehängt ist, um ein vorhersehbares Löschen beim Beenden sicherzustellen.

Wenn Sie möchten, dass das Volume beim Beenden der angehängten Instances gelöscht wird, aktivieren Sie "deleteOnTermination" für alle Instances, an die das Volume angehängt ist. Wenn Sie das Volume nach dem Beenden der angehängten Instanzen beibehalten möchten, deaktivieren Sie "deleteOnTermination" für alle angehängten Instances. Weitere Informationen finden Sie in der technischen Dokumentation zu Multi-Attach.

F: Kann meine Anwendung Multi-Attach verwenden?

Wenn Ihre Anwendung keine Speicherschichtkoordination von Schreibvorgängen erfordert, z. B. eine schreibgeschützte Anwendung, oder das IO-Fencing auf Anwendungsebene erzwingt, kann Ihre Anwendung Multi-Attach verwenden.