If you’re using Virtual Private Clouds (VPCs) in Amazon Web Services, you may one day find the need to allow two of these virtual networks to talk with each other. This is especially likely if you need to have protected communication between services in different AWS regions. To facilitate this, AWS provides a feature they call “VPC Peering.”
VPCs by themselves are complex because you need a strong grasp of the networking layer. Without an understanding of subnets, subnet masks, network address translation, DNS, and routing, it’s not likely you’ll have a good time. Even with that background, AWS layers its own complexity on top.
If you’re pretty sure you’ve done things correctly at the networking layer but find that your VPC Peering connection isn’t working, here are some areas you can double-check.
1. Check both sides.
Start with the basics. Does the peering connection exist for both VPCs? Has it been fully accepted?
Beyond that, this is a reminder for the subsequent checks. If something is incorrectly configured on either side of the peering connection, things won’t work.
Make sure you check both sides, and that everything is compatible internally and with the other VPC.
2. Check the routing table.
If the VPC peering connection is fully accepted, the next thing to check is the VPCs’ main routing tables.
On each side, the routing table should have a route entry for the other VPC’s subnet. The subnet and its mask must exactly match the VPC on the other side of the peering connection. The routes should both target the peering connection.
Without these entries in the routing table, no packets will be able to cross.
3. Check the other routing tables.
If your VPC has multiple subnets defined, they may have their own routing tables. In that case, the main routing table of the VPC will be ignored. Editing the VPC’s main routing table will have no effect.
Identify a service that can’t be reached (or reach out), and then find its subnet. Ensure that subnet’s routing table has an appropriate entry for the VPC peering connection.
4. Check the security groups.
If you’re reading a blog post on VPC peering, it’s likely you already have some familiarity with AWS’s “security groups.” If not, they’re essentially firewall rules that can only accept (not deny) traffic, and they can stack together.
The concept is fairly straightforward, but it still merits mention. One way or another, all services that need to communicate across the peering connection will need to have an attached security group granting permission to send (or receive) to the appropriate IPs or subnets of the remote VPC.
You’ll need to ensure everything is configured correctly on both sides of the peering connection and for each service-to-service line of communication. This, by far, is the most time-consuming step.
5. Check for private DNS resolution.
Perhaps all of the above steps have been verified and appear to be correct. In this case, the fix may be easy. You may simply need to enable the resolution of domain names to their private IPs. This is a setting on each side of the peering connection, and it applies to the other side.
For example, if it is enabled on the requester side, then the acceptor side will be able to resolve domains to the private IP of services within the requester.
This will only matter if you are referring to services by their domain name, such as my-aoeuid123-east-1.rds.amazonaws.com.
Speed up your peering connection trouble-shooting.
There’s a lot that can go wrong when attempting to set up a VPC peering connection, and it can take a long time to troubleshoot.
Hopefully, armed with this list, your troubleshooting can go much more quickly.