スナップショットと を使用した Amazon EC2バックアップとリカバリ AMIs

Amazon マシンイメージ (AMI) を使用してEC2インスタンスのフルバックアップを作成する必要があるか、個々のボリュームのスナップショットを作成する必要があるかを検討してください。

バックアップに AMIsまたは Amazon EBSスナップショットを使用する

AMI には、以下が含まれます。

• 1 つ以上のスナップショット。 Instance-store-backed には、インスタンスのルートボリューム (オペレーティングシステム、アプリケーションサーバー、アプリケーションなど) のテンプレートAMIsが含まれます。

• インスタンスを起動AMIするために を使用できる AWS アカウントを制御する起動アクセス許可。

• インスタンスの起動時にインスタンスにアタッチするボリュームを指定するブロックデバイスマッピング

AMIs を使用して、事前設定されたソフトウェアとデータを使用して新しいインスタンスを起動できます。ベースラインを確立するAMIsときに を作成できます。これは、より多くのインスタンスを起動するための再利用可能な設定です。既存のEC2インスタンスAMIの を作成すると、インスタンスにアタッチされているすべてのボリュームに対してスナップショットが作成されます。スナップショットにはデバイスマッピングが含まれます。

スナップショットを使用して新しいインスタンスを起動することはできませんが、既存のインスタンス上のボリュームを置き換えるために使用できます。データの破損やボリューム障害が発生した場合は、撮影したスナップショットからボリュームを作成し、古いボリュームを置き換えることができます。スナップショットを使用して新しいボリュームをプロビジョニングし、新しいインスタンスの起動時にアタッチすることもできます。

によって AWS 、または からAMIs維持および公開されるプラットフォームとアプリケーションを使用している場合は AWS Marketplace、データ用に個別のボリュームを維持することを検討してください。データボリュームは、オペレーティングシステムやアプリケーションボリュームとは別のスナップショットとしてバックアップできます。次に、 によって、 AWS または からAMIs新しく更新されたデータボリュームスナップショットを使用します AWS Marketplace。このアプローチでは、新しく公開された の設定情報を含むすべてのカスタムデータを慎重にテストし、バックアップおよび復元する計画が必要ですAMIs。

復元プロセスは、AMIバックアップまたはスナップショットバックアップのどちらを選択するかによって影響を受けます。インスタンスバックアップとして機能するAMIsように を作成する場合は、復元プロセスAMIの一環として からEC2インスタンスを起動する必要があります。衝突の可能性を避けるため、既存のインスタンスをシャットダウンする必要がある場合もあります。潜在的な衝突の例は、ドメイン参加 Windows インスタンスのセキュリティ識別子 (SIDs) です。スナップショットの復元プロセスでは、既存のボリュームをデタッチし、新しく復元したボリュームをアタッチする必要がある場合があります。または、アプリケーションが新しくアタッチされたボリュームを参照するように設定を変更する必要がある場合もあります。

AWS Backup は、インスタンスレベルのバックアップを としてAMIs、ボリュームレベルのバックアップを別々のスナップショットとしてサポートします。

• インスタンス上のすべてのEBSボリュームの完全なバックアップを行うには、Linux または Windows で実行されているEC2インスタンスAMIの を作成します。ロールバックする場合は、インスタンス起動ウィザードを使用してインスタンスを作成します。インスタンス起動ウィザードで、「マイAMIs」を選択します。

• 個々のボリュームをバックアップするには、スナップショット を作成します。スナップショットを復元するには、「スナップショットからボリュームを作成する」を参照してください。 AWS Management Console または AWS Command Line Interface () を使用できますAWS CLI。

インスタンスのコストAMIは、インスタンス上のすべてのボリュームのストレージですが、メタデータのストレージではありません。EBS スナップショットのコストは、個々のボリュームのストレージです。ボリュームストレージコストの詳細については、「Amazon EBSの料金」ページを参照してください。

サーバーボリューム

