What SD-WAN actually is
Traditional WANs were built around private MPLS circuits. They were predictable, but expensive and slow to change. SD-WAN moves the intelligence into software: each site has an SD-WAN edge device or virtual edge, the edges form encrypted tunnels to each other or to cloud gateways, and a central controller pushes application policy.
The important distinction is between the underlay and the overlay. The underlay is the physical connectivity you buy from carriers: business fibre, DIA, MPLS, 4G/5G, leased lines. The overlay is the SD-WAN fabric that measures those links and decides how traffic should move.
The core architecture
| Component | What it does | Questions to ask |
|---|---|---|
| SD-WAN edge | Appliance, VM or cloud edge at the branch, data centre or cloud region. | Can it handle your encrypted throughput with security features enabled? |
| Controller / orchestrator | Central policy, device onboarding, templates and monitoring. | Who operates it - you, the telco, MSP or vendor cloud? |
| Secure tunnels | Encrypted overlay between sites, cloud gateways and service edges. | Which crypto suites are used and how are keys rotated? |
| Application policy | Classifies apps and applies path, QoS and security rules. | Can it identify your real business apps, not only generic ports? |
| Analytics | Measures loss, latency, jitter, link health and app experience. | Can reports prove SLA performance by site and application? |
Where SD-WAN helps
SD-WAN is most useful when a business has many sites, mixed connectivity, high cloud usage or frequent branch changes. A Singapore HQ with branches in Malaysia, Indonesia, Thailand and Australia can blend local broadband, DIA, MPLS and LTE backup while managing policy centrally.
- Application-aware routing. Voice and ERP can prefer low-jitter links; software updates and backups can use cheaper broadband.
- Faster branch rollout. A site can come online using broadband first, then add private circuits later.
- Better resilience. Traffic can fail over in seconds if the active link degrades.
- Cloud alignment. Branches can go directly to SaaS and IaaS instead of hairpinning through HQ.
- Operational visibility. Teams can see per-site link health rather than waiting for users to complain.
What SD-WAN does not magically fix
SD-WAN cannot create bandwidth that is not there. It cannot make two circuits diverse if both enter the same building duct or ride the same carrier backbone. It cannot guarantee internet performance beyond the provider networks unless you use a managed middle-mile or private backbone.
The most common disappointment is buying SD-WAN as a box replacement instead of a WAN redesign. The link plan, branch firewalling, cloud security model, DNS, identity, logging and support model all need to be designed together.
SD-WAN and SASE
Many new deployments pair SD-WAN with SASE or SSE: secure web gateway, CASB, zero-trust network access, cloud firewalling and data-loss prevention. The goal is simple: if users and applications are no longer sitting behind one HQ firewall, security controls must follow the traffic.
For regulated sectors, be precise about log retention, data inspection locations, traffic breakout countries, tenant separation and incident response. A SASE diagram that looks clean in a slide can become messy when traffic from Singapore users is inspected in another jurisdiction.
Buyer checklist
Sources and further reading
- Mplify / MEF 70.1 SD-WAN Service Attributes and Service Framework
- Mplify SD-WAN service standards overview
- TechDirectory: LAN vs WAN basics