Amazon Virtual Private Cloud

VPC

You need an isolated, private network boundary to secure your virtual servers, databases, and internal APIs.

Reach for it when

Deploying multi-tier application architectures with public-facing load balancers and private databases.
Establishing secure IPSec VPN tunnels between on-premises corporate offices and AWS workloads.
Restricting network traffic to database instances so that only designated application instances can connect.

Deploying simple, standalone static websites with no backend dependencies — use S3 and CloudFront instead.
Building serverless applications entirely out of Lambda and DynamoDB without internal networking needs — use default AWS endpoints instead.
Hosting a simple containerized web app that does not connect to private resources — use App Runner instead.

Service	Pick it instead when
Transit Gateway	Choose it when you need to connect dozens of separate VPCs and on-premises networks together.
VPC Peering	Choose it when you need a simple, low-cost connection between exactly two VPCs without transit routing.

The model: Free to create VPCs, but you pay hourly for NAT Gateways, Transit Gateways, and data processing.
The line item that surprises people: NAT Gateways bill an hourly fee plus a per-GB processing fee that scales rapidly with outbound traffic.

The primary IPv4 CIDR is fixed after creation, but eligible secondary CIDR blocks can be associated. Overlapping ranges prevent VPC peering; plan address space before connecting networks.
Security groups are stateful and allow return traffic automatically, whereas Network ACLs are stateless and require explicit rules.
Each subnet is restricted to a single Availability Zone; failing to spread subnets across AZs eliminates high availability.

This page is a concept reference. Cost models are qualitative; confirm the current offering, Region and pricing before deploying.