Amazon EBS よくある質問

EBS 最適化インスタンスにアタッチされているプロビジョンド IOPS SSD (io2 Block Express および io1) ボリュームは、特定の 1 年間の 99.9% において、プロビジョンド IOPS パフォーマンスの ±10% 以内を実現するよう設計されています。正確なパフォーマンスはアプリケーションの I/O 要件によって異なります。

EBS 最適化インスタンスにアタッチすると、プロビジョンド IOPS io2 Block Express ボリュームはミリ秒未満のレイテンシーを達成でき、io1 ボリュームは 1 桁ミリ秒のレイテンシーを達成できます。正確なパフォーマンスはアプリケーションの I/O 要件によって異なります。

はい、影響します。io2 Block Express ボリュームのために IOPS をプロビジョニングする場合、実際の IOPS レートは、アプリケーションの読み取りと書き込みの I/O サイズによって異なります。プロビジョンド IOPS ボリュームには 16 KB のベース I/O サイズがあります。そのため、16 KB の I/O サイズに対して 40,000 IOPS のボリュームをプロビジョニングした場合、その規模で最大 40,000 IOPS を達成します。I/O サイズが 256 KB に増加すると、最大 16,000 IOPS が達成されます。これは、4,000 MiB/秒の最大スループットが 16,000 IOPS で達成されるためです。詳細については、プロビジョンド IOPS ボリュームに関するテクニカルドキュメントにアクセスしてください。 Amazon CloudWatch を利用すると、スループットと I/O サイズをモニタリングできます。

EBS 最適化インスタンスにアタッチされているプロビジョンド IOPS SSD (io2 Block Express および io1) ボリュームは、パフォーマンスが一定となるように設計されており、特定の 1 年間の 99.9% において、プロビジョンド IOPS パフォーマンスの ±10% 以内を実現します。スナップショットから作成した新しいボリュームとのパフォーマンスにおいて一貫性を最大限に引き出すために、スナップショットで Fast Snapshot Restore (FSR) を有効にすることをお勧めします。FSR が有効化されたスナップショットから復元された EBS ボリュームは、すぐに完全なパフォーマンスを発揮します。

パフォーマンスに影響するもう 1 つの要因として、アプリケーションから送信される I/O リクエストの少なさがあります。このことをモニタリングするには、ボリュームのキューの深度に注目してください。キューの深度とは、アプリケーションからボリュームへの I/O リクエストが処理中であるものの数です。一定性を最大化するには、プロビジョンド IOPS ボリュームのキューの平均深度 (小数点以下四捨五入) は、深度 1 につき、プロビジョニングされた IOPS が 1 秒あたり 1,000 である状態を維持する必要があります。例えば、3,000 IOPS を指定してプロビジョニングされたボリュームの場合は、キューの平均深度が 3 である必要があります。ボリュームのパフォーマンス一定性確保の詳細については、EBS パフォーマンスの向上を参照してください。

スループット最適化 HDD (st1) や Cold HDD (sc1) は、EBS 最適化インスタンスに接続されているときに、想定スループットパフォーマンスの±10% 以内のパフォーマンスを発揮できる時間が 1 年間のうち 99% となるように設計されています。正確なパフォーマンスは、アプリケーションの I/O 要件と EC2 インスタンスのパフォーマンスに応じて異なります。

はい。スループットレートは、アプリケーションの読み取りと書き込みの I/O サイズに応じて異なります。HDD タイプのボリュームでは、1 MB の I/O サイズで読み取りと書き込みが処理されます。シーケンシャル I/O は 1 MB 単位でマージおよび処理されます。一方、非シーケンシャル I/O は、実際の I/O サイズが 1 MB より小さい場合であっても 1 MB として処理されます。このため、データベースなど、I/O が小規模でランダムなトランザクションワークロードでは、HDD タイプのボリュームでは高いパフォーマンスが実現されません。ただし、シーケンシャル I/O と大規模な I/O では長期間にわたり st1 と sc1 の広告通りのパフォーマンスが実現されます。

