AWS Resource Explorer活用 - アカウント横断でのリソース調査を効率化

こんにちは、タイミーでエンジニアをしている佐藤です。
こちらはTimee Product Advent Calendar 2025の9日目の記事です。

この記事では、AWS Resource Explorerを用いてマルチアカウント環境での資産棚卸しを効率化した取り組みについて紹介します。その過程でAWS Organizationsのアカウント構成も見直したので、合わせて共有します。

背景

AWSにおいてマルチアカウント構成で運用を続ける中で、横断的な運用効率化ニーズが出てきました。

マルチアカウント環境での横断的なリソース調査
タグ付けに基づくリソース検索
生成AIを活用したリソース作成状況の把握

アカウントやリージョンが複数に跨る場合の検索性が課題になります。組織レベルでAWS Resource Explorerを設定することで、リソース調査を効率化することにしました。

AWS Resource Explorerとは

AWS Resource Explorerは、リージョンとアカウントを横断した高速な検索を提供する無料のサービスです。

リージョンまたぎでのリソース探索
マルチアカウント環境でのリソース把握
不要リソースの発見と最適化
タグ付けリソースの検出
フィルタールールによるカスタムビュー

また、AWSマネジメントコンソールの検索バーとも統合されており、上部の検索窓から/（スラッシュ）で呼び出せます。

AWS Resource Explorerの設定

デプロイ方法の選択

AWS Resource Explorerの組織展開には複数の方法があります。

方法	特徴
各アカウントで個別設定	柔軟だが漏れが発生しやすい
Quick Setup	簡単だがリージョン制御が難しい
CloudFormation StackSets	リージョン指定可能、IaC管理しやすい

私たちは以下の理由からCloudFormation StackSetsを採用しました。

新規アカウントを含めて漏れなく設定したい
SCPで利用可能リージョンを絞っている
構成をTerraformで管理している

CloudFormation テンプレートはAWS公式ドキュメントを参考にしました。

インデックス構成

Resource Explorerでは、AggregatorIndexとLocalIndexの2種類のインデックスがあります。

AggregatorIndex: 全リージョンのリソース情報を集約するインデックス。全アカウントで統一したリージョンに配置する必要がある
LocalIndex: 各リージョンのリソース情報を保持するインデックス

私たちは以下のように構成しました。

AggregatorIndex: ap-northeast-1にデプロイ
LocalIndex: ap-northeast-1以外の利用リージョンにデプロイ

StackSetはAggregatorIndex用とLocalIndex用の2つを用意し、Organizationsのルートを指定して組織メンバー全体に適用しています。auto_deploymentを有効にすることで、新規アカウントに対しても自動でデプロイされます。

設定時の注意点として、Resource Explorerを手動で設定した場合や、Systems Managerを有効にしているとResource Explorerの既存インデックスがあります。この状態でStackSetsをデプロイすると競合が発生します。

deployment_targetsのaccount_filterを設定することで、既存インデックス作成済アカウントでの競合を回避しました。

AWS Resource Explorerの活用

組織スコープのView作成

Operations Toolingアカウントで、組織全体を検索対象とするViewを作成して検索を可能としました。Viewはアカウントスコープとリソースフィルターで絞り込めるため、用途に応じて複数作成できます。

Resource Explorerは追加料金なしで利用できますが、以下のクォータがあります。

一度に取得できる結果: 1,000件
アグリゲーターリージョンの月間検索オペレーション: 10,000回（デフォルト）

フィルターを設定しない状態では、AWS Configのリソースが大量に取得されてしまい、探索性が落ちてしまいます。そこで、デフォルトView向けには以下のようなフィルターを設定した組織スコープのViewを作成して調査対象のリソースが絞り込みやすい状態にしました。

filter_string = "-service:config"

AIによるリソース調査での活用

11月20日から21日で開催されたアーキテクチャConference2025にて、弊社橋本が『AI x Platform Engineeringでスケーラブルな組織を作るには』を発表しました。この発表で紹介した、AIによるリソース配置・設定情報（AS-IS）の調査とドキュメント化の取り組みで、AWS Resource Explorerを活用しています。

