Cos’è Cloud OnRamp for Multicloud

Cloud OnRamp for Multicloud è il framework di Cisco Catalyst SD-WAN che estende il fabric SD-WAN dentro il cloud pubblico in modo automatizzato. Invece di costruire a mano VPN IPsec, route table e peering, il controller Catalyst SD-WAN Manager (l’ex vManage) orchestra il deploy di gateway SD-WAN virtuali — le istanze Catalyst 8000V (C8000V) — dentro le VPC/VNet del provider e li salda ai costrutti di rete nativi (AWS Transit Gateway, Azure Virtual WAN, GCP Network Connectivity Center). Il risultato è che una branch remota raggiunge i workload IaaS con la stessa segmentazione (service VPN), policy e telemetria del resto dell’overlay.

Attenzione a non confonderlo con Cloud OnRamp for SaaS, che non fa deploy di gateway ma misura la qualità applicativa (loss/latency via probe) verso app SaaS per scegliere il path migliore. Qui il focus è IaaS/Multicloud: infrastruttura di connettività, non application steering.

Componenti e ruoli

Componente Ruolo
SD-WAN Manager Orchestratore: onboarding account, deploy CGW, discovery, mapping intent-based
Cloud Gateway (CGW) Punto di attestazione nel cloud; ospita uno o più C8000V
C8000V WAN Edge virtuale che termina i tunnel dell’overlay e le service VPN
Costrutto nativo TGW (AWS) / Virtual WAN hub (Azure) / NCC (GCP) che interconnette le host VPC/VNet

Il workflow di automazione

1. Onboarding dell’account cloud

È il passo dove più candidati e progetti reali si bloccano. SD-WAN Manager deve autenticarsi al provider con credenziali che abbiano permessi sufficienti a creare risorse:

  • AWS: IAM role (cross-account, con external ID) oppure access/secret key, con policy per gestire EC2, TGW, VPC, IAM pass-role.
  • Azure: un service principal (app registration) con ruolo Contributor sulla subscription, più tenant ID, client ID e secret.
  • GCP: service account con chiave JSON e i ruoli di rete/compute necessari.

Se i permessi sono troppo stretti, il discovery magari funziona ma il deploy del CGW fallisce silenziosamente o a metà.

2. Deploy del Cloud Gateway

Definiti account e region, SD-WAN Manager istanzia il CGW: fa spin-up dei C8000V, li registra come WAN Edge (serve licenza/token valido), configura le interfacce e crea l’attach al costrutto nativo. Su AWS crea/associa la Transit VPC e le TGW attachment; su Azure integra i C8000V come NVA nell’hub Virtual WAN.

3. Host discovery e intent mapping

SD-WAN Manager interroga il provider e scopre le host VPC/VNet e i relativi tag. Il design chiave è il mapping intent-based: si associano i tag cloud (o le singole VPC/VNet) alle service VPN (segmenti) dell’overlay. Questo determina quali workload finiscono in quale segmento e, di conseguenza, la reachability end-to-end. Cambiando il tag di una VPC, la si sposta di segmento senza toccare la CLI.

Host VPC (tag: prod)  ─┐
                       ├─►  mapping  ─►  Service VPN 10
Host VPC (tag: dev)   ─┘                 Service VPN 20

I limiti che bloccano l’automazione

L’automazione dipende dalla disponibilità per regione dei costrutti. Non tutte le region espongono Transit Gateway Connect, i tipi di istanza richiesti dal C8000V, o Virtual WAN nella forma attesa; alcune region richiedono attivazione esplicita. In quei casi il workflow non completa, indipendentemente dalla correttezza della configurazione SD-WAN. I service quota del provider (numero di TGW, VPC attachment, EIP, vCPU) sono un secondo blocco comune.

Trappole tipiche d’esame

  • Scenario: il deploy del Cloud Gateway fallisce mentre il discovery delle VPC riesce → Risposta giusta: i permessi IAM/service principal sono insufficienti per creare risorse (mancano diritti EC2/TGW o il ruolo Contributor su Azure); il discovery richiede meno privilegi del provisioning.
  • Scenario: l’intera automazione non parte in una specifica region → Risposta giusta: la region non supporta i costrutti richiesti (TGW Connect / instance type del C8000V / Virtual WAN) o non è abilitata; scegliere una region supportata, non modificare le policy SD-WAN.
  • Scenario: serve indirizzare gli utenti verso Microsoft 365/Webex in base a loss/latency → Risposta giusta: è compito di Cloud OnRamp for SaaS, non di Multicloud/IaaS (che non fa application probing).
  • Scenario: dopo il deploy una host VPC “prod” non è raggiungibile dal segmento giusto → Risposta giusta: il tag-to-VPN mapping è assente o errato; la reachability nel modello intent-based dipende dal mapping tag→service VPN, non da route statiche manuali.
  • Scenario: il CGW si crea ma i C8000V restano offline nell’overlay → Risposta giusta: mancano licenza/OTP di onboarding o raggiungibilità ai controller (vBond/Validator, vSmart/Controller); verificare enrollment e connettività di controllo, non il mapping.