An Amazon VPC is the logically isolated network you define inside AWS to launch your resources. Its behavior comes down to five parts working together: an IP address range, subnets placed in Availability Zones, route tables that decide where traffic goes, gateways and endpoints that connect to other networks, and security controls that filter traffic. This guide covers each part in the order you need it, then gives you a checklist for tracing a connection when something fails.
What a VPC is
AWS describes a Virtual Private Cloud (VPC) as a logically isolated virtual network in which AWS resources can be launched. “Logically isolated” means your resources are separated from other customers’ networks, and you control the configuration: the network ranges, the subnets, the routes, and the connections to anything outside the VPC. New AWS accounts typically receive a default VPC in each Region. The examples below assume a custom VPC, because every setting in a custom VPC is one you chose and can see.
As an Amazon Associate I earn from qualifying purchases.
Address space: the VPC CIDR block and subnets
When you create a VPC, you assign it an IPv4 CIDR block such as 10.0.0.0/16. For IPv4 VPCs, the block size must fall between /16 and /28. Subnets are then carved out of that block. AWS’s documentation puts it plainly: “A subnet is a range of IP addresses in your VPC.”
Three rules matter at this stage:
- Each subnet resides in exactly one Availability Zone. A subnet cannot span zones, so an application meant to survive a zone failure needs subnets in at least two zones.
- Subnet ranges must not overlap with one another inside the same VPC.
- AWS reserves five IPv4 addresses in every subnet: the first four and the last one. A /24 subnet therefore has 251 usable addresses, not 256.
The following plan is illustrative, not a recommendation for any specific workload:
#1 Best Overall
| Subnet name | IPv4 CIDR | Availability Zone | Usable IPv4 addresses |
|---|---|---|---|
| public-a | 10.0.1.0/24 | us-east-1a | 251 |
| private-a | 10.0.2.0/24 | us-east-1a | 251 |
| public-b | 10.0.3.0/24 | us-east-1b | 251 |
| private-b | 10.0.4.0/24 | us-east-1b | 251 |
“Public” and “private” are routing decisions
A subnet is not a special kind of resource. It becomes public or private depending on its route table. A public subnet has a direct route to an internet gateway. A private subnet does not have that route. A separate subnet setting, “auto-assign public IPv4 address,” controls whether instances launched there receive a public address, but that setting does not create a route to the internet.
That distinction also explains why “public” should not be read as “publicly reachable.” Each configuration below has a different path in and out:
| Configuration | Route to the internet | Outbound internet access | Unsolicited inbound internet access |
|---|---|---|---|
| Public subnet | Default route to an internet gateway | Yes, for instances with a public IPv4 address or Elastic IP | Possible, if the security group allows it |
| Private subnet with NAT | Default route to a NAT gateway; no direct internet-gateway route | Yes, through the NAT gateway | Blocked; external systems cannot start a connection to these instances |
| Isolated subnet | No default route | No | No |
Route tables: how AWS chooses a path
Every subnet is associated with exactly one route table, while one route table can serve many subnets. A subnet that is not explicitly associated with a table uses the VPC’s main route table. Each route maps a destination CIDR range to a target. When more than one route matches a destination, AWS uses the most specific one, meaning the longest prefix. Every route table includes a local route for the VPC’s own CIDR block, which handles traffic between resources inside the VPC.
Rank #2
A public subnet’s route table typically looks like this:
| Destination | Target | What it does |
|---|---|---|
| 10.0.0.0/16 | local | Keeps traffic between resources in the VPC inside the VPC |
| 0.0.0.0/0 | igw-… (internet gateway) | Sends all other IPv4 traffic to the internet gateway |
Because the local route is more specific than the default route, traffic addressed to 10.0.x.x never leaves through the gateway.
Gateways and endpoints
Internet gateway
Attaching an internet gateway to a VPC does not, by itself, make an instance reachable from the internet. Three conditions must all hold:
- The instance’s subnet route table has a route to the internet gateway.
- The instance has a public IPv4 address or an Elastic IP address.
- The instance’s security group allows the required port and protocol from the source you expect.
If any one of these is missing, traffic fails, and the gateway attachment alone looks correct, which makes this the most common point of confusion for beginners.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →NAT gateway
A NAT gateway lets instances in a private subnet start outbound connections, such as downloading operating system updates, while external services cannot initiate connections back to them. The NAT gateway itself must sit in a public subnet and is assigned an Elastic IP address. The private subnet’s route table then sends 0.0.0.0/0 to the NAT gateway’s ID. Many production designs place one NAT gateway in each Availability Zone so that a zone failure does not cut off outbound access for the other zones. This adds cost, because NAT gateways bill by the hour and by the amount of data they process under AWS’s pricing model, so the number of gateways is a deliberate trade-off.
VPC endpoints
A VPC endpoint connects your VPC privately to supported AWS services without an internet gateway or NAT device, so NAT is not the only private route to AWS services. Gateway endpoints for Amazon S3 and Amazon DynamoDB add an entry to your route tables. Interface endpoints create elastic network interfaces in your subnets, and traffic reaches the service through their private IP addresses.
Rank #4
Security groups and network ACLs
AWS applies two separate filtering layers, and they behave differently:
| Control | Applies to | Stateful or stateless | Rule types | Default behavior for a new custom VPC |
|---|---|---|---|---|
| Security group | Associated resources (for example, instance network interfaces) | Stateful: return traffic for an allowed connection is automatically permitted | Allow rules only | Denies all inbound traffic; allows all outbound traffic |
| Network ACL | Everything in a subnet | Stateless: inbound and outbound directions are evaluated separately | Numbered allow and deny rules, evaluated in order | Allows all inbound and outbound traffic |
AWS states that security groups are sufficient for most cases, and that network ACLs can add a further layer of control at the subnet boundary.
Recommended Free Tools
Trace one outbound packet
Use this sequence to reason about any connection, whether it succeeds or fails:
Best Value
- Based On The Concepts The Students Have Already Learned
- Congratulate Students With A Correlated Repertoire
- Contains The Best Selections From Previous Lessons
- Standard Notation
- 48 Pages
- The source instance checks its security group’s outbound rules.
- The packet leaves the instance and passes the subnet’s network ACL outbound rules.
- The subnet’s route table selects the most specific matching route.
- If the target is an internet gateway, the gateway maps the instance’s private address to its public IPv4 address (or Elastic IP) before the packet leaves AWS.
- If the target is a NAT gateway, the NAT gateway replaces the source address with its own Elastic IP address.
- On the return path, the security group allows the reply automatically because it is stateful. The network ACL is stateless, so its inbound rules must allow the reply traffic on the ephemeral ports the response uses.
Step six is the one most often missed: a network ACL that allows the outbound request but blocks the inbound reply will break a connection that looks correctly configured everywhere else.
A checklist for failed connections
When a connection fails, check the layers in this order. Stopping at the first failing layer usually identifies the fault.
- Address range: confirm the source and destination are inside the VPC CIDR block, or that the destination is reachable through a configured route.
- Subnet and Availability Zone: confirm the resource is in the subnet you expect, and that the subnet is in the zone you intended.
- Route table association: confirm the subnet is associated with the route table you are inspecting, not the main route table by default.
- Route target: confirm the matching route points to a target that exists and is attached or running (an internet gateway, a NAT gateway, or an endpoint).
- Addressing: confirm the instance has the public IPv4 address or Elastic IP that an internet path requires, or that a private path does not need one.
- Security group: confirm the required port and protocol are allowed in the correct direction.
- Network ACL: confirm the subnet’s rules allow both the request and the stateless reply.
IPv4 and IPv6 are routed separately
A VPC can carry IPv4 and IPv6 traffic, but each address family has its own routes. A dual-stack subnet needs an IPv6 route alongside its IPv4 routes. A working IPv4 path does not prove that IPv6 traffic will flow, so test each protocol you rely on.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsWhere to practise next
AWS’s official tutorial index includes a basic VPC setup with one public subnet, and a more advanced multi-tier design with public and private subnets and NAT gateways. Both have Console and AWS CLI paths. AWS Networking Essentials is an official introduction covering VPCs, subnets, routes, gateways, and security layers. Console labels and screens change over time, so follow the current tutorial text where a button or menu name differs from what you see here.
Once the model above is comfortable, the next topics are VPC peering, transit gateways, VPN connections, traffic mirroring, and VPC flow logs. These add connectivity and visibility beyond a single VPC, and they are easier to reason about once the routing and filtering layers are clear.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
