こんにちは。masedatiです。
この記事は「2025 Japan AWS Jr. Chanpions 夏のQiitaリレー」の23日目の記事となります。
過去の投稿（リンク集）はこちらからご覧ください。
はじめに
皆さん、Amazon Q Developer CLI、もう活用されていますか？
日々のAWS運用業務において障害調査は避けて通れませんが、AWS初学者にとっては、緊迫した状況下で大量の情報から原因を突き止めるのは困難かと思います。
そんな中で、Amazon Q Developer CLIを使ってGuardDutyインシデント調査を効率化する手法を紹介してくださっているのが、kyonosukeさんのこちらのブログです。
今回はそれに続く形で、「EC2のメモリ使用率が急上昇した」という仮想シナリオをもとに、Amazon Q CLIに実際に調査を依頼してみたいと思います。
仮想シナリオ
着任したばかりのインフラ運用担当者へ、アプリケーションの挙動に異常があるのでサーバを確認してほしいとの報告を受けました。
さっそくマネジメントコンソールから、アプリケーションが稼働しているEC2インスタンスの「モニタリング」タブを確認しましたが、CPUやネットワークのメトリクスには特に問題は見られません。
しかし、担当者はメモリの使用状況が確認できないことに気づきます。
「どうもメモリが怪しい…」と目星はつけたものの、どこからメモリのメトリクスを確認すればいいのかわからず、対応に行き詰まってしまいました。
そこで担当者は、Amazon Q CLIに助けを求めることにしました。
本題
担当者は、以下のプロンプトを入力してみました。
EC2インスタンス名xxxxxのメモリ使用率が一時的に上昇したようです。原因を調査してください。
Amazon Q CLIの挙動
EC2の特定
Amazon Q CLIは、まずプロンプトに含まれるインスタンス名から該当のEC2を特定します。
CloudWatchメトリクスの確認
次に、対象インスタンスのCloudWatchメトリクスを確認します。
CloudWatch Agentの確認
ご存じの通り、CloudWatchの標準メトリクスにはメモリ使用率は含まれていません。
CloudWatchが標準で提供するEC2メトリクスは以下のようなものです。
- CPU使用率
- ネットワーク入出力
- ディスク読み書き
- ステータスチェック
メモリ使用率を収集するためには、EC2インスタンスにCloudWatch Agentを設定する必要があります。
該当インスタンスにはAgentが入っているでしょうか…？
Session Manager接続によるEC2インスタンスのメモリ調査
残念がら、CloudWatch Agentは導入されていなかったようです。
代替策として「Systems Manager Session Manager」を使用してインスタンスに接続することを提案しています。Systems Manager Session Managerは、AWSのEC2インスタンスやオンプレミスサーバーにセキュアに接続するためのサービスです。
ただし、前提としてAWS CLIで接続するには以下3点が必要となります。
-
IAMロール/ポリシー
- EC2インスタンスにAmazonSSMManagedInstanceCoreポリシーがアタッチされたIAMロール
- ユーザーへのssm:StartSession権限
-
SSM Agent
- EC2インスタンスにSSM Agentがインストール・実行されている
-
Session Manager Plugin
- ローカル環境にSession Manager pluginのインストールされている
今回、この前提条件3のpluginが担当者の作業端末にインストールされていないため、拒否されてしまいました。
Systems Manager Run Commandでのメモリ使用状況の確認
さらなる代替策としてSystems Manager Run Commandでのメモリ使用状況の確認を行ってくれます。
Systems Manager Run Commandは、EC2インスタンスやオンプレミスサーバーに対してリモートでコマンドを実行できるAWSサービスです。
Session Managerと同じく、SSM AgentやIAMロールが必要ですが、pluginは不要でネットワークが繋がっていればローカルPCから実行することができます。
原因特定！
最終的にRun Commandを実行することで今回のメモリ上昇の原因を特定することができました！
※仮想シナリオ再現のためstressコマンドでメモリ使用率を上昇させています。
まとめ
今回、担当者がAmazon Q CLIに入力したのは、たった一言のプロンプト
「原因を調査してください。」
それだけで、インスタンスの特定 → CloudWatchメトリクス → Session Managerの代替案提示 → Run Commandによる調査 → 原因特定と、ここまで自動で実行してくれました。
Amazon Q CLIは、AWS業務の強力なパートナーです。
ぜひ皆さんも、日々の障害対応や調査業務に活用してみてください！
以上、Amazon Q Developer CLIの魅力をお伝えした記事となります。
Appendix : Amazon QはRun Commandで何をやっていたのか？
free -h
ps aux --sort=-%mem | head -10
cat /proc/meminfo | grep -E 'MemTotal|MemFree|MemAvailable|Buffers|Cached'
uptime
dmesg | tail -20
1. free -h
メモリ使用状況を人間が読みやすい形式で表示
- free: メモリとスワップの使用状況を表示
- -h: 人間が読みやすい単位（KB、MB、GB）で表示
出力例：
total used free shared buff/cache available
Mem: 7.7G 2.1G 1.2G 180M 4.4G 5.2G
Swap: 2.0G 0B 2.0G
2. ps aux --sort=-%mem | head -10
メモリ使用率順にプロセスを並べて上位10件を表示
- ps aux: 全プロセスの詳細情報を表示
- --sort=-%mem: メモリ使用率の降順でソート（+は昇順、-は降順）
- head -10: 最初の10行を表示
3. cat /proc/meminfo | grep -E 'MemTotal|MemFree|MemAvailable|Buffers|Cached'
メモリ情報から特定の項目を抽出
- /proc/meminfo: システムのメモリ情報ファイル
- grep -E: 拡張正規表現でパターンマッチング
- パイプ（|）で区切られた項目を検索
出力例：
MemTotal: 8048576 kB
MemFree: 1234567 kB
MemAvailable: 5432109 kB
Buffers: 123456 kB
Cached: 3456789 kB
4. uptime
システムの稼働時間と負荷平均を表示
出力例：
14:30:25 up 5 days, 3:45, 2 users, load average: 0.15, 0.25, 0.30
- 現在時刻
- 稼働時間
- ログインユーザー数
- 負荷平均（1分、5分、15分）
5. dmesg | tail -20
カーネルメッセージの最新20行を表示
- dmesg: カーネルのリングバッファからメッセージを表示
- tail -20: 最後の20行を表示