スループット最適化 HDD (st1) や Cold HDD (sc1) は、EBS 最適化インスタンスに接続されているときに、想定スループットパフォーマンスの± 10% 以内のパフォーマンスを発揮できる時間が 1 年間のうち 99% となるパフォーマンスの一定性を実現できるように設計されています。この一定性に影響する要因には、さまざまなものがあります。例えば、ボリュームに対するランダム I/O 操作とシーケンシャル I/O 操作の間の相対的なバランスがパフォーマンスに影響を与える可能性があります。きわめて多くの小さいランダム I/O 操作が発生すると、I/O クレジットがすぐに枯渇し、ベースラインレートまでパフォーマンスが低下します。また、スループットレートは選択されたインスタンスに応じて低下する可能性があります。st1 では 500 MB/秒までスループットを高めることができますが、パフォーマンスは EBS トラフィックでは個別のインスタンスレベルの制限によって制限されます。もう 1 つの要因は、スナップショットの実行です。スナップショットが完了するまで、想定される書き込みパフォーマンスがベースラインレートまで低下します。これは st1 と sc1 に固有のものです。

また、アプリケーションが十分な I/O 要求を送信していない場合は、パフォーマンスも影響を受ける可能性があります。これは、ボリュームのキューの深度と I/O サイズに注目することで、監視できます。キューの深度とは、アプリケーションからボリュームへの I/O リクエストが処理中であるものの数です。一定性を最大化するため、HDD バックアップされたボリュームは、1 MB のシーケンシャル I/O ごとに 4 以上のキューの平均深度 (小数点以下四捨五入) を維持する必要があります。ボリュームのパフォーマンス一定性確保の詳細については、EBS パフォーマンスの向上を参照してください。

はい。複数のボリュームをまとめてストライピングして、より大きい EC2 インスタンスにアタッチすると、最大 400,000 IOPS または 12,500 Mbps を実現することもできます。複数のボリュームのストライピングの運用管理を必要とすることなく、より高いパフォーマンス要件を実現するには、io2 Block Express ボリュームを使用することをお勧めします。st1 および sc1 のパフォーマンスはボリュームサイズに比例して向上します。そのため、これらのボリュームをまとめてストライピングすることで得られるメリットはそれほど多くはない可能性があります。

EBS は、マルチテナントブロックストレージサービスです。リソース競合を回避するためのメカニズムとしてレート制限を採用しています。これは、ボリュームのパフォーマンス基準を定義することから始まります。弊社のボリュームタイプ (gp2、PIOPS、st1、および sc1) はすべて、IOPS とスループットの観点からパフォーマンス特性を定義しています。次のステップでは、インスタンスレベルでパフォーマンスを定義します。各 EBS 最適化インスタンスでは、インスタンスにアタッチされた EBS ボリュームのセットに対してパフォーマンス (スループットと IOPS の両方) を定義しています。これにより、お客様はインスタンスとボリュームのサイズを設定すれば、必要に応じたレベルのパフォーマンスを実現できます。さらに、お客様は報告されたメトリクを使用して、インスタンスレベルやボリュームレベルのパフォーマンスを確認できます。期待するパフォーマンスと一致しない状態を検出するためにアラームを設定できます。このメトリクスは、そのボリュームレベルに見合ったパフォーマンスを持つ適切なインスタンスタイプで構成しているかを判断のにも役立ちます。EBS 側では、構成したパフォーマンスを使い、ボリュームをサポートするために適切なインスタンスと EBS インフラストラクチャをどのように割り当てるかを通知します。インフラストラクチャを適切に割り当てることで、リソースの競合を回避します。さらに、弊社は常にインフラを監視しています。この監視により、インフラストラクチャの障害 (または差し迫ったインフラストラクチャの障害) を検出できるため、(必要に応じて) 基盤となるインフラストラクチャを修復または交換しながら、先を見越してボリュームを機能しているハードウェアに移動できます。

汎用 SSD (gp3 および gp2) ボリュームは、EBS 最適化インスタンスに接続されているときに、プロビジョンド IOPS の ±10% 以内のパフォーマンスを発揮できる時間が 1 年間のうち 99% となるように設計されています。正確なパフォーマンスはアプリケーションの I/O 要件によって異なります。

EBS 最適化インスタンスにアタッチした場合、汎用 SSD (gp3 および gp2) ボリュームは 10 ミリ秒未満のレイテンシーを実現できます。正確なパフォーマンスはアプリケーションの I/O 要件によって異なります。

いいえ。すべての汎用 SSD (gp3) ボリュームには、3,000 IOPS と 125 MB/秒の一貫したパフォーマンスがあり、追加コストはかかりません。ボリュームは、3,000 IOPS と 125MB/秒を無期限に維持できます。

