The Oversimplification of SD-WAN for Cross-Cloud Strategy

Are you confident in your cross-cloud strategy? Think again. Many organizations make the mistake of assuming that extending their SD-WAN to the public cloud is as straightforward cross-cloud strategy. This oversimplification can lead to significant operational and scalability challenges. To truly leverage the power of cross-cloud connectivity, you need a well-planned and meticulously designed approach that integrates seamlessly with public cloud networking services. Here’s why your cross-cloud network strategy needs more than just IPsec tunnels between public clouds and why careful planning is crucial for success.

Cross-cloud Network Strategy

Cross-cloud represents a new approach to multi-cloud infrastructure and is especially useful for connecting public cloud environments. It involves utilizing multiple cloud platforms or services to run a single application or workload, thereby minimizing overhead. This is different from multi-cloud, which involves using multiple clouds to achieve flexibility to choose the most suitable options, allowing each workload to operate in the optimal environment.

Evaluating cross-cloud connectivity strategy has never been more crucial. However, public clouds are not inherently designed to interconnect, making the task of running applications across multiple clouds difficult.

That is why it is increasingly common to see examples of organizations that choose to address their multi-cloud and cross-cloud strategies by extending their SD-WAN solution to the public cloud. Fundamentally, this option extends the SD-WAN fabric into the public cloud using Infrastructure as a Service (IaaS), deploying Network Virtual Appliances (NVAs) from the SD-WAN provider.

Underlay

SD-WAN technology typically creates a transport-agnostic virtual overlay. This is achieved by abstracting underlying public or private WAN connections. However, it relies on an underlay network to build an overlay network based on tunnels. There are many concerns with running tunnels over the Internet, as an underlay, to the public cloud. Among these are scalability and complexity with many public cloud providers, which limits visibility and control. Furthermore, using the public Internet can significantly decrease performance.

Consuming a third-party backbone for WAN connectivity (Network as a Service model) with agreed Service Level Agreements (SLAs) is a good alternative. This option provides a simple, scalable and solid network foundation for multi-cloud and cross-cloud strategies.

Overlay

As mentioned above, deploying NVAs to extend the SD-WAN fabric into the public cloud using IaaS is becoming more popular. This approach is even more common for organizations that, due to security requirements such as those in the banking sector, need to encrypt traffic even over a private underlay network.

The mistake lies in assuming that establishing IPsec tunnels between NVAs in public clouds and with on-premises environments constitutes a robust multi-cloud/cross-cloud strategy. This assumption is an oversimplification. Organizations that accept this statement as true and implement it are encountering significant difficulties in scaling and operating their multi-cloud and cross-cloud communications on day two.

The reasoning is simple: an overlay network based on IPsec tunnels from SD-WAN providers is built completely decoupled from public cloud network services. The result is a lack of interoperability. The situation worsens when these NVAs not only perform SD-WAN functions and cross-cloud traffic, but also handle east-west and north-south traffic routing and inspection. They suddenly become the most critical control plane components for routing, but on their own, they cannot integrate with the public cloud or communicate in the “same language”.

Some organizations try to resolve this integration issue between SD-WAN and public cloud with static routing, manual configurations or complex automation techniques. This is an unfortunate decision that will undoubtedly lead to operational, agility and scalability problems—exactly the opposite of what a cross-cloud strategy aims to achieve.

Technical Solution

If we want to follow this path, the integration factor between SD-WAN and public cloud network services is crucial and needs to be carefully considered to achieve a robust communication strategy to support production environments.

To do this, there are two alternatives:

• The first is to look for a native network service from the cloud provider that can integrate the public cloud’s routing control plane with the SD-WAN provider’s routing control plane. The key here is BGP, which can exchange network prefixes for end-to-end reachability. Services such as Azure Virtual WAN, AWS Transit Gateway and GCP Network Connectivity Center can be used for this purpose.

In this way, we can delineate the functions of the NVAs. If their role is to satisfy WAN and multi-cloud/cross-cloud connectivity, we should not use them for intra-cloud routing (between VNets/VPC spokes) because that is not their intended use. Nor should they be used as intra-cloud firewalls; instead, evaluate solutions from each cloud provider or additional clusters from third-party providers. It’s important to have a simple, well-defined and distributed architecture where the function of each component is clear, without single points of failure and leveraging the value of each component.

• The second alternative is to adopt multi-cloud/cross-cloud connectivity solutions that are agnostic of the public cloud provider and interoperable with all of them. This approach also results in an overlay network based on IPsec tunnels, but the key difference is that these technical solutions integrate directly with public cloud providers, they “speak the same language”. They feature robust reference architectures with well-defined Edge, Transit and Application layers and usually provide additional functionalities on top of connectivity, related to security and visibility. With a single solution, the hybrid and cross-cloud network can be managed as one, without needing to understand the specifics of each public cloud. This provides a single interface to configure and operate the entire network.

Conclusion

Assuming that cross-cloud strategies with SD-WAN function in the cloud the same way they do in on-premises environments is a significant oversimplification. Many organizations encounter operational and scalability challenges by extending SD-WAN to the public cloud without adequate planning and design. To avoid complexities in the control plane and ensure efficient traffic flows, it is crucial to adopt a thoughtful, well-designed approach that seamlessly integrates SD-WAN solutions with public cloud networking services. By carefully architecting your multi-cloud and cross-cloud network strategy, you can ensure efficient, reliable and secure production operations. Remember, successful cross-cloud connectivity requires more than just IPsec tunnels between NVAs in the public cloud; it demands control plane strategic planning and meticulous design.

Network discussion in cross-cloud strategy conversations cannot be an afterthought when it is too late to do it right. Don’t let oversimplification hinder your cloud networking ambitions.