Cisco SD-WAN Cloud OnRamp: Connecting Branches to Cloud

Cisco SD-WAN Cloud OnRamp is the set of features in Cisco Catalyst SD-WAN that extends your WAN into public clouds and SaaS applications, and automates the work of doing so. Cisco describes it as automating cloud connectivity, applying consistent policy and security across on-premises and cloud locations, and using application-performance insights to improve user experience. The name covers several distinct capabilities, and the older Cloud OnRamp for IaaS workflow is being replaced by Cloud OnRamp for Multicloud. This article explains what each option does, how the IaaS model works under the hood, and what to settle before you deploy.

Re-solution

Connect Branches to Cloud Securely

Re-solution provides Cisco network and security solutions to help organisations plan connectivity across branches and cloud environments.

Explore Cisco solutions

TL;DR

Cloud OnRamp is a family of capabilities: Multicloud (and the older IaaS workflow) for cloud workloads, SaaS for application path selection, and middle-mile options for provider backbones.
For IaaS, SD-WAN Manager takes your cloud credentials, discovers networks, builds redundant virtual routers and transit infrastructure, and maps host networks into the SD-WAN fabric.
From vManage release 20.9.1, Cisco recommends Cloud OnRamp for Multicloud, and the IaaS workflow will be phased out in a future release.
Policy, security and segmentation can be managed from one SD-WAN Manager interface across branch and cloud.
Decide on cloud platform, redundancy, routing and security policy before you build, not after.

What Cloud OnRamp does
The Cloud OnRamp options compared
How Cloud OnRamp for IaaS works
Moving from IaaS to Multicloud
How Cloud OnRamp for SaaS chooses a path
Security and policy across branch and cloud
Planning a Cloud OnRamp deployment
Our perspective
Getting help with Cloud OnRamp
FAQ
Sources

What Cloud OnRamp does

A traditional WAN sends branch traffic to a data centre, and from there to the cloud. That adds latency and a lot of hairpinning. Once applications and workloads live in public clouds, branches need direct, secure and predictable paths to them.

Cloud OnRamp handles that in a few ways. According to Cisco’s Cloud OnRamp overview, its core functions are:

automating cloud-agnostic connectivity;
applying unified policy across the major clouds;
consolidating networking and security functions;
providing a consistent operating interface;
using application-performance insights to improve user experience.

The design rationale is operational simplification. Each cloud provider has its own networking model, with its own constructs and terminology. Cisco’s Cloud OnRamp at-a-glance document positions a single SD-WAN Manager workflow as the way to normalise those models, so your team does not have to learn and configure each provider independently while common policy and security stay in place.

Cisco also presents Catalyst SD-WAN on its UK solutions page as combining branch and cloud security, application performance and Cloud OnRamp access, which is a useful reminder that Cloud OnRamp is part of the SD-WAN platform rather than a separate product.

The Cloud OnRamp options compared

Searches for “Cloud OnRamp” often mix up different capabilities. The table separates them by the problem each one solves.

Option	What it connects	What it does
Cloud OnRamp for Multicloud	Sites and workloads to AWS, Microsoft Azure and Google Cloud	Automates extending the enterprise WAN into the clouds, supporting site-to-cloud, intra-cloud and inter-cloud deployments with consistent policy
Cloud OnRamp for IaaS	The SD-WAN overlay to workloads in public-cloud VPCs or VNets	Earlier workflow: discovers cloud networks, deploys virtual SD-WAN routers and transit infrastructure, and maps host networks
Cloud OnRamp for SaaS	Users to SaaS applications	Probes available paths, measures latency and loss, and selects the best path for application traffic
Middle-mile and interconnect options	Sites and clouds over provider private backbones	Provides on-demand connectivity through interconnect and cloud backbone services

The Multicloud, SaaS and middle-mile descriptions come from Cisco’s Cloud OnRamp at-a-glance. The same document says the middle-mile and cloud-interconnect options automate site-to-site, site-to-cloud and cloud-to-cloud connectivity through colocation and interconnect providers and through native cloud backbones such as AWS Cloud WAN, Azure Virtual WAN and Google Network Connectivity Center.

In practice, most organisations use more than one. A school trust may use SaaS path selection for its learning platforms and cloud email while keeping a handful of workloads in a single public cloud. A manufacturer with ERP in one cloud and analytics in another has a Multicloud use case.

How Cloud OnRamp for IaaS works

Even though the IaaS workflow is being superseded, it explains the model that the Multicloud workflow builds on, and many estates still run it. Cisco’s IaaS white paper describes the sequence.

