Subnetting CIDR in AWS — The Simple Way

When working with AWS, especially with VPC design, subnetting is not optional — it’s a core skill.

Whether you’re building:

• multi-AZ architectures
• public/private subnet separation
• EKS or Auto Scaling workloads

you must understand how to split CIDR ranges correctly.

Problem

You have a VPC:

10.0.0.0/16

You want to divide it into:

8 subnets

Step 1: Identify where subnetting happens

• /16 means:
• 10.0 is fixed
• Subnetting will happen in the 3rd octet

Step 2: Calculate block size

Each octet has 256 addresses

256 ÷ 8 = 32

This is your block size (jump)

Step 3: Convert block size to CIDR

Block size 32 corresponds to:

/19

Quick reference:

| Block Size | CIDR  |
| - - - - - -| - - - |
| 128        | /17   |
| 64         | /18   |
| 32         | /19   |
| 16         | /20   |
| 8          | /21   |
| 4          | /22   |
| 2          | /23   |

Step 4: Generate subnet ranges

Start from 0 and increment by 32:

10.0.0.0   - 10.0.31.255
10.0.32.0  - 10.0.63.255
10.0.64.0  - 10.0.95.255
10.0.96.0  - 10.0.127.255
10.0.128.0 - 10.0.159.255
10.0.160.0 - 10.0.191.255
10.0.192.0 - 10.0.223.255
10.0.224.0 - 10.0.255.255

AWS Context

In real AWS setups, this maps directly to architecture:

Example:

• 3 Availability Zones
• Public + Private subnets per AZ

you’ll need at least 6 subnets so you round to 8 (power of 2)

Important AWS Notes

1. AWS reserves 5 IPs per subnet

Each subnet loses:

• first 4 IPs
• last IP

2. Plan for growth

Don’t design for today only.

Always leave space for:

• new AZs
• more services
• scaling workloads

3. Avoid small subnets

Example:

• /28 → only 11 usable IPs

Not suitable for:

• EKS
• Auto Scaling

Final Rule

Block size = 256 ÷ number of subnets CIDR follows the block size Ranges follow the block size increments

DevOps Tip

CIDR planning must be done before deployment because:

Changing subnet ranges later = redesigning your infrastructure