1,000 GB 未満の汎用 SSD (gp2) ボリュームは、最大 3,000 IOPS のバースト IOPS パフォーマンスを受け取り、少なくとも 30 分間の持続的なパフォーマンスを提供します。さらに、gp2 ボリュームは、プロビジョニングされた GB あたり 3 IOPS の一貫したパフォーマンスを提供します。例えば、500 GB のボリュームは、一貫して 1,500 IOPS を駆動し、60 分間で 3,000 IOPS にバーストできます (3,000 IOPS * 60 秒 * 30 分 / 1,500 IOPS / 60 秒)。

io2 ボリュームは、EC2 インスタンスすべてに高性能のブロックストレージを提供します。さらに高い性能が必要なアプリケーションについては、io2 ボリュームを Amazon EC2 インスタンスにアタッチすると Block Express で実行され io2 と比べて性能が 4 倍高くなります。これにより、単一の io2 ボリュームから最大 64 TiB の容量、256,000 IOPS、4,000 MB/秒のスループットとミリ秒未満の平均 IO レイテンシーを実現できます。

EBS Block Express は、クラウドスケールでのブロックストレージに対してミリ秒未満のレイテンシーで最高レベルのパフォーマンスを提供することを目的として構築された次世代の Amazon EBS ストレージサーバーアーキテクチャです。Block Express は、高性能で低レイテンシーのネットワークプロトコルである Scalable Reliable Datagrams (SRD) を使用してこれを行い、Nitro System ベースの EC2 インスタンスと通信します。これは、ハイパフォーマンスコンピューティング (HPC) および機械学習 (ML) ワークロード用の Elastic Fabric Adapter (EFA) のインスタンス間通信に使用されるのと同じ高性能で低レイテンシーのネットワークインターフェイスです。さらに、Block Express は、さまざまな方法で組み合わせることができるモジュラーソフトウェアおよびハードウェアビルディングブロックを提供します。これにより、パフォーマンスの向上と新機能をより迅速に設計および提供する柔軟性がもたらされます。

io2 Block Express は、単一ボリュームでの低レイテンシー、高 IOPS、高スループット、大容量の恩恵を受ける、パフォーマンスが求められ、容量を大量に消費するワークロードに適しています。このようなワークロードには、SAP HANA、Oracle、MS SQL、PostgreSQL、MySQL、MongoDB、Cassandra などのリレーショナルデータベースと NoSQL データベース、および SAP Business Suite、NetWeaver、Oracle eBusiness、PeopleSoft、Siebel などの重要なビジネスオペレーションワークロードや、Infor LN および Infor M3 などの ERP ワークロードが含まれます。

io2 ボリュームが Amazon EC2 インスタンスにアタッチされている場合、Block Express で実行され、単一のボリュームに対してミリ秒未満のレイテンシー、最大 256,000 IOPS、4,000 MB/秒のスループット、最大 64 TiB の容量を実現します。それ以外のすべてのボリュームにアタッチされた場合、io2 は Block Express では実行されず、単一のボリュームに対してレイテンシーは 10 ミリ秒未満、最大64K IOPS、1GB/秒のスループット、最大 16 TiB の容量を実現します。
 

この機能は、AWS CLI を使用するか、または AWS SDK 経由のいずれかにより以下の API を呼び出すことで使用できます。

• スナップショットブロックの一覧表示: ListSnapshotBlocks API オペレーションにより、指定したスナップショット内のブロックに対してブロックインデックスおよびブロックトークンが返されます。
• 変更されたブロックの一覧表示: ListChangedBlocks API オペレーションにより、ボリュームまたはスナップショットと同じ系列の 2 つの指定したスナップショットとは異なるブロックに対してブロックインデックスおよびブロックトークンが返されます。
• スナップショットブロックの取得: GetSnapshotBlock API オペレーションにより、指定したスナップショット ID、ブロックインデックス、ブロックトークンのブロック内のデータが返されます。
• スナップショットの開始: StartSnapshot 操作は、既存のスナップショットの増分スナップショットとして、または新しいスナップショットとして、スナップショットを開始します。開始されたスナップショットは、CompleteSnapshot アクションを使用して完了するまで、保留状態のままです。
• スナップショットブロックの配置: PutSnapshot 操作は、保留状態にある開始済みのスナップショットに個々のブロック形式でデータを追加します。送信されるデータのブロックに対して、Base64 でエンコードされた SHA256 チェックサムを指定する必要があります。送信が完了した後、サービスがチェックサムを検証します。サービスによって計算されたチェックサムが指定したものと一致しない場合、リクエストは失敗します。
• スナップショットの完了: CompleteSnapshot 操作は、保留状態の開始済みスナップショットを完了します。その後、スナップショットは完了状態に変更されます。

