AWS Config完全ガイド：構成変更の追跡と継続的コンプライアンスを仕組み化する（GCP Cloud Asset Inventory／Azure Policy＋Resource Graph比較）

まず結論：AWS Configは「変更の証跡」と「準拠の継続」を同時に扱うための土台です

AWS Configは、AWSリソースの構成（設定）を記録し、変更を追跡し、ルールでコンプライアンス評価まで行えるガバナンス系サービスです。運用の現場で本当に効くのは、障害や監査のときに「いつ、どの設定が、どう変わったか」を説明できること、そして「あるべき状態からの逸脱（ドリフト）を見つけて戻す」までを手順ではなく仕組みにできることです。:contentReference[oaicite:0]{index=0}

同じ悩みはGCPやAzureにもあります。GCPのCloud Asset Inventoryは、リソースの変化を追跡して監査証跡やドリフト管理に使えること、さらにPub/Subで変更通知を受けられることが明記されています。:contentReference[oaicite:1]{index=1}
Azureは、Azure Policyで組織標準の強制・評価・修復（リメディエーション）を大規模に行えることが示され、Resource Graphでクラウド資産の探索やインベントリ管理ができる、と整理されています。:contentReference[oaicite:2]{index=2}

この記事は、AWS Configを中心に「どこまで記録する？」「どう評価する？」「マルチアカウントはどう集約する？」を、現場目線で一本の設計ストーリーとしてまとめます。

この記事が役に立つ方（具体的に）

まず、SRE／運用担当の方です。設定変更が絡む障害でつらいのは「犯人探し」ではなく「事実の確定」です。AWS Configがあると、構成履歴やリソースの関係（依存）を手掛かりに、変更の影響範囲を早く切り分けやすくなります。:contentReference[oaicite:3]{index=3}

次に、セキュリティ／情シスの方です。監査や顧客要件では「ルールはある」と「継続的に守れている」は別物です。AWS Configはルール評価と、ルールと修復をまとめた“コンフォーマンスパック”で、継続的な準拠確認を配布しやすい構造になっています。:contentReference[oaicite:4]{index=4}

そして、マルチアカウント運用のクラウド管理者の方です。AWS Configには、複数アカウント・複数リージョン・Organizations配下をまとめて可視化するためのアグリゲータ（Aggregator）が用意されています。:contentReference[oaicite:5]{index=5}
「各アカウントでバラバラに見て疲れる」状態を、中央集約ビューに寄せたい方に向きます。

1. AWS Configとは：記録（証跡）と評価（準拠）を同じ画面と言語で扱うサービス

AWS Configの本質は、次の2つを同時に扱える点にあります。

• 設定の変化を継続的に記録し、履歴として残す（証跡）
• ルールで評価し、非準拠を検知できる（継続的コンプライアンス）

公式の説明では、AWS Configがリソース構成の変化を追跡し、指定したS3バケットへ更新された構成情報を定期的に配信すること、さらに構成履歴ファイルが一定間隔（例：6時間ごと）で送られること、構成スナップショット（全体像）を配信できることが明記されています。:contentReference[oaicite:6]{index=6}

ここで大事なのは、Configが「監視」ではなく「記録と評価」寄りのサービスだということです。メトリクス監視のように秒単位で異常を追うというより、設定という“状態”の変化と、その状態がルールに合っているか、を扱います。だから、障害復旧後の再発防止や、監査対応、標準化の継続にとても強いです。

2. まず決めるべき設計：何を記録するか（記録範囲）で運用が9割決まります

AWS Configを入れるとき、多くのチームが最初に迷うのは「全部記録すべき？」です。結論としては、全部を無条件に記録するよりも、目的を先に決めて、記録範囲を段階導入する方が失敗しにくいです。

公式説明では、Configはリソースタイプごとに構成履歴ファイルを作り、変更があったリソースの詳細を含める、とされています。つまり、記録対象が広いほど、出力されるデータも増え、保管・検索・保持の運用が重くなりがちです。:contentReference[oaicite:7]{index=7}

さらに日本語ドキュメントでは、過去のコンプライアンス結果を保存するための AWS::Config::ResourceCompliance 記録は“現在のコンプライアンス評価に必須ではない”こと、必要なければ除外できることが明記されています。これはとても実務的で、要件に応じて「履歴の深さ」を調整できる、ということです。:contentReference[oaicite:8]{index=8}

おすすめの段階導入（現場で揉めにくい順）は次の通りです。

1. まず“変更が痛い領域”（ネットワーク、権限、公開設定など）を中心に記録・評価
2. 次に“コスト事故が起きやすい領域”（不要リソース、無タグ、放置）を足す
3. 最後に“監査で厳密に必要な領域”を追加（保持期間や証跡の見せ方もセットで）

この順番だと、導入効果を実感しやすく、運用負荷の増加もコントロールできます。

3. ルールとコンフォーマンスパック：ルールを「個別」から「パッケージ運用」へ

