In this lesson, we are going to go through a high-level overview of the most common Cisco SD-WAN Cloud onRamp designs when it comes to integration with Amazon Web Services (AWS). The focus of each design is how to deploy secure network connectivity from remote locations within the SD-WAN fabric to one or more Amazon Web Services (AWS) virtual private clouds (VPCs) using the Cisco SD-WAN Cloud onRamp for Infrastructure as a Service (IaaS) feature.

A VPC is an on-demand virtual network, logically isolated from other virtual networks within an IaaS public cloud. 

Design Option 1 - Using a Transit VPC

This is the most common design option that Cisco SD-WAN support. A pair of WAN edge routers are deployed within a transit VPC that has the single purpose of transporting traffic between other Host-VPCs.  These host VPCs are connected to the transit VPC using AWS Site-to-Site VPN connections as is visualized in figure 1 below:

As with all network designs, this one has its own advantages and disadvantages.

Pros:

• Extended fabric - The main benefit of this design is that it extends the Cisco SD-WAN overlay fabric into the AWS cloud. This allows all remote locations that are part of the SD-WAN fabric to use advanced features such as Application-Aware Routing (AAR) to choose the best path to reach application hosted in the cloud provider. This is visualized in figure 2 where a client in a branch site communicates with an application hosted in a private VPC in AWS. The Cisco SD-WAN overlay fabric chooses ISP-1 over ISP-2 as the best performing transport to AWS based on the AppQoE score calculated by AAR.
• Fully Automated - This design is fully automated and managed through the vManage GUI.

Cons:

• Scale - The major drawback of this design option is that each host VPC has to establish an AWS Site-to-Site VPN tunnel to each vEdge in the transit VPC.  Therefore, each host VPC that the organization has in AWS would add four additional IPsec tunnels since each AWS site-to-site VPN consists of two IPsec tunnels and there are two vEdges in the transit VPC. Hence, as the number of Host VPCs increases, the number of IPsec tunnels increases x4 and at some point, the limit of supported IPsec tunnels would be reached at the WAN edge devices.

Design Option 2 - Using a Transit VPC as a Cloud Gateway (CGW)

This design option again extends the overlay fabric into the cloud through a transit VPC. However, host VPCs are now connected to an AWS Transit Gateway (TGW) instead of directly to the Transit VPC.

The AWS TGW connects to the transit VPC through VPN attachments.  This design is referred in the Cisco documentations as the SD-WAN Cloud Gateway (CGW).

Pros:

• Extended fabric - This design option also extends the Cisco SD-WAN overlay fabric into the AWS cloud. This allows all remote locations that are part of the SD-WAN fabric to use advanced features such as Application-Aware Routing (AAR) to choose the best path to reach application hosted in the cloud provider.
• Scale - This design option is more scalable than the above one because each host VPC is connected to the Transit Gateway (TGW) via a VPC attachment instead of a VPN attachment (AWS site-to-site VPN per VPC). 

Cons:

• Not fully automated yet - Implementing Cloud onRmp Cloud Gateway design is not fully automated in the present vManage version 20.3.1. Onboarding existing AWS Transit Gateway with connected host VPCs requires manual setup and extensive AWS knowledge.

Design Option 3 - Using a Transit VPC as a Cloud Gateway with TGW Connect

Cisco has recently announced that the new version of vManage will support automation of the entire orchestration of the Transit Gateway deployment and VPC networking, hence reducing the manual operations that I have classified as a downside of the above design option.

The new design will support the AWS TGW Connect attachments. These connect attachments are in essence GRE tunnels running BGP on top. They support 4 times higher bandwidth than the regular IPsec tunnels and eliminate the costs of maintaining many IPsec tunnels.

Pros:

• Higher bandwidth with GRE tunnels - the GRE tunnels offer 4 times more bandwidth than the IPsec tunnels
• Private IP addresses - Removing the IPsec tunnels removes the need for public IP addresses. Organizations can now deploy this design using private IP space which greatly reduces the cyberattack surface.
• Increased route limit - Currently the BGP route limit is 100. The new architecture promises to increase to significantly increase this limit.
• Increased visibility into the cloud - Integration with Transit Gateway Network Manager will allow for telemetry data exchange between vManage and TGW, which will subsequently increase the level of visibility within the cloud. 

Cons:

• Still not available as of present-day - vManage version 20.3.1

Design Option 4 - Using a Transit Gateway (TGW)

Another design option is to use a Transit Gateway (TGW) that aggregates all host VPCs, and then also connect the vEdges at remote locations directly to the AWS Transit Gateway as is visualized in figure 5.