AWS Backupには、EC2インスタンスのバックアップを他のリージョンにとる機能があります。
他のリージョンにバックアップがあれば、普段利用しているリージョンの障害時に、他のリージョンでサービスを再開することができます。
いわゆるDR（Disaster Recovery）です。
今回、東京リージョンからシンガポールリージョンに、バックアップ・リストアしてみました。
[東京リージョン] バックアップ設定
バックアップ取得タイミング
AWS Backupは、バックアップを取得するタイミングとして2通りあります。
- その場で即座に一回だけバックアップする 「オンデマンドバックアップ」
- 毎日とか毎時とか定期的にバックアップする 「バックアッププラン」
試したところ、どちらでも別リージョンにバックアップ取得できました。
ここでは 「バックアッププラン」の設定を紹介します。
バックアッププラン作成
AWS Backupの画面で「バックアッププラン」を作成します。
「バックアッププラン」の中で、次の2つの設定をします。
- スケジューリングやバックアップ先を指定する 「バックアップルール」
- バックアップ対象のEC2インスタンスなどを指定する 「リソース」
バックアッププラン
バックアップルール
今回は1時間単位でバックアップするようにしてみました。
「リージョンにコピーオプション」のところで、シンガポールを指定しました。
なお、「コピーを追加」というところで、さらに別のリージョンもバックアップ先として追加できるようです。
リソース
今回はシンプルに、東京リージョンで動いているEC2インスタンスを１台指定しました。
東京リージョンで確認
「リージョンにコピーオプション」でシンガポールを指定しましたが、コピー元である東京にもバックアップが作成されます。
[シンガポールリージョン] リストア実行
バックアップがコピーされていることを確認
1時間ごとにバックアップがコピーできているのがわかります。
AMIやスナップショットが、シンガポール側にも作成されてますね。
リストア実行
保護されたリソースから、復旧ポイントのAMIを指定
起動パラメータを指定
バックアップ取得元と同じリージョンでリストアする場合は、インスタンスタイプやセキュリティグループなどは元の情報を引き継ぐことが可能です。
しかし、今回のように別リージョンの場合は、バックアップ取得元インスタンスの情報を引き継げるのは、IAMロールだけです。
手動で適切に設定を入れて「バックアップを復元」ボタンをクリックします。
復元ジョブが終わるのを待つ
実行中となるので、完了となるまで待ちます。
なお、「失敗しました」となる場合があります。
一つ前の画面で「デフォルトのロール」を指定していますが、これは AWSBackupDefaultServiceRole というIAMロールを指していますが、このロール内のポリシーに「iam:PassRole」が入っていないのが原因と思われます。
ワークアラウンドとしては、以下の2つを検討してください。
- AWS Backup用に、より権限の強いロールを作成して指定する
- 「インスタンス IAMロール」を指定しない
完了
今回のテストでは、デフォルト状態の8GiBのAmazonLinux2をリストアしましたが、約10分かかりました。
EC2の画面をみると、しれっと起動してますね。
感想
AWS BackupはDRで利用を検討できるソリューションの一つと思います。
とはいえ、AWS Backupで全てできるかというとそうでもない気もします。
EC2周辺のことだけでも、セキュリティグループ、ELBとか、まだまだ色々考える必要がありますね。
渡辺 信秀(記事一覧)
2017年入社 / 地味な内容を丁寧に書きたい
