VPC Security Monitoring: Detecting Network Threats in AWS

Network-level threats are some of the hardest to detect in AWS environments. Application logs tell you about requests your application processed; network monitoring tells you about connections your application made or received. When an EC2 instance is compromised and begins exfiltrating data through HTTPS to a cloud storage endpoint, application logs show nothing unusual. VPC Flow Logs show an outbound connection to an unfamiliar IP address. GuardDuty detects that the destination IP is associated with known malicious infrastructure. DNS query logs show that the instance resolved a domain associated with a command-and-control server before establishing the connection.

No single monitoring layer catches everything. The combination of flow logs, GuardDuty, and DNS query logging provides defense in depth that makes network-based threats difficult to hide.

VPC Flow Logs: The Foundation

VPC Flow Logs capture metadata about network flows to and from network interfaces in your VPC: source and destination IP addresses, ports, protocol, packet counts, byte counts, and flow start and end times. They don't capture payload content — just connection metadata. This is enough to detect reconnaissance (port scanning), data exfiltration (large outbound transfers), and unusual connection patterns.

Enable Flow Logs at the VPC level to capture all traffic within the VPC. You can also enable at the subnet or ENI level for more granular collection, but VPC-level collection is simpler to manage and sufficient for most monitoring use cases. Choose ALL traffic (accepted and rejected) rather than just accepted — rejected traffic shows port scanning and unauthorized connection attempts that are worth investigating.

The delivery destination matters for analysis latency. Deliver Flow Logs to CloudWatch Logs for near-real-time access and pattern-based alerting, or to S3 for cost-effective long-term storage and Athena-based analysis. For security monitoring, CloudWatch Logs delivery allows you to create metric filters and alarms on specific patterns — for example, alerting when a specific instance makes connections to port 22 on more than 10 distinct IPs within an hour (port scanning behavior).

Querying Flow Logs with Athena

For retrospective investigation and pattern analysis, deliver Flow Logs to S3 and use Athena for querying. The Flow Logs custom format can include additional fields beyond the default (such as VPC ID, subnet ID, and instance ID via the ${aws-account-id} and ${instance-id} enrichment fields), which makes investigation queries faster.

Useful Athena queries for security investigation:

-- Top talkers by bytes sent to external IPs
SELECT srcaddr, dstaddr, sum(bytes) AS total_bytes
FROM vpc_flow_logs
WHERE dstaddr NOT LIKE '10.%'
  AND dstaddr NOT LIKE '172.%'
  AND dstaddr NOT LIKE '192.168.%'
  AND action = 'ACCEPT'
GROUP BY srcaddr, dstaddr
ORDER BY total_bytes DESC
LIMIT 20;

This query surfaces the top sources of egress traffic to public IPs — a starting point for identifying potential data exfiltration when investigating an incident.

GuardDuty Network Findings

GuardDuty applies threat intelligence to Flow Log, DNS, and CloudTrail data to generate high-signal findings. Network-specific finding types:

• UnauthorizedAccess:EC2/TorIPCaller: inbound traffic from Tor exit nodes
• Recon:EC2/PortProbeUnprotectedPort: port scanning of instances with open ports
• Backdoor:EC2/C&CActivity.B: outbound traffic to known C&C infrastructure
• CryptoCurrency:EC2/BitcoinTool.B: connections to cryptocurrency mining pools
• Exfiltration:S3/ObjectRead.Unusual: unusual S3 read patterns suggesting data exfiltration

GuardDuty findings arrive in EventBridge within minutes of detection. Configure EventBridge rules to route HIGH and CRITICAL findings to your alert channel for immediate response. GuardDuty finding types and response playbooks covers each finding type and appropriate response.

DNS Query Logging

Route 53 Resolver DNS query logging captures all DNS queries made from instances in your VPC. Malware and compromised instances commonly use DNS for command-and-control communication — the malware resolves a domain to find its C&C server's current IP address rather than hardcoding IPs (which are easily blocked). DNS logging catches this pattern even when the subsequent TCP connection is encrypted.

Enable DNS query logging in Route 53 Resolver settings for each VPC. Deliver logs to CloudWatch Logs for near-real-time analysis and alerting. GuardDuty automatically analyzes DNS query logs when they're available, generating DNS-specific findings for queries to known malicious domains. You don't need to build custom analysis on top of DNS logs if GuardDuty is enabled — but having the raw logs available is valuable for incident investigation.

Network Anomaly Detection

Point-in-time analysis of flow logs is useful for investigation but doesn't provide proactive threat detection. For proactive detection, build baselines of normal traffic patterns and alert on significant deviations.

CloudWatch metric filters on Flow Logs can count bytes per instance and alert when an instance exceeds a threshold. More sophisticated baseline comparison requires storing flow data in a time series database and comparing current patterns to historical averages — achievable with Amazon Timestream or CloudWatch with ML anomaly detection enabled on custom metrics.

The highest-value baselines to establish: normal egress volume per instance type, normal port distribution for application traffic, and expected geographic distribution of inbound connections. Significant deviations from these baselines warrant investigation regardless of whether GuardDuty has generated a specific finding.

Related Reading

• VPC Flow Logs deep dive — advanced flow log configuration and analysis
• Security groups best practices — network access controls that complement monitoring
• GuardDuty setup — enabling the threat detection layer that analyzes network data
• Network Access Control Lists — subnet-level controls for network security

FAQ

Do VPC Flow Logs capture traffic between private subnets in the same VPC?

Yes. Flow Logs capture all network flows through each elastic network interface (ENI), including east-west traffic between resources in the same VPC or between VPC-peered environments. This is valuable for detecting lateral movement — an attacker who has compromised one instance and is pivoting to others within the VPC will generate flow log entries even though they're not crossing an internet boundary.

How long should I retain VPC Flow Logs?

Retain Flow Logs for at least 90 days in accessible storage (CloudWatch Logs or S3 standard) and archive to cheaper storage (Glacier) for 1-2 years. Many security incidents aren't detected immediately — having 90 days of flow data available for investigation is often the difference between understanding the full scope of an incident and having an incomplete picture. Compliance frameworks like PCI DSS and SOC 2 specify log retention requirements; check your applicable frameworks.

Does GuardDuty replace the need for VPC Flow Logs analysis?

GuardDuty reduces the need for custom flow log analysis by detecting known threat patterns automatically. But Flow Logs remain valuable for investigation (understanding exactly what happened during an incident), for compliance (providing the raw audit trail), and for detecting patterns that GuardDuty's threat intelligence doesn't cover. Think of GuardDuty as the automated alert layer on top of flow data, not a replacement for having the data.