Software Firewalls: VM-Series & Public Cloud

Why

Cloud providers secure the underlying infrastructure, but you remain responsible for securing what runs on top of it — network segmentation, traffic inspection, and policy are still the customer's job under the shared-responsibility model. Cloud workloads also scale elastically, so a static-capacity firewall design doesn't fit; security has to scale with the workload.

How

In a data center, "insert the firewall inline" means physically recabling. In the cloud, there's no cable to move — instead, VM-Series plugs into whatever traffic-steering construct the cloud provider already offers:

• Load balancers / Gateway Load Balancers — distribute traffic across an autoscaled firewall fleet (see AWS GWLB / Azure GWLB) instead of pinning all traffic to one instance, which is what lets the firewall layer itself scale rather than becoming a fixed-capacity bottleneck.
• Transit gateways/hubs — centralize routing so one shared security VPC/VNet can inspect traffic on behalf of many spoke VPCs/VNets, rather than every application VPC needing its own firewall pair.
• Autoscaling — adds or removes firewall instances based on actual current load, replacing the traditional approach of permanently provisioning for peak capacity you might only hit occasionally.

The reassuring part: none of this changes what the firewall actually does once traffic reaches it — the same App-ID/User-ID/Content-ID policy model carries over completely unchanged. What's different in the cloud is purely the plumbing that gets traffic to the firewall, not the inspection or policy logic itself.

Why

Cloud-native workloads want elastic, pay-for-what-you-use capacity; traditional enterprise buyers often want predictable, pre-purchased capacity tied to an existing agreement. One licensing model can't serve both well, so VM-Series offers both.

How

Axis one — license type — answers "how do you pay":

• BYOL (bring your own license) — purchased and activated against your existing support account, fitting an organization that already buys enterprise software this way.
• PAYG — bought hourly/usage-based directly from a cloud marketplace (AWS/Azure/GCP) or a CSSP, fitting a trial, short-lived, or genuinely elastic workload where upfront procurement doesn't make sense.

Axis two — capacity model — answers "how is firewall capacity defined and changed":

• Software NGFW Credits (flexible vCPU) — reusable credits you activate and pool, then spend via a deployment profile bundling vCPU count, chosen security services, and optionally Panorama, up to 64 vCPUs on PAN-OS 10.0.4+. All firewalls sharing one profile share a single auth code and update together — and because a profile change is just a credit reallocation, not a new license, it propagates automatically with no reboot, which is exactly what a genuinely elastic cloud workload needs.
• VM-Series Model — fixed vCPUs per model (VM-100/300/500/700), sold as an Enterprise License Agreement token pool, a perpetual capacity license, or a term license, each optionally bundling Threat Prevention and other services. Because capacity here is tied to a specific license grant rather than a reallocatable credit pool, changing it means acquiring a new license and rebooting — real downtime that the credit model was built specifically to avoid.

The two axes are genuinely independent — you pick a payment method and a capacity model separately, and the combination you land on determines both your ongoing cost structure and how much operational friction a future capacity change will cost you.

Why

Each direction carries a different threat model — internet-facing inbound traffic needs to be defended against exploits and vulnerability scans, outbound traffic needs to be prevented from exfiltrating data or reaching malicious infrastructure, and east-west (inter-VPC/VNet/subnet) traffic needs to stop malware or a compromised workload from moving laterally. A single design has to account for all three without three separate, unrelated firewall deployments.

How

Each direction is answering a different question about traffic, which is why one firewall design has to reason about all three separately even though they share the same rulebase concept:

• Inbound (north-south) — "is this exploit traffic aimed at what we've exposed?" A cloud security-group/NSG has already made a coarse allow/deny decision on ports and source ranges before traffic ever reaches the firewall — inbound inspection picks up from there, protecting externally-reachable resources (web servers) from exploits and vulnerabilities riding inside traffic that was already let through the coarse cloud-native filter.
• Outbound (north-south) — "is this workload behaving, or leaking data?" Ensures workloads only reach permitted destinations/URL categories, blocks data exfiltration attempts, and — because outbound connections get responses — still scans the return traffic for malware riding back in.
• East-West — "can a compromise in one place spread to another?" Inspects traffic between VPCs/VNets/subnets specifically to contain malware propagation and enforce segmentation between application tiers or business units — the cloud equivalent of the zone-based segmentation covered on the Policy & Segmentation page.

Why centralization is the common target, not per-VPC firewalls. The common target architecture funnels all three directions into one shared security VPC/VNet (a "hub"), reached via Gateway Load Balancer endpoints or a transit gateway. The reasoning: deploying and managing a separate firewall pair inside every single application VPC multiplies operational overhead by the number of VPCs, while a hub design lets one managed firewall fleet protect many application VPCs at once — the tradeoff (that hub becoming a concentrated critical path) is covered in the cons below.

Why

Workloads on EC2 need the same App-ID/Content-ID protection as on-prem servers, but the deployment mechanics (image sourcing, licensing, autoscaling, network attachment) have to speak AWS's native model rather than a traditional hardware install process.