詳細については、テクニカルドキュメントを参照してください。

GetSnapshotBlock および PutSnapshotBlock API は、512 KiB のブロックサイズをサポートします。

いいえ。スナップショットは Amazon EC2 API 経由でのみ利用可能です。

いいえ。スナップショットはボリュームがアタッチされ使用中の状態でもリアルタイムで実行できます。ただし、スナップショットは、お客様の Amazon EBS ボリュームに対して記述されたデータのみを捕捉します。つまりお客様のアプリケーションまたは OS によってローカルにキャッシュされたデータは除外される可能性があります。インスタンスにアタッチされるボリュームで安定してスナップショットを取得するために、ボリュームを一旦明確に取り外し、スナップショットコマンドを発行して、ボリュームを再度アタッチすることをお勧めしています。ルートデバイスとしてサービスを提供する Amazon EBS ボリュームについては、明確なスナップショットを取得するためにマシンをシャットダウンすることをお勧めしています。

16 TB のボリューム全体の EBS スナップショットにかかる時間が、1 TB のボリューム全体のスナップショットを作成する場合の時間を超えない設計になっています。しかし、スナップショットをとるための実際の所要時間は、EBS ボリュームの最後のスナップショットの作成以降に変更されたデータの量を含む、複数の要素によって決まります。

スナップショットにはそれぞれ一意の識別子が付与され、どのスナップショットからでもボリュームを作成することができます。

AWS マネジメントコンソールの [Snapshots] セクションにあるリストから [Private Snapshots] を選択すると、お客様が共有しているスナップショットを見つけることができます。このセクションには、お客様が所有しているスナップショットと、お客様が共有しているスナップショットの両方が表示されています。

AWS マネジメントコンソールの [Snapshots] セクションにあるリストから [Public Snapshots] を選択すると、グローバルに共有されているスナップショットを見つけることができます。 また、EBS スナップショットのブロックパブリックアクセスを有効にすることで、アカウント内のスナップショットへのパブリックアクセスを制限することもできます。

Amazon スナップショットとして保存されているパブリックデータセットは、AWS マネジメントコンソールを使用して見つけることができます。コンソールにログインし、[Amazon EC2 Service] を選択し、[Snapshots] を選択して、[Public Snapshots] でフィルタしてください。パブリックデータセットに関するすべての情報は、AWS パブリックデータセットリソースセンターで公開しています。

スナップショットからボリュームにデータを復元する際に生じるデータアクセスのレイテンシーが懸念されるときや、初期化処理中のパフォーマンスへの影響を防ぎたい場合には、そのスナップショットで FSR を有効化してください。FSR は、仮想デスクトップのインフラストラクチャ (VDI)、バックアップと復元、テストおよび開発用のボリュームコピー、そしてカスタム AMI からのブートなどのユースケースに役立つよう意図されています。スナップショットで FSR を有効にすると、そのスナップショットからデータの復元をするときは、想定が可能で改善されたパフォーマンスがいつでも実現できます。

いいえ。FSR が有効化されたスナップショットは、そのスナップショットからボリュームへのデータ復元が改善されます。FSR が有効化されたスナップショットでは、スナップショットの作成時間は速くなりません。

この機能の使用には、初期化済みボリュームの復元先となるアベイラビリティゾーン (AZ) にあるスナップショットで、enable-fast-snapshot-restores という新しい API を呼び出します。

FSR が有効化済みのスナップショットは、有効化中、最適化中、有効化済み、無効化中、無効化済み、の中のいずれか 1 つの状態になります。FSR の状態の遷移状況は CloudWatch イベントとして公開されます。この状態は、describe-fast-snapshot-restores API を使ってチェックすることができます。

スナップショットで FSR を有効化しても、既存のスナップショット API からの応答に影響は与えません。また、既存のワークフローの変更の必要もありません。FSR の有効化と無効化は、そのアカウントが所有するスナップショットに対してのみ可能です。共有済みのスナップショットでは、FSR は使用できません。コンソールを使用するか API を通じて、FSR 有効化済みのスナップショットのリストを確認できます。

