AWS M&G Vol3｜Tag Policies×Resource Explorer×Resource Groups

1. この記事について

Management & Governance本番運用シリーズは、Vol1で「誰が何を作れるか」というアカウント統制のガードレールを、Vol2で「作られた後をどう監視するか」という構成監視・実行監視を積み上げてきました。しかし、この2層が揃っても現場では新しい悩みが生まれます。「組織に何百・何千のリソースがあるのか把握できない」「タグの付け方がアカウントごとにバラバラでコスト配賦ができない」「特定のタグを持つリソース群だけをまとめて操作したいが手段がない」——これらは統制層・監視層のどちらでも解決できない、第3の課題です。

本Vol3は、この「多アカウントのタグ統制・リソース可視化」層を担います。Organizations Tag Policiesで全社共通のタグ許可値を強制し、Resource Explorerで組織横断のリソース検索基盤を委任管理下に構築し、Resource Groupsでタグを軸にした論理グルーピング運用を確立する——この3本柱を、机上の概念解説ではなく、実際に手を動かして本番投入できる深度で解説します。

マルチアカウント運用が数十〜数百アカウント規模に育つと、次の3つの失敗パターンが必ずと言っていいほど顕在化します。

第一に「タグのバラバラ化」です。あるチームは CostCenter を、別のチームは cost_center を使い、値も Production と prod が混在する——このような状態では、Cost Explorerでのコスト配賦もABAC(属性ベースアクセス制御)によるアクセス制御も機能しません。SCP(Vol1)でリソース作成そのものは統制できても、タグの中身までは統制できないためです。

第二に「見えないリソース」です。数百アカウントに広がった環境で、「このワークロードに関連するリソースは全部でどれか」を調べる手段がなく、各アカウントに個別ログインしてコンソールを巡回する運用が常態化します。Configによる構成監視(Vol2)は「登録済みリソースの構成変化」を追えますが、組織全体を横断して素早く検索する用途には向きません。

第三に「一括操作の不在」です。特定タグを持つリソース群だけをまとめて棚卸し・タグ修正・監視対象への追加をしたい場面で、都度スクリプトを書いて対応する属人的な運用が続きます。

本Vol3の3本柱は、この3つの失敗パターンにそれぞれ対応します。Tag Policiesが「タグのバラバラ化」を、Resource Explorerが「見えないリソース」を、Resource Groupsが「一括操作の不在」を解消します。

1-1. 本記事のゴール

本記事を読み終えると、次の3つの運用状態に到達します。

第一に、Organizations Tag Policiesを使って組織全体のタグ許可値を設計し、enforced_for によるenforcementを段階的に有効化できるようになります。「まず特定アカウントで動作を確認してから組織全体へ展開する」という安全な導入手順、および非準拠リソースの準拠レポート取得と是正ワークフローへの接続まで扱います。

第二に、Resource Explorerを委任管理アカウントに設定し、集約リージョンインデックス(aggregator index)を軸にした組織横断検索基盤を構築できるようになります。管理アカウントでの信頼アクセス有効化から、委任管理者へのAWS Resource Access Manager(RAM)によるビュー共有まで、権限委譲の設計を含めて解説します。

第三に、Resource Groupsを使ってクエリベース/スタックベースのグループを設計し、タグ条件による論理グルーピングと一括操作(Resource Groups Tagging APIでの未タグリソース検出を含む)を本番運用へ組み込めるようになります。

これら3本柱は独立した機能ではなく、「タグで統制する(Tag Policies) → 横断的に見つける(Resource Explorer) → タグで束ねて運用する(Resource Groups)」という一連の運用ループとして設計します。§6ではこのループを束ねた統制運用パターンを提示します。

本記事を読み終えた時点の到達状態(チェックリスト)

本記事の構成(学習パス)

本記事は以下の順序でタグ統制・可視化の実装を展開します。各セクションは§3→§4→§5の運用ループを念頭に置いていますが、必要な節から個別に参照できます。

各節を読み終えた時点で、組織全体のタグ統制ポリシーの設計から、横断検索基盤の委任管理、タグベースの一括運用まで、一気通貫で本番投入できる状態に到達します。上記チェックリストの各到達状態について、具体的な検証コマンドや確認手順は§3〜§5の各セクション末尾に記載します。

1-2. 読者像

本記事は、マルチアカウント環境のプラットフォームチームまたはガバナンス担当者を主な対象としています。具体的には、Vol1(Organizations/Control Tower/Service Catalog/CloudTrail Lake)でアカウント統制の土台を、Vol2(Config/Systems Manager/Trusted Advisor/Health Dashboard)で構成監視・実行監視の仕組みを既に確立しており、次の課題として「組織全体に散在するリソースをどう見つけ、どう分類し、タグでどう統制するか」に直面している方を想定します。

具体的には次のような課題を抱えている方に向けた内容です。

• 「タグの付け方がチームやアカウントごとにバラバラで、コスト配賦や請求分析が破綻している」という統制の課題
• 「新しいアカウントが増えるたびに、そこに何があるのか把握できていない」という可視化の課題
• 「特定タグを持つリソース群だけをまとめて棚卸し・一括操作したいが、都度スクリプトを書いている」という運用効率の課題

一方で、単一アカウント運用でOrganizationsを使っていない方、あるいはタグ戦略よりもまずネットワーク設計やIAM権限設計を優先したい方には、本記事より先に取り組むべきテーマがあります。マルチアカウント環境でOrganizationsを既に運用しており、次の一手として「タグ統制と横断可視化」を検討している段階の方が、本記事から最も多くの価値を得られます。

前提知識として、AWS Organizationsの基本操作(OU階層・SCPアタッチ)とIAMの基礎を理解していることを想定します。Vol1/Vol2で解説したOrganizations基盤・Config/Systems Manager運用の知識については本記事では再掲しません。未読の方は先にVol1・Vol2を確認することを推奨します。

なお、Tag Policiesの個々のenforcement文法の全リファレンスやResource Explorerの検索構文の網羅的な解説は公式ドキュメントに譲り、本記事は「本番導入の手順と設計判断」に焦点を当てます。

