Why can’t I create an Amazon VPC peering connection with a VPC in another AWS account?

Last updated: 2022-04-15

When you create your VPC peering connection with a VPC in another AWS account, make sure to check the following settings:

• The account ID for VPC (Accepter) is entered correctly.
• The correct VPC ID for VPC (Accepter) is selected.
• None of the primary CIDR blocks or secondary CIDR blocks for your selected VPC (Requester) and VPC (Accepter) overlap.
  Note: If your VPCs have overlapping CIDR blocks, then you can’t create a VPC peering connection. You must delete and recreate one of the VPCs with a non-overlapping CIDR block.

Use a Private NAT gateway and Application Load Balancer through AWS Transit Gateway to establish private communication between two VPCs that have overlapping CIDR blocks.

Complete the following steps.

First VPC:

1. Add a secondary nonidentical CIDR.
2. Create additional private subnets in the primary and secondary blocks of the CIDRs.
3. Create a Private NAT Gateway in the secondary CIDR subnet to establish a private IP address from the subnet range.

Second VPC:

1. Add a secondary CIDR to the primary overlapping CIDR.
2. Create another identical private subnet in the primary CIDR.
3. In the newly created private subnet, launch an application hosting Amazon Elastic Compute Cloud (Amazon EC2) instance.
4. Create two more private subnets in different Availability Zones.
5. Create an internal Application Load Balancer, and then select the subnets from step 4.
6. Configure the Application Load Balancer, and register the instance by selecting the launched instance as Target. Note: The Application Load Balancer's targets must be the workloads in the primary CIDR's private subnet that the workloads from the first VPC need to access. Also, make sure that the registered targets are healthy.

Transit Gateway:

1. Create a Transit Gateway, and choose Disabled for the default route table propagation.
2. Create Transit Gateway VPC attachments for each VPC by associating appropriate subnets in each Availability Zone.
3. Enter routes in the Transit Gateway route table to route destination CIDRs to the VPC attachments.

VPC route table:

For first VPC:

1. Edit the route table of the workload in the private subnet.
2. Add a static route for the secondary destination CIDR through the Private NAT Gateway.
3. Create or modify a NAT subnet route table where the Private NAT gateway is launched.
4. Add a route entry to the secondary CIDR of the destination VPC through Transit Gateway.

For second VPC:

1. Edit the route table of the Application Load Balancer subnets.
2. Add routes for the return traffic of the first VPC's secondary CIDR through Transit Gateway.

Connectivity check:

1. Connect to the workload's instance of the first VPC using SSH.
2. Test the connectivity of the target instance in the second VPC through Application Load Balancer.

Important: Make sure that the Availability Zone or the subnets in the VPC attachment align with the Availability Zone or subnets of the NAT Gateway.

Limitations:

• Routing traffic to a Private NAT Gateway and another VPC makes the on-premises network unidirectional. When the on-premises network is unidirectional, resources on the other side of the connections can't use a NAT gateway.
• You can route your NAT gateway to Transit Gateway only for outbound private communication between two VPCs or a VPC and your on-premises network.
• Because NAT Gateways perform only source NAT, the preceding setup allows only the source to initiate a connection to the destination VPC. If you need bidirectional traffic from the second overlapping VPC to the first, then you must reverse the setup. Create the NAT Gateway in the second VPC, and have Application Load Balancer target the instance in the first VPC.