Course contents

Unit 7: Cloud and hybrid WANLesson 7.1 (1 of 4 in this unit)14 of 25 in the Advanced Cisco SD-WAN course

Cloud OnRamp overview

The Cloud OnRamp family (SaaS, IaaS, multicloud and colocation), the problem each one solves, and how they differ from a plain tunnel to the cloud.

Advanced · 11 min read

You'll learn to tell which Cloud OnRamp feature fits a given cloud problem, list what the automation needs before it can work, and decide when a hand-built tunnel is the simpler choice.

Technical definition

Cloud OnRamp is the name Cisco gives to a group of Catalyst SD-WAN features that connect branches and data centres to cloud services. Some measure how well a cloud application is reached. Others build routers and connections inside a public-cloud account. SD-WAN Manager (vManage) drives them and shows their state.

Two different problems with the same name

A branch user complains that a Microsoft 365 or Webex session is slow. A cloud team asks for twenty virtual networks in AWS to be reachable from every site. Both are "cloud connectivity", but they are not the same job. The first is about choosing the best path to an application that already exists. The second is about building networks and routers in someone else's account and joining them to the fabric. Cloud OnRamp covers both, which is why one name can mislead.

Two problems that share the name Cloud OnRamp
Two problems that share the name Cloud OnRampCloud OnRamp for SaaS solves the problem of reaching a SaaS application well: the edge measures the available paths, for example direct internet or through a hub, and sends the application the best one. Cloud OnRamp for IaaS solves the problem of connecting your own cloud networks: the Manager builds cloud routers in the cloud account so that the fabric reaches your cloud networks.SD-WAN fabricBR-01, BR-02, HUB-01Cloud OnRamp for SaaSMeasure the paths,pick the best oneper applicationCloud OnRamp for IaaSBuild cloud routersin your cloud account,map networks to VPNsSaaS applicationYour cloud networks

On small screens, swipe sideways or focus the diagram and use the arrow keys.

Choose a feature from the question you are asking: how do users reach an application, or how does the fabric reach my cloud network.

The family at a glance

The family at a glance
The family at a glanceFeature; Problem it solves; What it changes. Cloud OnRamp for SaaS: Which exit gives users the best experience for a SaaS application Chooses a path per application between available exits. Builds nothing in the cloud Cloud OnRamp for IaaS: Reaching workloads in public-cloud networks (VPCs on AWS, VNets on Azure) as part of the fabric Deploys cloud routers through the provider's APIs and maps cloud networks to SD-WAN VPNs Multicloud and interconnect workflows: Connecting to several providers with one intent-based workflow, optionally through an interconnect provider Builds cloud gateways and connections. Newer than IaaS, so check what your release offers Cloud OnRamp for colocation: Hosting SD-WAN and security services in a colocation facility close to users and clouds Brings up a stack of devices in a colocation site. Keep expectations high level hereFeatureProblem it solvesWhat it changesCloud OnRamp for SaaSWhich exit gives users the bestexperience for a SaaS applicationChooses a path per applicationbetween available exits. Buildsnothing in the cloudCloud OnRamp for IaaSReaching workloads in public-cloudnetworks (VPCs on AWS, VNets onAzure) as part of the fabricDeploys cloud routers through theprovider's APIs and maps cloudnetworks to SD-WAN VPNsMulticloud andinterconnect workflowsConnecting to several providers withone intent-based workflow, optionallythrough an interconnect providerBuilds cloud gateways andconnections. Newer than IaaS, socheck what your release offersCloud OnRamp forcolocationHosting SD-WAN and security servicesin a colocation facility close tousers and cloudsBrings up a stack of devices in acolocation site. Keep expectationshigh level here

On small screens, swipe sideways or focus the diagram and use the arrow keys.

Read each row across: the left box names the item, the others describe it.

Names and menus have changed between releases, and some older workflows have been replaced by newer ones. Open your Manager and look at which Cloud OnRamp entries it shows before you plan around a feature from this table.

How this differs from a tunnel you build yourself

A hand-built connection to a cloud has five jobs: create the cloud network, create a gateway or router in it, configure the tunnel on both ends, set routes on both sides, and keep it all consistent when things change. You can do every one of these yourself, and for one small network that is often the right call. Cloud OnRamp takes over the repeated parts.

  1. You give Manager a cloud account connection and describe the intent: which cloud networks, which SD-WAN VPNs, which regions.
  2. Manager calls the provider's APIs and creates the networking resources and the cloud routers.
  3. The cloud routers join the fabric like any other WAN Edge and form tunnels and OMP sessions.
  4. Manager maps cloud networks to VPNs, so routes flow in both directions.
  5. Manager keeps reporting the state of what it built, and you change the intent rather than the individual pieces.

The trade is control for speed. A manual design lets you choose every detail. The automation gives a tested pattern, but only the pattern its workflow supports.

What the automation needs before it starts

