Amazon EBS – Häufig gestellte Fragen

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

Wenn Volumes mit EBS-optimierten Instances verbunden sind, können bereitgestellte IOPS-io2-Block-Express-Volumes Latenzzeiten von unter einer Millisekunde erreichen und io1-Volumes können Latenzzeiten im einstelligen Millisekundenbereich erreichen. Die exakte Leistung hängt von den E/A-Anforderungen Ihrer Anwendung ab.

Ja, das ist der Fall. Wenn Sie IOPS für io2-Block-Express-Volumes bereitstellen, hängt die erhaltene IOPS-Rate von der I/O-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 IOPS für eine I/O-Größe von 16 KB bereitgestellt haben, werden bei dieser Größe bis zu 40 000 IOPS. erreicht. Wenn die I/O-Größe auf 256 KB erhöht wird, erreichen Sie bis zu 16 000 IOPS, da der maximale Durchsatz von 4 000 MiB/s bei 16 000 IOPS erreicht wird. Weitere Informationen erhalten Sie in der technischen Dokumentation zu bereitgestellten IOPS-Volumes. Sie können Amazon CloudWatch verwenden, um den Durchsatz und die I/O-Größen zu überwachen.

Bereitgestellte IOPS SSD (io2 Block Express und io1)-Volumes, 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.

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.

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.

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.

Ja. Sie können bei einer Anbindung an größere EC2-Instances mehrere Volumes mithilfe von Stripes verbinden, um bis zu 400 000 IOPS oder 12 500 MB/s zu erreichen. Wir empfehlen die Verwendung von io2-Block-Express-Volumes für höhere Leistungsanforderungen, ohne dass das Betriebsmanagement durch Striping mehrerer Volumes erforderlich ist. Die Leistung für st1 und sc1 wird linear mit der Volume-Größe skaliert, sodass ein Verbinden dieser Volumes mit Stripes möglicherweise nur von geringem Nutzen ist.

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.

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.

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.

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.

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).

io2-Volumes bieten leistungsstarken Blockspeicher für alle EC2-Instances. Für Anwendungen mit noch höheren Leistungsanforderungen können Sie io2-Volumes an EC2-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.

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.

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.

Wenn ein io2-Volume an eine Amazon-EC2-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 TB 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.
 

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.

Weitere Informationen entnehmen Sie bitte der technischen Dokumentation.

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

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

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.

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.

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

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.

Sie können global freigegebene Snapshots finden, indem Sie über die AWS Management Console im Abschnitt "Snapshots" den Listeneintrag "Public Snapshots" auswählen. Sie können den öffentlichen Zugang zu Snapshots in einem Konto auch einschränken, indem Sie die Option Sperren des öffentlichen Zugangs für EBS-Snapshots aktivieren.

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.

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.

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.

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.

Volumes, die aus einem FSR-aktivierten Snapshot erstellt wurden, sind vollständig initialisiert. Die Anzahl Volumes, die mit sofortiger vollständiger Leistung erstellt werden können, ist allerdings begrenzt. Diese Begrenzungen werden anhand eines Kredit-Buckets angezeigt, der zu einem FSR-aktivierten Snapshot in einer gegebenen AZ zugeordnet ist. Wichtiges, das Sie über Kredite wissen müssen:

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 TiB 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.

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.

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.

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

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.

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.

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.

Sie können Amazon Data Lifecycle Manager und AWS Systems Manager (SSM) verwenden, um das Einfrieren, Leeren und Entsperren Ihrer Anwendung oder Datenbank sowie die Initialisierung von EBS-Snapshots zu koordinieren. Sie müssen Befehle angeben, um die Aktionen auszuführen, die für Ihre Anwendung oder Datenbank spezifisch sind. Sie können auch unsere Dokumentation für von AWS bereitgestellten Code und SSM-Dokumente für MySQL-, PostgreSQL- und Windows-Anwendungen einsehen.

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.

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.

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.

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.

Ja.

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.

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.

Ja. Weitere Informationen finden Sie in der technischen Dokumentation.

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.

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. 

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.

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

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

Nein.

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.

Ihre Anwendung kann Multi-Attach verwenden, wenn die Anwendung auf einem Windows-Server-Failover-Cluster basiert, den sicheren Zugriff auf gemeinsam genutzten Speicher mithilfe von NVMe-Reservierungen koordiniert oder den sicheren Zugriff auf Anwendungsebene koordiniert.