Discovery and automation

Automation is the heart of the feature. You provide cloud credentials, and Cisco Catalyst SD-WAN Manager discovers the host VPCs (AWS) or VNets (Azure) in your accounts, creates virtual routers and manages the connectivity. That removes the manual work of building tunnels and route tables one network at a time.

Transit infrastructure and redundancy

The virtual SD-WAN routers sit in a transit VPC or transit VNet and act as the cloud-side edge of your overlay. For resilience, Cisco’s configuration guide describes deploying one to four pairs of virtual routers in transit VPCs or VNets, so the path to the public cloud survives a single failure. In AWS, the routers of a redundant pair are placed in different availability zones to improve availability.

For AWS specifically, the white paper explains that SD-WAN Manager can deploy an AWS Transit Gateway and two SD-WAN virtual routers in a transit VPC. In Cisco’s example the routers connect to the Transit Gateway using IPsec or, alternatively, GRE, and host VPCs attach to that gateway. The current configuration guide also notes that AWS autoscale supports one to four pairs of SD-WAN cloud devices associated with a transit VPC.

Mapping, IPsec, BGP and OMP

Mapping is the step that connects a host network to the transit network. For Azure, the same guide explains that mapping automatically establishes IPsec tunnels between transit and host VNets, with BGP exchanging routes. The IPsec tunnels use IKEv2, and the BGP routes are redistributed automatically into OMP, the Overlay Management Protocol used by the SD-WAN overlay. An earlier version of the guide summarises the purpose of BGP simply: it lets the transit network direct traffic to the right host network.

For your network team, the consequence is that cloud networks appear in the overlay as reachable prefixes, without hand-built routing per VPC. Your addressing plan still matters, though: overlapping CIDR ranges between sites and cloud networks cause problems that no automation fixes.

Moving from IaaS to Multicloud

If you are planning a new deployment, this is the point to note. Cisco’s configuration guidance says that beginning with vManage release 20.9.1, Cloud OnRamp for Multicloud is recommended for setting up cloud infrastructure, and Cloud OnRamp for IaaS will be phased out in a future release.

The practical implications:

New builds should start with Multicloud. Building on a workflow with a stated retirement path creates a migration project later.
Existing IaaS deployments keep working today, but you should record which VPCs and VNets are mapped, which router pairs serve them, and which policies depend on them. That inventory is the first task of any migration.
Brownfield estates, where cloud networks already exist and carry production traffic, need the most care. Bringing existing networks under SD-WAN control should be piloted on a low-risk workload first, with a rollback route agreed in advance.
Software versions matter. Check the release on your SD-WAN Manager and edge devices against Cisco’s documented requirements for the workflow you choose.

Multicloud also changes the scope. Rather than only extending to workloads in a transit VPC or VNet, it supports site-to-cloud, intra-cloud and inter-cloud designs across AWS, Azure and Google Cloud, with the same policy model applied to each.

How Cloud OnRamp for SaaS chooses a path

Cloud OnRamp for SaaS solves a different problem. There is no workload of yours in the cloud to connect to. Instead, users reach an application you do not host, and the quality of that experience depends on the path.

According to Cisco’s SaaS FAQ, the feature continuously probes permissible paths to SaaS applications, measures latency and loss to calculate application-quality metrics, and dynamically selects the best path for application traffic. The FAQ states support for more than 1,400 business applications, plus custom or standard NBAR applications.

The measurements that drive this are the same ones that decide whether real-time traffic is usable. If you run voice or video, it is worth understanding how latency, jitter and loss translate into what users hear, and VoIP audio quality metrics are a good place to see how those figures are read in practice. Path selection in SaaS mode applies the same logic to your business applications: the path with the better quality score wins, and the decision is re-evaluated continuously.

Two design points follow. First, SaaS path selection needs more than one viable exit, such as a direct internet path at the branch and a path via a regional hub, otherwise there is nothing to choose between. Second, your resilience design should say what happens when all measured paths degrade together. Our guide to SD-WAN failover design covers that in detail.

Security and policy across branch and cloud

One of the strongest arguments for Cloud OnRamp is consistency. Using the single SD-WAN Manager interface, you can apply the same Catalyst SD-WAN policies, security and segmentation to on-premises and public cloud environments, as described in the IaaS white paper. Cisco’s stated aim is a unified security architecture, where enforcement does not depend on where the user or workload sits.

To make that real, think through these points:

