how can I set up Prisma SD WAN on an Azure landing...

If by “Azure accelerator” you mean the Azure Landing Zones IaC Accelerator, I’d set it up so that Azure Landing Zones owns the Azure platform network, and Prisma SD-WAN integrates into that network as a brownfield Virtual WAN integration.

The key architectural choice is: have the ALZ accelerator create Azure Virtual WAN and the Virtual Hubs first; then let the Prisma SD-WAN “Azure Virtual WAN with vION” CloudBlade attach to those existing hubs. Palo Alto explicitly supports this brownfield model, and describes it as the most common deployment model. (Palo Alto Networks TechDocs)

Recommended architecture

text
Azure tenant
│
├── Platform
│   ├── Management subscription
│   ├── Identity subscription
│   ├── Security subscription
│   └── Connectivity subscription
│        │
│        └── Azure Virtual WAN
│             │
│             ├── vHub - East US 2
│             │      │
│             │      ├── Application LZ VNets
│             │      ├── ExpressRoute/VPN if required
│             │      │
│             │      └── Prisma Transit VNet
│             │             ├── vION-1  ─┐
│             │             └── vION-2  ─┴─ BGP → vHub
│             │
│             └── vHub - West US 2
│                    │
│                    ├── Application LZ VNets
│                    └── Prisma Transit VNet
│                           ├── vION-1
│                           └── vION-2
│
└── Branches / datacenters
       │
       └──── Prisma SD-WAN Secure Fabric ────► vIONs
                                                │
                                                ▼
                                           Azure vWAN
                                                │
                                                ▼
                                        Application LZs

The ALZ reference architecture places the hubs and shared networking services in the Connectivity subscription, while application VNets live in separate application landing-zone subscriptions. Azure Virtual WAN then provides the transitive connectivity between them. (Microsoft Learn)

1. Deploy the landing zone first

For a new environment, use the current ALZ IaC Accelerator, preferably Terraform. Microsoft currently recommends the accelerator for deploying the Terraform-based Azure Landing Zone. (Azure)

There are several current accelerator scenarios, including:

• Multi-region Virtual WAN + Azure Firewall
• Multi-region Virtual WAN + NVA
• Single-region Virtual WAN + Azure Firewall
• Single-region Virtual WAN + NVA

(Azure)

For Prisma SD-WAN connectivity, I would normally start with:

text
ALZ Accelerator
      ↓
Virtual WAN + Azure Firewall
      ↓
Prisma SD-WAN vION transit VNet

rather than automatically picking the “Virtual WAN + NVA” accelerator scenario.

There is an important nuance here: the ALZ NVA scenario expects the third-party NVA to perform functions such as DNS proxying to the Azure Private DNS Resolver. (Azure) Prisma SD-WAN vIONs are being introduced primarily for SD-WAN connectivity, so I would not treat the Prisma vION pair as the accelerator's generic security NVA merely because it is a virtual appliance.

If you are also deploying Palo Alto VM-Series / Cloud NGFW as the security enforcement point, then the ALZ NVA architecture becomes a different discussion.

2. Let ALZ own Virtual WAN

Configure the accelerator to create, for example:

text
Connectivity subscription
  rg-connectivity-eastus2
  rg-connectivity-westus2

  vwan-global
    vhub-eastus2
    vhub-westus2

For multi-region environments, Azure Virtual WAN Standard automatically provides hub-to-hub connectivity, and Microsoft specifically recommends Virtual WAN as one of the standard ALZ networking topologies. (Microsoft Learn)

Do not ask the Prisma CloudBlade to create a second vWAN.

This gives you a clean ownership model:

Resource	Owner
Management groups / policies	ALZ accelerator
Connectivity subscription	ALZ accelerator
Azure Virtual WAN	ALZ accelerator
Azure Virtual Hubs	ALZ accelerator
DNS / Private DNS Resolver	ALZ accelerator
Azure Firewall, if used	ALZ accelerator
Prisma transit VNets	Prisma CloudBlade
vION VMs	Prisma CloudBlade
vION configuration	Prisma SD-WAN
vION ↔ vHub BGP	Prisma CloudBlade
Application LZ VNets	subscription vending / workload IaC

