Top Techniques for Scalable VPC Peering and Other Options for Connecting Multiple VPCs

When designing a multi-VPC architecture, you're right to be concerned about the scalability and complexity of VPC peering as your environment grows.

Scalability and Complexity

While VPC peering works well for connecting a small number of VPCs, it becomes increasingly complex to manage as you add more VPCs. With 10 VPCs in a full-mesh topology, you'd need to manage 45 peering connections, which is operationally challenging.

The current best practice is to use a hub-and-spoke model rather than a many-to-many mesh when connecting more than two network address spaces. AWS Transit Gateway is specifically designed for this purpose, providing an easy-to-maintain hub-and-spoke model for routing traffic among multiple networks.

Transitive Peering & Centralized Services

You've correctly identified that VPC peering doesn't support transitive routing. For centralized services that need to be accessible from every VPC, you have a few options:

1. Create direct peering connections from each VPC to the VPC hosting your centralized services (becomes unwieldy at scale)
2. Use AWS Transit Gateway as a central hub, which natively supports transitive routing
3. Consider AWS PrivateLink for specific services that need to be shared across VPCs

AWS Transit Gateway vs. VPC Peering

Transit Gateway is recommended when:

• You have more than two VPCs that need to communicate
• You need transitive routing capabilities
• You want to simplify management of network connections

Key trade-offs:

• Management: Transit Gateway significantly simplifies network management with a centralized hub for up to 5,000 attachments
• Routing: Transit Gateway supports transitive routing, while VPC peering requires direct connections between each pair of VPCs
• Scalability: Transit Gateway is designed for large-scale deployments, whereas VPC peering becomes difficult to manage at scale
• Cost: Transit Gateway has additional costs compared to VPC peering, but the operational benefits often outweigh these costs for larger deployments

CIDR Management

For non-overlapping CIDR blocks, it's best to allocate a single, contiguous, non-overlapping CIDR block to each VPC. When dealing with third-party VPCs with overlapping ranges, you could:

1. Use AWS Network Firewall with NAT as you suggested
2. Consider AWS PrivateLink for specific service connectivity without requiring full network integration
3. Implement a software VPN solution that can handle NAT between the overlapping networks

For your current situation with shared databases and East-West traffic between microservices, AWS Transit Gateway would likely be the most appropriate solution as your environment grows, providing simplified management and native support for the transitive routing needed for your centralized services.
Sources
REL02-BP04 Prefer hub-and-spoke topologies over many-to-many mesh - AWS Well-Architected Framework
Network connectivity for a multi-account architecture - AWS Prescriptive Guidance
Amazon VPC-to-Amazon VPC connectivity options - Amazon Virtual Private Cloud Connectivity Options
Communicating across VPCs and AWS Regions - AWS Prescriptive Guidance

The re:Post agent is mostly correct in its answer, except for the point below regarding CIDR management, note that AWS Network Firewall does not have NAT functionality as of today:

Use AWS Network Firewall with NAT as you suggested

If you have a scenario where you need to establish network connectivity with overlapping IP CIDRs, you can use AWS PrivateLink and/or VPC Lattice. Both of these services support overlapping IP CIDRs between consumer and provider networks.

You'll also see a couple of AWS blogs on this topic, here is one: https://aws.amazon.com/blogs/networking-and-content-delivery/connecting-networks-with-overlapping-ip-ranges/