本記事では扱わない内容として、AWS Configによる構成準拠監視やConformance Packsによるルール一括管理はVol2で詳説済のため本記事では扱いません。また、Control TowerのAccount FactoryやService CatalogによるStackSetsの一括展開制御はVol1・Service Catalog Vol2のスコープであり、本記事では触れる場合も委任管理・org-native視点に限定します。コストの可視化・最適化そのもの(Cost Explorer/Budgets)は別シリーズのテーマとし、本記事はあくまで「タグ統制とリソース可視化」に焦点を当てます。

1-3. なぜ今これを書くか（シリーズ内の差別化軸）

Management & Governance本番運用シリーズは、Vol1「アカウント統制・Landing Zone」→ Vol2「構成監視・実行監視」→ Vol3(本記事)「多アカウントのタグ統制・リソース可視化」という3段階で、組織全体のガバナンスを積み上げる構成になっています。

本Vol3の主軸はTag Policiesです。既存コーパスに専用節を持つ記事がなく、許可値強制・準拠レポート・継承と例外・enforcementを扱う純空白領域として本記事が最初の詳解となります。

本記事から読み始めても内容は完結しますが、Vol1で解説したOU階層・SCPの基礎、Vol2で解説したConfig/Systems Managerの構成監視を先に理解していると、Tag PoliciesがSCPと同じOrganizations基盤をどう使い、Resource Explorer/Resource GroupsがConfigの構成監視とどう役割分担するのかをより深く理解できます。Vol1・Vol2未読の方は、まず本記事で「タグ統制・可視化」の実務価値を確認した上で、必要に応じて前2作を参照する読み方でも問題ありません。

Resource ExplorerとResource Groupsについては、Service Catalog Vol2に「AppRegistry移行の代替候補」として軽く触れた記述が存在します。本Vol3はそれとは異なるレンズ——委任管理アーキテクチャ・マルチリージョンインデックス・RAMビュー共有・タグベース一括運用という「本番運用DEEP」——で両サービスを掘り下げます。したがって内容は重複せず、Service Catalog Vol2の読者にも新しい価値を提供します。

加えて、本Vol3の3本柱はVol1・Vol2とも設計思想でつながっています。Vol1のSCPは「何を作れるか」を組織全体で強制するガードレールですが、作成後のリソースにどんなタグが付くかまでは関与しません。Tag PoliciesはOU階層の継承モデルを使い、SCPと同じOrganizations基盤の上で「作られたリソースにどんなタグが付いているべきか」を強制する、いわば「タグ版のSCP」として補完関係にあります。公式ドキュメントでも、Tag Policiesの準拠状況の確認にはAWS Resource Groupsを使う設計になっており、本Vol3の3本柱(Tag Policies・Resource Explorer・Resource Groups)が単なる並列列挙ではなく機能的に連携している点は、§6で改めて運用ループとして明示します(取得日: 2026-07-13)。

また、StackSetsによる組織全体への一括展開メカニクス(ProvisioningPreferencesによる同時実行制御・失敗許容・パイロット/本番の2段階ロールアウト)は、Service Catalog Vol2 §7で既に詳説済です。本Vol3でStackSetsに言及する場合も、Organizationsの信頼アクセスや新規アカウント参加時の自動デプロイ、委任管理といったorg-native視点に限定し、一括展開の実装詳細は再解説せず §6 で委譲します。

前作 Vol2（Config × Systems Manager × Trusted Advisor × Health）を読む

本シリーズはAWSのサービスアップデートに合わせて内容を継続的に更新します。最新の公式ドキュメントも併せてご参照ください。

2. 前提・環境・準備

本章では、§3以降で実装するTag Policies・Resource Explorer・Resource Groupsのすべてが前提とするアカウント構成・権限・技術スタックを整えます。Vol1で構築したOrganizations基盤、Vol2で確立した構成監視の運用がすでに存在することを前提とし、本章はその上に「タグ統制・可視化」層を載せるための準備に特化します。

2-1. 前提環境

Organizationsの前提条件(全機能有効化)

Tag Policiesは、Organizationsが「全機能が有効(all features enabled)」なモードで運用されている場合にのみ利用できます(2026-07-13時点、docs.aws.amazon.com/organizations/ 確認)。一括請求(consolidated billing)のみのモードでは利用できないため、Vol1の手順でOrganizationsを構築済みであれば通常この条件を満たしていますが、念のため以下のコマンドで確認します。

# Organizationsの機能セットを確認(FeatureSet: ALL であること)
aws organizations describe-organization \
  --query 'Organization.FeatureSet' \
  --output text

アカウント構成の役割分担

Tag Policies・Resource Explorer・Resource Groupsは、いずれも管理アカウント(management account)と委任管理アカウント(delegated administrator account)という2つのロールを前提に設計します。

管理アカウントに日常運用の全権限を集中させず、委任管理アカウントに横断検索基盤の運用を委譲することで、最小権限の原則を保ったまま組織横断の可視化を実現できます。

信頼アクセス(trusted access)の有効化確認

Resource Explorerの組織横断検索を有効化するには、Organizations側でResource Explorerとの信頼アクセスを有効にする必要があります。

# 管理アカウントで、Resource Explorerの信頼アクセスが有効か確認
aws organizations list-aws-service-access-for-organization \
  --query "EnabledServicePrincipals[?ServicePrincipal=='resource-explorer-2.amazonaws.com']"

# 未有効の場合は有効化する
aws organizations enable-aws-service-access \
  --service-principal resource-explorer-2.amazonaws.com

委任管理者(delegated administrator)の登録

信頼アクセスを有効化した後、Resource Explorerの委任管理者を1アカウントだけ登録します。Resource Explorerは委任管理者を組織につき1アカウントのみサポートするため、登録先アカウントの選定は事前に運用チームで合意しておく必要があります。

# 管理アカウントで、委任管理者アカウントを登録する
aws organizations register-delegated-administrator \
  --account-id <DELEGATED_ADMIN_ACCOUNT_ID> \
  --service-principal resource-explorer-2.amazonaws.com

# 登録済みの委任管理者を確認する
aws organizations list-delegated-administrators \
  --service-principal resource-explorer-2.amazonaws.com

委任管理者を後から変更・解除すると、その委任管理アカウントに作成済みの組織横断ビューがすべて削除される点に注意してください。委任管理者の選定は、頻繁に変更しない前提で決定します。

アカウント構成の全体像