EBS ボリュームは、Amazon のプライマリ永続ストレージオプションですEC2。このブロックストレージは、データベースなどの構造化データや、ボリューム上のファイルシステム内のファイルなどの非構造化データに使用できます。

EBS ボリュームは、特定のアベイラビリティーゾーンに配置されます。ボリュームは複数のサーバーにレプリケートされ、単一のコンポーネントの障害によるデータの損失を防ぎます。故障とは、ボリュームのサイズと性能に応じて、ボリュームの完全または部分的な喪失を指します。

EBS ボリュームは、年間障害率 (AFR) が 0.1～0.2% になるように設計されています。これにより、EBSボリュームの信頼性は一般的なコモディティディスクドライブの 20 倍になり、約 4% AFRの で失敗します。例えば、1 年間に 1,000 個のEBSボリュームが実行されている場合、1 つまたは 2 つのボリュームに障害が発生することが予想されます。

Amazon は、データのバックアップを取得 point-in-timeするためのスナップショット機能EBSもサポートしています。すべてのEBSボリュームタイプは耐久性のあるスナップショット機能を提供し、99.999% の可用性を実現するように設計されています。詳細については、「Amazon Compute サービスレベルアグリーメント」を参照してください。

Amazon EBSでは、任意のEBSボリュームのスナップショット (バックアップ) を作成できます。スナップショットは、EBSボリュームのバックアップを作成するための基本機能です。スナップショットはEBSボリュームのコピーを取得し、Amazon S3 に配置します。このスナップショットは複数のアベイラビリティーゾーンに冗長的に保存されます。最初のスナップショットはボリュームの完全コピーであり、進行中のスナップショットはブロックレベルの増分変更のみを保存します。Amazon EBSスナップショットの作成方法の詳細については、Amazon EC2ドキュメントを参照してください。

復元オペレーションの実行、スナップショットの削除、スナップショットに関連付けられたタグなどのスナップショットメタデータの更新を、スナップショットを作成したリージョンと同じリージョンの Amazon EC2コンソールから実行できます。

スナップショットを復元すると、フルEBSボリュームデータを含む新しい Amazon ボリュームが作成されます。部分的な復元のみが必要な場合は、実行中のインスタンスに別のデバイス名でボリュームをアタッチできます。次にそれをマウントし、オペレーティングシステムのコピーコマンドを使って、バックアップボリュームから本番ボリュームにデータをコピーします。

Amazon EBSスナップショットは、Amazon EC2ドキュメント で説明されているように、Amazon EBSスナップショットコピー機能を使用して AWS リージョン間でコピーすることもできます。この機能を使用すると、基盤となるレプリケーションテクノロジーを管理しなくても、バックアップを別のリージョンに保存できます。

個別のサーバーボリュームを確立する

オペレーティングシステム、ログ、アプリケーション、およびデータには、すでに標準の個別のボリュームセットを使用している場合があります。個別のサーバーボリュームを確立することで、ディスクスペースの枯渇が原因でアプリケーションやプラットフォームに障害が発生した場合の影響範囲を軽減できます。通常、物理ハードドライブで物理的なハードディスクドライブの場合、ボリュームを迅速に拡張する柔軟性がないため、このリスクは通常より大きくなります。物理ドライブの場合は、新しいドライブを購入してデータをバックアップし、新しいドライブにデータを復元する必要があります。を使用すると AWS、Amazon を使用してプロビジョニングされたボリュームを拡張できるためEBS、このリスクが大幅に軽減されます。詳細については、「AWS ドキュメント」を参照してください。

アプリケーションデータ、ユーザーデータ、ログ、スワップファイル用に別々のボリュームを用意して、これらのリソースに別々のバックアップポリシーと復元ポリシーを使用できるようにします。データ用にボリュームを分けることで、データのパフォーマンスとストレージの要件に基づいて異なるボリュームタイプを使用することもできます。そして、異なるワークロードに対してコストを最適化し、微調整できます。

インスタンスストアボリュームに関する考慮事項

