I investigated EC2 instances affected by AWS outages using Q Developer CLI, and also asked about prevention measures

I investigated EC2 instances affected by AWS outages using Q Developer CLI, and also asked about prevention measures

I would like to introduce a case where we were able to utilize Amazon Q CLI to identify the cause and receive suggestions for automatic recovery settings during the investigation of EC2 instances that were unintentionally stopped due to an AWS outage.
2025.05.29

This page has been translated by machine translation. View original

I recently investigated an EC2 instance that unexpectedly stopped and found that an AWS-related StatusCheckFailed_System metric was recorded.
During this investigation, I had the opportunity to test the effectiveness of Amazon Q Developer CLI, so I'll share those results.

Examples of problems that can cause system status checks to fail include:

  • Loss of network connectivity
  • Loss of system power
  • Software issues on the physical host
  • Hardware issues on the physical host that affect network reachability

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html

Environment

I installed Amazon Q Developer CLI (Q CLI) on an Amazon Linux 2023 (x86_64) environment using the ZIP file installer.

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

The Q CLI version was 1.10.2.

$ q --version
q 1.10.2

I used the free version of Amazon Q Developer, which can be accessed by registering with an 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=***-***

For IAM authentication, I used temporary security credentials obtained from a read-only role with no modification or write permissions, set as environment variables.

export AWS_ACCESS_KEY_ID=XXXXXXXXXXXXXXXXXXXX
export AWS_SECRET_ACCESS_KEY=YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
export AWS_SESSION_TOKEN=ZZZZZZZZ

I conducted the investigation using the q chat command in an interactive format.

$ 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
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Incident Investigation

I provided the EC2 instance ARN and approximate time of the incident to Q CLI in Japanese, asking it to investigate the issue.

Investigation Prompt

EC2(arn:aws:ec2:ap-northeast-1:XXXXXXXXXXXX:instance/i-XXXXXXXXXXXXXXXXX)2025/5/27 13時台(JST)で発生した、ステータスチェックエラーについて報告して。

Q CLI Response

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 internally ran the use_aws tool (AWS CLI) to automatically collect CloudWatch metrics and EC2 instance status information.

Q CLI Report

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構成を検討して可用性を向上させる

Auto Recovery Settings

Based on the recommended actions provided by Q CLI, I asked further questions about setting up auto recovery for the EC2 instance.

CloudWatch Alarm

推奨アクション として案内された 「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. 自動復旧が失敗した場合は、手動での対応が必要になります

この設定により、今回のようなシステムステータスチェック失敗が発生した場合に、自動的にインスタンスの復旧が試みられ、サービスの可用性が向上します。

I received an explanation of the CLI command for setting up auto recovery using CloudWatch alarms, along with the associated costs.

Auto Recovery Option

In addition to using CloudWatch alarms, there is an option added in a 2022 update that allows enabling auto recovery directly in the EC2 instance settings.

https://dev.classmethod.jp/articles/amazon-ec2-now-performs-automatic-recovery-of-instances-by-default/

I asked Q CLI about this method.

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の問題によってインスタンスが損なわれた場合に復旧します。

ただし、この機能は特定のインスタンスタイプと構成でのみ利用可能です。お使いのインスタンスが自動復旧の対象となっていることを確認してください。

Based on this answer, I asked whether the target instance was eligible for this feature.

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アラームを設定しなくても、インスタンスの自動復旧機能が有効になります。

After checking the target instance's information, Q CLI provided a specific command for setting up auto recovery using ModifyInstanceMaintenanceOptions.

Conclusion

In this exercise, I used Amazon Q Developer CLI to investigate an EC2 instance issue and explore auto recovery options. The experience demonstrated how Q CLI can be useful for efficient incident response.

While AI responses aren't always perfect, by crafting good questions and evaluating the information received, Q CLI proved to be a powerful tool that can provide valuable information in a short time.

Currently, using Q CLI requires installing the tool, but I hope that in the future, Amazon Q integrated into the AWS Management Console will support Japanese and offer equivalent functionality, lowering the barrier to entry.

Amazon Q Developer has both free and paid (Pro) versions. The Pro version at $19 per month relaxes usage limits and improves response times. If you see potential in the free version, I encourage you to try Amazon Q Developer Pro.

https://dev.classmethod.jp/articles/amazon-q-developer-pro-member-account/

Share this article

FacebookHatena blogX

Related articles