VPC fundamentals
A VPC is a logically isolated section of an AWS Region in which you define your own network: IP address ranges, subnets, route tables and gateways.
What a VPC contains
Section titled “What a VPC contains”- One or more IPv4 CIDR blocks, and optionally IPv6
- Subnets, each in exactly one Availability Zone
- An implicit router, configured through route tables
- Optionally an internet gateway, egress-only internet gateway, NAT gateways, virtual private gateway or transit gateway attachments
- Network ACLs at the subnet boundary and security groups at the interface
Creating a VPC creates a main route table, a default network ACL and a default security group along with it. An internet gateway is not created; you add and attach one if the VPC needs internet access. A VPC can have at most one internet gateway attached, and an internet gateway attaches to at most one VPC.
Subnets and Availability Zones
Section titled “Subnets and Availability Zones”Each subnet lives in exactly one Availability Zone. An Availability Zone can contain any number of subnets — a three-tier application typically has a public, a private application and a private database subnet in every zone it uses.
A VPC itself spans all the Availability Zones in its Region, which is what makes zone-redundant architecture possible: distribute instances, databases and load balancer nodes across zones inside one VPC, and communicate between them over private addresses.
Availability Zone names are assigned per account, so eu-west-2a in one account is not necessarily the same physical site as eu-west-2a in another. Use the Availability Zone ID when placement has to be coordinated across accounts.
Default VPC and custom VPCs
Section titled “Default VPC and custom VPCs”Every account gets a default VPC in each Region.
Default VPC
- Every subnet has a route to an internet gateway, so every subnet is public.
- Instances launched into it receive a public IPv4 address as well as a private one.
- Convenient for experiments, unsuitable for anything you care about.
Custom VPC
- Nothing is public unless you make it so.
- You choose the address ranges, the subnet layout and the routing.
Production workloads belong in a custom VPC. If a default VPC is not needed, deleting it removes a class of accidental internet exposure.
Choosing an address range
Section titled “Choosing an address range”The primary CIDR block should come from the RFC 1918 private ranges:
- 10.0.0.0/8 — over 16 million addresses. The right default for anything that will grow, and the only range large enough to carve up cleanly across accounts, environments and Regions.
- 172.16.0.0/12 — about a million addresses. Useful when 10/8 is already spoken for by an on-premises network.
- 192.168.0.0/16 — 65,536 addresses. Common in home and small-office networks, which makes it a poor choice for a VPC that will ever connect to one over VPN.
AWS supports /16 to /28 for VPCs and subnets. A calculator such as cidr.xyz is useful for working out ranges.
Overlapping address space is the constraint that bites later: two VPCs with overlapping CIDR blocks cannot be peered, and a VPC overlapping an on-premises range cannot be reached over VPN or Direct Connect. Plan the allocations centrally before the first VPC exists — see private IPv4 address planning.
A three-tier layout
Section titled “A three-tier layout”- Web tier — public subnets, reachable on 80 and 443 from the internet.
- Application tier — private subnets, reachable only from the web tier, able to reach the database tier.
- Database tier — private subnets, reachable only from the application tier.
Each tier gets a subnet in every Availability Zone in use, so the loss of one zone removes one instance from each tier rather than an entire tier.
What you can do with a VPC
Section titled “What you can do with a VPC”- Launch instances into a subnet of your choosing
- Assign your own address ranges to each subnet
- Configure routing between subnets and to gateways
- Attach an internet gateway, NAT gateways or a virtual private gateway
- Apply network ACLs at the subnet boundary and security groups at the interface
- Extend the network to on-premises with a VPN or Direct Connect connection
Cross-zone data transfer
Section titled “Cross-zone data transfer”Data transfer between resources in the same Availability Zone using private addresses is not charged. Data transfer between Availability Zones is charged per gigabyte in each direction — considerably less than internet egress, but enough to matter for a chatty application.
Two consequences:
- Design so that a request is served within one zone where possible: a load balancer node, an application instance and a cache replica in the same zone.
- Do not compromise zone redundancy to save the charge. Multi-zone deployment is the reason the architecture survives a zone failure, and the transfer cost is the price of it.
Some services price replication differently — Amazon RDS Multi-AZ replication, for example, is not billed as cross-zone transfer. Check per service rather than assuming.
Monitor inter-zone transfer if the bill is unexpected; it is a common cause of cost that is invisible in the architecture diagram.
Sharing internet access across VPCs
Section titled “Sharing internet access across VPCs”Because an internet gateway attaches to one VPC only, several VPCs that need internet access either each get their own, or share one through a central VPC:
- Transit gateway — attach every VPC to a hub and route egress through a shared VPC’s NAT gateways. Scales to many VPCs and is the usual answer.
- VPC peering — a spoke can route through a peer’s NAT gateway. Workable for a small number of VPCs; does not scale, because peering is not transitive.
- Shared services VPC — one VPC provides egress, DNS and other common services to the rest.
- Shared subnets with AWS RAM — one VPC, several accounts deploying into it, one set of NAT gateways. See cross-account network sharing.
Detaching an internet gateway from one VPC and attaching it to another is possible; attaching it to two at once is not.