3
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

AWSでAuto Recoveryを意図的に発生させたい

Last updated at Posted at 2019-05-12

Auto Recovery発動後のEC2の動作確認がしたかったので、方法を調べてみました。
StatusCheckFailed_Systemを意図的に失敗させる方法がわかればAuto Recoveryを発動させることができると考えていたのですが、うまくいかず・・・。
結論からいうと「Auto Recoveryを意図的に発生させることはできない」になるのですが、やったことをまとめます。

検証環境

  • Windows Server 2016

やったこと

  • ネットワークインターフェースを無効にする
  • AWSのサポートセンターに問い合わせる

ネットワークインターフェースを無効にする

GUIでネットワークインターフェースを無効にしました。
ステータスチェック2.png
結果・・・
システムステータスのチェックではなく、インスタンスステータスのチェックが失敗になりました。
ステータスチェック.png

AWSのサポートセンターに問い合わせる

以下のような回答をいただきました。

大変恐れ入りますが、StatusCheckFailed_System のステータスチェック失敗を意図的に発生させる方法は提供しておりません。
ご要望を満たすことができる方法ではないかもしれませんが、AWS CLIの「set-alarm-state」を使用し、設定されたアラームを意図的に発報することは可能でございます。
以下に、コマンドの例を記載させていただきます。
aws cloudwatch set-alarm-state --alarm-name <アラーム名> --state-reason <任意の理由> --state-value ALARM
このような方法でアラームを発報した場合、実際にAWS基盤の障害が発生している状況ではございませんが、CloudWatchアラームが動作するかのテストは可能であると考えられます。

StatusCheckFailed_Systemを意図的に発生させる方法はないとのことでしたが、一応上記のコマンドを実行してみました。
ステータスチェック3.png

その結果・・・
CloudWatchでアラームの履歴を確認してみると以下のようになっており、短時間の間に状態が変わったことがわかりました。
しかしAuto Recoveryが発動した気配はありません。
autorecovery_test.png

そこでメールをチェックしてみると、契約アカウントに以下のメールが届いてました。
message.png
・・・手動でアラームのステータスを変えたことがばれていましたね。。

結論

Auto Recoveryを意図的に発生させることはできない。

3
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?