Bring Leased IPv4 to Google Cloud: BYOIP Guide

The invoice arrives on the third of the month, and someone finally reads the networking line item.

It is a familiar story. A team migrates a few hundred workloads to Google Cloud, everything runs beautifully, and nobody thinks about IP addresses until the finance lead circles a number and asks what it is for. The answer is uncomfortable: the company is renting public IPv4 addresses from Google by the hour, on top of the compute those addresses are attached to. And it is paying that rent forever, because the addresses are Google's, not the company's.

There is a second version of the same story that ends differently. In that version, the team already has a /24 - owned or leased from an IP holder - and brings it into Google Cloud. The addresses keep their reputation, their whitelisting history, their reverse DNS. The hourly external IP charge disappears. The only cost left is the lease itself, which is a predictable line item the company controls.

The mechanism for the second version is called GCP BYOIP, and this guide walks through it end to end: what it costs, how the two-level prefix model works, what Google actually verifies, how long provisioning takes, and what changes when the IP block is leased rather than owned.

GCP external IP pricing in 2026: what you are actually paying

Before the migration mechanics, it helps to see the number the migration is meant to remove. Google's current external IP address pricing looks like this:

Two details in that table surprise most people.

The first is that an idle address costs twice as much as a working one. Google raised in-use VM address pricing in February 2024 (from $0.004 to $0.005 for standard VMs, and from $0.002 to $0.0025 for Spot) but left the unassigned static rate at $0.01. So a reserved address doing nothing bills at $7.30 a month, while the same address attached to a running VM bills at $3.65. Teams that reserve address pools "for later" pay a premium for the privilege.

The second detail matters for anyone whose traffic goes through a load balancer: addresses attached to forwarding rules are already free. If your entire estate sits behind external load balancers, external IP pricing is not your problem and BYOIP will not save you money on that line. BYOIP saves money where addresses attach to VMs and to Cloud NAT gateways.

Scaled up, a full /24 - 256 addresses - looks like this if every address is in use on standard VMs:

256 × $0.005 × 730 = $934.40 per month, or $11,212 per year.

On Spot instances the same block costs $467.20 a month. Reserved and unused, it costs $1,868.80 a month. Those are ceiling figures; real deployments mix states. But they establish the scale of what is on the table.

Against all of that, Google's own documentation states the BYOIP position in one sentence: there are no charges for idle or in-use IP addresses. Once your prefix is imported, addresses drawn from it are free in every state - assigned, unassigned, on a standard VM, on a Spot VM, behind Cloud NAT.

How GCP BYOIP works: two prefixes, not one

The single most common source of confusion with google cloud byoip is that there are two different prefix objects, and they do different jobs. Understanding the split makes the rest of the process straightforward.

The public advertised prefix (PAP) is the block Google announces to the internet on your behalf. It is a single unit of route advertisement. This is the object your ROA and your reverse DNS validation attach to, and it is the object that takes weeks to provision. For IPv4 on Premium Tier, a PAP can be anywhere from a /16 to a /24 - so a /24 is the smallest block you can bring, exactly as with every other cloud BYOIP programme, because /24 is the smallest prefix the global routing table reliably accepts.

The public delegated prefix (PDP) is a slice of that PAP assigned to one specific project and one specific scope - a single region, or global. This is where the addresses become usable. A top-level PDP can be /16 to /28 for the recommended v2 regional configuration, and it can be the same size as its parent PAP or smaller. You can then break a PDP into sub-prefixes down to a minimum of /28, and those sub-prefixes can be delegated out to different projects across your organisation. Sub-delegation is allowed up to three times from a single PAP.

The practical value of the split is that the slow, registry-facing part of the process happens once at the PAP level, while the fast, organisation-facing part happens repeatedly at the PDP level. A /24 brought in as one PAP can be carved into sixteen /28 subnets, spread across sixteen projects and regions, without touching BGP again.

One hard constraint governs everything else: Google does not support overlapping BYOIP announcements. If a prefix - or any part of it - is being advertised anywhere outside Google, Google must not advertise it at the same time. Doing both produces unpredictable routing and packet loss. This single rule shapes the entire cutover strategy, and it is the reason the timeline below is sequenced the way it is.

