［AWS］他リージョンにバックアップしたリソースをリストアする際に気をつけること(EC2,RDS)

AWSのEC2やRDSで他のリージョンでバックアップから立ち上げる際、何点か気をつける点があると思いましたので纏めてみました。
※上げている内容以外でもあればご指摘いただけますと幸いです。

今回の前提

東京リージョンで運用、大阪リージョンでバックアップを取っている場合を想定
AWS上にあるADサーバに参加している
※2021/9/9時点の情報です。

EC2

インスタンスタイプを確認

リージョンによって対応可能なサービスは異なりますが、対応可能なインスタンスタイプも制限があります。
例えば、東京リージョンでt3a系を利用していた場合、大阪リージョンでt3a系は対応していないので立ち上げることはできません。
また、t2系において、東京は複数のアベイラビリティゾーンで利用可能ですが、大阪は1つのアベイラビリティゾーンのみ対応しています。
バックアップ先で利用できないインスタンスタイプについては、事前にインスタンスタイプの変更を推奨いたします。
インスタンスタイプ変更については下記ドキュメントに纏まっています。
インスタンスタイプを変更する

利用可能なインスタンスタイプについては、マネジメントコンソール→EC2の画面→”インスタンスタイプ”で見ることが可能です。
リージョンごとの利用できるサービスについては下記ご確認ください。
AWS リージョン別のサービス

Windows初期パスワード取得ができない

Windowsインスタンスの場合、AMIバックアップイメージから復元すると、Windows初期パスワードの取得ができなくなります。
例えばマネジメントコンソールからWindowsパスワードを取得しようとすると下記エラーが出ます。

これは下記ブログで紹介があるのですが、あくまで初期パスワード取得のための機能の為、バックアップから復元はそれに当てはまらないという事になります。

AMIバックアップイメージから復元したWindows EC2インスタンスのパスワード取得について

もし初期パスワードを利用している場合は変更し適切に管理することをお勧めいたします。

また、キーペアにおいてもマネジメントコンソール上だと表示されなくなります。
実際は東京リージョンで立ち上げた時に設定したキーペアが設定されている状態になります。

IP情報が変更になる

ここは理解している方も多いと思いますが、異なるCIDRでVPCを作成する為、利用するサーバーのIP情報も変更になります。
またEIPを利用している場合も、特定のリージョン用サービスなのでリージョンを跨いで移管することができません。

事前に新たなIPを確認するようにしましょう。
IPについては、AMIから復元する時にIPアドレスを新たに指定することが可能です。
その他、変更される項目については下記ブログをご確認ください。

[小ネタ]AWS BackupでEC2をリストアした後に変更される項目や再設定が必要な項目

ADサーバのDNS先を変更

たとえば下記のような構成をしていたとします。

急遽、東京に隕石が落ちてきた等の理由で右側の東京リージョンが使えなくなってしまったとします。

その時に、大阪リージョンでEC2を立ち上げたとしても、対象のサーバは東京リージョンのADを見ている為、DNSの矛先を変更する必要があります。(以下図の状態)

その為、リストアした後にDNSの設定でADサーバに向けるように設定の変更が必要になります。

また、ADの役割(FSMO)を強制的に大阪に持つようにする必要があります。
FSMO強制移管の詳細については下記ブログをご確認ください。

FSMOの役割を他のドメインコントローラに強制する – Active Directory on AWS(5)

リストア後にADに参加した後は、エラーログがないか等を確認するのを推奨いたします。

RDS

エンドポイント名が変わる

RDSをリストアするとエンドポイント名が変更になります。
リージョンが変わると、そもそもエンドポイント名にリージョンの値が入ってるので必然的に変更になります。
アプリケーション等がエンドポイントを参照している場合、変更の手を加える必要があります。

または、どうしても変更したくなければRoute53でドメインを持つ、というやり方があります。

【初心者向け】エンドポイントを持つサービス（RDSなど）とRoute53をセットで使うことのメリット

こちらを行う場合は、事前の仕込みが必要であるのと、動作確認を行っておきましょう。

パラメーターグループ、オプショングループを事前に用意

RDSではパラメーターグループ、オプショングループをカスタムして利用されている方が多いと思います。
これはEC2のセキュリティグループ等もそうですが、事前にバックアップ先で作成しておくようにしましょう。
パラメーターグループではLogの設定等も行なっていると思いますので、事前に同等の設定で用意しておきましょう。

その他留意点

AWS Backupを使ったバックアップの場合、オンラインバックアップの為、OSを止めないと整合性が取れなくなる可能性があります。
Windowsの場合はVSSを検討してください。

Systems ManagerでVSS(Volume Shadow Copy)を利用したスナップショットを取得する

Backupツールについては、AWS Backupか、弊社で無償提供しているOpswitchをご検討ください。
opswitch
AWS Backup

最後に

リストアする際に基本的に注意するべきところを纏めてみました。
あとは環境固有の内容等もあると思いますが、ぜひDR対策の際に参考にして頂けますと幸いです。

上記懸念事項がある為、他リージョンで復元するのは最終手段と考えるのがいいと思います。
まずは、マルチアベイラビリティゾーンで冗長構成を組めるか検討し、最終的手段として必要であればマルチリージョンのDR対策を検討しましょう。
また、必ず、リストアテストを行い、問題ないか洗い出しを行いましょう。
RTO(目標復旧時間)や、RPO(目標復旧ポイント)、コストを考えつつ、見合った要件で環境を整えていくのがよいと思います。
下記ブログのレポートを一読することをお勧めします。

【レポート】マルチリージョン、ちょっとその前に…-サービスの可用性について考える #AWS-53 #AWSSummit

ではまた！コンサルティング部の洲崎でした。