Amazon VPC Flow Logs · IP traffic metadata · Observability

Record every flow through your VPC as a one-line record

VPC Flow Logs records IP traffic going to and from network interfaces as records keyed by the 5-tuple. Collection happens outside the traffic path, so throughput and latency aren't affected, and you can send records to CloudWatch Logs, Amazon S3, or Amazon Data Firehose for immediate analysis.

Default format · version 21 record = 1 flow

2 123456789012 eni-0a1b2c3d4e5f60718 203.0.113.12 10.0.1.25 51544 22 6 3 180 1760331600 1760331660 REJECT OK

  • 2version
  • 123456789012account-id
  • eni-0a1b…0718interface-id
  • 203.0.113.12srcaddr
  • 10.0.1.25dstaddr
  • 51544srcport
  • 22dstport
  • 6protocol · TCP
  • 3packets
  • 180bytes
  • 1760331600start
  • 1760331660end
  • REJECTaction
  • OKlog-status

One line tells you that an SSH attempt from the internet was blocked by a security group or network ACL.

6

Capture targets (VPC · subnet · ENI · TGW · TGW attachment · regional NAT)

1 / 10 min

Maximum aggregation interval options (Nitro instances always 1 minute or less)

3

Destinations (CloudWatch Logs · S3 · Firehose)

Out-of-path

Collected outside the traffic path, no performance impact

Why Flow Logs

The baseline log that answers "where was this packet blocked?"

Without packet capture, you can see who communicated, when, on which port, how much, and whether it was accepted or rejected. Network operations, security, and cost analysis all work from the same data.

Diagnose

Troubleshoot security groups and NACLs

Use REJECT records to find overly restrictive rules, and compare ingress and egress records of the same flow to spot return traffic missing from stateless NACLs.

Forensics

Security investigation and anomaly detection

Reconstruct peers around a suspected compromise, port scans, and unexpected outbound traffic from records. Amazon GuardDuty also analyzes VPC flow logs as a foundational data source.

Analyze

Traffic and cost analysis

Break down cross-AZ, internet, and peering traffic volume with the bytes, traffic-path, and az-id fields, and trace where data transfer costs come from.

Record format

Start with the default format; add the fields you need with a custom format

The default format uses the 14 version 2 fields in a fixed order. A custom format picks only the fields you want, in the order you want, and the record's version becomes the highest version among the chosen fields. The format can't be changed after creation; to change it, create a new flow log.

--log-formatcustom · version 5
${version} ${interface-id} ${instance-id} ${srcaddr} ${dstaddr}
${pkt-srcaddr} ${pkt-dstaddr} ${flow-direction} ${traffic-path}
${tcp-flags} ${action}
Example custom format definition
NAT gateway ENI · ingresssample record
5 eni-0nat0123456789abc - 10.0.1.25 10.0.0.15 10.0.1.25 198.51.100.10 ingress - 2 ACCEPT

# dstaddr     = private IP of the NAT gateway ENI
# pkt-dstaddr = actual packet destination (internet peer)
# instance-id = '-' (requester-managed ENI)
# tcp-flags 2 = SYN; traffic-path is populated only in egress records
Custom format record captured on a NAT gateway network interface, with field interpretation
  1. v3 pkt-srcaddr · pkt-dstaddr

    When traffic passes through an intermediate layer such as a NAT gateway or EKS pods, these show the packet's original source and destination rather than the ENI address. vpc-id, subnet-id, instance-id, and tcp-flags are also v3.

  2. v4 · v5 Location and direction

    region, az-id, and sublocation (v4), plus flow-direction (ingress or egress), traffic-path (the egress path such as IGW, peering, VGW, or gateway endpoint), and pkt-src/dst-aws-service (v5) add context to the flow.

  3. v7 ecs-* fields

    ecs-cluster-name, ecs-service-name, ecs-task-arn, and others identify traffic per ECS task. They require permission to call the relevant ECS APIs, and non-ECS traffic shows '-'.

  4. v8+ Reject reasons and extended metadata

    reject-reason (v8) identifies flows rejected by VPC Block Public Access (BPA) or VPC Encryption Controls (EC). resource-id (v9) adds regional NAT gateways, encryption-status (v10) shows whether traffic is encrypted in transit, and v11 adds instance, ENI, and ASG tags, interface-type, and next-hop-* fields.

Traffic that isn't logged

Flow Logs doesn't capture all IP traffic. The traffic below produces no records, so if you need a record of DNS queries, also use Route 53 Resolver query logging.

Amazon DNS server queries169.254.169.254 (IMDS)169.254.169.123 (Time Sync)DHCPARPWindows license activationDefault VPC router reserved IPTraffic Mirroring source trafficEndpoint ENI ↔ NLB ENIRegional NAT deleted right after creation

Features

Main features

Scope

Choose capture scope

Create a flow log on a VPC or subnet and every ENI in it is covered, including ENIs created later. You can also watch a single ENI, or create flow logs per transit gateway, attachment, or regional NAT gateway.

Traffic type

ACCEPT · REJECT · ALL

Log only accepted traffic, only rejected traffic, or everything. For security group troubleshooting, collect only REJECT to cut log volume and cost.

Aggregation

1- or 10-minute aggregation

Groups the same flow into one record over the maximum aggregation interval. The default is 10 minutes; choosing 1 minute is more granular but produces more records. Nitro instance ENIs use 1 minute or less regardless of the setting.

Query

Logs Insights · Athena

