Juniper Session Smart SD-WAN Deep Dive Part 6: Cloud Onramp and Multicloud
Part 5 covered the security model. This post covers what happens when the WAN needs to reach a resource that doesn’t live in a branch or a data centre at all — public cloud — and how Session Smart Routing’s architecture shapes that answer differently from the tunnel-based cloud onramp patterns the Cloud On-Ramp series on this site already covered for Fortinet.
The same primitive, extended into cloud
Session Smart Routers are available as virtual instances deployable directly into AWS and Azure, running the same SVR data plane and the same tenant/service policy model as a physical SSR at a branch or hub. That continuity is the headline architectural point: a cloud region running a virtual SSR isn’t a special case requiring different policy language or a separate management construct — from the Conductor or Mist control plane’s point of view, it’s simply another site, classified against the same tenants and services already governing branch-to-branch and branch-to-DC traffic.
This mirrors a pattern this site has already covered from the tunnel-based side: the Fortinet Cloud On-Ramp series treated AWS Transit Gateway and Azure Virtual WAN as extensions of an existing SD-WAN fabric rather than bespoke cloud-networking projects. Session Smart Routing reaches the same conceptual destination — cloud as just another site in the fabric — but arrives there without needing a tunnel-terminating gateway construct at all, because the SVR data plane itself is what’s running in the cloud, not a tunnel endpoint feeding a separate cloud-native routing service.
What this removes from the design
The specific complexity a tunnel-based cloud onramp design has to solve — which this site’s Cloud On-Ramp series spent two full posts on for Fortinet — is largely about the handoff between the SD-WAN overlay’s tunnel termination and the cloud provider’s own native routing constructs: Transit Gateway route tables on the AWS side, Virtual WAN hub route propagation on the Azure side, and the BGP or static routing needed to make traffic actually flow correctly between the two routing domains. A virtual SSR running natively in the cloud doesn’t need that handoff in the same way, because there’s no tunnel boundary between “the SD-WAN fabric” and “the cloud network” for a routing domain to change across — the SSR is simply present inside the cloud VPC/VNet, participating in the same session-and-tenant model as everywhere else in the fabric.
That doesn’t eliminate cloud-networking design work entirely — a virtual SSR still needs to be placed correctly within the cloud provider’s own VPC/VNet topology, sized appropriately for the traffic it’s expected to carry, and made highly available the way any critical piece of cloud infrastructure needs to be. What it removes is the specific category of tunnel-handoff complexity that’s distinctive to bridging a tunnel-based overlay into a cloud provider’s native routing fabric.
Multicloud and the tenant/service model’s natural fit
An organization running workloads across both AWS and Azure — the dual-cloud resilience pattern Part 2 of the Fortinet Cloud On-Ramp series walked through in detail — gets a specific benefit from SVR’s tenant/service abstraction here: a service definition describing “reach this application” doesn’t need to encode which cloud, or which specific tunnel, that application currently lives behind. If a workload migrates from AWS to Azure, or runs active-active across both, the service definition’s job is still just “here’s how to reach this, and here’s the SLA that applies” — the underlying path is something the routing engine resolves dynamically rather than something baked into a static tunnel topology an administrator has to manually redesign around a cloud migration.
Where this leaves the comparison
The pattern holds across every post in this series so far: SVR’s session-and-tenant model removes a specific category of operational complexity that tunnel-based architectures carry by construction, in exchange for asking operators to think in tenant/service terms rather than the tunnel/gateway/route-table language most cloud-networking documentation — including AWS’s and Azure’s own — is written in. For an organization already comfortable with SVR’s model from the branch and DC side of the fabric, extending it into cloud is a natural continuation rather than a new discipline to learn. For an organization whose cloud networking team is fluent in Transit Gateway and Virtual WAN specifically, there’s a genuine learning curve in adopting SVR’s abstraction even where the underlying goal — cloud as just another well-connected site — is identical.
The next post in this series is the practical one: a playbook for actually cutting an MPLS-based WAN over to Session Smart Routing, mirroring the cutover playbooks this site has already published for Cisco/Viptela and Palo Alto/Prisma.