Cloud-Delivered SD-WAN: Service Models and Architecture Trade-offs
Understand what cloud-delivered SD-WAN changes, how its control and edge functions may be placed, and what to assess for path performance, resilience, security, and operations.
By Mark Poulton
Cloud-Delivered SD-WAN: Service Models and Architecture Trade-offs
Cloud-delivered SD-WAN places some management or network functions in provider or public-cloud infrastructure, but it does not necessarily remove equipment or software at each site. The important architectural questions are which functions are hosted, where user traffic actually flows, what happens when a control or data path is unavailable, and who operates each component.
“Cloud-native” is often used loosely in product descriptions. For an SD-WAN evaluation, ask for the service's actual control-plane, data-plane, edge, and security placement. A cloud-hosted management portal and a branch edge that forwards traffic locally are different from a service that sends selected traffic through a cloud gateway. Neither is inherently right for every network.
What does cloud-delivered SD-WAN mean?
SD-WAN separates centrally managed traffic policy from the links that carry traffic. Cloud delivery changes where some control, orchestration, gateway, or security functions run. The branch still needs a way to connect its local networks to the overlay, which may be a physical appliance, software edge, or function provided by another platform.
The SD-WAN architecture article describes the general components. For this service-model decision, distinguish at least three placements:
| Function or placement | What to establish |
|---|---|
| Cloud-hosted management and control | How policy is authored and distributed, what remains available during a management outage, and how configuration changes are audited. |
| Site edge with cloud management | What hardware or software remains at the site, how it forwards traffic, and what local functions continue if the provider is unreachable. |
| Cloud or provider-hosted forwarding and security functions | Which traffic is sent through the gateway, where the gateway is located, how paths are selected, and what latency, capacity, inspection, and availability commitments apply. |
These functions can be combined differently across products. The service description and tested traffic paths matter more than the marketing label.
What trade-offs should an organisation assess?
Traffic path and application experience
Trace the path for representative applications from user or branch to destination, including security inspection and return traffic. A cloud gateway can provide a useful point for policy or inspection, but it can also add a network hop. Measure the application path and test locations that are geographically or operationally different. Do not infer performance from the gateway's region name alone.
Resilience and dependency
Identify dependencies on provider reachability, management services, cloud gateways, DNS, identity, and local edge availability. Ask which existing policies continue during a control-plane interruption and what happens if a data-plane gateway is unavailable. Test failover and recovery against documented requirements rather than relying on a product diagram.
Security and data handling
Map where traffic is encrypted, inspected, logged, and stored. Confirm which party manages each control and how events reach the organisation's monitoring and response processes. Cloud delivery does not by itself establish a security outcome. The SD-WAN security article explains the control and responsibility questions in more detail.
Operations and service boundaries
Clarify which team owns policy, site connectivity, edge updates, incident triage, and provider escalation. A hosted service may shift some operational work, but it does not eliminate the customer's need to define outcomes, approve changes, understand dependencies, and investigate business impact.
Portability and exit
Document configuration export, policy portability, data access, termination assistance, and what must be replaced if the service changes. Also identify which local or cloud functions remain usable during migration. This is part of architecture and lifecycle planning, not just procurement detail.
How should service models be compared?
Use the same set of sites, applications, traffic paths, security requirements, and support expectations for each candidate. For each one, record function placement, expected dependencies, failure behaviour, operating owner, and evidence required for acceptance. Then validate the design through a representative pilot. The SD-WAN design guide covers topology and requirements; SD-WAN deployment: risks, sequencing, and mitigation provides rollout and validation guidance.
Cloud-delivered SD-WAN may suit an organisation that wants provider-hosted management or gateways and has verified that the traffic path, resilience, and operating model fit. A locally managed or appliance-centric design may fit better where local forwarding, specific control, or existing operational arrangements matter more. A hybrid service model is also possible. The decision should follow measured requirements rather than a presumption that cloud delivery is always simpler or more scalable.
SASE is a related but broader service model that combines networking and security capabilities. It should not be used as a synonym for cloud-hosted SD-WAN; What is SASE? explains that distinction in depth.
Conclusion
Cloud-delivered SD-WAN is best understood by tracing where control, forwarding, edge, and security functions run. Compare real traffic paths, failure modes, security boundaries, operating responsibilities, and exit options. Once those are clear, the delivery model can be assessed on its merits without relying on an ambiguous “cloud-native” label.