Before we begin, let's first define what is Infrastructure as a Service (IaaS). IaaS is a virtualized computing infrastructure, provisioned and managed over the Internet that can be used to host and deliver enterprise applications.
The Business Need
Infrastructure as a Service (IaaS) has many benefits over the on-premise data center infrastructure. To list a few:
- It can scale up and down as the business demand changes;
- It drastically reduces the time to market;
- It decreases capital expenses and reduces ongoing costs;
- It has better security than on-prem;
- And many more.
The most popular IaaS providers are Amazon Web Service (AWS), Microsoft Azure, and Google Cloud (GCP). Extending the enterprise network to a public cloud provider can be a challenging task though. Each cloud provider has different connectivity and provisioning models.
What is Cloud onRamp for IaaS?
Cloud onRamp for IaaS is a set of capabilities that extend the Cisco SD-WAN overlay fabric to a public cloud instance. This allows remote branches, campuses, and data centers within the SD-WAN overlay fabric to leverage features such as Application-Aware Routing (AAR) to choose the best path to reach the applications hosted in private VPCs within a public cloud provider such as AWS, Azure, or GCP. Cloud onRamp for IaaS is designed to automate the connectivity to IaaS workloads and most importantly to provide visibility into the cloud.
The connection between the SD-WAN overlay fabric and a public-cloud application is provided by a pair of redundant virtual WAN edge routers as is visualized in figure 2. These virtual SD-WAN devices (vEdge Cloud or Cisco CSR1000V) act as a transit between the overlay fabric and the applications hosted in the cloud. They provide device level and path resiliency to the connectivity to the public cloud.
A high-level overview of the steps required to deploy a Cloud onRamp for IaaS are:
-
Identify a pair of unused vEdge Cloud routers in Cisco vManage.
-
Attach a basic device template to both devices.
-
Enter the cloud provider's credentials (AWS or Azure API access and secret keys).
-
Add the transit Virtual Private Cloud (VPC) or transit Virtual Network (VNet) configuration depending on the cloud provider.
-
Discover and map host VPCs or host VNets to the transit VPC/VNET.
The infrastructure on AWS and Microsoft Azure can be seamlessly integrated into the overlay fabric. Once integrated into the fabric, the cloud vEdges can be managed using the same templates, security, and other Cisco SD-WAN policies which are used on-premises and on other clouds.
Cloud Terminology
Before we see how Cloud OnRamp for IaaS is implemented in AWS and Azure, let's introduce some cloud terminology that will come in handy later on.
Description | AWS | Azure | GCP |
---|---|---|---|
Customer Hierarchy | Organization > Accounts > Users > API/Secret Keys | Tenant > Subscriptions > Users > Client IDs/Secrets | |
Geography | Regions > Availability Zones > VPCs | Locations > Availability Sets > VNETs | Regions > Zones > VPCs |
VMs | EC2 instances | Azure Virtual Machines | Compute Engine |
Virtual Networks | AWS Virtual Private Cloud (VPC) | Virtual Network (VNET) | Google Virtual Private Cloud (VPC) |
Dedicated Connection | AWS Direct Connect | Azure ExpressRoute | Google Cloud Interconnect |
Internet Gateway | IGW | Internet Gateway | |
IPsec VPN Gateway | VGW | Azure VPN Gateway | Cloud VPN |
Security | Security Groups / ACLs | Network Security Groups (NSG) | Compute Engine Firewall Rules |
Cloud onRamp for IaaS with AWS
Amazon Web Services (AWS) is the biggest Infrastructure-as-a-Service provider as of present. A virtual on-demand network on AWS is called a virtual private cloud (VPC). A VPC is logically isolated from other virtual networks (VPC) within the AWS infrastructure. The cloud provider allows traffic to flow between different VPCs within a region or between regions through VPC peering connections. However, AWS does not allow traffic to transit through a host VPC. This means that traffic must either originate or terminate within a virtual provide cloud (VPC) but not pass through it. If we consider this at scale, as the number of VPC instances increases, the amount of VPC peerings between the instances would increases dramatically if full-mesh connectivity between VPCs is a requirement.
Cloud onRamp for IaaS is designed to solve these scaling issues by implementing a networking construct called a Transit VPC. A Transit VPC can connect multiple VPCs that might be geographically disparate or running in separate AWS accounts.
Within the VPC dedicated to function as a transit point, a pair of Cisco WAN Edge routers are deployed to route the traffic between the host VPCs. Each vEdge is instantiated within a different availability region within the transit VPC for resilience in case of failure and is automatically provisioned with the following:
-
A transport VPN 0, also available via an AWS Elastic IP address
-
A management VPN 512, available via an AWS Elastic IP address (public IP address)
-
One or more service VPNs which have a range from 0 - 65528
The transit VPC also provides the entry point from AWS into the Cisco SD-WAN overlay fabric. The AWS VPN gateway at each host VPC establishes redundant site-to-site VPN connections to each vEdge cloud router within the transit VPC, through the service VPN side of the Cisco vEdge cloud routers.
Full Content Access is for Registered Users Only (it's FREE)...
- Learn any CCNA, DevNet or Network Automation topic with animated explanation.
- We focus on simplicity. Networking tutorials and examples written in simple, understandable language for beginners.