Skip to content

Palo Alto Networks BYOIP Integration Overview

BYOIP SUPPORTER
ASN -
IPv4 support
IPv6 support
LOA support
ROA support
Process Semi-automatic
Locations supported
Other: India, Japan, France, Germany, Italy, United Kingdom, Canada, United States, Brazil, Australia

This page outlines the technical and procedural information required for integrating Bring Your Own IP (BYOIP) with Palo Alto Networks cloud-delivered security services—primarily Cloud NGFW for AWS using Egress NAT with Bring Your Own IPs (BYOIPs). In this model, you first onboard your public IPv4/IPv6 space into AWS BYOIP, then (for Cloud NGFW egress) you provision and advertise the CIDR through AWS IP Address Manager (IPAM) and share an IPAM pool so Palo Alto Networks’ Cloud NGFW dataplane can use your addresses for source NAT egress. Palo Alto Networks also exposes a “Bring Your Own IP” option for Prisma Access Service Provider Interconnect (SPI) IP pools, allowing BYOIP-based Ingress and Egress IP Pools in supported SPI regions.

Provider Details

FieldInformation
Provider NamePalo Alto Networks
Legal NamePalo Alto Networks, Inc.
CategoryOther (Security / SASE / Managed Firewall Services)
Website Cloud NGFW for AWS: Configure Egress NAT (BYOIPs)  |  Prisma Access SPI: Add IP Pool (Bring Your Own IP)  |  Prisma Access SPI: Supported Regions / Locations  |  AWS EC2 BYOIP Overview (upstream requirement)
BYOIP-Related Product(s) Cloud NGFW for AWS: Egress NAT with Bring Your Own IPs (BYOIPs) via AWS IPAM pool sharing.
Prisma Access (SPI): “Bring Your Own IP” option for Ingress and Egress IP Pool configuration in Service Provider Interconnects.
ASN(s) Cloud NGFW for AWS BYOIP advertisement is performed via AWS (you select an appropriate ASN when advertising the CIDR in AWS). Palo Alto Networks does not document originating your prefix from a Palo Alto Networks ASN for this flow.
Prisma Access SPI: uses your public/private BGP ASN for peering to exchange routes (interconnect connectivity), separate from BYOIP address ownership.
Regions Supported Cloud NGFW for AWS BYOIPs inherit AWS BYOIP regional availability (AWS BYOIP is available in all commercial AWS Regions except China Regions).
Prisma Access SPI supports a defined set of regions/locations depending on cloud provider (AWS or GCP). Representative AWS SPI locations include: US East/West/Central, UK, Ireland, Germany (Central), France (North), Sweden, Singapore, Japan (Central), UAE (see full supported list in the SPI locations reference).
Support Contact Palo Alto Networks Support Portal  |  Knowledge Base  |  Contact / Sales
Tech Article & Date Cloud NGFW for AWS: Configure Egress NAT (Updated Jan 20, 2026).
Prisma Access SPI: Add IP Pool & SPI Locations (Updated Jan 27, 2026).
BYOIP Scope Cloud NGFW for AWS: customer-owned public IP space is onboarded to AWS (BYOIP), then provisioned/advertised in an AWS IPAM pool; the pool is shared so Cloud NGFW can use the resulting public IPs for Egress NAT (source NAT).
Prisma Access SPI: BYOIP option configures Ingress/Egress IP Pools for interconnect deployments (use-case: controlling published ingress/egress IPs per SPI deployment).
Supported Versions Cloud NGFW for AWS BYOIPs: IPAM pool must be created with Address Family = IPv4 (IPv4 egress NAT public IPs). Upstream AWS BYOIP supports IPv4 and IPv6, but this Cloud NGFW BYOIP egress flow is documented as IPv4-based.
Prisma Access SPI: interconnect configuration supports IPv4 single-stack or IPv4+IPv6 dual-stack for some cloud provider configurations; BYOIP IP pool address-family specifics are not exhaustively documented on the “Add IP Pool” page.
Supported Services Cloud NGFW for AWS (Egress NAT with BYOIPs supported for rulestack and Panorama policy management).
Prisma Access (Managed by Strata Cloud Manager) for Service Provider Interconnects (Bring Your Own IP for IP Pools).
BYOIP Automation Level Semi-automatic: you complete AWS IPAM/BYOIP onboarding and pool sharing steps, then Cloud NGFW consumes the shared pool for egress NAT. Releasing addresses back to your pool is documented as a support-assisted action.

Technical Requirements