That boundary also reduces Terraform/CloudBlade ownership collisions.

3. Reserve address space for Prisma

Before running the accelerator, put the Prisma transit networks into your enterprise IP plan.

For example:

text
Azure
10.0.0.0/8

Platform
10.0.0.0/12

vHub East US 2
10.0.0.0/23

Prisma transit East US 2
10.0.16.0/24

vHub West US 2
10.0.2.0/23

Prisma transit West US 2
10.0.17.0/24

Application LZs
10.16.0.0/12

Palo Alto's current CloudBlade documentation allows the Transit Virtual Network CIDR to use prefix lengths from /16 through /26. (Palo Alto Networks TechDocs)

Make sure these ranges don't overlap with Azure workloads, branches, datacenters, or other SD-WAN sites.

4. Create the Prisma Azure identity

After the Connectivity subscription exists, create an Entra application/service principal for the Prisma integration.

Palo Alto's documented process is to capture:

text
Tenant ID
Client ID
Client secret
Azure subscription ID

and assign the application Contributor access. (Palo Alto Networks TechDocs)

For an ALZ deployment, scope that access to the Connectivity subscription rather than tenant/root management-group scope unless you have a specific reason to go broader.

Conceptually:

text
Entra ID
└── App registration: prisma-sdwan-azure
      │
      └── Contributor
             │
             ▼
       Connectivity subscription

I would create the identity and RBAC assignment through your platform IaC pipeline, and treat the client secret as a managed secret rather than committing it to the ALZ repository.

5. Configure Prisma as a brownfield vWAN deployment

In Strata Cloud Manager:

text
Configuration
  → Prisma SD-WAN
  → CloudBlades
  → Azure Virtual WAN with vION

Choose/configure the brownfield model.

Typical inputs might resemble:

text
Azure Subscription ID:
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Tenant ID:
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Client ID:
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Client Secret:
********

Transit Virtual Network CIDR:
eastus2:10.0.16.0/24,
westus2:10.0.17.0/24

Virtual WAN Resource:
rg-connectivity-global:vwan-global

Virtual Hub Resources:
vhub-eastus2,
vhub-westus2

The actual resource names should come from the outputs of your ALZ deployment.

In brownfield mode, the CloudBlade references the existing Azure vWAN/vHubs and creates a Prisma transit VNet per region. Only a hub in the same Azure region can be associated with that regional transit VNet. (Palo Alto Networks TechDocs)

6. Let CloudBlade deploy the vION layer

The nice part is that you don't need to model most of the Prisma internals in the ALZ Terraform.

The current vION CloudBlade automatically:

• deploys two vIONs per region
• places the pair in separate availability zones where supported
• creates the Prisma transit VNet
• creates its private/LAN, Internet/public, and controller subnets
• connects that VNet to the Virtual Hub
• claims the vIONs into Prisma SD-WAN
• creates the data-center site
• establishes BGP between the vIONs and Azure Virtual Hub
• configures the required routes

(Palo Alto Networks TechDocs)

Palo Alto currently lists an active Prisma SD-WAN subscription and enough licensing for at least two v7108 IONs per region as prerequisites. (Palo Alto Networks TechDocs)

7. Connect application landing zones to vWAN

Your application subscription vending process then connects workload VNets to the appropriate vHub.

For example:

text
App subscription A
   VNet 10.16.0.0/16
        │
        └──── vHub East US 2

App subscription B
   VNet 10.17.0.0/16
        │
        └──── vHub East US 2

App subscription C
   VNet 10.32.0.0/16
        │
        └──── vHub West US 2

The ALZ subscription-vending Terraform module supports vWAN connectivity for landing-zone VNets, so you can make hub attachment part of the application-LZ vending process rather than hand-building connections. (GitHub)

The resulting route path becomes:

text
Branch
  ↓
Prisma ION
  ↓
Prisma SD-WAN fabric
  ↓
Azure vION pair
  ↓ BGP
Azure vHub
  ↓
App landing-zone VNet

and in reverse:

text
Application VNet
  ↓
Azure vHub
  ↓
Prisma vION
  ↓
Secure Fabric
  ↓
