How to Design an Enterprise SD-WAN
A requirements-led guide to SD-WAN topology, underlay choices, traffic policy, security boundaries, resilience, operations, and growth.
By Mark Poulton
How to Design an Enterprise SD-WAN
An enterprise SD-WAN should be designed from the traffic, application, site, security, and operational requirements it must support. Start by documenting those requirements and constraints; then choose topology, transports, policy, and failure behaviour that can be tested against them. There is no single topology or platform that suits every network.
What should an SD-WAN design account for?
| Design area | Establish before choosing a design | Questions to answer |
|---|---|---|
| Applications and users | Important workflows, locations, dependencies, and traffic patterns. | Which application paths have requirements that differ from the general case? |
| Sites and topology | How locations communicate and where shared services are reached. | Which flows need a hub, a direct path, or a combination? |
| Underlay | Available transports, service terms, capacity, and known failure dependencies. | Which connections can carry each path, and are claimed backup links genuinely independent? |
| Traffic policy | Application identification, path preference, prioritisation, and exceptions. | What conditions change the selected path, and what should happen when none meet policy? |
| Security boundaries | Required inspection, segmentation, and ownership on each traffic path. | Where are controls enforced, and which team investigates events or approves exceptions? |
| Operations and growth | Monitoring, change processes, support skills, and expected site or traffic changes. | Who maintains policy, validates changes, and diagnoses the complete path? |
The SD-WAN architecture article explains the components and topology patterns. This article focuses on turning requirements into design choices rather than repeating that vocabulary.
How should topology and traffic paths be selected?
Map representative user-to-application flows before selecting hub-and-spoke, mesh, or hybrid connectivity. A hub may provide a controlled transit point for selected traffic; a direct path may avoid an unnecessary detour for another flow. Each path changes where traffic is inspected, which links it uses, and which operations team can troubleshoot it.
Do not choose a topology based on the name alone. Check site-to-site requirements, application dependencies, control placement, available link capacity, and the effect of losing a hub or transport. For a comparison of MPLS, SD-WAN, and hybrid service choices, see MPLS vs SD-WAN.
How should underlay and path policy be planned?
Record each candidate connection's service characteristics and operational dependencies. More than one link does not automatically provide resilience if the paths share a provider, physical route, power source, or upstream service. Define which traffic may use each link and what the edge should do when conditions no longer meet policy.
Policy should reflect application requirements and observed network conditions, not assumed application performance. Decide how traffic is identified, how exceptions are approved, and how priority or path changes are tested. Avoid treating a policy preference as a service guarantee.
Where should security controls sit?
Map inspection, segmentation, encryption, and identity dependencies onto the actual traffic paths. Some controls may be placed at an edge; others may be delivered through a connected or cloud service. The design should state what is inspected, what can bypass inspection, what is logged, and who owns each control. For a focused discussion of these responsibilities and the SD-WAN/SASE boundary, see SD-WAN security.
Plan for operations and change
Include management reachability, telemetry, support hand-offs, policy review, and recovery procedures in the design. Test representative paths and failure cases before broad rollout; record the expected result, observed behaviour, exception owner, and rollback condition. Detailed rollout challenges are covered in SD-WAN deployment: risks, sequencing, and mitigation, and outcome measures in measuring SD-WAN success.
A sound design remains reviewable as sites, applications, and requirements change. Treat scale and platform capabilities as requirements to verify, not as outcomes guaranteed by a product label. Cloud-native service models are covered separately in cloud-delivered SD-WAN.