AWS Configでフローログの抜けを探す ― 複数アカウントのログ設定を確かめる

調査を始めてから、「そのVPCはフローログが無効だった」「別のバケットに送られていた」「必要な項目がなかった」と分かることがあります。ログの有無は、事件が起きてからでは直せません。

前回のCloudTrailとVPCフローログの記事は、ログが残っている前提で調査を組み立てました。今回は、その前提を事前に確かめる話です。使うのは、AWSの設定がいつ、どう変わったかを記録し、決めたルールを守れているかを自動でチェックするAWS Configです。基本を初めての方向けに説明したうえで、複数アカウントでフローログの設定漏れを探す確認項目を設計します。

AWS Configとは ― 設定の台帳と自動チェック

AWS Configは、AWSのリソース（サーバー、ネットワーク、バケットなど）の作成・変更・削除を検知して、その時点の設定を記録するサービスです。記録した設定が決めたルールに合っているかも判定できます。台帳をつける役と、台帳を見て合否を出す役の2つを持っています。

設定の変更履歴を残す「構成アイテム」

1回の変更で残る記録が「構成アイテム」（Configuration Item）です。たとえばセキュリティグループ（通信を許可する条件を決める設定）が「どこからでも接続可」へ変わり、数時間後に元へ戻ったとします。構成アイテムを時系列に並べれば、いつ開いて、いつ戻したかを追えます。

※値は架空、項目は実物から一部を抜粋した例です。構成アイテムは変更のたびに1件ずつ残り、この例ではSSHの接続元が10.0.0.0/16から0.0.0.0/0に変わった2件目にあたります（1件目は2026-10-05 01:10、3件目は05:15に10.0.0.0/16へ戻した、という仮の経過。時刻はいずれもUTC）。

{
  "version": "1.3",
  "accountId": "111122223333",
  "configurationItemCaptureTime": "2026-10-05T03:40:12.000Z",
  "configurationItemStatus": "OK",
  "configurationStateId": "1791171612000",
  "awsRegion": "ap-northeast-1",
  "resourceType": "AWS::EC2::SecurityGroup",
  "resourceId": "sg-0example1234567890",
  "configuration": {
    "groupId": "sg-0example1234567890",
    "ipPermissions": [
      {
        "fromPort": 22,
        "ipProtocol": "tcp",
        "ipv4Ranges": [ { "cidrIp": "0.0.0.0/0" } ]
      }
    ]
  }
}

見るのは、いつ記録したか（configurationItemCaptureTime）、何のリソースか（resourceType、resourceId）、設定の中身（configuration）です。なお、構成アイテムの関係（relationships）にネットワークの通信の流れは含まれません。通信そのものは、フローログの仕事です。

決まりへの適合を判定する「ルール」

ルールは、「S3バケットが公開されていないこと」のような決まりを構成アイテムに当てて判定する仕組みです。結果は COMPLIANT（適合）か NON_COMPLIANT（不適合）が基本で、パラメータ不正の ERROR、対象外の NOT_APPLICABLE もあります。

ルールには2種類あります。AWSが用意するマネージドルールと、自社で作るカスタムルールです。カスタムルールは、Lambda関数で判定を書くカスタムLambdaルールと、Guard（ポリシーを記述する言語）で書くカスタムポリシールールの2通りです。

いつ判定するか（トリガー）は、「設定が変わったとき」「定期（たとえば24時間ごと）」「両方」から選びます。Guardのカスタムポリシールールは設定変更で評価が始まります。本記事の主役である vpc-flow-logs-enabled は定期の評価です。この違いは5節と6節で効いてきます。

既定では動いていない。範囲を選んで有効にする

AWS Configはアカウントとリージョンごとに有効にします。アカウントを作っただけでは記録は始まりません。コンソールの「1-click setup」は、すべてのリソースタイプ（上書き設定あり）を「継続記録」で記録します。IAMのグローバルリソースは費用削減のため初期状態では除外され、マネージドルールは何も選ばれていません。

手動で設定すると、特定のリソースタイプだけ記録する、除外する、といった選択もできます。記録の頻度は、変更のたびに記録する「継続」と、24時間で最新の状態が前回と違うときだけ1件にする「日次」です。

費用は、記録した構成アイテムの数と、ルールを評価した回数で決まります。単価は9節の表にまとめました。