AWS Configの評価は、Configルール（managed/custom）で行い、さらに複数ルールと修復アクションをまとめて配布できるのがコンフォーマンスパックです。公式ドキュメントでは、コンフォーマンスパックが「Configルールと修復アクションのコレクション」であり、アカウントとリージョン、またはOrganizations全体にデプロイできる、と説明されています。:contentReference[oaicite:9]{index=9}

運用上のコツは、ルールを“場当たり”で増やさないことです。個別ルールを無計画に追加すると、

• 何のためのルールか分からない
• 例外の扱いが属人化する
• 非準拠が増えすぎて誰も見なくなる
  という状態になりがちです。

コンフォーマンスパックは「セキュリティ」「運用」「コスト最適化」などの目的で束ねやすいことが、サンプルテンプレートの説明でも示されています。:contentReference[oaicite:10]{index=10}
つまり、ルール群を“目的別のセット”として運用できるので、チーム内の合意形成が楽になります。

サンプル（考え方の例）

• セキュリティ基礎パック：公開設定や暗号化、ログ有効化など“落としてはいけない最低限”
• 運用標準パック：タグ付け、バックアップ前提、監視前提など“運用の前提”
• コスト衛生パック：未使用・放置・過剰の早期発見

この「パック単位」の考え方は、GCPやAzureの世界でも、ポリシーセットや組織標準という形で相性が良いです（後半で比較します）。

4. マルチアカウント集約：Aggregatorで“見る場所”を1つにする

AWSはマルチアカウント運用が前提になりやすいので、Configも中央で集約して見たい場面が多いです。公式ドキュメントでは、アグリゲータが複数アカウント・複数リージョン、またはOrganizations配下（Config有効化済み）の全アカウントから、Configの構成データとコンプライアンスデータを収集できる、と説明されています。:contentReference[oaicite:11]{index=11}

ここが整うと、運用のメリットが一気に出ます。

• どのアカウントが非準拠かを横串で見られる
• 標準が守れていないチームを“責める”のではなく、“戻す仕組み”として運用できる
• 監査で「組織として継続評価している」を説明しやすい

つまり、Configの価値は単体アカウントより、マルチアカウントで標準化を回すほど大きくなります。

5. 変更の追跡：Configが強いのは「いつから変だったか」を説明できること

AWS Configの運用でいちばん“救われる”瞬間は、障害対応や調査で「いつからこの設定だった？」と聞かれたときです。Configは構成履歴ファイルとスナップショットをS3へ配信し、履歴として残せることが明記されています。:contentReference[oaicite:12]{index=12}

また、コンフォーマンスパックのコンプライアンス状態変化をタイムラインとして保存・閲覧できることも説明されています。これは、単に「今は非準拠」ではなく「いつ非準拠になったか」を追えるという意味で、運用の証跡としてとても価値があります。:contentReference[oaicite:13]{index=13}

ここでの設計ポイントは、履歴を“持つかどうか”だけでなく、

• どれくらいの期間を保持するか
• 誰がどの頻度で見るか
• 例外（正当な逸脱）をどう管理するか
  まで含めることです。

「ログはあるけれど誰も見ない」は、実質的に無いのと同じになりやすいので、週次・月次で見る最低限の運用リズム（例：非準拠トップ10の棚卸し）を作るのがおすすめです。

6. GCPとの比較：Cloud Asset Inventoryは“資産の棚卸し＋変更通知”が中心に据わります

GCPのCloud Asset Inventoryは、メタデータでのフィルタ、変更追跡による監査証跡、コンプライアンスドリフト管理、セキュリティ/コスト監査などの用途が整理されています。:contentReference[oaicite:14]{index=14}
また、資産の履歴については「最大35日分の作成・更新・削除の履歴を取得できる」と明記されています。:contentReference[oaicite:15]{index=15}

さらに、Pub/Subを使って“変更をリアルタイム通知”として受け取れる（フィードを作って購読する）ことも公式に説明されています。:contentReference[oaicite:16]{index=16}

このため、GCP側の標準的な組み立ては、

• Asset Inventoryで棚卸し（現状）と履歴（直近の変化）を掴む
• 変更通知（Pub/Sub）を起点に、検知→自動対処（またはチケット化）を作る
  という流れになりやすいです。

AWS Configと比べたときの分かりやすい違いは、AWSが「ルール評価とコンフォーマンス」をConfigの中心に置きやすい一方、GCPは「資産の可視化と変更検知」をAsset Inventoryが強く担い、ポリシー強制や修復は別の仕組み（組織ポリシーや自動化）と組み合わせて作ることが多い点です。どちらが優れているというより、サービス分担の設計思想が少し違う、と捉えると理解が楽です。

7. Azureとの比較：Policyで“評価と修復”、Resource Graphで“横断探索”を担います

