CIS AWS Foundations v1.2 2.9: VPC flow logging should be enabled in all VPCs

CIS AWS Foundations Benchmark controls are often assessed as “baseline hygiene,” but audits fail on basics: inconsistent coverage across accounts, missing evidence, and weak operational ownership. Requirement 2.9 focuses on VPC Flow Logs because they are one of the few native data sources that can answer “what talked to what, when” inside and across VPC boundaries. If you cannot reconstruct traffic patterns during an incident, you are forced to rely on partial telemetry from endpoints, load balancers, or third-party tools that may not cover every path.

This page turns the requirement into an implementation you can run. You’ll get a plain-English interpretation, an operator-ready build checklist, and an evidence package you can hand to an auditor. The guidance aligns to the CIS AWS Foundations Benchmark and the AWS Security Hub mapping that evaluates this requirement as a discrete control (mapped as EC2.6 in Security Hub). Sources: CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table.

Regulatory text

Excerpt (provided): “Implement CIS AWS Foundations Benchmark v1.2 requirement 2.9 as mapped in AWS Security Hub.” (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table)

What this means for operators: You must configure AWS so that every VPC has VPC Flow Logs enabled, and you must be able to demonstrate that configuration through AWS-native evidence (for example, Security Hub findings and VPC Flow Logs configuration state). The practical expectation is continuous coverage across accounts/regions and ongoing verification, not a one-time setup. (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table)

Plain-English interpretation

• Requirement intent: Maintain network traffic visibility at the VPC level so security and operations teams can investigate suspicious activity, validate segmentation, and support incident response.
• What “enabled in all VPCs” means in practice:
  • Every VPC in every in-scope AWS account and region has at least one flow log configured.
  • New VPCs get flow logs automatically (or are blocked from deployment until flow logs exist).
  • Logs are delivered to a controlled destination with retention and access governance so they are actually usable.

Who it applies to

Entity scope: Any organization operating workloads in AWS and assessing against CIS AWS Foundations. (CIS AWS Foundations Benchmark)

Operational scope (typical):

• Multi-account AWS Organizations environments (shared services, dev/test/prod).
• Regulated environments where network logging supports security monitoring and investigations (financial services, healthcare, SaaS handling sensitive data).
• Teams using AWS Security Hub to report CIS benchmark alignment (since this requirement is mapped in Security Hub). (AWS Security Hub CIS AWS Foundations mapping table)

Control owners to assign (practical):

• Primary: Cloud Platform / Cloud Security (build and guardrails)
• Secondary: SOC / Detection Engineering (consumption, alerting)
• Consulted: Network/Infrastructure (routing, TGW), App teams (exception handling)

What you actually need to do (step-by-step)

Step 1: Define the standard (your “done” criteria)

Create a short internal standard that states:

• Flow logs are required for all VPCs (including shared services and non-prod).
• Approved destinations: CloudWatch Logs or S3 (pick one default).
• Retention is set and documented.
• Access is restricted (least privilege) and centrally administered.

Map this standard directly to CIS 2.9 and Security Hub’s CIS mapping so auditors see traceability. (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table)

Step 2: Inventory VPCs across accounts and regions

You need a complete list of VPCs to close gaps.

• If you have AWS Organizations, inventory at the org level (accounts + regions).
• Record: account ID, region, VPC ID, VPC name/tag, environment, owner, and whether flow logs exist.

Evidence tip: Capture a point-in-time export of the inventory and store it with the assessment package.

Step 3: Choose log destination and design for central governance

Pick one primary pattern:

Pattern A: CloudWatch Logs destination

• Pros: faster operational querying, easy subscription filters.
• Cons: cost management and cross-account aggregation requires discipline.

Pattern B: S3 destination

• Pros: durable archive, simpler central retention model, pairs well with analytics tools.
• Cons: operational querying may require additional tooling.

Whichever you choose, ensure:

• Central account ownership of the destination (where feasible).
• Strong access controls (only security/log pipeline roles, break-glass access, and tightly scoped read roles).
• Retention rules (CloudWatch retention policy or S3 lifecycle rules).

Step 4: Implement flow logs for every VPC (including future VPCs)

Operationally, you need both remediation and prevention:

1. Remediate existing VPCs

• For each VPC without flow logs, create a flow log targeting the chosen destination.
• Ensure the IAM role or delivery permissions are correct and tested.
• Validate log delivery (you should see new log streams/events or new S3 objects).

2. Prevent drift (new VPCs without flow logs) Pick one or more guardrails:

• Infrastructure-as-code modules: your “VPC module” always creates a flow log by default.
• Policy guardrails: require flow logs for VPC creation workflows.
• Continuous detection via Security Hub plus ticketing automation for any new noncompliant VPC. (AWS Security Hub CIS AWS Foundations mapping table)

Step 5: Operationalize monitoring, triage, and exceptions

Auditors often ask, “So what do you do with the logs?”

Minimum operating model:

• SOC has a documented procedure to access and query flow logs for investigations.
• A triage path exists for Security Hub findings tied to this control (assignments, SLAs, escalation).
• Exceptions are documented with expiry dates (for example, isolated lab accounts), and you can prove compensating controls.

Step 6: Continuous verification (your audit-proof loop)

Set a recurring control check:

• Review Security Hub CIS control status for this requirement and track exceptions to closure. (AWS Security Hub CIS AWS Foundations mapping table)
• Run periodic configuration queries to confirm every VPC has flow logs and that the logs are still delivering.