本記事が前提とするアカウント構成を図示すると、以下のような3層構造になります。

management account (管理アカウント)
  ├─ Organizations 全機能有効化
  ├─ Tag Policy 作成・OUへのアタッチ
  └─ resource-explorer-2.amazonaws.com への信頼アクセス有効化
  │
  ▼ register-delegated-administrator
delegated administrator account (委任管理アカウント)
  ├─ Resource Explorer 集約インデックス(aggregator index)
  ├─ 組織/OUスコープの view 作成
  └─ RAM で view をメンバーアカウントへ共有
  │
  ▼ ローカルインデックス作成 + タグ付与
member accounts (メンバーアカウント ×N)
  ├─ Resource Explorer ローカルインデックス
  ├─ Tag Policy の継承(OU経由)
  └─ Resource Groups(クエリベース/スタックベース)

AWS CLIバージョンの要件

aws --version

リージョン可用性(取得日: 2026-07-13)

Tag PoliciesとResource Groupsは商用リージョン全般で利用可能なグローバル/リージョナル機能ですが、Resource Explorerのマルチアカウント検索は対応リージョンが限定されています。東京リージョン(ap-northeast-1)はマルチアカウント検索の対応リージョンに含まれていることを公式ドキュメントで確認済みです。

IAM権限(3サービス共通の最小権限例)

委任管理アカウントで本記事の作業をする運用ロールには、以下の権限を最小権限原則で付与します。

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Sid": "TagPolicyManagement",
"Effect": "Allow",
"Action": [
  "organizations:CreatePolicy",
  "organizations:UpdatePolicy",
  "organizations:AttachPolicy",
  "organizations:DetachPolicy",
  "organizations:DescribePolicy",
  "organizations:ListPoliciesForTarget"
],
"Resource": "*"
 },
 {
"Sid": "ResourceExplorerAdmin",
"Effect": "Allow",
"Action": [
  "resource-explorer-2:CreateIndex",
  "resource-explorer-2:UpdateIndexType",
  "resource-explorer-2:CreateView",
  "resource-explorer-2:AssociateDefaultView",
  "resource-explorer-2:GetIndex",
  "resource-explorer-2:ListIndexes",
  "resource-explorer-2:Search"
],
"Resource": "*"
 },
 {
"Sid": "ResourceGroupsAndTagging",
"Effect": "Allow",
"Action": [
  "resource-groups:CreateGroup",
  "resource-groups:UpdateGroupQuery",
  "resource-groups:ListGroupResources",
  "tag:GetResources",
  "tag:TagResources",
  "tag:UntagResources",
  "tag:GetComplianceSummary"
],
"Resource": "*"
 },
 {
"Sid": "RamViewSharing",
"Effect": "Allow",
"Action": [
  "ram:CreateResourceShare",
  "ram:AssociateResourceShare",
  "ram:GetResourceShares"
],
"Resource": "*"
 }
  ]
}

tag:GetComplianceSummary は、Tag Policiesの準拠レポートをResource Groups Tagging APIから取得する際に使用するアクションです。公式ドキュメントでも「Tag Policiesの準拠状況確認にはResource Groupsを使う」設計になっており、この権限セットは3本柱を横断した運用を前提にしています。

2-2. 使用技術スタック

本Vol3で扱う技術スタックを、統制・可視化・共有・運用の4レイヤに整理します。

Resource Explorerのインデックス種別の違い

Resource Explorerには「ローカルインデックス」と「集約インデックス」という2種類のインデックスがあります。両者を混同すると、検索結果が自リージョンに限定されたまま気づかない、という事故につながるため、§4で実装する前に整理しておきます。

2-3. ゴール状態の定義

本記事(§2〜§6)を読み終えた時点で、以下の状態に到達します。

各到達状態の具体的な検証コマンドは、§3(Tag Policies)・§4(Resource Explorer)・§5(Resource Groups)の各セクション末尾に記載します。

3. Tag Policies による多アカウントのタグ統制（主軸）

本節では、既存コーパスに専用節を持たない純空白領域として、Tag Policiesの本番運用を4つの観点——基本構造と継承モデル(3-1)・enforcementと例外設計(3-2)・準拠レポートの運用(3-3)・Terraform/CLIによる宣言的管理(3-4)——から深く解説します。Tag Policiesは「タグ版のSCP」と表現できますが、SCPが「作れるかどうか」を強制するのに対し、Tag Policiesは「作られたリソースにどんなタグが付いているべきか」を強制・報告する点が本質的に異なります。この違いを踏まえ、まず基本構造から見ていきます。

3-1. Tag Policy の基本構造と継承モデル

Tag Policyは、タグキーごとに許可される値・強制対象リソースタイプをJSONで宣言するポリシードキュメントです。中核となる要素は tag_key・tag_value・enforced_for の3つで、いずれも @@assign(値を置換)・@@append(リストに追加)・@@remove(リストから除外)という継承演算子を使って定義します(2026-07-13時点、docs.aws.amazon.com/organizations/latest/userguide/tag-policies-syntax.html 確認)。

{
  "tags": {
 "CostCenter": {
"tag_key": {
  "@@assign": "CostCenter"
},
"tag_value": {
  "@@assign": ["100-platform", "200-analytics", "300-shared"]
},
"enforced_for": {
  "@@assign": ["ec2:instance", "s3:bucket", "rds:db"]
}
 },
 "Environment": {
"tag_key": {
  "@@assign": "Environment"
},
"tag_value": {
  "@@assign": ["production", "staging", "development"]
}
 }
  }
}

CostCenter は enforced_for を持つため後述のenforcement対象になりますが、Environment は tag_value のみで enforced_for を持たないため「準拠レポートには現れるが、タグ付け操作自体はブロックされない」レポート専用モードで動作します。この2モードの違いは3-2で詳しく扱います。

OU階層での継承とマージ動作

Tag Policyはroot・OU・アカウントの各階層にアタッチでき、実際に適用される「実効ポリシー(effective policy)」は、rootからアカウントに向かって階層を降りながら各階層のポリシーをマージした結果になります。ここで重要なのは、マージが「ポリシー全体の上書き」ではなく「要素単位のマージ」である点です。

