9.3 Cloud NGFW & Virtual Firewall Architecture (AWS, Azure & Containers)

9.3 Cloud NGFW & Virtual Firewall Architecture (AWS, Azure & Containers)

Cloud NGFW: Fully Managed Native PaaS (AWS & Azure)

As enterprises migrate mission-critical workloads into public cloud environments, traditional Infrastructure-as-a-Service (IaaS) firewall deployments can introduce substantial operational overhead. Managing virtual machines, orchestrating auto-scaling groups, handling software upgrades, and configuring complex cloud routing fabrics demands continuous engineering effort. Cloud NGFW for AWS and Cloud NGFW for Azure solve these challenges by delivering Palo Alto Networks' industry-leading security as a fully managed, cloud-native Platform-as-a-Service (PaaS).

+-----------------------------------------------------------------------------------+
|                         CLOUD NGFW PAAS ARCHITECTURE                              |
|                                                                                   |
|  [Customer VPC / VNet Spoke Workloads]                                             |
|         |                                                                         |
|         v                                                                         |
|  [Cloud Routing Fabric: AWS Transit Gateway (TGW) / Azure Virtual WAN (vWAN)]     |
|         |                                                                         |
|         v                                                                         |
|  [Hyperscaler Integration Point: AWS GWLB Endpoints (GWLBE) / Azure Security Hub] |
|         |                                                                         |
|         v (Transparent GENEVE / Native Encapsulation)                             |
|  +-----------------------------------------------------------------------------+  |
|  |            FULLY MANAGED PALO ALTO NETWORKS CLOUD NGFW FABRIC               |  |
|  |  - Elastic, Automated Scaling (No instances to size or cluster)             |  |
|  |  - Automated Zero-Downtime OS Patching & Dynamic Content Updates            |  |
|  |  - Native Cloud Resiliency & Availability Across Availability Zones         |  |
|  |  - RuleStack Policy Enforcement (App-ID, Advanced Threat Prevention, CDSS)  |  |
|  +-----------------------------------------------------------------------------+  |
+-----------------------------------------------------------------------------------+

Core PaaS Architectural Characteristics

• Zero Infrastructure Lifecycle Management: The underlying compute infrastructure, high-availability clustering, OS upgrades, security patching, and capacity planning are managed entirely by Palo Alto Networks in close partnership with AWS and Microsoft Azure. There are no EC2 instances or Azure VMs visible in the customer's cloud management console.
• Automated Elastic Scaling: Cloud NGFW transparently scales processing capacity up or down in response to fluctuating network traffic demands and connection rates. This eliminates the risk of dropped packets during sudden traffic spikes and avoids paying for over-provisioned idle compute.
• Hyperscaler-Native Orchestration:
  • AWS Integration: Integrates directly with AWS Gateway Load Balancer (GWLB). Cloud NGFW deploys dedicated Gateway Load Balancer Endpoints (GWLBE) into customer VPCs. Using the GENEVE protocol (UDP port 6081), traffic is routed to the firewall fabric while preserving original Layer 3 and Layer 4 packet headers and client IP addresses.
  • Azure Integration: Delivered as a native Azure Native ISV Service. Integrates directly into Azure Virtual WAN (vWAN) hubs as a Software-as-a-Service security solution, or into hub-and-spoke Virtual Networks (VNets) using Azure Route Server and software-defined routing tables.

RuleStack Architecture & Management

Policies within Cloud NGFW are organized into RuleStacks:

• Local RuleStacks: Scoped to an individual AWS account or Azure subscription. Managed directly by application teams to define custom rules, security profiles, and inbound/outbound inspection policies specific to that account's applications.
• Global RuleStacks: Centrally authored and governed by the enterprise security operations team across multiple AWS organizations, accounts, or Azure tenants. Global rules take precedence, enforcing corporate-wide compliance baselines (such as blocking high-risk applications or enforcing outbound decryption).
• Management Consoles: RuleStacks can be managed via the native AWS Console or Azure Portal, through Infrastructure-as-Code (Terraform provider, AWS CloudFormation), or centrally through Strata Cloud Manager (SCM) and Panorama.

---

VM-Series Virtualized Firewalls: High-Performance Multi-Cloud IaaS

Where organizations require complete control over PAN-OS operating system configurations, custom routing topologies, or private hypervisor environments, the VM-Series virtual next-generation firewall provides the complete feature set of physical hardware appliances in a virtual form factor.

Supported Environments

• Private Cloud / Hypervisors: VMware ESXi, KVM, Nutanix AHV, Microsoft Hyper-V.
• Public Cloud: Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), and Oracle Cloud Infrastructure (OCI).

Hardware Acceleration & Datapath Optimization

