Skip to content
BYOIP

Google Cloud BYOIP Integration Overview

BYOIP SUPPORTER
ASN 396982
IPv4 support
IPv6 support
LOA support
ROA support
Process Semi-automatic
Locations supported
Other: South Africa, China, India, Indonesia, Israel, Japan, Qatar, Saudi Arabia, Singapore, South Korea, Belgium, Finland, Germany, Italy, Netherlands, Poland, Spain, Switzerland, United Kingdom, Canada, United States, Brazil, Chile, Australia

Location

This page outlines the technical and procedural information required for integrating Bring Your Own IP (BYOIP) with Google Cloud infrastructure. Page provides step-by-step onboarding flow (PAP → PDP → sub-prefix → addresses → attach), CLI-focused deprovisioning, troubleshooting, and operational best practices.

Searching for the best IP providers? Google Cloud delivers robust BYOIP automation, flexible routing, and global reach. Below you’ll find setup docs, requirements, flows, and best practices for streamlining your BYOIP configuration.

Provider Details

FieldInformation
Provider NameGoogle Cloud
WebsiteGoogle Cloud
ASN(s)396982
Regions SupportedAll global regions. IPv6 BYOIP is regional only.
Support ContactVia Google Cloud Console
Google’s Tech Article Bring your own IP addresses, Last updated:  2025-12-02
BYOIP ScopeGlobal for IPv4; regional for IPv6
Supported VersionsIPv4 and IPv6 (limited services)
Supported ServicesVMs, Load Balancers, VPN, Global Load Balancing, Cloud NAT, Cloud CDN

Technical Requirements

Category Requirements
Ownership & Routing Demonstrable control of the IP prefix; valid RPKI ROA authorizing Google ASN 15169; ability to configure reverse DNS (rDNS) for Google verification token publication; LOA where applicable.
APIs & Quotas Compute Engine API enabled; project quotas for external IPs, forwarding rules, and compute/network resources must be sufficient for deployment scale.
Access Control Project Owner or IAM role with permissions to create and manage Public Advertised Prefixes (PAP), Public Delegated Prefixes (PDP), delegated sub-prefixes, and static external addresses.
Entity Model PAP (global BYOIP container) → PDP (regional or global delegated range) → delegated sub-prefixes (e.g., /28) → materialized static IP addresses → attached to VM NICs, load balancers, or services.
IPv6 Support IPv6 BYOIP supported only in regional mode; feature coverage is more limited than IPv4. Validate service compatibility before planning BYOIP IPv6 deployments.

Step-by-Step BYOIP Process

Estimated Setup Time: Varies by provisioning and prefix validation

Tested By Us: Confirmed.

Tests were done: 2025-11

BYOIP Onboarding Flow (Phases I–III)

Phase I — Preparation
  • Enable APIs: Enable Compute Engine API if not already enabled.
  • Confirm ROA visibility: Ensure your ROA is published and visible via public RPKI portals.
  • Reverse DNS / Validation: Prepare to add a PTR or TXT token for PAP validation if requested by Google.
Phase II — Configuration
  • Create PAP (global): VPC Network → Bring your own IP → Create public advertised prefix. Provide the exact prefix and complete validation steps (ROA and reverse-DNS token as instructed by Google).
  • Create PDP (regional): From the PAP, create one or more PDPs in the regions you plan to use.
  • Create a sub-prefix (e.g., /28) and materialize IPs: Under the PDP, create a sub-prefix and optionally auto-create static addresses.
  • Announce PDP, then PAP: At least one PDP must be announced before the PAP can be announced to the public Internet. Expect several minutes for PDP to become usable and ~10–60 minutes for PAP advertisements to propagate broadly.

Note on placeholders: The CLI examples below use generic placeholders. Replace <YOUR_DELEGATED_RANGE> with the actual sub-prefix you are delegating (for example, a /28), <PDP_NAME> with the name of your Public Delegated Prefix, and <BYOIP_ADDRESS_NAME> with the static Address object derived from your prefix. All placeholder values must correspond to resources created in your own Google Cloud project.

CLI — Create delegated sub-prefix and (optionally) materialize addresses
# Create a /28 under the PDP
# Replace placeholders with your own BYOIP details.
gcloud compute public-delegated-prefixes delegated-sub-prefixes create sub-EXAMPLE-16-28-en1 \
  --range=<YOUR_DELEGATED_RANGE> \
  --public-delegated-prefix=<PDP_NAME> \
  --public-delegated-prefix-region=europe-north1 \
  --delegatee-project=$(gcloud config get-value project)
# Optionally, auto-create static Address objects for all IPs in that /28
gcloud compute public-delegated-prefixes delegated-sub-prefixes create addrs-EXAMPLE-16-28-en1 \
  --create-addresses \
  --public-delegated-prefix=<PDP_NAME> \
  --public-delegated-prefix-region=europe-north1
CLI — Check BYOIP version and announce PDP
# Verify your BYOIP API version (v2 expected)
gcloud compute public-delegated-prefixes describe PDP_NAME \
  --region=PDP_REGION | grep byoipApiVersion
# Announce the PDP (required before PAP can be announced)
gcloud compute public-delegated-prefixes update PDP_NAME \
  --region=PDP_REGION \
  --announce-prefix
Phase III — Attach addresses to resources

After announcement, materialized BYOIP addresses behave like regular external static IPs. You can reserve/label specific addresses and assign them to VMs, load balancers, or other services.

