VPC Networking Basics: Subnets, Route Tables and Gateways

A Private Network You Draw Before You Build

A virtual private cloud is a software defined network that belongs to your account. Inside it you choose the address range, carve it into subnets, decide which subnets can reach the internet, and control what may talk to what. Nothing enters or leaves except through a path you created.

Most people meet a VPC by accident, because their provider made a default one and the first server landed in it. That works until the day it does not: a database that should never have had a public address, a second region that overlaps the first, a subnet with no room left to grow.

Four concepts do almost all the work: the address plan, subnets, route tables and gateways. Understand those and the provider specific vocabulary becomes a translation exercise rather than a new subject.

Start With the Address Plan

A VPC is created with a private address block written in CIDR notation, drawn from the ranges reserved for private use in RFC 1918: 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16.

The prefix length after the slash says how many bits are fixed. A smaller number means a larger network: a /16 holds far more addresses than a /24. You cannot usefully change the block after resources exist inside it, so pick generously at the start. Address space inside a VPC costs nothing.

The rule that saves the most pain later: make every network your organisation owns non-overlapping. Two VPCs that both use 10.0.0.0/16 can never be peered, connected by a transit gateway or joined to an office network over a tunnel. Keep a written register, give each environment and region its own slice, and treat it as a permanent record.

Leave room inside each block too. A subnet is carved from the VPC range and cannot be resized on most platforms, so allocate a subnet larger than today's server count. Providers also reserve a few addresses in every subnet for the gateway, DNS and internal use, which matters when you size very small subnets.

Subnets and Where They Live

A subnet is a slice of the VPC range that is tied to a location. On AWS and Azure a subnet belongs to a single availability zone, so spreading a workload across zones means creating a subnet in each. On Google Cloud the model differs: the VPC itself is global and each subnet is regional, covering every zone in that region.

The conventional layout uses pairs. For each zone, one public subnet and one private subnet. Load balancers, bastion hosts and anything that must accept connections from the internet go in the public one. Application servers, databases, caches and internal services go in the private one.

Nothing about a subnet is inherently public or private. The words describe its route table, which is the next concept. A "public subnet" is simply a subnet whose default route points at an internet gateway.

Plan for three layers if the workload warrants it: a public tier for ingress, an application tier, and a data tier that has no route to the internet at all. The separation costs nothing and makes a later security review much shorter. The regions and zones article covers how many zones you should actually spread across.

Route Tables Decide Everything

Every subnet is associated with exactly one route table. A route table is an ordered set of rules matching a destination prefix to a target, and the most specific matching prefix wins.

Two entries do most of the work. The first is the local route covering the whole VPC range, which is created automatically and cannot be removed; it is what lets instances in different subnets reach each other without configuration. The second is the default route, written as 0.0.0.0/0, which catches everything not matched by a more specific rule.

Where the default route points is the entire difference between a public and a private subnet:

A common early mistake is giving a private subnet a default route to an internet gateway and assuming the instances stay private because they have no public address. They do stay unreachable from outside, but the intent is now expressed in two places instead of one, and the next person who attaches a public address gets a surprise.

The Gateways and What They Cost

An internet gateway is a logical attachment to the VPC. It is generally free, it does not become a bottleneck, and it only moves traffic for instances that hold a public address.

Network address translation is the piece that lets private instances reach outward. A managed NAT gateway is the low effort option: highly available within a zone, no maintenance, and billed both for the hours it exists and for the data it processes. That second meter is the reason NAT appears unexpectedly high on bills, especially where private instances pull large container images or back up to a public endpoint.

Two ways to reduce it. Use private endpoints or private service access so traffic to the provider's own storage and APIs never leaves the private network. And place one NAT per zone rather than routing every zone through one, since cross-zone traffic is usually metered as well.

A self-managed NAT instance, a small VM with forwarding enabled, is cheaper and is a legitimate choice for non-critical environments. It is also a single machine you now patch and monitor, and it becomes a single point of failure for every outbound connection in the subnet.

IPv6 changes the shape here. Because addresses are plentiful, instances receive globally routable ones and there is no translation involved; to get outbound-only behaviour you use an egress-only gateway instead. The IPv6 article covers the differences per provider.

The Same Ideas, Different Words

The developer clouds deliberately expose less. A DigitalOcean VPC or a Hetzner network gives you a private range and attaches servers to it, with no route table to edit, which is exactly right for a stack of a few machines. The private networking article covers that simpler model, and the firewalls and security groups guide covers the filtering layer that sits on top everywhere.

If you are learning on AWS, the VPC user guide is the canonical description, and the Google Cloud VPC documentation is worth skimming alongside it purely to see how differently a global network model reads. An AWS account is the usual place to practise, since it exposes every one of these objects explicitly, and the AWS and Google Cloud comparison covers the wider architectural differences.

Key Takeaways

• Choose a private address block once, make it large, and never let two networks in your organisation overlap.
• Subnets are location bound. On AWS and Azure that means per zone; on Google Cloud, per region.
• Public and private are properties of the route table, not of the subnet itself.
• Internet gateways move traffic for hosts with public addresses; NAT provides outbound-only access and is metered on data as well as time.
• Give the data tier no default route at all, and reach provider services through private endpoints where they exist.
• Every provider implements the same four ideas; only the vocabulary and the number of exposed knobs change.