>
    Strata Copilot
    Platform-Specific Reference
    Focus
    Download PDF
    Focus
    1. Home
    2. Prisma AIRS
    3. AI Runtime Security
    4. AI Runtime Security VM Firewall
    5. Dynamic Autoscaling for Non-Mesh Firewalls
    6. Platform-Specific Reference
    Download PDF
    Prisma AIRS

    Platform-Specific Reference

    Table of Contents

    Platform-Specific Reference

    Cloud-specific scaling mechanisms, monitoring resources, behavior details, and best practices for dynamic autoscaling of non-mesh Prisma AIRS firewalls on AWS, Azure, and GCP.
    Where Can I Use This?What Do I Need?
    • Prisma AIRS
    • AWS
    • Azure
    • GCP
    • Prisma AIRS license
    • Access to Strata Cloud Manager
    AWS (Auto-Deploy)
    PropertyDetail
    Scaling MechanismAuto Scaling Group (ASG) via Target Tracking Policy in Terraform
    Monitoring & MetricsCloudWatch — a unique namespace is created per deployment, named after the firewall alias. A high alarm (scale-out trigger) and an auto-computed low alarm (scale-in trigger) are created for each configured metric.
    Scale-Out BehaviorComputes required capacity in one step (e.g., 2 → 4 instances simultaneously). AWS does not scale incrementally — it uses Target Tracking Policy to calculate exactly how many instances are needed and provisions them all at once. This behavior is not configurable from the Strata Cloud Manager UI.
    Scale-In Behavior
    Scale-in threshold is auto-computed. Requires the metric to remain below the threshold for 15 consecutive data points within 15 minutes before triggering scale-in. Scale-out checks only 3 data points, making scale-in intentionally more conservative.
    For AWS, you can only configure the scale-out (target). Scale-in threshold is managed automatically by AWS target-tracking.
    Scale-Out CooldownAWS target-tracking policy defaults apply automatically.
    Scale-In CooldownAWS target-tracking policy defaults apply automatically.
    DecommissioningDecommissioning terminates and wipes off all security infrastructure (firewalls, Auto Scaling Group, security VPCs, subnets, etc.). CloudWatch metrics expire based on retention schedules. Once data publishing stops, metrics drop out of the console list after 14 days of inactivity and are completely removed after 15 months.
    Azure (Auto-Deploy)
    PropertyDetail
    Scaling MechanismVirtual Machine Scale Sets (VMSS) via Terraform
    Monitoring & MetricsApplication Insights — one dedicated resource per deployment, named [alias]-common-vmss-ai, aggregates custom firewall metrics.
    Scale-Out BehaviorIncreases one instance at a time. Scale-out threshold is user-configured.
    Scale-In BehaviorThe scale-in threshold is controlled by Terraform and automatically set to 20% of the scale-out threshold, with a minimum value of 20 (For example: scale-out 200 → scale-in 40; scale-out 80 → scale-in 20).
    Scale-Out Cooldown30 minutes (product default, configured in generated Terraform). Can be adjusted via Azure Portal or Terraform — not via Strata Cloud Manager UI.
    Scale-In Cooldown1 hour (product default, configured in generated Terraform). After one instance is terminated, the next scale-in can occur no sooner than 1 hour later. Can be adjusted via Azure Portal or Terraform — not via Strata Cloud Manager UI.
    DecommissioningAll VMSS, scaling rules, Application Insights resources, and auto-created management subfolders are automatically deleted.
    GCP (Auto-Deploy and Manual)
    PropertyDetail
    Scaling MechanismManaged Instance Groups (MIG) via Cloud Monitoring metrics. MIG is named [alias]-firewall-autoscale-common.
    Monitoring & MetricsGoogle Cloud Monitoring — metrics are emitted by each firewall instance and aggregated across the group.
    Scale-Out BehaviorThe autoscaler adds instances to maintain average group metrics at or below the configured target utilization. Depending on traffic load, it may provision multiple instances simultaneously. Metrics from newly created instances are ignored during their initial 8-minute boot phase.
    Scale-In BehaviorAverage load must remain below the target for approximately 10 minutes (GCP autoscaler stabilization period) before scale-in triggers. Once triggered, scale-in controls defined in the generated Terraform limit removal to a maximum of 1 instance per rolling 30-minute window
    Scale-Out CooldownNew instances undergo an 8-minute initialization period (cooldown_period = 480s in Terraform), during which their metrics are excluded from autoscaling calculations.
    Scale-In CooldownRestricted to removing at most 1 instance per rolling 30-minute window via Terraform scale-in controls. This setting is managed via Terraform and is not configurable on Strata Cloud Manager UI.
    DecommissioningAutomated removal wipes off all security infrastructure (firewalls, MIG, security VPCs - trust, untrust, management). Manual: Run terraform destroy from your GCP security project environment to remove all security infrastructure (firewalls, MIG, security VPCs).

    Best practices for autoscaling-enabled manual deployments

    Deployments that belong to different clouds must have separate cloud-wise folders:
    You must have a separate folder per manual deployment to prevent folder configurations belonging to previous deployments (namespace/instrumentation key, update interval, etc.) from getting overridden by new deployment configuration. It is not recommended to have multiple deployments within the same folder for a cloud type. However, if a user still wants to do so, they will observe that the POST autoscale API config/device/v1/autoscale fails with an error: “Object already exists” on the configuration review page because the previous configuration is already applied to the folder.
    Error Details:
    {
    "_errors": [
        {
            "code": "PRISMA_ACCESS_API_I00013",
            "message": "Object already exists - /config/devices/entry[@name='localhost.localdomain']/container/entry[@name='username_manual']/devices/entry[@name='localhost.localdomain']/deviceconfig/virtualization",
            "details": null
        }
    ],
    "_request_id": "9159994e-750e-4eb7-b456-7a7e040a2aff"
}
    Following are the steps to override the folder configuration:
    In your Strata Cloud Manager console go to ConfigurationNGFW & Prisma AccessSelect the folder in the configuration scope (the one you want to override)Network & devicesDevice Setup.
    1. Edit the configuration in the VM-Series plugin section.
    2. Update the settings.
    3. Perform a folder push to apply your updated settings to the folder.
      Previous deployments in the same folder will also be overridden with the latest configuration, so we recommend maintaining a separate, unique folder per deployment.
    Here is an example of unique folder per cloud and per deployment:

    © 2026 Palo Alto Networks, Inc. All rights reserved.