Virtual Private Cloud (VPC)

A Virtual Private Cloud (VPC) is your own isolated section of the AWS cloud. You define its IP address range (CIDR block), create subnets, configure route tables, and control network access with security groups and NACLs.

Key Components

• Subnets: public (with internet gateway route) and private (no direct internet access)
• Route Tables: control traffic routing between subnets and gateways
• Internet Gateway: enables internet access for public subnets
• NAT Gateway: allows private subnets to reach the internet for updates without being reachable from the internet
• VPC Endpoints: private connections to AWS services without traversing the internet
• Flow Logs: capture network traffic metadata for monitoring and troubleshooting

Quotas That Shape Your Design

VPC limits are generous but not infinite, and knowing the defaults avoids surprises mid-project:

• 5 VPCs per region per account by default, adjustable into the hundreds (raising it also raises the internet gateway quota by the same amount)
• 200 subnets per VPC by default (adjustable)
• 5 IPv4 CIDR blocks per VPC by default, adjustable up to 50, counting the primary and all secondary blocks
• 2,500 security groups per region by default, with 60 inbound and 60 outbound rules per group

How It Goes Wrong in Practice

The most common VPC security failure is the subnet that is public without anyone deciding it should be. "Public" is not a property you set on a subnet: it is an emergent fact of routing. Any subnet whose route table contains a 0.0.0.0/0 route to an internet gateway is public, and if the subnet also auto-assigns public IPv4 addresses, every instance launched into it is internet-reachable, protected only by its security groups. Teams reorganize route tables, associate the wrong one with a data-tier subnet, and suddenly databases sit one security group mistake away from the internet.

The default VPC compounds this. It exists in every region, is built for convenience rather than isolation, and its subnets are public by design. Workloads launched "temporarily" into the default VPC have a habit of becoming permanent. A sound baseline: treat the default VPC as unused territory, monitor it for any resource creation, and build deliberate VPCs where public subnets exist only for load balancers and NAT gateways, with compute and data tiers in private subnets reached through them.

The other recurring mistake is CIDR planning debt. Overlapping CIDR ranges between VPCs, or between a VPC and on-premises networks, block future peering and VPN routing. Address space is cheap at design time and painful to change later; allocate non-overlapping ranges from a plan, not per-project improvisation.

Practical Check: Find Default VPCs

List the default VPC in a region, if one exists:

aws ec2 describe-vpcs --filters Name=is-default,Values=true

Run this across every region in scope. Anywhere it returns a VPC, follow up by checking whether anything is actually running there; a default VPC hosting forgotten instances is a common finding in first-time AWS security reviews. The same command with Name=cidr,Values=10.0.0.0/16 style filters helps you spot CIDR collisions across accounts before a peering or Transit Gateway project runs into them.

Frequently Asked Questions

What exactly makes a subnet public?

A route to an internet gateway in the subnet's associated route table. Whether instances in that subnet are actually reachable then depends on whether they have public IP addresses and what their security groups allow. All three layers (routing, addressing, security groups) must line up for exposure, which is also why checking only one of them gives false comfort.

Is one big VPC better than many small ones?

For strong isolation, separate VPCs (or better, separate accounts) beat subnet-level separation inside one VPC, because a VPC boundary stops lateral movement at the routing layer rather than relying on security group discipline. The cost is more plumbing: peering, Transit Gateway, or PrivateLink for the traffic that legitimately crosses boundaries. Most mature AWS environments land on multiple VPCs across multiple accounts, connected through a Transit Gateway with segmented route tables.

Does a VPC encrypt my traffic?

No. A VPC provides isolation and routing control, not encryption. Traffic inside a VPC is isolated from other tenants, but encryption in transit remains your job, through TLS at the application layer or the encryption features of the services you use. Treat "it is internal traffic" as a routing statement, never as a security control.