DEV Community: Kristoffer Hatland

Subnet Planning for Kubernetes: Why Most Calculators Are Wrong

Kristoffer Hatland — Mon, 09 Mar 2026 08:26:51 +0000

When planning networks for Kubernetes clusters, many engineers reach for a simple subnet calculator.

Something like:

10.0.0.0/24 → 256 addresses

Looks simple enough.

But in practice, cloud networking rarely behaves that way.

After running into subnet exhaustion issues multiple times while deploying Kubernetes clusters, I realized that traditional subnet calculators miss several critical details — especially in cloud environments like AWS, Azure, and Google Cloud.

Let’s walk through why.

The Hidden Problem With Subnet Planning

Most subnet calculators assume a very simple model:

Total IPs = 2^(32 - prefix)

So a /24 network gives you:

256 total IP addresses

Subtract the network and broadcast addresses:

254 usable addresses

This model works fine in traditional networking.

But cloud providers reserve additional addresses, and Kubernetes can consume IP space far faster than expected.

Cloud Platforms Reserve More IPs

Each cloud platform reserves several IP addresses in every subnet.

For example, Azure reserves five IP addresses:

Address	Purpose
.0	Network address
.1	Default gateway
.2	Azure DNS
.3	Reserved
Last	Broadcast

That means a /24 subnet actually provides:

256 - 5 = 251 usable addresses

AWS and GCP have similar reservation models.

This already makes many traditional subnet calculators inaccurate for cloud deployments.

Kubernetes Changes the Game

The real challenge appears when running Kubernetes clusters.

Depending on the networking model, each pod may consume an IP address from the subnet.

Examples:

Platform	Networking model
AWS EKS	VPC CNI
Google GKE	VPC-native clusters
Azure AKS	Azure CNI

In all these cases, pod IPs come from the underlying network, which means subnets must handle both nodes and pods.

This causes IP consumption to grow quickly as clusters scale.

Example: AKS Subnet Planning

Let’s walk through a simple example.

Imagine an AKS cluster with:

Parameter	Value
Nodes	20
Pods per node	30

Required pod IPs:

20 × 30 = 600

Add node IPs:

Add Azure reserved addresses:

Total IPs required:

625

A /24 subnet only provides 251 usable addresses, so it would run out of space very quickly.

Even a /23 may not leave much room for scaling.

This is why many teams allocate much larger ranges such as:

/20
/19

especially when clusters are expected to grow.

How Large Should a Kubernetes Subnet Be?

One of the most common questions engineers ask is:

How large should the subnet be for a Kubernetes cluster?

The answer depends on three main factors:

number of nodes
maximum pods per node
networking model (CNI plugin)

A simple formula is:

required_ips = (nodes × pods_per_node) + nodes + reserved_ips

Example cluster:

Parameter	Value
Nodes	20
Pods per node	30

Pod IPs:

20 × 30 = 600

Node IPs:

Reserved addresses:

Total required:

625 IPs

This means the cluster would need at least a /22 subnet.

Typical recommendations are:

Subnet	Usable IPs	Typical Use
/24	~251	small clusters
/23	~507	medium clusters
/22	~1019	larger clusters
/20	~4091	production environments

Allocating slightly larger ranges early is usually safer than resizing subnets later.

What Happens When Subnets Are Too Small

This is a surprisingly common failure scenario.

Everything works initially.

Then the cluster grows.

Suddenly:

pods fail to schedule
node pools cannot scale
networking errors appear

At that point the options are painful:

rebuild the cluster
migrate workloads
redesign the VNet or VPC
update firewall rules and routing

All of which are far harder than simply planning a larger subnet from the beginning.

Planning Subnets the Safe Way

When designing Kubernetes networking, it's often best to start from maximum expected scale, not the initial deployment.

A simple rule of thumb:

max_nodes × pods_per_node

Then add buffer capacity for:

future node pools
cluster upgrades
cloud platform reserved addresses

This approach avoids painful migrations later.

A Small Tool I Built to Help With This

After running into this issue several times, I built a small planner to estimate the subnet size required for Kubernetes clusters running on Azure.

You can try it here:

https://subnettool.com/tools/aks-subnet-planner/

It helps estimate how large your CIDR range should be based on:

node count
pods per node
Azure networking constraints

before deploying the cluster.

Final Thoughts

Subnet planning used to be straightforward.

But in modern cloud-native environments, the interaction between:

cloud platform IP reservations
Kubernetes networking models
cluster scaling

makes it much easier to underestimate address requirements.

Taking the time to plan subnet sizes properly can save a lot of painful networking migrations later.

If you want a deeper explanation of AKS networking models and subnet planning, see this detailed guide:
https://subnettool.com/learn/aks-networking

Related Tools

If you're working with subnet planning in cloud environments, these calculators may also be useful.

General subnet calculator

https://subnettool.com/

Kubernetes subnet planner

https://subnettool.com/tools/kubernetes-subnet-planner/

AKS subnet planner

https://subnettool.com/tools/aks-subnet-planner/

Usable IP calculator