RequirementDetails
BYOIP Prerequisite Platform AWS BYOIP is the upstream mechanism for bringing publicly routable IPv4/IPv6 space to AWS and advertising it through AWS (the BYOIP range appears as an address pool in your AWS account).
Prefix Size Upstream AWS BYOIP: smallest publicly routable IPv4 range is /24; IPv6 BYOIP supports /48 (publicly advertisable) and /60 for some non-public cases. Cloud NGFW’s Egress NAT BYOIP flow is documented using an AWS IPAM pool with Address Family = IPv4.
ASN Ownership Required Cloud NGFW for AWS BYOIPs: no customer ASN is required for Cloud NGFW to perform egress NAT; your CIDR is advertised via AWS and you select an appropriate ASN when advertising the CIDR in AWS.
Prisma Access SPI: you provide a public or private BGP ASN for peering (route exchange) during interconnect setup.
ROA or LOA ROA: in AWS BYOIP, ROAs are referenced as part of the ecosystem and are not required only for certain non-publicly advertisable cases; for publicly advertised space, plan on maintaining the required RPKI/registry objects per AWS guidance.
LOA: not described in the Palo Alto Networks Cloud NGFW BYOIP flow; ownership is handled through AWS BYOIP control validation.
Ownership Validation AWS validates that you control the IP range using either: (1) RDAP + X.509 certificate validation, or (2) DNS TXT validation via IPAM-based onboarding. In the Cloud NGFW BYOIP flow, you provision a CIDR to an IPAM pool using X.509 certificate input (signature-based workflow).
IRR / Route Objects AWS BYOIP documentation states AWS automatically updates RADb for BYOIP; manual IRR changes that include the BYOIP ASN can cause provisioning failures.
AWS IPAM Pool For Cloud NGFW BYOIPs, you must create an AWS IPAM pool, provision/advertise the CIDR, then share the pool with the Cloud NGFW deployment account. The pool locale should match where you deploy Cloud NGFW.
Cloud NGFW Dataplane Account Allowlist When creating the IPAM pool for BYOIPs, you must whitelist the Cloud NGFW dataplane AWS account ID: 010510656586.

Step-by-Step BYOIP Process

Estimated Setup Time: Creating the required AWS IPAM pool may take ~10 minutes. End-to-end timelines vary based on AWS BYOIP onboarding/registry validation and propagation once advertisement is enabled.

Tested By Us: Not yet

A) Prepare and advertise your BYOIP range in AWS (IPAM + BYOIP prerequisite)

  • Bring your public IP range to AWS (BYOIP) so it appears in your AWS account as an address pool; AWS validates control via RDAP/X.509 or DNS TXT depending on onboarding path.
  • In AWS, create an Amazon VPC IP Address Manager (IPAM). Then create an IPAM pool for BYOIP egress: set Address Family to IPv4 and set Locale to match the region where you will deploy Cloud NGFW for AWS.
  • During IPAM pool creation, whitelist the Palo Alto Networks Cloud NGFW dataplane AWS account ID: 010510656586 (required for pool sharing between the Cloud NGFW dataplane and AWS).
  • Provision your public IPv4 CIDR to the new pool (Planning → Pools → CIDRs → Actions → Provision CIDR). Use the option to input a CIDR with an X.509 certificate/signature and complete the provisioning flow.
  • Advertise the CIDR (Actions → Advertise). By default CIDRs are not advertised. When advertising, select the appropriate ASN in the AWS ‘Advertise CIDR’ dialog and publish the route so the CIDR is publicly reachable.
  • Share the IPAM pool with your Cloud NGFW deployment account (Resource sharing tab → Create resource share → grant principals). Confirm the pool and its associated resources are shared successfully.

B) Enable Cloud NGFW for AWS Egress NAT and attach your BYOIPs (IPAM Pool ID)

  • In the Cloud NGFW console, create a new NGFW resource. (Egress NAT is not supported on some older existing firewalls created before the relevant release; create a new firewall resource if needed.)
  • Select policy management mode supported for Egress NAT (rulestack or Panorama). Enable Egress NAT for the NGFW resource.
  • In the Public IPs section, select Bring Your Public IPs and enter the AWS IPAM Pool ID that contains your provisioned/advertised BYOIP CIDRs.
  • After creation, verify firewall status and review the Public IPs tab to confirm the Cloud NGFW resource is using the expected BYOIP addresses for source NAT egress.

C) Releasing BYOIP addresses back to your IPAM pool (support-assisted)

  • If you choose not to use BYOIPs and need to release addresses back to your AWS IPAM pool, Palo Alto Networks documents this as a support-assisted action: open a Palo Alto Networks support case to release the addresses back to your pool.

D) (Optional) Prisma Access Service Provider Interconnect (SPI): enable “Bring Your Own IP” for IP Pools

  • When configuring a shared interconnect (or later via Add IP Pool), choose the IP Pool Type: either Prisma Access IP (provider-assigned) or Bring Your Own IP to configure Ingress and Egress IP Pools.
  • Select supported compute region/location for your SPI instance (supported lists differ by cloud provider such as AWS or GCP).

References: Cloud NGFW for AWS: Configure Egress NAT, AWS EC2 BYOIP, AWS VPC IPAM Overview, Prisma Access SPI: Add IP Pool, Prisma Access SPI: Locations.

Cost and Limitations

