# AWS VPC Subnetting Guide: Step-by-Step Planning Made Easy with Visual Tools

## Introduction

If you've ever tried creating a custom VPC in AWS, you’ve probably run into the question:  
**"What CIDR block should I use?"**

For many DevOps/Cloud engineers, subnetting feels like a leftover from the old networking world — full of slashes, bit counts, and IP math. But in reality, subnetting is **still fundamental** when designing resilient, scalable infrastructure in the cloud.

Whether you're allocating public and private subnets, planning for multiple availability zones, or avoiding IP conflicts across environments, **CIDR block planning matters**.

Thankfully, there's a tool that takes the guesswork out of subnetting: the [Visual Subnet Calculator](https://www.davidc.net/sites/default/subnets/subnets.html). In this post, I’ll show you how to use it to design your VPC layout in minutes — with no subnetting headaches — and explain how it helps prevent common mistakes cloud engineers make when dealing with CIDRs.

Let’s dive in.

---

## Why Subnetting Still Matters in the Cloud

With the rise of serverless, managed services, and container orchestration, you might think subnetting is an old-school concern — something from the days of rack-mounted switches and spanning tree nightmares.

But that’s a dangerous assumption.

In cloud environments like AWS, subnetting is still the backbone of **network segmentation, routing, and security**. Here's why it matters:

### 1\. Every VPC Needs a CIDR Block

When you create a Virtual Private Cloud in AWS, you must assign it an IPv4 CIDR block (e.g., `10.0.0.0/16`). This CIDR defines your **IP address space**, and all your subnets must live within it.

Once set, this CIDR becomes the **foundation for routing tables, NAT behavior, and internal DNS resolution**. There's no way around it — if you miscalculate this upfront, you'll end up re-architecting later.

### 2\. Subnets Define Network Zones

Subnets are not just IP ranges — they’re **logical zones**. For example:

* Public subnets = internet-facing EC2 instances, Load Balancers
    
* Private subnets = databases, internal services
    
* Isolated subnets = services without outbound access
    

Each of these gets its own CIDR range. That means you have to plan:

* How many IPs are needed per zone
    
* How many AZs you'll spread across
    
* Whether you’ll reserve space for future growth
    

### 3\. IP Conflicts Break Everything

If your subnets overlap — or if your on-prem network overlaps with your cloud CIDR — you’ll run into **VPC peering failures, blackholed packets, or broken VPNs**.

Careless subnetting is one of the top causes of invisible infrastructure issues in hybrid and multi-cloud environments.

### 4\. Security Depends on Good Boundaries

Security groups and NACLs rely on subnet-level granularity. If your network isn’t segmented properly — say, everything is crammed into a `/16` — it becomes much harder to isolate workloads or enforce zero-trust policies.

Proper subnetting allows you to **model the principle of least privilege** at the network layer.

**In Short:**

Even in 2025, subnetting is more than a legacy skill — it’s an essential part of responsible cloud infrastructure design.

The problem is, most engineers either:

* Overestimate how much space they need (and waste IPs), or
    
* Underestimate it and get boxed in
    

This is where the Visual Subnet Calculator proves to be an invaluable tool. Before diving into how it works, though, we need to understand the fundamentals of designing a VPC and its subnets.

---

## How to Design Your VPC and Subnets (Step by Step)

Before you start clicking around in a subnet calculator, you need to answer a few critical design questions. This ensures your VPC setup is scalable, conflict-free, and aligned with your infrastructure goals.

Follow this checklist step by step — by the end, you’ll know exactly what CIDR to assign to your VPC and how to split it into subnets.

### Step 1: Will This VPC Connect to Other VPCs or Networks?

* **If Yes**: Avoid using overlapping IP ranges.
    
    * Stick to less common private ranges like `10.1.0.0/16`, `172.31.0.0/16`, or even `100.64.0.0/10` (for carrier-grade NAT).
        
    * This avoids conflicts with on-prem networks, peered VPCs, or VPNs.
        
