AWS障害が発生したEC2インスタンスをQ Developer CLIで調査、再発防止策も聞いてみた
先日、意図せず停止したEC2インスタンスについて調査したところ、AWS側に起因する StatusCheckFailed_System メトリクスが記録されていました。
この調査の際、Amazon Q Developer CLI の有効性を検証する機会がありましたので、その結果を紹介します。
システムステータスチェックの失敗の原因となる問題の例を次に示します。
- ネットワーク接続の喪失
- システム電源の喪失
- 物理ホストのソフトウェアの問題
- ネットワーク到達可能性に影響する、物理ホスト上のハードウェアの問題
実行環境
Amazon Linux 2023 (x86_64) 環境に、ZIPファイル版のインストーラを使用して Amazon Q Developer CLI (以下、Q CLI) をインストールしました。
curl --proto '=https' --tlsv1.2 -sSf "https://desktop-release.q.us-east-1.amazonaws.com/latest/q-x86_64-linux.zip" -o "q.zip"
unzip q.zip
./q/install.sh
Q CLI のバージョンは1.10.2でした。
$ q --version
q 1.10.2
Amazon Q Developer は、AWS Builder ID で登録して利用できる無料版を使用しました。
$ q login
✔ Select login method · Use for Free with Builder ID
Confirm the following code in the browser
Code: ***-***
Open this URL: https://view.awsapps.com/start/#/device?user_code=***-***
IAM認証は、変更・書き込み権限のない読み取り専用のロールから取得した一時的な認証情報(Temporary Security Credentials)を、環境変数に設定して利用しました。
export AWS_ACCESS_KEY_ID=XXXXXXXXXXXXXXXXXXXX
export AWS_SECRET_ACCESS_KEY=YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
export AWS_SESSION_TOKEN=ZZZZZZZZ
q chat
コマンドを利用して対話形式で調査を進めました。
$ q
⢠⣶⣶⣦⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣤⣶⣿⣿⣿⣶⣦⡀⠀
⠀⠀⠀⣾⡿⢻⣿⡆⠀⠀⠀⢀⣄⡄⢀⣠⣤⣤⡀⢀⣠⣤⣤⡀⠀⠀⢀⣠⣤⣤⣤⣄⠀⠀⢀⣤⣤⣤⣤⣤⣤⡀⠀⠀⣀⣤⣤⣤⣀⠀⠀⠀⢠⣤⡀⣀⣤⣤⣄⡀⠀⠀⠀⠀⠀⠀⢠⣿⣿⠋⠀⠀⠀⠙⣿⣿⡆
⠀⠀⣼⣿⠇⠀⣿⣿⡄⠀⠀⢸⣿⣿⠛⠉⠻⣿⣿⠛⠉⠛⣿⣿⠀⠀⠘⠛⠉⠉⠻⣿⣧⠀⠈⠛⠛⠛⣻⣿⡿⠀⢀⣾⣿⠛⠉⠻⣿⣷⡀⠀⢸⣿⡟⠛⠉⢻⣿⣷⠀⠀⠀⠀⠀⠀⣼⣿⡏⠀⠀⠀⠀⠀⢸⣿⣿
⠀⢰⣿⣿⣤⣤⣼⣿⣷⠀⠀⢸⣿⣿⠀⠀⠀⣿⣿⠀⠀⠀⣿⣿⠀⠀⢀⣴⣶⣶⣶⣿⣿⠀⠀⠀⣠⣾⡿⠋⠀⠀⢸⣿⣿⠀⠀⠀⣿⣿⡇⠀⢸⣿⡇⠀⠀⢸⣿⣿⠀⠀⠀⠀⠀⠀⢹⣿⣇⠀⠀⠀⠀⠀⢸⣿⡿
⢀⣿⣿⠋⠉⠉⠉⢻⣿⣇⠀⢸⣿⣿⠀⠀⠀⣿⣿⠀⠀⠀⣿⣿⠀⠀⣿⣿⡀⠀⣠⣿⣿⠀⢀⣴⣿⣋⣀⣀⣀⡀⠘⣿⣿⣄⣀⣠⣿⣿⠃⠀⢸⣿⡇⠀⠀⢸⣿⣿⠀⠀⠀⠀⠀⠀⠈⢿⣿⣦⣀⣀⣀⣴⣿⡿⠃
⠚⠛⠋⠀⠀⠀⠀⠘⠛⠛⠀⠘⠛⠛⠀⠀⠀⠛⠛⠀⠀⠀⠛⠛⠀⠀⠙⠻⠿⠟⠋⠛⠛⠀⠘⠛⠛⠛⠛⠛⠛⠃⠀⠈⠛⠿⠿⠿⠛⠁⠀⠀⠘⠛⠃⠀⠀⠘⠛⠛⠀⠀⠀⠀⠀⠀⠀⠀⠙⠛⠿⢿⣿⣿⣋⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠈⠛⠿⢿⡧
╭─────────────────────────────── Did you know? ────────────────────────────────╮
│ │
│ You can use /editor to edit your prompt with a vim-like experience │
│ │
╰──────────────────────────────────────────────────────────────────────────────╯
/help all commands • ctrl + j new lines • ctrl + s fuzzy search
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
障害調査
Q CLI に、日本語でEC2インスタンスのARNと障害が確認されたおおよその日時を伝え、障害調査を依頼しました。
障害調査プロンプト
EC2(arn:aws:ec2:ap-northeast-1:XXXXXXXXXXXX:instance/i-XXXXXXXXXXXXXXXXX)2025/5/27 13時台(JST)で発生した、ステータスチェックエラーについて報告して。
Q CLI の回答
EC2インスタンス(arn:aws:ec2:ap-northeast-1:XXXXXXXXXXXX:instance/i-XXXXXXXXXXXXXXXXX)の2025年5月27日13時台(JST)に発生したステータスチェックエラーについて確認します。AWS CLIを使用して詳細情報を取得します。
まず、指定されたインスタンスIDのステータスチェックの詳細を確認しましょう。
🛠️ Using tool: use_aws (trusted)
⋮
● Running aws cli command:
Service name: cloudwatch
Operation name: get-metric-statistics
Parameters:
end-time: "2025-05-27T05:00:00Z"
namespace: "AWS/EC2"
start-time: "2025-05-27T04:00:00Z"
metric-name: "StatusCheckFailed"
statistics: ["Maximum"]
dimensions: [{"Name":"InstanceId","Value":"i-XXXXXXXXXXXXXXXXX"}]
period: 300 Profile name: default Region: ap-northeast-1 Label: EC2インスタンスのステータスチェック履歴を取得 ⋮ ● Completed in 0.579s
🛠️ Using tool: use_aws (trusted)
⋮
● Running aws cli command:
Service name: cloudwatch
Operation name: get-metric-statistics
Parameters:
period: 300
statistics: ["Maximum"]
start-time: "2025-05-27T04:00:00Z"
dimensions: [{"Name":"InstanceId","Value":"i-XXXXXXXXXXXXXXXXX"}]
metric-name: "StatusCheckFailed_Instance"
end-time: "2025-05-27T05:00:00Z"
namespace: "AWS/EC2" Profile name: default Region: ap-northeast-1 Label: EC2インスタンスのステータスチェック詳細を取得 ⋮ ● Completed in 0.518s
🛠️ Using tool: use_aws (trusted)
⋮
● Running aws cli command:
Service name: cloudwatch
Operation name: get-metric-statistics
Parameters:
metric-name: "StatusCheckFailed_System"
statistics: ["Maximum"]
dimensions: [{"Name":"InstanceId","Value":"i-XXXXXXXXXXXXXXXXX"}]
namespace: "AWS/EC2"
period: 300
end-time: "2025-05-27T05:00:00Z"
start-time: "2025-05-27T04:00:00Z" Profile name: default Region: ap-northeast-1 Label: EC2インスタンスのシステムステータスチェック詳細を取得 ⋮ ● Completed in 0.502s
🛠️ Using tool: use_aws (trusted)
⋮
● Running aws cli command:
Service name: ec2
Operation name: describe-instance-status
Parameters:
instance-ids: ["i-XXXXXXXXXXXXXXXXX"] Profile name: default Region: ap-northeast-1 Label: EC2インスタンスの現在のステータスを取得 ⋮ ● Completed in 0.625s
Q CLI は内部で use_aws ツール(AWS CLI)を実行し、CloudWatch のメトリクスや EC2 のインスタンスステータス情報を自動的に収集しました。
Q CLI の報告
EC2インスタンスステータスチェックエラー報告
対象EC2インスタンス: i-XXXXXXXXXXXXXXXXX (arn:aws:ec2:ap-northeast-1:XXXXXXXXXXXX:instance/i-XXXXXXXXXXXXXXXXX)
日時: 2025年5月27日 13時台 (JST) / 04:00-05:00 (UTC)
エラー発生状況
2025年5月27日13時台(JST)において、対象EC2インスタンスで複数回のステータスチェックエラーが発生しました。具体的には以下の時間帯でエラーが検出されました:
• 13:40 JST (04:40 UTC): インスタンスチェック失敗およびシステムチェック失敗
• 13:45 JST (04:45 UTC): インスタンスチェック失敗およびシステムチェック失敗
• 13:50 JST (04:50 UTC): システムチェック失敗
• 13:55 JST (04:55 UTC): システムチェック失敗
エラーの種類
システムステータスチェック失敗: AWS側のネットワークやハードウェアの問題を示します。
インスタンスステータスチェック失敗: インスタンスのオペレーティングシステムやソフトウェア構成の問題を示します。
現在の状態
現在のインスタンスステータスは「running」で、すべてのステータスチェック(インスタンス、システム、EBSボリューム)は「passed」となっており、問題は解決されています。
考えられる原因
一時的なハードウェア障害
ホストサーバーのメンテナンス
ネットワーク接続の一時的な問題
基盤となるAWSインフラストラクチャの問題
推奨アクション
インスタンスのシステムログを確認し、エラー発生時の詳細情報を収集
CloudWatchアラームを設定して、今後同様の問題が発生した場合に通知を受け取る
自動復旧を設定して、ステータスチェック失敗時に自動的にインスタンスを回復させる
重要なワークロードの場合は、マルチAZ構成を検討して可用性を向上させる
オートリカバリー設定
Q CLI から提示された推奨アクションに基づき、EC2インスタンスの自動復旧(オートリカバリー)設定について、さらに質問してみました。
CloudWatchアラーム
推奨アクション として案内された 「3. 自動復旧を設定して、ステータスチェック失敗時に自動的にインスタンスを回復させる」 を 今回のインスタンスに対し設定したいです。CloudShellのCLIで自動復旧、オートリカバリー設定を反映する方法と、月額費用への概算を教えて。
EC2インスタンスの自動復旧(オートリカバリー)設定をCloudShellのCLIで行う方法と、その費用について説明します。
## CloudShellでの自動復旧設定方法
EC2インスタンスの自動復旧は、CloudWatch アラームと組み合わせて設定します。以下のコマンドで設定できます:
bash
# 1. CloudWatch アラームを作成して自動復旧アクションを設定
aws cloudwatch put-metric-alarm \
--alarm-name "AutoRecovery-i-XXXXXXXXXXXXXXXXX" \
--alarm-description "Auto recover EC2 instance on status check failure" \
--metric-name "StatusCheckFailed_System" \
--namespace "AWS/EC2" \
--statistic "Maximum" \
--period 60 \
--threshold 1 \
--comparison-operator "GreaterThanOrEqualToThreshold" \
--dimensions Name=InstanceId,Value=i-XXXXXXXXXXXXXXXXX \
--evaluation-periods 2 \
--alarm-actions "arn:aws:automate:ap-northeast-1:ec2:recover" \
--region ap-northeast-1
このコマンドは、システムステータスチェックが2分間連続で失敗した場合に、自動的にインスタンスの復旧を試みるCloudWatchアラームを作成します。
## 月額費用への影響
EC2インスタンスの自動復旧機能自体には追加料金はかかりません。ただし、CloudWatchアラームには以下の費用が発生します:
• CloudWatch アラーム: $0.10/アラーム/月
• CloudWatch メトリクス: 基本モニタリングは無料(5分間隔)
したがって、この自動復旧設定による追加費用は、月額約$0.10(約15円)のみです。
## 注意事項
1. 自動復旧は以下の場合にのみ機能します:
• システムステータスチェック失敗の場合
• インスタンスが専有ホストで実行されていない場合
• インスタンスタイプが自動復旧をサポートしている場合
2. 自動復旧プロセスでは:
• インスタンスは同じ物理ホスト上で再起動されます
• インスタンスID、プライベートIPアドレス、Elastic IPアドレス、EBSボリューム、インスタンスメタデータは保持されます
3. 自動復旧が失敗した場合は、手動での対応が必要になります
この設定により、今回のようなシステムステータスチェック失敗が発生した場合に、自動的にインスタンスの復旧が試みられ、サービスの可用性が向上します。
CloudWatch アラームを利用した自動復旧設定の CLI コマンドと、関連する費用についての説明が得られました。
オートリカバリオプション
CloudWatch アラームを利用する方法以外にも、EC2 インスタンス自体の設定で自動復旧を有効にできる、2022年のアップデートで追加されたオプションがあります。
この方法について Q CLI に確認してみました。
CloudWatchアラームを利用せずModifyInstanceMaintenanceOptions で AutoRecovery 設定は可能?
EC2インスタンスの自動復旧設定は、CloudWatchアラームを使用せずにModifyInstanceMaintenanceOptions APIを使って直接設定することが可能です。これはより簡単なアプローチで、インスタンスの復旧設定をよりシンプルに行えます。
AWS CLIを使用する場合は、以下のコマンドで設定できます:
bash
aws ec2 modify-instance-maintenance-options \
--instance-id i-XXXXXXXXXXXXXXXXX \
--auto-recovery default \
--region ap-northeast-1
--auto-recoveryパラメータには以下の値を指定できます:
• default: 自動復旧を有効にします(推奨)
• disabled: 自動復旧を無効にします
このアプローチにはCloudWatchアラームを使用する方法と比較して、いくつかの利点があります:
1. 設定がシンプル - アラームを作成する代わりに1つのコマンドで済みます
2. CloudWatchの追加コストがかかりません
3. EC2インスタンスのプロパティとして直接管理されます
自動復旧機能は同じように動作し、基盤となるハードウェアの問題やAWSの問題によってインスタンスが損なわれた場合に復旧します。
ただし、この機能は特定のインスタンスタイプと構成でのみ利用可能です。お使いのインスタンスが自動復旧の対象となっていることを確認してください。
この回答を受け、対象インスタンスがこの機能の対象かどうかを続けて質問しました。
instance-id i-XXXXXXXXXXXXXXXXX は 自動復旧の対象?
インスタンス ID i-XXXXXXXXXXXXXXXXX が自動復旧の対象かどうかを確認するには、まずインスタンスの詳細情報を取得する必要があります。インスタンスタイプによって自動復旧の対象になるかどうかが決まります。
🛠️ Using tool: use_aws (trusted)
⋮
● Running aws cli command:
Service name: ec2
Operation name: describe-instances
Parameters:
- instance-ids: ["i-XXXXXXXXXXXXXXXXX"]
Profile name: default
Region: ap-northeast-1
Label: インスタンスの詳細情報を取得
⋮
● Completed in 0.695s
インスタンス i-XXXXXXXXXXXXXXXXX の詳細情報を確認しました。以下の情報が分かりました:
1. インスタンスタイプ: m6i.xlarge
2. プラットフォーム: Windows
3. 現在の自動復旧設定: disabled (無効)
このインスタンスは自動復旧の対象となります。m6iシリーズのインスタンスは自動復旧をサポートしています。
AWS EC2の自動復旧機能は、以下の条件を満たすインスタンスで利用可能です:
• ほとんどの最新世代のインスタンスタイプ(m6i.xlargeを含む)
• 専有ホストで実行されていないこと
• インスタンスストアボリュームを使用していないこと
• Amazon EC2 Auto Scalingグループの一部でないこと
現在、このインスタンスの自動復旧設定は「disabled」(無効)になっていますが、以下のコマンドで有効にすることができます:
bash
aws ec2 modify-instance-maintenance-options \
--instance-id i-XXXXXXXXXXXXXXXXX \
--auto-recovery default \
--region ap-northeast-1
このコマンドを実行すると、CloudWatchアラームを設定しなくても、インスタンスの自動復旧機能が有効になります。
Q CLI は、ModifyInstanceMaintenanceOptions を利用した自動復旧設定についても、対象インスタンスの情報を確認した上で、具体的なコマンドを提示してくれました。
まとめ
今回、Amazon Q Developer CLI を利用して、EC2 インスタンスの障害調査から自動復旧設定の検討までを試してみました。その結果、Q CLI が効率的な障害対応に役立つ可能性を体感できました。
AIの回答は常に完璧とは限りませんが、質問の仕方や得られた情報を吟味することで、短時間で有益な情報を引き出す強力なツールとなり得ると感じました。
現時点ではQ CLIの利用にはツールのインストールが必要ですが、将来的にはAWSマネジメントコンソールに統合されているAmazon Qでも、日本語サポートやCLIと同等の機能が利用可能になり、利用のハードルが下がることを期待しています。
Amazon Q Developer には無料版と有償版 (Pro) があります。月額19ドルの Q Developer Pro は、無料版の利用回数などの制限が緩和され、応答速度も向上します。無料版の評価で可能性を感じられた方は、ぜひ Pro もお試しください。