AWS Configによるリソース構成の記録・ルール評価・修復

AWS Configが扱うのは「リソースの状態と変化」

AWS Configは、AWSアカウント内のリソースが現在どのような設定か、リソースどうしがどのように関連しているか、その状態が時間とともにどう変わったかを把握するための構成管理サービスです。EC2インスタンス、EBSボリューム、セキュリティグループ、VPCなどの構成情報を記録し、後から履歴を調べたり、ルールに基づいて設定を評価したりできます。

たとえば、監査ログを保管するS3バケットでバージョニングが有効かを継続確認したいとします。Configは対象リソースの設定変更を記録し、ルールが条件に照らして準拠・非準拠を判定します。ルール違反の通知や修復処理を別サービスへつなげれば、検知から対応までを自動化できます。

CloudTrailとの役割の違い

CloudTrailが中心に記録するのは、ユーザーやAWSサービスによるAPI操作の証跡です。「誰が、いつ、どのAPI操作を実行したか」を調べるときに使います。一方、Configが中心に記録するのは、リソース自体の構成とその履歴です。「特定時点でリソースがどの設定だったか」「設定がどう変わったか」を調べる用途に向きます。

両者は競合するものではありません。Configで問題のある設定変更と対象リソースを特定し、同じ時刻のCloudTrailイベントを確認すれば、変更後の状態と操作主体を結び付けられます。

確認したいこと	主に使うサービス	記録・確認する情報
APIを呼び出した主体、時刻、操作内容	AWS CloudTrail	APIイベントと操作証跡
リソースの現在の設定と過去の構成	AWS Config	リソース構成、関係、構成変更
ルールへの準拠状況	AWS Config Rules	リソース単位の準拠評価

記録を始めるときの構成要素

Configを有効にすると、対象とするリソースタイプを選び、構成を記録するレコーダーと、記録データの配信先を設定します。一般的な構成では、構成履歴やスナップショットの保存先としてS3バケットを指定し、必要に応じて通知先のSNSトピックも設定します。Configがこれらの処理を行えるよう、必要なIAM権限も準備します。

• 構成レコーダー（configuration recorder）: 指定したリソースタイプの構成変更を検出し、記録する。
• 構成アイテム（configuration item、CI）: ある時点でのリソースの構成を表す記録単位。リソースの属性や関連情報などを含む。
• 構成履歴（configuration history）: リソースの構成アイテムを時系列にたどり、いつどのような設定だったかを調べるための履歴。
• 構成スナップショット（configuration snapshot）: 対象範囲におけるリソース構成を特定時点の状態としてまとめたもの。要求に応じた取得や定期配信に使用する。
• 配信チャネル（delivery channel）: スナップショットと構成履歴の配信先となるS3バケットや、通知に利用するSNSトピックなどを設定する。

履歴を使うと、障害が発生する前後で設定を比較し、最後に正常だった構成を見つける手掛かりになります。また、リソース間の関係を確認すれば、ある設定変更が依存先に与える影響を調査できます。

Configルールで望ましい状態を定義する

Configルールは、対象リソースの構成が組織のポリシーや技術要件に合っているかを判定する評価条件です。ルールは準拠している状態を定義し、評価結果としてリソースを準拠または非準拠として扱います。違反を見つけた後の通知や修復は、ルール評価に続く別のアクションとして構成します。

ルールには大きく二つの種類があります。

• AWS管理ルール（AWS managed rules）: AWSがあらかじめ用意している評価ロジックを使う。よくあるセキュリティや運用要件を、独自コードを書かずに適用しやすい。たとえばs3-bucket-versioning-enabledルールは、S3バケットでバージョニングが有効かを評価する。
• カスタムルール（custom rules）: 組織固有の条件を評価するため、利用者がロジックを定義する。AWS Lambdaを使うカスタムルールなどがある。対象リソースタイプを適切にスコープし、不要な関数呼び出しや評価を避ける設計が重要となる。

