VPC Flow Logs: Reading ACCEPT and REJECT Records in Sazabi

Last verified on Nov 8, 2026.

A VPC flow log answers one question: which network interface talked to which address, on which port, and was the traffic accepted. It does not show payloads. It shows the shape of your network, which is often enough to find a misconfigured security group, an unexpected outbound connection or a scan.

What a flow log record contains

By default each record is a string of space-separated fields, and the default format includes the version 2 fields in a fixed order:

version, account-id, interface-id, srcaddr, dstaddr, srcport, dstport, protocol, packets, bytes, start, end, action and log-status.

Notes from the AWS field reference:

• protocol is the IANA protocol number, so 6 is TCP.
• action is ACCEPT or REJECT.
• start and end are Unix seconds. A flow is captured within an aggregation interval, which is 10 minutes by default and can be set to 1 minute.
• log-status is OK, NODATA or SKIPDATA. NODATA means no traffic on the interface in that interval. SKIPDATA means some records were skipped because of a capacity constraint or an internal error.
• A field that does not apply shows as -.

Metadata fields that do not come from the packet header are best-effort, so treat them as hints.

What to look for

• REJECT by destination port. A rise in rejected flows to 22 or 3389 usually means scanning.
• ACCEPT to ports you never meant to expose. Group by dstport and read the list once.
• Outbound flows with large bytes to addresses outside your ranges.
• REJECT on a flow whose reverse direction was accepted. That pattern can point at a network ACL, because security groups are stateful and network ACLs are not.
• SKIPDATA records. They mean your picture of that interval is incomplete.

Example: a rejected RDP attempt

This record is the AWS documentation's example of rejected traffic:

2 123456789010 eni-1235b8ca123456789 172.31.9.69 172.31.9.12 49761 3389 6 20 4249 1418530010 1418530070 REJECT OK

Reading left to right: version 2, account 123456789010, interface eni-1235b8ca123456789, source 172.31.9.69 port 49761, destination 172.31.9.12 port 3389, TCP, 20 packets and 4,249 bytes over a minute and REJECT. Remote Desktop traffic was refused at that interface.

One rejected record is normal background. Many records from one source across many destination addresses is a sweep. Many records from one source to one destination port across time is a client with the wrong address or a rule that is too tight.

How Sazabi reads flow logs

Per the Sazabi docs, you connect your AWS account and Sazabi creates a flow log for each VPC you pick. Each flow log records accepted and rejected flows at a 1-minute aggregation interval and publishes to CloudWatch Logs. A subscription filter forwards each record to Sazabi, and every flow log field becomes a searchable log attribute.

The setup adds two things to your account. A SazabiVpcFlowLogsManagement policy goes on the SazabiLogIngestion role, the same role the CloudWatch source uses. A SazabiVpcFlowLogsDelivery role lets VPC Flow Logs write the records. For each VPC, Sazabi creates a log group named /sazabi/vpc-flow-logs/VPC_ID, with 1-day retention so records are not stored twice.

To check the source, ask for rejected traffic. This command is from the Sazabi docs:

sazabi logs ask "Show VPC flow log records with aws.vpc.flow.action REJECT in the last 30 minutes"

If you prefer not to grant a role, the docs describe an endpoint path with an OpenTelemetry Collector and the awscloudwatch receiver. On that path each record is stored as its text line, not as separate fields. See OpenTelemetry.

Cost

AWS bills CloudWatch Logs ingestion for every flow log record, on top of Sazabi usage. Pick the VPCs that matter first. Sazabi plans are on the pricing page.

Related AWS sources

Flow logs show the network side of an event. CloudTrail shows the API side and GuardDuty shows what AWS flagged. See the AWS integration page for how to read them together.