この記事でわかること
調査を始めてから「そのVPCはフローログが無効だった」と分かっても遅い、という問題を、AWS Configで事前に確かめる方法を初学者向けにまとめました。AWS Configの基本から、複数アカウントでフローログの設定漏れを探す確認項目の作り方までを扱っています。
AWS Configの3つの部品
- 構成アイテム：リソースの作成・変更・削除のたびに、その時点の設定を1件ずつ残す記録。いつ設定が変わったかを履歴で追える
- ルール：決まりに合っているかを自動で判定する。結果は COMPLIANT / NON_COMPLIANT のほか、ERROR と NOT_APPLICABLE がある。トリガーは設定変更時・定期・両方から選ぶ
- アグリゲーター：複数アカウント・リージョンの構成データと評価結果を1か所に複製して読めるようにする。読み取り専用で、集めるのは「AWS Configが有効なアカウント」だけ
既定では動いていない
AWS Configはアカウントとリージョンごとに有効にします。記録の範囲（全リソースタイプか、特定のタイプか）と頻度（継続か日次か）を選びます。費用は構成アイテムの数とルール評価の回数で決まります。
vpc-flow-logs-enabled で分からないこと
このマネージドルールは、対象が AWS::EC2::VPC、トリガーが定期で、パラメータは trafficType だけです。公式の説明に出てくるのは「VPCにフローログが見つかり、有効か」の判定です。次の3点は、別の方法で確かめる必要があります。
- 送信先（調査担当者が読めるバケットやロググループに届いているか）
- 記録項目（vpc-id、flow-direction などが入っているか）
- 共有VPCの利用者アカウントが作ったフローログ（所有者からは参照も削除もできない）
Security Hub CSPM の EC2.6 も同じルールを使いますが、trafficType は REJECT に固定です。
確認項目の作り方
- 確認表を作る：対象、所有アカウント、作成アカウント、通信の種類、送信先、記録項目、確認方法
- AWS Configは AWS::EC2::FlowLog を記録でき、送信先や記録形式などの設定値が台帳に残る
- 高度なクエリ（SQLのSELECTの一部）で、アグリゲーター越しにフローログとVPCの一覧を取る。JOINは使えないので突き合わせは表計算などで行う
- 送信先と記録項目の判定は、AWS::EC2::FlowLog を対象にしたカスタムルールで設計する
記事にはクエリ例と確認表の記入例を載せています。値はすべて架空の例で、クエリは構文を公式ドキュメントで確認しただけです。検証環境での実測はしていません。
※2026年10月時点の公開情報に基づく