Quick Summary
- A VPC is your own isolated virtual network in AWS, defined by a private CIDR block like 10.0.0.0/16
- Subnets live in one Availability Zone each; a route table decides whether a subnet is public (Internet Gateway) or private (NAT Gateway or local only)
- Two firewalls protect resources: stateful security groups at the instance level, and stateless network ACLs at the subnet level
The Walled Office Floor Analogy
Imagine AWS as a giant shared skyscraper full of tenants. You don't get the whole building -- you rent your own private, walled office floor. Inside that floor, you decide everything: how the rooms are laid out, which doors open onto the public lobby, and exactly who is allowed to walk through each door. The other tenants on other floors can't see in. That walled floor is an Amazon VPC (Virtual Private Cloud).
Technically, a VPC is your own logically isolated virtual network inside AWS, where you
launch resources like EC2 instances. The very first thing you decide is the floor's footprint: a
CIDR block of private IP addresses, for example 10.0.0.0/16. AWS strongly
encourages RFC 1918 private space (10.0.0.0/8, 172.16.0.0/12, or
192.168.0.0/16), because these addresses are meant for internal use.
You then divide the floor into rooms, called subnets. Each subnet lives in exactly one Availability Zone (a physically separate data center), which is how you build resilience: put a copy of your app in a subnet in one AZ and another in a second AZ, and a single data-center failure won't take you down. Whether a room has a door to the public lobby is decided not by the room itself, but by its route table -- the floor plan that says where traffic from that room is allowed to go.
That single idea -- a route table makes a subnet public or private -- is the heart of VPC networking, and it trips up almost every beginner. Let's make it visual.
The Shape of a VPC
Here is a small VPC 10.0.0.0/16 with one public subnet and one private subnet, an Internet Gateway, and a NAT Gateway. Notice how the route tables -- not the subnets themselves -- decide who can reach the internet:
Build-a-VPC: Public or Private?
Change each subnet's route table and watch how its reachability flips. The route table -- not the subnet -- is what makes a subnet public, outbound-only, or fully private.
Subnet A
Subnet B
Security Group
- Stateful — return traffic is auto-allowed
- Attaches at the instance / ENI level
- Allow rules only (no explicit deny)
Network ACL (NACL)
- Stateless — you must allow return traffic
- Attaches at the subnet level
- Numbered allow and deny rules, in order
Try it above: flip Subnet B's route from NAT Gateway to Internet Gateway and it
becomes public; flip it to local only and it goes completely dark to the internet. The EC2
instance never moved -- only the route table changed. That is the single most important mental
model for VPC networking.
The Core Building Blocks
The VPC and its CIDR block
When you create a VPC you give it a private IP range using a CIDR block, such as
10.0.0.0/16 (65,536 addresses). This is the total address space your whole floor can use.
Pick it generously but thoughtfully -- it should not overlap with your on-premises networks or other
VPCs you may later connect, because overlapping ranges break peering and VPNs. The VPC itself spans an
entire AWS Region.
Subnets and Availability Zones
You slice the VPC's CIDR into smaller subnets, for example 10.0.1.0/24 and
10.0.2.0/24. Each subnet lives in exactly one Availability Zone. Spreading
subnets across two or three AZs is how you survive a data-center outage. A subnet is "public" or
"private" purely because of the route table it is associated with -- there is no checkbox on the subnet
itself that says public.
Route tables, Internet Gateway, NAT Gateway
A route table lists where traffic for each destination should go. Add
0.0.0.0/0 → Internet Gateway (IGW) and the subnet becomes public: resources with a
public or Elastic IP can be reached from and reach the internet. Point that same default route at a
NAT Gateway instead, and private-subnet resources get outbound-only
internet (great for downloading updates) while staying unreachable from outside.
Two firewalls: Security Groups and NACLs
Security groups are stateful, attach at the instance/ENI level, and have allow rules only -- if you allow inbound traffic, the return traffic is allowed automatically. Network ACLs (NACLs) are stateless, attach at the subnet level, evaluate numbered rules in order, and support both allow and deny -- so you must explicitly permit return traffic. Most teams rely on security groups and keep NACLs as a coarse backstop.
VPC Patterns in the Real World
A handful of standard layouts cover the vast majority of real deployments. Here are three you will meet again and again:
Public web, private database
A classic two-tier app: the web servers sit in a public subnet (route to IGW) so users can reach them, while the database sits in a private subnet with no inbound internet route. The database reaches out for patches through a NAT Gateway. This keeps your data tier off the public internet entirely.
Private fleet behind NAT
A batch-processing or worker fleet that needs to pull from the internet (container
images, OS updates, S3) but should never accept inbound connections. Put it in private subnets whose
route table sends 0.0.0.0/0 to a NAT Gateway. Outbound works; inbound from
the internet is impossible.
Connecting VPCs together
Need two VPCs to talk? VPC Peering links two of them directly. For many VPCs, a Transit Gateway acts as a central hub. And VPC endpoints let private subnets reach AWS services (like S3 or DynamoDB) without traversing the internet at all -- traffic stays on the AWS backbone.
Common VPC Mistakes
These few mistakes account for most "why can't my instance reach the internet?" support tickets:
Expecting a NAT Gateway to allow inbound
A NAT Gateway only enables outbound connections from private subnets. It does not, and cannot, let the internet initiate a connection to your instance. If you need inbound access, you need a public subnet with an Internet Gateway and a public/Elastic IP (or a load balancer in a public subnet) -- not a NAT Gateway.
Public subnet, but no public IP
A subnet can have a perfect 0.0.0.0/0 → IGW route and the instance still won't be
reachable if it has no public or Elastic IP. The IGW only works for instances that
actually have a public address. Enable auto-assign public IP on the subnet, or attach an Elastic IP,
or front it with a public load balancer.
Forgetting NACLs are stateless
Because security groups are stateful, beginners assume NACLs behave the same way. They don't. A NACL is stateless: if you allow inbound on a port, you must also add an outbound rule for the ephemeral return ports, or the reply is silently dropped. This causes baffling "connection hangs" that security groups would never produce.
Elastic IPs and Private Service Access
A few more pieces round out the picture. An Elastic IP is a static public IPv4 address you own and can attach to an instance or NAT Gateway -- handy when you need an address that doesn't change. For reaching AWS services privately, VPC endpoints let a private subnet talk to services like Amazon S3 or DynamoDB over the AWS network instead of the public internet, which is both more secure and often cheaper than routing through a NAT Gateway.
Putting It All Together
Designing a VPC is really just answering three questions for each tier of your application: What address range? (the CIDR block and subnets), Who can it reach, and who can reach it? (the route table, plus IGW vs NAT), and What traffic is allowed? (security groups and NACLs). Resilience comes from spreading subnets across Availability Zones.
The bottom line: a VPC is your private floor in the AWS skyscraper. Subnets are the rooms, route tables are the floor plan that decides which rooms have a door to the public lobby, gateways are those doors, and security groups and NACLs are the guards checking who passes. Once that picture clicks, the rest of AWS networking falls neatly into place.
Frequently asked questions about AWS VPC
What is an AWS VPC?
An Amazon VPC (Virtual Private Cloud) is your own logically isolated virtual network inside AWS where you launch resources such as EC2 instances. You define its private IP range with a CIDR block (for example 10.0.0.0/16), then divide it into subnets, attach gateways, and control traffic with route tables and firewalls.
What is the difference between a public and private subnet?
A public subnet has a route table entry sending 0.0.0.0/0 to an Internet Gateway, so resources with a public or Elastic IP can be reached from and reach the internet. A private subnet has no direct route to an Internet Gateway, so its resources are not reachable from the internet; they can still make outbound connections through a NAT Gateway.
What is the difference between an Internet Gateway and a NAT Gateway?
An Internet Gateway (IGW) provides two-way internet connectivity for resources that have a public or Elastic IP, making a subnet public. A NAT Gateway lets resources in a private subnet make outbound-only connections to the internet (for example to download updates) without allowing any inbound connections from the internet.
What is the difference between a security group and a network ACL?
A security group is stateful, operates at the instance or ENI level, and supports allow rules only; return traffic is automatically allowed. A network ACL (NACL) is stateless, operates at the subnet level, evaluates numbered rules in order, and supports both allow and deny rules; you must explicitly allow return traffic.
What is a route table in a VPC?
A route table is a set of rules that decides where traffic from a subnet is directed. Each subnet is associated with one route table. Adding a route for 0.0.0.0/0 pointing to an Internet Gateway makes the subnet public; pointing it at a NAT Gateway gives outbound-only access; with only the default local route, the subnet stays fully private.
Try the NAT gateway lab
You just learned how route tables, gateways, and firewalls shape a VPC. Now build the same pattern from routers, a NAT gateway and firewall rules, and run a trace for every path to see exactly what can reach what, and where each blocked packet stops.
Launch the NAT gateway lab →