My role
I partnered with the Azure cloud team on this Cloud NGFW for Azure deployment. The cloud team owned the Azure infrastructure; I helped with the deployment and led the security side: security policy, security posture, segmentation, application groups, and the overall cloud security approach.
The challenges I owned sat between application needs and enforceable controls:
- Tightening cloud security posture without breaking production: moving from broad access to specific, inspected access in stages that application owners can validate.
- Segmenting north-south and east-west traffic: separating internet-facing flows from workload-to-workload flows so each has a deliberate path and policy.
- Classifying App-IDs into application groups: turning the applications seen in traffic into named groups that express what each workload is allowed to use.
- Security profile posture: deciding which security profiles and profile groups apply to the traffic that policy allows.
- Explaining snippets and the folder structure: helping both teams understand how the Strata Cloud Manager configuration hierarchy scopes and shares policy.
- Deployment options: comparing the deployment architectures and policy-management models available for Cloud NGFW for Azure.
My job was to translate which workloads need to communicate into segmentation and policy the firewall can enforce, and to bridge the cloud and security teams so infrastructure and security decisions fit together. The sections below explain each of these topics in generalized form.
About this project
This project brings together Azure network design and Palo Alto Networks security controls. The engineering problem is broader than deploying a firewall: applications need a predictable inspection path, policies need to express their permitted dependencies, and operators need evidence that the intended controls are working.
My focus in this write-up is the logic connecting those elements. The architecture and examples are generalized so the technical reasoning can be shared without publishing private infrastructure details. The discussion covers design alternatives, the implementation sequence, and the validation criteria that make the design reviewable.
A cloud firewall becomes an effective security control only when application traffic reaches it, the intended policy is enforced, and the resulting evidence is available to the people who operate it. Creating the Azure resource is the beginning of that process.
This article presents an implementation approach for Palo Alto Networks Cloud NGFW for Azure, with Strata Cloud Manager (SCM) for security policy management. It covers Azure traffic steering, policy design, NAT, logging, troubleshooting, and operational acceptance. Examples are generalized and contain no private infrastructure details.
1. Start with the security requirement
The design objective is controlled access to Azure workloads and external services, with application-aware inspection and usable telemetry. To turn that objective into an implementation, the work is organized around four questions: which flows require inspection, how those flows reach the firewall, what policy should do with them, and what evidence demonstrates the result.
| Engineering question | Design artifact |
|---|---|
| Engineering questionWhat needs to communicate? | Design artifactApplication dependency and traffic matrix |
| Engineering questionWhere must inspection occur? | Design artifactForward and return path design |
| Engineering questionWhat should be permitted? | Design artifactSecurity rules, inspection profiles and exceptions |
| Engineering questionHow will the team verify it? | Design artifactTest cases, logs and acceptance record |
2. Cloud NGFW and VM-Series are different operating models
Cloud NGFW for Azure is a managed service. [1] VM-Series is a virtual firewall appliance deployment model. Familiarity with Palo Alto policy concepts is valuable in both, but appliance deployment procedures and supported configuration options should not be assumed to transfer unchanged to Cloud NGFW.
The practical consequence is a clear division of work: the project still needs customer-owned network design, workload access policy, change control, and monitoring, even when the firewall service handles its underlying infrastructure. A managed service reduces some infrastructure tasks; it does not define the application trust model.
3. Understand the service boundary
Cloud NGFW for Azure is a managed firewall service integrated with Azure. The service supports VNet and Virtual WAN deployments and offers multiple security policy management options. [1] It should not be treated as a customer-managed VM-Series appliance. This article uses the VNet deployment model and SCM as its operational focus.
Azure traffic steering remains part of the design: a firewall does not inspect a workload merely because both resources exist in the same subscription. For a VNet deployment, route tables must direct the intended flows to the service. [1]
Deployment and policy-management options
Two decisions shape the rest of the project: the Azure deployment architecture and the policy-management model. Microsoft documents both sets of options. [1]
| Decision | Documented options | What to consider |
|---|---|---|
| DecisionDeployment architecture | Documented optionsHub-and-spoke virtual network, or Virtual WAN; Cloud NGFW can also sit behind Azure Application Gateway for web applications | What to considerWhich architecture the existing Azure network already uses, and how routes will steer traffic to the firewall |
| DecisionPolicy management | Documented optionsAzure Rulestack in the Azure portal, Palo Alto Networks Panorama, or Strata Cloud Manager | What to considerWhether policy should be shared with other Palo Alto firewalls, and which features each mode supports |
Make the management choice before deployment. Palo Alto’s SCM guide describes selecting Strata Cloud Manager in the Security Policies settings when the Cloud NGFW resource is created. [2] Feature support also differs by mode: for example, application groups and security profile groups are listed for Panorama and SCM but not for native Rulestacks. [3]
4. Separate configuration ownership
| Configuration area | Primary management surface |
|---|---|
| Configuration areaSecurity rules and shared policy | Primary management surfaceStrata Cloud Manager |
| Configuration areaCloud NGFW NAT and DNS proxy | Primary management surfaceAzure portal |
| Configuration areaVNet topology and route tables | Primary management surfaceAzure networking configuration |
| Configuration areaTraffic and threat investigation | Primary management surfaceSCM and Strata Logging Service; Azure logging when configured |
SCM integration does not move every setting into one console. Palo Alto documents the Azure portal as the configuration surface for NAT and DNS proxy with SCM-managed Cloud NGFW. Confirm the supported feature matrix before translating an existing rulebase. [2], [3]
Folders and snippets in Strata Cloud Manager
Explaining the SCM configuration hierarchy early prevents confusion about where a setting lives and which firewalls it affects.
- Folders group firewalls that need similar configuration. Cloud NGFW resources linked to SCM start in the default All Firewalls folder, and can be organized into nested folders. [2] For firewall folders, SCM documents up to four nested levels, with All Firewalls always at the top. [7]
- Snippets are reusable configuration objects, or groups of objects, that can be associated with a folder, deployment, or device to apply a standard baseline. [6] Palo Alto’s Cloud NGFW guide points to snippets for applying standard settings and policy requirements across multiple folders. [2]
- Precedence: snippet associations have top-down priority when object values conflict, and settings inherited from a snippet can be overridden at the child folder, deployment, or device level. A snippet can be associated only once within a given folder hierarchy. [6]
| Illustrative element | Generic example | Purpose |
|---|---|---|
| Illustrative elementFolder path | Generic exampleAll Firewalls → Cloud → Azure workloads | PurposeScope configuration to the Cloud NGFW resources that share it |
| Illustrative elementSnippet | Generic examplebaseline-security-profiles | PurposeApply the same profile groups wherever the snippet is associated |
| Illustrative elementSnippet | Generic exampleshared-application-groups | PurposeReuse approved application groups across folders |
These names are illustrative only. The SCM snippets page notes that the feature may need to be enabled on request, so confirm availability for the tenant before designing around it. [6]
5. Design the Azure inspection path
Start with a traffic matrix. For every application dependency, identify the source subnet, destination, protocol, expected direction, and required inspection. Include DNS, update services, external APIs, and administrative access. This provides a testable scope before route or policy changes begin.
Outbound and east-west traffic
For VNet-based deployments, Microsoft documents user-defined routes with the Cloud NGFW private IP as the next hop. Associate the route table with the intended workload subnet. [1] A default route alone should not be treated as proof that every internal flow is inspected; verify the effective route for each destination in the traffic matrix.
Review the return path as carefully as the forward path. Record the relevant peering settings, subnet associations, network security groups, and destination-side controls. A successful connection without a corresponding firewall event may indicate a visibility gap or a path that bypasses inspection.
Inbound access and address translation
DNAT can expose an approved service through a firewall public address while translating traffic to an internal destination. [1] Keep exposure narrow and validate the destination application, security policy, and response path together. Treat the NAT mapping and the security rule as separate parts of the same change.
For outbound traffic, establish whether source translation is required and which public address downstream systems should observe. Test from the workload itself. Record any external allowlists that depend on that address before moving production flows.
Segment north-south and east-west traffic
Classify every flow in the traffic matrix by direction before writing policy. Microsoft describes three flow types for Cloud NGFW: inbound (public to private), outbound (private to public), and east-west (private to private). [1]
| Flow type | Typical path | Policy question |
|---|---|---|
| Flow typeNorth-south inbound | Typical pathInternet to a published service through DNAT | Policy questionWhich service is exposed, to whom, and with which inspection? |
| Flow typeNorth-south outbound | Typical pathWorkload to internet or external service | Policy questionWhich destinations and applications does each workload need? |
| Flow typeEast-west | Typical pathWorkload to workload, across subnets or spokes | Policy questionWhich internal dependencies are permitted, and are they routed through the firewall? |
How the distinction is expressed depends on the management mode. Microsoft describes private and public zones when Panorama manages Cloud NGFW. [1] With SCM, the security rule zone fields must be set to ANY, so segmentation is expressed through source and destination addresses, address groups, and applications, together with the Azure routes that bring each flow to the firewall. [2], [3]
6. Build policy around application intent
Create rules that describe a business dependency: which workload needs access, to what destination, for which application, and under which inspection requirements. Add an owner and review date to temporary exceptions. Preserve explicit evidence for both permitted and denied traffic.
Management modes do not provide identical capabilities. The SCM guidance currently specifies ANY in security-rule zone fields even though logs can show public and private zones. It also lists restrictions including User-ID, tag-based rules, and X-Forwarded-For. Recheck these details against the current service documentation before implementation. [2], [3]
Where supported and licensed, apply appropriate threat inspection and URL controls. Validate dependencies before narrowing a broad rule. For an unidentified application, capture the observed traffic and determine whether the selected management mode supports the needed application definition before using a custom application as the solution.
From App-IDs to application groups
Cloud NGFW uses the App-ID classification system, which relies on application signatures to identify applications, and supports application groups and application filters under Panorama and SCM management. [3]
- Observe: collect the App-IDs that each workload actually uses from traffic logs during testing.
- Classify: group the applications by business dependency, such as a web tier’s external dependencies or a management workflow.
- Group: create an application group for each set of sanctioned applications that need the same enforcement. When the supported applications change, update the group instead of every rule. [8]
- Filter with care: application filters match applications dynamically by attributes such as category, subcategory, technology, risk, and characteristics. Palo Alto describes filters as looser controls than groups and recommends using them to discover applications, then converting those rules to application groups that specify the exact applications to allow. [9], [10]
Illustrative group names such as app-grp-web-external or app-grp-admin-tools make the rule’s intent readable. These are examples, not names from any real environment. Note that Policy Optimizer, which helps convert port-based rules to application-based rules, is listed only for Panorama management of Cloud NGFW for Azure. [3]
Security profile posture
Security rules decide whether traffic is allowed; security profiles inspect the traffic that rules allow. A security profile group treats a set of profiles as a unit that can be added to rules. In Strata Cloud Manager, a profile is active only when it is in a profile group and a security rule references that group. A group can contain one profile of each type. [11]
For Cloud NGFW for Azure, the feature matrix lists default and custom profiles (for example, Antivirus, Vulnerability Protection, and URL Filtering) and security profile groups under SCM management, subject to licensing. [3] Define the profile groups as part of the policy design, record which rules use them, and confirm that threat logs show the expected inspection during acceptance testing.
7. Make logging part of acceptance
For an onboarded Cloud NGFW resource, SCM provides access to traffic and threat logs through Strata Logging Service. Azure log destinations are also supported, with configuration dependent on the selected management mode. [3], [4] Choose the investigation destination before cutover and test it with a known application transaction.
Record the test time, source, destination, application, rule, action, and session outcome. If NAT is involved, retain the translated addressing needed to follow the transaction. Set retention, access, and forwarding requirements deliberately; a visible event in one console does not prove delivery to an external SIEM.
Separate connectivity from detection
A successful application test demonstrates availability. A permitted-session event demonstrates visibility. An approved security test demonstrates that an inspection control produces the expected action and evidence. Use all three checks rather than treating a single allow event as proof of complete protection.
8. Troubleshoot from the workload outward
| Observed symptom | First checks |
|---|---|
| Observed symptomConnection fails and no firewall event appears | First checksEffective route, subnet association, DNS result, NSG, log scope and time range |
| Observed symptomFirewall records a deny | First checksMatched rule, policy order, application identification and active deployment |
| Observed symptomFirewall allows but the application fails | First checksDestination listener, response path, NAT, TLS and application logs |
| Observed symptomUnexpected public source address | First checksActual egress path, NAT configuration and external allowlists |
| Observed symptomPolicy change appears ineffective | First checksSCM scope, target resource, deployment result and a fresh test session |
| Observed symptomEvent is visible locally but absent in the SIEM | First checksForwarding configuration, destination health, ingestion delay and parser behavior |
Treat these as investigation starting points, not definitive diagnoses. Preserve the original symptom and change one variable at a time. Broad temporary allow rules can hide the actual dependency and make later policy cleanup harder.
Monitor capacity and service health
Palo Alto documents Azure Monitor metrics including throughput, sessions, latency, packet counts, and SNAT port utilization. [5] Establish a workload baseline and alert on sustained deviations. In particular, investigate address translation pressure alongside application connection failures instead of assuming every timeout is a policy problem.
9. Deploy in controlled stages
- Inventory the intended flows and their application owners. Capture existing routes, NAT dependencies, and logging requirements.
- Confirm the deployment region, subscription permissions, selected management mode, required capabilities, and commercial entitlements.
- Deploy and onboard the Cloud NGFW resource. Confirm that SCM targets the correct resource and that the intended policy is deployed.
- Enable the selected log destinations and validate access for the operating team.
- Move a limited test subnet or workload group into the inspection path. Validate both permitted traffic and expected blocks.
- Expand in batches after application owners confirm functionality and the security team verifies evidence.
- Close the change with a tested rollback procedure, named operational owners, and recorded acceptance results.
Tighten posture without breaking production
Tightening is a sequence, not a single change. Start from observed traffic, replace broad rules with application groups once dependencies are confirmed, and move one workload group at a time. Validate each step with the application owner and keep a rollback ready.
New App-IDs can change enforcement for traffic that is newly or differently classified. Palo Alto describes an application filter based on the New App-ID characteristic as a way to reduce that impact while new applications are assessed; confirm that the characteristic is available in the selected management mode before relying on it. [9] Treat any temporary broad rule as an exception with an owner and review date, as described in section 6.
10. Define production readiness with evidence
Keep a compact acceptance record: application test results, effective-route evidence, matched policy, NAT observations, log arrival, and rollback steps. Include a denied-flow test so the record demonstrates enforcement as well as connectivity. Review exceptions after the rollout and remove rules that were needed only for troubleshooting.
The operational lesson is straightforward: Azure configuration determines which traffic reaches the service; security policy determines what happens to that traffic; logging makes the result verifiable. Production readiness depends on all three working together.
Further reading
Official references
Official documentation reviewed on October 27, 2026. Feature availability and management support can change; validate the linked guidance for the deployment being implemented.
- Microsoft Learn. Cloud NGFW by Palo Alto Networks FAQ
- Palo Alto Networks. Strata Cloud Manager Policy Management
- Palo Alto Networks. Supported Security Policy Management Features
- Palo Alto Networks. View Traffic and Threat Logs in Strata Cloud Manager
- Palo Alto Networks. Cloud NGFW for Azure Release Notes
- Palo Alto Networks. Strata Cloud Manager: Snippets
- Palo Alto Networks. Strata Cloud Manager: Folder Management (NGFWs)
- Palo Alto Networks. Create an Application Group (Strata Cloud Manager)
- Palo Alto Networks. Policy Object: Application Filter
- Palo Alto Networks. Policy Optimizer Best Practices
- Palo Alto Networks. Security Profile Groups
This article is an independent educational resource by Sofia Wagner. Examples are generalized and contain no private infrastructure details.