Palo Alto Prisma SDWAN Deep Dive Part 6: Cloud Onramp and Multicloud
Cisco’s Cloud OnRamp for IaaS and the Fortinet AWS Transit Gateway and Azure Virtual WAN designs both answered the same question — how does the overlay reach a public-cloud VPC or VNet without every branch building its own tunnel there — with a dedicated cloud-gateway concept, automated centrally. Prisma SD-WAN answers it with a design decision that, once you’ve read Parts 1–5, should feel entirely predictable: it doesn’t invent a new component. A cloud region just becomes another data centre site.
The DC-as-cloud-region pattern
Data-centre sites in Prisma SD-WAN are organised into clusters — a cluster determines which DC ION(s) a given set of branch sites builds its fabric tunnels to, with a default cluster catching any branch that isn’t explicitly mapped elsewhere. There’s nothing cloud-specific about a cluster; it’s the same construct used for an on-premises DC. What makes a cloud region work is simply putting a pair of virtual ION appliances — deployed as VMs, HA-paired for redundancy — inside a VPC or VNet and pointing a cluster at them. From that point on, the cloud region is architecturally indistinguishable from a physical DC: it joins AppFabric like any other site, it’s subject to the same App-Defined Policies from Part 3, and branch traffic destined for workloads in that VPC/VNet rides the fabric to it exactly the way it would to an on-premises data centre.
This is the same instinct behind Arista/VeloCloud’s Partner Gateway design and Cisco’s Transit-Gateway automation — reduce a new environment to a concept the architecture already understands — applied one level more literally than either: Prisma SD-WAN doesn’t even introduce a cloud-specific device type. It’s a DC ION, running in a cloud VM instead of on branch hardware.
Azure: the vWAN CloudBlade
The automation doing the heavy lifting on Azure is the Azure Virtual WAN with vION CloudBlade. Pointed at a target region (or regions), it provisions a Virtual WAN and vWAN Hub, a Resource Group containing a Transit VNET per region, deploys the HA vION pair into that Transit VNET, and connects the VNET to the regional Azure vWAN Hub — then, on the Prisma SD-WAN side, creates the IPsec VPN tunnel interfaces and BGP peering needed to bring the new DC site into the fabric. Two Standard IPsec VPN tunnel interfaces, BGP peer configuration, and a static route to support that peering all get created automatically; nobody is hand-building tunnel definitions per region. The result — a Transit VNET peered to customer workload VNETs through the Azure Virtual Hub, with link-quality measurement (LQM) running across it the same as any other fabric path — gives branch traffic a clean, measured path into Azure workloads without every branch needing its own direct Azure connection.
AWS: VPC extension and Transit Gateway
The AWS pattern is architecturally the same idea, deployed slightly differently depending on scale: for a single VPC, ION Virtual Appliances (available directly from AWS Marketplace) deploy into the VPC and extend the fabric to it exactly like the Azure case. For a design spanning many VPCs, the AWS Transit Gateway CloudBlade — one of the “popular CloudBlades” flagged in Part 5 alongside Zscaler and Netskope — automates the attachment between the Prisma SD-WAN fabric and an AWS Transit Gateway, so branch traffic can reach any VPC attached to that Transit Gateway without a dedicated ION-to-VPC tunnel per destination.
Traffic attraction: BGP, not fabric policy
One detail worth being precise about, because it’s a different mechanism from anything covered in Parts 3–4: getting traffic to the cloud DC site over the fabric is App-Defined Policy’s job, same as any other fabric destination. Getting the cloud-side network to prefer routing traffic back through the DC ION rather than some other path is a BGP job — the DC ION achieves this “traffic attraction” by injecting more specific or preferred routes toward the core router for Prisma-SD-WAN-managed site prefixes, over peering that can be configured as one of three types: core, edge, or classic, depending on where in the topology the peer sits. This is the same LAN/DC-routing layer Part 4 flagged as genuinely separate from fabric path selection — the cloud onramp case is simply the DC-routing story applied to a VPC’s route table instead of a physical core switch’s.
How this compares
| Cisco Cloud OnRamp for IaaS | Fortinet (Transit Gateway / vWAN designs) | Prisma SD-WAN | |
|---|---|---|---|
| Cloud concept | Dedicated transit VPC/VNet with SD-WAN edge routers as virtual aggregation routers | Hub FortiGates or native TGW/vWAN attachment, engineer-designed | Cloud region = ordinary DC site; virtual ION pair joins AppFabric |
| Automation | vManage-driven, native TGW/vWAN integration | Largely manual/Terraform-driven per the architecture decision | CloudBlade-driven: Azure vWAN and AWS TGW CloudBlades provision cloud + fabric sides together |
| New component introduced? | Yes — transit VPC/VNet purpose-built for SD-WAN | Depends on design (hub FortiGate reused) | No — same DC-site/cluster concept as on-prem |
| Traffic attraction into the cloud VPC/VNet | OMP-driven | BGP, engineer-configured | BGP (core/edge/classic peer types), CloudBlade-provisioned |
None of the three is strictly more automated than the others at this point — Cisco and Prisma SD-WAN both ship dedicated automation for the major hyperscalers, and Fortinet’s design leans more on the engineer explicitly building the Transit Gateway/vWAN attachment, which the Fortinet cloud on-ramp posts on this site cover in detail. Where Prisma SD-WAN’s approach is distinct is conceptual economy: there’s no separate mental model for “cloud gateway” versus “data centre” the way Cisco’s transit-VPC design introduces one. Once you understand DC clusters and DC-side BGP peering from ordinary on-premises design, cloud onramp is the same knowledge applied to a VM instead of a rack.
What’s next
Part 7 is the practical payoff of everything so far: an actual MPLS-to-Prisma-SD-WAN cutover playbook, using the Analytics-to-Control progression from Part 3 as the spine of a parallel-run migration — onboarding, validation, and the decommission sequence, done per site rather than as a single flag-day event.