SDWSCS Part 12: Cloud Interconnect & OnRamp for Colocation

Part 11 connected the fabric to each cloud over the Internet. This part covers the two patterns for estates that have outgrown that: software-defined cloud interconnect (SDCI) — private, SLA-backed paths into and between clouds, provisioned like cloud resources — and Cloud OnRamp for Colocation — putting a compact, orchestrated network-services stack in a carrier-neutral facility and steering regional traffic through it.

Cloud Interconnect: private paths, API provisioning

The traditional way to get private cloud connectivity — order a Direct Connect or ExpressRoute circuit, wait weeks, terminate it somewhere you have kit — sits awkwardly with everything else in this course being a vManage workflow. SDCI providers (Megaport and Equinix are the integrated ones) fix the model: they already have dense fibre into every major cloud on-ramp, and they sell virtual cross-connects (VXCs) across that footprint by API, in minutes, at bandwidths you can change.

The Cisco integration puts a virtual edge inside the provider’s fabric: vManage deploys a Catalyst 8000V as a Megaport Virtual Edge (MVE) or into Equinix Network Edge, and that instance becomes a fabric node like any other. From vManage’s Interconnect workflow you then provision:

  • Site-to-cloud: VXC from the virtual edge to AWS Direct Connect, Azure ExpressRoute, or GCP Partner Interconnect — private connectivity to the same TGW/vWAN/NCC constructs Part 11 built, minus the Internet underlay.
  • Cloud-to-cloud: VXC between two clouds through the interconnect fabric — the sane answer to multicloud east-west, keeping inter-cloud traffic off both the Internet and your DC.
  • Site-to-site: the interconnect fabric as a private middle mile between regions, an underlay option alongside your Internet transports.

The design win is that branches don’t need new circuits: they reach the virtual edge over the ordinary overlay on their existing transports, and the private leg begins there. The virtual edge is a TLOC like any other, so app-route policy can prefer it per application — Salesforce over Internet DIA, the latency-sensitive database replication over the ExpressRoute VXC, chosen by SLA class.

What to compare when choosing between the two providers is mundane and decisive: on-ramp density where your sites and clouds are, VXC pricing at your bandwidth points, and which cloud pairings are first-class.

Cloud OnRamp for Colocation: the regional stack, orchestrated

The second pattern solves a different problem: you want the Part 5 dedicated-security answer — a real regional inspection stack — without owning data centres. Cloud OnRamp for Colocation puts the stack in a colo facility (ideally the same one the interconnect lives in) as an orchestrated appliance cluster:

  • Hardware: Cisco Cloud Services Platform (CSP-5000 series) x86 hosts running NFVIS, fronted by a pair of Catalyst 9500 switches — the whole unit deployed and managed as a cluster by vManage.
  • Workloads: VNFs from the validated catalogue — C8000V for routing, firewalls (Cisco or third-party — ASAv/FTDv, Palo Alto, Fortinet), WAN optimisers, whatever the design needs.
  • The orchestration: vManage’s service chain designer. You define a chain — say C8000V → FTDv → exit — and vManage instantiates the VNFs on the cluster, wires the service VLANs between them, and publishes the chain so that fabric policy (the same OMP service routes and set service actions from Part 5) can steer VPN traffic through it.

The intended consumption model: regional branches send their Internet-bound or inter-VPN traffic across the overlay to the colo, through the chain, and out — a regional security hub without a regional data centre. Combined with the interconnect piece, the same facility gives those branches their private cloud on-ramp; that pairing (chain + VXC in one carrier hotel) is the whole argument for the colo pattern.

Choosing between everything since Part 5

At this point the course has given you four places to put dedicated inspection and three ways to reach cloud; the honest selection table:

You needAnswer
Inspection at a handful of big sites you ownService chain in your DC (Part 5)
Regional inspection, no real estateOnRamp for Colocation
Private cloud connectivity, one cloud, one regionDirect DX/ER into your DC or colo
Private multicloud, multiple regions, agilitySDCI virtual edge + VXCs
Small sites, Internet-bound trafficNone of the above — SIG (Part 7)

Colocation earns its complexity only at sufficient regional scale — the CSP cluster is a capability you staff and lifecycle, not a checkbox. Below that threshold, SIG plus embedded security covers the same risk more cheaply; above it, the colo pattern gives you controls the cloud-delivered stack can’t match (your firewall, your rules, full throughput, no per-tunnel ceilings).

Next up, Part 13, the finale: monitoring and operating everything this series deployed — vManage’s security and cloud dashboards, vAnalytics, and the day-2 checklist for the whole security-and-cloud estate.