FSR が有効化されたスナップショットから作成したボリュームは、初期化が完了しています。しかし、そのまま完全なパフォーマンスを実現するボリュームには、作成できる数に制限があります。これらの制限は、AZ 内にあり FSR が有効化されたスナップショットに関連付けられた、クレジットバケットの形で記述されています。クレジットについて知っておくべき重要事項を次に示します。

1.1 度のボリューム作成でクレジットを 1 個消費します
2.クレジットの個数は FSR が有効化されたスナップショットのサイズにより変わります
3.クレジットは時間経過に伴い補充されます
4.クレジットバケットのサイズは最大で 10 までです。

クレジットバケットサイズと充填率の概算は、1,024 をスナップショットのサイズで割り算すると得られますたとえば、FSR を有効にしている 100 GiB のスナップショットでは、最大クレジット数は 10 個で、充填率は毎時 10 クレジットのバランスとなります。4 TiB のスナップショットであれば、最大クレジット数は 1 個で充填率は 4 時間ごとに 1 クレジットとなります。

クレジットバケットのサイズは、作成したボリュームのサイズではなく、FSR が有効化されたスナップショットのサイズにより変化することには十分ご注意ください。たとえば、100 GiB のスナップショットからは、1 TiB のボリュームを一度に 10 個まで作成できます。

また、スナップショットで FSR が有効化されている各 AZ では、他の AZ とは別に独自のクレジットバケット与えられます。

作成するクレジットバケットのサイズは作成できる最大個数を反映しており、クレジットバケットのバランスには作成が可能な回数が反映されます。充填された時点では、FSR が有効化されたスナップショットからは、一度に初期化済みボリュームが 10 個まで作成できます。クレジットバケットの最大サイズと、クレジットバケットのバランスは、CloudWatch のメトリクスとして公開されます。制限個数を超えた範囲でのボリューム作成は、スナップショットで FSR が有効化されていない場合と同様に処理されます。

FSR を使用すると、作成時のステータスを示すため、DescribeVolumes API には EBS 固有の新しい属性 (fastRestored) が追加されます。FSR が有効化されたスナップショットからボリュームを作成するとき、ボリューム作成クレジットが不足していると、作成処理は成功しますが、そのボリュームは初期化されません。

スナップショットを削除するとスナップショットの FSR が自動的に無効化され、スナップショットの FSR 料金の請求が停止します。

はい。パブリックのスナップショットとお使いのアカウントに共有されているすべてのプライベートスナップショットの FSR は、有効化できます。共有されたスナップショットの FSR を有効にするときは、所有するスナップショットで FSR を有効化する際に使用したものと同じ API コールのセットを使用します。

共有されたスナップショットの FSR を有効にすると、標準の FSR 料金が請求されます (料金のページを参照)。共有されたスナップショットにおける FSR 料金の請求は、お客様のアカウントに対してのみ行われます。共有されたスナップショットでお客様が FSR を有効にしても、スナップショットの所有者には請求は行われません。

共有されたスナップショットの所有者が、そのスナップショットからボリュームを作成するためのアクセス許可を取り消して、そのスナップショットを削除したりお客様との共有を停止したりした場合、共有されたスナップショットの FSR は自動的に無効となり、そのスナップショットにおける FSR 料金の請求は停止されます。

アプリケーションやデータベースのフリーズ、フラッシュ I/O、フリーズ解除、および EBS スナップショットの初期化を調整するには、Amazon Data Lifecycle Manager と AWS Systems Manager (SSM) を使用します。アプリケーションまたはデータベースに固有のアクションを実行するコマンドを提供する必要があります。MySQL、PostgreSQL、および Windows アプリケーション向けに AWS が提供するコードと SSM ドキュメントについては、こちらのドキュメントを参照することもできます。

Amazon EBS 暗号化サービスにより、EBS データボリュームとスナップショットがシームレスに暗号化されるため、セキュアキー管理インフラストラクチャの構築と管理の必要がなくなります。EBS 暗号化サービスは、データを暗号化して、データ保管時のセキュリティを有効にします。これを行うには、Amazon が管理するキーを使用するか、またはユーザーが AWS Key Management Service (KMS) を使用して、作成し管理するキーを使用します。EC2 インスタンスをホストするサーバーで暗号化が行われるため、EC2 インスタンスと EBS ストレージとの間を移動するデータが暗号化されます。詳細については、『Amazon EC2 ユーザーガイド』の「Amazon EBS 暗号化」をご参照ください。

