AWS VPC Support
VPC Flow Logs: setup and analysis.
Flow Logs record metadata about traffic in your VPC. They answer who is talking to whom, which rule rejected a connection and what drives NAT or cross-AZ charges. We enable them at the right level, with the fields that matter, and build queries your team can reuse.
When You Need This
The situations where this work pays for itself.
Signs it is time
- You need to know why a connection is timing out or being rejected
- You suspect scanning, exfiltration or unexpected outbound traffic
- NAT gateway data processing is high and you do not know the source
- An audit requires network traffic records
- Cross-AZ data transfer costs are unexplained
What you get
- Flow Logs enabled with a custom format in infrastructure as code
- An Athena table and saved queries for rejects, top talkers and NAT traffic
- Alarms for unusual rejects or outbound spikes
- A cost estimate for log volume and retention
How we do it
A clear, safe process you can follow along with.
1. Choose scope and destination
We enable logs on the VPC, subnet or network interface. For long-term and large volume we send to S3 for Athena; for live troubleshooting and alarms we send to CloudWatch Logs.
2. Pick a useful log format
The default format omits fields we want. We use a custom format adding vpc-id, subnet-id, instance-id, pkt-srcaddr, pkt-dstaddr, flow-direction, tcp-flags and traffic-path so NAT and endpoint traffic can be attributed.
3. Understand the limits of the data
Flow Logs are metadata, not packet contents, they are delivered with delay, and some traffic is not logged, such as DNS to the Amazon resolver and instance metadata. We set expectations before relying on them.
4. Find rejected traffic
A REJECT means a security group or NACL denied it. We query for the destination port and addresses, then identify the specific rule. Because security groups are stateful, return-traffic rejects usually point to a NACL.
5. Find top talkers and NAT cost drivers
With Athena or Logs Insights we aggregate bytes by source, destination and port, joined on the NAT gateway interface, to show which instances and destinations account for the traffic.
6. Control volume and alert
We use a partitioned S3 layout and a lifecycle policy, filter to REJECT where full logs are not needed, and create metric filters for patterns such as repeated rejects from one source.
Mistakes we help you avoid
Common ways this goes wrong, and what we do instead.
Using the default format only
You cannot see the real source behind a NAT or which subnet generated the traffic.
Logging everything to CloudWatch Logs
At high volume ingestion is expensive. S3 plus Athena is usually cheaper for analysis.
Reading REJECT as an attack
Many rejects are misconfigured clients or expected scanner noise. We look at patterns and direction.
Assuming Flow Logs show payloads
They record metadata only. Content inspection needs other tools.
Frequently Asked Questions
How do I find which security group blocked traffic?
Query Flow Logs for REJECT records matching the source, destination and port, then compare with the security group and NACL rules on the network interface involved.
Are VPC Flow Logs real time?
No. Records are aggregated over an interval and delivered after a delay, so they suit investigation and trend analysis rather than instant response.
Do Flow Logs cost a lot?
Costs come from log ingestion and storage. They depend on traffic volume and destination, so we estimate before enabling them broadly.
Want Help With VPC Flow Logs: setup and analysis?
Schedule an appointment. Tell us about your environment and we will outline the safest, highest-value approach.
Schedule Appointment › No commitment required