Cloud NGFW
Cloud NGFW: Concepts, Components & Billing 61
Learning objectives
- Explain what makes Cloud NGFW a managed service rather than a VM you operate
- Name the core components: tenant, NGFW resource, rulestack
- Describe how inbound, outbound and east-west traffic reach the firewall
- Compare pay-as-you-go with the credit model, and Standard with Premium
Cloud NGFW is a machine-learning next-generation firewall delivered as a cloud-native service. Palo Alto Networks runs and scales the firewall. You describe the policy and point traffic at it. It is sold through the cloud provider (Azure Native ISV Service, AWS Marketplace) and managed with the provider's own tools: portal, RBAC, ARM templates, API and Terraform.
Why
Teams that already run workloads in a public cloud want App-ID, URL filtering, threat prevention and decryption without deploying, patching, licensing and scaling firewall VMs themselves. Cloud NGFW removes that operational work and lets the cloud team stay inside its normal workflow.How
You subscribe through the cloud marketplace, create a Cloud NGFW resource in a region, attach a rulestack (the rules, objects and Security Profiles), and change the cloud routing so traffic flows through the firewall. Resilience and elastic scaling are handled by the service.
- Cloud NGFW (tenant/service). The managed regional service, available in selected regions.
- NGFW resource. The firewall tied to your VNet or vWAN hub. It appears as private IP addresses in the NGFW subnet you choose. You update route tables (UDRs) to send traffic to those addresses.
- Rulestack. A set of security rules with their objects and Security Profiles. A local rulestack can be attached to one or more NGFW resources. Policy authored in Panorama arrives as a global rulestack.
Three traffic directions
How you pay
| Model | How it works |
|---|---|
| Pay-as-you-go | Hourly rate per NGFW resource plus a per-GB charge for traffic processed. Add-ons (Threat Prevention, Advanced URL Filtering, DNS Security, WildFire, Panorama management) add their own hourly and per-GB charges. |
| Credits | Prepaid Cloud NGFW credits on a one to five year contract, bought in the marketplace or at a private price from Palo Alto Networks or a partner. Lower cost up to the purchased capacity. Consumption above the credits is billed at pay-as-you-go rates. |
| Standard instance | Foundation tier for standard policy sets. Autoscaling handles peaks up to 100 Gbps. |
| Premium instance | For highly sensitive applications. Larger policy sets and faster ramp-up, peaks up to 200 Gbps, at a higher price. |
Pros
- No firewall VMs to size, patch, license or scale
- Native cloud experience: portal, RBAC, API, ARM templates, Terraform
- One policy model that can be shared with PA-Series and VM-Series through Panorama
- Traffic is inspected without redesigning the application networks beyond routing changes
Cons
- You do not configure interfaces, zones or routing on the firewall. The service owns them
- Available only in supported regions and clouds
- Per-resource and per-GB billing needs monitoring at high traffic volumes
- Feature and scale limits are lower in native rulestack mode than under Panorama
Exam trap
Cloud NGFW is not a VM-Series firewall in disguise. There is no interface, zone or virtual router to build. If a question asks how to bring traffic to it, the answer is cloud routing (UDRs, routing intent, or Transit Gateway routes), not a new interface on the firewall.
Self-check: Cloud NGFW concepts
Curriculum: Software Firewall (NGFW) course. Sources: Cloud NGFW for Azure overview, pricing and limits pages in the local docs mirror.
Cloud NGFW Deployment Models (Azure & AWS) 62
Learning objectives
- Choose between hub-and-spoke VNet and Virtual WAN on Azure
- Choose between distributed, centralized (Transit Gateway) and combined on AWS
- Match a stated requirement (least compute, minimal network change, unified policy) to a model
Why
The right model depends on how the cloud network is already built. Forcing every application to change its routing is expensive, and running one firewall per VPC or VNet wastes compute.How
Each cloud offers a model that keeps the existing hub or independent-spoke layout, and the choice is about where the firewall attaches and how routes are changed.
| Cloud | Model | How traffic reaches the firewall | Choose it when |
|---|---|---|---|
| Azure | Hub-and-spoke VNet | NGFW private IPs in the hub VNet. Update VNet routes (UDRs) to send traffic through them. | Applications route independently and you want few changes |
| Azure | Virtual WAN | NGFW attached to the virtual hub. Routing intent steers traffic to it. | You already use vWAN, multiple regions, branches, ExpressRoute or VPN |
| AWS | Distributed | NGFW endpoints in each protected VPC. | Each VPC needs its own inspection point |
| AWS | Centralized | NGFW components in a central security VPC. All traffic passes the Transit Gateway (TGW) to the security VPC, then to the NGFW endpoint. | Many VPCs already connect to a Transit Gateway |
| AWS | Combined | Centralized for east-west and outbound, distributed endpoints where needed. | Mixed requirements |
Worked example from the practice sets
A company has AWS (all VPCs on a Transit Gateway) and Azure (each application routes independently). It must minimise changes, scale using the least compute, and unify policy across everything. Which two designs fit?
- Azure: deploy Cloud NGFW in the VNets, update VNet routing through the NGFWs, manage policy with Panorama. Few changes and one policy plane.
- AWS: deploy Cloud NGFW in a centralized security VPC, update the Transit Gateway to route through it, manage policy with Panorama. One firewall deployment instead of one per VPC.
- Wrong: VM-Series in every VPC plus an IPSec tunnel (compute and complexity), or local rules (breaks unified policy).
Pros
- Keeps the existing cloud network design
- Centralized AWS model avoids a firewall per VPC
- vWAN model covers branches and multiple regions from the hub
Cons
- Every model still needs deliberate route changes, and a missed route bypasses inspection
- Centralized designs concentrate traffic through one inspection point
Exam trap
Words like "least compute" and "minimize changes" point to the managed Cloud NGFW model with central inspection. Wording about "unified policy" points to Panorama, not local rulestacks.
Self-check: deployment models
Curriculum: Software Firewall (NGFW) course. Sources: Cloud NGFW for Azure deployment architectures page (local docs mirror), Cloud NGFW for AWS centralized deployments (Palo Alto Networks docs), and the NGFW Engineer practice sets.
Cloud NGFW Policy Management, Limits & Logging 63
Learning objectives
- Compare native rulestacks, Panorama, Strata Cloud Manager, and API/Terraform
- Explain Cloud Device Groups, Cloud template stacks and what Cloud NGFW ignores
- Recall the Panorama prerequisites and the key scale limits
Why
Cloud teams want quick native policy, while security teams want the same rules across data center firewalls and cloud firewalls. Cloud NGFW supports both.How
Pick one management path per firewall resource.
- Native rulestack. Author rules, prefix lists, FQDN lists and certificate objects in the Cloud NGFW console. Certificates come from Azure Key Vault and are used for outbound decryption (PAN-OS 11.0.x is required for that).
- Panorama. Install the Panorama Azure plugin (mandatory), link the tenant, then author rules in a Cloud Device Group. That group manifests as a global rulestack in each region it is associated with. A Cloud template stack holds template settings.
- Strata Cloud Manager. Cloud-managed policy across the whole security estate.
- API or Terraform. The recommended way to manage policy as code.
Cloud NGFW ignores template settings for interfaces, zones and routing protocols. It honors certificate management and log settings. Zones in inherited rules map to two Cloud NGFW zones, Public and Private.
Limits worth remembering
| Attribute (per Cloud NGFW resource) | Native rulestack | Panorama Standard | Panorama Premium |
|---|---|---|---|
| Security rules | 1,000 | 10,000 | 20,000 |
| Decryption rules | n/a in this table | 1,000 | 2,000 |
| Address objects | 1,000 | 20,000 | 40,000 |
Panorama prerequisites
- Panorama 11.2 or later for new customers (12.0 and 12.1 not supported), and Azure plugin 5.2.3 or later
- Registered and licensed Panorama, with the device certificate installed
- Same CSP account email for Cloud NGFW and Panorama, and a Panorama Administrator role
- Open ports 3978, 28443 and 28270 toward Panorama
- Network path from Panorama to the VNet: Panorama in the hub VNet, in a peered VNet, or on-premises over VPN
- Redeploy the Cloud NGFW resource after adding a log collector or changing the Panorama IP
Logging
Traffic, threat and decryption logs can be viewed natively in Azure and sent to Strata Logging Service. Activity and audit logs are available for the firewall resource and its resource groups. With Panorama, logs and activity are viewable in Panorama too.
Pros
- Panorama gives one rulebase across PA-Series, VM-Series and Cloud NGFW
- Native rulestacks are fast for cloud-only teams
- Policy as code through API and Terraform
Cons
- Native rulestack limits are far below Panorama's
- Panorama integration has version and plugin constraints
- Infrastructure settings in templates are silently ignored
Exam trap
Assigning managed devices to a Cloud Device Group is not how it works. You do not assign managed devices to Cloud DGs or Cloud template stacks. The Cloud DG is tied to the Cloud NGFW resource and region through the Azure plugin.
Self-check: policy management
Curriculum: Software Firewall (NGFW) course. Sources: Cloud NGFW for Azure native policy management, Panorama policy management, prerequisites, and limits pages in the local docs mirror.
Module Quiz
1. What best describes Cloud NGFW?
2. In a Cloud NGFW for Azure hub-and-spoke deployment, how is traffic sent through the NGFW?
3. Which mechanism steers traffic to Cloud NGFW in an Azure Virtual WAN hub?
4. An AWS estate connects many VPCs through a Transit Gateway. Which Cloud NGFW design uses the least compute?
5. Which Panorama component is mandatory to manage Cloud NGFW for Azure policy, and what does a Cloud Device Group become?
6. Which settings in a template added to a Cloud template stack does Cloud NGFW honor?
7. Approximately how many security rules can one Cloud NGFW resource hold in native rulestack mode versus Standard SKU under Panorama?
8. Which ports must be reachable toward Panorama for Cloud NGFW integration?
9. Which is the recommended way to automate Cloud NGFW policy across environments?
10. A customer buys a three-year block of Cloud NGFW credits and consumption exceeds it in some months. What happens to the excess?
11. AWS uses a Transit Gateway. Azure applications each route independently. The company needs minimal change, least compute, and unified policy. Which pair fits?