Amazon Virtual Private Cloud (Amazon VPC) offers a comprehensive set of virtual networking capabilities that provide AWS customers with many options for designing and implementing networks on the AWS cloud. With Amazon VPC, customers can provision logically isolated virtual networks to host their AWS resources. Customers can create multiple VPCs within the same region or in different regions, in the same account or in different accounts. This is useful for customers who require multiple VPCs for security, billing, regulatory, or other purposes, and want to integrate AWS resources between their VPCs more easily. More often than not, these different VPCs need to communicate privately and securely with one another for sharing data or applications.

This webpage provides AWS customers with high-level connectivity options for multiple VPCs that reside in different AWS Regions. It includes best practices and guidance, and outlines the most commonly used cross-region VPC network configurations. For guidance on connecting VPCs in the same AWS Region, see Single Region Multi-VPC Connectivity.

The following sections offer prescriptive advice for connecting VPCs in different AWS Regions using either non-AWS networks, such as the Internet or a customer’s existing network backbone, or AWS-managed networks. Customers who have already established AWS Direct Connect or VPN connections from on-premises networks to their VPCs typically prefer to reuse existing connections, while customers without existing network infrastructure usually opt for AWS-managed networks. Keep in mind that VPC designs that adhere to networking best practices can be easily changed from one configuration to another, so select the option that makes most sense for your current networking needs.

Many AWS customers have invested heavily in on-premises networks, and use VPN connections or AWS Direct Connect to connect to AWS. These customers often prefer to leverage their existing infrastructure investments to route VPC traffic across regions, either by establishing new VPN connections or using their own corporate network backbone. AWS customers in this scenario often start by connecting on-premises networks to the closest AWS Region, and then look to expand to additional AWS Regions.

This approach enables customers to leverage Internet-based VPN connections and their on-premises infrastructure in a single region to route VPC traffic between regions. This option is best suited for customers who do not have existing network infrastructure investment in the remote region and want to leverage their existing VPN investments to connect VPCs.

This design pattern creates a network hub to route traffic between spoke VPCs in different AWS Regions. Intra-region network connectivity is established using either a VPN connection or AWS Direct Connect (both options are portrayed in the diagram), and cross-region connectivity is established with Internet-based VPN connections.

This approach enables customers to route cross-region VPC traffic over existing corporate networks. This option is best suited for customers who can leverage existing global infrastructure and networks, such as a multinational customer with network connectivity between data centers in multiple locations. It is also appropriate for customers who want to ensure their VPC traffic never traverses a public network.

As in the previous approach, this design also establishes intra-region network connectivity to existing network infrastructure using either a VPN connection or AWS Direct Connect. Cross-region connectivity leverages existing wide area network (WAN) connections by propagating VPC network advertisements within the company’s internal network. Finally, network routing in each VPC must be configured (through either dynamic BGP advertisements or static routes) to route cross-region traffic over the existing network backbone.

This design leverages existing on-premises network equipment and wide area network (WAN) connections to route network traffic between VPCs. It also allows customers to apply additional on-premises network monitoring and controls to inter-VPC traffic. Note that the cross-region network traffic is subject to the specific latency, variability, and available bandwidth of the existing private network connections.

AWS provides high bandwidth, global network infrastructure to support customers’ regional networking needs. AWS Regions are connected to multiple Internet Service Providers (ISPs) as well as to a private global network backbone, which provides lower cost and more consistent cross-region network latency when compared with the public Internet. AWS customers with small on-premises network footprints, limited regional network connectivity, or who simply want to leverage AWS networks often choose one of the following options to connect VPCs in different regions. These options use public IP addresses to route network traffic between regions, using the AWS global network backbone by default. However, use of AWS private network infrastructure is provided on a best effort basis and network connectivity will failover to AWS ISP networks in the unlikely event that private network connectivity between AWS Regions is not available. Note that, for simplicity, the diagrams in this section depict use of AWS backbone network connections and do not depict network failure scenarios where traffic might briefly be routed over public ISP networks.

This approach leverages the Amazon VPC capability to create VPN tunnels between EC2 instances in order to route traffic between VPCs in different regions. This option uses customer- or AWS Partner Network (APN) member-managed, EC2-based software VPN appliances and is best suited to customers who want to manage both ends of VPN connections using their preferred VPN software provider.

This design optimizes cross-region network transfer costs, however it requires customers to design and manage their own HA configuration for EC2 network instances.

Products available in the AWS Marketplace provide additional network control features for monitoring and controlling traffic between VPCs. These include additional security features such as enhanced monitoring, network-protocol-aware firewall rules, or universal threat management capabilities. Note that customers must run network appliances in each VPC, which results in additional EC2 and, potentially, third-party license charges. These EC2 instances can also introduce a single point of failure into the network architecture, and a potential network bottleneck, so be sure to choose a VPN appliance instance size that will meet cross-region network routing requirements. Finally, leverage Auto Recovery for EC2 or other network monitoring and recovery options to decrease the time to recover failed VPN appliances.

This option is best suited to customers who want to leverage AWS-provided, automated HA network connectivity features and also optimize their investments in third-party product licensing. Additionally, this design enables customers to control cross-region network traffic using AWS and third-party network security products.

This design pattern creates dynamically routed VPN connections between spoke VPC VGWs and VPN appliances in one or more transit VPCs (and optionally to on-premises network equipment). The best practice for making a transit network highly available and scalable is to use dynamically routed VPN connections to take advantage of VGW native HA capabilities and reduce network single points of failure. Note that in the diagrams above, all communication with the VPN appliances uses transit VPC Internet gateways and Elastic IP addresses. Additionally, AWS highly recommends the use of Auto Recovery for EC2 or Auto Scaling for automatic recovery of failed EC2-based VPN instances.

Customers can use a transit VPC not only to provide direct network routing between VPCs and on-premises networks, but also to implement more complex routing rules such as network address translation between overlapping network ranges, or to add additional network-level packet filtering or inspection. However, this approach requires the customer to configure and manage the EC2-based VPN instances deployed in the transit VPC. AWS highly recommends leveraging virtual network appliances available in the AWS Marketplace to significantly reduce the level of effort to establish and maintain these VPN connections. This design will result in additional EC2 and, potentially, third-party license charges. Also, be aware that this design will generate additional data-transfer charges for traffic traversing the transit VPC: data is charged when it is sent from a spoke VPC to the transit VPC, and again from the transit VPC to the on-premises network.