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. 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)

Quick Guidance:

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:

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:

---

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 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.

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:

The final result:

You can also undo your divisions!

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 /19s fit inside a /16 before I use a visualizer?”

For that, there’s a helpful tool: the IPTP IP Subnet 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)

---

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 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

Or you can even run it with Docker:

cd <project folder>
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

---

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 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.