How

Baseline requirements to get a VM-Series instance running on standard AWS: an AWS account, an Amazon Machine Image (AMI) ID for the VM-Series image itself, a license (PAYG from the AWS Marketplace, or BYOL), the VM-Series plugin, and Panorama with the Panorama plugin for AWS specifically needed once you're managing licensing/config for more than one or two instances at scale.

Why the specialized variants exist, and what actually changes in each:

• AWS GovCloud — an isolated AWS region built for US government compliance/CUI (controlled unclassified information) data. Same feature set as standard AWS, but with two real operational differences: only horizontally-scalable deployment is supported (not every standard-AWS design pattern carries over), and offline licensing requires manually entering CPU ID/UUID/auth-code through the CSP rather than the streamlined online activation standard AWS gets — a genuinely heavier process, consistent with GovCloud's isolation requirements.
• AWS China — BYOL-only, through a completely separate AWS China account. There's no PAYG marketplace shortcut here the way there is on standard AWS, because China's cloud regions operate as functionally distinct accounts/ecosystems.
• AWS Outposts — BYOL AMIs deployed on AWS hardware that physically sits in your own data center. This exists for organizations that want AWS's operational model and consistency but have a regulatory, latency, or data-residency reason they can't put the workload in an actual AWS region.

Why

Manually routing every application VPC's traffic through a fixed firewall pair doesn't scale and doesn't tolerate firewall failure gracefully. GWLB turns the firewall fleet into an elastic, load-balanced, fault-tolerant service that other VPCs can consume like any other AWS-managed endpoint.

How

The core topology. Firewalls sit behind a GWLB in a centralized security VPC attached to a Transit Gateway (TGW) — this is the concrete implementation of the "hub" design described in the previous section. Traffic reaches the firewall via Gateway Load Balancer Endpoints (GWLBE), created both in each spoke/application VPC and in the security VPC itself, and the whole path uses GENEVE encapsulation between GWLB and VM-Series — which matters because GENEVE wraps the original packet without stripping or rewriting its headers/payload, so the firewall retains full end-to-end visibility (including the true original source) despite the traffic having passed through a load balancer along the way.

How each of the three traffic directions actually routes through this topology:

• Inbound — arrives via the Internet Gateway, routes to a GWLBE that sends it to the firewall, then continues to the application via an Application Load Balancer (ALB).
• Outbound — originates in an application VPC, routes via TGW to the security VPC's GWLBE, through the firewall, then exits via a NAT Gateway.
• East-west — between two application VPCs, routes through TGW into that same security-VPC GWLBE/firewall path before continuing on to its destination VPC — every direction funnels through the identical firewall stack, which is exactly what makes one centralized hub sufficient for all three.

Why Appliance Mode is a hard requirement, not an optimization. A GWLB distributes flows across an autoscaled pool of firewall instances — but a stateful firewall needs to see both the outbound leg and its return traffic on the same instance, since it's tracking session state (and if decryption is enabled, decrypted session material) that a different instance simply wouldn't have. Appliance mode, enabled on the TGW VPC attachment for the security VPC, is what pins request and response traffic to that same firewall instance. Without it, GWLB has no way to maintain that per-flow persistence, and traffic silently fails in one direction only — the single most common GWLB misconfiguration in practice. VM-Series supports full decryption (including TLS 1.2/1.3 with DHE/ECDHE) while deployed this way, so this isn't a design that trades away inspection depth for scalability.

Why

Azure customers expect firewall deployment and HA to integrate with Azure-native primitives (Azure Load Balancer health probes, Azure Security Center, ARM/Solution Templates) the same way AWS customers expect CloudFormation/GWLB integration — the underlying firewall logic is identical, but the cloud plumbing has to match the platform.

How

Getting deployed — two ends of a convenience/flexibility tradeoff. Azure Marketplace Solution Templates are the fast path: pre-wired networking that gets a standard topology running quickly. A fully custom VM image trades that speed for the ability to fit a bespoke topology the template wasn't designed for — plus Azure China variants exist for deploying into that sovereign cloud specifically.

Why HA works differently here than on-prem — the actual reason, not just "it's cloud." Traditional on-prem PAN-OS HA relies on dedicated HA links and L2 adjacency between the active and passive firewall. Azure's virtual network model doesn't support that same L2 adjacency assumption between VMs the way a physical switch fabric does. So active/passive HA on Azure instead relies on Azure's own health-probe mechanism to detect a failed instance — a fundamentally different failure-detection mechanism, which is exactly why failover timing and behavior don't carry over unchanged from on-prem experience.

The Azure-native integrations, and what each solves:

