Article

Demystifying AWS VPC: Your Complete Guide to IP Addressing and CIDR Notation

6 min read
Originally published on Medium. Read, clap or comment on Medium ↗

Stop overthinking network design and start building scalable cloud infrastructure with confidence

Picture this: You’re about to deploy your first application on AWS, and suddenly you’re faced with creating a VPC. The console asks you for a “CIDR block” and you freeze. What’s a CIDR? How many IPs do I need? Will I run out of addresses later?

If this sounds familiar, you’re not alone. IP addressing and CIDR notation are often the biggest hurdles for developers moving to the cloud. But here’s the thing — once you understand the fundamentals, VPC design becomes surprisingly straightforward.

Why CIDR Matters More Than You Think

In the physical world, you wouldn’t build a house without knowing how many rooms you need. Similarly, in AWS, you can’t build efficient infrastructure without understanding how to allocate IP addresses properly.

Poor CIDR planning leads to:

Let’s fix that.

CIDR Notation: The Language of Networks

CIDR (Classless Inter-Domain Routing) is simply a way to describe a range of IP addresses. Think of it as a street address system for the internet.

The Anatomy of CIDR

192.168.1.0/24
    ↑        ↑
  Network   Subnet Mask
  Address   (How many IPs)

The number after the slash (/24) tells you how many bits are "locked" for the network portion. The remaining bits determine how many individual IP addresses you can assign.

The Magic Numbers You Need to Know

Here’s the cheat sheet that every AWS architect should memorize:

CIDR Available IPs* Best Used For /28 11 IPs Small subnets, NAT gateways /24 251 IPs Standard application subnets /20 4,091 IPs Large application tiers /16 65,531 IPs Entire VPC (maximum recommended) /8 16+ million IPs Enterprise-wide networks

*AWS reserves 5 IPs in each subnet, hence the odd numbers.

Quick Mental Math Trick

Want to calculate available IPs quickly? Use this formula:

Available IPs = 2^(32 - CIDR) - 5

For /24: 2^(32-24) - 5 = 2^8 - 5 = 256 - 5 = 251 IPs

AWS VPC: Your Private Kingdom in the Cloud

Think of a VPC as your private data center in AWS. It’s completely isolated from other customers and gives you full control over your network environment.

The Three-Tier Architecture Pattern

Most production applications follow this pattern:

Internet Gateway
      ↓
┌─────────────────┐  ← Public Subnet (Web Servers)
│   10.0.1.0/24   │     Load Balancers, NAT Gateways
└─────────────────┘
      ↓
┌─────────────────┐  ← Private Subnet (App Servers)  
│   10.0.2.0/24   │     EC2 instances, ECS tasks
└─────────────────┘
      ↓
┌─────────────────┐  ← Private Subnet (Databases)
│   10.0.3.0/24   │     RDS, ElastiCache, etc.
└─────────────────┘

Real-World VPC Design: A Step-by-Step Walkthrough

Let’s design a VPC for a typical web application that needs to scale.

Step 1: Choose Your VPC CIDR Block

Recommendation: Use 10.0.0.0/16

This gives you 65,531 IP addresses — enough for most applications while leaving room for future VPC peering.

Pro tip: Avoid 172.16.0.0/16 if you plan to connect to corporate networks, as many companies use this range internally.

Step 2: Plan Your Subnets

For a multi-AZ deployment across 3 availability zones:

VPC: 10.0.0.0/16 (65,531 IPs)
Public Subnets (for load balancers):
├── 10.0.1.0/24 (AZ-1a) → 251 IPs
├── 10.0.2.0/24 (AZ-1b) → 251 IPs  
└── 10.0.3.0/24 (AZ-1c) → 251 IPsPrivate Subnets (for applications):
├── 10.0.11.0/24 (AZ-1a) → 251 IPs
├── 10.0.12.0/24 (AZ-1b) → 251 IPs
└── 10.0.13.0/24 (AZ-1c) → 251 IPsDatabase Subnets (for RDS):
├── 10.0.21.0/24 (AZ-1a) → 251 IPs
├── 10.0.22.0/24 (AZ-1b) → 251 IPs
└── 10.0.23.0/24 (AZ-1c) → 251 IPs

Step 3: Leave Room for Growth

Notice we’ve only used 10.0.1.x to 10.0.23.x. This leaves us 10.0.24.x through 10.0.255.x for future expansion – that's 232 additional /24 subnets!

Common CIDR Mistakes and How to Avoid Them

Mistake #1: Starting Too Small

# DON'T: This VPC will limit your growth
VPC CIDR: 10.0.0.0/24 (only 251 total IPs)
# DO: Give yourself room to grow  
VPC CIDR: 10.0.0.0/16 (65,531 total IPs)

Mistake #2: Overlapping IP Ranges

