EC2自動復旧Auto Recover紹介

Auto Recoverとは

CloudWatchアラームのアクションの一つとして設定するもので、物理ホストに障害があった場合に仮想マシンをマイグレーションしてくれるものです。

詳細は下記をご覧ください。
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-instance-recover.html

Auto Recover発動全体イメージ

発動流れ：

１．AutoRecoveryの発動条件（Alarm）を定義
２.ステータスチェック（システム）を行う
３．Alarm条件を達成
　３－１．AutoRecoveryを発動
　３－２．定義あるなら、AWS SNSを利用して通知する
４．AutoRecovery発動後、OS、ミドルウェア等の挙動を定義

実行主体

Amazon CloudWatchアラーム

実行契機

システムステータスチェックの失敗の原因となる問題には、次のようなものがあります。

• ネットワーク接続の喪失
• システム電源の喪失
• 物理ホストのソフトウェアの問題
• ネットワーク到達可能性に影響する、物理ホスト上のハードウェアの問題

発動時の挙動

元のインスタンスと同じEC2復旧する

発動後も保持されるデータ

EC2各種情報を引き継ぎます。

• インスタンスID
• プライベートIPアドレス
• パブリックIPアドレス
• Elastic IPアドレス
• メタデータ

注意点

発動には条件があります。

• インスタンスタイプが特定のものであること
• (A1、C3、C4、C5、C5n、Inf1、M3、M4、M5、M5a、M5n、P3、R3、R4、R5、R5a、R5n、T2、T3、T3a、X1、または X1eのいずれかを使用する)
• EBS ボリュームのみ持っている (インスタンスストアボリュームは設定しない)
• defaultまたはdedicatedインスタンステナンシーを使用する
• マイグレーション先の物理ホストに空きが無い場合など、復旧処理に失敗することもあります。

発動後の後続作業

• 発動後はEC2各種情報を引き継ぎますので、パラメータシートより各種設定データが復元できるか確認作業を行う必要になります、
• 発動時のメモリデータや接続セッションなど、永続化していないデータがなくなるので、要確認。
• 連携がある他のサービス確認が必要、Lambda、ELB、EFSなど