What the automation needs before it starts
What the automation needs before it startsNeed; Why. Manager can reach the provider's APIs: All cloud changes are API calls from Manager. An on-premises Manager behind a strict firewall may need an explicit rule or proxy path A cloud account with enough permissions: The workflow creates networks, routes, gateways and instances. A read-only account will fail partway Image subscription and licensing for the cloud router: Cloud routers are virtual WAN Edges that come from the provider's marketplace. The image must be available to your account, and the SD-WAN licence must cover it Quota for instances and addresses: Cloud accounts have service limits. A new account may have low defaults A naming and addressing plan: Overlapping prefixes between cloud networks and sites are a common reason for a failed or confusing result A change-control agreement: Someone owns the cloud account and has to accept that Manager will change itNeedWhyManager can reach theprovider's APIsAll cloud changes are API calls from Manager. An on-premises Managerbehind a strict firewall may need an explicit rule or proxy pathA cloud account with enoughpermissionsThe workflow creates networks, routes, gateways and instances. A read-onlyaccount will fail partwayImage subscription andlicensing for the cloudrouterCloud routers are virtual WAN Edges that come from the provider'smarketplace. The image must be available to your account, and the SD-WANlicence must cover itQuota for instances andaddressesCloud accounts have service limits. A new account may have low defaultsA naming and addressingplanOverlapping prefixes between cloud networks and sites are a common reasonfor a failed or confusing resultA change-control agreementSomeone owns the cloud account and has to accept that Manager will changeit

On small screens, swipe sideways or focus the diagram and use the arrow keys.

Each item on the left, with what it means on the right.

When a manual tunnel is the better choice

  • One small cloud network. A single IPsec tunnel to a provider VPN service, with a static route or BGP, is quick and cheap. A pair of cloud routers can cost more than the workload justifies.
  • Strict change control on the cloud account. If the cloud team does not allow another system to create resources, the automation cannot work. A reviewed, hand-written design may be the only allowed route.
  • A pattern the workflow does not support. Unusual segmentation, a required third-party firewall in the path, or an existing transit design may not fit the workflow.
  • No need for SD-WAN features in the cloud. If the workload only needs a private path and not application-aware routing or fabric policy, a plain provider VPN is enough.

In practice, the choice is rarely permanent. Many sites start with one manual tunnel and move to the automated workflow when the number of cloud networks grows.

Choosing a feature from the question

The question isStart with
"Users reach this SaaS application over a poor path"Cloud OnRamp for SaaS. See the SaaS lesson
"Many VPCs or VNets must be reachable from the fabric"Cloud OnRamp for IaaS or the multicloud workflow. See the IaaS lesson
"The workloads are in AWS and a connection design is needed"The AWS design lesson
"Two or three clouds, plus a private interconnect"The multicloud workflow, if your release offers it. Check current documentation
"One cloud network, one site"A manual IPsec tunnel, and reconsider later
"Measure tunnels between SD-WAN sites"Not Cloud OnRamp. This is application-aware routing
Why does the automation report state, and why does that matter?

Cloud resources can change outside Manager: someone edits a route table in the cloud console, or an instance is stopped to save cost. If the only record of the design is in the cloud account, nobody sees the drift until traffic fails. Manager showing the state of what it built gives a second view to compare with. It does not stop the drift, so agree who is allowed to change the cloud resources directly.

Where Cloud OnRamp projects stall

  • The cloud account is created by another team and the permissions are asked for only after the workflow fails.
  • The marketplace image is not subscribed in the account or region, so the router cannot launch.
  • Cloud network ranges overlap with branch or data-centre ranges, such as 10.10.0.0/16 used in both places.
  • Nobody costed the cloud routers and data transfer, and the bill is the first surprise.
  • The feature chosen belongs to an older workflow that the Manager release no longer offers.

Test yourself on choosing a Cloud OnRamp feature

Predict · scenario 1

Branch users report that a SaaS application is slow through the local internet circuit, while a hub with internet access seems faster. Which feature compares the exits for that application?

Predict · scenario 2

A Cloud OnRamp for IaaS workflow fails while creating the cloud routers, with an error about the image. What is the most likely area to check first?

Predict · scenario 3

A team has one VPC with a single application and one data centre. They ask whether they need the full IaaS automation. What is the most sensible answer?

Predict · scenario 4

The cloud security team says no external system may create or change resources in their accounts. What does that do to the plan?

FAQ

Is Cloud OnRamp one product?
No. It is a family of features with a shared name and a shared place to manage them, SD-WAN Manager. The SaaS feature measures application quality. The IaaS feature builds routers in a cloud account. Newer multicloud workflows cover several providers. Each has its own prerequisites, and which ones you see depends on your release.
Can I connect a branch to the cloud without Cloud OnRamp?
Yes. You can build an IPsec tunnel from a WAN Edge (cEdge/vEdge) to a cloud provider's VPN service, or deploy a virtual router yourself and join it to the fabric. Cloud OnRamp automates that work. It does not make it possible for the first time.
Does Cloud OnRamp need the cloud provider's credentials?
The IaaS and multicloud workflows do, because Manager calls the provider's APIs to create and change resources. The SaaS feature does not create anything in a cloud account, because it only measures paths. Treat the credentials like any other privileged account and give them the least access that works.