AWS管理ルールは多数提供され、要件に応じて継続的に追加・更新されます。ルール数は固定値として覚えるより、既成ルールを検索し、要件に合うものがなければカスタムルールを検討すると整理してください。マネージドルールの具体的な入力パラメーターや対応リソースはルールごとに異なります。

評価の契機とリソース記録頻度を区別する

Configルールの評価タイミングには、代表的に次の方式があります。

1. 構成変更時の評価（change-triggered）: 対象リソースに構成変更が発生したときに評価する。設定ミスを変更の発生に結び付けて検知したい場合に向く。
2. 定期評価（periodic）: 指定した周期で対象リソースを評価する。変更イベントだけでは拾いにくい状態を定期的に再確認したい場合に使う。利用可能な周期はルールや設定に従い、常に日次とは限らない。

これとは別に、リソース構成の記録頻度 にも連続記録と日次記録があります。連続記録は対応する構成変更を変更の都度記録し、日次記録では対象タイプの記録を1日単位で行います。日次記録を選んだ場合、変更が起きた瞬間の構成履歴が連続記録と同じ粒度で残るわけではありません。

したがって「ルールをいつ評価するか」と「構成変更をどの頻度で記録するか」は別々に設計します。記録方式が日次でも、ルール側に定期評価を設定するかどうかは別の判断です。検知の即時性、必要な履歴の細かさ、評価対象の範囲、料金要件を照らして選択してください。

Configでは記録されるリソース構成アイテム数やルール評価などが料金に関係します。変更のたびに記録・評価する設計は、日次の記録や頻度を抑えた評価と比べ、処理量とコストが増える可能性があります。すべてのリソースタイプを無条件に対象とするのではなく、監査・セキュリティ要件を満たす範囲を記録対象に設定し、評価回数も見積もります。正確な単価と課金条件は利用リージョン・機能の現行料金表で確認します。

複数アカウント・リージョンを集約する

複数のAWSアカウントやリージョンを運用する場合、各環境で記録・評価された結果を一元的に把握する仕組みとして 構成アグリゲーター（configuration aggregator） を利用できます。対象のアカウントやリージョン、またはAWS Organizations内でConfigを有効化しているアカウントのデータを、一つの集約アカウントとリージョンから横断的に確認できます。

集約対象には、リソースインベントリ、構成情報、Configルールの準拠結果などが含まれます。組織全体の準拠状況を俯瞰したり、異なる環境にまたがるリソース構成や依存関係を追跡したりする際に役立ちます。Organizationsとの連携により、組織内アカウントを集約対象として管理できます。

重要な制約は、アグリゲーターがソースアカウントやリージョンのデータを集約する読み取り専用のビューであることです。アグリゲーターを作成しただけでは、ソース側にルールを作成したり、修復処理を実行したりすることはできません。ルールや修復アクションの配布には、適合パックなど、別の展開手段を使います。

非準拠の検知から通知・自動修復へ

ルールの評価結果やリソース構成の変化を、通知・ワークフローへ接続できます。たとえば、準拠状態の変化をEventBridgeで扱い、条件に合うイベントをSNS通知、Lambda処理、その他のターゲットに連携できます。また、Configの検出結果をAWS Security Hubへ取り込み、他のセキュリティ所見と一緒に確認する構成も可能です。

自動対応が必要な場合、Configルールに Systems Manager Automationのドキュメント を修復アクションとして関連付けます。非準拠の評価をきっかけに、対象リソースを引数としてAutomationを起動し、定められた手順を実行します。AWS提供のAutomationドキュメントを利用する方法と、要件に合わせたカスタムドキュメントを関連付ける方法があります。

すべての違反を無条件で自動修復する必要はありません。修復アクションは次のように運用要件に合わせます。

• 自動修復: 影響範囲が限定され、処置が安全かつ繰り返し可能な場合に、評価後の実行を自動化する。
• 手動での修復開始: 変更前の確認が必要な場合、担当者が内容を確認してからAutomationを実行する。
• 承認を伴うワークフロー: 重要なリソースの変更などでは、実行前に承認ステップを置く。Systems Manager Automationの手順に承認処理を組み込むこともできる。

