What Is SD-WAN: How It Works, How It Differs from VPN, and How to Choose One

SD-WAN (Software-Defined WAN) is a technology for software-defined management of a wide area network that combines different communication channels (internet, leased lines, mobile connectivity) and centrally distributes traffic across them according to defined policies. The core idea is to connect branch offices and the head office flexibly and reliably, without depending on a single expensive channel.

How SD-WAN Works

SD-WAN separates network management from the hardware: policies are defined centrally, and on-site devices execute them. This lets the network pick the best channel for each application in real time.

Key principles:

• Centralized management. Policies are configured from a single console and applied across all sites.
• Channel aggregation. Multiple communication lines work as a shared resource with load balancing and redundancy.
• Application prioritization. Critical traffic gets the best channel; secondary traffic gets whatever bandwidth is left.
• Automatic failover. When a channel degrades, traffic switches to a backup without interrupting services.

What an SD-WAN Solution Consists Of

Behind the general phrase “software-defined network” there is a very specific set of components, and understanding their roles helps you avoid confusing SD-WAN with an ordinary set of routers.

• Edge device (CPE). A physical or virtual gateway at every site — an office, a store, a production facility. It connects to all available communication channels, measures their state, and applies the policies pushed down from the center.
• Orchestrator, or management controller. The central point from which the administrator defines routing policies, application priorities, and security rules. It is the orchestrator that turns a set of separate devices into a managed network rather than a scattering of standalone routers.
• Transport channels. Internet providers, mobile connectivity, leased lines — any channel that physically reaches the site. SD-WAN doesn't require a particular type of channel; it abstracts them into a common pool of resources.
• Policies. Rules that describe which traffic should go over which channel, what to do when a channel degrades, and which applications take priority. Policies are what turn a set of channels into a managed network rather than just parallel communication lines.
• Monitoring and telemetry layer. Continuous measurement of latency, packet loss, and jitter on every channel — the foundation on which automatic route switching is built.

Without any one of these elements, the solution stops being SD-WAN in the full sense: a set of edge devices without a central orchestrator is just routers with more flexible configuration, and an orchestrator without telemetry cannot make well-founded routing decisions.

How the Traffic Path Is Chosen and What Happens When a Channel Degrades

SD-WAN makes its routing decision not once, when the connection is established, but continuously, based on the measured characteristics of every channel.

Here is how it works step by step:

1. Traffic classification. The device identifies the type of application (voice, video, an ERP system, background synchronization) using the rules defined in the policy.
2. Channel state measurement. The orchestrator and the edge devices continuously assess latency, packet loss, and jitter on every available channel.
3. Matching against the policy. Every traffic class has its requirements — voice traffic, for example, doesn't tolerate latency and loss above a certain threshold.
4. Channel selection. Traffic is routed over the channel that meets the policy requirements at that moment, not over the channel that was assigned “by default” during configuration.
5. Continuous reassessment. The routing decision is revisited as channel conditions change rather than fixed once and for all.

The behavior during channel degradation deserves separate attention. SD-WAN distinguishes two states: a complete channel failure (blackout), when the channel is unavailable altogether, and partial degradation (brownout), when the channel technically works but latency, loss, or jitter grow beyond the threshold acceptable for a particular application. A complete channel failure is relatively simple for SD-WAN to handle — traffic switches to a backup channel. Degradation is far harder: the channel is formally alive, but its quality is already insufficient for sensitive traffic. What matters here is not merely the ability to detect the problem, but the speed of reaction — how quickly the solution moves voice or video traffic to another channel before the user notices anything. This is one of the characteristics worth verifying when choosing a solution rather than taking on faith from marketing materials.

How SD-WAN Differs from VPN and MPLS

In short: a VPN creates an encrypted tunnel, MPLS is a carrier's dedicated network service, and SD-WAN manages any channels according to policy and picks the route itself.

• VPN encrypts the connection but doesn't manage quality or channel selection.
• MPLS delivers predictable quality but is expensive and inflexible when connecting new sites.
• SD-WAN works on top of any channels, adds intelligent routing and centralized management, and often includes VPN as one of its mechanisms.