There is also a newer capability worth knowing about. For v2 IPv4 delegated prefixes and sub-prefixes created after 13 December 2025, Google enabled enhanced IP address allocation, which lets you create individual addresses out of a delegated prefix. Older prefixes could only produce address groups sized /17 to /28, which meant a minimum of sixteen addresses at a time. If you are provisioning today, you get the granular behaviour.

Requirements: what Google checks before it will route your block

Google validates ownership with two artefacts. Both must be in place before provisioning starts, and both are the most common cause of delay when they are not.

1. A Route Origin Authorization (ROA) naming Google's ASN. You create this at your RIR - RIPE NCC, ARIN, APNIC, LACNIC or AFRINIC. The ROA must cover the exact prefix and prefix length of your PAP, and it must authorise the correct Google ASN for your chosen network tier:

• Premium Tier (the default): AS 396982

• Standard Tier (Preview): AS 19527, either as separate ROAs for the PAP and each top-level PDP, or as a single ROA with maxLength /24

Google also recommends creating a second ROA for the same prefix with your own ASN as origin. It costs nothing and it means that if you ever need to announce the block yourself again, RPKI-validating networks will not drop your route as invalid.

Note that the ROA must remain in place for a period after you delete the PAP - it is not something to revoke the moment you finish a migration.

2. A reverse DNS PTR record. When you create the PAP, you nominate one unused address from the block as a verification address. Google returns a generated hostname string (exposed as sharedSecret in the API). You then publish a PTR record for that address pointing at that string within the DNS zone used for your block, and tell Google to validate it. The status moves to VALIDATED on success, or REVERSE_DNS_LOOKUP_FAILED if the lookup does not resolve.

This second requirement is the one that catches leased blocks, and it is covered in its own section below.

Two more prerequisites are organisational rather than technical. Someone needs the Compute Public IP Admin role (roles/compute.publicIpAdmin), and Google recommends isolating prefix administration in a dedicated project rather than mixing it with the projects that consume the addresses. If you use Shared VPC, addresses can be created in the host project and used by service projects, but not created in a service project.

Also worth confirming before you commit: not every resource accepts BYOIP addresses. GKE nodes and Pods do not. Cloud VPN gateway external addresses, Classic or HA, do not - though a BYOIP address can serve as the peer address of a Classic VPN tunnel. And managed instance groups that allocate addresses automatically do not, though stateful MIGs with static addresses assigned at VM creation do. Check your architecture against Google's supported-resources list before the lease is signed.

IPv4 Pricing Calculator

See exactly what you pay. No hidden fees or markup.

Open calculator

Step by step: the gcloud BYOIP workflow

The gcloud byoip commands live under gcloud compute public-advertised-prefixes and gcloud compute public-delegated-prefixes. The full sequence:

Step 1 - Create the ROA at your RIR. Do this first and do it early. RIR processing is outside Google's control and outside your control.

Step 2 - Create the public advertised prefix. For the recommended v2 regional configuration:

Names cannot be changed later without deleting and recreating the resource, so use a generic, durable convention like pap-203-0-113-0-24.

Step 3 - Retrieve the validation hostname and publish the PTR record.

Publish the PTR, then trigger validation:

Step 4 - Wait for provisioning, and use the wait productively. While the PAP provisions, create your public delegated prefixes and sub-prefixes. For v2 these take minutes, not weeks, and they can be created before the parent finishes provisioning.

Step 5 - Create addresses and attach them to resources. Addresses drawn from a PDP work only within the project and scope they were delegated to. Note that every address in the block is usable - there is no reserved subnet address or broadcast address, so a /28 yields sixteen usable addresses, not fourteen.

Step 6 - Announce. With v2 prefixes, nothing is announced automatically. You announce a PDP first, then the parent PAP:

Timeline: what to expect

Google's documentation gives provisioning times but does not explain what fills the calendar. Here is the realistic shape of it:

One warning if you check the documentation yourself: the status-check page still quotes a flat four weeks, a figure that predates the v2 configuration. The comparison table on the same documentation set is the current one. Plan for two weeks on v2, but do not be surprised if Google's own interface quotes you the older number.

