AWS - VPC Peering
VPC Peering vs. Transitive Peering
AWS supports two types of peering when it comes to networking together VPCs. They are:
- VPC Peering
- Transitive VPC Peering via Transit Gateways.
VPC Peering
However, just because A can connect to B and C doesn't mean that B can connect to C; that's what they call transitive peering, which isn't supported with VPC Peering.
In order for B and C to communicate you will need to connect them as well.
The diagram to the right shows a peering connection between B and C, now B and C to communicate.
As you can imagine, this can get quite tedious; the more VPCs, the more connections you will need to make and the more maintenance it will be to maintain those connections.
Transit Gateway (Transitive Peering)
By comparison, a Transit Gateway allows traffic to route to any VPC that it's connected to and as long as the appropriate routes are in the route tables.
In general, this is typically the way to go, and we'll cover a Transit Gateway in another article.
Why would I use VPC Peering
So why isn't this article about VPC Transitive Peering (Transit Gateways) instead of the standard VPC Peering? Well, I'm glad you asked! Transit Gateways are technically the new default standard for VPC Peering, and while they offer a lot of great benefits they also miss one extremely important detail (which I'm hoping they can resolve in the future).
Standard VPC Peering supports sharing security groups across VPCs, which means you can reference them by name across different VPC boundaries. Transit Gateways do not, which means you'll need to put in the CIDR ranges while allowing traffic from one VPC to another.
When adding an inbound or outbound rule, and if you use the source/destination of a security group from another VPC, it may not automatically show up in the type-ahead/IntelliSense that you see with other security groups in your current VPC, that's ok. You won't get an error and you can still save it and use it.
TIP:
- Share Security Groups across VPCs using VPC Peering
- For cross-account security-group sharing you will require an account id to prefix the security group. Enter it as <aws-account-id>/<security-group-id>. For example: 12345678/sg-xxxxxxxxx
- Security Groups must be in the same region for this work (same account or cross-account). Security Groups are Region-specific.
- If in another region, you will need to use CIDR ranges for your security groups.
General Guidelines for VPC Peering vs Transit Gateway
So a general rule of thumb is to use a standard VPC peering if you need to share security groups across VPC accounts and if the total number of VPCs is less than 10 (based on AWS's documentation), personally I think once you hit 5 VPCs you should start looking at switching to a Transit Gateway and define good subnets for CIDR ranges for sharing.
Remember: Security groups in a peer VPC are not automatically displayed in the Inbound or Outbound rule manager... but you can still add them without an error.
What's Next
In my next article, I'll explain how connect two VPCs with VPC Peering along with the benefits of sharing the security groups, then we'll move on to a Transit Gateway so that you can see the difference between the two. At that point a good architect weighs the pros and the cons of each and decides how to proceed based on requirements, cost, security, easy of use, and maintenance.
Additional Resources
If you want to learn more, be sure to read the AWS white papers on Building a Scalable and Secure Multi-VPC AWS Network Infrastructure
For more information on cross VPC Security Groups read: Update your security groups to reference peer VPC groups
Main Image Credit: Photo by Saish Menon on Unsplash