OU(Platform)では tag_value に対して @@append を使っているため、rootで定義した3値に 400-platform-sandbox が追加された4値が、配下のsandboxアカウントに継承されます。enforced_for はOUで再定義していないため、rootの値がそのまま継承されます。このように、子階層は「要素ごとに」上書き・追加・除外を選べるため、全社共通の骨格をrootで固定しつつ、特定OUだけタグ値を拡張する、といった柔軟な運用が可能です。

一方、rootや親OUのポリシー作成者が「この要素は子階層で一切変更させたくない」と判断した場合は、@@operators_allowed_for_child_policies で許可する演算子自体を制限できます。例えば tag_key に対して "@@operators_allowed_for_child_policies": ["@@assign"] のように空リストに近い制限を設定すると、子階層のポリシーがその要素を上書き・追加できなくなり、全社共通の必須タグキーを構造的に固定できます。全社統制上「絶対に緩めてはいけない」要素(必須タグキーの存在そのものなど)にはこの制御を使い、「現場ごとの裁量を残したい」要素(タグ値の追加など)には @@append を使う、という設計判断がTag Policy運用の肝になります。

管理アカウントからの配布

Tag Policyの作成・アタッチは管理アカウント(または委任管理者に権限委譲した場合はそちらでも可能)から行います。§2の権限例で付与した organizations:CreatePolicy・organizations:AttachPolicy を使い、まずroot直下に全社共通ポリシーを作成し、その後OU単位で追加ポリシーをアタッチしていく順序が安全です。root→OUの順で段階的にアタッチすることで、影響範囲を確認しながら展開できます。

3-2. 許可値の強制（enforcement）と例外設計

Tag Policiesには「準拠レポート専用モード」と「enforcementモード」の2段階があり、この区別が本番導入の安全性を左右します。

enforcementの効果範囲を正しく理解する

enforced_for によるブロックは、あくまで「その仕組みに対応したAPI呼び出し(タグ付け操作)」に対してのみ働きます。ポリシー適用前から存在する非準拠リソースが自動的に修正されることはなく、また既存タグを変更しない限りそのリソースは非準拠のまま残り続けます。つまりenforcementは「新規の非準拠を防ぐ仕組み」であり、「既存の非準拠を是正する仕組み」ではありません。既存リソースの是正は3-3の準拠レポートを起点にした運用でカバーします。

段階的導入パターン(本番投入の推奨手順)

全社一括でenforcementを有効化すると、想定外のリソースタイプでタグ付けが失敗し、デプロイパイプラインが連鎖的に止まるリスクがあります。以下の3段階で導入することを推奨します。

1. 第1段階(観測): 全社共通ポリシーを enforced_for なしでrootにアタッチし、準拠レポート専用モードで運用する。この時点でAPI呼び出しはブロックされないため、既存ワークロードへの影響はゼロです。
2. 第2段階(パイロット): 準拠状況を数週間観測し非準拠リソースの傾向を把握した後、影響範囲の小さい1つのOU(サンドボックスやPoC用OUなど)にのみ enforced_for 付きポリシーをアタッチし、実際にenforcementの挙動を検証する。
3. 第3段階(全社展開): パイロットOUで想定外の失敗がないことを確認した上で、rootまたは主要OUに enforced_for を段階的に広げる。リソースタイプも一度に全部指定せず、影響の大きい ec2:instance や s3:bucket から先に有効化し、様子を見ながら他のリソースタイプへ広げます。

例外設計パターン

全社で一律にenforcementを強制すると、業務が回らなくなるケースは必ず出てきます。代表的な例外設計は次の2つです。

• リソースタイプ単位の例外: enforced_for に列挙するリソースタイプを絞り込み、まだ運用が追いついていないリソースタイプは外しておく。準拠レポートには表示され続けるため、可視性を失わずにブロックだけを緩和できます。
• OU単位の例外: 例外を認めたいOU(レガシーシステムが稼働するOUなど)に対して、enforced_for を @@remove で明示的に除外する、または tag_value に @@append で暫定的な許可値(legacy-untagged など)を追加した専用ポリシーをアタッチする。全社ポリシーの骨格は維持しつつ、特定OUだけ緩和幅を持たせられます。

いずれの例外パターンも「例外を認める代わりに準拠レポートでの可視性は失わない」ことが設計の前提です。ブロックを緩めても、非準拠リソースとして棚卸しの対象には残り続けるようにします。

3-3. 準拠レポートと非準拠リソースの検出

Tag Policiesの準拠状況は、AWS公式ドキュメントでも案内されている通りResource Groups Tagging APIから取得します(2026-07-13時点確認)。§2のIAM権限例で付与した tag:GetComplianceSummary と tag:GetResources を使い、次の2つの粒度で準拠状況を把握します。

サマリ粒度での準拠状況取得

# リージョン・リソースタイプ・タグキー単位の準拠サマリを取得
aws resourcegroupstaggingapi get-compliance-summary \
  --region ap-northeast-1 \
  --group-by TARGET_ID REGION RESOURCE_TYPE \
  --query 'SummaryList[?ComplianceDetails.ComplianceStatus==<code>false</code>]'

get-compliance-summary は組織横断ではなく実行アカウント単位の集計である点に注意してください。組織全体の傾向を把握する場合は、§4で構築するResource Explorerの委任管理アカウントから各メンバーアカウントへ横断的にこのAPIを呼び出す運用、またはメンバーアカウントごとに定期実行して結果を集約する運用のいずれかを組みます。

個別リソース粒度での非準拠リソース検出

# 非準拠リソースのみをARN付きで一覧取得(準拠リソースは除外)
aws resourcegroupstaggingapi get-resources \
  --region ap-northeast-1 \
  --include-compliance-details \
  --exclude-compliant-resources \
  --query 'ResourceTagMappingList[].{ARN:ResourceARN, Tags:Tags, NonCompliantKeys:ComplianceDetails.NoncompliantKeys}'

--exclude-compliant-resources を付けることで、非準拠リソースのARNとどのタグキーが非準拠なのか(NoncompliantKeys)だけを効率よく取得できます。これが是正ワークフローの起点になるデータです。

是正ワークフローへの接続

準拠レポートを取得するだけでは非準拠リソースが減らないため、次のような運用ループへ接続します。