* **If No**: You have more freedom. `10.0.0.0/16` is fine for isolated workloads.
    

### Step 2: How Many Environments Do You Need?

Typical examples:

* Dev, Staging, Prod
    
* QA, Test, Demo
    

> Multiply environments × zones to estimate subnet count.

> Example:  
> If you want **3 environments**, each spread across **3 AZs**, you’ll need **9 subnets**.

### Step 3: Do You Need Public & Private Zones?

Many architectures use:

* Public subnets → for Load Balancers, NAT Gateways
    
* Private subnets → for EC2, RDS, containers
    
* Optionally isolated subnets → for sensitive services with no outbound access
    

> Multiply again. If you want public + private, you now need:  
> **9 × 2 = 18 subnets** total.

### Step 4: Estimate the Number of Hosts per Subnet

Use this table to decide your subnet mask (`/19`, `/20`, `/21`, etc.)

AWS VPC subnet size reference (based on a /16 CIDR block)

| **Subnet Mask** | **\# of Subnets in a /16** | **Total IPs** | **Usable Hosts** |
| --- | --- | --- | --- |
| `/16` | 1 | 65,536 | **65,534** |
| `/17` | 2 | 32,768 | **32,766** |
| `/18` | 4 | 16,384 | **16,382** |
| `/19` | 8 | 8,192 | **8,190** |
| `/20` | 16 | 4,096 | **4,094** |
| `/21` | 32 | 2,048 | **2,046** |
| `/22` | 64 | 1,024 | **1,022** |
| `/23` | 128 | 512 | **510** |
| `/24` | 256 | 256 | **254** |
| `/25` | 512 | 128 | **126** |
| `/26` | 1024 | 64 | **62** |
| `/27` | 2048 | 32 | **30** |
| `/28` | 4096 | 16 | **14** |

**Quick Guidance:**

| **Use Case** | **Recommended Mask** |
| --- | --- |
| NAT Gateway, Bastion Host | `/28` or `/27` |
| Public Web App Tier | `/24` or `/23` |
| Container Clusters / Auto Scaling | `/21` or `/20` |
| Data Layer (RDS, ElastiCache) | `/24` |
| High-throughput services (e.g., EKS, Kafka) | `/19` or larger |

> Example:  
> If each subnet needs up to 500 containers or EC2s, go with `/22` or `/21`.

### Step 5: Choose a VPC CIDR that Can Fit All Your Subnets

Your VPC CIDR needs to be big enough to contain all planned subnets **with some room to grow**.

> Example: You want 20 subnets with `/21` ranges.  
> Each `/21` = 2,048 IPs  
> → 20 × 2,048 = 40,960 IPs  
> Choose at least a `/16` VPC (which provides 65,536 IPs).

### Step 6: Document Your Subnet Layout

Before creating anything in AWS, make a quick plan:

| Subnet Name | CIDR Range | AZ | Type | Purpose |
| --- | --- | --- | --- | --- |
| `dev-public-a` | 10.0.0.0/21 | `us-east-1a` | Public | Dev LB / NAT |
| `dev-private-a` | 10.0.8.0/21 | `us-east-1a` | Private | Dev app layer |
| `prod-public-a` | 10.0.16.0/21 | `us-east-1a` | Public | Prod LB / NAT |
| ... | ... | ... | ... | ... |

Now you’re ready to plug these ranges into AWS or a subnet calculator.

### Steps summary

To make an informed decision about your VPC’s CIDR and subnet layout, follow these six steps:

1. **Check for External Connectivity**  
    Will your VPC connect to on-prem, other VPCs, or VPNs?  
    → Avoid overlapping IP ranges.
    
2. **Define Your Environments**  
    How many environments (e.g., dev, staging, prod) do you need?
    
3. **Decide on Subnet Types**  
    Will you have public, private, or isolated subnets for each environment?
    
4. **Estimate Hosts per Subnet**  
    Pick subnet sizes based on expected host counts. Use the `/16`–`/28` table for guidance.
    