CloudTrail・VPCフローログとの違い

AWSには「記録」と呼べるものが3つあり、答えられる問いがそれぞれ違います。

← 表は横にスクロールできます →

セキュリティグループが開いた件なら、CloudTrailは「誰が変更APIを呼んだか」、AWS Configは「変更の前後の設定」、フローログは「開いたあとに実際に届いた通信」を教えてくれます。

VPCフローログを簡単におさらいします。VPCはAWSの中に作る自社専用のネットワークで、フローログはそこを通った通信の「通話記録」です。VPC、サブネット、ネットワークインターフェイス（ENI）のどれかの単位で作り、作成時に送信先（CloudWatch Logs、S3、Amazon Data Firehose）を必ず指定します。既定では作られません。読み方は前回記事の「VPCフローログとは」にあります。

「このVPCにフローログが設定されているか」は、フローログ自身には残りません。設定の有無や中身を記録するのは、AWS Configの役目です。

複数のアカウントの設定をまとめて見るには

AWS Configは、原則としてアカウント×リージョンごとに動きます。本番、開発、委託先とアカウントが分かれれば、台帳もそれぞれに分かれます。

この台帳をまとめて読めるようにするのが「アグリゲーター」です。各アカウント・リージョンの構成データと評価結果を、1つのアカウント・リージョンに複製して、そこから横断して見られるようにします。ただし読み取り専用で、アグリゲーターからルールを配ったり、設定を変更したりはできません。アグリゲーター自体に追加料金はかかりません。

作り方は2通りあります。

• アカウントIDを個別に追加する: 追加される各アカウント側で、集めてよいという承認（authorization）が必要です
• 組織を追加する: AWS Organizations（複数のアカウントをまとめて管理する仕組み。作り方は過去記事）の組織内なら承認は不要です。組織の管理アカウントか委任管理者で作成し、組織で「すべての機能」が有効で、AWSConfigRoleForOrganizations を付けたIAMロールが必要です

委任管理者の登録はCLIで行います。ルールやコンフォーマンスパック（ルールをまとめて配る単位）を組織へ展開する場合は、別の登録も要ります。

調査のときに「ログがない」と判明する

たとえば次のような状況を考えます（仮の例です）。「フローログは全VPCで有効」と報告されていました。ところが調べてみると、検証用VPCは対象外で、本番VPCの一部はREJECT（拒否された通信）だけを記録しており、別の一部はアプリチームのアカウントのCloudWatch Logsへ送られていて、調査担当者が読めませんでした。

「フローログがある」は3段に分けて考えます。1つ目は有効になっていること。2つ目は、調査に必要な通信（許可も拒否も）を記録していること。3つ目は、調査担当者が読める場所に届いていることです。

前回の調査は、3段すべてが満たされている前提で成り立っていました。その前提を事件の前に確かめる役を、AWS Configに持たせます。

AWS Configで確認できること・できないこと

フローログについて、AWS Configの各機能が何を教えてくれるかを先に表にします。

← 表は横にスクロールできます →

vpc-flow-logs-enabled が見ているもの

vpc-flow-logs-enabled（識別子は VPC_FLOW_LOGS_ENABLED）は、対象のリソースタイプが AWS::EC2::VPC、トリガーが定期で、パラメータは任意の trafficType だけです。「VPCにフローログが見つかり、有効か」を判定し、有効でないVPCが1つでもあれば NON_COMPLIANT になります。

公式の説明に、送信先・記録項目・保存期間の判定は出てきません。サブネット単位やENI単位のフローログしかないVPCの扱いも、公式の説明からは確認できませんでした。送信先や項目は別の方法で確かめる必要があります。確認した範囲では、送信先や記録項目を判定するマネージドルールは見当たりません（2026年10月22日時点）。2026年7月に追加された191種にも、フローログのルールは含まれていません。

Security Hub CSPMのコントロール EC2.6（VPC flow logging should be enabled in all VPCs）は、同じ vpc-flow-logs-enabled を使います。ただし trafficType は REJECT に固定されていて変更できず、評価は定期、重要度はMediumです。Amazon Security Lake経由で有効にしたフローログは確認しない、という注記もあります。つまり、EC2.6が合格でも、ACCEPTを含む全通信を記録しているとは限りません。Security Hub CSPMなどが自分の機能のために評価を動かす内部サービスリンクルール（2026年6月発表）は、利用者のレコーダーやルールと独立して動き、AWS Configからの課金はありません。自社で配った vpc-flow-logs-enabled（たとえば trafficType が ALL）とは判定条件が違うため、同じVPCで結果が食い違うことがありえ、どちらを報告に使うかを先に決めておく必要があります。