# Confirm active project
gcloud config get-value project
# Open HTTP from the Internet (demo only)
gcloud compute firewall-rules create allow-http \
  --network=default --direction=INGRESS --priority=1000 \
  --action=ALLOW --rules=tcp:80 --source-ranges=0.0.0.0/0 \
  --target-tags=web
# Create a tiny VM and assign a BYOIP static address resource
# Replace <BYOIP_ADDRESS_NAME> with the name of your Address object.
gcloud compute instances create web-min \
  --zone=europe-north1-b \
  --machine-type=e2-micro \
  --tags=web \
  --address=<BYOIP_ADDRESS_NAME>
# Verify the VM's external IP (should match the BYOIP address)
gcloud compute instances describe web-min \
  --zone=europe-north1-b \
  --format='table(name,networkInterfaces[0].accessConfigs[0].natIP)'

BYOIP Deprovisioning (Phase IV)

Deprovisioning should reverse the onboarding lifecycle carefully to avoid orphaned resources and the common error: “Addresses in a reserved external IP range cannot be deleted individually.” Prefer the CLI for predictable ordering and explicit feedback. Order of operations matters:

  • 1. Detach & remove workload dependencies: Remove BYOIP IPs from VMs, load balancers, Cloud NAT, etc.
  • 2. Release materialized addresses associated with the sub-prefix(es).
  • 3. Withdraw announcements: Withdraw PDP announcements first; when all PDPs are withdrawn, withdraw the PAP.
  • 4. Delete sub-prefixes under each PDP.
  • 5. Delete the PDP(s) (must be not announced, with no children and no addresses).
  • 6. Delete the PAP (not announced and no attached PDPs).
  • 7. Validate cleanup: BYOIP dashboard empty; VPC → IP addresses contain no objects from the prefix; optional external checks (BGP/RPKI).
CLI — Helpful inspection & cleanup commands
# Inspect address objects using a specific BYOIP IP
gcloud compute addresses list \
  --filter='address=("YOUR_IP")' \
  --regions=YOUR_REGION \
  --format='table(name,address,status,in_use_by)'
# Check regional/global forwarding rules that reference the IP
gcloud compute forwarding-rules list \
  --regions=YOUR_REGION \
  --filter='IPAddress="YOUR_IP"' \
  --format='table(name,IPAddress,loadBalancingScheme,region)'
gcloud compute forwarding-rules list --global \
  --filter='IPAddress="YOUR_IP"' \
  --format='table(name,IPAddress,loadBalancingScheme)'
# Detach a BYOIP IP from a VM (remove external access config)
gcloud compute instances delete-access-config VM_NAME \
  --zone=YOUR_ZONE \
  --access-config-name="External NAT"
# Re-check that the VM has no external IP
gcloud compute instances describe VM_NAME \
  --zone=YOUR_ZONE \
  --format='table(name,networkInterfaces[0].accessConfigs[0].natIP)'
# (Withdraw PDP/PAP announcements using Console or CLI as per docs)
# Then delete sub-prefixes, delete PDP(s), and delete the PAP.

Troubleshooting & Gotchas

  • “Cannot delete address individually”: A PDP or sub-prefix is still announced or in use. Withdraw announcements and ensure all static addresses and sub-prefixes are removed before deleting the PDP, then the PAP.
  • PAP not PREFIX_CONFIGURATION_COMPLETE: Validation is incomplete (ROA not visible yet or reverse-DNS token not in place). Complete validation, then announce.
  • No reachability after assigning address: Ensure PDP is announced in the region of use and (when Internet reachability is required) the PAP is announced.
  • Propagation time: PDP announcements are usually ready in minutes inside Google; public PAP ads can take 10–60 minutes to become visible across looking glasses.
  • IPv6 constraints: IPv6 BYOIP is regional and not supported by all services. Validate service support before committing to IPv6 BYOIP.
  • Validation token placement: If Google asks for a reverse-DNS token, place it exactly as instructed (PTR/TXT) for the prefix, then re-run validation.
  • Labels & documentation: Label address objects and record which workloads use which IPs to simplify deprovisioning later.

Cost and Limitations

ItemDetails
FeesNo extra BYOIP charge; standard Google Cloud rates apply for resources used.
Bundled or StandaloneIntegrated with VPC networking services.
Traffic/Peering RestrictionsClean reputation required; poor or abusive IPs may be rejected.
Other LimitationsIPv6 BYOIP is regional-only; not all services support BYOIP.

Automation & Developer Access

  • API Access: Full control via gcloud CLI and REST.
  • Terraform / SDKs: Many operations are supported; some steps are easier and more reliable via CLI.

Abuse & Reputation Management

  • IP reputation monitoring: Use third-party tools and RBLs to monitor cleanliness.
  • Blacklist removal: Responsibility of the user/holder of the prefix; keep evidence and remediation logs.

Additional Notes

  • Before terminating your Google Cloud account (tenant), ensure all services using BYOIP addresses are manually cancelled and addresses detached.
  • After cancellation, confirm that your IP prefix is no longer advertised via public BGP and that PDP announcements are fully withdrawn.
  • If the prefix remains advertised after termination, it may continue to persist on the Internet without your control.
  • Only Google Cloud Support can withdraw these announcements post-termination; without an active account, this can take weeks or months.

Google Cloud BYOIP Overview
Create a Public Advertised Prefix (PAP)
Create a Public Delegated Prefix (PDP)
Google Cloud CLI (gcloud)
IPXO – Prepare your leased subnet for GCP BYOIP

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.