A detailed comparison, with practical scenarios and criteria for choosing between the technologies, is available in the article SD-WAN vs VPN.

Security in SD-WAN

SD-WAN isn't only about connectivity — it's also about protecting traffic between sites. Modern solutions combine networking and security functions: channel encryption, segmentation, and access control. This matters especially when traffic between branches travels over the public internet rather than leased lines: without encryption and segmentation, cheaper channels translate directly into higher risk. Check the exact set of security features against the product documentation.

It is important to understand that the SD-WAN transport layer is not self-sufficient in terms of security. As soon as a site gets direct internet access instead of sending traffic through the central data center, every point of presence becomes a potential entry point for an attacker — and the more sites there are, the wider that surface. This is exactly why production deployments are shifting from “plain SD-WAN” to Secure SD-WAN, where the firewall, traffic inspection, and segmentation are built in at the level of every branch rather than at the center alone. What exactly such a solution includes and how it differs from basic SD-WAN is covered in the article What Is Secure SD-WAN.

SD-WAN should also be told apart from the approach to user access: SD-WAN is responsible for connectivity between sites and the quality of traffic between them, not for which particular employee may reach which application. That task is handled by the Zero Trust Network Access model: it verifies every access request regardless of the channel and the network it arrived through.

Does SD-WAN Cut Network Costs

SD-WAN often helps cut costs by letting you use ordinary internet channels instead of expensive leased lines, without sacrificing reliability. The savings come from combining several inexpensive channels and automatic redundancy. That said, the real-world effect depends on network topology and quality requirements, so the economics should be calculated for your specific infrastructure rather than taken from general promises.

How to Choose SD-WAN

When choosing SD-WAN, focus on manageability, fault tolerance, and built-in security. Useful criteria:

• Ease of centralized management and scaling across many sites;
• Support for different channels and the quality of automatic failover;
• Built-in security features and segmentation;
• Visibility and monitoring of network state;
• Fit for your infrastructure and deployment scenarios.

Russian companies additionally check whether the solution is listed in the Russian software registry and what regulatory requirements apply — this should be verified against the product documentation.

Typical SD-WAN Deployment Scenarios

SD-WAN delivers the most value where the network is distributed and business-critical. Let's look at three scenarios in more detail — not as abstract examples, but as a sequence of practical steps.

A Branch Network with a Growing Number of Sites

A company with a branch network runs into the fact that connecting every new location over a leased line takes a lot of time and costs a lot of money. A typical deployment sequence:

1. Document the list of sites and their network requirements — which applications are critical and what traffic passes through each location.
2. Identify the communication channels available at every location: internet providers, mobile connectivity and, where needed, the remaining leased lines.
3. Configure routing policies in the central console — which applications take priority on which channel.
4. Deploy an edge device at a pilot site and verify how the policies work on real traffic.
5. Replicate the configuration to the remaining sites using automated onboarding of the device to the orchestrator.

Connecting to Cloud Services

If a significant share of the company's applications lives in the cloud or in SaaS services, traffic from the office to them shouldn't travel through the central data center — that adds unnecessary latency and loads the central channel for no reason. The steps:

1. Separate traffic to cloud services and SaaS applications into a dedicated class in the routing policy.
2. Configure direct internet access for this traffic class from every site, bypassing the central node.
3. Keep inspection and protection of this traffic at the level of the branch device rather than assuming that it is “inside a protected perimeter anyway.”
4. Check how the solution behaves when the channel carrying cloud traffic degrades — the switchover should be transparent to the user.

Channel Redundancy for Critical Sites

For sites where network downtime directly affects the business — production facilities, points of sale — redundancy is built as follows:

1. Identify at least two independent communication channels for the site, preferably from different providers or based on different technologies (wired internet and mobile connectivity).
2. Configure a policy for automatic switching between channels both on complete failure and on quality degradation.
3. Test the failure scenario not only on paper, but by actually disconnecting the primary channel under controlled conditions.
4. Record the switchover time and make sure that critical applications don't lose their session when moving to the backup channel.

