Architecture Overview - Transit Network VPC (Cisco CSR)

Architecture Overview

Deploying this solution with the default parameters builds the following environment in the AWS Cloud.

        Transit network VPC using Cisco CSR on the AWS Cloud.

Figure 1: Transit VPC solution on AWS

This highly available design deploys two VPN appliances (Cisco CSR 1000v instances) into separate Availability Zones of a dedicated transit VPC. Customers can choose to automatically create a new VPC or to use an existing VPC as the transit hub (see AWS CloudFormation Templates for details). Spoke VPCs are connected to the transit network through dynamically routed VPN connections between their virtual private gateways (VGWs) and the CSR instances. This design uses VPN connections to enable routing between any connected network, including external networks or spoke VPCs in other AWS Regions. VPN connections also allow spoke VPC resources to leverage VGW capabilities for routing and failover in order to maintain highly available network connections to the transit VPC instances. Remote networks also connect to the transit VPC using redundant, dynamically routed VPN connections between their customer gateways and the CSR instances. This design supports dynamic routing protocols, which customers can use to automatically route traffic around potential network failures as well as to propagate network routes to remote networks.

Note that all communication with the CSR instances, including the VPN connections between corporate data centers or other provider networks and the transit VPC, uses the transit VPC Internet gateway and the instances’ Elastic IP addresses. Each CSR instance has an associated Amazon CloudWatch alarm that enables automatic recovery of the instance if the underlying EC2 hardware fails.

Along with providing direct network routing between VPCs and on-premises networks, this design also enables the transit VPC to implement more complex routing rules, such as network address translation (NAT) between overlapping network ranges, or to add additional network-level packet filtering or inspection. Although it is possible, we recommend that you consider implementing non-overlapping network ranges for your private networks to simplify the ability to route between remote networks. Although a transit network can be an excellent place to implement NAT rules to compensate for overlapping networks, this adds additional complexity to the network design.

The AWS-to-AWS VPN connectivity in this design relies on software VPN appliances running on the Cisco CSR 1000v instances. It also relies on the capabilities of the hardware VPN device deployed on premises that connects to the software VPN appliance. While every effort has been made to come up with a solid configuration, each customer should verify the configuration and adapt it to their specific needs.


We do not recommend adding other resources in the transit VPC because the primary function of this VPC it to provide a transit overlay network connecting spoke networks. If you deploy resources into the transit VPC, it will require extra steps to connect those resources to the transit network and will not leverage the design’s highly available VGW connections.