「SG が開けられていた」「S3 が公開になっていた」を、事故が起きてから知った。CloudTrail を見れば誰が API を呼んだかは分かるのに、「その時点で設定がどうなっていたか」「いまも守られているか」は追いにくい。そこで出てくるのが AWS Config ですが、CloudTrail との違いやルールの動く契機が曖昧なまま、名前だけ知っている人も多いはずです。この記事では、記録・評価・修復・集約の 4 つの部品に分けて、Config を説明できる状態を目指します。
この記事の結論
- Config はリソースの「設定の状態」とその変遷を記録し、CloudTrail は「誰がどの API を呼んだか」を記録します。答える問いが違います。
- レコーダーが構成項目（CI）を作り、S3 や履歴に残します。記録するリソースの種類は選べます。
- ルールは「あるべき設定」を表し、マネージドルールとカスタムルールがあります。評価の結果が準拠か非準拠です。
- 非準拠は通知だけでなく、修復アクションと Systems Manager Automation で自動で戻せます。
- 適合パックはルールと修復のまとまり、アグリゲーターは複数アカウント・リージョンを 1 か所で見る部品です。
- 記録は構成項目の数で費用が変わるので、記録範囲とルールの対象を絞る判断が要ります。
AWS Config とは何か｜「設定の状態」を記録するサービス（CloudTrail との違い）
AWS Config は、AWS リソースの設定を記録し、その設定が決めた基準に合っているかを評価するサービスです。公式ドキュメントでは、記録・ルールによる評価・適合パック・修復・アグリゲーターといった機能がひとまとまりで説明されています。ここで大事なのは、Config が見ているのは「操作」ではなく「状態」だという点です。
たとえば、セキュリティグループの入口を全世界に開く変更が入ったとします。
- 開けた人は誰か、どの API で、いつ呼んだか → CloudTrail の領域
- 開いたあとのセキュリティグループは、どんな設定だったか。その前はどうだったか → Config の領域
ログ全体の地図は AWS のログの仕組み で扱いました。ここでは、その中の「設備台帳」にあたる Config を掘り下げます。
TWO QUESTIONS操作と状態は別の帳簿
CloudTrail は誰がしたか、Config はどうなっているかに答える
CloudTrail
操作の記録
- 誰が
- どの API を
- いつ呼んだか
AWS Config
状態の記録
- いまの設定は何か
- いつ・どう変わったか
- 基準に合っているか
| 見るもの | CloudTrail | AWS Config |
|---|---|---|
| 記録する対象 | API 呼び出し（操作） | リソースの設定の状態と変遷 |
| 答える問い | 誰が・いつ・何をしたか | いまの設定は何か、いつ変わったか、基準に合っているか |
| 向いている場面 | 操作者の特定、証跡の保全 | 設定の履歴確認、継続的な準拠評価 |
どちらかが他方の代わりになるわけではありません。設定が変わった時点を Config で特定し、その変更をした人を CloudTrail で探す、という組み合わせで使います。
CHECK 1ここまでの確認
ある時点でネットワークの入口が全世界に開いたと分かりました。「その時点の設定内容」と「開けた人」を、それぞれ調べるサービスの組み合わせはどれ?
答えと解説
答え: 2. 設定内容は AWS Config、開けた人は CloudTrail
Config は設定の状態と変遷を、CloudTrail は誰がどの API を呼んだかを記録します。問いが違うので帳簿も別です。第 1 章を読み直してください。
Config はどう記録するのか｜レコーダー・構成項目・履歴とスナップショット
記録の中心は構成レコーダーです。レコーダーは、対象のリソースに変化があるたびに構成項目（CI: Configuration Item）を作ります。構成項目は、あるリソースのある時点の設定内容、他のリソースとの関係、メタデータをまとめた 1 件の記録です。
記録の置き場所
Config を使い始めるには、記録の配信先として S3 バケットが要ります。通知を受けたいなら SNS トピックも用意し、Config がそれらへ書き込むための IAM ロールも渡します。つまり Config は単独で完結せず、S3・SNS・IAM と組み合わさって動きます。
- 設定履歴: リソースごとの構成項目の時系列。「いつ、何が変わったか」を後から遡るときに使う
- 設定スナップショット: ある時点のリソース設定全体をまとめて S3 に書き出したもの
何を記録するかは選べる
レコーダーが記録するリソースの種類は選べます。すべての対応リソースを記録することも、必要な種類だけに絞ることもできます。構成項目の数は後で述べるように費用に直結するので、「何を見張りたいか」から決めるのが筋です。
履歴があると、「準拠から外れた時点」を後から特定できます。評価結果は「いま非準拠」と教えてくれますが、「いつから」を知りたいときに頼るのが設定履歴です。
ルールはどう評価するのか｜マネージドルールとカスタムルール、評価の契機
記録だけでは「守られているか」は分かりません。そこで使うのが Config ルールです。ルールは「あるべき設定」を表し、記録されたリソースの設定をそれに照らして、準拠か非準拠かを判定します。
ルールの種類
公式ドキュメントでは、ルールを次のように整理しています。
| 種類 | 中身 | 使いどころ |
|---|---|---|
| マネージドルール | AWS があらかじめ用意したルール | よくある基準（入口の開放、暗号化など）をすぐ使いたいとき |
| カスタムルール | 自分で判定の中身を書くルール（Lambda などで実装） | 組織独自の基準を評価したいとき |
| サービスリンクルール | 他の AWS サービスが作るルール | そのサービスの機能として使うとき |
| 組織ルール | 組織全体に展開するルール | 全アカウントに同じ基準を当てたいとき |
まず使うべきはマネージドルールです。個別のルールの一覧は公式のドキュメントに任せ、基準に合うものがなければカスタムを検討する、という順番になります。
いつ評価されるのか
ルールには評価の契機があります。
- 構成変更を契機に動くもの: 対象リソースの設定が変わったときに評価する
- 周期で動くもの: 一定の間隔で評価する
「変更のたびに見る」と「決まった間隔で見る」の 2 系統がある、と覚えておけば十分です。入口の開放のような、変わった瞬間に知りたい基準は変更契機が向きます。
カスタムの Lambda ルールでは、評価の対象にするリソースを絞り込めます。評価の回数も費用に効くので、全部を対象にせず、基準の意味がある範囲に絞ります。
RECORD TO REMEDIATE記録から修復まで
変更が記録され、評価され、非準拠なら直る
-
リソース変更
設定が変わる
-
レコーダー
構成項目を作る
-
S3・履歴
時系列で残る
-
ルール評価
準拠か非準拠か
-
通知・修復
Automation が戻す
CHECK 2ここまでの確認
Config ルールが評価を始める契機として、正しい組み合わせはどれ?
答えと解説
答え: 1. 構成が変わったときと、一定の周期のとき
ルールには、リソースの構成変更を契機に動くものと、周期で動くものがあります。第 3 章を読み直してください。
非準拠をどう直すのか｜通知・修復アクション・Systems Manager Automation
非準拠と判定されたあとの動きは 2 段階で考えます。
- 知らせる: 評価結果の変化を通知する（SNS などへ）
- 直す: 修復アクションで、リソースを元の設定へ戻す
修復アクションは、ルールに紐づけて設定します。実際に設定を直す実行役は Systems Manager Automation のドキュメント（手順書）です。S3 のパブリックアクセスのブロックが外れたら、Automation が有効に戻す、といった形です。
ここで押さえたいのは 検知と実行が別の部品 だということです。
- Config ルール: 合っているかを判定する（直さない）
- 修復アクション: 非準拠になったときに何を呼ぶかを決める
- Systems Manager Automation: 実際に設定を書き換える
自動修復を入れるときの注意
自動で直せるのは便利ですが、人の意図した変更まで元に戻してしまう可能性もあります。検証用の環境で意図して開けているものを、修復が閉じてしまうこともあります。最初は通知だけで運用して非準拠の出方を把握し、そのあとで修復を入れる、という順番が安全です。また、修復の実行にも権限が要るので、Automation に渡す IAM ロールは必要な操作だけに絞ります。
CHECK 3ここまでの確認
非準拠と判定されたリソースを、人手を介さずに元の設定へ戻す部品はどれ?
答えと解説
答え: 2. 修復アクションと、その実行役の Systems Manager Automation
ルールは「合っているか」を判定するだけで、直すのは修復アクションが呼ぶ Automation です。検知と実行は別の部品です。第 4 章を読み直してください。
複数アカウントでどう集めるのか｜アグリゲーターと適合パック
アカウントやリージョンが増えると、Config はそれぞれの場所に別々に存在することになります。全部を見に行くのは現実的ではないので、集める部品と配る部品が用意されています。
- アグリゲーター: 複数のアカウント・リージョンの Config のデータ（ルールの準拠状況やリソース設定）を 1 つのアカウントに集めて読む。組織を対象にすれば、メンバーアカウントを 1 つずつ承認しなくても集められる。集めたデータは読む用途で、集約先から元の設定を書き換えるものではない
- 適合パック: Config ルールと修復アクションを 1 つのまとまりとして定義したもの。組織の適合パックとして展開すれば、全アカウントに同じ基準のルール群を配れる
つまり、配るのが適合パック、集めるのがアグリゲーター です。向きが逆の部品なので、混同しないようにします。
SPREAD AND GATHER配る部品と集める部品
配るのは適合パック、集めるのはアグリゲーター
-
配る
適合パック — ルールと修復を 1 つのまとまりにして各アカウントへ
組織の適合パックなら全アカウント
-
集める
アグリゲーター — 各アカウント・リージョンの準拠状況を 1 か所へ
集約先は読む用途
-
前提
対象のアカウントとリージョンで Config を有効にしておく
空白のリージョンは見えない
組織単位の運用は マルチアカウント設計 で扱う Organizations が前提になります。そちらで、アカウントをどう分けるかを決めたうえで、Config をどう配るかを考えます。なお、Firewall Manager のような他のサービスが、対象のアカウントとリージョンで Config が有効になっていることを前提にする場合もあります。ガバナンス系の機能の土台として、Config を先に有効にしておく意味はここにもあります。
CHECK 4ここまでの確認
組織内の全アカウント・全リージョンの準拠状況を、1 つのアカウントでまとめて見るために使う部品はどれ?
答えと解説
答え: 1. アグリゲーター
複数のアカウントとリージョンのデータを集めて読む部品がアグリゲーターです。適合パックはルールを配る側の部品です。第 5 章を読み直してください。
運用で気をつけること｜記録範囲・料金・ルールの対象の絞り方
Config は、記録する構成項目の数とルールの評価の回数などで費用が変わります。単価や無料枠の数値はここでは書きません。必ず公式の料金ページで確認してください。
費用と効果のバランスを取るための考え方は 3 つです。
- 記録するリソースの種類を、見張る目的から逆算して決める。すべてを記録するか、種類を絞るかは、目的が決める
- ルールの対象を絞る。基準が意味を持つリソースだけを評価する
- 評価の契機を目的に合わせる。変更の瞬間が大事な基準は変更契機、棚卸しのような基準は周期にする
また、アカウントとリージョンごとに有効化が要るので、「使っていないリージョンにも置くか」は運用ポリシーとして決めておきます。リージョンを後から有効にし忘れると、そこだけ見張りが空白になります。
他のサービスとの役割分担（CloudTrail・Security Hub・Access Analyzer）
最後に、並べて名前が出るサービスとの違いを整理します。
| サービス | 一言で言うと |
|---|---|
| CloudTrail | 誰がどの API を呼んだかの操作記録 |
| AWS Config | 設定の状態の記録と、基準への準拠評価・修復 |
| Security Hub | 各種の検出結果を 1 か所に集めて見る場所 |
| IAM Access Analyzer | 外部へのアクセスや未使用のアクセスを分析する部品 |
Config を設備台帳、CloudTrail を入館記録にたとえると、台帳は「いまの設備が決まりに合っているか」を見るもの、入館記録は「誰がいつ入ったか」を見るものです。たとえ話はここまでで、正確な言葉に戻すと、前者は設定の状態と準拠、後者は API 呼び出しの記録です。
Cloudory 執筆者（AWS 認定 全冠）
Config は「入れて終わり」になりやすい部品です。まず記録の範囲を決め、次にマネージドルールを少数だけ当て、通知で出方を見る。そのあとに修復と複数アカウントへの展開へ進む、という順に積むと迷いにくくなります。
参照ソース
- AWS Config とは（AWS Config 開発者ガイド） — 記録・ルール・適合パック・修復・アグリゲーターの機能の概要と、S3・SNS・IAM ロールが要ることの根拠
- AWS Config ルールによるリソースの評価（AWS Config 開発者ガイド） — ルールの種類、構成項目と費用の注意、カスタムルールの対象の絞り込みの根拠
