インベントリ検索はAIに任せる時代。Amazon Quick Suiteで実現する「問い合わせるだけ」のEC2インベントリ管理術

はじめに

「緊急の脆弱性が発見された！影響を受けるサーバーを今すぐ特定しなければ...」

こんな経験、ありませんか？

管理するEC2インスタンスが増えれば増えるほど、以下のような課題に直面します：

課題	具体例
インベントリ管理の煩雑さ	マルチアカウント × 複数インスタンスの情報を手動で管理
検索の困難さ	「Apache 2.4.49以前のバージョン」を使っているサーバーはどのアカウントの、どのインスタンス？
緊急対応の遅れ	脆弱性情報が出てから影響範囲（対象インスタンス）の特定に数時間〜数日

本記事では、Amazon Quick Suite のAI機能とSSM Inventoryを活用して、これらの課題を解決する方法をご紹介します。

今回想定している利用者について

ペルソナ

社内システムのインフラ担当者（セキュリティ担当を兼務しているが、各サービスの管理者ではない）

社内システムのインフラの特性および管理方法

管理しているAWSアカウントは50アカウント存在する。
各AWSアカウントにはEC2インスタンスが多数あり、管理者（サービス主管）はそれぞれ異なる。
インフラ担当者は基本的にEC2インスタンスにアクセスすることを許可されておらず、アクセスする場合は別途申請が必要となる。

課題

OSやミドルウェアで緊急度の高い脆弱性が発見された際、どのEC2インスタンスが脅威にさらされているのかを迅速に特定する手段がない。

解決手段の全体像

構成

前提

EC2インスタンスがSSMマネージドノードとして、Systems Managerの管理下にあること
SSM Inventory を有効化していること
Amazon Quick Suite は「us-east-1」でアカウントを作成していること（アジアパシフィック（東京）リージョン未サポートのため）

補足：Amazon Quick Suite と Amazon QuickSight の関係性について

Amazon Quick Suiteは、Amazon QuickSight の全機能を包含したプラットフォームです。全く新しいAWSサービスというわけではなく、Amazon QuickSight の機能を大幅に拡張した包括的なサービスだとお考えください。従来のBI機能はそのまま維持しながら、AI技術を活用してより直感的で包括的な企業データ活用環境を提供しています。

QuickSight（従来）
- 主にビジネスインテリジェンスとデータ可視化に特化
- ダッシュボードとレポート作成が中心
Quick Suite（現在）
- QuickSightの全機能を包含
- AI搭載チャットエージェントによる自然言語でのデータ問い合わせ
- Quick Researchによる深い調査とレポート生成
- Quick Flowsによる業務自動化
- スペースによるナレッジベース管理とコラボレーション
- カスタムナレッジベースとドメイン特化エージェントの設定 etc

実装までの7つの手順

手順1. データ送信先のAWSアカウントで、インベントリデータの保管用S3バケットを作成する
手順2. データ送信元のAWSアカウントにアクセスし、クロスアカウント/クロスリージョンでSSM Inventory のリソースデータ同期を作成する
手順3. データ送信先のAWSアカウントにアクセスし、Amazon Athena でワークグループおよびテーブル作成を行う
手順4. Amazon Quick Suite (QuickSight) の管理画面で、Athenaをデータソースとして作成する
手順5. Amazon Quick Suite (QuickSight)でインベントリデータのダッシュボードを作成する
手順6. Amazon Quick Suite で、インベントリデータへのQ&A専用のスペースを作成し、データソースにダッシュボードを指定する
手順7. Amazon Quick Suite のチャット機能を用いて質問する

実装の流れ

手順1. データ送信先のAWSアカウントで、インベントリデータの保管用S3バケットを作成する

データ送信先のAWSアカウント上で、SSM Inventoryの情報を保管するS3バケットを作成します。今回はAmazon Quick Suite の利用リージョンと同じ米国東部（バージニア北部）リージョンで作成しています。