インスタンスストアは、インスタンス用のブロックレベルの一時ストレージを提供します。このストレージは、ホストコンピュータに物理的にアタッチされたディスク上にあります。インスタンスストアは、バッファ、キャッシュ、スクラッチデータ、その他の一時的なコンテンツなど、頻繁に変更される情報の一時的な保存に最適です。また、ウェブサーバーのロードバランストプールなど、複数のインスタンスにまたがってレプリケートされるデータにも適しています。

インスタンスストア上のデータは、関連付けられたインスタンスの運用中のみ維持されます。インスタンスが再ブートされた場合、その再ブートが意図的なものでも、意図せずに行われたとしても、インスタンスストアのデータは維持されます。ただし、次のいずれの状況でも、インスタンスストアのデータは失われます。

• 基盤となるドライブが故障しました。

• インスタンスが停止しました。

• インスタンスが終了します。

したがって、価値のある長期的なデータをインスタンスストアに依存してはなりません。代わりに、Amazon S3、Amazon 、Amazon EBSなどの耐久性の高いデータストレージを使用しますEFS。

インスタンスストアボリュームの一般的な戦略は、復旧ポイント目標 (RPO) と復旧時間目標 () に基づいて、必要に応じて必要なデータを Amazon S3 に定期的に保持することですRTO。その後、新しいインスタンスが起動されたときに、Amazon S3 からインスタンスストアにデータをダウンロードできます。インスタンスが停止する前に、Amazon S3 にデータをアップロードすることもできます。永続化のために、EBSボリュームを作成し、インスタンスにアタッチし、定期的にインスタンスストアボリュームからEBSボリュームにデータをコピーします。詳細については、AWS「 ナレッジセンター」を参照してください。

EBS スナップショットと のタグ付けと標準の適用 AMIs

すべての AWS リソースにタグを付けることは、コスト配分、監査、トラブルシューティング、および通知のための重要なプラクティスです。EBS ボリュームの管理と復元に必要な関連情報が存在するように、ボリュームにはタグ付けが重要です。タグは、EC2インスタンスからソースボリュームへ、AMIsまたはソースボリュームからスナップショットへ自動的にコピーされません。バックアッププロセスには、これらのソースからの関連タグが含まれていることを確認してください。これは、将来これらのバックアップを使用するために、アクセスポリシー、添付ファイル情報、コスト配分などのスナップショットメタデータを設定するのに役立ちます。 AWS リソースのタグ付けの詳細については、「タグ付けのベストプラクティスのテクニカルペーパー」を参照してください。

すべての AWS リソースに使用するタグに加えて、次のバックアップ固有のタグを使用します。

• ソースインスタンス ID

• ソースボリューム ID (スナップショット用)

• 回復ポイントの説明

AWS Config ルールとIAMアクセス許可を使用して、タグ付けポリシーを適用できます。IAM は強制タグの使用をサポートしているため、Amazon EBSスナップショットを操作するときに特定のタグの使用を義務付けるIAMポリシーを記述できます。アクセスIAM許可ポリシーで定義されたタグが権限を付与せずにCreateSnapshotオペレーションを試みた場合、スナップショットの作成は失敗し、アクセスは拒否されます。詳細については、より強力なセキュリティポリシーの作成と実装に関する Amazon EBSスナップショットのタグ付けに関するブログ記事 を参照してください。

AWS Config ルールを使用して、リソースの設定を自動的に評価できます AWS 。開始しやすくするために、 は、マネージドルールと呼ばれる、カスタマイズ可能な事前定義されたルール AWS Config を提供します。独自のカスタムルールを作成することもできます。は、リソース間の設定変更 AWS Config を継続的に追跡しながら、これらの変更がルールの条件に違反していないかどうかを確認します。リソースがルールに違反した場合、 はリソースとルールを非準拠の として AWS Config フラグします。必須タグ管理ルールは現在、スナップショットと をサポートしていないことに注意してくださいAMIs。