Most AWS mistakes are reversible. You resize an instance, you change a policy, you delete a bucket. Networking is not like that: a CIDR you chose in 2021 is now peered to two partners and baked into forty security groups, and changing it means a migration.
These are the six we find most often, roughly in order of how painful they are to fix later.
1. A CIDR that collides with something
The single most expensive networking mistake is picking 10.0.0.0/16 because it is the default. Every other company picked it too, and the day you peer with a partner, acquire a company or connect a client VPN, you cannot route.
Allocate from a plan: a /16 per region per environment, drawn from a documented range that your on-premises network team has blessed, with IPAM tracking it. If you are already collided, private NAT gateways and Transit Gateway with NAT can paper over it, but the paper is expensive and confusing.
Reserve more than you think. A /24 per subnet feels generous until an EKS cluster with VPC CNI assigns a pod IP per pod and you exhaust it in a quarter.
2. No separation between public, private and data subnets
Three tiers per availability zone, always: public (load balancers and NAT only), private (compute), isolated (databases, no route to the internet at all). The isolated tier is the one people skip, and it is the one that makes "the database cannot be reached from the internet" a statement about routing rather than about security groups.
3. NAT gateway topology chosen by accident
A NAT gateway per availability zone is the correct high-availability answer and it is three fixed monthly charges plus data processing. A single NAT gateway saves money and adds a cross-AZ data charge for the traffic plus a single point of failure.
Neither is wrong. What is wrong is not deciding. And before you decide, remove the traffic that should never reach a NAT gateway at all: gateway VPC endpoints for S3 and DynamoDB are free and cut a surprising share of it. Interface endpoints for the other services cost per hour, so enable them where the data processing charge exceeds the endpoint price — usually ECR, Secrets Manager, SSM and CloudWatch Logs in a busy account.
4. Security groups used as a firewall, not as an identity
The pattern that scales: security groups reference other security groups, not CIDR ranges. app-sg allows 5432 from web-sg. When you add a subnet, nothing changes. When you use CIDRs, every topology change is a security group review.
Keep 0.0.0.0/0 out of ingress rules entirely except on the load balancer's HTTPS port, and use SSM Session Manager instead of SSH so port 22 never opens. That one substitution removes the most common finding in every posture scan we run — see the tooling piece for how to catch the rest.
5. Peering where you needed a Transit Gateway
VPC peering is free to create and does not transit: A peered to B and B peered to C does not let A reach C. At three VPCs it is fine. At eight it is 28 peering connections and a route table nobody understands.
Transit Gateway costs per attachment per hour plus data processing, and it gives you a hub with route tables you can reason about, segmentation between environments, and one place to attach the VPN. The crossover is around five VPCs, or immediately if you need environment segmentation.
6. No flow logs, or flow logs nobody can query
Enable VPC flow logs to S3 in Parquet format, partitioned by hour, in the log archive account. Not to CloudWatch Logs, where the cost at volume is painful. Then create the Athena table on day one, because a flow log you cannot query during an incident is storage, not telemetry.
The three questions flow logs answer, that nothing else does: what is actually talking to this instance, where is the cross-AZ traffic coming from, and did anything reach the compromised host in the hour before.
The cheap version of all six
For a new estate, all of this is an afternoon of decisions and a week of Terraform. For an existing one, pick the reversible ones first: endpoints, security group references, flow logs. The CIDR and the peering topology are migrations, and they belong in a plan with a date, not in a backlog. That plan is usually one of the first things we write in a cloud engagement.
What to do this week
List your VPC CIDRs across every account and region, and check for overlaps. Then check whether S3 and DynamoDB gateway endpoints exist in the VPCs that talk to them. The first tells you whether you have a migration coming; the second is free money.