• Azure health monitoring — lets Azure Load Balancer itself detect a failed firewall instance and stop routing traffic to it, the same health-probe mechanism underpinning HA above, now applied to load-balanced traffic distribution.
• Azure Security Center integration — surfaces VM-Series alerts directly inside Azure's native security dashboard, so Azure admins see firewall alerts in the same place they already monitor everything else, instead of needing a separate pane purely for firewall events.
• VM-Series + Azure Application Gateway template — combines Azure's own L7 web app gateway with VM-Series inspection specifically for web-facing workloads, layering NGFW-grade inspection onto traffic Application Gateway is already fronting.

Why

The same problem GWLB solves on AWS applies on Azure: a firewall fleet needs to sit transparently in front of application traffic, scale independently, and stay fault-tolerant, without every application VNet needing custom routing logic per firewall instance.

How

The mechanism, and how it differs conceptually from AWS's GWLBE model. On AWS, GWLB Endpoints are inserted into route tables directly. On Azure, Gateway Load Balancer instead chains onto a standard Azure Load Balancer's frontend — meaning client traffic still enters through the Load Balancer frontend applications already point at, and Azure GWLB transparently redirects that traffic through the VM-Series firewall stack before it continues to the real backend. The end result is the same idea as AWS GWLB — a scalable firewall fleet sits transparently in the path without applications needing to know it's there — just implemented through Azure's own load-balancer-chaining primitive instead of AWS's endpoint-service model.

Why symmetric routing is non-negotiable here too, for the exact same reason as AWS. Decryption and threat prevention are connection-based — the firewall instance handling a flow needs to see both the outbound leg and its return traffic to maintain session and (if applicable) decrypted state. Whichever cloud platform provides the load-balancing layer, that requirement doesn't change; only the mechanism for achieving it (Appliance Mode on AWS, the chaining configuration on Azure) is platform-specific.

Why

GCP customers get the same App-ID/Content-ID policy engine, but need it to integrate with GCP's autoscaling groups and internal/external load balancers, and to meet GCP-specific platform requirements (minimum system requirements, secure boot support) for the images they run.

How

By this point in the guide, the pattern across all three major clouds should feel familiar — the same underlying needs (scale with demand, steer traffic transparently, fail over gracefully), each solved with that specific cloud's own native primitive rather than a one-size-fits-all mechanism:

• Deployment models range from a single standalone instance up to a fully autoscaled firewall tier, depending on scale needed.
• Autoscaling on GCP adds/removes VM-Series instances behind a GCP load balancer based on real-time load — the same "match capacity to demand instead of provisioning for peak forever" idea as AWS/Azure autoscaling, just running on GCP's own autoscaling groups.
• The GCP load balancer is what actually steers traffic into the firewall tier — conceptually GWLB's role, but expressed through GCP's own internal/ external load balancer constructs rather than a GWLB-equivalent product.
• Secure boot support and documented minimum system requirements gate which GCP machine types/images are actually supported — worth checking before assuming any arbitrary GCP instance type will run VM-Series.
• Active/passive HA on GCP is supported, and like Azure, it relies on GCP's own health-check/failover primitives rather than dedicated HA links — but unlike Azure's relatively similar-in-spirit health-probe model, GCP HA has its own distinct documented caveats worth checking per release, which is exactly why HA runbooks don't transfer cleanly between clouds even though the underlying goal (detect failure, fail over) is identical everywhere.

Why

Private-cloud/virtualized data centers built on NSX-T need the same App-ID-driven east-west and north-south protection as public cloud, but have to plug into VMware's own service-chaining and steering-rule model instead of a cloud provider's load balancer.

How

Why this needs a specific chain of components, each with its own role. There's no single "install the firewall" step here — NSX-T's service-insertion model means several systems each own one piece of the process, and all of them have to agree with each other:

• vCenter/ESXi — the underlying compute virtualization layer everything else sits on top of.
• NSX-T Manager 3.0+ — registered with vCenter, and specifically what's required to actually deploy VM-Series onto ESXi hosts. This is the piece that owns service chains and steering rules — the NSX-T-native mechanism for directing traffic through a security appliance.
• Panorama 9.1+ with the Panorama plugin for VMware NSX 3.0+ — works together with NSX-T Manager to deploy, license, and centrally administer the firewalls, keeping this environment on the same management plane as every other Palo Alto form factor rather than a bespoke VMware-only console.
• VM-Series plugin 1.0.6+ — on the firewalls themselves. This platform is BYOL-only across VM-100/300/500/700 models, with up to 64 vCPUs available via Software NGFW credits — no PAYG marketplace shortcut the way public cloud offers, because there's no cloud marketplace to buy from in a private NSX-T environment.

Why two different deployment workflows exist — because "who owns what" differs by org. The operations-centric workflow splits the work along existing team boundaries: Panorama handles plugin communication, template stacks/device groups, service definition, and firewall launch; NSX-T Manager handles service chains and steering rules; then the process returns to Panorama for security policy. This fits organizations where NSX-T steering rules change often and admins are genuinely comfortable operating both consoles. The security-centric workflow exists for the opposite situation — where the security team wants to drive as much of the process as possible from Panorama, with minimal direct hands-on time in NSX-T Manager, because that's not really their tool or their team's day-to-day responsibility.