Segmentation. Decide which segments (guest, corporate, operational technology, building systems) are allowed to reach which cloud networks, and write that down before mapping anything.
Cloud-delivered security. Where branches break out to the internet directly, you need DNS-layer and web security at that exit. See how we approach cloud security consolidation with Cisco Umbrella.
Control of the fabric itself. The overlay is now a high-value target. Our SD-WAN security checklist sets out controls aligned with NCSC and ENISA guidance.
Identity and access. Cloud reachability should not mean flat access. Combine segmentation with network access control, as covered in our Network Access Controller guide.

Planning a Cloud OnRamp deployment

A sensible sequence for a UK organisation with several sites:

Define the traffic. List the cloud workloads and SaaS applications each site depends on, and rank them by business impact. A warehouse management system matters more than a staff portal.
Choose the cloud model. Single cloud, multicloud, or a mix of cloud and SaaS. This decides whether you need Multicloud, SaaS or interconnect options.
Audit the starting point. Check addressing, existing tunnels, firewall rules, software versions and licensing. A network audit before design usually saves more time than it costs.
Design redundancy. Decide how many router pairs, which availability zones or regions, and how branches fail over. The SD-WAN design guide walks through the main decisions before rollout.
Pilot. Choose one cloud network and a small set of sites, with measurable success criteria. Our SD-WAN migration plan sets out pilot criteria for UK organisations.
Operate. Monitoring, change control and software upgrades continue long after go-live. This is where many internal teams are stretched.

The sector shapes the priorities. Education networks need strong segmentation between students, staff and building systems. Manufacturing and logistics sites depend on uptime for operational systems. Hospitality groups run many small, similar sites that suit templates. Shared workspaces and housing providers need to onboard and separate tenants quickly.

Our perspective

We have worked with Cisco infrastructure for more than 35 years, and the pattern we see is consistent: cloud connectivity projects rarely fail on the technology. They fail on scoping. The automation in Cloud OnRamp is genuinely useful, but it automates whatever design you give it, including a poor addressing plan or an undefined policy model.

Three views follow from that.

First, start new work on Cloud OnRamp for Multicloud, and treat any existing IaaS workflow as something to inventory and migrate on your own timetable rather than under pressure.

Second, do not buy the feature before you have decided your segmentation policy. Cloud reachability is easy to create and hard to retract once applications depend on it.

Third, plan who runs it. Many organisations we speak to have a small network team covering many sites. A managed service or Network as a Service model can keep the SD-WAN, wireless and security layers monitored and consistent without adding headcount, while the organisation retains control of policy.

— Jacob

Getting help with Cloud OnRamp

Re-Solution is a Cisco partner that designs, audits and runs multi-site networks for education, manufacturing, logistics, hospitality, shared workspaces and property developers. If you are weighing Cloud OnRamp for a new build or a move away from the IaaS workflow, we can start with a network audit to establish what you have, then support design and rollout through our professional services. For day-to-day operation, see our managed services and Network as a Service options, or contact us to discuss your sites.

FAQ

Is Cloud OnRamp for IaaS the same as Cloud OnRamp for Multicloud?

No. They are separate workflows in SD-WAN Manager with a common purpose. Cisco recommends Multicloud from vManage release 20.9.1 and says the IaaS workflow will be phased out in a future release, so new deployments should start with Multicloud.

Which clouds does Cloud OnRamp support?

Cloud OnRamp for Multicloud automates extending the enterprise WAN into AWS, Microsoft Azure and Google Cloud. It supports site-to-cloud, intra-cloud and inter-cloud deployments with consistent policy for cloud workloads.

Do I need Cloud OnRamp for SaaS if I already have Cloud OnRamp for Multicloud?

They address different traffic. Multicloud connects your own workloads in public clouds, while SaaS measures paths to applications you consume and steers traffic over the best one. Many organisations with both kinds of traffic use the two together.

How does Cloud OnRamp keep cloud connectivity resilient?

In the IaaS model, Cisco describes one to four pairs of virtual SD-WAN routers in transit VPCs or VNets, with AWS router pairs placed in different availability zones. Tunnels use IPsec, and BGP exchanges routes so traffic reaches the right host network. You still need to design branch-side failover separately.

Can a managed provider run Cloud OnRamp for us?

Yes. Design, monitoring, change control and upgrades can all be handled under a managed services contract, with your team keeping ownership of policy. The scope should be written down clearly, including who approves changes to cloud mappings.

Cisco SD-WAN Cloud OnRamp: Connecting Branches to Cloud

TL;DR

Table of Contents

What Cloud OnRamp does

The Cloud OnRamp options compared