5. **Calculate Total IP Need**  
    Multiply the number of subnets × IPs per subnet → choose a large enough VPC CIDR.
    
6. **Document Your Plan**  
    Create a subnet table before provisioning in AWS.
    

### Example: Plan for a Multi-AZ, Multi-Env App

**Goals:**

* Environments: **Dev**, **Staging**, **Prod**
    
* Availability Zones: **3 AZs**
    
* Subnet Types: **Public** and **Private**
    
* Each subnet should support ~500 IPs
    

**Step-by-step Breakdown:**

1. **Connectivity**: Will connect to on-prem → use `10.1.0.0/16` to avoid overlap.
    
2. **Environments**: 3 total (Dev, Staging, Prod)
    
3. **Subnets per AZ**:
    
    * Each env needs **3 public + 3 private** = **6 subnets**
        
    * Total across 3 envs: **18 subnets**
        
4. **Subnet size**:
    
    * Use `/22` → gives 1,022 usable IPs (more than enough)
        
5. **IP count**:
    
    * 18 subnets × 1,022 = **18,396 IPs** → `/16` (65,534 usable) is sufficient and it has room to grow
        
6. **Document**:
    

| Subnet Name | CIDR Range | AZ | Type |
| --- | --- | --- | --- |
| dev-public-a | 10.1.0.0/22 | us-east-1a | Public |
| dev-private-a | 10.1.4.0/22 | us-east-1a | Private |
| staging-public-b | 10.1.8.0/22 | us-east-1b | Public |
| prod-private-c | 10.1.12.0/22 | us-east-1c | Private |
| ... | ... | ... | ... |

---

## Meet the Visual Subnet Calculator

Once you’ve chosen your VPC CIDR block — let’s say `10.0.0.0/16` — Your next step is to **divide it into subnets** that match your infrastructure needs. This is where most people either:

* Overestimate and waste thousands of IPs per subnet, or
    
* Underestimate and run out of space when scaling up.
    

That’s where the [Visual Subnet Calculator](https://www.davidc.net/sites/default/subnets/subnets.html) comes in — a brilliant, no-nonsense tool that mimics exactly how you plan subnets inside the AWS VPC console.

### Step-by-step Example

Imagine you’ve created a VPC with the range `10.0.0.0/16`. Now you want to split it into smaller blocks — for example, **four subnets with around 8,000 usable IPs each**.

Try This:

1. Enter `10.0.0.0` and `/16` into the Visual Subnet Calculator and click update.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1742819458865/074b3228-eb4d-4805-83cb-752decf79757.png align="center")

2. Click **Update** — this shows the full `/16` block.
    
3. Click **Divide** on the `/16` — you’ll get 2 × `/17`.
    
4. Click **Divide** again — each `/17` becomes 2 × `/18`.
    
5. Keep clicking **Divide** until you reach `/19`.
    

At the `/19` level, the calculator shows you **8 subnets**, each with:

* **8190 usable hosts**
    
* Ranges like:
    
    * `10.0.0.0 - 10.0.31.255`
        
    * `10.0.32.0 - 10.0.63.255`
        
    * ...
        
    * `10.0.224.0 - 10.0.255.255`
        

This is how it’s done in action:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1742830023113/402bf8d7-8415-4ea3-b6ad-8aab180ede0c.gif align="center")

The final result:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1742819911832/765ae174-510b-4f94-aec9-4a6bc5e1d8e7.png align="center")

You can also undo your divisions!

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1742830206794/7c86b9b9-b746-4e44-92f8-75c6379c6518.gif align="center")

**Why It’s So Useful**

* Instantly shows **usable IPs** per subnet
    
* Clearly displays **start/end IPs**
    
* Lets you **experiment interactively** with subnet sizes
    
* Supports **joining subnets** back together if you go too far
    

In short, it’s exactly what most engineers need before going into the AWS Console or writing Terraform code.

### How Can I Predict This in Advance?

You might be wondering:

> “How do I know how many `/19`s fit inside a `/16` *before* I use a visualizer?”