Azure Policyは、組織標準を強制し、コンプライアンスを大規模に評価できる仕組みとして説明され、コンプライアンスダッシュボードで集計ビューを提供し、既存リソースへの一括修復や新規リソースの自動修復にも触れられています。:contentReference[oaicite:17]{index=17}

さらに、非準拠リソースを修復する「リメディエーションタスク」について、deployIfNotExists や modify のポリシー割り当てに対して、指定したIDで修復操作を実行する、と明確に説明されています。:contentReference[oaicite:18]{index=18}

一方で、Resource Graphはクラウド資産のインベントリを探索し、より効果的に管理するためのサービスとして整理されています。:contentReference[oaicite:19]{index=19}
つまりAzureは、

• Policy：標準に合っているかの評価＋戻す仕組み
• Resource Graph：横断的な棚卸し・探索（クエリ）
  という役割分担が見えやすいです。

AWS Configに写像するなら、Configの「評価（ルール／コンフォーマンスパック）」はPolicy的で、Configの「インベントリ／履歴」はResource Graphや資産管理の領域に近い、という対応づけができます。マルチクラウドでガバナンスを揃えるなら、この対応関係で会話をすると、チーム間の認識が揃いやすいです。

8. 実務で効く導入テンプレ：最初の2週間で決めたいこと

AWS Configを“入れただけ”にしないために、最初に合意しておくと後が楽になる項目をまとめます。

1. 目的の優先順位
   監査なのか、障害調査なのか、標準化（継続的準拠）なのか。目的で記録範囲とルールが変わります。:contentReference[oaicite:20]{index=20}

2. 記録範囲（対象リソースタイプ）
   全部から始めるのか、重要領域から始めるのか。履歴の深さ（例：過去コンプライアンス履歴を残すか）もセットで決めます。:contentReference[oaicite:21]{index=21}

3. ルール運用の単位
   個別ルールで増やすのか、コンフォーマンスパックで目的別に束ねるのか。長期運用はパックの方が破綻しにくいです。:contentReference[oaicite:22]{index=22}

4. マルチアカウントの集約方針
   アグリゲータで中央に集約するか、どのアカウントが集約ビューの責任を持つか。:contentReference[oaicite:23]{index=23}

5. 保存と保持の方針
   ConfigはS3へ履歴を配信するため、保持期間やライフサイクル（アーカイブ）を運用ルールとして決めます。Config自体がS3のライフサイクルを変更しない点も明記されています。:contentReference[oaicite:24]{index=24}

6. “見る運用”を作る
   週次・月次で誰が何を見るか（非準拠の棚卸し、例外の見直し）を決めます。ここを決めないと、非準拠が積もって形骸化しやすいです。

まとめ：AWS Configは、標準化が進むほど“チームの安心”として効いてきます

AWS Configは、構成の変更を記録し、履歴として残し、ルールで準拠評価まで行えるガバナンスの中核サービスです。構成履歴やスナップショットをS3へ配信する仕組み、コンフォーマンスパックによるルールと修復の束ね方、そしてアグリゲータによるマルチアカウント集約といった部品が揃っているため、運用を「手順」から「仕組み」へ移しやすいです。:contentReference[oaicite:25]{index=25}

GCPのCloud Asset Inventoryは資産の棚卸しと変更追跡、Pub/Subによる変更通知が強く、AzureはPolicyで評価と修復、Resource Graphで横断探索という分担が見えやすいです。:contentReference[oaicite:26]{index=26}

最初の一歩としては、「重要領域から記録＋評価を始め、目的別にコンフォーマンスパックで束ね、アグリゲータで中央集約ビューを作る」この流れが、いちばん失敗しにくいです。焦らず小さく始めて、でも“見る運用”だけは最初に丁寧に。AWS Configは、その丁寧さがそのまま、障害対応と監査対応の強さになります。

参考リンク（公式・一次情報中心）

• AWS Config とは（公式） :contentReference[oaicite:27]{index=27}

• AWS Config の仕組み（履歴ファイル／スナップショット配信） :contentReference[oaicite:28]{index=28}

• AWS Config コンフォーマンスパック :contentReference[oaicite:29]{index=29}

• コンフォーマンスパック サンプルテンプレート :contentReference[oaicite:30]{index=30}

• AWS Config マルチアカウント／マルチリージョン集約（Aggregator） :contentReference[oaicite:31]{index=31}

• GCP Cloud Asset Inventory 概要 :contentReference[oaicite:32]{index=32}

• GCP 資産変更のリアルタイム通知（Pub/Subフィード） :contentReference[oaicite:33]{index=33}

• GCP 資産履歴の取得（最大35日） :contentReference[oaicite:34]{index=34}

• Azure Policy 概要（準拠評価と修復） :contentReference[oaicite:35]{index=35}

• Azure Policy 非準拠リソースの修復（Remediation） :contentReference[oaicite:36]{index=36}

• Azure Resource Graph ドキュメント（インベントリ探索） :contentReference[oaicite:37]{index=37}