What Is SD-WAN? Software-Defined WAN Explained

Three pieces do the work. An edge appliance sits at each branch and terminates the local transports. A controller holds the policy and the topology and distributes both. And an overlay — an encrypted tunnel mesh built across whatever underlying links exist — carries site-to-site traffic independently of who provides those links. Because the overlay is decoupled from the underlay, a site can change internet providers without the application policy changing at all.

On top of that sits the part buyers actually notice: application-aware path selection. The appliance identifies traffic — by application signature, by destination, by DSCP marking or by policy — and matches it to a path whose current measured performance suits it. Voice and video go on the link with the lowest jitter; bulk backup goes on the cheapest one; a SaaS application may break out directly to the internet rather than being hauled back to a datacentre first. When a path degrades, flows move without a human deciding, and some implementations can duplicate or forward-error-correct critical traffic across two paths at once so a lossy link stops being audible on a call.

Historically a branch network meant a private WAN — most often MPLS — with a router at each site, static routing policy, and any internet-bound traffic backhauled to a central firewall before it went out. That design was coherent when applications lived in a datacentre. It became expensive and slow once most of the traffic was headed for cloud services that the backhaul route reached the long way around.

SD-WAN does not necessarily remove the private circuit. The common outcome is hybrid: keep a smaller MPLS or dedicated circuit for the traffic that genuinely needs guaranteed transport, add cheaper broadband and often a cellular backup alongside it, and let policy decide what uses which. The saving comes from carrying bulk and internet-bound traffic on commodity links instead of premium ones, and from local internet breakout removing the backhaul hop for cloud applications. The management saving — one policy instead of hundreds of device configurations — is frequently the larger of the two and the harder one to put on a spreadsheet.

The appliance is a branch router with more responsibilities. It terminates the local links, builds and maintains the encrypted overlay tunnels, measures every path continuously, classifies traffic, applies the central policy, and reports telemetry back to the controller. Many models also carry local firewalling, and in a growing number of designs the security functions are delivered as a cloud service that the appliance steers traffic into rather than performing itself.

Sizing is driven by throughput with encryption enabled, not by port count, and it is worth checking the vendor's figure with the features you will actually turn on — deep inspection and encryption both cost capacity. Beyond that, the practical questions are physical: how many WAN interfaces the site needs, whether it needs an integrated cellular modem or a separate one, whether it will be wall-mounted in a cupboard or racked, and whether the site needs a second appliance for redundancy. A small branch and a regional office rarely take the same model, so an estate is usually two or three appliance types rather than one.

The hardware is the visible part and usually the smallest line: an appliance per site, sometimes two, plus any cellular modems, antennas, transceivers, mounting and cabling. It is also the part that is easiest to price, which is why it dominates early conversations and misleads early budgets.

The licensing is recurring and is where most of the money sits. Vendors licence SD-WAN by site or by bandwidth tier, in subscription terms, and the tier usually governs which features are available — advanced path remediation, application visibility, integrated security and cloud on-ramps are commonly gated. The controller or orchestrator itself is licensed, whether hosted by the vendor or run by the customer. Support contracts and hardware replacement terms are separate again, and on a distributed estate the replacement service level matters more than it does in a datacentre.

The service half is the one that gets under-scoped: designing the policy and the topology, staging and pre-configuring appliances before they ship, coordinating circuit orders with providers whose lead times drive the whole schedule, running the migration site by site without dropping the sites still on the old design, and then operating it. Some organisations run it themselves; many buy it as a managed service. Uniqcli quotes all three together — appliances, subscriptions and the deployment and lifecycle work — on one document, because splitting them across separate purchase orders is the most reliable way for an SD-WAN programme to lose its schedule.

Start with the circuits, because they are the long pole. Broadband and cellular can be provisioned quickly; a new private circuit to a branch can take months, and the migration plan has to be built around the slowest site rather than the fastest. Inventory what each site actually has today, what it can get, and when — before any appliance model is chosen.

Then check the boundaries. What the SD-WAN vendor does and does not consider security is the most common surprise: some platforms include full firewalling at the edge, some expect a separate firewall, and some assume traffic is steered into a cloud security service that is licensed separately. Confirm which model you are buying and what it implies for the sites that break out locally to the internet. Finally, confirm the licensing term and what happens at renewal — the appliance is capital, the licence is not, and an estate whose subscription lapses does not degrade gracefully.