When does SD-WAN make sense?

This is an important question, with a simple answer: it depends. And the main thing it depends on is, why an organization wants an SD-WAN in the first place. Answering that goes a long way to answering the size question.

The baseline assumption is that the IT department sees a need for the organization to have a iprivate WAN, rather than every site communicating solely over the public internet.

This is not a trivial assumption any more. As little as a decade ago, it was standard to have a private WAN for even two or three locations, since they would most likely be sharing back-end services of some sort from a common data center. Today, no such assumption can be made. Many companies grow to have many sites without needing private connectivity among them because everything they do is hosted in one or another external cloud. And, as some organizations migrate services out of data centers, they find that they need private WAN links at fewer sites or only at their data centers.

For an organization needing a WAN, SD-WAN can usually provide a better one, better because it is more resilient, thanks to SD-WAN’s signature ability to combine and balance traffic across multiple active links. And better also because it is more consistent in configuration, thanks to the broad and deep automation built into SD-WAN.

This consistency contributes to resilience because a huge portion of outages come down to configuration errors. SD-WAN reduces cybersecurity risk for the same reason—a huge portion of compromises are rooted in configuration errors. Being more resilient and better managed makes the WAN less risky, reducing business risk from outages and exploits from attackers. SD-WAN also requires less staff time to operate and troubleshoot, making it more labor efficient.

Hub-and-spoke or meshed WAN?

If the need for the WAN is only to support hub-and-spoke communications with applications housed in a data center, engineers might reasonably opt for site-to-site internet VPNs from each branch to that data center, managed via conventional WAN configuration tools. The number of VPNs to configure is equal to the number of sites, and adding a site requires modifying configurations on only the new site and the hub site. With proper rigor, this can be managed with reasonable reliability for up to a couple dozen sites.

However, if the WAN has to support a full mesh with each branch talking directly to all the others, VPNs become less attractive rapidly as the number of sites increases. For example, five sites would require 10 VPNs, 10 sites would require 45, and 20 would require 190. Managing such a rapidly growing set of site-to-site VPNs directly—including touching the configuration at every old site whenever a new site is added, or any existing site is dropped or modified—is an immensely more challenging task. Turning that level of work over to an SD-WAN makes sense even if you’re connecting very few sites: three or four are enough if the expectation is that the number will grow soon and for some time.

And of course if every site is also set up with multiple network links for resilience, the amount of configuration work is multiplied. That strengthens the case for SD-WAN both to manage point-to-point communications and all the failover of traffic in the event a link goes down. While other tools can automate these types of configuration tasks, SD-WAN is designed to handle exactly these kinds of automation.

Counting the costs

Cost is also a consideration, and in 2016 Nemertes built an SD-WAN cost model to address it. The goal was and still is to provide a rough estimate of cost savings or increases with SD-WAN based on an organization’s current network and its preferences going forward. After using the tool with clients for three or four years, we saw that about 20 sites was the number where SD-WAN would cost less than a traditional WAN. Results varied depending on factors including the level of discounting they got from equipment vendors and service providers, and on how many internet links and MPLS links (if any) they expected each site to have going forward.

Over time, SD-WAN adoption forced MPLS providers to steadily reduce the premium they charged vs. business internet.  By 2021, large customers saw the MPLS premium drop to as little as 13% on a per-Mbps basis for connections of 10Mbps or more, and the breakeven point for adopting SD-WAN dropped well below 20 sites.

That said, if the plan is to go all-internet and have multiple internet links at every site in order to reduce WAN downtime then the addition of SD-WAN can’t be justified on the grounds of hard-dollar savings; it only increases both startup and ongoing maintenance costs.

However, the soft-dollar case can still be compelling. All the points made above about managing complex networks still apply, and the labor saved and down-time avoided represent real returns on the investment.

So, how small is too small? For most organizations, more than a handful of sites is enough to justify SD-WAN, if the need is for really resilient and well-secured private connectivity among sites.