1 Answer
- Newest
- Most votes
- Most comments
0
Maybe it's a typo but the way you've written it, your VPC A is the 10.10.x.x block but it contains a 10.20.x.x instance - that doesn't look right.
Assuming VPC A is actually 10.20.0.0/16, you need the following routes:
- The route table for the subnet in VPC A containing 10.20.1.1 needs a route directing traffic for 10.11.0.0/16 to the peering connection.
- The route table for the subnet in VPC B containing your other instance needs a route directing traffic for 10.20.0.0/16 to the peering connection.
That way both requests and responses are handled.
In addition you need your subnet ACLs set appropriately (default should do). And the Security Group egress rules on the instance initiating a request, and the Security Group ingress ruled on the instance receiving a request need to be set up allowing the other SG, instance IP, subnet CIDR or VPC CIDR.
Relevant content
- Accepted Answerasked 5 months ago
- asked 6 months ago
AWS OFFICIALUpdated a month ago- AWS OFFICIALUpdated 8 months ago
- AWS OFFICIALUpdated 3 years ago
- AWS OFFICIALUpdated a month ago
Unfortunately not a typo. For legacy reason, I really have a
10.20.1.1into a10.10.0.0subnet. Inside the subnet this works thanks to the eni. Wondering if peering is possible though.Oh I see. In short no, you can't do this with VPC Peering as it's not transitive. The traffic doesn't originate or terminate on a network interface in the VPC so there's no associated route table directing traffic for the next hop, which is looks like is what you need (10.20.1.0/24 ec2-eni). Transit Gateway can do this if that suits your environment. Another option that may be worth exploring is using part of the "Transit VPC" Strategy that pre-dates Transit Gateway. Basically you could put a VGW in one VPC and make a VPN connection between it and VPN software running in an EC2 instance (or preferably two for redundancy) in the other VPC.