Build VPC Flow Log configurations with custom log formats, S3/CloudWatch destinations, and partition options.
Build VPC Flow Log configurations with custom log formats, S3/CloudWatch destinations, and partition options.
Required Fields
ResourceIdResourceTypeTrafficTypeLogDestinationTypeOutput will appear here...Build a VPC Flow Log configuration specifying scope (VPC, subnet, or individual ENI), destination (CloudWatch Logs or S3), and either the default log format or a custom LogFormat listing exactly which fields to capture, including newer fields like pkt-src-aws-service and flow-direction that aren't in the original default format and have to be explicitly requested. Flow logs only capture accepted and rejected traffic metadata (5-tuple plus byte/packet counts), never packet payloads, so they're the right tool for 'was this connection attempted and did it succeed' investigations but can't answer 'what data was actually sent'.
No, flow logs only capture connection metadata, source/destination IP and port, protocol, packet and byte counts, and accept/reject action, never the packet payload itself. For payload-level inspection you need a different tool (packet capture via Traffic Mirroring, or application-level logging), flow logs answer 'was this connection made and did it succeed', not 'what was actually transmitted'.
Newer fields like pkt-src-aws-service, pkt-dst-aws-service, flow-direction, and traffic-path aren't included in the original default log format for backward compatibility, they only appear if you specify a custom LogFormat explicitly listing them, as the example config does. If you need these fields, you have to opt in with a custom format string, not just enable flow logs with default settings.
It confirms a rejection happened at the network ACL or security group layer and the 5-tuple involved, but it doesn't name the specific rule responsible in the flow log record itself, you have to cross-reference the rejected traffic's characteristics (ports, IPs, direction) against your actual security group and NACL rules to identify which one is responsible. Flow logs tell you where to look, not the exact rule.
The builder validates that ResourceId, ResourceType, TrafficType, and LogDestinationType all resolve before accepting the JSON as a valid CreateFlowLogs request, the fields the EC2 API needs to know what's being logged, what traffic direction to capture, and where logs go; it doesn't validate that DeliverLogsPermissionArn actually has write access to the specified destination, that's only checked once flow log delivery is attempted.
The original default LogFormat is missing several genuinely useful modern fields (pkt-src-aws-service, flow-direction, traffic-path), for any serious troubleshooting or security investigation, define a custom LogFormat including these rather than accepting the legacy default.
Parquet with Hive-compatible partitioning for S3-destined logs isn't just a nice-to-have, it's the difference between an Athena query scanning gigabytes of raw text versus a partition-pruned columnar scan, for any flow log volume worth keeping past a few days, use this destination option from the start rather than reprocessing raw logs later.
A MaxAggregationInterval of 60 seconds versus the 600-second default meaningfully increases log volume and cost at scale, reserve the finer interval for active investigations or specifically security-sensitive VPCs, not as a default for every VPC in the account.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.