カスタマーサクセス部の山﨑です。
今回はEC2インスタンスのバックアップを取得する3つの方法を比較検討してみます
はじめに
バックアップとリストア
みなさんはプライベートでとても大切にしている写真、仕事で利用する書類データをうっかり削除してしまってめちゃくちゃ焦った経験はありませんか?
このような万が一が起こった時のために、データをコピー・保存しておくとこでデータが完全に失われることを回避することができます。このようにデータの紛失や損失、破損などに備えて予めデータを別の保管場所に保存しておくことを「バックアップ」と呼び、バックアップから復元することを「リストア」と呼びます。
データの紛失や損失、破損は人によるミスだけではなく、機器の故障やシステムのバグ、ウイルス感染等が原因となることがあります。
- ヒューマンエラー:誤操作によって、重要なファイルを削除してしまった際、バックアップがあれば迅速に復旧させることができます。
- データの保護:何らかの理由で重要なデータが消えてしまったらめちゃくちゃ焦ります。昨今ではウイルスやランサムウェアによってデータが消失する危険もあります。しかし、バックアップがあれば、データの喪失を最小限(RPOの範囲内)に抑えることができます。
- 復旧時間の短縮:問題が発生しても、バックアップからすぐに復旧できれば、サービスのダウンタイムを短くできます。
- コンプライアンス対応:業界業種によっては、データの保存期間やバックアップの取得が法律や標準で定められている場合もあります。
こういったとき、最新のバックアップがあれば、迅速にシステムを復旧できます。
AWSにおいても例外ではなく、EC2インスタンスやRDS DBインスタンス等のリソースのバックアップも、災害や障害からの速やかな復旧に不可欠です。本ブログでは、主にEC2インスタンスのバックアップ、特にAMI取得にフォーカスして筆を進めていきます。
EC2インスタンスのバックアップを取得する3つの方法
EC2インスタンスにおいて、バックアップを取得する方法は大きく分けると以下の3つがあります。本ブログではこれらについて比較検討していきたいと思います。
- 手動AMI作成
- Amazon Data LifeCycle Manager(DLM)
- AWS Backup
結論
手動AMI作成が適しているユースケース
- EC2インスタンスに対して作業を行う際、作業開始直前にAMIを取得したい
Amazon Data Lifecycle Manager (DLM)が適しているユースケース
- EC2 インスタンスや EBS ボリュームのバックアップを手軽に、コスト効率良く自動化したい(デフォルトポリシー)
- AMI取得前にEC2インスタンスを再起動して、データ整合性を確保したい(カスタムポリシー)
- データの一貫性は保証されるが、同時に複数のインスタンスが再起動する可能性があるので注意
- 検証用AWSアカウントでサクッとAMIとEBSスナップショットを取得したい
AWS Backupが適しているユースケース
- EC2 インスタンスだけでなく、他のAWSサービス(RDS、DynamoDB等)のバックアップも一元管理したい
- コンプライアンスやガバナンスの要件を満たしたい
- アクセスポリシーの適用や、Vault Lock、監査ログの取得など、企業のコンプライアンス要件に対応できる各種機能が備わっている
簡易比較表
比較項目 | 手動AMI作成 | Data Lifecycle Manager (DLM) | AWS Backup |
---|---|---|---|
学習難度 | 低 | 中(機能が限定的) | 高(多機能) |
適用範囲 | 主にEC2インスタンスのAMI作成に限定。 | EBSスナップショットやAMIの管理に特化。 | EC2、RDS、S3など、複数のAWSサービスに対応。 |
自動化 | 手動操作のみ | 自動化が可能。スケジュールに基づいて自動でAMIやスナップショットを作成。 | 自動化が可能。バックアッププランを設定して自動化。 |
設定の柔軟性 | 手動なので詳細な設定が可能だが、手間がかかる。 | ポリシーに基づいて詳細な設定が可能。 | バックアッププランに基づいて設定が可能。 |
コスト | 無料(但し、取得したAMIやスナップショットに料金がかかる) | 左記に同じ | 左記に同じ |
データ整合性 | 手動での再起動や静止点の設定が必要。 | 再起動オプションを設定可能。 | デフォルトでは再起動しないため、別途対応が必要。 |
復元方法 | 取得したAMIから新規インスタンスを起動 | 取得したAMIから新規インスタンスを起動 | 1.取得したAMIから新規インスタンスを起動 2.AWS Backupのリカバリーポイントから復元 (バックアップ取得元インスタンスの各種設定を引き継いで復元可能なので設定ミスが起きづらい) ※詳細モニタリングは引き継げない |
ガバナンス遵守 | 人間による各種設定チェック等が必要 | ライフサイクル管理、リージョン間コピーへの対応が可能 | アクセスポリシーやVault Lock等の各種機能を組み合わせることで対応可能 |
手動AMI作成
コンソール画面またはAWS CLIを用いたバックアップ取得
## AWS CLI aws ec2 create-image \ --instance-id i-1234567890abcdef0 \ --name "My server" \
create-image — AWS CLI 2.18.3 Command Reference
手動でAMIを作成する方法は、最も基本的でシンプルなバックアップ手段ですが、どうしても属人的な対応になります。
そのため、定期的なバックアップや大量のインスタンスのバックアップ取得には手間がかかりますし、ヒューマンエラーやバックアップ漏れのリスクもあります。
EC2インスタンスに対して作業を行う際、作業開始直前のバックアップを取得したい場合に利用することを推奨します。
Amazon Data LifeCycle Manager(DLM)
機能概要
Amazon Data Lifecycle Manager(DLM)を使用すると、EBSスナップショットおよびAMIの作成、保持、削除の自動化に特化しており、以下のようなメリットを享受することができます。
- 定期的なバックアップ・スケジュールを実施することで、データを保護する。
- 監査または内部コンプライアンスによって要求されるバックアップを保持する。
- 古いバックアップを自動削除することで、コストを削減する。
- 別のAWSリージョンまたはAWSアカウントにバックアップをコピーすることで、災害発生時のシステム復旧に備える。
Amazon Data LifeCycle Manager(DLM)はインスタンスの再起動設定によって、データ整合性を確保することができるのも特徴の1つです。但し、複数のターゲットのインスタンスが同時に再起動する可能性があるため注意が必要です
個人的な推しポイント
1. 設定がとにかく簡単
Amazon Data Lifecycle Manager(DLM)はEC2のコンソール画面から簡単に設定できます。
EC2インスタンスのAMIやEBSスナップショットを取得したい、という要件だけであればAmazon Data Lifecycle Manager(DLM)は簡単に設定できるのでオススメです
実装方法に関しては以下のブログをご覧ください。
AWS Backup
機能概要
AWS Backup は、複数の AWS サービスにまたがるデータのバックアップを一元的に自動化・管理できるフルマネージドサービスです。これにより、EC2、EBS、RDS、DynamoDB、EFS などのリソースのバックアップポリシーを一括設定し、バックアップのスケジュールや保持期間を統合的に管理できます。
AWS Backupの仕組みや利用方法等については以下のブログも合わせてご覧ください
機能詳細
AWS Backupには以下に示すように多数の機能が実装されており、これらを駆使することで厳しいコンプライアンス要件に対応することができます。
もちろん全ての機能を理解する必要はありませんが、手動AMI作成やAmazon Data LifeCycle Managerと比較すると多機能であるため、学習難度が高いです。
機能例 | 説明 |
---|---|
Backup vault locks | バックアップの不変性を確保するためのメカニズム。設定された期間中、バックアップの削除や変更を防止し、データの完全性を保護。規制要件やコンプライアンス基準を満たすために重要な機能。Write-Once-Read-Many (WORM) モデルを強制し、不正なデータ改ざんや削除から保護。 |
Restore testing | バックアップからの自動リストアテストを設定・実行する機能。定期的なテストにより、バックアップの整合性と復元可能性を確認。災害復旧計画の一部として、バックアップデータの信頼性を継続的に検証し、ビジネス継続性を確保。 |
Cross-account monitoring | 組織内の複数のAWSアカウントにわたるバックアップ活動を一元的に監視。大規模環境でのバックアップ管理を効率化。複数のアカウントやプロジェクトにまたがるバックアップ状況を包括的に把握し、一貫したデータ保護戦略を実施。 |
Backup policies | 組織全体に適用されるバックアップポリシーを定義・管理。複数のアカウントに一貫したバックアップ戦略を適用可能。中央集権的なポリシー管理により、組織全体でのコンプライアンス遵守とデータ保護標準化を実現。 |
Frameworks (Backup Audit Manager) | コンプライアンス要件に基づいたバックアップ監査フレームワークを定義。組織のデータ保護ポリシーの遵守状況を評価。業界標準や規制要件に基づいたカスタム監査フレームワークを作成し、継続的なコンプライアンス監視を自動化。 |
Reports (Backup Audit Manager) | バックアップ活動とコンプライアンス状況に関する詳細なレポートを生成。監査やコンプライアンス証明のためのドキュメントを提供。定期的な報告書や即時のコンプライアンス状況確認が可能となり、内部監査や外部監査への対応を効率化。 |
個人的な推しポイント
1. リストア時の設定ミスが起きにくい(復元が容易)
AWS Backupでは「リカバリーポイント」と呼ばれるバックアップからEC2インスタンスを復元します。
この時、リカバリーポイント(バックアップ)取得元のEC2インスタンスの設定情報(VPC、サブネット、IAMロール、Security Group、タグ等)が引き継がれて自動入力されています。
手動AMI作成やAmazon Data LifeCycle Managerを利用して取得したバックアップからEC2インスタンスを復元する場合、取得したAMIから新規インスタンスを起動することになります。そのため、EC2インスタンスを配置するVPCやサブネット等の各種情報をイチから設定する必要があります。
有事の際にバックアップからEC2インスタンスを復元する場合、少なからず気持ちは焦っているはずなので、復元時にヒューマンエラーによる設定ミスが起こる可能性があります。AWS Backupからリストアする場合は、取得元EC2インスタンスの各種設定情報が引き継がれて自動入力されているので、設定ミスを減らすことができます。(ただし、詳細モニタリングは有料機能ということもあってか設定は引き継がれません)
2. EC2のコンソール画面からはバックアップを削除できない
AWS Backupで取得したAMIバックアップは、AWS Backupのコンソール画面からのみ削除可能です。そのため、EC2のコンソール画面からの誤削除を防止できます。
3. アクセスポリシーでバックアップへのアクセス制御ができる
AWS Backupで取得したAMIバックアップは「Vault」と呼ばれる保管庫に格納されます。このVaultにはS3のバケットポリシーのように、アクセスポリシーを定義することができます。
IAMポリシーでユーザーやロールごとに、AWS Backupへの最小権限のアクセスを許可するのは面倒です。そういった時にVaultのアクセスポリシーを定義しておけば、IAMポリシーで多少広い権限を許可していたとしても、リカバリーポイントの削除等のクリティカルな操作は明示的に拒否することができます。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Principal": "*", "Action": [ "backup:DeleteBackupVault", "backup:DeleteRecoveryPoint", "backup:PutBackupVaultAccessPolicy", "backup:DeleteBackupVaultAccessPolicy", "backup:UpdateRecoveryPointLifecycle", "backup:DisassociateRecoveryPoint", "backup:PutBackupVaultLockConfiguration" ], "Resource": "*", "Condition": { "ArnNotEquals": { "aws:PrincipalArn": "arn:aws:iam::111111111111:role/sample-role" } } } ] }
まとめ
以上、AWSにおけるEC2インスタンスのバックアップを行う3つの方法について、特徴と適したユースケースをご紹介しました。それぞれに異なる利点があるため、ニーズに応じたバックアップ方法を選択することが重要です。
例えば、簡易なバックアップには手動AMI作成やDLM、複数リソースの一元管理にはAWS Backupが適しています。ぜひ今回の比較を参考に、効率的で信頼性の高いバックアップ戦略を設計してみてください。
山﨑 翔平 (Shohei Yamasaki) 記事一覧はコチラ
カスタマーサクセス部所属。2019年12月にインフラ未経験で入社し、AWSエンジニアとしてのキャリアを始める。2023 Japan AWS Ambassadors/2023-2024 Japan AWS Top Engineers