# DON'T: These ranges overlap and will cause peering issues
VPC-1: 10.0.0.0/16
VPC-2: 10.0.50.0/24  ← This is within VPC-1's range!
# DO: Use non-overlapping ranges
VPC-1: 10.0.0.0/16   (10.0.0.1 - 10.0.255.254)
VPC-2: 10.1.0.0/16   (10.1.0.1 - 10.1.255.254)

Mistake #3: Forgetting AWS Reserved IPs

AWS reserves 5 IP addresses in every subnet:

So a /28 subnet (16 total IPs) only gives you 11 usable addresses.

Advanced Patterns for Scale

Pattern 1: Environment Separation

Development:   10.0.0.0/16
Staging:       10.1.0.0/16  
Production:    10.2.0.0/16

Pattern 2: Multi-Region Architecture

us-east-1:     10.0.0.0/16
us-west-2:     10.1.0.0/16
eu-west-1:     10.2.0.0/16

Pattern 3: Microservices at Scale

For organizations running hundreds of microservices:

VPC: 10.0.0.0/16
Shared Services (ALB, NAT, etc.):  10.0.0.0/20  → 4,091 IPs
Service Mesh (Istio, Consul):      10.0.16.0/20 → 4,091 IPs
Application Subnets:               10.0.32.0/19 → 8,187 IPs
Database Subnets:                  10.0.64.0/18 → 16,379 IPs

Practical Tools and Commands

AWS CLI for VPC Creation

# Create VPC
aws ec2 create-vpc --cidr-block 10.0.0.0/16
# Create subnet
aws ec2 create-subnet \
  --vpc-id vpc-12345678 \
  --cidr-block 10.0.1.0/24 \
  --availability-zone us-east-1a

Terraform Example

resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true
  
  tags = {
    Name = "production-vpc"
  }
}
resource "aws_subnet" "public" {
  count             = 3
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.${count.index + 1}.0/24"
  availability_zone = data.aws_availability_zones.available.names[count.index]
  
  map_public_ip_on_launch = true
  
  tags = {
    Name = "public-subnet-${count.index + 1}"
    Type = "public"
  }
}

Security Considerations

Network ACLs vs Security Groups

Network ACLs operate at the subnet level and are stateless:

# Example: Block all traffic from a specific IP range
Rule: DENY ALL traffic from 192.168.1.0/24

Security Groups operate at the instance level and are stateful:

# Example: Allow HTTP traffic from anywhere
Rule: ALLOW port 80 from 0.0.0.0/0

The Principle of Least Privilege

Always start restrictive and open up as needed:

  1. Database tier: Only allow traffic from application tier
  2. Application tier: Only allow traffic from load balancer
  3. Public tier: Only allow necessary ports (80, 443)

Monitoring and Troubleshooting

VPC Flow Logs

Enable VPC Flow Logs to monitor traffic patterns and identify security issues:

aws ec2 create-flow-logs \
  --resource-type VPC \
  --resource-ids vpc-12345678 \
  --traffic-type ALL \
  --log-destination-type cloud-watch-logs \
  --log-group-name VPCFlowLogs

Common Connectivity Issues

Problem: Can’t reach the internet from private subnet Solution: Check NAT Gateway configuration and route tables

Problem: Can’t connect between subnets
Solution: Verify security group rules and NACLs

Problem: Running out of IP addresses Solution: Consider creating additional subnets or using larger CIDR blocks

Your Action Plan

Ready to implement this knowledge? Here’s your step-by-step action plan:

Phase 1: Assessment (Week 1)

Phase 2: Planning (Week 2)

Phase 3: Implementation (Weeks 3–4)

Phase 4: Optimization (Ongoing)

Key Takeaways

Understanding CIDR and VPC design isn’t just about memorizing IP ranges — it’s about building a foundation for scalable, secure cloud architecture. Remember these core principles:

  1. Plan for growth: Always choose larger CIDR blocks than you think you need
  2. Think in tiers: Separate your public, private, and database resources
  3. Security first: Use the principle of least privilege for all network access
  4. Document everything: Your future self (and team) will thank you
  5. Monitor actively: Use VPC Flow Logs and CloudWatch to stay informed

The cloud is incredibly powerful, but that power comes with responsibility. By mastering these networking fundamentals, you’re not just avoiding common pitfalls — you’re setting yourself up to build the kind of robust, scalable infrastructure that modern applications demand.

What’s your next move? Start with a simple three-tier VPC design, get comfortable with the concepts, and gradually work your way up to more complex architectures. The cloud is waiting for you to build something amazing.

Have questions about your specific VPC design? follow for more cloud architecture insights. And if this article helped you finally understand CIDR notation, give it a clap — it helps other developers find these practical guides.

← All articles Discuss on Medium ↗