CloudWatchの自動有効化とは役割が違う

2025年8月4日に発表された、組織全体でのVPCフローログの自動有効化（CloudWatchのテレメトリー設定の「有効化ルール」）は、フローログを作る仕組みです。AWS Configのルールは、作られた設定を評価する仕組みです。役割が違います。

有効化ルールの要点は次の通りです。

• 送信先はCloudWatch Logsのみです。S3へ集約している組織では、この機能でS3向けのフローログは作れません
• すでにCloudWatch Logsへ取り込んでいるVPCには、フローログを作りません
• 利用者が作ったフローログは、変更も削除もしません

2026年4月16日の発表で、有効化ルールを複数のリージョンへ複製できるようになり、全商用リージョンで使えます。

料金の案内は、発表時と現行のドキュメントで書き方が違います。2025年8月の発表では、有効化ルールの対象リソースタイプの構成アイテムに課金されると案内されていました。2026年10月22日時点のCloudWatchのドキュメントには、CloudWatchが内部サービスリンクレコーダーを使うため、その構成アイテムには課金しないと書かれています。どちらが適用されるか断定せず、導入前に料金ページと請求で確認してください。

フローログ設定の確認項目を決める

何を確認するかを、表にして決めます。

確認表の列

列は7つです。対象のVPC・サブネット、所有アカウント、フローログを作ったアカウント、通信の種類、送信先と保存先、記録項目、確認方法です。所有と作成を分けるのは、7節の共有VPCで2つが一致しないことがあるためです。

※以下は架空の記入例です。

← 表は横にスクロールできます →

この記入例では、2行目の送信先は調査担当者が読めないアカウントです。3つ目の条件を満たしていないことが、確認表の時点で分かります。

AWS Configに残るフローログの設定値

AWS Configは AWS::EC2::FlowLog を記録できます。主な設定値は次の例のとおりです（項目名は公式のリソーススキーマのものです）。

※値はすべて架空です。カスタム形式のフローログの例で、既定形式のときに logFormat へ入る値は確認していません。

{
  "resourceType": "AWS::EC2::FlowLog",
  "awsRegion": "ap-northeast-1",
  "accountId": "111122223333",
  "configuration": {
    "flowLogId": "fl-0example1234567890",
    "resourceId": "vpc-0example1234567890",
    "trafficType": "ALL",
    "logDestinationType": "s3",
    "logDestination": "arn:aws:s3:::example-org-flowlogs/prod/",
    "logFormat": "${version} ${account-id} ${vpc-id} ${subnet-id} ${srcaddr} ${dstaddr} ${action} ${flow-direction} ${traffic-path}",
    "maxAggregationInterval": 60,
    "deliverLogsStatus": "SUCCESS",
    "flowLogStatus": "ACTIVE"
  }
}

deliverLogsStatus は SUCCESS か FAILED で、配信に失敗していないかを見る手がかりになります。

高度なクエリで一覧にする

AWS Configの高度なクエリは、SQLのSELECT文の一部が使える検索機能です。アグリゲーター越しに、複数のアカウント・リージョンへ同じクエリを投げられます。

※以下のクエリは構文を公式ドキュメントで確認しただけで、実行検証はしていません。バケット名は架空です。

-- 1本目: フローログの一覧
SELECT accountId, awsRegion, resourceId,
       configuration.resourceId, configuration.trafficType,
       configuration.logDestinationType, configuration.logDestination
WHERE resourceType = 'AWS::EC2::FlowLog'

-- 2本目: ログ保存アカウントのバケットに送っているものだけ
SELECT accountId, awsRegion, resourceId, configuration.logDestination
WHERE resourceType = 'AWS::EC2::FlowLog'
  AND configuration.logDestination LIKE 'arn:aws:s3:::example-org-flowlogs%'

-- 3本目: VPCの一覧
SELECT accountId, awsRegion, resourceId
WHERE resourceType = 'AWS::EC2::VPC'

