EC2インスタンスの自動リカバリー設定を改めて説明する（CloudWatch Alarm)

渡辺聖剛

2017.09.04

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

一部条件付きですが、EC2インスタンスにアラームを設定して、StatusCheckFailedなどの特定条件で自動的に再起動させたりすることができます。

このブログでも過去に紹介している記事がいくつもあるのですが、時間もそこそこ経っているので、改めて紹介したいと思います。

できること

アクションとして設定できるのは下記の 4種類です。

EC2インスタンスの停止 (Stop)
EC2インスタンスの削除 (終了、Terminate)
EC2インスタンスの再起動 (Restart)
EC2インスタンスの復元 (復旧、Stop / Start)

これらのアクションを取らせるための条件は、下記のいずれかになります。

CPU使用率(%)
ディスク読み取り / 読み取り操作
ディスク書き込み / 書き込み操作
ネットワーク入出力
ステータスチェックに失敗 (すべて / インスタンス / システム)

なお、CloudWatchアラームの画面から設定すれば、EC2インスタンスで取得するメトリクスすべてが条件として選択できます。¹

アラームは複数設定できるので、例えば

「ステータスチェック(インスタンス)に2回失敗したら再起動」「ステータスチェック(システム)に3回失敗したら復元」

といった二段構えにすることも可能です。²

ただし、「復元 (Stop / Start)」アクションを設定するには条件を「ステータスチェックに失敗 (システム)」にするしかないので、そこも注意してください。

ちなみにアラームは「リージョンごとに最大で 5,000」という制限があるので、その範囲におさめる必要があります。

対象EC2インスタンスの条件

「EC2インスタンスの復元」アクションを実施する場合にのみ、設定できるEC2インスタンスに条件がつきます。

C3、C4、M3、M4、R3、R4、T2、または X1 インスタンスタイプを使用している
VPC (EC2-Classic 以外) で実行されている
共有テナンシーを使用している (テナンシー属性が default に設定されている)
EBS ボリュームのみを使用します (インスタンスストアボリュームは設定しないでください)

なお、ドキュメントの同じところに、

インスタンスにパブリック IP アドレスが割り当てられている場合、復旧後に同じパブリック IP アドレスが維持されます。

と書いてあります。

「インスタンスの復元」アクションは「ステータスチェック(システム)」を条件にするしかなく、これは簡単に発生させることができないので未検証ですが。。。通常の Stop / Start だと、EIPを使っていない限りパブリックIPアドレスは変更されるものなので、この機能はうれしいですね。

Amazon CloudWatch アラームへの復旧アクションの追加 - インスタンスを停止、終了、再起動、または復旧するアラームを作成する - Amazon Elastic Compute Cloud

設定方法

実際に設定してみます。簡単に試験できるように「ステータスチェック(インスタンス)に、1分間隔で2回失敗したら再起動する」にしてみましょう。

また、アラームの作成方法はいくつかあるのですが、比較的わかりやすそうな、EC2のマネジメントコンソールから設定する方法でやってみます。

まず、マネジメントコンソールにて対象となる EC2インスタンスを選択、「アクション」から「CloudWatch のモニタリング」>「アラームの追加/編集」をクリックします。

表示されたダイアログで「アラームの作成」をクリックします。

「アラームの作成」ダイアログが表示されたら、下記のように設定します。

「通知の送信先」チェックボックスは外す
「アクションを実行」にチェックを入れる
「このインスタンスの再起動」にチェックを入れる
「次の時:」プルダウンメニューから「ステータスチェックに失敗(インスタンス)」を選択
「最低期間」を設定。今回は図のようにしました
アラーム名は適当にわかりやすい名前をつけます。デフォルトのままでも良いでしょう

また、初めてアクション付きのアラームを作成する際には「IAM ロールの作成: EC2ActionsAccess」というチェックリストも表示されるので、こちらにもチェックを入れてください。

問題なければ「アラームの作成」をクリックします。

実験

それでは、実際に「ステータスチェック(インスタンス)」が失敗する状況を作ってみましょう。

このチェックは該当EC2インスタンスのネットワークがダウンしても検知されるので、SSH でログインしてインターフェースを落としてみます。

※ 当然ですがこの操作をすると、再起動されるまで該当インスタンスとの通信が全て出来なくなります。ご注意ください！

# 念のためインスタンスIDを確認
$ curl http://169.254.169.254/latest/meta-data/instance-id ; echo
i-0388d7f30b179092f

# インターフェース停止
$ sudo ifdown eth0
(以後無反応、のちタイムアウト)

数分待つと、見事に異常を CloudWatch アラームが検知し、再起動処理が開始されました。そのログ(履歴)は、マネジメントコンソールの CloudWatch > アラームの画面で確認することが可能です。

さいごに

様々な要因から、EC2インスタンスが意図せず停止したり異常をおこしたりすることは、残念ながら完全には避けられません。

AutoScalingなどのヒーリング対策がされていないインスタンスがあれば、そしてそれらが「再起動すれば治る (再起動することにあまり複雑な手順や考慮が必要ない)」という運用がされているのであれば、こういった機能を使うことも、是非視野に入れてみてください。

ここだけの話、英語版の EC2 マネジメントコンソールだともうちょっと選択できる項目が増えます ↩
このドキュメントに「重要」として、「再起動と復旧アクションの競合状態を避けるには、Amazon EC2 インスタンスを再起動するアラームを作成するときに、アラームのしきい値として 1 分に代えて 3 分を設定することをお勧めします。」との記載があります。設定する際には参考にしてください。 ↩