Amazon Q が AWS の作業中の "相棒" になった話

はじめに

「AI といえば何を思い浮かべますか？」
そう聞かれて、多くの人が答えるのは ChatGPT や Claude あたりでしょう。私もずっとそうでした。

けれど最近、AWS の作業中だけは 別の AI を相棒のように使用する ようになりました。
それが Amazon Q です。

こんにちは、Qurated編集部のKです。
前回は AWS Documentation MCP に救われた話を書きましたが、今回はその姉妹編として、AWS の現場で 別の AI ＝ Amazon Q に救われた話をお届けします。

本記事では、プライベートサブネットに置いた EC2 に SSM で入れず詰まっていた状況を、Amazon Q との対話だけで閉域構成に辿り着いて解決した実体験を紹介します。

Amazon Q ってそもそも何？

Amazon Q は、AWS が提供する AWSコンテキストに最適化された生成AI です。

• マネジメントコンソール画面の 左上に常駐 していて、画面遷移なしで聞ける
• インスタンスIDなどリソース識別子を渡すと、 そのリソースの実状態を読み込んで 答えてくれる
• AWSサービスの最新仕様を前提に話せる

ChatGPT や Claude と並べて優劣を語るというより、用途が違う という整理がしっくりきます。汎用AIは万能なアシスタントとして、Amazon Q は「いま画面に映っているこのAWSリソースについて相談する相棒」として、棲み分けて使う、という距離感です。

今回の状況：プライベートEC2にSSMで入れない

舞台はこんな環境です。

• すでに プライベートサブネットに配置されたEC2 が1台ある
• インターネットゲートウェイも NAT Gateway も持たない、閉域寄りのVPC
• 踏み台もSSHキーも使いたくないので、SSM Session Manager で入りたい
• Systems Manager のフリートマネージャー（マネージドノード一覧）にも 対象インスタンスが出てこない

「SSMが正解」までは知っていても、ここから先は構成要素（IAMロール／VPCエンドポイント／SSM Agent／SG）が絡み合っていて、未経験寄りの自分にとってはどこを疑えばいいのか手応えがない状態でした。

Amazon Q に「インスタンスID」を渡して聞いてみた

ここで、画面右上の Amazon Q を開きました。投げた質問はざっくりこんな内容です。

i-xxxxxxxxxxxxxxxxx にSSM接続できない原因を教えて

ポイントは、Amazon Q が インスタンスIDを受け取って、対象リソースの実状態を読み込んだ上で 答えてくれるところです。VPCの情報やルートテーブル、IAMロールの中身を自分でコピペして渡す必要はありません。インスタンスIDを書くだけで、そのインスタンスを取り巻く環境を Amazon Q 側が確認してくれます。

実際に返ってきた回答は、ざっくりこんな形でした。

接続状況：SSM接続ステータス 未接続 ❌
インスタンスが Systems Manager に登録されていません。SSMエージェントが動作していないか、SSMサービスと通信できない状態です。

問題の詳細

1. ネットワーク接続の問題（主要原因）
   • VPCエンドポイントなし: VPC (vpc-xxxxxxxxxx) に SSMサービス用のVPCエンドポイントが設定されていません
   • プライベートサブネットで NAT なし: インスタンスはプライベートサブネット (subnet-xxxxxxxxxxxxxxxxx) にありますが、ルートテーブルに NAT ゲートウェイやインターネットゲートウェイへのルートがありません
   • パブリックIPなし: インスタンスにはプライベートIPのみでパブリックIPがありません
2. IAMロール設定：正常 ✅
   • IAMロール「test-role」に AmazonSSMManagedInstanceCore ポリシーが適用されており、Session Manager に必要な権限は正しく設定されています

解決方法

• 推奨オプション1: VPCエンドポイントの作成（ssm / ssmmessages / ec2messages）
• オプション2: NATゲートウェイの追加
• オプション3: パブリックサブネットへの移動

ここで効いてくるのが、自アカウントの VPC ID・サブネット ID・IAMロール名（test-role）まで読み込んだ上で診断を組み立ててくれている ことです。
「インスタンスID をひとつ書いただけ」でここまで掘ってくれる感覚は、汎用AIではちょっと出せないものでした。

推奨オプション1：VPCエンドポイント方式を選んだ

自分の制約は 「VPC構成は変えたくない、NAT Gateway も入れたくない、閉域でやりきりたい」 だったので、選ぶのは迷わず 推奨オプション1のVPCエンドポイント方式 一択でした。

そのまま Amazon Q に手順の詳細を続けて聞き、提示された通りに作業を進めました。

• 必要なエンドポイント: ssm / ssmmessages / ec2messages の 3点（インターフェース型）
• 各エンドポイントで プライベートDNSを有効化 すること
• EC2に AmazonSSMManagedInstanceCore ロールをアタッチ すること
• セキュリティグループは、EC2からエンドポイント宛てに アウトバウンド443を許可 すれば足りること

提示された手順をそのままなぞっただけで、SSM 接続が通りました。

結果として組んだ最終構成

ここまで、コマンドを叩いたのは構築フェーズだけ。原因の切り分けから方針決定までは、コンソール内の Amazon Q との対話で完結しました。

この体験で気づいた Amazon Q の本領

たった1つのトラブル解決ですが、Amazon Q の良さがいくつも体感できました。

1. インスタンスIDから対象リソースの実状況を読みに行ってくれる
   VPC ID・サブネットID・IAMロール名まで自分で取得して、 “そのインスタンス” の現状診断として返してくれる。事実ベースで原因が並ぶので、初動の精度が段違いに上がります。
2. 解決オプションを構造化して並べてくれる
   今回も「推奨オプション1: VPCエンドポイント／オプション2: NAT／オプション3: パブリック移動」と並列提示してくれました。自分の制約（閉域でやりたい）に照らして即断できるので、対話のターン数が少なくて済みます。
3. コンソールから一歩も離れない
   タブ切り替えゼロ、ログイン情報を別画面に渡す手間ゼロ、コピペ整形ゼロ。地味ですが、作業中の認知負荷が一段下がります。

まとめ

• 踏み台ゼロのSSM接続は IAMロール + 3つのVPCエンドポイント + プライベートDNS有効化 で実現できる
• ただ、それ以上に大きな収穫は、Amazon Q が 「インスタンスIDひとつでリソースの実状況を読み込み、原因と解決オプションを並べてくれる相棒」 として機能した実感
• 制約条件を伝えるだけで提示済みオプションから最適解が絞れるので、 トラブル時の最短ルート探しに強い

結論

AI = ChatGPT/Claude のイメージはそのままで構いません。
ただ、AWS の作業をするときは、画面の中で Amazon Q を相棒として開いてみてほしい。

インスタンスIDを投げて、自アカウントの状況を読んでもらって、選択肢から最適解を選ぶ——この一連の流れがコンソールから一歩も離れずに完結する感覚は、一度味わうと戻れません。

参考リンク

• Amazon Q (AWS公式)
• AWS Systems Manager Session Manager
• Session Manager の前提条件
• VPCエンドポイント経由で Systems Manager を使用する