このループを回す際は、Vol2で構築したConfig/Systems Managerの運用体制と役割を混同しないよう注意が必要です。Configは「リソースの構成がルールに準拠しているか」を継続的に評価する仕組みであり、Tag Policiesの準拠レポートは「タグの値がポリシーに準拠しているか」に特化した別軸のデータです。両者を1つのダッシュボードに統合する場合も、データソースは分けたまま可視化層で束ねる設計が安全です。

3-4. Terraform / CLI による Tag Policy 運用

Tag Policyそのものは、Terraformの aws_organizations_policy リソース(type = "TAG_POLICY")と aws_organizations_policy_attachment リソースの組み合わせで宣言的に管理できます。

terraform {
  required_version = ">= 1.7.0"
  required_providers {
 aws = {
source  = "hashicorp/aws"
version = "~> 5.70"
 }
  }
}

resource "aws_organizations_policy" "cost_center_tag_policy" {
  name  = "org-cost-center-tag-policy"
  description = "全社共通CostCenter/Environmentタグ許可値ポリシー"
  type  = "TAG_POLICY"

  content = jsonencode({
 tags = {
CostCenter = {
  tag_key = {
 "@@assign" = "CostCenter"
  }
  tag_value = {
 "@@assign" = ["100-platform", "200-analytics", "300-shared"]
  }
  enforced_for = {
 "@@assign" = ["ec2:instance", "s3:bucket", "rds:db"]
  }
}
Environment = {
  tag_key = {
 "@@assign" = "Environment"
  }
  tag_value = {
 "@@assign" = ["production", "staging", "development"]
  }
}
 }
  })
}

resource "aws_organizations_policy_attachment" "cost_center_tag_policy_root" {
  policy_id = aws_organizations_policy.cost_center_tag_policy.id
  target_id = data.aws_organizations_organization.current.roots[0].id
}

data "aws_organizations_organization" "current" {}

Terraform管理を始める前の前提条件

aws_organizations_policy は、対象の組織で TAG_POLICY というポリシータイプ自体が有効化されていることを前提とします。この有効化操作(enable-policy-type)はTerraformのリソースとして宣言的に管理する手段がなく、事前にCLIで一度だけ実行しておく必要がある点に注意してください。

# root IDを取得
aws organizations list-roots --query 'Roots[0].Id' --output text

# TAG_POLICYポリシータイプを有効化(初回のみ・Terraform管理対象外)
aws organizations enable-policy-type \
  --root-id <ROOT_ID> \
  --policy-type TAG_POLICY

この手順を terraform plan の前提条件としてREADMEやCI/CDのpre-applyチェックに明記しておかないと、「TerraformでTag Policyリソースを作ったのにアタッチでエラーになる」という初見のハマりどころになります。

CI/CDでのポリシー配布

Tag Policyの変更は、SCPと同様に組織全体へ影響する変更のため、通常のアプリケーションデプロイと同じパイプラインに混在させず、Organizations専用のTerraformルート(state分離)で管理することを推奨します。

# CI/CDパイプライン概要(GitHub Actions想定)
# 1. PRトリガーで terraform plan を実行し、diffをPRコメントに投稿
# 2. ガバナンスチームのレビュー承認を必須化(CODEOWNERSでOrganizations管理者を指定)
# 3. main マージ後、terraform apply を実行(enforced_for拡大を含む変更は
# 3-2の段階的導入パターンに従い、1PR=1段階の変更に限定する)
# 4. apply後、get-compliance-summary を実行し非準拠リソース数の急増がないか自動チェック

ポイントは、enforced_for の追加(=enforcementモードへの移行)を含むPRは、タグ値の追加(@@append)のようなレポート専用の変更とは別PRに分離することです。1PRに複数の変更を混在させると、想定外の失敗が起きた際にどの変更が原因かの切り分けが難しくなります。また、apply後に準拠サマリを自動チェックするステップを組み込むことで、ポリシー変更が意図せず大量の非準拠リソースを生んでいないかを即座に検知できます。

4. Resource Explorer による組織横断リソース可視化

Service Catalog Vol2では、Resource ExplorerとResource Groupsは「AppRegistry移行の代替候補」として軽く紹介されるにとどまりました。本節はそのレンズを引き継がず、委任管理体制のもとで組織横断のリソース可視化基盤を本番投入するための3つの設計判断——マルチリージョンインデックスの配置(4-1)・委任管理者による組織横断検索の有効化(4-2)・ビューのガバナンスとRAMによる共有(4-3)——を扱います。Resource Explorerの検索機能自体は単純ですが、検索が実際にどこまでの範囲を対象にするかは、インデックスの配置とビューのスコープ設計に完全に依存します。この設計を誤ると「検索して0件だったので存在しない」という誤った判断を組織全体に広めてしまう事故につながるため、本節は検索範囲の設計原則を軸に解説します。

4-1. マルチリージョンインデックスアーキテクチャ

Resource Explorerは、リソース情報をリージョンごとに「ローカルインデックス」として保持します(2026-07-13時点、docs.aws.amazon.com/resource-explorer/latest/userguide/manage-aggregator-region.html 確認)。例えば東京リージョンとバージニア北部リージョンにそれぞれリソースがある場合、各リージョンのローカルインデックスにそのリージョン分の情報だけが格納されます。ローカルインデックスは、検索権限を持つユーザーが該当リージョンで検索操作を行った時点で自動作成されるほか、create-index で明示的に作成できます。

複数リージョンを横断して検索するには、いずれか1つのリージョンのローカルインデックスを「アグリゲーターインデックス」に昇格させます。アグリゲーターインデックスは、そのアカウント内の他の全リージョンのローカルインデックスの複製を保持し、アグリゲーターインデックスが存在するリージョンで実行した検索だけが全リージョン横断の結果を返せます。アグリゲーターインデックスはアカウントにつき1つのみ設定可能で、既にアグリゲーターを持つアカウントで別リージョンを新たにアグリゲーターに指定すると、既存のアグリゲーターはローカルインデックスに降格します。

# 対象リージョンにローカルインデックスを作成する
aws resource-explorer-2 create-index --region ap-northeast-1

# 作成済みのローカルインデックスをアグリゲーターインデックスに昇格させる
aws resource-explorer-2 update-index-type \
  --arn arn:aws:resource-explorer-2:ap-northeast-1:<ACCOUNT_ID>:index/<INDEX_ID> \
  --type AGGREGATOR