1本目でフローログの一覧、3本目でVPCの一覧を取り、configuration.resourceId とVPCのIDを突き合わせます。JOINが使えないので、表計算などで照合します。2本目は、ログ保存アカウントのバケットに送っているものだけを数えるクエリで、1本目の件数との差を見ます。

制約も知っておく必要があります。LIKEのワイルドカードは後ろ側（前方一致）だけで、3文字以上です。そのため「logFormat に flow-direction を含むか」のような部分一致は、高度なクエリでは調べられません。記録対象にしていないリソース（ResourceNotRecorded）と削除済みのリソースも検索できず、対象は現在の状態だけです。

送信先と記録項目はカスタムルールで判定する

ここは設計の提案です。コードは載せません。

フローログ1件ごとの判定、たとえば送信先が組織のログ保存アカウントのバケットか、logFormat に必要な項目が入っているか、は AWS::EC2::FlowLog を対象にしたカスタムルール（Guardのカスタムポリシールール、またはLambda）で、設定変更時に評価できます。一方、「どのVPCにも条件を満たすフローログがあるか」は、VPCとフローログをまたぐ判定です。vpc-flow-logs-enabled と組み合わせるか、定期実行のカスタムLambdaルールでAPIを呼んで判定します。

調査で使う項目の例は、account-id、vpc-id、subnet-id、instance-id、pkt-srcaddr・pkt-dstaddr、flow-direction、traffic-path です。既定の形式（バージョン2の項目）には、vpc-id 以降は入っていません。

2026年6月の新項目を使うなら、作り直しを計画する

2026年6月10日に、フローログへEC2タグ（instance-tag、interface-tag、asg-tag など）とネクストホップ（next-hop-interface-id など）の項目が追加されました。どちらもバージョン11の項目です。発表ページには、既存のフローログの扱いは書かれていません。

ただし、公式の記録形式のページでは、既定の形式はバージョン2の項目で固定され、変更できません。制限事項のページには、フローログは作成後に設定も形式も変更できず、削除して作り直すと明記されています。そのため、既存のフローログに新しい項目は後から足せません。必要な項目を決めてから、カスタム形式で作り直すことになります。

作り直しの間に記録が途切れないよう、新しいものを先に作ってから古いものを消す順にします。これは手順上の一般的な注意です。1つのリソースにつき250件までサブスクリプションを作れるという公式の記載があるので、一時的に2本並べる余地はあります。

タグ項目を含むフローログを作ると、サービスにリンクされたロール（AWSServiceRoleForVPCFlowLogs）とEventBridgeのマネージドルールが自動で作られます。Auto Scalingグループのタグ項目には、有効なCloudTrailの証跡が1つ以上要ります。作成後1時間は、タグの値が欠けたり不正確だったりする場合があります。メタデータ項目はベストエフォートです。

共有VPCとアカウントをまたぐ経路で抜けやすいところ

所有者と利用者で、作れる範囲と見える範囲が違う

共有VPCは、1つのVPCのサブネットを複数のアカウントで使う構成です。VPCを持つアカウントが「所有者」、借りて使うアカウントが「利用者」で、フローログの権限は次のように分かれています。

• 所有者: 共有サブネットのフローログに加え、利用者が所有するENIのフローログも、作成・参照・削除できます
• 利用者: 自分が所有するENIのフローログだけ、作成・参照・削除できます。共有サブネットのフローログは作れません
• 所有者は、利用者が作ったフローログを参照も削除もできません

ここから先は推論です。AWS Configが記録するのは各アカウントが参照できる範囲なので、利用者が作ったフローログは利用者アカウントの台帳にだけ載ると考えられます。所有者側だけ、利用者側だけを見ても全体は分からないので、アグリゲーターで両方を集めます。

共有サブネットでの新項目にも注意が要ります。所有者がサブネット単位でタグ項目付きのフローログを作っても、利用者が所有するリソースのタグの値は計算されず、- になります。ネクストホップの項目も、次の行き先のENIがフローログの作成者の所有でないと計算されません（next-hop-az-id は除きます）。

経路ごとの記録責任を表にする

アカウントをまたぐ経路ごとに、誰がフローログを作れるかを整理します。

← 表は横にスクロールできます →

組織の外のアカウントは、アグリゲーターの「組織を追加」の対象になりません。個別に追加して先方の承認を受けます。実際には、契約で記録と開示の範囲を取り決める話になります（前回記事の「ログの集め方を、アカウント間の取り決めとして設計する」を参照）。

