I’ve been spending a lot of time the past few weeks reviewing SD-WAN vendor cloud offerings. Maybe it’s because of some the announcements in the area. It triggered a bunch of questions from my customers. Maybe it’s because a lot of folks seem to be waking up to the importance of connecting their SD-WAN into the cloud.
Regardless, what’s become increasingly apparent to me are the vast differences between vendor implementations. At first glance, the cloud would seem to be just like any other site. Add an SD-WAN node as you would with any other location, let it connect into the SD-WAN, and voila! Job done. Oh, how I wish it was that simple.
SD-WAN cloud configurations are like that sweet, devilish 5-year old who can terrorize your home while looking delightfully cherubic. Different tools are needed to manage cloud implementations than the cloud. Routing into the IaaS cloud is rarely simple. Properly configuring the cloud—setting up the VPCs, installing the SD-WAN nodes, provisioning the IPsec connectivity—all take time. It’s why SD-WAN vendors have made a point of introducing cloud-specific implementations.
SD-WAN vendor cloud approaches
From what I’m seeing, SD-WAN players with support for IaaS all target AWS with a few delivering solutions for Azure and Google Cloud. There are two basic approaches taken to extending the SD-WAN fabrice to IaaS, which has a lot to do with whether or not the vendor offers an SD-WAN appliance or an SD-WAN service. Appliance vendors will place a dedicated SD-WAN node in the IaaS service; service providers will place a shared node near the IaaS service. Let me explain.
SD-WAN appliances are two-sided architectures. You need an appliance on either end of the connection in order to work. You’ll have an SD-WAN appliance on your premises, but the other end of the connection has to terminate in IaaS service. Since you’re going to be responsible for the deployment that means getting an SD-WAN appliance into the IaaS data center, or more specially that means deploying an instance into the IaaS data center.
The IaaS instance can be a shared gateway running on its own VPC (in AWS parlance) providing the SD-WAN access to rest of the company’s VPCs and resources in the IaaS service. This is the model Viptela (now Cisco) introduced during the summer with Cloud onRamp for IaaS. Alternatively, the IaaS node can be dedicated gateways running on each of your VPCs, connecting back to the rest of the SD-WAN. This is the model used by several SD-WAN vendors, including Cisco Meraki, NetScalar, Riverbed, Silver Peak, and Viptela. Regardless of the approach, customers can choose to go across the public Internet to reach the IaaS service or a high-speed interconnect from their MPLS WANs (ExpressRoute for Azure or DirectConnect for AWS).
Services providers may take the same approach as appliance vendors, if they’re just delivering a managed service built on third-party, SD-WAN appliances, but service providers also have another approach available to them. They may integrate IaaS into their service by placing one of their PoPs near, and at times within, the same physical datacenter as the edge of the IaaS service.
Traffic bound for the service is then routed to the PoP and from there to the provider’s data-center. Technically, ExpressRoute or Direct Connect is not being provided by the provider but practically, access should be very fast as traffic only needs to traverse the local network of the hosting facility. Cato Networks takes this approach, moving cloud traffic across its backbone to SD-WAN nodes in or near the same data-centers as AWS. Velocloud takes a similar approach, providing shared gateways to the IaaS services, but relying on third-party partners for backbone connectivity.
Finding the right approach
Like so much about networking, there’s no right approach. It’s a matter of aligning the relative strengths and weaknesses of each model with your company’s requirements. I can tell you there are significant differences in ease of deployment, price, availability and security. We’ll walk through issues in greater detail in our next post.
This article is published as part of the IDG Contributor Network. Want to Join?