This post is part of my note taking while studying for the AWS Certified Advanced Networking - Specialty certification.
There are a couple ways to peer VPCs with overlapping IP ranges without changing the addresses for hosts in the VPC. They are all variations on a theme: create more subnets and use separate route tables for the subnets. We’ll go over a few in more detail here. Remember the best practice: unique routing tables per subnet.
Two Subnets in Shared Services VPC
This design is used when peering a VPC that has shared services in the common VPC. The two separate subnets in the Shared Services VPC cannot talk to both subnets but they can each talk to one. Remember that VPCs do not carry transit traffic so we needn’t be worried about VPC Alpha and VPC Beta talking to each other.
Two Subnets in Remote VPCs
Thsi design is used when the Shared Services VPC only has one subnet. There is a catch here, if host 192.168.2.55⁄32 in VPC Alpha sends traffic to the Shared Services VPC, the host in the Shared Services VPC will send it to VPC Beta, per its route table. If that host really needs to communicate with the Shared Services VPC and there isn’t a 192.168.2.55⁄32 host in VPC Beta, you could add a route to 192.168.2.55⁄32 via pcx-123456. The more specific route would be chosen by traffic in reply to 192.168.2.55.
One Subnet in Local & Remote VPCs (/32 Routing)
This is used when you only have a few hosts in one of your peered VPCs that you need to access. These IPs should not overlap with any hosts you want to communicate with in another subnet.
Overlapping IPs is bad for everyone. If at all possible, plan for non-overlapping ranges or Re-IP where necessary. The one things we didn’t go over here was using NAT instances or NAT/Firewall IPSec tunnels to communicate across subnets. The obvious drawback here is you only have 1 IP to route to.