AWS KMS は、データの暗号化に使用される暗号化キーの作成と管理を容易にするマネージド型サービスです。AWS Key Management Service は Amazon EBS、Amazon S3、Amazon Redshift などの他の AWS サービスと統合されており、ユーザーが管理する暗号化キーでのデータの暗号化を簡単にします。また AWS Key Management Service は AWS CloudTrail とも統合されており、すべてのキーの使用ログを表示できるため、規制およびコンプライアンスの要求に応えるために役立ちます。KMS の詳細については、AWS Key Management Service の製品ページをご覧ください。

EBS 暗号化サービスを使用することにより、クラウドで保管されるデータの暗号化に関するセキュリティ要件とコンプライアンス要件を満たすことができます。暗号化と既存の IAM アクセスコントロールポリシーを組み合わせることで、会社の多重防御戦略をさらに強めることができます。

Amazon EBS 暗号化サービスでは、お客様に代わってキーを管理します。新たに作成されたボリュームそれぞれに一意の 256 ビット AES キーが付与されます。暗号化されたスナップショットから作成されたボリュームはキーを共有します。これらのキーは、不正アクセスを防止する堅牢な論理的および物理的セキュリティ統制を実装する、当社独自のキー管理インフラストラクチャによって保護されます。お客様のデータと関連するキーは、業界標準の AES-256 アルゴリズムを使用して暗号化されます。

はい。

はい。AWS の管理する、または顧客の管理するカスタマーマスクキー (CMK) を用いて行えます。ボリュームの詳細と暗号化は、RunInstances API 呼び出しで、BlockDeviceMapping パラメータまたは EC2 コンソールの起動ウィザードを用いて指定できます。

はい。インスタンスの作成時には、デフォルトまたはカスタム CMK 暗号化で暗号化されたデータボリュームを作成できます。ボリュームの詳細と暗号化は、BlockDeviceMapping オブジェクトで、RunInstances API 呼び出しか、EC2 コンソールの起動ウィザードを通して指定できます。

はい。詳しくは技術文書をご参照ください。

はい。他の AWS アカウントとカスタマー管理型カスタマーマスターキー (CMK) を使用して、暗号化したスナップショットと AMI を共有できます。詳細は、技術文書を参照してください。

はい、リージョンごとに 1 回設定すればデフォルトで EBS 暗号化を有効にすることができます。これで確実に、新たに作成したすべてのボリュームが必ず暗号化されます。詳細は、技術文書を参照してください。 

はい。プロビジョニングされている IOPS は、インスタンスから切断されている場合も請求の対象になります。コスト削減のため、ボリュームを取り外す場合は、スナップショットを作成してボリュームを削除することを検討するようお勧めします。詳細については、Trusted Advisor で「Underutilized Amazon EBS Volumes」のコスト最適化チェックを参照してください。この項目は Amazon Elastic Block Store (Amazon EBS) ボリュームの設定を確認し、ボリュームが過少利用と思われる場合は警告します。

別途記載がない限り、表示される料金には VAT、売上税その他取引に対して適用される一切の税金等および関税は含まれません。日本の居住者であるお客様が AWS サービスをご利用になった場合には、料金とあわせて別途消費税をご請求させていただきます。詳細はこちら。

いいえ。EBS プロビジョンド IOPS ボリュームでマルチアタッチを有効にできます。プロビジョニングされたストレージ (GB-Mo) および IOPS (IOPS-Mo) に対して料金が発生します。

いいえ。

ボリュームの deleteOnTermination 動作は、終了された最後に接続されたインスタンスの構成によって決まります。終了時の予測可能な削除動作を保証するには、ボリュームが接続されているすべてのインスタンスの「deleteOnTermination」を有効または無効にします。

接続されたインスタンスが終了したときにボリュームを削除する場合は、ボリュームが接続されているすべてのインスタンスに対して「deleteOnTermination」を有効にします。接続されたインスタンスが終了した後もボリュームを保持する場合は、すべての接続されたインスタンスの「deleteOnTermination」を無効にします。詳細については、マルチアタッチの技術文書を参照してください。

アプリケーションが Windows Server フェイルオーバークラスターに構築されている場合、NVMe 予約を使用して共有ストレージへの安全なアクセスを調整する場合、およびアプリケーションレベルで安全なアクセスを調整する場合に、アプリケーションでマルチアタッチを使用することができます。