Daydream fit (earned mention): If you struggle to keep evidence current across many accounts, Daydream can track the requirement-to-control mapping, schedule evidence pulls (inventory + Security Hub status), and keep an auditor-ready trail without re-building the package each quarter.

Required evidence and artifacts to retain

Keep evidence that proves coverage, delivery, and governance:

Coverage (configured everywhere)

• Export/list of all VPCs in scope with a “Flow Logs enabled: yes/no” field.
• Screenshots or exported findings showing Security Hub CIS mapping status for the control associated with this requirement (EC2.6 mapping reference). (AWS Security Hub CIS AWS Foundations mapping table)

Delivery (logs are actually arriving)

• For CloudWatch: log group names, retention settings, sample recent events (redact as needed).
• For S3: bucket name, sample object prefixes, and a proof of recent writes (redact as needed).

Governance (controlled and retained)

• IAM policy snippets or role descriptions that show who can read/manage flow logs destinations.
• Retention evidence (CloudWatch retention policy or S3 lifecycle configuration).
• Exception register (approved exceptions, owners, compensating controls, expiry).

Common exam/audit questions and hangups

1. “Does this include non-production and sandbox VPCs?”
   Most auditors interpret “all VPCs” literally unless your scope statement explicitly excludes accounts/regions and explains why. Document scope clearly and apply consistently.

2. “How do you ensure new VPCs get flow logs?”
   Expect to show either preventive IaC patterns or detective monitoring plus a rapid remediation process. Security Hub mappings help for detective coverage. (AWS Security Hub CIS AWS Foundations mapping table)

3. “Where are logs stored and who can access them?”
   Be ready with a simple access matrix: security operations read access, limited admin access, and no broad developer write/delete permissions.

4. “How long do you retain logs?”
   Auditors typically accept your documented retention standard if it is consistent and enforced. Avoid ad hoc retention.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails audits/IR	How to avoid it
Enabling flow logs only in “prod”	Violates “all VPCs” expectation; gaps appear in inventories	Apply org-wide; define explicit scope exclusions
Configured but not delivering	You “have a flow log” but no usable data	Test delivery; verify recent writes/events
Decentralized log destinations	Evidence collection becomes chaotic; access control weak	Centralize destination ownership and standards
No retention policy	Logs disappear, undermining investigations	Set and evidence retention configuration
No ongoing verification	Drift returns; new VPCs appear noncompliant	Automate periodic checks and track findings

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific CIS requirement. Practically, the risk is operational: without VPC Flow Logs, you may not be able to reconstruct network activity during a security incident, and you may be unable to demonstrate detective control operation during an audit against CIS AWS Foundations mappings in Security Hub. (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table)

Practical 30/60/90-day execution plan

Days 0–30: Get to visibility and a written standard

• Assign control owner(s) and define scope (accounts/regions).
• Decide default destination (CloudWatch Logs or S3) and document the configuration standard.
• Inventory all VPCs; identify gaps (no flow log, unknown owner, unknown environment).
• Pilot in a small set of accounts, validate delivery, and capture evidence.

Days 31–60: Remediate and implement guardrails

• Remediate remaining VPCs in priority order (internet-facing, shared services, production).
• Centralize destinations (or standardize naming/structure) and lock down access.
• Implement IaC defaults for VPC creation so flow logs come “for free.”
• Turn on Security Hub tracking for the CIS mapping and integrate findings into your ticketing workflow. (AWS Security Hub CIS AWS Foundations mapping table)

Days 61–90: Prove continuous compliance

• Formalize runbooks: how SOC queries flow logs; how cloud team remediates failures.
• Create a monthly evidence pack: VPC inventory export, flow logs coverage proof, retention proof, Security Hub status snapshots.
• Stand up an exceptions process with expiration and compensating controls.
• If evidence collection is consuming cycles, configure Daydream to maintain the control mapping and keep an evidence trail current across accounts.

Frequently Asked Questions

Does “all VPCs” include shared services, dev/test, and temporary VPCs?

Yes, unless you have a formally documented scope exclusion that auditors accept. Treat ephemeral and non-prod VPCs as in-scope by default because incidents often start outside production.

Is enabling flow logs at the subnet or ENI level acceptable instead of the VPC level?

The requirement language targets VPC-wide coverage. Subnet/ENI-only logging can create gaps if teams forget to apply it everywhere; use VPC-level flow logs as the default, and document any narrower scope as an exception.

Can we send VPC Flow Logs to either CloudWatch Logs or S3?

Either destination can meet the intent if logs are retained, access-controlled, and verifiably delivered. Pick one standard pattern so evidence and operations are consistent.

What evidence is most persuasive to an auditor?

A complete VPC inventory showing flow log status, plus Security Hub CIS control status screenshots/exports tied to the mapped requirement. Add proof of log delivery and retention settings. (AWS Security Hub CIS AWS Foundations mapping table)

How do we prevent new VPCs from being created without flow logs?

Make flow logs part of your VPC IaC module and require teams to use it. Backstop with Security Hub detection and a remediation SLA so drift is caught quickly. (AWS Security Hub CIS AWS Foundations mapping table)

What if flow logs are enabled but the security team never looks at them?

Audits may still pass on configuration, but operational risk remains. Add a lightweight runbook and a periodic exercise where the SOC pulls flow log data for a sample investigation.

Related compliance topics

• 03.01.18: Access Control for Mobile Devices
• 03.01.19: Withdrawn
• 03.01.20: Use of External Systems
• 03.01.21: Withdrawn
• 03.01.22: Publicly Accessible Content