SD-WAN Deployment Stages and What to Check at Each One

Deploying SD-WAN is not a one-off hardware replacement but a sequence of stages, each of which carries its own risk of missing a problem before the network goes into production.

1. Survey of the current network. An inventory of sites, channels, applications, and connection quality requirements. Check: whether all sites are documented, including small and temporary ones, and not just the large offices.
2. Policy design. Defining traffic classes, priorities, and channel switching rules. Check: whether the set of policies covers the company's actual applications rather than a generic template from the vendor's documentation.
3. Pilot deployment. Rolling out at one or several non-critical sites. Check: whether the solution behaves as intended under real rather than synthetic load.
4. Fault tolerance testing. Controlled disconnection of channels and verification of the failover. Check: the reaction time to a blackout and to a brownout, and the behavior of critical applications during a switchover.
5. Rollout to all sites. Mass deployment using automated onboarding of devices. Check: whether the configuration of the replicated sites diverges from the pilot because of manual edits made locally.
6. Operation and monitoring. Continuous observation of channel state and incidents. Check: whether degradation alerts reach the people who are supposed to react to them rather than merely piling up in a log.

Common Mistakes in SD-WAN Deployments

• Porting the old topology without revisiting the policies. If all traffic used to go through the central data center, mechanically enabling SD-WAN on top of the same scheme won't deliver the expected effect — part of the benefit lies precisely in direct access to clouds and to the sites.
• Ignoring security at the branch perimeter. Direct internet access from every site without built-in protection expands the attack surface faster than the network gains convenience.
• Piloting at an atypical site. If the pilot site is simpler or smaller than the rest, the results of the pilot don't reflect the problems that will show up when rolling out to complex locations.
• No real channel failure test. Verification “by documentation” is no substitute for actually disconnecting a channel and observing how the network behaves.
• Underestimating regulatory requirements. For some industries and organizations, certification of the solution and its listing in the Russian software registry matter — these questions are worth closing at the selection stage rather than after the purchase.

How to Check Yourself

Before deciding that you understand SD-WAN well enough to design a network or to discuss one with a vendor, it is useful to answer a few questions:

• Can I explain the difference between a complete channel failure (blackout) and its degradation (brownout), and how SD-WAN handles each of these cases?
• Do I understand why the orchestrator and telemetry are mandatory rather than optional parts of the solution?
• Can I list which security functions are needed at the branch perimeter and why the transport layer on its own does not close these risks?
• Do I understand how the task of SD-WAN differs from the task of ZTNA — connectivity between sites versus a user's access to a specific application?
• Could I describe the pilot stage of a deployment for a specific network of several sites, and not only in general terms?

If the answer to any of these questions is uncertain, that is a normal point from which practice begins, not a reason to postpone it.

Who SD-WAN Is For

SD-WAN is especially useful for distributed organizations with branch offices whose requirements for connection reliability and inter-site traffic protection keep growing. The more sites and the more critical the applications, the more noticeable the payoff from centralized management and automatic redundancy. For a small organization with a single office, the benefit may be less obvious, so the decision should be based on your actual network topology.

What to Consider Before Deployment

Before deploying SD-WAN, it's important to document the current network and its requirements: which sites exist, which applications are critical, which channels are available, and what security and regulatory requirements apply. This shapes both the solution's architecture and its set of policies. The more precisely the network is described upfront, the fewer reworks you'll face during operation.

Hands-On Practice at BI.ZONE Cybersecurity Labs

SD-WAN is best learned on infrastructure that resembles a real multi-site network. In the “Deploying and Administering BI.ZONE Secure SD-WAN” course, you configure routing and security policies on isolated test benches, work through channel failover, and practice operational scenarios. Engineers who set the solution up at sites will find the hands-on course for engineers a good fit, while those who design the network architecture as a whole should look at the course for architects. Product capabilities are described on the BI.ZONE Secure SD-WAN page; you can start learning on the course for engineers page.