Amazon VPC Explained: Subnets, Route Tables and Gateways for Beginners

Almost every AWS architecture you will ever build sits inside an Amazon Virtual Private Cloud (VPC). EC2 instances, RDS databases, load balancers, ECS tasks and Lambda functions that need private access all live in one. Yet the VPC is also the part of AWS that confuses beginners the most, because it hides a whole network behind a few console screens.

This guide explains the moving parts in plain English: what a VPC is, how subnets and route tables work together, what the internet gateway and NAT gateway really do, and the mistakes that cause most "my instance can't reach the internet" tickets.

What a VPC is

A VPC is your own isolated network inside an AWS Region. You choose its private IP range, split it into smaller networks (subnets), and decide which of those can talk to the internet and how. Nothing enters or leaves a VPC unless you create a path for it.

Every new AWS account comes with a default VPC in each Region. It is convenient for experiments, because every subnet in it is public, but it is not how production networks are designed. Real workloads use a custom VPC with a deliberate split between public and private subnets.

CIDR blocks: choosing the address range

When you create a VPC you give it an IPv4 range in CIDR notation, for example 10.0.0.0/16. The number after the slash says how many bits are fixed. A /16 fixes the first 16 bits, leaving 16 bits for hosts: 65,536 addresses. A /24 leaves 8 bits: 256 addresses.

• VPC sizes range from /16 (largest) to /28 (smallest).
• Use private ranges from RFC 1918: 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16.
• Plan ahead: if you will ever connect this VPC to another VPC or to your office network, the ranges must not overlap. Overlapping CIDRs are the number one reason peering and VPN projects stall.

AWS reserves five addresses in every subnet (the network address, the VPC router, DNS, one reserved for future use, and the broadcast address), so a /24 subnet gives you 251 usable IPs, not 256.

Subnets: slicing the VPC by Availability Zone

A subnet is a slice of the VPC's range that lives in exactly one Availability Zone. That detail matters: to survive the loss of a data center, you spread resources across subnets in at least two AZs.

A typical small design looks like this:

Here is the key insight: a subnet is not public or private by itself. There is no "public" checkbox. A subnet becomes public only because of the route table attached to it.

Route tables: the real switch

Each subnet is associated with one route table. A route table is a list of rules that say "traffic for this destination goes to that target". Every route table starts with a local route that lets everything in the VPC reach everything else in the VPC:

Destination     Target
10.0.0.0/16     local

To make a subnet public, its route table needs one more line that sends all other traffic to an internet gateway:

Destination     Target
10.0.0.0/16     local
0.0.0.0/0       igw-0abc123

Private subnets get a different route table. Instead of the internet gateway, their default route points at a NAT gateway (if they need outbound internet) or nowhere at all (if they should be completely isolated).

AWS picks the most specific route that matches a destination. A packet for 10.0.12.7 matches both 10.0.0.0/16 and 0.0.0.0/0, and the /16 wins because it is more specific.

Internet gateway: the door to the internet

An internet gateway (IGW) is a horizontally scaled, highly available component that you attach to a VPC. It does two things: it is a target for routes to the internet, and it performs one-to-one translation between an instance's private IP and its public IP.

For an EC2 instance to be reachable from the internet, three things must all be true:

1. The instance has a public IPv4 address or an Elastic IP.
2. Its subnet's route table sends 0.0.0.0/0 to the internet gateway.
3. Its security group and the subnet's network ACL allow the traffic.

Miss any one and the connection times out. This three-part checklist solves a surprising share of real-world networking incidents.

NAT gateway: outbound only

Private instances often need to reach the internet without being reachable from it: downloading OS patches, calling a payment API, pulling container images. A NAT gateway handles that.

• You create it in a public subnet and give it an Elastic IP.
• The private subnets' route tables send 0.0.0.0/0 to the NAT gateway.
• The NAT gateway forwards the traffic out through the internet gateway, replacing the private source IP with its own Elastic IP. Replies come back the same way. New inbound connections from the internet cannot start.

NAT gateways are zonal. For high availability, create one per AZ and point each private subnet at the NAT gateway in its own AZ. They also cost money every hour plus a per-GB processing charge, so many teams pair them with VPC endpoints to keep S3 and DynamoDB traffic off the NAT entirely.

Follow a packet: a worked example

An app server in private-a calls api.stripe.com:

1. DNS resolves the name to a public IP using the VPC's DNS resolver.
2. The packet leaves the instance. Its security group allows outbound HTTPS.
3. The subnet's network ACL allows outbound port 443 and the ephemeral return ports.
4. The private route table matches 0.0.0.0/0 → nat-0123.
5. The NAT gateway in public-a rewrites the source address to its Elastic IP and sends it to the internet gateway via the public route table.
6. The response returns to the NAT gateway, which hands it back to the instance.

If any hop is missing, you get a timeout, not an error message. That is why VPC troubleshooting is mostly about checking each hop in order.

Security groups and network ACLs in one paragraph

Two firewalls protect traffic in a VPC. Security groups attach to network interfaces, only have allow rules and are stateful (return traffic is allowed automatically). Network ACLs attach to subnets, have numbered allow and deny rules and are stateless (you must allow return traffic explicitly, including ephemeral ports 1024–65535). We cover the difference in depth in Security Groups vs Network ACLs.

Common VPC mistakes

• Instance in a "public" subnet without a public IP. The route is right, but there is no address for the internet gateway to translate to.
• NAT gateway placed in a private subnet. It then has no route to the internet gateway and silently drops traffic.
• One NAT gateway for all AZs. Works until that AZ has a problem, and you pay cross-AZ data charges every day.
• Overlapping CIDRs. Painful to fix later because you cannot change a VPC's primary range.
• Deleting the default VPC. Some tools and console wizards assume it exists. You can recreate it, but it is easier not to delete it.

Practice it in a real AWS account

Reading about route tables helps, but building one is what makes it stick. In Cloud Arena's free lab VPC with Public and Private Subnets you create the VPC, subnets, internet gateway and route tables yourself in a real AWS account, and every step is checked automatically. When you are ready for more, try Security Group vs NACL or the break-fix incident Private App Servers Lost Internet Access, where you diagnose a broken NAT path under time pressure.

FAQ

Is a VPC free?

Creating a VPC, subnets, route tables and an internet gateway costs nothing. You pay for things that process traffic or hold addresses: NAT gateways, public IPv4 addresses, VPC endpoints of the interface type, VPN connections and data transfer.

How many subnets should I create?

At minimum one public and one private subnet in each of two Availability Zones. Many teams add a third tier of isolated subnets for databases with no route to the internet at all.

Can I change a VPC's CIDR later?

You cannot change the primary CIDR, but you can add secondary CIDR blocks. Planning a large enough, non-overlapping range up front saves a lot of pain.

What is the difference between a VPC and a subnet?

The VPC is the whole network in a Region. A subnet is a slice of it in one Availability Zone, and its route table decides whether it is public or private.