A Practical Guide to VPC Security That Goes Beyond the Basics

If you've been working with AWS for more than a few months, you already know the fundamentals of VPC security. Public vs. private subnets. Security groups vs. NACLs. Internet gateways. The usual suspects.

This article isn't about those. This is about the VPC configurations that slip through standard reviews — the ones that create exposure without triggering obvious alarms.

I've spent the better part of three years analyzing VPC architectures across production AWS accounts, and the patterns I'm going to describe show up far more often than they should.

Default VPCs: The Zombie That Won't Die

Every AWS region comes with a default VPC. It has public subnets, an internet gateway, and a default security group that allows all outbound traffic. When you launch an EC2 instance without specifying a VPC, it lands here.

The problem isn't that default VPCs exist — it's that most organizations never delete them, and some teams actively use them for production workloads because "it was easier."

Here's what makes default VPCs dangerous:

• The default security group allows all inbound traffic from members of the same security group. In a default VPC where everything shares that group, every instance can talk to every other instance.
• Subnets in a default VPC auto-assign public IPs. Every EC2 instance gets a public IPv4 address unless you explicitly disable it.
• The default NACL allows all inbound and outbound traffic.

What to do: Delete default VPCs in every region you're not using. For regions where you can't delete them (because something is running there), migrate workloads to purpose-built VPCs and then delete the defaults. Pavora checks for active resources in default VPCs and flags them as high-severity findings.

Security Group Sprawl

Security groups are stateful firewalls — the bread and butter of network security in AWS. But they accumulate over time in a way that makes them nearly impossible to audit manually.

I've seen accounts with 400+ security groups, many of them unused or duplicates of each other. The naming conventions (if they ever existed) have degraded to the point where sg-web-server-v2-final-FINAL is a real thing that exists in production.

The specific risk isn't the sheer number — it's the rules inside them. A security group that was created to allow SSH access from a developer's home IP three years ago might still be attached to 15 instances, long after that developer left the company. That IP address might have been reassigned to someone else entirely.

What to do:

1. Identify and delete unused security groups (not attached to any ENI).
2. Audit all inbound rules with 0.0.0.0/0 as the source. For each one, ask: does this genuinely need to be open to the world?
3. Replace developer-specific IP rules with a VPN or AWS Client VPN. Individual IP-based rules don't scale and rot quickly.

The Flow Log Gap

VPC Flow Logs capture metadata about IP traffic flowing through your VPC. They're essential for security monitoring, incident response, and compliance. And yet, I'd estimate that fewer than half of the production VPCs I've reviewed have them enabled.

The usual excuse is cost. Flow logs generate a lot of data, and storing that data in CloudWatch Logs or S3 adds up. But here's the thing — you don't need to capture all traffic. AWS supports filtering Flow Logs to capture only REJECT traffic, which is typically what matters for security monitoring. Rejected traffic tells you who's knocking on doors that are closed.

For compliance frameworks like PCI-DSS and SOC 2, the absence of flow logs is a finding. Your auditor will ask how you monitor network traffic in your cloud environment, and "we don't" is not an acceptable answer.

What to do: Enable VPC Flow Logs on every VPC with at least REJECT traffic captured. Send them to a centralized S3 bucket with a lifecycle policy that transitions to Glacier after 90 days and deletes after 365 days. The cost is negligible compared to the visibility you gain.

Transit Gateway: Power and Peril

AWS Transit Gateway is brilliant for hub-and-spoke network architectures. Instead of peering every VPC with every other VPC (which creates an O(n²) mesh), you connect them all through a central transit gateway.

But Transit Gateway introduces a subtlety that trips up even experienced network engineers: route propagation. When you attach a VPC to a Transit Gateway and enable route propagation, the Transit Gateway automatically installs routes for that VPC's CIDR into the route tables of other attached VPCs.

In a dev environment, this is convenient. In a production environment with regulated workloads, it means your PCI cardholder data environment might suddenly become routable from a developer sandbox VPC. That's a compliance violation — and potentially an audit failure.

What to do: Disable automatic route propagation. Use static routes and Transit Gateway route tables to explicitly define which VPCs can communicate with which. Create separate route tables for production, staging, and development environments.

DNS Resolution Across VPC Boundaries

VPC peering and Transit Gateway connections don't automatically share DNS resolution. If VPC A has a private hosted zone for internal.mycompany.com, instances in VPC B can't resolve those records unless you've configured DNS resolution forwarding.

This leads to a common pattern: teams hardcode private IP addresses instead of using DNS names, because "DNS didn't work across VPCs." Now you've got IP addresses scattered throughout configuration files, and when those IPs change (because you rebuilt a VPC or migrated a database), things break silently.

The fix is straightforward — enable DNS hostnames and DNS resolution on both VPCs, and configure Route 53 Resolver rules to forward queries appropriately. But I've seen surprisingly few organizations do this correctly.

What to do: Enable enableDnsHostnames and enableDnsSupport on every VPC. Use Route 53 Resolver to forward DNS queries between VPCs. Never hardcode private IP addresses in application configurations.

---

VPC architecture isn't something you set up once and forget. Networks evolve as teams grow, applications scale, and new requirements emerge. What was a reasonable architecture eighteen months ago might have significant gaps today.

Pavora's VPC and networking checks cover security groups, NACLs, flow logs, VPC endpoints, peering connections, and Transit Gateway configurations across all your regions. We flag overly permissive rules, missing logs, and architectural anti-patterns — and map every finding to the compliance frameworks that care about it.

Scan your network posture in under 60 seconds. Read-only access. No agents.