2025.05.21 2025.05.27

Amazon Q Developer for CLIで簡単インフラ調査〜クラウドリソースの作成者を特定する〜

sho

Contents

はじめに
従来のアプローチ
Amazon Q Developerを使うアプローチ
調査用のセットアップ
1. CLIのインストール
2. credentialの設定
Amazon Q Developerに調査依頼をする
1. 依頼時のプロンプト
2. 調査の様子
Amazon Q Developerを使った調査の利点
1. 操作の煩雑さの解消
2. 検索基盤のコスト削減
まとめ

はじめに

西藤です。
前回に続いて、Amazon Q Developerの活用方法に関する記事です。

前回の記事

AWS MCP Serversを活用して、ブログの記事レビューをAmazon Q Developerに依頼する

AWSクラウドでトラブルが起きたり、用途不明の高コストなリソースが見つかったりすると、「誰が作ったんだろう？」と思うことがありますよね。
リソースの作成者を特定できれば、設定の意図や背景を直接聞けるので、トラブル解決がグッと早くなります。

今回は、そういったクラウドリソースの作成者を特定するためにAmazon Q Developerを活用する方法を紹介します。

従来のアプローチ

リソースの作成者を特定するにはどうするか？と言われた時に最初に思い浮かぶ方法は何でしょうか？

社内の運用関連のナレッジを確認する
リソースにつけられたリソースタグ情報から特定する
AWS Configからリソース変更履歴を遡る
Amazon CloudTrailからリソース作成が行われた操作履歴をクエリする

と言った具合でしょうか。

社内ナレッジの確認の場合、適切にナレッジが蓄積されていればもっとも早く、その組織にあった形で情報が得られる可能性は高いです。
しかし、ナレッジを常に最新に保つ労力が必要だったり、そもそもナレッジが最新化されていない場合は、結局他の方法で確認する必要があります。

リソースタグを参照する場合でも、正しくタグがついている必要がありますし、AWS ConfigやAmazon CloudTrailから履歴を遡る場合はそのための一手間がどうしても必要です。

よりスムーズに調査するために何らかの検索基盤を構築して、そこで迅速にクエリを発行できる体制を組むということも考えられますが、作成者を即座に特定するためだけに構築するには、コストに見合わないケースもあります。

Amazon Q Developerを使うアプローチ

そこで、今回、Amazon Q DeveloperのCLI版を試してみました。

Amazon Q Developerというと、開発コードの実装を支援するIDE版の印象が強いかもしれませんが、それだけではありません。
IDE内のコーディング支援だけでなく、コマンドライン上でのAWS CLIコマンドの実行支援やトラブルシューティングなどの機能も提供しています。

今回は次のようなシナリオで使ってみましょう。

EC2インスタンスが見つかったが、タグ情報や社内のドキュメントからしても利用実態がわからない
このインスタンスの作成者を特定し、その背景や目的を知りたい
Amazon Q Developer for CLIを使って、各種ログのクエリなどを自ら行わずにチャットベースで調査を完結したい

こういったシナリオのもとリソースの作成者（IAM情報）を特定するまでを目指します。

調査用のセットアップ

上記のシナリオを実現するためにAmazon Q Developer for CLIの設定を行います。

CLIのインストール

Amazon Q Developer for CLIはmacOS、Linux（AppImageおよびUbuntuパッケージ）、Windows Subsystem for Linux (WSL) でインストールできます。今回、詳細なインストール手順自体は割愛して、qコマンドが利用可能になっている状態から解説します。

※インストール手順の解説が必要な場合は、下記を参照してください。

Amazon Q Developer CLI版のインストール手順

credentialの設定

インストールを終えたら該当のリソースが存在するAWSアカウントにアクセスできるようにするためのcredentialsの設定をします。

IAM Identity Centerを使っている場合は、アクセスキー取得画面からプロファイル追加用のキー情報をコピーして~/.aws/credentialsに貼り付けます。

調査タスクなので、ReadOnlyで権限は足りるはずです。ReadOnlyに権限を絞っておくことでAIによる想定外な処理が行われても安心です。

IAM Identity Centerのガイダンスにしたがってプロファイルを追加します。

上記の設定でプロファイルの作成を終えたら、試しにこのプロファイルを使うよう指示してコマンドを実行させてみましょう。
例としてAmazon Q Developerにaws s3 lsコマンドを実行してもらいます。

期待通り、指定されたプロファイルを使った上で情報を取得し、該当のAWSアカウント内のs3バケットの情報が表示されました。

Amazon Q Developerに調査依頼をする

では、必要な設定が終わりましたのでAmazon Q Developerに調査を依頼してみましょう。

依頼時のプロンプト

プロンプトとしては、次のような形で入力します。

プロファイル <プロファイル名>を使って EC2インスタンスの作成者の特定を行なってください。
対象のEC2インスタンスのARNは次の通りです。
- arn:aws:ec2:ap-northeast-1:<アカウントID>:instance/<インスタンスID>

調査のために必要な権限が付与されたプロファイルと、作成者を特定したいリソースのARNを指定して指示を行います。

調査の様子

では、上記のプロンプトを使って実行してみます。

aws ec2 describe-instancesコマンドが実行されました。
ログを見ますとDescribe the EC2 instance to check for creator tagsとあり、タグから作成者の情報を探ろうとしており、人間と同じようなアプローチをとっているのが興味深いですね。

次にCloudTrailのログをチェックすると提案してきましたので、yと返し、処理の開始を許可します。

どうやら、調査に使うパラメータを間違えていたようですね。
（AttributeKey,AttributeValueとするべきところにattribute-key,attribute-valueが使われていた）

訂正した上で再度実行する旨、提案してきましたので、許可します。

調査が完了し、結果が表示されました。

どのユーザーが
どのIAMロールを使って
いつ（日本時刻）
どこから（ソースIPアドレス）
どの方法で

該当のEC2インスタンスを作成したのかがわかりやすく表示されており期待通りの結果が得られました。

プロンプトを投げた以降に行なった操作はyと入力していただけで、非常に簡単に結果が得られました。

Amazon Q Developerを使った調査の利点

さて、Amazon Q DeveloperのCLI版を使ったリソース作成者の調査方法を紹介しましたが、この価値を考えてみましょう。

操作の煩雑さの解消

冒頭にも記載しましたが、従来は今回のようなシナリオにおいては、自分たちの組織が持つ情報やAWS内の各サービスをさまざま切り替えながら調査をする必要がありました。

今回は、結果としてCloudTrailの情報から特定していましたが、そのCloudTrailの画面上からの検索も、なかなか大変なものです。

さまざまあるAttributeの中から適切なものを選ぶ必要があり、

さらにその値も正しい記法で入力する必要があります。

入力→検索→結果確認を繰り返せば、最終的に答えにたどり着けるでしょう。ただし、実際には思ったように検索できないケースも多くあります。

たとえば、以下のようなケースです。

Resource NameにARNを入れて検索したらヒットするが、インスタンス起動時のイベントではない
検索対象の時間帯が合っていなかったのかと思い対象をずらしながら調査するがちょうど当てはまるイベントがヒットしない
ARNを入れたらヒットはしていたので、Resource Nameの指定は合っていると思っていたのだが、実は間違っていた。正しくはインスタンスIDだけを入力するべきだった
正しく検索できたとしても、そのイベントの内容はJSONで表示されて、200行以上になっていて読むのが大変・・・。

というような状況になると、なかなか辛いものがあります。

そうしたトライ・アンド・エラーをすべてAIに任せられるようになると、かなりストレスは減りますし、実際の工数としても削減できる可能性があります。