The headline number, then, is two to four weeks - and the variable that decides which end you land on is which configuration you choose. The v2 regional configuration provisions in roughly two weeks. The older v1 configuration and the global configuration take roughly four, and global additionally requires your project to be added to an allowlist through a support case, which is more calendar time before the clock even starts.

Deprovisioning is slower still, and this catches people out. Moving a delegated prefix from one region to another requires deleting and recreating it, which Google estimates at approximately eight weeks. Decide where your addresses need to live before you provision, not after.

The two ways teams get stuck are both avoidable. The first is starting the ROA at the RIR after creating the PAP, which adds days at the front. The second is discovering during validation that nobody controls reverse DNS for the block - which adds however long it takes to arrange delegation.

The cutover: moving traffic without renumbering

This is where the v2 configuration earns its place, and it is worth understanding precisely, because the internet does not let you advertise the same block from two places at once.

With a v2 public advertised prefix, provisioning and announcing are separate events. Google completes all the internal configuration for your block and then waits. Nothing is advertised until you issue the announce command. That gives you a staging window: your addresses exist inside Google Cloud, attached to real VMs and real load balancers, fully configured and testable - while your current provider is still announcing the block and still carrying live traffic.

The cutover itself is then a coordinated pair of actions rather than a renumbering project:

1. Build and validate everything in Google Cloud, prefix unannounced.

2. Withdraw the announcement from your existing network or upstream.

3. Announce the PDP, then the PAP, in Google Cloud.

Traffic follows the routing table. Application configuration, DNS records, firewall allowlists and partner integrations that reference your addresses never change, because the addresses never change. Convergence across the global routing table is a matter of minutes, and it can be planned into a maintenance window instead of a migration quarter. The same staged approach applies whether you are moving into a cloud or between networks - our guide to migrating to leased IPv4 without downtime covers the DNS and TTL side of the same operation.

A finer point that is useful for phased migrations: you can announce a public delegated prefix inside Google Cloud without announcing the parent public advertised prefix to the internet. That lets you bring a slice into service internally while the block as a whole is still being advertised elsewhere.

One caution about older material you may find online. Google's 2019 Bitly case study is still widely cited for its BYOIP cutover approach, but Google has since added an editor's note to that post stating the cutover method it describes is no longer supported. Work from the current documentation.

If your /24 is leased, not owned

Everything above assumes you can act as the holder of the IP block. When you lease rather than own, a few of those steps belong to someone else, and the lease has to be written accordingly.

The ROA is created by the registered holder, not by you. RPKI signing authority sits with whoever holds the resource at the RIR. Your lessor must be willing and able to create a ROA authorising Google's ASN for your prefix, and to keep it in place for the full term plus the deprovisioning tail. An IP owner who does not offer this cannot support a cloud BYOIP deployment, whatever the listing says.

Reverse DNS must be delegated to you. Google's validation requires a PTR record in the DNS zone for the block. Either the lessor delegates the reverse zone to your nameservers, or they agree to publish the specific validation record on request. Confirm which before signing, and confirm the turnaround time - a lessor who takes three weeks to publish a PTR record has added three weeks to your migration.

The lease term must cover the whole lifecycle. Two to four weeks to provision, the operational life of the deployment, and up to eight weeks if addresses ever need to move regions. A twelve-month lease on a block you spend a month provisioning is really an eleven-month lease.

Exclusivity and announcement rights need to be explicit. Because Google cannot advertise a block that is being advertised elsewhere, the lease must guarantee that no other party announces your prefix for the duration. Sub-leased or shared blocks are incompatible with BYOIP.

Registry records should be clean and consistent. Google verifies ownership through ROA and reverse DNS, not through RDAP or whois. But your peers, your customers' security teams and the abuse-database operators all read RDAP - so accurate, current records remain a practical requirement even though they are not a formal Google gate.

At IPbnb we structure lease agreements around exactly these requirements, because a leased block that cannot pass cloud verification is not really a usable block. If you are evaluating IP renters or IP owners for a cloud migration, treat ROA support, reverse DNS delegation and announcement exclusivity as pass/fail criteria rather than nice-to-haves.

Cost math: a leased /24 on GCP