S3バケットポリシーは以下で作成しました。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "SSMBucketPermissionsCheck",
            "Effect": "Allow",
            "Principal": {
                "Service": "ssm.amazonaws.com"
            },
            "Action": "s3:GetBucketAcl",
            "Resource": "[Amazon S3 のARN]"
        },
        {
            "Sid": " SSMBucketDelivery",
            "Effect": "Allow",
            "Principal": {
                "Service": "ssm.amazonaws.com"
            },
            "Action": "s3:PutObject",
            "Resource": "[Amazon S3 のARN]/*/accountid=[accountId]/*",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "[accountId]",
                    "s3:x-amz-acl": "bucket-owner-full-control"
                },
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:ssm:*:[accountId]:resource-data-sync/*"
                }
            }
        },
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "athena.amazonaws.com"
            },
            "Action": [
                "s3:GetObject",
                "s3:ListBucket",
                "s3:GetBucketLocation"
            ],
            "Resource": [
                "[Amazon S3 のARN]",
                "[Amazon S3 のARN]/*"
            ]
        }
    ]
}

手順2. データ送信元のAWSアカウントにアクセスし、クロスアカウント/クロスリージョンでSSM Inventory のリソースデータ同期を作成する

Systems Manager のコンソール画面上で、「リソースデータの同期」を作成します

バケット名には、手順1で米国東部（バージニア北部）リージョンで作成したS3バケット名を入力します。今回は、「ap-northeast-1」のインベントリ情報を「us-east-1」のS3バケットに転送します。

「リソースデータの同期」が無事に成功したら、出力先として指定したS3バケットにインベントリ情報が格納されていることを確認します。 SSM Inventoryの収集頻度は最短で30分間隔なので、リアルタイムに収集することはできませんのでご留意ください。

手順3. データ送信先のAWSアカウントにアクセスし、Amazon Athena でワークグループおよびテーブル作成を行う

Amazon Athena で、インベントリ情報に対してクエリを実行する専用のワークグループを作成します。

そして、以下のAthena DDLを実行してテーブル定義を行います。今回は取得したインベントリ情報のうち「AWS:Application」という情報に対してクエリを実行します。

SSM Inventoryによって収集されるメタデータについては以下のドキュメントをあわせてご覧ください。

docs.aws.amazon.com

CREATE EXTERNAL TABLE IF NOT EXISTS AWS_Application (
    Name string,
    ResourceId string,
    ApplicationType string,
    Publisher string,
    Version string,
    InstalledTime string,
    Architecture string,
    URL string,
    Summary string,
    PackageId string
)
PARTITIONED BY (
    AccountId string,
    Region string,
    ResourceType string
)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
WITH SERDEPROPERTIES ('serialization.format' = '1')
LOCATION 's3://[bucket name]/AWS:Application'

手順4. Amazon Quick Suite (QuickSight) の管理画面で、Athenaをデータソースとして作成する

まずは、Amazon Quick Suite のアカウント管理画面に遷移します。そして「アクセス許可」→「AWSリソース」と進み、Amazon Athena へのアクセスを許可しておきます。

次に、Amazon Quick Suite のクイックサイト機能で、「データソースを作成」→「データセットを作成」の順番で実装を進めます。

データソースは「Amazon Athena」を指定します。Athena ワークグループとテーブルは、手順3で作成したものを指定します。

「データクエリを直接実行」を選択し、「視覚化する」をクリックします。

手順5. Amazon Quick Suite (QuickSight)でインベントリデータのダッシュボードを作成する

今回は、簡単なテーブル形式でインベントリ情報を整理したダッシュボードを作成して公開します。

手順6. Amazon Quick Suite で、インベントリデータへのQ&A専用のスペースを作成し、データソースにダッシュボードを指定する

Amazon Quick Suite のスペース機能は、チームやプロジェクトごとにコンテンツ（ダッシュボード、分析、データセット）を整理・一元管理するための共有ワークスペースです。

たとえば、以下のような使い方が可能です。

社内システムのインフラ担当者専用のスペースを作成する
スペースの詳細画面を開き、RAGのデータソースを追加するイメージで、手順書や社内ドキュメントをアップロードします
作成したスペースを他のインフラ担当者に共有する
Amazon Quick Suite Chat のデータソースとしてスペースを指定することで、インフラ担当者専用のRAG回答ボットを作成できる

今回はSSM Inventory専用のスペースを作成します。

手順4で作成したダッシュボードをナレッジとして追加します。

手順7. Amazon Quick Suite のチャット機能を用いて質問する

あとは、Amazon Quick Suite のチャット機能で、スペースを指定してプロンプトを入力するだけです。

今回は以下のプロンプトを実行しました。

「httpd 2.4.64」よりも前のバージョンのhttpdがインストールされているEC2インスタンスを列挙して

すると、スペースに追加したナレッジ（ダッシュボード）をデータソースとしてきちんと応答してくれました！

まとめ

本記事で実現したこと

本記事では、Amazon QuickSightのAI機能とSSM Inventoryを組み合わせて、EC2インスタンスのインベントリ管理を効率化する方法をご紹介しました。

実装の全体像（おさらい）

手順	実施内容	所要時間（目安）
1	S3バケット作成	5分
2	リソースデータ同期設定	15分
3	Athenaテーブル作成	10分
4-5	QuickSightデータソース・ダッシュボード作成	20分
6-7	スペース設定・チャット機能活用	10分
合計		約60分

この仕組みのメリット

1. 脆弱性対応の迅速化

従来：影響範囲の特定に数時間〜数日
→ 改善後：数分で特定可能

2. 自然言語での検索

従来：AWSアカウントおよびEC2インスタンスにログインして確認、Amazon S3 + Athena で複雑なSQLクエリを記述
→ 改善後：「〇〇より前のバージョンは?」と質問するだけ

3. マルチアカウント対応

従来：各アカウントに個別アクセスして確認
→ 改善後：一元管理された情報から検索

その他活用法

本記事では「AWS:Application」のインベントリ情報のみを扱いましたが、以下のような拡張も可能です：

OS情報（AWS:InstanceInformation）の追加
ネットワーク設定（AWS:Network）の可視化
カスタムインベントリによる独自メタデータの収集

さいごに

EC2インスタンスの管理は、規模が大きくなるほど複雑になります。しかし、適切なツールと仕組みを導入することで、運用負荷を大幅に削減できます。

本記事が、皆さまのインフラ運用の効率化に少しでもお役に立てれば幸いです。

ぜひ、実際に試してみてください！

インベントリ検索はAIに任せる時代。Amazon Quick Suiteで実現する「問い合わせるだけ」のEC2インベントリ管理術

はじめに

今回想定している利用者について