生成AIモデルの支援を受けてリソースの一覧を取得する際に、AWS API MCP Serverを利用することも考えられます。しかし、多くの結果を受け取るとコンテキスト超過・欠落で情報欠損することがあります。

Resource Explorerで取得したリソース一覧を保存し、ローカルで必要な情報を抽出するアプローチが効果的でした。アドホックな調査であれば生成AIモデル経由でAWS CLIを呼び出し、調査対象が明確な場合は要件を元にプログラムからAWS SDKでクエリする手法も有効です。

まとめると、AIによるリソース調査での活用ではResource Explorerを起点とした以下の3段階アプローチが有効でした。

生データの取得（CLI）：Resource Explorerの検索クエリを用いてリソース一覧を取得する。
構造化・フィルタリング：jqやPythonでアカウント番号、リージョン、リソースARN、必要情報のリストにする。設定情報の詳細を一覧化する場合は、AWS CLIによる生データ取得と構造化を繰り返す。
分析・洞察 (LLM/MCP)：リストを元に個別のリソースの設定状況を確認する。

AIエージェントにアカウント横断での調査対象と作業ステップを指示して、リスト抽出する一例になります。

今回の調査で得られたリソース取得の方法と適したユースケースについて、以下の表にまとめます。

方法	適したユースケース
AWS Resource Explorer を AWS CLI でクエリ	アカウント横断でリソースを網羅的に抽出する場合
AWS Resource Explorer を AWS SDK でクエリ	アカウント横断でリソースを網羅的に抽出し、追加処理を行う場合
任意のリソースを AWS API MCP Server 経由でクエリ	対象アカウントとサービスが絞られており対話的な探索をする場合
任意のリソースを AWS CLI/AWS SDK でクエリ	対象アカウントとサービスのリストを元に詳細を取得する場合

タグによるガバナンス確認での活用

Resource Explorerでは、タグの有無をベースにフィルターできます。また、クエリ結果から対象リソースに付与されたタグ値を確認できます。

12月7日のアドベントカレンダー「S3バケットの構成標準化 - 分類とガードレールによる運用改善」では、S3への適切なタグ付与とAWS Configによるガードレール実装を紹介しました。Resource Explorerを活用すれば、アカウント横断でタグの付与漏れを確認できます。

例えばConfigRule-s3-bucket-server-side-encryption-enabledが付与されていないバケットは、-tag.key:の否定検索で以下のように取得できます。

service:s3 resourcetype:s3:bucket -tag.key:ConfigRule-s3-bucket-server-side-encryption-enabled

注意点

AWS Resource Explorerは多数のリソースタイプをカバーしていますが、すべてではありません。利用前にResource Explorer で検索できるリソースタイプを確認することをおすすめします。例えば、Amazon Bedrockの基盤モデルのように、リソースが作成されないサービスは対象外です。

AWS Cost Explorer MCP Serverを併用して、課金が発生しているサービスを確認して組み合わせるとレポート作成に役立ちました。

AWS Organizations構成の見直し

この章では、AWS Resource Explorerをどのアカウントに委任したかを紹介します。

タイミーではAWS セキュリティリファレンスアーキテクチャ (AWS SRA)を参考に、セキュリティOUのアカウントやインフラストラクチャOUの共有サービスアカウントを整備してきました。

組織横断での運用効率化に関わるAWSサービスとして以下が挙げられます。

AWS Healthの組織ビュー
AWS User Notificationsの組織通知
AWS Resource Explorerのマルチアカウントリソース検索

しかし、これら全てを共有サービスアカウントへ委任すると、アカウントの責務が重くなりすぎます。そこで、AWSホワイトペーパー Organizing Your AWS Environment Using Multiple Accounts を参考にしました。インフラストラクチャOUを以下のアカウントへ分割しています。

アカウント	責務
Identityアカウント	AWS IAM Identity Centerの管理
Operations Toolingアカウント	運用ツール、監視、リソース可視化
Backup管理アカウント	バックアップの一元管理