はじめに
こんにちは、mori (@morimori) です。
前回の記事で、AWS の構成管理を一枚にまとめた「できることマップ」を紹介しました。
今回はその中身の話です。AWS Config と AWS CloudTrail で何ができるのかを、「やりたいこと」から整理してみます。
まずは役割分担
AWS Config と AWS CloudTrail は、記録するものが違います。
- AWS Config：何が・どう変わったか（リソースの設定を記録して、ルールで判定する）
- AWS CloudTrail：誰が・いつ操作したか（API 操作を記録する）
AWS Config だけでは誰がやったかが分かりませんし、AWS CloudTrail だけでは設定が結果的にどうなったかを追いにくいです。構成管理では、この2つをセットで使います。
AWS Config でできること
AWS Config の機能は、「記録する」と「判定する」に分けると整理しやすいです。マップでも上段を「記録する」、下段を「判定する」にしています。
記録する
| 機能 | できること |
|---|---|
| リソース記録 | 設定が変わるたびに記録する。変更前後の設定や、リソース同士の関係（例：セキュリティグループと EC2 インスタンス）も見られる |
| 構成スナップショット | ある時点の全リソースの設定を、JSON ファイルで Amazon S3 に出力する |
| 高度なクエリ | SQL に近い書き方で、今の構成を条件検索する |
| アグリゲータ | 複数アカウント・リージョンの情報を1か所に集める |
リソース記録は変更の履歴、スナップショットはある時点の全体の写真です。
高度なクエリでは、たとえばどこにも接続されていない EBS ボリュームを次のように探せます。
SELECT resourceId
WHERE resourceType = 'AWS::EC2::Volume'
AND configuration.state.value = 'available'
検索できるのは今の状態だけで、過去の状態や削除済みのリソースは探せません。
判定する
| 機能 | できること |
|---|---|
| Config ルール | 設定が基準どおりか（準拠／非準拠）を自動で判定する |
| 適合パック | ルールをまとめて、アカウントや組織全体に展開する |
| 自動修復 | 非準拠になったリソースを、AWS Systems Manager Automation で直す |
Config ルールには、AWS が用意しているマネージドルールと、自分で作るカスタムルールがあります。評価のタイミングは、設定が変わったときと、定期（1・3・6・12・24時間から選択）の2種類です。
AWS CloudTrail でできること
AWS CloudTrail で使うのは、主にイベント履歴と証跡の2つです。
| 機能 | できること | 注意点 |
|---|---|---|
| イベント履歴 | 直近90日の操作を、設定なしで画面から検索できる | 1アカウント・1リージョン単位。絞り込みは1項目と期間のみ |
| 証跡 | 操作記録を Amazon S3 に長期保管する | 検索には Amazon Athena などの仕組みが必要 |
ちょっと調べるだけならイベント履歴で十分です。90日より前を追いたい、全アカウントをまとめて見たいなら、組織全体の証跡を作っておきます。
やりたいこと27件
マップでは、構成管理のやりたいことを7分類・27件に整理しました。
| 分類 | やりたいこと |
|---|---|
| A 資産把握 | A-1 リソース一覧 / A-2 構成台帳の自動作成 / A-3 タグの付け漏れ検出 / A-4 不要リソースの発見 |
| B 変更の把握 | B-1 変更履歴の確認 / B-2 操作者の特定 / B-3 前日の変更レポート / B-4 人と AWS 自動の区分 / B-5 重要な変更の通知 |
| C セキュリティ | C-1 危険な設定の検知 / C-2 社内基準の一律適用 / C-3 違反設定の自動修復 / C-4 指摘事項の一覧 |
| D 監査対応 | D-1 時点の構成の提出 / D-2 無変更の証明 / D-3 違反期間の提示 / D-4 基準対応の説明 |
| E 変更管理 | E-1 申請との突合 / E-2 時間外変更の検知 / E-3 IaC とのずれ検出 |
| F 障害対応 | F-1 障害前後の変更確認 / F-2 影響範囲の確認 |
| G AI の活用 | G-1 ことばで質問 / G-2 対話で原因調査 / G-3 チャットから質問 / G-4 レポートの要約 / G-5 作成の手助け |
全部紹介すると長くなるので、ここからは分類ごとにいくつかピックアップします。
やりたいこと別に見てみる
A-2 月末時点の構成台帳を自動で作りたい
Excel で手作業管理している構成台帳をなくしたい、というケースです。
Amazon EventBridge Scheduler で毎月末に小さな処理（AWS Lambda など）を動かし、構成スナップショットか高度なクエリの結果を Amazon S3 に月別で保管します。全項目を残すならスナップショット、必要な項目だけならクエリが向いています。スナップショットは項目の多い JSON なので、台帳として見るには整形が要ります。
B-2 その変更を誰が行ったか知りたい
AWS Config と AWS CloudTrail の両方を使う、一番分かりやすい例です。
- AWS Config のリソースタイムラインで、対象の変更を見つける
- 関連する AWS CloudTrail のイベントを開く
- 操作者・日時・接続元・操作内容を確認する
1人ずつ別のユーザーでログインする運用（AWS IAM Identity Center など）になっていることが前提です。共用のユーザーで作業していると、記録はあっても「誰か」までは分かりません。
B-3 前日に何が変わったかを毎朝一覧で見たい
マップで「組み合わせ技！」として大きく扱ったものです。
AWS Config の履歴ファイル（何が変わったか）と AWS CloudTrail の証跡（誰がやったか）を Amazon S3 に貯めておき、毎朝 Amazon Athena で前日分を集計します。結果は CSV で保管し、Amazon SNS でメール通知します。
AWS CloudTrail の操作者情報を使うと、変更を「人の作業」「デプロイ」「AWS の自動変更（Auto Scaling など）」に分けることもできます（B-4）。毎朝確認するのは、人の作業とデプロイだけで済みます。
気をつけたいのは配信のタイミングです。AWS Config の履歴ファイルは約6時間ごとに届くので、深夜の変更は翌日分に入ることがあります。
C-1 危険な設定を常にチェックしたい / C-3 自動で元に戻したい
SSH の全開放や S3 バケットの公開などは、Config ルールで常にチェックできます。たとえばマネージドルールの restricted-ssh を有効にしておくと、セキュリティグループで 22 番ポートが全開放されたときに「非準拠」と判定されます。
自動修復を組み合わせれば、AWS Systems Manager Automation で設定を元に戻すこともできます。ただ、申請なしで設定が変わることになるので、最初は手動実行から始めるのが無難です。
D-3 いつからいつまでルール違反だったかを示したい
監査で「いつからいつまで違反していたのか」を聞かれたときに使えます。Config ルールの準拠状況の履歴を見れば、非準拠になった日時と準拠に戻った日時が分かります。
この履歴は、AWS::Config::ResourceCompliance というリソースタイプとして記録されます。コスト削減で記録対象を絞るときに、これを外すと履歴が残らないので注意です。
E-3 IaC で作ったリソースが手作業で変えられていないか確認したい
AWS CloudFormation で作ったリソースなら、Config ルール cloudformation-stack-drift-detection-check でドリフト（テンプレートとのずれ）をチェックできます。対象は AWS CloudFormation のスタックだけなので、Terraform で作ったリソースには使えません。
F-1 障害の前後で何が変わったかを確認したい
B-2 の流れを、障害対応に使う例です。影響のあったリソースのタイムラインで障害前後の変更を確認し、変更があれば AWS CloudTrail で操作者を確認します。
影響範囲を知りたいとき（F-2）は、リソースの詳細画面の「関係」が役立ちます。たとえば、あるセキュリティグループにつながっている EC2 インスタンスが分かります。
G-1 自然言語でリソースについて質問したい
Amazon Q Developer を使うと、コンソールのチャットで「東京リージョンで動いている EC2 インスタンスを一覧にして」のように聞けます。
ただし、回答はその都度 AI が生成するものなので、証跡にはなりません。また、セキュリティ・ID・認証情報・暗号化に関わるリソースの質問は対象外です。
マップでは付箋に「AI は手助け役。判定と記録は仕組みで担う」と書きました。AI で当たりを付けて、最後は AWS Config と AWS CloudTrail の記録で確かめる、という使い方です。
AI との組み合わせ技
マップの最後には、AI との組み合わせを中心に9パターンを載せています。ロボット印が AI を使うものです。
AI を使うものも、最後に判断するのは人です。AI に任せるのは、要約や解説、たたき台づくりまでにしています。
料金の目安
主なものだけ載せておきます。
| 項目 | 料金 |
|---|---|
| AWS Config の構成アイテム | 連続記録 0.003 USD/件、日次記録 0.012 USD/件 |
| Config ルールの評価 | 0.001 USD/件（最初の10万件。以降は段階的に安くなる） |
| AWS CloudTrail のイベント履歴 | 無料（直近90日） |
| AWS CloudTrail の証跡（管理イベント） | 最初の1つは無料。追加の証跡は 2.00 USD/10万イベント |
米国東部の料金です（2026年11月時点）。最新の料金は、参考に載せた公式ページで確認してください。
構成アイテムは、記録したリソースが変わるたびに1件ずつ増えます。Auto Scaling のように頻繁に変わるリソースが多いと、そのぶん料金も増えます。変更の多いリソースタイプは日次記録に切り替える、記録対象から外す、といった調整もできます。
まとめ
- 「何が変わったか」は AWS Config、「誰がやったか」は AWS CloudTrail
- AWS Config は「記録する」と「判定する」に分けると整理しやすい
- やりたいことから逆引きすると、必要な機能と組み合わせが見えてくる
- AI は記録の上に乗せる手助け役
「とりあえず設定しておくもの」だった AWS Config と AWS CloudTrail ですが、整理してみると、思った以上にいろいろできました。
AWS には、小さなサービスをブロックのように組み合わせて仕組みを作る「ビルディングブロック」という考え方があります。AWS Config と AWS CloudTrail は、その土台になる記録のブロックです。そこに Amazon Athena での集計、Amazon EventBridge での通知、Amazon Bedrock での要約を積み上げていくと、台帳づくりから監査対応、AI の活用まで広げられます。
今回の27件も、あくまで一例です。組み合わせ方次第で、まだまだいろいろなことが実現できる可能性を秘めています。構成管理で何から手を付けるか迷ったら、まずはやりたいことの一覧から眺めてみてください。皆様の AWS 活用に少しでもお役に立てば幸いです。