AWS VPC Support
AWS VPC design and CIDR planning.
CIDR mistakes are painful because overlapping ranges block peering, VPN and Transit Gateway later, and a VPC primary CIDR cannot simply be shrunk. We plan address space across accounts and regions before you build, or fix a layout you have already outgrown.
When You Need This
The situations where this work pays for itself.
Signs it is time
- You are creating the first VPCs for a new AWS environment
- Peering or VPN fails because ranges overlap with another network
- A subnet has run out of IP addresses, often with EKS or Lambda
- You plan multiple accounts, regions or an on-premises connection
- You inherited a default VPC layout used for production
What you get
- An address plan covering accounts, regions and on-premises
- VPC and subnet definitions in infrastructure as code
- IPAM configuration if you want enforced allocation
- A migration plan if you must renumber
How we do it
A clear, safe process you can follow along with.
1. Inventory every network you will connect
We list on-premises ranges, partner networks, other VPCs and VPN client pools. Anything that might ever route to this VPC must not overlap.
2. Allocate a master plan
We carve a large private block into per-region and per-account ranges, usually with IP Address Manager (IPAM) so allocations are tracked and overlaps are blocked automatically.
3. Size the VPC and subnets
We choose subnet sizes by workload. Remember AWS reserves five addresses in each subnet, and EKS pods, Lambda ENIs and large autoscaling groups can consume many addresses.
4. Define tiers across availability zones
We create public, private application and isolated data subnets in at least two AZs, with route tables per tier, so network ACLs and routing follow the architecture.
5. Plan connectivity and egress
We decide the internet, NAT, endpoint and Transit Gateway paths up front, and leave unallocated ranges for growth.
6. Fix a layout that is too small or overlapping
If you are already stuck, we add a secondary CIDR and new subnets, migrate workloads gradually, or use private NAT where overlap cannot be avoided.
Mistakes we help you avoid
Common ways this goes wrong, and what we do instead.
Using the default 172.31.0.0/16 everywhere
Every account has the same default range, which guarantees overlap later.
Making subnets too small
A /28 fills quickly with endpoints, ENIs and pods. Resizing a subnet means rebuilding it.
Single subnet per tier
Without one subnet per AZ you lose AZ failure tolerance.
Ignoring IPv6
Dual-stack can relieve IPv4 exhaustion and cut NAT costs where your workloads support it.
Frequently Asked Questions
What CIDR should I use for an AWS VPC?
Pick a private range from RFC 1918 that does not overlap anything you connect. A /16 is a common starting size, and subnet sizes follow your workload counts.
Can I change a VPC CIDR after creation?
You can add secondary CIDR blocks, but you cannot resize the primary one. Planning space early avoids migrating workloads.
How many IP addresses are reserved in an AWS subnet?
Five: the network address, the VPC router, the DNS server, one reserved for future use and the broadcast address.
Want Help With AWS VPC design and CIDR planning?
Schedule an appointment. Tell us about your environment and we will outline the safest, highest-value approach.
Schedule Appointment › No commitment required