https://subnettool.com/tools/usable-ip-calculator/

CloudNetDraw is Now Live as a SaaS – Azure Network Diagrams, No Setup Needed

Kristoffer Hatland — Fri, 11 Jul 2025 07:20:44 +0000

CloudNetDraw Is Now Live as a Hosted Service 🚀

A few weeks ago, I introduced CloudNetDraw — a side project I built to automate Azure network diagrams and eliminate the pain of drawing HUB/spoke topologies by hand.

The early feedback was fantastic — and now I'm excited to share that CloudNetDraw is available as a hosted service.

🟦 What’s New

You can now:

Log in directly to the CloudNetDraw portal
Authenticate with Azure (your own tenant)
Generate .drawio network diagrams instantly:
- HUB & spoke layout
- vNet peerings
- Subnets (with CIDRs)
- NSG and UDR flags

No need to deploy anything. Just authenticate, run, download.

👉 Try it now: https://cloudnetdraw.com

🧠 Why a Hosted Version?

While some users prefer to run everything locally or inside their own tenant, many just want to plug in credentials and go.

This hosted version is perfect for:

Consultants doing one-time Azure assessments
Infra or security engineers documenting their environment
Anyone tired of hand-drawing vNets and peerings

🔍 How It Works

CloudNetDraw:

Uses read-only Azure API access (you authenticate using your browser)
Pulls your network topology (no data stored)
Generates a .drawio diagram you can edit, export, or embed

No telemetry, no tracing, no hidden analytics.

👉 Watch the quick demo: How to use the user login in CloudNetDraw

📬 What’s Next?

Over the coming weeks:

I’ll improve layout logic and draw subnet details more cleanly
Add HLD support for multiple address space within one vNet
Possibly build a ServiceNow/Confluence integration for the self-hosted version

🙏 Call for Feedback

If you try the hosted version, I’d love to hear:

What features you’re missing
Whether you prefer SaaS or self-hosted
Would you pay for a usage-based or flat-rate version?

Thanks again to everyone who tested the early version and helped shape this tool — you’re awesome 💙

→ Try it now at cloudnetdraw.com

Azure Diagramming Without Pain – How I Built CloudNetDraw

Kristoffer Hatland — Tue, 01 Jul 2025 08:37:18 +0000

If you’ve ever needed to document an Azure network — especially one you didn’t build yourself — you know the pain:

Hunting through the Azure portal

Clicking into each vNet, peering, subnet, NSG, UDR

Recreating it all manually in Draw.io or Visio

It’s tedious. And error-prone.
I wanted something better.
So I built CloudNetDraw.

🚀 What It Does
CloudNetDraw is a tool that automatically generates Azure network diagrams by querying your environment and exporting editable .drawio files.

You can use it in two ways:

Hosted version: Just sign in with your Azure account (or use a Service Principal)

Self-host: Deploy it yourself as an Azure Function from the GitHub repo

No agents, no install, no need to reverse-engineer infrastructure.
You get instant diagrams with:

✅ Hub & Spoke visualization
✅ All vNets and subnets (with CIDRs)
✅ NSG and UDR indicators
✅ Editable output (Draw.io)
✅ HLD and MLD versions

🔧 How it works
Data Collection
Using the Azure Python SDK, the tool authenticates via Entra ID (Azure AD) and pulls:

All vNets

Peering relationships

Subnets (with address ranges)

Network Security Groups

Route tables (UDRs)

Topology Mapping
The script identifies:

Which vNet is acting as the hub

All spokes peered to the hub

Additional peerings (mesh setups)

Subnets with NSG or UDRs attached

Diagram Generation
The result is passed into a layout engine that outputs a .drawio file, which opens cleanly in https://app.diagrams.net. Or Drawio Desktop

🧠 Why I Built It
I’m a cloud security architect — so I constantly review Azure environments. But I kept hitting the same wall:

There was no quick and accurate way to get an overview of network architecture.

Exporting from Terraform didn’t help in live environments. Defender for Cloud and Network Watcher is a mess. Visio stencils were slow and brittle.

I didn’t need another Cloud Security Posture Management (CSPM) tool. I just wanted a visual, editable, and scriptable map of the actual network.

🔐 What About Security?

This was a key design goal:

We don’t store any network data

The diagrams are generated in memory

Everything is wiped after download

Only basic telemetry (errors, usage counts) is collected

Fully open-source if you want to audit it or self-host

More details in the privacy policy.

🛠 Tech Stack
Azure Functions (Python backend)

Azure SDK (Python: azure-mgmt-*)

lxml for Draw.io XML generation

GitHub Actions for deployment

Draw.io viewer (optional for preview)

🌐 Try It Now

Website: CloudNetDraw

GitHub: CloudNet-Draw

No signup required. Just log in with Azure or use a service principal.

💬 Feedback?
I’d love to hear your thoughts — especially if you’re working in large-scale Azure environments or want to see support for:

AWS or GCP?

More detailed subnet-level LLD diagrams?

Additional resource types?

Let me know in the comments or open an issue on GitHub!

Thanks for reading —
Kristoffer