# インデックスの状態を確認する(ACTIVEになるまで検索結果は不完全)
aws resource-explorer-2 get-index --region ap-northeast-1 \
  --query '{Arn:Arn, Type:Type, State:State}'

組織全体へ展開する際の運用上の注意点

AWS Systems ManagerのQuick Setupを使うと、組織内の複数アカウント・複数リージョンへ一括でResource Explorerを有効化できます(2026-07-13時点、docs.aws.amazon.com/systems-manager/latest/userguide/Resource-explorer-quick-setup.html 確認)。この際、対象アカウント・対象OU(または組織全体)とアグリゲーターインデックスを置くリージョンを1つ選択しますが、選択したアカウントの中に既に別リージョンでアグリゲーターインデックスを持つアカウントが含まれていた場合、そのアカウントの既存アグリゲーターは自動的に新しいリージョンへ置き換えられる点に注意が必要です。個別チームが先行してResource Explorerを試験導入していた環境では、組織一括展開の前に既存のアグリゲーター配置を棚卸ししておかないと、意図せず検索基点リージョンが変わってしまいます。なお、組織向けQuick Setupは管理アカウント自体にはリソースを配置しません(委任管理アカウントおよびメンバーアカウントのみが対象)。

4-2. 委任管理者による組織横断検索

§2で有効化した信頼アクセス(trusted access)と委任管理者(delegated administrator)の登録は、Resource Explorerの操作を委任管理アカウントへ委譲するための前提条件です。Resource Explorerの委任管理者は組織につき1アカウントのみサポートされ、管理アカウントに準じた操作(組織全体を対象にしたQuick Setupの実行やビューの作成)が行えます(2026-07-13時点、docs.aws.amazon.com/resource-explorer/latest/userguide/ 確認)。

委任管理者に特有の権限は、ビューのスコープを「組織スコープ(organization scope)」「OUスコープ(organizational unit scope)」「アカウントスコープ(account-level scope)」の3段階から選んで作成できる点です。組織スコープのビューを検索の起点に選べば、Quick Setupで有効化した全メンバーアカウントのリソースを単一の検索結果として横断的に取得できます。OUスコープのビューは、特定OU配下のアカウントだけに検索範囲を絞りたい場合(例えば本番系OUだけを横断検索したいが、サンドボックスOUは含めたくない場合)に使います。

# 委任管理アカウントで、作成済みビューの一覧とスコープを確認する
aws resource-explorer-2 list-views --region ap-northeast-1

aws resource-explorer-2 get-view \
  --view-arn <ORG_SCOPE_VIEW_ARN> \
  --query '{ViewArn:View.ViewArn, Scope:View.Scope, Filters:View.Filters}'

# 組織スコープビューを使い、東京リージョンのS3バケットを組織全体から横断検索する
aws resource-explorer-2 search \
  --view-arn <ORG_SCOPE_VIEW_ARN> \
  --query-string "region:ap-northeast-1 resourcetype:s3:bucket" \
  --max-results 20

検索結果に想定より少ないアカウント数しか含まれない場合、原因の多くは「対象アカウントにローカルインデックスがまだ存在しない」か「ビューのスコープが組織全体ではなくOU限定になっている」のいずれかです。Quick Setup実行直後は各アカウントへのインデックス配布が完了するまで一定のタイムラグがあるため、展開直後に検索結果が不完全でも即座に設計不備と判断せず、get-index で各アカウントのインデックス状態が ACTIVE になっていることを確認してから調査する順序が安全です。

4-3. ビューのガバナンスと RAM によるビュー共有

委任管理アカウントで組織スコープ/OUスコープのビューを作成しただけでは、メンバーアカウント側からそのビューを使った検索はできません。ビューをメンバーアカウントへ利用可能にするには、AWS RAM(Resource Access Manager)による共有が必須です(2026-07-13時点、docs.aws.amazon.com/resource-explorer/latest/userguide/configure-views-share.html 確認)。ビューの共有は、組織の管理アカウントまたは委任管理者のみが実行できます。

# 組織スコープビューを組織全体へRAM共有する
aws ram create-resource-share \
  --name org-wide-resource-explorer-view \
  --resource-arns <ORG_SCOPE_VIEW_ARN> \
  --principals <ORGANIZATION_ARN>

# OUスコープビューを特定OUへRAM共有する場合はOUのARNをprincipalsに指定する
aws ram create-resource-share \
  --name prod-ou-resource-explorer-view \
  --resource-arns <OU_SCOPE_VIEW_ARN> \
  --principals <PRODUCTION_OU_ARN>

# 共有状態を確認する
aws ram get-resource-shares --resource-owner SELF \
  --query 'resourceShares[?status==<code>ACTIVE</code>].[name,status]'

RAM共有には、組織/OU/アカウントが増減した際にRAM側が共有の付与・剥奪を自動的に追随するという運用上の利点があります。新規アカウントが対象OUに参加すれば自動的にビューへのアクセスが有効化され、OUから離脱すれば自動的に無効化されるため、メンバーアカウントの増減のたびに共有設定を手動更新する必要がありません。

§4の到達状態を検証する

委任管理アカウントから組織スコープビューで検索した結果に複数のメンバーアカウントのリソースが含まれていること、およびRAM共有のステータスが ACTIVE であることの両方を確認して初めて、「組織全体を単一ビューで横断検索できる」という§2-3のゴール状態に到達したと判断できます。片方だけの確認では、ビューは存在するが共有されておらずメンバーアカウント側からは使えない、という状態を見落とすため注意してください。

5. Resource Groups による論理グルーピングとタグベース運用

§3のTag Policiesで許可値を強制し、§4のResource Explorerで組織横断のリソースを見つけられるようになっても、「見つけたリソース群をどう束ねて日常運用に組み込むか」という最後の課題が残ります。本節では、Resource Groupsのグループ設計(5-1)とタグベースの一括操作(5-2)を扱い、この最後の課題を解消します。

5-1. クエリベースとスタックベースのグループ設計

Resource Groupsのグループは、内部的にはすべて ResourceQuery というクエリ定義を持ちますが、クエリの種類によって2つのタイプに分かれます(2026-07-13時点、docs.aws.amazon.com/ARG/latest/userguide/gettingstarted-query.html 確認)。

