Palo Alto Prisma SDWAN Deep Dive Part 2: ION, Strata Cloud Manager, and the Planes
Part 1 covered the lineage. This post covers the hardware and software you’d actually procure, and where it sits against the management/control/data framework this site has used for every vendor so far.
The ION line
ION — Instant-On Network — is Palo Alto’s name for the SD-WAN edge appliance, physical or virtual, and it’s the only device in this architecture that touches user traffic. There’s no separate controller appliance, no separate gateway box shipped to a customer site; whatever control and policy-enforcement work needs to happen at the edge happens on the ION itself. The current line runs from small branch to large regional hub:
| Model | Class | Typical placement |
|---|---|---|
| ION 1000 / 1200 | Small branch | Single-circuit or dual-circuit retail/branch |
| ION 2000 | Small-to-mid branch | Multi-circuit branch, modest throughput |
| ION 3000 | Mid branch | Larger branch, higher VPN/tunnel scale |
| ION 5000 | Large branch / small DC | Regional office, small data centre |
| ION 7000 | Large DC / regional hub | High-throughput aggregation point |
| ION 9000 | Large DC / regional hub | Highest-scale physical aggregation point |
| ION 3000v / 7000v / virtual ION | Virtual | ESXi, KVM, and public-cloud (AWS/Azure) deployment as a VM |
Every ION, from the smallest branch box to the largest DC appliance, runs the same software and the same three functions in one device: it terminates the physical circuits (MPLS, broadband, LTE/5G, satellite — whatever the site has), it runs the stateful firewall and App-ID classification engine against every flow, and it participates in AppFabric, the secure tunnel mesh covered properly in Part 3. There is no ION model that does only control-plane work or only forwarding — unlike Cisco’s vSmart/WAN-Edge split or even Arista’s Gateway/Edge split, every ION is doing the full job, all the time. The size tiers scale VPN/tunnel count, throughput, and interface density, not architectural role.
Strata Cloud Manager: the management plane, and the reason there’s no controller to rack
This is the detail that trips people up coming from any of the other three architectures on this site: there is no on-premises controller option for Prisma SD-WAN, full stop. Not “not recommended past a certain scale” the way vManage clustering gets discouraged past a few thousand edges, not “usually cloud-hosted but self-hosted is available for regulated customers” the way some vendors offer — Prisma SD-WAN’s management and policy-authoring plane has been cloud-delivered SaaS since the CloudGenix days, and it still is now that it’s been absorbed into Strata Cloud Manager, Palo Alto’s unified console that also drives NGFW and Prisma Access configuration.
The lineage of that console is worth being explicit about, because you’ll see all three names depending on the age of the documentation you’re reading:
| Era | Console name |
|---|---|
| Pre-2020 | CloudGenix Portal |
| 2020 – ~2024 | Prisma SD-WAN (standalone portal) |
| ~2024 onward | Strata Cloud Manager — SD-WAN as one configuration surface among several |
Practically, this means an administrator managing Prisma SD-WAN today isn’t logging into a Prisma-SD-WAN-specific tool the way a Cisco engineer logs into vManage or a Fortinet engineer logs into FortiManager — they’re in the same console used to manage the customer’s NGFWs and Prisma Access tenant, looking at an SD-WAN-specific set of screens within it. That’s a genuinely different operational shape from every other vendor on this site, and it’s the clearest architectural signal of where Palo Alto has taken this product since the acquisition: not toward being a better standalone SD-WAN controller, but toward being one configuration domain inside a single security platform.
Where the planes actually live
Applying the management/control/data framework to Prisma SD-WAN produces a shape that doesn’t map cleanly onto any of the three architectures already covered:
| Plane | Where it lives | Notes |
|---|---|---|
| Management | Strata Cloud Manager (cloud, SaaS-only) | Config authoring, software/certificate lifecycle, dashboards. No on-prem option. |
| Control (policy authoring) | Strata Cloud Manager (cloud, SaaS-only) | App-Defined Policies, Path Policies, security rules — authored centrally, pushed down. |
| Control (real-time decision) | Every ION, locally | Per-flow path selection against live telemetry — happens at the edge, not in the cloud. |
| Data | Every ION | Packet forwarding, AppFabric tunnel termination, App-ID enforcement. |
That split-control-plane row is the important one, and it’s what makes Prisma SD-WAN genuinely hard to place next to the other three philosophies. Fortinet collapses control fully onto the data-plane device — no cloud component in the loop at all for route exchange. Arista/VeloCloud and Cisco/Viptela both centralise control on a dedicated component (Gateway, vSmart) that every edge continuously depends on for new route learning. Prisma SD-WAN centralises policy authoring in the cloud — Strata Cloud Manager is the single source of truth for what “good” means for each application, and it’s where telemetry from every ION gets aggregated for the dashboards and reports covered in Part 4 — but it deliberately does not centralise the moment-to-moment forwarding decision. That decision is made locally, on the ION, against a locally-cached policy and locally-measured path telemetry.
The practical consequence, which we’ll test properly against Fortinet’s and Cisco’s failure modes in Part 8: an ION that loses its connection to Strata Cloud Manager doesn’t stop making path decisions. It keeps enforcing whatever policy it last received and keeps measuring its own paths in real time, because the decision loop was never dependent on a live round-trip to the cloud in the first place. What it loses is the ability to receive new policy and the ability to report telemetry upstream — closer to Arista’s “new routes stop, existing tunnels keep forwarding” failure mode than to a hard outage, but for a structurally different reason: not because a route reflector went quiet, but because the local decision loop was designed to be self-sufficient from day one.
API and automation surface
Because Strata Cloud Manager is the only management plane, it’s also the only automation surface, and it’s a mature one: a REST API covering site creation, ION onboarding, WAN interface configuration, path policy, security policy, application definitions, and telemetry queries, plus an official Terraform provider (PaloAltoNetworks/prismasdwan) and a Python SDK (prisma-sase on PyPI) for teams who want SD-WAN fabric managed as code rather than clicked through a UI. A representative Terraform resource block for a WAN interface’s path-policy binding looks like this:
resource "prismasdwan_path_policyset" "branch_default" {
name = "branch-default-app-slas"
rule {
name = "voip-realtime"
app_def_ids = [data.prismasdwan_appdef.zoom.id]
active_path_label = ["public-broadband", "mpls"]
priority = 1
}
}We’ll come back to the automation surface with real onboarding and policy-push examples in Part 7 when we cover the MPLS cutover playbook — for now, the point is that everything a Strata Cloud Manager admin can click, a Terraform pipeline can also push, which matters a great deal once you’re managing more than a handful of sites and don’t want configuration drift between them.
What’s next
Part 3 is where the philosophical claim from Part 1 gets tested against the actual mechanics: how AppFabric builds its tunnel mesh, what a “Secure Fabric Link” actually is, and — the part every OMP- or BGP-literate reader will want proof of — how path selection genuinely happens without anything resembling a routing protocol advertising a route.