For that, there’s a helpful tool: the [IPTP IP Subnet Calculator](https://www.iptp.net/en_US/iptp-tools/ip-calculator/)

This tool lets you:

* Input a CIDR (like `10.0.0.0/16`)
    
* Choose the desired **subnet mask** (like `/19`)
    
* See the **exact number of possible subnets** and get **full details** like usable IPs, broadcast addresses, wildcard masks, and binary subnet masks.
    

Example:

* Input: `10.0.0.0/16`
    
* Desired subnet: `/19`
    
* Result: **8 subnets** — from `10.0.0.0/19` to `10.0.224.0/19`
    
* Each has **8190 usable IPs in theory**, but remember:
    
    > **In AWS VPCs, only 8,187 are actually usable** per subnet due to AWS reserving 5 IPs.
    

*(See IPTP calculator screenshots below for full breakdown)*

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1742906782683/f601255c-7812-4436-91a6-4c65bdfde079.png align="center")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1742906805863/e6fffcdb-31ba-4852-be3b-9efb25a6275e.png align="center")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1742820691385/d494d6af-9149-4570-8595-e277c89874ca.png align="center")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1742820712124/8675f553-363d-4c21-b3e9-7819e1c8d7f1.png align="center")

---

## Bonus: Avoiding Common Subnetting Mistakes

Using a visual subnet calculator doesn’t just make planning easier — it helps you **avoid critical mistakes** that are surprisingly common, especially when working at scale in cloud environments.

Here’s how tools like [David C’s Visual Subnet Calculator](https://www.davidc.net/sites/default/subnets/subnets.html) save you from disaster:

### 1\. Overlapping Subnets

Manually assigning CIDR blocks increases the risk of defining two subnets with overlapping ranges — something AWS won’t allow, but Terraform and cloudformation users can trip over easily.

The calculator shows you **visually distinct ranges** as you divide subnets, so you can ensure clean, non-overlapping allocations across all Availability Zones and environments.

### 2\. IP Exhaustion

You might think a `/24` is enough — until autoscaling kicks in or you add new services.

The tool shows **exact usable IPs per subnet**, so you can confidently choose between a `/23`, `/22`, `/21`, etc, without guesswork — and leave room for future growth.

### 3\. Poor Network Segmentation

Too often, people just create a `/16` VPC and drop everything into a few massive subnets. That kills visibility, auditability, and fine-grained control.

With this tool, you can **design subnet boundaries intentionally** — separating public-facing components, backend services, database layers, and isolated internal apps using CIDR boundaries that match your architecture.

### 4\. No Room for Expansion

Let’s say you deploy in two AZs today — what happens when your app needs a third?

The visual layout helps you **reserve IP space for future AZs or new environments**, even if you're not using them yet. This makes your VPC more flexible and future-proof.

---

## Want to Use Visual Subnet Calculator Offline?

[**Download it here**](https://drive.google.com/file/d/1HO1S8LSXNg1LM2boKPv200u4cyiWqVpt/view?usp=sharing)

Or you can even run it with Docker:

```plaintext
git clone https://github.com/davidc/subnets.git
cd subnets
docker build . -t subnets
docker run -d -p 5001:80 --name subnets subnets
```

Then open http://localhost and start visualizing your subnets without relying on an external site.

[Visual subnet calculator github repo](https://github.com/shahinam2/visual-subnet-calculator)

---

## Conclusion

Subnetting doesn’t have to be painful. With the right tools and a bit of planning, you can design scalable, conflict-free VPCs that support any architecture, from simple web apps to multi-environment, multi-AZ cloud platforms.

The [Visual Subnet Calculator](https://www.davidc.net/sites/default/subnets/subnets.html) is a must-have for DevOps engineers, SREs, and cloud architects. It bridges the gap between traditional networking and modern cloud practices, offering:

* Clear visual subnet breakdowns
    
* Instant feedback on usable IPs
    
* No guesswork when planning CIDR ranges
    

**Bookmark it**, share it with your team, and make it part of your VPC design workflow.