組織全体へ展開するときの順序

全アカウントへ一度にルールを配ると、例外の整理が追いつかず、NON_COMPLIANTができやすくなります。次の順がよいと考えます。

1. アグリゲーターで、フローログの現状を把握する
2. 例外を整理する（理由と期限を決める）
3. ルールやコンフォーマンスパックを組織へ展開する
4. 自動有効化や修復を検討する

4つ目の修復を自動にするか、承認を挟むかは、以前の「Security HubとASRのAI Toolkitの記事」の判断表に戻って決めます。

組織ルールと組織コンフォーマンスパックは、APIかCLIで作成します（コンソールからは作れません）。リージョンごとに呼び出し、新しく参加したアカウントには自動で配られます。ただしそのアカウントでレコーダー（記録を担う部分）が有効でないと、再試行は7時間までです。除外アカウントの指定もできます。

記録範囲の選び方

特定のリソースタイプだけを記録している場合、AWS::EC2::FlowLog を含めないと、フローログの設定は台帳に残りません。2026年10月7日に追加された77種のリソースタイプ（EC2関連は AWS::EC2::VPCCidrBlock など）も、特定のタイプを指定していると対象になりません。

全部を記録すれば構成アイテムが増え、費用も増えます。スポットインスタンスのような短命なリソースが多いアカウントは、除外するか別アカウントに分けることが公式でも示されています。

監査や顧客に説明できる状態にする

「ログを取っています」と答える前に、対象の範囲（アカウント、リージョン、VPC）、例外とその理由、確認した日時と方法を示せるようにします。AWS Configの台帳と評価結果は、「確認した日時と方法」の裏づけになります。

費用は、AWS Config側とフローログ側に分かれます。AWS Configの単価を表にしました。

← 表は横にスクロールできます →

2026年10月22日に確認した単価です。試算ではなく、単価の転記です。

フローログ側は、CloudWatchの「Vended Logs」として、取り込みと保存の料金がかかります。単価は今回再確認していないので、CloudWatchの料金ページで確認してください。

シリーズ全体での位置づけ

シリーズの4本を並べると、次のようになります。

検知はGuardDutyの記事、修復はSecurity HubとASRの記事、調査はCloudTrailとVPCフローログの記事で扱いました。今回のAWS Configは、調査で使うログの設定が保たれているかを確かめる役です。

始めるなら、まず1つのアカウントでAWS Configを有効にして、AWS::EC2::FlowLog を記録対象に含めます。そのうえで、表3の確認表を3行だけ埋めてみてください。空欄が見つかれば、それが最初に直す項目です。

参考資料（2026年10月22日確認）

• AWS Config 記録するリソースの選択（2026年10月22日確認）
• AWS Config 1-click setup（同）
• ConfigurationItem（APIリファレンス）（同）
• 構成アイテムのフィールド（同）
• AWS Config ルールによる評価（同）
• カスタムルールの開発（同）
• マルチアカウント・マルチリージョンのデータ集約（同）
• アグリゲーターの作成（同）
• 委任管理者の登録（同）
• vpc-flow-logs-enabled（同）
• Security Hub CSPM EC2のコントロール（EC2.6）（同）
• AWS Configが記録するリソースタイプ（同）
• AWS::EC2::FlowLog のリソーススキーマ（GitHub）（同）
• FlowLog（EC2 APIリファレンス）（同）
• 高度なクエリ（同）
• フローログのサービスにリンクされたロール（同）
• VPCフローログ、制限事項、レコード（同）
• 共有VPCの責任と権限、Transit Gatewayのフローログ（同）
• VPCフローログのメタデータ追加（2026-06-10）（同）
• CloudWatch 組織全体のVPCフローログ有効化（2025-08-04）（同）
• CloudWatch テレメトリー設定の有効化ルール、TelemetryDestinationConfiguration（同）
• CloudWatch 有効化ルールのクロスリージョン対応（2026-04-16）（同）
• AWS Config 新しいリソースタイプ（2026-10-07）（同）
• AWS Config マネージドルールの追加（2026-07-09）（同）
• AWS Config 内部サービスリンクルール（2026-06-02）（同）
• 組織ルールの展開（同）
• AWS Config の料金（東京の単価はAWS Price List APIで確認。同）、CloudWatchの料金