When most teams start building in AWS, networking feels simple.
You create a VPC, add a few subnets, maybe a load balancer, and everything works. At this stage, the architecture is small and networking decisions rarely feel critical.
The real problems appear later.
As organizations grow, they add more services, more environments, and more teams. What once worked perfectly can slowly turn into operational complexity.
These are architecture anti-patterns — designs that work initially but become problematic as the system scales.
In this article, we’ll explore several AWS networking anti-patterns that often appear in growing environments and how to design architectures that scale more effectively.
The VPC Peering Mesh That Eventually Becomes a Nightmare
VPC peering works extremely well when connecting a small number of VPCs.
This design is simple and easy to understand.
However, as more VPCs are added, the architecture becomes a full mesh.
Each new VPC requires additional peering connections and route table updates.
Two major problems appear:
• Operational complexity grows quickly
• VPC peering does not support transitive routing
In large environments this becomes difficult to manage.
Better Architecture: Hub-and-Spoke with Transit Gateway
A more scalable design uses a Transit Gateway.
Benefits:
• Centralized routing
• Easy VPC onboarding
• Cleaner architecture
• Better scalability
The “One NAT Gateway Is Enough” Myth
Private subnets often need outbound internet access.
Many architectures start like this:
This introduces two hidden problems.
Problem 1 — Availability
NAT Gateways are traditionally Availability Zone–scoped resources.
If all private subnets depend on a NAT Gateway in a single AZ, an issue in that AZ can impact outbound connectivity across the environment.
Even if your workloads are spread across multiple AZs, your egress path is not.
Problem 2 — Cross-AZ Traffic Costs
When private subnets in different AZs use a NAT Gateway in one AZ, traffic must cross AZ boundaries:
Private AZ2 → Cross-AZ → NAT GW AZ1 → Internet
At small scale this is negligible.
At larger scale, this becomes a quiet but significant cost driver.
Better Architecture – it Depends Now
Traditionally, the recommended approach was to deploy one NAT Gateway per Availability Zone.
This ensures:
• better resilience
• no cross-AZ data transfer
• predictable architecture
However, newer approaches — including regional NAT patterns — are changing this guidance.
Option 1 — NAT Gateway per AZ (Traditional)
Use one NAT Gateway in each AZ:
AZ-A → NAT-A
AZ-B → NAT-B
AZ-C → NAT-C
Best for:
- strict AZ isolation
- highly critical workloads
- predictable failure domains
Option 2 — Regional NAT (Modern Approach)
A single NAT Gateway can now be used more flexibly across AZs, relying on AWS-managed resilience.
This simplifies the architecture:
Private AZ-A → NAT
Private AZ-B → NAT
Private AZ-C → NAT
Best for:
- simpler environments
- reduced operational overhead
- cost optimisation (fewer NAT Gateways)
The Real Shift — Do You Even Need NAT?
In many modern architectures, the better question is:
Can we avoid NAT entirely?
Alternatives include:
- VPC Endpoints (S3, DynamoDB, etc.)
- PrivateLink for service-to-service communication
- IPv6, where NAT is not required
Reducing NAT usage often improves:
• cost
• security posture
• architectural simplicity
Key Takeaway
There is no longer a single “best practice” for NAT design.
Instead, it’s about choosing the right trade-off:
- per-AZ NAT → maximum isolation
- regional NAT → simplicity and efficiency
- no NAT → modern, cloud-native approach
The important thing is to design outbound connectivity intentionally, not just default to a single NAT Gateway because it works at small scale.
When Internal Services Are Exposed Through Public Load Balancers
Sometimes internal services are exposed through public load balancers, even though they are only used inside the VPC.
Even if access is restricted, the load balancer is still internet-facing.
This increases:
• attack surface
• operational complexity
• security risks
Better Architecture: Internal Load Balancer
Internal load balancers are not reachable from the internet and only operate inside the VPC.
The CIDR Decision That Breaks the Network Two Years Later
Poor IP planning is one of the most common networking mistakes.
Two teams create VPCs independently:
Everything works until someone tries to connect them.
VPC A X VPC B
Because the CIDR blocks overlap, routing is impossible.
This prevents:
• VPC Peering
• Transit Gateway connectivity
• Hybrid networking
Fixing the problem later often requires re-IPing entire VPCs.
Better Architecture: Planned Address Space
Good IP planning avoids painful migrations later
Security Groups That Nobody Understands
Over time, security groups sometimes accumulate many rules.
Security Group
Allow 10.0.0.0/8
Allow 172.16.0.0/12
Allow 192.168.0.0/16
Allow Port 80
Allow Port 443
Allow Port 3306
Allow Port 8080
...
Eventually nobody remembers why half the rules exist.
This creates:
• auditing difficulty
• security risks
• operational confusion
Better Architecture: Service-Oriented Security Groups
Instead of large rule sets, organize security groups around application tiers.
+--------+
| SG Web |
+---+----+
|
v
+--------+
| SG App |
+---+----+
|
v
+--------+
| SG DB |
+--------+
Benefits:
• clearer security boundaries
• easier auditing
• simpler rule management
Designing AWS Networks That Scale
Most networking mistakes don’t appear immediately.
They appear as systems grow.
More services.
More teams.
More environments.
Architectures that seemed perfectly fine at the beginning can become difficult to operate.
A few principles help avoid many of these problems:
• plan IP addressing early
• avoid mesh architectures
• design for multi-AZ resilience
• keep internal services private
• keep security policies simple
Good AWS networking design is not only about making systems work today.
It’s about building networks that remain simple and scalable as your infrastructure evolves.
Leave a Reply