Menu
Transit Network VPC (Cisco CSR)
Transit Network VPC (Cisco CSR)

Transit VPC Components

As described in the Architecture Overview, at the core of the design is a VPC (the transit VPC) that acts as a central hub for traffic flowing to any other destination, whether it be another VPC or a remote network. The transit VPC hosts two CSR instances that allow for VPN termination and routing. This solution uses two AWS Lambda functions, the VGW Poller and the Cisco Configurator, to automatically configure VPN connections between these instances and spoke VPCs.

The following diagram gives an overview of the various components and steps involved in connecting spoke VPCs to the transit network. (See Appendix A for detailed information.)


      Connecting spoke VPCs to the transit network

Figure 2: Connecting spoke VPCs to the transit network

The process for adding a new spoke VPC is as follows:

  1. Every (1) minute, an Amazon CloudWatch event invokes the VGW Poller Lambda function, which iterates through each AWS Region of a customer’s account, searching for appropriately tagged spoke VGWs (default tag key transitvpc:spoke, default tag value true) that do not have existing transit VPC VPN connections.

  2. When the VGW Poller identifies an applicable spoke VGW, it creates the corresponding customer gateways (if required) and VPN connections to each CSR, and then saves this connection information to an Amazon S3 bucket using S3 SSE-KMS. All data in the S3 bucket is encrypted using a solution-specific AWS KMS managed customer master key (CMK).

  3. The S3 Put event invokes the Cisco Configurator Lambda function, which parses the VPN connection information and generates the necessary config files to create new VPN connections.

  4. The Cisco Configurator pushes the configuration to the CSR instances using SSH.

  5. As soon as the Cisco configuration is applied onto the CSR instances, the VPN tunnels come up and Border Gateway Protocol (BGP) neighbor relationships are established to the spoke VPCs.

The process for removing an existing spoke VPC is as follows:

  1. Every (1) minute, an Amazon CloudWatch event invokes the VGW Poller Lambda function, which iterates through each AWS Region of a customer’s account, searching for spoke VGWs to remove. Spoke VGWs to remove have existing transit VPC connections, but either lack the spoke VPC tag (because it has been removed) or the spoke VPC tag value has been changed from the expected value.

  2. When the VGW Poller identifies an applicable spoke VGW for removal, it deletes existing VPN connections to each CSR, saves the existing connection information to an Amazon S3 bucket using S3 SSE-KMS, and deletes any corresponding customer gateways (if no longer required). All data in the S3 bucket is encrypted using a solution-specific AWS KMS managed customer master key (CMK)

  3. The S3 Put event invokes the Cisco Configurator Lambda function, which parses the VPN connection information and generates the necessary config files to remove the VPN connections.

  4. The Cisco Configurator pushes the connection-removal configuration to the CSR instances using SSH.