Put the numbers side by side for a /24 fully deployed on standard VMs:

The comparison that matters is the last two rows against the first: the Google external IP charge goes to zero, and it is replaced by a lease that costs under a tenth of it. On a fully utilised /24 the saving is roughly $10,100 to $10,300 a year - and the block comes with an established reputation and a clean history, which no freshly assigned cloud address has.

For context, wider market lease rates in the RIPE and ARIN regions run $0.38 to $0.50 per IP per month, and above $0.60 in the supply-constrained APNIC region. Rates also move with block reputation: clean blocks command a premium, and blocks with blocklist history trade at a discount of around 40%. Cheap addresses are cheap for a reason, and on a migration where partner allowlists are the whole point, reputation is not the place to economise.

Three honest caveats on the math. Addresses behind forwarding rules were already free, so a load-balancer-heavy estate saves less. The savings scale with utilisation, so a /24 that is half empty saves roughly half as much. And the provisioning weeks are real engineering time that belongs in the business case.

Run your own figures against your actual address count and utilisation with the IPv4 price calculator before committing.

FAQ

Does Google Cloud charge for BYOIP addresses?

No. Google's documentation is explicit: there are no charges for idle or in-use BYOIP IP addresses. Once your prefix is imported, addresses drawn from it are free whether they are attached to a resource or sitting unassigned - which is a meaningful difference from Google-assigned static addresses, where an unassigned address costs $0.01 per hour. Normal data transfer, load balancing and compute charges still apply.

What are the BYOIP limits on Google Cloud?

The main ones: the advertised prefix must be between /16 and /24 for IPv4 on Premium Tier (/16 to /23 on Standard Tier, in Preview), so /24 is the smallest block you can bring. Delegated prefixes run from /16 to /28 on Premium Tier v2 (/17 to /24 on Standard Tier), sub-prefixes bottom out at /28, and a prefix can be sub-delegated up to three times. Provisioning takes multiple weeks and cannot be accelerated. Addresses cannot be moved between projects. Overlapping announcements are not supported. And several resource types are excluded - GKE nodes and Pods, Cloud VPN gateway external addresses, and MIGs that allocate addresses automatically.

How long does GCP BYOIP take?

Approximately two weeks for the recommended v2 regional configuration, and approximately four weeks for the older v1 configuration or for global prefixes. Global prefixes also require an allowlist request through a support case first. Add RIR processing time for the ROA at the front, and plan for up to eight weeks if a delegated prefix ever needs to move to a different region.

Can I split one range between Google Cloud and my own infrastructure?

Not within a single advertised prefix. Google cannot advertise a block that is simultaneously advertised elsewhere, so the whole PAP has to be exclusively Google's while it is announced. What you can do is split at the announcement boundary: if you hold a /23, bring one /24 to Google Cloud as its own PAP and keep the other /24 on your own network. Inside Google Cloud, delegated prefixes then let you split that /24 across regions and projects down to /28 granularity. And for phased moves, a delegated prefix can be announced within Google Cloud while the parent prefix is still advertised from your existing infrastructure.

Can I use leased IPv4 addresses for GCP BYOIP?

Yes. Google verifies control of the block through a ROA and a reverse DNS PTR record - it does not require that you be the registered holder. What it does require is that the registered holder cooperates: the lessor creates the ROA pointing at Google's ASN, delegates or publishes reverse DNS, and guarantees that nobody else announces the block. A lease structured with those three provisions works with BYOIP without complication.

Clean IPv4, ready to deploy

Lease Clean IPv4 Fast With Zero Platform Fees

Start leasing

Bringing a leased /24 into Google Cloud is not a difficult project, but it is a sequenced one. The engineering effort is small; the waiting is not, and almost all of the waiting is front-loaded into registry and DNS work that can be started before anyone touches the console.

If you are weighing a leased block against Google-assigned addresses, start with your address count and your utilisation, then check the lease terms against the four requirements above. And if you are running the same evaluation on another cloud, our companion guide covers bringing leased IPv4 to Azure with a Custom IP Prefix, where the model and the terminology differ more than you would expect.

Explore BYOIP-ready IPv4 blocks on IPbnb →