Published on · Updated on
Rewrote the configuration reference with current AWS routing, IPv4 and IPv6, NAT gateway, endpoint, security, DNS, cost, and troubleshooting guidance.
Amazon Virtual Private Cloud (VPC) is the network boundary for many AWS workloads. Good VPC configuration starts with an address plan and a clear request path, then adds only the gateways, routes, endpoints, and controls that the workload needs.
This guide is a configuration and design reference. It explains how to reason about CIDR blocks, subnets, route tables, IPv4 and IPv6, security groups, network ACLs, NAT gateways, endpoints, private connectivity, and operational checks. For a bounded console lab, use the companion AWS VPC tutorial for beginners.
A VPC is a logically isolated network in one AWS Region. It spans the Region's Availability Zones, while each subnet belongs to exactly one Availability Zone. You choose the VPC address ranges and decide how resources reach other subnets, AWS services, on-premises networks, and the internet.
A VPC automatically includes a main route table, a default security group, a default network ACL, and a DHCP option set. Those defaults are starting points, not proof that a workload has the right security posture. See AWS's VPC basics for the current resource model.
The VPC console, AWS CLI, APIs, CloudFormation, and Terraform manage the same objects. A useful mental model is:
A VPC provides isolation and programmable network controls. It does not make every resource private, encrypt every application protocol, or provide high availability by itself. A resource can be reachable from the internet when it has an internet path, a public IPv4 or IPv6 address, and permissive security rules. Resilience requires capacity and dependencies in more than one Availability Zone where the workload needs it.
There is no universal VPC-per-application or VPC-per-environment rule. Separate VPCs when isolation, account ownership, address-space boundaries, compliance, or independent network administration justify the operational cost. Keep workloads together when they need frequent private communication and can share a security and routing boundary safely.
Record the decision and check for overlapping CIDRs before creating a VPC. Overlap makes later peering, Transit Gateway, and hybrid routing difficult or impossible. AWS lists a default quota of five VPCs per Region, and that quota is adjustable; it is not a design limit or a reason to create exactly five. Review the current Amazon VPC quotas for the Region and account.
A shared-services VPC can be useful for selected central services, but it adds routing, ownership, and failure-domain decisions. Use a hub such as Transit Gateway when many networks need controlled connectivity; use peering for a small number of direct, non-transitive relationships.
Think of a VPC as an addressable network boundary in AWS. Subnets are smaller ranges placed in Availability Zones. Route tables decide the next hop. An internet gateway provides a path to and from the public internet when the resource has an appropriate public address. A NAT gateway lets private IPv4 resources initiate outbound connections without accepting unsolicited inbound connections. Security groups and network ACLs then filter the traffic.
“Public subnet” and “private subnet” describe routing, not a permanent security classification. A subnet is public when its route table has a route to an internet gateway. A subnet is private when it has no direct route to an internet gateway; it may still reach the internet through a NAT gateway, reach AWS services through endpoints, or reach other networks through a VPN or Transit Gateway.
Choose the simplest path that meets the workload's communication and isolation requirements. A private subnet with no NAT is a valid design when its resources do not need public egress. For workload tier placement and the request paths between presentation, application, and data services, see the AWS multi-tier architecture guide.
A VPC's primary IPv4 CIDR must use a netmask between /16 and /28. See AWS's VPC CIDR block guidance for the current range and association rules. For example, 10.20.0.0/16 contains 65,536 addresses, a /20 contains 4,096, and a /24 contains 256. Those are total addresses, not all assignable host addresses. In an IPv4 subnet, AWS reserves the first four and last address, leaving 251 usable addresses in a /24. Read the current subnet sizing rules before choosing small subnets.
Pick a range that does not overlap connected corporate networks, other VPCs, or likely future networks. Use additional non-overlapping VPC CIDR blocks or Amazon VPC IP Address Manager (IPAM) when one primary block is insufficient, subject to the current quotas and allocation rules. A /16 is common, but it is not automatically correct; size it from actual subnet counts, service scaling, and address consumption.
Each subnet must fit inside the VPC CIDR and must not overlap another subnet in the VPC. Place corresponding public, application, and data subnets in each Availability Zone where the workload needs redundancy. A subnet can use one route table at a time, while one route table can serve several subnets.
Subnets do not span Availability Zones. For a multi-AZ application, create comparable subnets in at least two Zones and place compute and dependencies according to their own availability behavior. A load balancer and Auto Scaling group can distribute capacity, but they do not make a single-AZ database or gateway resilient automatically.
IPv4 and IPv6 routes are evaluated separately. A 0.0.0.0/0 route does not cover IPv6; add a ::/0 route when the subnet needs IPv6 internet connectivity. Public IPv6 addresses are globally unique. For outbound-only IPv6 access, use an egress-only internet gateway, which is stateful and blocks internet-initiated connections. Native IPv6 does not use an IPv4 NAT gateway; NAT64 is a separate option for IPv6 clients that need IPv4 destinations.
Security groups are stateful allow rules attached to a resource's network interface. They evaluate all matching rules and cannot express an explicit deny. Network ACLs apply to the whole subnet, support allow and deny rules, and evaluate entries in ascending rule-number order. They are stateless, so return traffic must be allowed separately. Use security groups as the primary resource control and NACLs as deliberate subnet guardrails. See AWS's security group guidance and NACL examples.
When creating a subnet, specify the VPC, Availability Zone, and a non-overlapping IPv4 CIDR. Optionally associate an IPv6 CIDR. Create separate custom route tables for public and private roles, then associate each subnet explicitly. The main route table remains the implicit association for subnets without a custom association, so leaving it unchanged and making associations explicit can prevent accidental exposure.
An internet gateway is a VPC attachment and a route target; it does not by itself make every subnet public. Attach it to the VPC, then add 0.0.0.0/0 to a public subnet route table for IPv4 and, when needed, ::/0 for IPv6. A resource also needs a public address and rules that allow the intended traffic. AWS describes the full internet gateway path.
Every route table includes a local route for communication within the VPC. Other routes specify a destination and target, such as an internet gateway, NAT gateway, endpoint, peering connection, Transit Gateway, or virtual private gateway. AWS selects the most specific matching route. Check both directions: a forward route is not enough when the return path is missing.
Do not create one route table per subnet by habit. Share a table when the subnets have the same destinations, and separate it when their required paths differ. See AWS's route table guidance.
A public NAT gateway translates outbound IPv4 connections from private resources. A zonal public NAT gateway is created in a subnet and needs an Elastic IP and a public route to an internet gateway. Private subnet route tables point 0.0.0.0/0 to the NAT gateway. The NAT gateway does not accept unsolicited inbound connections.
For zonal NAT gateways, placing one in each active Availability Zone and routing locally avoids a cross-zone dependency. AWS also provides regional NAT gateways, which can expand across Zones based on workload presence and do not require a public subnet. They have different routing and billing behavior; use the mode that matches the workload and Region. A private NAT gateway is for private connectivity paths, not general internet egress.
NAT gateways incur an hourly charge while provisioned and a per-gigabyte processing charge, in addition to applicable data transfer and public IPv4 charges. Gateway endpoints can avoid NAT processing for supported S3 and DynamoDB paths. Check the current Amazon VPC pricing before enabling a gateway for a short-lived environment.
Gateway endpoints provide private access to Amazon S3 and DynamoDB through route-table entries and have no additional endpoint hourly or data-processing charge. Interface endpoints use private network interfaces and AWS PrivateLink for supported AWS services or endpoint services. They need security group rules, subnet placement, DNS decisions, and incur hourly per-AZ and data-processing charges.
Endpoint policies can limit access, but they do not replace IAM or service policies. For interface endpoints that use private DNS, enable both VPC DNS support and DNS hostnames. Check the current VPC endpoint types and behavior before assuming an endpoint supports a service or connectivity path. For diagnosis, use the site's VPC endpoint connectivity troubleshooting guide.
Amazon Route 53 Resolver is available inside a VPC. The enableDnsSupport attribute controls resolver-based DNS, while enableDnsHostnames controls public DNS hostnames for resources that have public addresses. Private hosted zones and interface endpoint private DNS require both settings enabled. If workloads use custom DNS servers, document the forwarding path instead of assuming that AWS private names will resolve automatically. See AWS VPC DNS attributes.
VPC peering provides private, point-to-point connectivity between two VPCs, including across accounts or Regions where supported. Both sides need non-overlapping address ranges and routes to the peer CIDR. Peering is not transitive: a VPC connected to A and B does not automatically route between A and B. Add DNS resolution settings only when the name-resolution path requires them.
A Site-to-Site VPN provides encrypted tunnels between a customer gateway and AWS. A virtual private gateway is suitable for a VPC-specific connection; a Transit Gateway can centralize multiple VPC and VPN attachments. Direct Connect supplies a dedicated network connection through a Direct Connect location, but it still requires deliberate routing and does not automatically provide encryption.
Transit Gateway can connect many VPCs and hybrid attachments through separate Transit Gateway route tables. Design which attachments associate with which table and which routes propagate. Avoid treating propagation as universal access: route-table associations and propagated or static routes determine the actual path. The site's Transit Gateway route table guide covers those relationships in more detail.
Terraform, CloudFormation, and the AWS CLI can all create VPC resources. The tool matters less than keeping the CIDRs, subnet-to-AZ map, route associations, endpoint choices, and security rules reviewable. Use dependency-aware resources and tags so an operator can identify ownership and remove a test environment safely.
Parameterize Region, Availability Zones, CIDRs, and optional gateways. Review a plan for unintended public routes, public IP assignment, route-table replacement, endpoint costs, and destructive changes. Keep state in a protected backend appropriate for the team, with access controls and recovery procedures. Do not assume a reusable module's defaults match the required security boundary.
After applying a change, inspect the VPC resource map, route table associations, endpoint state, DNS attributes, and flow logs. Test a representative allowed path and a deliberately denied path where safe. A successful infrastructure plan proves that resources were created; it does not prove that application traffic can complete.
VPC Flow Logs can publish IP-flow records for a VPC, subnet, or network interface to CloudWatch Logs or S3. They are useful for finding rejected traffic and confirming which interface saw a path, but they are aggregated records rather than a packet capture or application-latency measurement. Account for log storage and query costs and protect the destination.
VPC, subnet, route, endpoint, address, and network-interface quotas vary by resource and account. Some are adjustable. Use Service Quotas and the current VPC quota reference when a deployment approaches a limit; do not hard-code a historical default into a design.
Keep chatty resources in appropriate Availability Zones when that reduces cross-zone transfer, use endpoints for supported service paths, and choose compute based on measured network and application needs. A NAT gateway, endpoint, firewall, load balancer, or Transit Gateway each adds a different cost and failure mode. Measure before adding a component for a generic performance claim.
Do not open SSH or RDP to 0.0.0.0/0 as a diagnostic shortcut. Use a private access path or a tightly scoped source and remove temporary rules promptly.
Revisit the design when address space, connected networks, workload placement, or service dependencies change. For a first build with safe cleanup, continue with the beginner VPC setup tutorial, then return here when the network becomes a shared design boundary.