Subnetting isn’t just for certification exams; it’s a critical skill that can bring your entire production environment down. This is how senior engineers handle VPC design and fix IP exhaustion in the real world, from quick fixes to long-term strategies.

Beyond the CIDR Calculator: How Much Subnetting Do We *Really* Do?

It was 2 AM. PagerDuty was screaming about cascading failures in our main production API. The dashboards were a sea of red. After 30 frantic minutes of troubleshooting, we found the culprit: IP address exhaustion. A well-meaning engineer, trying to be efficient, had provisioned a new microservice in our primary app subnet using a /28 block. We had exactly 14 usable IPs, and a traffic spike had just spun up three new containers. Game over. That’s the night I learned that subnetting isn’t an academic exercise; it’s the concrete foundation our entire operation rests on, and most people ignore it until it’s on fire.

So, Why Does This Keep Happening?

I see this question on Reddit all the time: “How much subnetting do you *actually* do at work?” The answer is: a lot more than you think, but not in the way you’re tested on it. We’re not sitting around with a pencil and paper calculating broadcast addresses. We’re dealing with the consequences of poor planning.

The root cause is usually a mix of three things:

• The “ClickOps” Trap: Cloud providers make it dangerously easy to deploy a VPC with default settings. You click “next, next, finish,” get a massive /16 block, and throw everything into one or two giant subnets. It works… until it doesn’t.
• Growth Without a Plan: Your startup’s simple three-tier architecture from two years ago is now a sprawling mesh of microservices, Kubernetes clusters, and serverless functions. Each one churns through IPs, but the network foundation was never designed to handle that scale.
• Siloed Teams: The platform team creates a VPC, and the application teams just consume it. There’s no feedback loop until an app team says, “Hey, I can’t deploy my service, the subnet is full.”

The Subnetting Playbook: From Band-Aids to Surgery

When you’re staring at a full subnet in production, you have a few options, ranging from “get us back online now” to “let’s never have this happen again.”

The Quick Fix: Carving Out Emergency Space

This is the battlefield triage. Your `prod-app-subnet-1a` (`10.50.10.0/24`) is out of addresses and the API is down. You can’t resize a subnet, so you need to make space, fast.

The play is to create a new, adjacent subnet and move non-critical workloads over. You find an unused block, like `10.50.11.0/24`, and provision `prod-app-subnet-1a-overflow`. You then update your route tables to ensure they can talk to each other and start the painful process of re-deploying less critical services (like background workers or a low-traffic admin tool) into the new subnet. This frees up a handful of precious IPs in the original subnet, allowing your critical API servers to scale.

Warning: This is pure technical debt. You’re creating network fragmentation and making your routing more complex. It buys you time, but it’s not a solution. Do this to get through the night, but plan a real fix for the morning.

The Strategic Fix: Plan Before You Build

The real, permanent solution is to treat your network like you treat your application code: with intention and a clear architecture. Stop using the defaults. For any new environment, we lay out a VPC IP space allocation plan before a single resource is built.

We start with a large CIDR for the VPC (e.g., `10.50.0.0/16`) and then break it down logically. This prevents different tiers from stepping on each other’s toes and gives high-churn services like Kubernetes the breathing room they need.

A simple allocation plan might look like this:

By thinking about future needs—”Will we use Kubernetes? How many database replicas might we need?”—you can avoid the 2 AM fire drill entirely. This is what we mean when we say we “do subnetting.”

The ‘Nuclear’ Option: The Great Re-IP

Sometimes the initial design is so flawed that no amount of band-aids will help. You have overlapping CIDRs with a peered VPC, fragmented subnets everywhere, and no room to expand. You’ve reached the point where you have to declare bankruptcy and start over. This is the “Great Re-IP.”

This involves:

1. Designing a brand new, clean VPC based on the strategic principles above. You define everything with Infrastructure as Code (like Terraform).
2. Creating a migration plan to move everything from the old VPC (`vpc-legacy-prod`) to the new one (`vpc-prod-v2`).
3. Migrating services in phases, usually over a weekend or a scheduled maintenance window. You start with stateless services, then tackle the stateful ones (databases) using things like read-replica promotion to minimize downtime.

This is a high-stakes, high-effort project. Here’s a tiny snippet of what the Terraform for a new, well-planned VPC might look like:

resource "aws_vpc" "prod_v2" {
  cidr_block           = "10.50.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true
  
  tags = {
    Name        = "vpc-prod-v2"
    Environment = "production"
  }
}

resource "aws_subnet" "prod_v2_app_1a" {
  vpc_id            = aws_vpc.prod_v2.id
  cidr_block        = "10.50.10.0/23" # Planned CIDR from our table
  availability_zone = "us-east-1a"

  tags = {
    Name = "prod-v2-app-subnet-1a"
  }
}

Pro Tip: A project like this requires buy-in from the entire engineering organization. You cannot do it in a silo. It requires meticulous planning, communication, and a clear rollback strategy for every single step. It’s painful, but the stability and scalability you gain are worth it.

So, yes, we do subnetting. We just don’t do it for a test. We do it to keep the lights on.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions