Cisco Catalyst SD-WAN Deep Dive Part 6: Cloud OnRamp for SaaS and IaaS

Parts 1–5 covered the fabric as it exists on customer premises. This post follows it into the two places it most often needs to go next: SaaS applications it doesn’t control, and IaaS workloads in a hyperscaler the customer does control but doesn’t physically own.

Cloud OnRamp for SaaS: measure first, route second

Part 5’s DIA discussion treated “break out locally” as a single decision per segment — Internet-bound traffic either backhauls to a hub or it doesn’t. Cloud OnRamp for SaaS makes that decision per-application instead, and continuously, rather than as a one-time design choice.

The mechanism: vManage maintains a catalog of well-known SaaS applications (Microsoft 365, Salesforce, Webex, and so on), and WAN Edges at each site continuously probe path quality toward each enabled app’s endpoints over every available local transport — direct, over DIA, where a transport is available for it; via a cloud-hosted measurement path for sites without a usable local breakout. The result is a constantly-updated scorecard: for this branch, over this transport, how does this specific SaaS app actually perform right now. vManage then steers each app’s traffic over whichever local transport scores best for that app specifically — which means two SaaS applications at the same branch can legitimately exit over two different circuits simultaneously, because Office 365 measured better over biz-internet today while a different SaaS app happened to measure better over the secondary Internet circuit or even MPLS.

This is the same underlying idea as app-route policy from Part 4 — continuous measurement feeding a per-flow path decision — applied one layer up the stack, to known SaaS destinations specifically rather than generic application traffic matched by DSCP or ACL. Where app-route policy answers “which TLOC pair is healthy enough for this traffic class,” Cloud OnRamp for SaaS answers “which local egress is fastest for this specific SaaS app, right now” — a narrower, app-aware version of the same measure-then-steer philosophy.

Cloud OnRamp for IaaS: the cloud VPC becomes just another site

Where SaaS OnRamp is about reaching applications you don’t host, Cloud OnRamp for IaaS is about extending the fabric itself into infrastructure you do — an AWS VPC, an Azure VNet — so that cloud-resident workloads participate in the overlay exactly like a branch does. vManage automates standing up cloud-resident WAN Edge instances inside a hub VPC/VNet, wires the underlying cloud-native networking (VPC peering or Transit Gateway attachment in AWS, the Azure-native equivalent for VNet hub connectivity) behind the scenes, and the result is a cloud router that’s a full OMP participant — it gets a system-IP, advertises OMP routes for whatever cloud-side prefixes it’s responsible for, and branches reach cloud workloads through the exact same TLOC-and-policy machinery covered in Parts 2–4. There’s no separate “cloud connectivity” technology layered on top; the cloud VPC is architecturally just another site, automated into existence rather than racked.

The direct Fortinet comparison

This site already covered the equivalent problem from Fortinet’s side in the two-part Cloud On-Ramp series — Part 1 on AWS Transit Gateway, Part 2 on Azure Virtual WAN and dual-cloud resilience. The goal is identical across both vendors — don’t make engineers hand-build cloud connectivity as a bespoke project, extend the existing SD-WAN fabric into the hyperscaler instead — and the shape even rhymes: both put a vendor-controlled virtual appliance in a hub VPC/VNet and lean on the cloud provider’s own transit construct (Transit Gateway, Virtual WAN) for the underlying cloud-native plumbing. The difference is in what glues the on-prem and cloud sides together once that plumbing exists: Fortinet’s cloud-resident FortiGate-VMs join the fabric over BGP and ADVPN, the same mechanisms used everywhere else in that architecture; Cisco’s cloud router joins as an OMP participant, the same mechanism used everywhere else in this architecture. Neither vendor invented a new cloud-specific protocol — they each extended the protocol they already had.

Next

Part 7 stays close to this cloud/Internet-facing edge and covers security there directly: SIG (Secure Internet Gateway) integration, Secure Firewall and UTD running on cEdge itself, and how DIA traffic that’s no longer backhauled through a hub for inspection (Part 5) gets its security coverage some other way.