たとえば、監査ログ用S3バケットでバージョニングが停止されていることを検知したら担当者に通知し、影響を確認してからカスタムAutomationドキュメントでバージョニングを有効化する流れを設計できます。重要なのは、修復手順に必要なIAM権限、対象リソースの特定、実行失敗時の扱い、再評価による修復後の確認まで含めて設計することです。

EventBridgeとSecurity Hubはそれぞれイベントのルーティングとセキュリティ所見の集約に用います。イベントを受けて独自処理を実装する場合はEventBridgeのルールからLambdaなどを起動できますが、Configルールに対する標準の修復アクションはSystems Manager Automationです。イベント連携とConfigの修復アクションは同じ仕組みとして混同しないでください。

適合パックでルールと修復をまとめる

**適合パック（conformance pack）**は、Configルールと関連する修復アクションを一つの展開単位にまとめたものです。YAMLテンプレートにルール群と修復定義を記述し、単一アカウント・リージョンへ展開したり、Organizations内へ組織単位で配布したりできます。

個々のルールを一つずつ作成・維持する代わりに、適合パックとしてポリシー群を管理することで、アカウント間で共通の統制を適用しやすくなります。コンプライアンス標準や社内ガバナンスポリシーに沿ったテンプレートを土台にし、自組織の対象範囲や例外に合わせて調整できます。AWSはサンプルテンプレートを提供しており、CIS AWS Foundations BenchmarkやNIST Cybersecurity Frameworkなどを意識したテンプレートも公開されています。

適合パックは、集約アグリゲーターと役割が異なります。適合パックはルール・修復の 定義と展開 をまとめ、アグリゲーターはアカウント・リージョンの 記録データと評価結果の集約表示 を担います。組織全体でポリシーを適用し、結果を中央で監視するには、両方を目的に応じて組み合わせます。

高度なクエリで構成情報を検索する

AWS Configの高度なクエリ（Advanced Queries）では、記録されたAWSリソースの現在の構成状態を、SQLに似たクエリで検索できます。リソースタイプや属性で絞り込み、アカウント・リージョンに散在する構成情報の棚卸しや監査を効率化できます。あらかじめ用意されたクエリ例を使うほか、リソースの構成スキーマに合わせて独自クエリを作成できます。

アグリゲーターのデータを対象にすれば、許可された複数アカウント・リージョンをまたいだ検索にも利用できます。クエリ結果は記録済みの構成情報を調べるものであり、CloudTrailのAPI呼び出し履歴を検索するものではありません。また、Configが記録していないリソースタイプや属性を、クエリだけで新たに取得できるわけではありません。

DVA試験での使い分け

設問の要件から、記録・評価・通知・修復のどの段階を求めているかを読み取ります。

要件・キーワード	選択肢の中心	判断の要点
リソースの設定変更履歴や過去の状態を確認する	AWS Config	構成アイテムと履歴を使う。API操作主体の証跡はCloudTrailで調べる。
設定が組織ルールに適合しているか判定する	AWS Configルール	標準要件はAWS管理ルール、独自要件はカスタムルールを検討する。
非準拠リソースをルール評価から自動修復する	Systems Manager Automation	ConfigルールにAutomationドキュメントを関連付ける。承認や手動実行も選択可能。
複数アカウント・リージョンの状態を中央で確認する	AWS Configアグリゲーター	読み取り専用の集約。ソース側への変更や修復は実行しない。
複数ルール・修復定義をポリシー群として展開する	AWS Config適合パック	YAMLテンプレートを単一の展開単位として扱う。Organizations展開にも対応。
構成イベントを条件に通知・独自処理を起動する	EventBridgeなどとの連携	EventBridgeでイベントを振り分け、SNSやLambda等へ接続する。
リソース構成を属性条件で棚卸しする	AWS Config高度なクエリ	Configに記録された構成データを検索する。CloudTrailのAPI履歴とは異なる。

料金や機能の詳細、利用できるルール・対応リソースは変更されるため、実環境へ適用する際はAWS Configの最新仕様と料金表を確認します。