top of page

Capabilities and limitations of Palo Alto Firewall in AWS

In the previous post, we looked at how we can analyze and filter egress traffic via the dedicated central appliance (Palo Alto Firewall). A set of Firewall VMs was deployed behind the AWS Gateway Load Balancer. The Palo Alto Firewall was intended to solve many different problems for the organization. In the process of the firewall configuration, we faced some limitations and had to find solutions for them, which will be described in this post.

Limitation 1. Configuration synchronization

We have two VMs, deployed in different AZ for high availability, traffic will be forwarded to a random VM, so configurations should be identical.

Palo Alto firewalls support high availability with session and configuration synchronization, but unfortunately today (October 2022, PAN-OS 10.2) it has several limitations:

- AWS supports active/passive HA only.

- On AWS, when you deploy the firewall with the Amazon Elastic Load Balancing service, it does not support HA

Solution. Palo Alto Panorama

We need HA + configuration sync due to requirements and common sense. Nobody wants to repeat the same configuration several times in different VMs. Palo Alto provides a solution for this (that has to be bought separately), called Panorama. It can be used for centralized configuration and visibility. The diagram below shows how it is deployed in the "Egress VPC" (other parts will be discussed later).

Here you can find an instruction on how to add a firewall VM to the Panorama-managed devices. The only thing that needs to be kept in mind, is that versions of Panorama and Firewalls OS should be the same. Unfortunately, the Panorama version in the AWS Marketplace is not up to date, so it should be updated separately (October 2022).

Once you finished with managed devices, you can see that VMs are "In Sync":

You can also see some basic health metrics:

Then you can create policies, objects, and other configurations and push them to the relevant device groups:

Limitation 2. Palo Alto GlobalProtect VPN

Another pair of Palo Alto virtual machines are depicted in the above diagram (VPN VPC) because they can not be configured on the same VMs, that is used for Egress traffic filtering. GlobalProtect is used as a VPN solution to get access to private resources. Instances are deployed in the public subnets because they should be accessible for end-users from the internet, a single endpoint should be exposed for users' convenience, and the deployment should be highly available.

Active/Active HA is not available in AWS, so our choice is Active/Passive.

Here you can find an instruction on how to configure Active/Passive HA for Palo Alto VMs in AWS. When the active peer goes down, the passive peer detects the failure and becomes active. Additionally, it triggers API calls to the AWS infrastructure to move all the data-plane interfaces (ENIs) from the failed peer to itself.

We can see that the Config is Synchronized between VMs:

As a result, we need at least 5 Palo Alto VMs in order to have Egress traffic filtering with config synchronization and highly-available GlobalProtect VPN.

Limitation 3. Palo Alto GlobalProtect SSO and group mapping

In the first diagram, you can see that AWS Directory Service is present in the current architecture. First of all, it is used as an identity source for AWS SSO:

A custom application that supports identity federation with SAML 2.0 was created for the GlobalProtect SSO.

So we have everything on the single login page:

One more requirement is that different groups of users must have access only to appropriate private networks, for example, Team1 can access only App1 VPC, while Team2 can access only App2 VPC. The above configuration is not enough for this task.

Palo Alto states that to enable group mapping functionality, you must create an LDAP server profile that instructs the firewall how to connect and authenticate to the directory server and how to search the directory for the user and group information. Then you can define GlobalProtect configurations and/or security policies based ongroup_membership.

Limitation 4. Palo Alto VM monitoring.

Using Palo Alto VMs in production requires detailed monitoring for alerting and scaling purposes and providing appropriate SLA. We have a set of standard EC2 metrics in CloudWatch, but it is not enough. We can install the CloudWatch agent in Linux or Windows instances, but Palo Alto VM has its OS called PAN-OS, where we can not install the CloudWatch agent. Fortunately, the firewall VM has the capability to send some custom metrics to CloudWatch. As usual, we need to provide relevant permissions via IAM Role (Instance profile), for example:

    "Version": "2012-10-17",
    "Statement": [
           "Effect": "Allow",
            "Action": [
            "Resource": [

or managed IAM policy CloudWatchAgentAdminPolicy that also allows writing logs into CloudWatch.

Then you need to reboot the VM, otherwise, it will not start using the IAM role. Enable one checkbox in the Palo Alto WebUI:

Here is a list of available Palo Alto VM metrics.



Dataplane CPU Utilization (%)

Monitors dataplane CPU usage and measures the traffic load on the firewall.

Dataplane Packet Buffer Utilization (%)

Monitors dataplane buffer usage and measures buffer utilization. If you have a sudden burst in traffic, monitoring your buffer utilization allows you to ensure that the firewall d