AWS Builder Center is the official home for builders on AWS. Share and read what others are working on, follow people who inspire you, explore training and workshops, and find tools to support what you're building.
VPC Peering Architecture: Best Practices for Common Design Challenges
Hello I intend to use VPC Peering for connectivity as I design a multi-VPC architecture. I want to make sure my design is scalable and reliable. I would value any community insights on best practices as I have some specific architectural questions. CIDR Block Overlaps: How do you manage CIDR block overlaps when integrating with pre-existing VPCs? In this case, are there any suggested methods for re-addressing or utilizing alternative connectivity options? • Transitive Peering: What are the common architectural patterns for facilitating communication between spoke VPCs without constructing a complete mesh, given that VPC Peering does not support transitive routing? Are a central transit VPC or AWS Transit Gateway the main options? • Security and Routing Configuration: Which procedures are most important to guarantee appropriate security and communication between peering VPCs? Which is the suggested sequence of steps for setting up Network ACLs/Security Groups and route tables? VPC Peering Scaling: How should a large number of peering connections be managed and scaled? When designing for a large-scale environment, are there any architectural constraints I should be mindful of? I would be very grateful for any guidance on these particular subjects.
- Language
- English
asked a year ago533 views
- Newest
- Most votes
- Most comments
IP overlap: In general, don't do this. VPC peering is very strict and even if it wasn't I strongly recommend that you do not use overlapping IP addresses unless you have a very specific and good reason (of which there are extremely few). Ref: https://aws.amazon.com/blogs/networking-and-content-delivery/connecting-networks-with-overlapping-ip-ranges/
Multi-VPC connectivity: Peering is good up until it isn't - either you run into hard limits; or the overhead of maintaining a lot of routes and a lot of peering connections is not worth it. Transit Gateway or Cloud WAN are the appropriate services to use.
Security: You need to be a lot more specific about what you're looking for here. What "guarantees" are required? What security features are mandatory for you?
Security Groups/NACLs: I would start with security groups and use NACLs only when necessary. There is a far larger conversation to be had here but the vast majority of what most customers want to do can be done with Security Groups which makes your life easier - especially for future maintenance.
Route tables: I don't know what you're asking for here. You need route tables - as you get more peering connections they are going to get more complex. Transit Gateway/Cloud WAN make that much easier by acting as that "core router".
Scaling peering: In general we would recommend that you don't have a large number of peering connections because you need to maintain it - or write the automation to do that. There's nothing specifically "wrong" there, just that it is effort for you.
You might also read https://aws.amazon.com/blogs/networking-and-content-delivery/aws-network-optimization-tips/
Relevant content
asked a year ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 10 months ago
