Skip to content
Log in Sign up My account

5.5 and 5.6 Cloud Connectivity and Service Models

Blueprint 5.5: Cloud connectivity options (direct connect, cloud on-ramp, MPLS direct connect, WAN integration)

Pick a connectivity option for a given workload, performance target, security need and cost, and explain its failure behaviour.

Blueprint 5.6: Cloud service models (SaaS, PaaS, IaaS) in private, public and hybrid deployments

Match a requirement to a service model and a deployment model, and state what the enterprise still has to design and operate.

This is a design topic with little protocol detail. The mechanics of the pieces you connect are in other pages: Catalyst SD-WAN for OMP and the overlay, and GRE and IPsec for the tunnel building blocks.

Service models (5.6)

The three service models differ in how much the provider runs for you. The more the provider manages, the less control and customisation you have.

Layer On premises IaaS PaaS SaaS
Application You You You Provider
Data You You You You (the tenant's data and access)
Runtime and middleware You You Provider Provider
Operating system You You Provider Provider
Virtualisation, servers, storage You Provider Provider Provider
Network (physical) You Provider Provider Provider
Model You get Examples (categories) Network design implication
IaaS Virtual machines, networks, storage. You manage OS and up Compute instances, virtual networks You design virtual networking, routing, firewalling and connectivity. Biggest design surface
PaaS A managed runtime or database. You deploy code or data Managed databases, app platforms, functions Connectivity is to service endpoints, often via private endpoints or public addresses. Less network control
SaaS A finished application Collaboration suites, CRM, video conferencing You control only user access paths. Performance depends on how users reach the provider

Responsibility reminder

In every model the customer still owns its data, its identities and its access policy. The shared responsibility model moves infrastructure duties to the provider as you go from IaaS to SaaS, but it never moves them all.

Deployment models

Model Definition Design drivers Trade-off
Private Cloud infrastructure for one organisation, on premises or hosted Data residency, regulation, predictable performance You carry the capital cost and the operations
Public Shared provider infrastructure, multi-tenant Elasticity, speed, pay-per-use Less control, egress costs, shared responsibility
Hybrid Private and public joined by connectivity and common management Burst capacity, gradual migration, keep sensitive data local The connection and consistent policy become the hard part
Multicloud More than one public provider (often with a private estate) Avoid lock-in, best-of-breed services, regional presence More skills, inconsistent tooling, more connectivity

Hybrid is a deployment choice, and IaaS is a service choice. They are independent. You can run IaaS in a hybrid design, or consume SaaS from a public cloud while hosting a private one.

Connectivity options (5.5)

graph TB
  subgraph E ["Enterprise"]
    BR["Branch"]
    DC["Data centre"]
  end
  BR -->|"1 Internet / SD-WAN"| INT["Internet"]
  INT --> CLOUD["Cloud"]
  DC -->|"2 Private circuit<br/>(direct connect)"| CLOUD
  BR -->|"3 MPLS L3VPN<br/>(provider cloud connect)"| MPLS["Provider MPLS"]
  MPLS --> CLOUD
  BR -->|"4 SD-WAN Cloud OnRamp"| CLOUD

The four options compared

Option What it is Strengths Weaknesses Best fit
Internet VPN to the cloud IPsec tunnels from branch or DC to a cloud gateway or a virtual router in the cloud Fast to deploy, cheap, any location Variable latency and loss, internet SLA absent, encryption overhead Small sites, SaaS, non-critical workloads, backup path
Direct connect (dedicated private connection) A private circuit from the enterprise (or a provider) to the cloud provider's edge. Offered by each provider under its own name Predictable latency, higher throughput, lower egress charges in many pricing models, not on the public internet Lead time, port and circuit cost, a location constraint, redundancy is your job Data-centre-to-cloud, large data transfers, regulated workloads
MPLS direct connect The provider's MPLS L3VPN extended to the cloud provider, so cloud networks appear as another site in the VPN One WAN for all sites and cloud, provider SLA and QoS, no new routing design for branches Depends on the provider's cloud partnerships, cost, less flexible than internet Existing MPLS customers adding cloud with branch-to-cloud SLAs
Cloud on-ramp SD-WAN feature set that automates cloud access: virtual edges in cloud networks and per-application path selection to SaaS Application-aware path choice, automated provisioning, consistent policy Requires the SD-WAN fabric and a licence tier, extra cloud resources Distributed branches using SaaS and IaaS
WAN integration Treat the cloud as a site of the existing WAN overlay, using virtual routers or colocation facilities One policy and segmentation model end to end Design and cost of virtual edges and interconnect providers Enterprises standardising on SD-WAN

Cloud on-ramp in detail

Cisco SD-WAN uses the name Cloud OnRamp for several functions. Match each to the problem it solves.

Function Problem solved How
Cloud OnRamp for SaaS Users reach SaaS over the best path, not the default path Probes measure loss, latency and jitter through each exit (direct internet at the branch, or via a regional gateway) and steers each SaaS application to the best one, failing over when quality drops
Cloud OnRamp for IaaS (Multicloud) Connect the SD-WAN overlay to public cloud networks without hand-building tunnels The manager provisions virtual SD-WAN edges in cloud networks and attaches them to the cloud's transit constructs, extending the overlay and segmentation into the cloud
Cloud OnRamp for Colocation Provide a regional hub with security and WAN services close to cloud on-ramps A stack of virtual network functions in a colocation facility serves as a shared hub for branches to reach the cloud

The principle is application-aware: the overlay measures the real quality of each path and moves traffic as conditions change. See Catalyst SD-WAN for the control and data plane.

Design factors

Factor Question to ask Typical effect on the choice
Latency and jitter Does the application need predictable delay (voice, trading, database replication)? Direct connect or MPLS direct connect over internet VPN
Bandwidth and volume Large data migration or steady bulk flows? Direct connect, and check egress pricing
Resilience What survives a single failure? Two circuits at two locations, or a circuit plus an internet VPN backup
Security and compliance Must traffic avoid the public internet? Private connection; encryption on top is still often required
Time to deploy Weeks or months? Internet VPN first, private later
Branch breadth Hundreds of sites needing cloud access? SD-WAN on-ramp or MPLS direct connect, not one circuit per site
Skills and operations Who runs it? Automation from SD-WAN reduces per-site work
Cost Port fees, circuits, egress, virtual edge licences Model total cost, not circuit price alone

Common resilience patterns

graph LR
  DC["Enterprise DC"] -->|"Primary: dedicated circuit"| CL["Cloud region"]
  DC -.->|"Backup: IPsec over internet"| CL
  • Primary private, backup internet VPN. Cheap resilience. Remember that the backup has lower bandwidth and different latency. Routing preference (for example higher local preference or a shorter AS path on the private path) must keep traffic off the VPN in normal conditions.
  • Two private circuits at two locations. Protects against a facility or provider failure.
  • Two cloud regions. Protects against a regional cloud failure, at the cost of data replication and complexity.
  • Routing. Cloud providers usually use BGP over the private connection, so route filtering, prefix limits and community use apply. Apply the BGP route filtering and path preference principles from the routing domain. Make sure the enterprise does not become a transit path between two cloud networks by accident.

Redundancy is the customer's job

A single private connection to the cloud is a single point of failure even if the provider's own network is redundant. The design must supply the second path, ideally in a separate facility, and test failover.

Exam trap

Direct connect is private and predictable but not automatically encrypted. If the requirement says "data must be encrypted in transit", the design adds IPsec or MACsec on top, or uses a service that encrypts. "Private" does not mean "encrypted".

Exam trap

Cloud OnRamp is not a connection type like a circuit. It is an SD-WAN capability that sits on top of any transport (internet, MPLS, direct connect). An option that says "replace MPLS with Cloud OnRamp" mixes up a transport with a policy and automation layer.

Exam trap

Mixing up the service model and the deployment model. "Hybrid" describes where workloads run (private plus public). "IaaS" describes what the provider supplies. A scenario that says "company hosts VMs in a provider data centre and keeps a database on premises" is IaaS in a hybrid deployment.

Design exercise

Scenario. A manufacturer has 80 plants and two data centres. It is moving its ERP front end to virtual machines in a public cloud (the database stays on premises for now), adopting a SaaS collaboration suite, and wants a path for a future analytics platform that will receive tens of terabytes of plant data per month. Requirements:

  1. ERP traffic between the data centres and the cloud needs consistent latency and must survive a circuit or facility failure.
  2. Plants need good SaaS performance, and today they backhaul all internet traffic through a data centre.
  3. The WAN is MPLS today, with an SD-WAN rollout under way at the plants.
  4. Budget is limited, and the cloud migration is staged over twelve months.

Choose the service and deployment models and the connectivity.

Model answer

Models. The ERP front end on VMs is IaaS, and with the database on premises the deployment is hybrid. The collaboration suite is SaaS in the public cloud. The analytics platform will probably be PaaS, which is a later decision that does not change the connectivity choice.

Data centres to cloud. Use two direct-connect circuits, one from each data centre, landing at different cloud edge locations, with BGP routing. This gives predictable latency for ERP, survives a circuit or facility failure, and keeps the tens of terabytes of analytics traffic off the internet and off the metered path where pricing favours it. Add an encrypted overlay if compliance requires encryption in transit.

Plants to cloud and SaaS. Use Cloud OnRamp for SaaS and direct internet access at the plants that run SD-WAN. The overlay measures each SaaS path and chooses between local internet exit and a data-centre exit, which removes the backhaul penalty. Use Cloud OnRamp for IaaS (multicloud) to extend the SD-WAN overlay and segmentation into the cloud, so plants reach ERP through the overlay and policy is consistent.

Migration and cost. Start with internet VPN to the cloud and SD-WAN at the plants while the direct-connect circuits are ordered, then cut over. Keep the VPN as the backup path. Plants not yet on SD-WAN continue to use MPLS and reach the cloud via the data centres.

Rejected alternatives.

  • Internet VPN only: cheapest, but cannot give consistent ERP latency or support the large analytics transfers.
  • MPLS direct connect for every plant: gives an SLA, but the manufacturer is already moving to SD-WAN, and MPLS cloud connectivity ties the design to the provider's partnerships and costs more per plant.
  • Single direct-connect circuit: meets latency but fails requirement 1 because it is a single point of failure.
  • Keep backhauling all SaaS through the data centres: simple, but adds latency and consumes data-centre WAN and firewall capacity.

Quick check

A requirement says traffic to the cloud must never traverse the public internet and must be encrypted. Does a dedicated private connection satisfy it?

It satisfies the first part. A private connection is not encrypted by default, so the design adds IPsec or MACsec over it, or uses a feature that encrypts the link.

Which service model leaves the customer with the largest network design responsibility?

IaaS. The customer builds the virtual networks, routing, addressing and security policy. PaaS and SaaS reduce that surface.

A branch has two internet exits. Which Cloud OnRamp function chooses between them for a SaaS application?

Cloud OnRamp for SaaS. It measures loss, latency and jitter through each path and steers the application to the best one.

References

  • Cisco Catalyst SD-WAN design and Cloud OnRamp guides: search "Cloud OnRamp" and "Cisco SD-WAN Cloud OnRamp for Multicloud" on cisco.com
  • Cisco Validated Designs for SD-WAN and multicloud: search "SD-WAN Cloud OnRamp CVD" on cisco.com
  • Provider documentation for private cloud connections: search the provider's documentation for "Direct Connect", "ExpressRoute" and "Cloud Interconnect"
  • NIST SP 800-145, "The NIST Definition of Cloud Computing" (search on nist.gov)
  • Cisco Live On-Demand Library: search "cloud connectivity", "Cloud OnRamp" and "multicloud"