VPC design: CIDR planning and subnet layout

Every workload you run on AWS lives inside a VPC — a Virtual Private Cloud, your own private network in the cloud. How you design that VPC — its address range, its subnets, where things sit — is another decision that is painful to change later, because resizing a network with running workloads in it is genuinely hard. Get it right up front and you never think about it again; get it wrong and you fight it for years. This lesson is VPC design: CIDR planning and subnet layout. It applies the networking fundamentals from the DevOps Foundation to AWS specifically.

What a VPC is

A VPC is a logically isolated virtual network you define within an AWS region. Inside it, you control the IP address range, the subnets, the routing, and what can reach what. Your servers, databases, load balancers and EKS nodes all live inside a VPC, with private IP addresses, isolated from other customers and (by your design) from the internet except where you allow it. A VPC is regional — it spans the Availability Zones of one AWS region (below) — and everything network-related in this module happens inside it.

CIDR: choosing your address range

When you create a VPC you give it a CIDR block — its range of private IP addresses, written like 10.0.0.0/16. The /16 means the first 16 bits are fixed, leaving 16 bits for hosts — about 65,000 addresses (10.0.0.0 to 10.0.255.255). CIDR notation from the networking lesson applies directly here.

Two planning rules matter:

• Use private ranges — 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16 (the private ranges from the networking lesson). A /16 from the 10.x space (like 10.0.0.0/16) is a common, roomy choice.
• Leave room, and do not overlap. Pick a range big enough to grow into, and — critically — one that does not overlap with your other VPCs or your on-premises network. Overlapping ranges make it impossible to connect two networks later (you cannot route between two 10.0.0.0/16s — the addresses are ambiguous). If you might ever peer VPCs or connect to an office network (the hybrid lesson), plan non-overlapping ranges now. This is the single most common VPC-design regret: two environments that cannot be connected because someone used the same CIDR for both.

So before creating VPCs, sketch an address plan: a distinct, non-overlapping range per VPC/environment, each large enough to grow, all within private space. That plan is cheap to make now and expensive to retrofit.

Availability Zones: designing for failure

An AWS region contains several Availability Zones (AZs) — physically separate data centres, close enough for low latency but isolated so a failure in one does not take out another. Designing across AZs is how you build systems that survive a data-centre failure, and it shapes your subnet layout:

• Spread across at least two (usually three) AZs. If everything is in one AZ and that AZ fails, you are down; spread across AZs and the system keeps running when one fails.
• Subnets are per-AZ. A subnet lives in exactly one AZ, so to be multi-AZ you create the same kind of subnet in each AZ (a public subnet in AZ-a, AZ-b, AZ-c; a private subnet in each too).

Multi-AZ design is a core AWS reliability practice — load balancers spread traffic across AZs, EKS runs nodes in multiple AZs, databases replicate across AZs — and it all starts with laying out subnets in each AZ.

Public and private subnets

Within your VPC's range you carve out subnets — smaller CIDR blocks (e.g. 10.0.1.0/24, giving 256 addresses) — and the most important distinction is public versus private:

• Public subnets — have a route to the internet gateway (the next lesson), so resources in them can be reached from, and reach, the internet directly. You put here only what must face the internet: load balancers, and NAT gateways. Not your application servers or databases.
• Private subnets — have no direct route to the internet. Resources here (your app servers, EKS nodes, databases) are not reachable from the internet at all; they reach out (for updates, APIs) via a NAT gateway in a public subnet (the next lesson). This is where the bulk of your workloads live.

The security principle — a direct application of least exposure — is: put as little as possible in public subnets. The internet-facing load balancer sits in the public subnet and forwards to your application in the private subnet; the app and database are never directly reachable from the internet. This dramatically reduces attack surface: an attacker cannot reach a server that has no internet route. A typical layout, per AZ, is a small public subnet (for the load balancer and NAT) and larger private subnets (for apps and data).

A concrete layout

Putting it together, a common three-AZ VPC looks like:

VPC: 10.0.0.0/16  (region eu-west-1)
  AZ-a:  public 10.0.0.0/24    private-app 10.0.10.0/24   private-data 10.0.20.0/24
  AZ-b:  public 10.0.1.0/24    private-app 10.0.11.0/24   private-data 10.0.21.0/24
  AZ-c:  public 10.0.2.0/24    private-app 10.0.12.0/24   private-data 10.0.22.0/24

Read it: one VPC, three AZs, and in each AZ a public subnet (load balancer / NAT), a private application subnet (app servers, EKS nodes), and a private data subnet (databases) — with room left in the /16 to grow. This layout gives you internet-facing entry only where needed, workloads isolated in private subnets, and resilience across three data centres. It is the shape most production AWS networks take, and — the theme of this module — you design it once, up front, with a non-overlapping CIDR plan, so you never have to unpick it later. In practice you would express this whole layout in Terraform (the Terraform modules build a reusable VPC module), so it is version-controlled and reproducible across environments.

Check your work

VPC = your isolated virtual network in an AWS region; all workloads live in it with private IPs. You control its address range, subnets, routing and reachability.

CIDR: the VPC gets a CIDR block (10.0.0.0/16 ≈ 65k addresses). Rules: use private ranges (10/172.16/192.168), and pick a non-overlapping, roomy range per VPC/environment — overlapping ranges can never be connected later (the top VPC regret). Plan the address space before creating anything.

Availability Zones: physically separate data centres in a region; spread across 2-3 AZs for resilience; a subnet lives in exactly one AZ, so create each subnet type in every AZ. Multi-AZ is core AWS reliability.

Public vs private subnets: public = has a route to the internet gateway (put only load balancers + NAT here); private = no internet route (apps, EKS nodes, databases — reach out via NAT). Principle: put as little as possible in public subnets — the LB is public, the app/DB are private and unreachable from the internet (minimal attack surface).

Typical layout: one VPC, 3 AZs, per AZ a public + private-app + private-data subnet, room to grow, expressed in Terraform. Designed once up front with a non-overlapping CIDR plan.

Practice

1. Explain what a VPC is and why every AWS workload lives in one.
2. Choose a VPC CIDR and explain why it must be private, roomy, and non-overlapping with other networks.
3. Explain the VPC-design regret of overlapping CIDR ranges and what it prevents.
4. Explain why you spread subnets across multiple Availability Zones, and that a subnet is per-AZ.
5. Explain the difference between public and private subnets and what belongs in each.
6. Sketch a three-AZ subnet layout for a 10.0.0.0/16 VPC with public, app and data tiers, and justify it.

Official documentation

• AWS — VPC user guide — VPCs, subnets and IP addressing.
• AWS — VPC design & subnet sizing — Choosing CIDR blocks and subnets.
• AWS — Regions and Availability Zones — Designing across AZs for resilience.

Next: route tables, internet and NAT gateways.