ItemDetails
Fees With Cloud NGFW Egress NAT, you avoid AWS NAT Gateway costs; Palo Alto Networks documents that you pay Palo Alto Networks for egress traffic data transfer. If you use Palo Alto Networks-managed AWS Elastic IPs instead of BYOIPs, you incur hourly EIP management costs. Using BYOIPs is positioned to avoid hourly EIP management costs.
Bundled or Standalone BYOIPs are not a standalone SKU; they are part of the Egress NAT configuration path for Cloud NGFW for AWS (requires Cloud NGFW subscription and AWS account). Prisma Access SPI “Bring Your Own IP” is part of SPI IP Pool configuration.
Operational Limitations Egress NAT policy management constraint: Egress NAT with BYOIPs is supported for rulestack and Panorama policy management (not documented for all management modes).
IP pool lifecycle constraint: When adding new CIDRs for Egress NAT, do not add them to an existing IP pool already in use by a Cloud NGFW resource; create a new IP pool and associate it with the firewall.
Regional constraint (AWS BYOIP): you bring each address range to one AWS Region at a time and AWS enforces per-region quotas.
Release / Rollback Releasing BYOIP addresses back to your AWS IPAM pool is documented as a support-assisted operation (open a support case).

Automation & Developer Access

  • AWS-side automation: AWS VPC IPAM is designed to help you plan/track/monitor IP space and supports automated workflows for IP management; AWS also provides programmatic interfaces for many IPAM/BYOIP operations (see AWS documentation).
  • Cloud NGFW binding: The Cloud NGFW BYOIP egress configuration is completed by entering the AWS IPAM Pool ID (“Bring Your Public IPs”) during firewall creation in the Cloud NGFW console.
  • Lifecycle note: Releasing BYOIP addresses back to your IPAM pool is documented as a support case workflow rather than self-service automation.

Abuse & Reputation Management

  • AWS BYOIP prerequisite includes IP reputation checks: AWS may investigate the reputation of the IP range and can reject a range if it includes IPs with poor reputation or associated with malicious behavior.
  • Customer responsibility: Even when using BYOIPs for egress, you remain responsible for maintaining good sending/traffic hygiene and handling blacklist monitoring and delisting for your IPs where applicable.

Palo Alto Networks Homepage
Cloud NGFW for AWS: Configure Egress NAT (BYOIPs)
Support Portal
AWS EC2 BYOIP
AWS VPC IPAM Overview
Prisma Access SPI: Add IP Pool
Prisma Access SPI: Supported Regions / Locations

FAQ

BYOIP, or Bring Your Own IP, is a service that enables organizations to bring their own public IP addresses—whether owned outright or leased from an IP provider—into a service provider’s network infrastructure. Instead of relying on IP addresses assigned by the provider, BYOIP allows businesses to retain control over their IP resources. This ensures continuity, particularly for organizations with established IP-based reputations, branding, or dependencies on specific address blocks. IP providers can assist in streamlining this process, making it easy to integrate your IPs into the desired network environment.

BYOIP offers several compelling advantages. By using your own IPs, you can maintain continuity in your network’s identity, reduce the risk of disruptions to email deliverability or service recognition, and avoid reputational concerns associated with shared IPs. Additionally, BYOIP provides enhanced flexibility and control over your IP resources.

BYOIP is ideal for organizations that either own public IP addresses or lease them from a trusted IP provider with explicit BYOIP support. This includes enterprises, cloud providers, content delivery networks (CDNs), and businesses with compliance requirements or IP reputation needs. Working with a reputable IP provider ensures that leased IPs can be seamlessly integrated into another provider’s infrastructure without ownership concerns.

You must either legally own the IP addresses or have explicit authorization from a leasing IP provider to route and manage them. IP providers who offer BYOIP-ready IP addresses simplify this process, providing documentation and support to ensure compliance with regional internet registry (RIR) policies and service provider requirements. This collaboration ensures smooth implementation without any legal or operational issues.

To use BYOIP, you’ll typically need to present documentation verifying your authority over the IP block. This can include official records from a regional internet registry (RIR) such as ARIN, RIPE NCC, or APNIC. If you are leasing IPs, the IP provider should supply proof of their ownership and grant you permission for BYOIP. Providers that specialize in IP leasing often handle this paperwork for you, reducing administrative burden and ensuring compliance.

Yes, BYOIP is designed to be a secure and reliable solution. Reputable service providers and IP providers implement robust safeguards to prevent unauthorized use or hijacking of IP addresses. Security measures include BGP filtering, route validation, and advanced protocols like Resource Public Key Infrastructure (RPKI). By collaborating with a trusted IP provider, businesses can benefit from additional layers of protection, ensuring that only authorized traffic is routed through their IP blocks.

The setup process for BYOIP varies by provider, typically taking anywhere from a few hours to a few days. Factors include the complexity of your network, the verification process for IP ownership or authorization, and the time needed for global BGP route propagation. IP providers often expedite the preparation and validation stages, ensuring a smooth and timely integration into the desired infrastructure.

Absolutely. Many providers, in partnership with IP providers, support routing IPs across multiple data centers or geographic regions. This feature optimizes performance for global businesses by reducing latency and improving service availability. When working with an IP provider, you can also ensure that your leased or owned IPs are aligned with your geographic requirements for compliance and efficiency.

If you choose to discontinue BYOIP with a provider, your IP addresses will be released from their network, and routing will cease. You can then reallocate these IPs for use with a different service provider or project.