この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので十分ご注意ください。
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など