タグベースグループ:動的なメンバーシップ

タグベースグループは、条件に一致する限りリソースが増減してもメンバーシップが自動的に追随する点が最大の特徴です。新しくタグを付与したリソースは自動的にグループへ加わり、タグを外せば自動的に抜けます。

# CostCenter=100-platform かつ Environment=production のEC2/RDSリソースをグルーピングする
aws resource-groups create-group \
  --name platform-production-resources \
  --resource-query '{
 "Type": "TAG_FILTERS_1_0",
 "Query": "{\"ResourceTypeFilters\":[\"AWS::EC2::Instance\",\"AWS::RDS::DBInstance\"],\"TagFilters\":[{\"Key\":\"CostCenter\",\"Values\":[\"100-platform\"]},{\"Key\":\"Environment\",\"Values\":[\"production\"]}]}"
  }'

スタックベースグループ:静的なメンバーシップ

スタックベースグループは、指定したCloudFormationスタックが直接作成したリソースだけをメンバーとし、後からそのリソースが間接的に作った別リソース(例えばAuto Scalingグループが起動したEC2インスタンス)は含みません。また子スタックを持つ親スタックを指定した場合でも、子スタックは1つのメンバー(子スタックそのもの)として扱われ、子スタックの中身までは展開されません。有効なメンバーシップを持てるスタックのステータスも CREATE_COMPLETE・CREATE_IN_PROGRESS・DELETE_FAILED・DELETE_IN_PROGRESS・REVIEW_IN_PROGRESS に限られ、DELETE_COMPLETE などへ遷移するとグループ自体は残りますがメンバーは0件になります。

# 特定のCloudFormationスタックが直接作成したS3バケットだけをグルーピングする
aws resource-groups create-group \
  --name app-foo-stack-buckets \
  --resource-query '{
 "Type": "CLOUDFORMATION_STACK_1_0",
 "Query": "{\"ResourceTypeFilters\":[\"AWS::S3::Bucket\"],\"StackIdentifier\":\"arn:aws:cloudformation:ap-northeast-1:<ACCOUNT_ID>:stack/app-foo/<STACK_UUID>\"}"
  }'

使い分けの指針

タグベースグループは、「特定タグを持つリソース群」という運用横断の切り口(コストセンター単位・環境単位)でリソースを束ね、リソースの増減へ追従させたい場合に選びます。一方スタックベースグループは、「1つのデプロイ単位(アプリケーションスタック)が持つリソースだけ」をパッチ適用やモニタリング対象として束ねたい場合に選びます。両者は排他ではなく、同じリソースが両方のグループに同時に属することも一般的です。

5-2. タグベース運用と一括操作

未タグ・非準拠リソースの検出

Resource Groups Tagging APIの TagFilters は、キーを指定して値を省略(または空リストを指定)すると「そのキーが任意の値で付与されているリソース」に一致します。裏を返すと、このAPI単体では「特定のタグキーが付いていないリソース」を直接絞り込むことはできません。そのため、実務では次の2ステップで未タグリソースを検出します。

# ①対象タイプの全リソースを取得する(タグフィルタなし)
aws resourcegroupstaggingapi get-resources \
  --resource-type-filters ec2:instance s3 rds:db \
  --query 'ResourceTagMappingList[].ResourceARN' > all_resources.json

# ②必須タグキー(CostCenter)を持つリソースだけを取得する
aws resourcegroupstaggingapi get-resources \
  --resource-type-filters ec2:instance s3 rds:db \
  --tag-filters Key=CostCenter \
  --query 'ResourceTagMappingList[].ResourceARN' > tagged_resources.json

# ③①と②の差分が「CostCenterタグ未設定のリソース」
comm -23 <(sort all_resources.json) <(sort tagged_resources.json)

§4で構築したResource Explorerの組織横断ビューを①のリソース一覧取得に使えば、単一アカウントのAPI呼び出しだけでは追えないアカウント横断の未タグリソースも洗い出せます。なお、Tag Policiesによる準拠評価(enforcement対象タグの許可値違反)は§3-3で解説した --include-compliance-details --exclude-compliant-resources を使う専用の経路があり、本節の「タグキー自体の有無」の検出とは区別して運用します。

グループ単位の一括操作

グループのメンバーを取得し、そのARNに対して一括でタグ付け・タグ削除をすることで、グループを起点にした運用の自動化ができます。

# グループのメンバーリソースを取得する
aws resource-groups list-group-resources \
  --group-name platform-production-resources \
  --query 'ResourceIdentifiers[].ResourceArn' --output text

# 取得したARN群に対して一括でタグを追加する
aws resourcegroupstaggingapi tag-resources \
  --resource-arn-list <ARN1> <ARN2> <ARN3> \
  --tags Owner=platform-team,ReviewedAt=2026-07-13

# 不要になったタグを一括削除する
aws resourcegroupstaggingapi untag-resources \
  --resource-arn-list <ARN1> <ARN2> <ARN3> \
  --tag-keys TemporaryException

この一括操作をEventBridge Schedulerで定期実行するLambdaに組み込めば、3-3で構築した準拠レポートの是正ワークフロー(検出→通知→是正→再検証)の「③是正」ステップを、担当チームの手作業ではなくグループ単位の自動化に置き換えられます。この統合運用の全体像は§6で改めてループとして整理します。

§5の到達状態を検証する

タグベースグループについては、意図したタグ条件でメンバー数が0件になっていないか(list-group-resources の結果件数で確認)、スタックベースグループについては対象スタックのステータスが有効な範囲内にあるか(aws cloudformation describe-stacks で StackStatus を確認)の両方を確認し、いずれも問題なければ§2-3の「Resource Groups」到達状態を満たしたと判断します。

6. 3サービスを束ねた統制運用パターンと既存記事との棲み分け

§3〜§5では、Tag Policies・Resource Explorer・Resource Groupsをそれぞれ独立した節として深掘りしてきましたが、本番運用ではこの3つを個別に導入しただけでは「タグ統制・可視化が定着した」状態には到達しません。本節では、これまで各節末尾で個別に触れてきた要素——3-3の是正ワークフロー、4-2の組織横断検索、5-2のグループ単位一括操作——を1つの日次運用ループとして統合する設計(6-1)と、隣接する既存記事との境界線を明確にするクロスリンク委譲(6-2)を扱います。