To deliver multi-gigabit throughput in virtualized environments, VM-Series incorporates specialized networking frameworks:

• Data Plane Development Kit (DPDK): Bypasses the virtual machine's standard Linux kernel network stack, executing packet processing directly in user space. This drastically reduces CPU interrupt overhead and context switching.
• Single Root I/O Virtualization (SR-IOV): Allows a physical network adapter (NIC) to present multiple virtual functions directly to the VM-Series guest OS. Packets bypass the hypervisor virtual switch entirely, achieving near bare-metal wire-speed forwarding and ultra-low jitter.
• Dedicated Management vs. Data Cores: Like hardware appliances, VM-Series allocates dedicated vCPU cores to the Management Plane (handling commits, logging, and Panorama communications) and distinct vCPU cores to the Data Plane (executing the Single-Pass Parallel Processing engine).

---

VM-Series Licensing Models: BYOL, PAYG & Software NGFW Credits

Palo Alto Networks offers three distinct licensing models to accommodate diverse procurement, budgeting, and deployment lifecycles.

Deep-Dive: Software NGFW Credits (Flex Licensing)

Software NGFW Credits represent the modern, enterprise standard for virtual firewall licensing. Instead of locking licenses into rigid hardware-equivalent models, the organization purchases a shared pool of credits registered in the Palo Alto Networks Customer Support Portal or Strata Cloud Manager.

Credit Consumption Calculation:
The number of credits consumed per hour by an active VM-Series firewall is dynamically calculated based on three variables:

1. vCPU Allocation: The number of vCPU cores provisioned to the VM (e.g., 2, 4, 8, 16, or 32 vCPUs).
2. Security Profile Tier (CDSS): The attached subscription bundle—such as Core (Threat Prevention), Advanced (Threat Prevention + WildFire + Advanced URL Filtering), or Complete (Advanced Threat Prevention + Advanced WildFire + Advanced URL Filtering + Advanced DNS + Enterprise DLP).
3. Add-on Services: Enabling GlobalProtect gateway services or virtual systems (vsys).

When a firewall instance is decommissioned or scaled down, it immediately ceases burning credits, returning capacity to the shared enterprise pool. Furthermore, credits can be transferred dynamically between AWS, Azure, GCP, and on-premises VMware ESXi without re-procurement.

---

VM-Series Auto-Scaling & Zero-Touch Bootstrapping

To maintain security across elastically expanding cloud application workloads, VM-Series integrates with native cloud auto-scaling architectures:

• AWS Auto Scaling Groups (ASG) with GWLB: An ASG monitors traffic demand. As traffic increases, the ASG launches additional VM-Series instances behind the AWS Gateway Load Balancer, using health checks to distribute traffic symmetrically.
• Azure Virtual Machine Scale Sets (VMSS): Automatically scales VM-Series instances behind Azure Load Balancer (ALB).

+-----------------------------------------------------------------------------------+
|                         VM-SERIES BOOTSTRAP ARCHITECTURE                          |
|                                                                                   |
|  [Cloud Storage Bucket: AWS S3 / Azure Blob / GCP Bucket]                         |
|         |                                                                         |
|         +--> /config                                                              |
|         |      |-- init-cfg.txt     <-- Panorama IP, VM-Auth-Key, Device Group    |
|         |      +-- bootstrap.xml    <-- Baseline Day-0 PAN-OS XML Configuration   |
|         +--> /license                                                             |
|         |      +-- authcodes        <-- Software NGFW Credit Auth Token           |
|         +--> /software                                                            |
|         |      +-- (optional)       <-- Specific PAN-OS Base Image                |
|         +--> /content                                                             |
|                +-- (optional)       <-- Dynamic Content Updates (App/Threat-ID)   |
|                                                                                   |
|         | (Instance Boot: Reads Cloud Metadata & Mounts Storage Bucket)           |
|         v                                                                         |
|  [Newly Launched VM-Series Instance]                                              |
|  - Applies bootstrap.xml (Interfaces, Zones, Virtual Routers configured)          |
|  - Claims Software NGFW Credits from Auth Token                                   |
|  - Registers with Panorama, joins Device Group, pulls active security policies     |
|  - Reports Healthy to GWLB and begins processing transit traffic in minutes       |
+-----------------------------------------------------------------------------------+

The Exact Bootstrapping Directory Structure

When a newly created VM-Series instance boots for the first time without a local drive configuration, it queries cloud instance user-data metadata pointing to an object storage bucket (AWS S3 bucket, Azure Storage Account Blob, or GCP Storage Bucket). The storage bucket must contain an exact four-directory hierarchy:

• /config: Contains two critical files:
  • init-cfg.txt: Key-value parameters including the Panorama IP address, Panorama VM registration authentication key (vm-auth-key), device group name, template stack name, and network configuration mode (DHCP vs static).
  • bootstrap.xml: The Day-0 XML configuration file that defines baseline interfaces, security zones, virtual routers, and management access profiles.
• /license: Contains license authorization codes or Software NGFW credit authorization tokens (authcodes).
• /software: (Optional) Contains a specific PAN-OS software image to upgrade or downgrade the instance during initial boot.
• /content: (Optional) Contains dynamic content update packages (Applications and Threat database, WildFire signatures) ensuring the newly booted firewall is current before processing its first packet.

---

CN-Series Containerized Firewalls: Kubernetes Microsegmentation

Modern containerized microservices running on Kubernetes (Amazon EKS, Azure AKS, Google GKE, Red Hat OpenShift) communicate primarily via east-west traffic within the cluster. Traditional perimeter firewalls and even VM-Series virtual appliances are blind to pod-to-pod communications occurring across the cluster's internal Container Network Interface (CNI).

CN-Series is the industry's first container-native next-generation firewall designed specifically to secure containerized Kubernetes environments.

+-----------------------------------------------------------------------------------+
|                         CN-SERIES KUBERNETES ARCHITECTURE                         |
|                                                                                   |
|  KUBERNETES WORKER NODE                                                           |
|  +-----------------------------------------------------------------------------+  |
|  |                                                                             |  |
|  |  +-------------------------+            +--------------------------------+  |  |
|  |  |     CN-Mgmt Pod         |            |          CN-Data Pod           |  |  |
|  |  |  - Panorama Registration|            |  - High-Speed Dataplane Engine |  |  |
|  |  |  - Policy Sync & Logs   |            |  - App-ID & Threat Prevention  |  |  |
|  |  +-------------------------+            +--------------------------------+  |  |
|  |               ^                                         ^                   |  |
|  |               | (Control Channel)                       | (eBPF / OVS Tap)  |  |
|  |               +--------------------+                    |                   |  |
|  |                                    |                    |                   |  |
|  |  +-----------------------+         |         +-----------------------+      |  |
|  |  |   Payment Pod (App)   |---------+-------->|  Customer DB Pod (App)|      |  |
|  |  |   Namespace: 'prod'   |  (Inspects Traffic|  Namespace: 'secure' |      |  |
|  |  |   Label: tier=frontend|   Before Forward) |  Label: tier=database |      |  |
|  |  +-----------------------+                   +-----------------------+      |  |
|  +-----------------------------------------------------------------------------+  |
+-----------------------------------------------------------------------------------+

DaemonSet Architecture: CN-Mgmt vs. CN-Data

CN-Series deploys as a Kubernetes DaemonSet, guaranteeing that an instance automatically spins up on every worker node in the cluster:

• CN-Mgmt (Management Pod): Runs as a lightweight pod on the node. It manages lifecycle communications with Panorama, synchronizes security policies, monitors node health, and forwards traffic logs, threat logs, and telemetry to Cortex Data Lake.
• CN-Data (Data Plane Pod): The high-performance packet processing container running the PAN-OS Single-Pass Parallel Processing engine. It integrates directly with the node's Container Network Interface (e.g., Calico, AWS VPC CNI, Flannel) using eBPF (Extended Berkeley Packet Filter) or Open vSwitch (OVS) to transparently intercept pod traffic before forwarding.

Native Kubernetes Metadata Policy Enforcement

Unlike traditional firewalls that enforce rules using static IP addresses, CN-Series is completely Kubernetes metadata-aware:

• In Kubernetes, pod IP addresses are highly ephemeral—pods are created, scaled, rescheduled, and destroyed in seconds, cycling through IP addresses continuously.
• CN-Series security policy rules reference native Kubernetes constructs directly: Namespaces, Pod Labels, and Service Names.
• Example Policy: Allow traffic from Namespace: checkout with Label: app=frontend to Namespace: billing with Label: app=payment-api exclusively for Application: json-rpc while enforcing an inline Threat Prevention Profile. All other cross-namespace pod traffic is denied.

---

Comparison: Cloud NGFW vs. VM-Series vs. CN-Series

Exam Trap Alert: Remember the primary use case differentiator on the exam: if the question asks to protect pod-to-pod traffic within a Kubernetes cluster using container labels and namespaces, the answer is always CN-Series. If the scenario requires a zero-maintenance, fully managed cloud firewall where network teams do not want to manage virtual machines or OS updates, the answer is Cloud NGFW. If the organization requires full PAN-OS feature parity, custom SSL Inbound Decryption, or deployment on VMware ESXi, the answer is VM-Series.