VPN connection
is the most commonly used method to connect enterprise data centers to AWS
Virtual Private Cloud. More often than not, enterprises use multiple VPCs, sometimes
across multiple regions. For a large enterprise doing business internationally,
its global data center footprint can be linked to AWS data centers across
multiple continents, thus forming a global hybrid cloud.
Clearly, it
is desirable to have a redundant pair of Customer Gateways to terminate multiple
VPN connections to multiple VPCs. Having dedicated gateway to each VPC is
neither scalable nor cost efficient. Automation will be impossible if new
hardware is required each time a new VPC is created.
However, AWS’s
current VPN connection creation logic is designed to ensure unique tunnel IP
addresses for each connection within a single VPC, but not necessarily
across multiple VPCs. In other words, each time a new VPC establishes tunnels
to existing customer gateway, there is a real risk that address conflict will
bring down existing production traffic.
In this AWS guide, a couple of
workarounds are suggested to support connecting a single customer router to multiple
VPCs. However, neither workaround is elegant. In the first case, implementing VRF
just for the sake of this deficiency creates unnecessary complexity on the
customer’s part, not to mention some devices may not support VRF. In the second
case, which is essentially trial and error, automated VPN creation through
scripting and API becomes extremely cumbersome.
AWS Feature Request
Because each
customer gateway is uniquely identifiable (at least within the region), it seems
logical (and desirable) for AWS to implement a feature to ensure uniqueness of
tunnel address generated for shared customer gateways.
- Phase 1 may support uniqueness within the region, as illustrated.
- Phase 2 may support uniqueness across multiple regions. In a global hybrid cloud, enterprise data centers may connect to multiple AWS regions in multiple continents.