6-1. タグ統制→横断発見→論理分類の運用ループ

Tag Policies(統制)・Resource Explorer(発見)・Resource Groups(分類)は、単独でも価値を持ちますが、「統制→発見→突合→分類→是正→再検証」という一連のループとして日次で回して初めて、§2-3で定義した「統合運用」のゴール状態に到達します。

①統制(Tag Policies)②発見(Resource Explorer)
enforced_for で新規の→ 委任管理アカウントの組織スコープ
非準拠タグ付けをブロックビューで全リソースを横断検索
  │  │
  ▼  ▼
③突合(get-compliance-summary / ④分類(Resource Groups)
get-resources --exclude-  タグ条件で非準拠・未タグ
compliant-resources)リソース群を動的グルーピング
  │  │
  └────────────┬───────────────────┘
 ▼
  ⑤是正(tag-resourcesで一括タグ修正)
 │
 ▼
  ⑥再検証(翌日の①へ回帰・EventBridge Schedulerで自動化)

各ステップの実行アカウントと参照節を整理すると、次の通りです。

このループの要点は、②の発見を委任管理アカウントに一元化することで、③の突合が単一アカウントのget-compliance-summaryでは捉えられない組織横断の非準拠傾向を把握できる点、および④の分類をResource Groupsのタグベースグループとして固定しておくことで、⑤の是正対象が毎回スクリプトを書き直す属人的な作業ではなくlist-group-resourcesの出力をそのまま渡せる定型作業になる点です。Tag Policiesが「新規の非準拠を防ぐ」役割に留まる(§3-2)のに対し、Resource ExplorerとResource Groupsを組み合わせることで初めて「既存の非準拠を継続的に発見し是正する」運用ループが完成します。

6-2. StackSets による組織展開との棲み分け（クロスリンク委譲）

本Vol3の3本柱(Tag Policies/Resource Explorer/Resource Groups)は、いずれも「作成済みのリソースをどう統制・発見・分類するか」を扱う仕組みであり、「新規アカウントやリソースをどう一括展開するか」という展開側の仕組みとは役割が異なります。後者の代表格であるAWS CloudFormation StackSetsの一括展開メカニクス——ProvisioningPreferencesによる同時実行数制御・失敗許容率・パイロット/本番の2段階ロールアウト——は、Service Catalog Vol2 §7で既に本番運用DEEPとして詳説済みのため、本Vol3では再解説しません。

本Vol3でStackSetsに言及する場合も、次の3つの「org-native視点」に限定します。第一に、Organizationsの信頼アクセスを前提としたStackSetsの組織単位デプロイです。第二に、新規アカウントが対象OUに参加した際の自動デプロイ(自動追随)です。第三に、委任管理者へのStackSets操作権限の委譲です。これらはいずれも§2で解説した信頼アクセス・委任管理と同じOrganizations基盤の上に成り立つため、Tag Policies/Resource Explorerの委任管理設計と地続きの話題として触れる価値がありますが、一括展開そのもののメカニクス(ProvisioningPreferences等)は範囲外とし、詳細はService Catalog Vol2に委譲します。

Service Catalog Vol2（StackSets大規模展開制御・AppRegistry移行）を読む

7. まとめ

本Vol3では、Organizations Tag Policies・Resource Explorer・Resource Groupsの3サービスを、「多アカウントのタグ統制・リソース可視化」という単一のテーマの下で本番運用DEEPとして解説しました。

Tag Policies(§3)では、tag_key/tag_value/enforced_forによるOU階層の継承モデルを軸に、準拠レポート専用モードとenforcementモードを段階的に導入する安全な展開手順、および例外設計のパターンを扱いました。既存コーパスに専用節を持たない純空白領域として、全社共通のタグ許可値をどう強制し、どう例外を許容するかという設計判断を詳解しました。

Resource Explorer(§4)では、ローカルインデックスとアグリゲーターインデックスの違いを起点に、委任管理者による組織横断検索の有効化、RAMによるビュー共有とそのガバナンス(RAM共有とIAM許可の2層構造)を扱いました。Service Catalog Vol2で軽く触れられた「AppRegistry移行代替」というレンズとは異なる、委任管理アーキテクチャという本番運用DEEPのレンズで掘り下げました。

Resource Groups(§5)では、タグベース(動的メンバーシップ)とスタックベース(静的メンバーシップ)という2つのグループタイプの使い分け、および未タグリソースの2ステップ検出とグループ単位の一括タグ操作を扱いました。

そして§6では、これら3サービスを「統制→発見→突合→分類→是正→再検証」という単一の運用ループとして統合する設計を示しました。Tag Policiesが新規の非準拠を防ぎ、Resource Explorerが組織全体を横断して見つけ、Resource Groupsがタグを軸に束ねて一括操作する——この3層は個別に導入しても価値を持ちますが、日次のループとして自動化して初めて「タグ統制と可視化が本番運用に定着した」状態に到達します。

Management & Governance本番運用シリーズは、本Vol3をもって「誰が何を作れるか」(Vol1・アカウント統制)、「作られた後をどう監視するか」(Vol2・構成監視)、「組織全体のリソースをどう見つけ・分類し・タグで統制するか」(Vol3・タグ統制と可視化)という3層構造が揃いました。この3層を積み上げることで、マルチアカウント環境のガバナンスは「作る前の統制」「作った後の監視」「作られたものの発見と分類」という3つの時間軸をカバーした状態になります。

次の一手としては、本Vol3で確立したタグ統制・可視化の基盤の上に、Cost Explorer/Budgetsによるコスト可視化・最適化(本記事のスコープ外)を接続する、あるいはVol2で構築したConfig Conformance Packsの評価結果とTag Policiesの準拠レポートを1つの運用ダッシュボードに束ねる、といった発展が考えられます。いずれも本Vol3の3本柱が「発見と分類の基盤」として機能することが前提になるため、まずは§3〜§6の運用ループを自組織で確立することを推奨します。

本シリーズはAWSのサービスアップデートに合わせて内容を継続的に更新します。最新の公式ドキュメントも併せてご参照ください。