SDWSCS Part 11: Cloud OnRamp Multicloud — AWS, Azure & GCP

Parts 6–10 dealt with SaaS — traffic to applications someone else runs. This part extends the fabric to IaaS: your own workloads in AWS, Azure and GCP, reachable as first-class fabric destinations with the same segmentation, policy and telemetry as any branch. The manual version of this is a well-understood slog (C8000Vs in a transit VPC, IPsec, BGP — I walked the Fortinet equivalent in the cloud on-ramp pair); Cloud OnRamp for Multicloud is vManage automating that slog end to end.

The common shape

Whatever the provider, the workflow builds the same three things:

1. A cloud gateway — a pair of Catalyst 8000V instances deployed by vManage into a transit construct in the provider, running as ordinary fabric edges (OMP, TLOCs, BFD — colour typically biz-internet or public-internet, plus provider backbone options).
2. Native transit attachment — the C8000Vs connect to the provider’s own transit layer (TGW/vWAN/NCC), which hauls traffic between the gateway and your workload VPCs/VNets at provider speeds.
3. Intent mapping — the piece that makes it SD-WAN rather than plumbing: a matrix in vManage mapping cloud tags to service VPNs. Tag VPCs prod and map to VPN 10; tag dev, map to VPN 20; the fabric’s segmentation now extends into the cloud, and VPCs in different VPNs can’t talk unless policy says so — same rules as branches, enforced through the same OMP machinery.

Setup is anticlimactic by design: associate cloud account credentials (an IAM role/service principal vManage can drive), pick a region, choose gateway instance sizes and the license/image, click create. vManage drives the provider APIs; twenty minutes later show sdwan omp routes on a branch includes VPC CIDRs learned via the cloud gateway’s TLOCs.

Provider specifics worth knowing

AWS. The gateway pair lands in a transit VPC and attaches to an AWS Transit Gateway; workload VPCs attach to the same TGW and vManage manages the route-table plumbing and the tag-to-VPN mapping. Connectivity between C8000V and TGW uses VPN attachments or Connect attachments (GRE) for higher per-tunnel throughput — Connect is the right default at scale. The newer option targets AWS Cloud WAN instead of per-region TGWs: a global provider backbone with segment semantics that map naturally onto VPNs. Region-to-region traffic can then ride AWS’s backbone rather than your overlay — a routing-policy decision vManage exposes rather than makes for you.

Azure. The integration deploys the C8000V pair as an NVA inside an Azure Virtual WAN hub (or attaches to an existing one); VNets attach to the vWAN hub, and the tag/VPN mapping drives which VNets are reachable from which service VPN. Azure’s twist is that the NVA-in-hub model makes the gateway a managed-app deployment — sizing is chosen in “NVA infrastructure units” rather than raw instance types, and day-2 resize is a redeploy, so size for headroom.

GCP. The gateways peer with Network Connectivity Center (NCC) as a site-to-site spoke; workload VPCs join as VPC spokes, with Google’s global VPC/backbone doing the interconnect. GCP’s global-by-default VPC design means fewer per-region gateways for the same coverage — the intent mapping is the same.

	AWS	Azure	GCP
Transit construct	TGW / Cloud WAN	Virtual WAN hub	NCC
Gateway placement	Transit VPC	Inside vWAN hub	Peered VPC
Gateway↔transit link	VPN / GRE Connect	Hub NVA (native)	NCC spoke
Segment extension	Tags → VPNs	Tags → VPNs	Tags → VPNs

Design decisions the wizard won’t make for you

• Gateway sizing and licensing. The C8000V’s throughput is tiered (and DRE/security features change the math) — size against the aggregate branch-to-cloud demand for the region, not the average.
• Where inspection happens. Branch-to-VPC traffic in VPN 10 passes no firewall unless you put one in the path — the Part 5 service-chaining conversation recurs in the cloud: chain via a firewall VNet/VPC, use the provider’s firewall service, or accept segmentation as the control.
• Overlay vs provider backbone for east-west. Cloud-to-cloud (region-to-region, or AWS-to-Azure via an interconnect) can ride your overlay through gateways or the provider’s backbone — cost, latency and visibility all differ; Part 12’s interconnect options extend this menu.
• Failure domains. The gateway pair is your cloud region’s front door; treat its health (BFD sessions, tracker state, provider-side attachment status) as tier-1 monitoring, and know whether branch traffic fails over to another region’s gateway or backhauls via the DC when it dies.

Verification is pleasingly ordinary — the cloud gateway is just an edge: show sdwan control connections, show sdwan bfd sessions, show sdwan omp routes vpn 10, plus the Cloud OnRamp dashboard’s per-gateway health and the provider console when attachments misbehave.

Next up, Part 12: the connectivity patterns between clouds and back to earth — software-defined cloud interconnect through Megaport and Equinix, and Cloud OnRamp for Colocation for the estates that want their security stack in a carrier hotel.