Amazon VPC

Your own logically isolated virtual network in AWS, where you control the IP range, subnets, routing, and firewalls.

Verified against AWS documentation · 2026-09-09

Key facts

01Regional: a VPC spans every AZ in one Region, but each subnet lives in exactly one AZ — 5 VPCs per Region by default (soft limit)
02Public subnet = has a route to an internet gateway. Private subnet = no IGW route; outbound-only internet via a NAT gateway sitting in a public subnet
03Security groups are stateful, attach to resources, allow rules only. NACLs are stateless, attach to subnets, and can explicitly deny
04CIDR must be /16 to /28 and can't be shrunk later; AWS reserves 5 IPs in every subnet; every Region ships a default VPC whose subnets are already public

Phrases and scenarios that point here.

"Logically isolated", "our own IP range", "private subnet", "not reachable from the internet" → VPC
Instances need to download patches but must never accept inbound traffic → NAT gateway, not an internet gateway
Block one specific attacking IP range → NACL (deny rules). Allow the app tier to reach the DB tier → security group
Reach S3 or DynamoDB without touching the internet → gateway VPC endpoint (free)

Connecting many VPCs and accounts hub-and-spoke → Transit Gateway
A private, dedicated physical line from your data center → Direct Connect (a VPC alone doesn't reach on-prem)

01Classic three-tier web app: load balancer in public subnets, app servers and the database in private subnets, so the database has no route to the internet at all
02Meeting a compliance requirement that customer data never crosses the public internet — everything on private IPs, AWS service calls via VPC endpoints
03Lift-and-shift from a data center, where you pick a CIDR that doesn't collide with the existing corporate range before joining the two with VPN or Direct Connect
04Environment isolation without spinning up extra accounts: separate dev/staging/prod VPCs so a sloppy dev security group can't reach production
05Spreading subnets across multiple AZs so losing one AZ takes out one subnet, not the whole application

01The VPC itself is free — subnets, route tables, security groups, NACLs, internet gateways, and creating a peering connection all cost nothing
02NAT gateway is the usual bill shock: an hourly charge per gateway plus a per-GB data processing charge on everything passing through, on top of normal data transfer out
03Every public IPv4 address bills hourly whether it's attached to a running resource or sitting idle — since February 2024, a forgotten Elastic IP is no longer free
04Gateway endpoints (S3, DynamoDB) are free. Interface endpoints (PrivateLink) bill hourly per AZ plus per GB, so ten services across three AZs is thirty hourly charges
05Traffic between AZs in the same Region is billed in both directions; traffic staying inside one AZ over private IPs is free