In CloudWatch Logs, aggregate directly with Logs Insights queries; in S3, run SQL with Amazon Athena. The console can also generate a CloudFormation template for Athena integration.

Transit Gateway

TGW flow logs

Record flows for an entire transit gateway or per attachment. Find routing problems with source and destination VPCs and accounts, plus loss counters such as packets-lost-no-route and packets-lost-blackhole. Transit Gateway overview

Organization

Central collection · Organization-wide enablement

Send to S3 buckets or Firehose streams in other accounts using bucket policies or cross-account IAM roles. With CloudWatch telemetry enablement rules, flow logs to CloudWatch Logs are created automatically for existing and new VPCs in an organization, account, or tag scope.

Destinations

Comparing destinations

You can create several flow logs with different destinations and formats on the same resource. CloudWatch Logs suits immediate queries and alarms, S3 suits long-term retention and bulk analysis, and Firehose suits streaming to external tools.

VPC Flow Logs destinations compared
DestinationStorageAnalysisBest for
CloudWatch Logs A log stream per ENI in a log group. Requires an IAM role with publish permissions Logs Insights queries, metric filters and alarms, subscription filters Querying right away during troubleshooting, or alarming on REJECT spikes
Amazon S3 Text (gzip) or Apache Parquet files. Optional Hive-compatible S3 prefixes and hourly partitions Amazon Athena SQL, Athena integration template generated by the console Retention of months or longer, bulk analysis per account or organization, lower cost
Amazon Data Firehose Delivered to a Firehose stream in the same or another account Analyzed in destinations Firehose supports (OpenSearch Service, Splunk, HTTP endpoints, and more) Near-real-time streaming to a SIEM or third-party observability tools

Reference architecture

Three stages: capture, delivery, analysis

Flow Logs collects flow metadata from ENIs and transit gateways outside the traffic path, groups it into records every aggregation interval, and delivers them to destinations. Because each destination uses different analysis tools, it's common to create separate flow logs per purpose. To check statically whether the path itself is configured as intended, use Reachability Analyzer.

VPC Flow Logs capture and delivery architecture Flow information is collected by VPC Flow Logs from EC2 instance ENIs, NAT gateway ENIs, and ECS task ENIs inside the VPC, and from a transit gateway outside the VPC. Flow Logs creates records at a 1- or 10-minute aggregation interval and delivers them to CloudWatch Logs, Amazon S3, and Amazon Data Firehose. CloudWatch Logs is analyzed with Logs Insights and alarms, S3 with Athena, and Firehose with tools such as OpenSearch or Splunk. VPC 10.0.0.0/16 DESTINATIONS → ANALYSIS EC2 instance ENIprivate subnet NAT Gateway ENIpkt-srcaddr · pkt-dstaddr ECS task ENIecs-* fields Transit Gatewayper TGW · attachment VPC Flow Logs out-of-path capture aggregate 1 · 10 min ACCEPT · REJECT · ALL flow metadata CloudWatch Logslog stream per ENI Amazon S3text · Parquet Data Firehosestreaming delivery deliver Logs Insightsquery · alarm Amazon AthenaSQL analysis OpenSearchSplunk, HTTP, …
Flow capture (out-of-path) Record delivery Delivery to analysis tools

On narrow screens, swipe the diagram sideways.

Getting started

Steps to turn on your first flow log

  1. STEP 1

    Scope and traffic type

    Choose a target among VPC, subnet, ENI, TGW, and regional NAT, and decide on ACCEPT, REJECT, or ALL. VPC overview

  2. STEP 2

    Prepare the destination

    Prepare a log group and IAM role, or an S3 bucket policy or Firehose stream.

  3. STEP 3

    Format and aggregation interval

    Choose default or custom format, a 1- or 10-minute interval, and for S3, Parquet and Hive partitions.

  4. STEP 4

    Create the flow log

    Create it in the console or with aws ec2 create-flow-logs and add tags.

  5. STEP 5

    Verify with queries

    Once records accumulate after a few minutes, check the top REJECT flows first with Logs Insights or Athena.

Pricing

Cost components

Flow Logs has no separate hourly charge; the log data it generates is billed at CloudWatch vended logs rates. Rates differ by destination and are tiered, decreasing as usage grows.

VPC Flow Logs charges
ChargeBilling basisNotes
CloudWatch Logs ingestionGB of vended logs ingestedCloudWatch Logs storage charges are added for the log group's retention period
Delivery to S3GB of vended logs deliveredS3 storage and request charges for the bucket are separate. Reduce retention costs with lifecycle policies
Parquet conversionGB convertedOnly when you choose Parquet for an S3 destination. In return, Athena scans less data
Delivery to FirehoseGB of vended logs deliveredCharges for downstream Firehose stages and the final destination are billed by those services
Organization-wide auto-enablementAWS Config configuration itemsCloudWatch telemetry enablement rules discover resources with an AWS Config service-linked recorder, so Config charges apply; ingestion is billed at vended logs rates
AnalysisBilled by other servicesLogs Insights is based on data scanned; Athena is based on data scanned per query

Log volume scales with the number of flows, the aggregation interval, and the number of fields chosen more than with traffic volume. Logging only REJECT or choosing only the fields you need reduces cost. Add cost allocation tags to destination resources (log groups, buckets, Firehose streams) to split flow log charges by team. See Vended Logs on the Amazon CloudWatch pricing page for current rates.

Next step

Log only the flows you need, in the format you need

Tell us whether the goal is troubleshooting, security investigation, or cost analysis, and bring your account and VPC structure; we'll review the capture scope, field selection, destinations, and retention strategy together.