CloudWatch AlarmのAuto Recoveryに触れる

こんにちは、網走の大村です。
CloudWatch Alarmで設定できるEC2のAuto Recoveryついて調べました。

発端

EC2の標準メトリクスだけで何かアラート設定したいけどオススメある？と社内Slackで軽く聞いてみたところ、 Auto Recovery を設定する機会が多いかも。よかれと思ってアラート設定してもアラート大量に飛んできても迷惑だよね。との声。お客様から監視についての要望がないときや、とくに運用面まで深く考えている時間がない、運用担当者はいないから兼務で頑張ります!というお客様のときに役に立つアラートは何かと考えたところ、単体のEC２インスタンスなら Auto Recovery はあって損はないだろうという押し付けがましい結論に至り調べました。

なにが嬉しいの？

Auto Recoveryを設定しておくとAWSの基盤の問題でEC2インスタンスが落ちたとき自動的にインスタンスの停止開始してくれる。なにか障害が起きたら担当者が手動で停止開始しますが一次対応くらいの運用なら自動的にやってくれたら助かる、とくに夜間。

Auto Recoveryの設定方法

設定はこちらを参考に、せっかくなので簡単に說明します。
【新機能】EC2 Cloudwatchの新機能「Auto Recovery」を使ってみた | Developers.IO

Auto Recoveryとは

EC2インスタンスの システムステータスチェック が失敗したときに、EC2のインスタンスを自動的に停止/開始を実行してくれるCloudWatch Alarmの機能です。

システムステータスとは

EC2インスタンスが実行されているAWSの基板側の状態（死活監視）です。

インスタンスが実行されているAWSシステムを監視します。これらのチェックでは、修復には AWS の関与が必要なインスタンスの根本的な問題が検出されます。システムステータスチェックが失敗した場合、AWS が問題を解決するのを待つか、自分で解決できるかを選択できます。Amazon EBS でバックアップされたインスタンスの場合は、インスタンスを自分で停止および起動することができます。通常、インスタンスは新しいホストに移行されます。インスタンスストアによってサポートされているインスタンスの場合、インスタンスを終了して置き換えることができます。

システムステータスチェックの失敗の原因の例

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

私の勘違い

Auto Recoveryの機能は知っていたものの前職では使っていませんでした。職場の環境にもよると思いますが...手動でEC2インスタンスを停止しても勝手に起動してくるんじゃないの？それだと設定入っていることを知らない人と後々面倒毎になりそうだからいいやと勝手に思っていました。調べてみるとどうやらそんなことはないとわかり、とは言え不安なので確認してみました。

検証してみた

意図的にシステムチェックの失敗は引き起こせないのでAuto Recoveryのテストができないとググるとでてくるが、どういうことかいまいち理解できないので試してみました。

CloudWatch Alarmを設定

ステータスチェックに対してこのインスタンスを復旧を選択して、Auto Recoveryの設定をしました。

EC2インスタンスを手動停止した場合

EC2インスタンスをマネージドコンソールから手動で停止をクリックした。

結果

アクションが失敗しており停止/開始が実行されないため、EC2インスタンスは停止したまま。なにか設定間違ってたのかな、IAMロールでEC2に対する権限必要だったのかなと自分の設定を疑う。

エラーメッセージを見ても理由はわからない。

{
  "actionState": "Failed",
  "stateUpdateTimestamp": 1594792768753,
  "notificationResource": "arn:aws:automate:ap-northeast-1:ec2:recover",
  "publishedMessage": null,
  "error": null
}

CloudWatch Alarmのしきい値を変更した場合

正常時は0のため、しきい値を0以上にすることにより、EC2インスタンスが起動しているだけで異常になりアラートがあがる想定。

結果

想定通りアラートになり、復旧のアクションが実行されました。設定に間違いはなかったようです。

しかし、停止/開始された気配はなく、uptimeから起動したままであることがわかる。

$ uptime -p
up 1 hour, 20 minutes

AWSサポートからメールが届いていた。

• 件名：[Auto Recovery] Amazon EC2 instance recovery: No action taken [AWS Account: 000000000000]

なぜアクションが実行されなかったのか？ EC2自動リカバリは、処理を進める前にインスタンスのシステムの健全性を再検証します。この検証ステップでは、インスタンスが健全であると報告したため、リカバリは開始されませんでした。※DeepL翻訳

EC2インスタンスが正常だということはバレていた。

もうひと工夫

EC2インスタンスにダメな感じを出してみます。NICを落としてインスタンスチェックをエラーにします。

sudo ip link set eth0 down

こうなりました。EC2インスタンスに異常でている感が出でてます。再度アラートを出すために、一度しきい値を1に戻しアラートを復旧させてから、再度0に変更しアラートを出します。

結果

同じメールがAWSサポートから届きました。AWS基盤側の障害ではないとやはりAuto Recoveryは発動しないということなんでしょう。だから、Auto Recoveryのテストはできないと言われているわけを理解できました。

おわりに

お客様にはこういう設定入れますと說明することになるので、運用の体制をヒアリングしてケースバイケースで必要に応じてこの辺は設計したいなと思う。調べる際にドキュメント読んでいたら、ステータスチェックのメトリクスは無料で1分頻度の取得できると知れたのが収穫。デフォルトは何でも5分間隔だと思っていた。

AWS/EC2 名前空間には、次のステータスチェックメトリクスが含まれます。デフォルトでは、ステータスチェックメトリクスは無料で 1 分の頻度で利用できます。

参考

インスタンスのステータスチェック - Amazon Elastic Compute Cloud インスタンスの利用可能な CloudWatch メトリクスのリスト表示 - Amazon Elastic Compute Cloud