Branch

8. Decide where security enforcement happens

This is one of the most important design decisions.

A common design is:

text
                Prisma SD-WAN
                     │
Branches ───────────►│
                     ▼
                  vION pair
                     │
                     ▼
                 Azure vWAN
                   /     \
                  /       \
        Azure Firewall    App VNets

Then you can use Azure vWAN routing/route tables/routing intent to determine which flows traverse your central security layer.

For example:

text
Branch → Azure workload
Prisma → vHub → Firewall → App VNet

Azure workload → Internet
App VNet → vHub → Firewall → Internet

Azure workload → Branch
App VNet → vHub → Prisma vION → Branch

Don't accidentally configure both Prisma and Azure Firewall to attract the same 0.0.0.0/0 path without deciding which should win. That's a common way to create asymmetric routing.

Azure vWAN gives you route tables and propagation controls specifically for segmentation and traffic steering. (Microsoft Learn)

9. Check ALZ policies before enabling CloudBlade

This part is easy to miss.

Because CloudBlade creates infrastructure dynamically, your ALZ policies must allow the Prisma deployment to create the required:

text
Resource group
VNet
Subnets
NICs
Public connectivity
vION VMs
vHub connection
Routes/BGP configuration

Palo Alto documents that the integration uses Azure APIs for resource groups, deployments, subnets, NICs, and other resources. (Palo Alto Networks TechDocs)

So before installing the CloudBlade, run a policy review against the Connectivity subscription. In particular, look for policies around:

text
Allowed VM SKUs
Allowed Azure regions
Allowed marketplace images
Public IP addresses
NSGs
NIC configuration
Mandatory tags
DDoS
Resource naming
Managed disk encryption
Diagnostic settings

If a policy conflicts with the vION deployment, create a narrow exemption at the Prisma transit resource-group scope, rather than disabling the policy globally.

10. Validate routing before onboarding branches

Palo Alto's current validation sequence is useful. Verify that:

1. CloudBlade status is green.
2. Prisma created the Azure data-center site.
3. Both vIONs are assigned.
4. Secure Fabric links exist.
5. vION interface IP addresses match Azure.
6. Both vION ↔ Azure vHub BGP peers are up.
7. Required static routes exist.
8. Azure application prefixes are received by Prisma.
9. Branch prefixes are advertised toward Azure.

(Palo Alto Networks TechDocs)

I would then explicitly test:

text
Branch → Azure VM
Azure VM → Branch
Branch A → Branch B through Prisma
Azure region A → branch
Azure region B → branch
Regional vION failure
Single vION failure
vHub route propagation
DNS resolution
Firewall traversal, if used

The deployment sequence I would use

text
1. Bootstrap ALZ accelerator
          ↓
2. Deploy platform subscriptions
          ↓
3. Deploy Azure vWAN + regional vHubs
          ↓
4. Validate hub routing/DNS/security
          ↓
5. Create Prisma Entra app + RBAC
          ↓
6. Configure Prisma CloudBlade in BROWNFIELD mode
          ↓
7. CloudBlade deploys transit VNets + HA vIONs
          ↓
8. Verify BGP vION ↔ vHub
          ↓
9. Vendor application landing zones
          ↓
10. Connect application VNets to vHub
          ↓
11. Configure vWAN route tables / firewall routing
          ↓
12. Onboard Prisma branches
          ↓
13. Failover and route-convergence testing

One architectural principle I'd stick to is ALZ owns the vWAN; Prisma owns the SD-WAN integration. Avoid the Prisma greenfield option in an ALZ environment because it allows CloudBlade to create the vWAN and vHubs itself; that splits ownership of core platform resources between the accelerator and Prisma and makes governance/state management harder. Palo's brownfield mode exists specifically to attach to an already deployed vWAN/vHub. (Palo Alto Networks TechDocs)

Azure Landing Zones IaC Accelerator documentation
Prisma SD-WAN Azure Virtual WAN with vION integration

If you're implementing this with the Terraform ALZ accelerator, the next useful step would be to map this into the actual accelerator tfvars, subscription-vending configuration, CIDRs, and Prisma CloudBlade values for a 1- or 2-region deployment.