Naar de inhoud
Networks

Eigen IP meenemen

Google Cloud BYOIP: bring your own IPv4 addresses to Compute Engine

BYOIP beschikbaarUnited StatesGecontroleerd aan de hand van de documentatie van Google Cloud op Artikel in het Engels

You prove control of the block with a ROA naming Google's ASN and a PTR record carrying a name Google gives you, then carve delegated prefixes out of it and create static external addresses from them.

This guide covers IPv4 in the configuration Google recommends, a regional (v2) prefix on Premium Tier, through the gcloud CLI. Global addresses for global load balancers use the older v1 configuration, and your project has to be on an allowlist first.

What Google Cloud accepts

From Google Cloud's documentation, on the day we checked:

  • Size. A public advertised prefix of "/16 to /24" on Premium Tier, the default, or "/16 to /23" on Standard Tier, which is in Preview. You can split it down to /28 blocks.
  • Registry. Google links ROA instructions for each regional registry, ARIN, the RIPE NCC and APNIC among them. It publishes nothing on PA, PI or legacy status, or on whose name the block must be in.
  • Who originates. Google, from AS396982 on Premium Tier or AS19527 on Standard Tier. It documents no option to announce from your own ASN.
  • No overlap. "Google Cloud does not support overlapping BYOIP route announcements": neither the prefix nor any part of it may be announced elsewhere while Google announces it.
  • Regions. Each delegated prefix serves one region, or the global scope. Google's BYOIP pages name no excluded regions.
  • Price. "There are no charges for idle or in-use IP addresses."
  • Timing. "Approximately 2 weeks" for a v2 prefix after validation, "approximately 4 weeks" for v1 and global ones. Provisioning "cannot be accelerated".
  • Resources. Most of those that take a static external address, but not GKE nodes and Pods or the external address of a Cloud VPN gateway. Addresses cannot move between projects.

Before you start

A ROA for Google's ASN. On Premium Tier it names the prefix, its exact length and AS396982. On Standard Tier it names AS19527, either in one ROA for each prefix you will provision, which Google recommends, or in one ROA with a maximum length of /24 (RPKI and ROAs).

A second ROA for your own ASN. Google recommends one with the same details and your ASN as origin, so that networks doing route origin validation do not treat the prefix as invalid if you ever announce it yourself.

Control of the reverse DNS. Google checks ownership with a PTR record, not with a token in the registry record. You pick an unused address in the prefix, Google returns a name (its shared secret), and you publish a PTR record for that address pointing to that name under your domain.

Nothing else from the registry. Google asks for no certificate, letter of authorization or route object. On its side, you need the Compute Public IP Admin role (roles/compute.publicIpAdmin) on the project.

Step by step

01Create the public advertised prefix, naming the address you will use for DNS validation:

Shell
gcloud compute public-advertised-prefixes create pap-203-0-113-0-24 \
    --range=203.0.113.0/24 \
    --pdp-scope=REGIONAL \
    --dns-verification-ip=203.0.113.144

For Standard Tier, use gcloud beta and add --network-tier=STANDARD.

02Publish the PTR record. gcloud compute public-advertised-prefixes describe pap-203-0-113-0-24 --format='value(sharedSecret)' gives the name. If it is 55kk88tt00 and your domain is example.net, then dig +short -x 203.0.113.144 must return 55kk88tt00.example.net.

03Trigger validation:

Shell
gcloud compute public-advertised-prefixes update pap-203-0-113-0-24 --status=PTR-CONFIGURED

The status turns VALIDATED, or REVERSE_DNS_LOOKUP_FAILED if Google cannot find the record. Provisioning is finished when describe with --format='value(status)' shows PREFIX_CONFIGURATION_COMPLETE.

04Delegate a block to a region. This can run while you wait:

Shell
gcloud compute public-delegated-prefixes create pdp-203-0-113-0-25 \
    --public-advertised-prefix=pap-203-0-113-0-24 \
    --range=203.0.113.0/25 \
    --region=europe-west4

05Create addresses. Delegated prefixes created after 13 December 2025 allow single addresses:

Shell
gcloud compute addresses create web-1 --network-tier=PREMIUM \
    --ip-collection=pdp-203-0-113-0-25 --addresses=203.0.113.10 --region=europe-west4

Older prefixes and global addresses take whole blocks, through delegated-sub-prefixes create --create-addresses. Attach the addresses to VMs or forwarding rules. They are not reachable yet.

06Announce. Make sure no other network announces the block. Announce the delegated prefix first, which Google carries inside its own network, then the advertised prefix, which goes to the internet from all Google points of presence:

Shell
gcloud compute public-delegated-prefixes update pdp-203-0-113-0-25 --region=europe-west4 --announce-prefix
gcloud compute public-advertised-prefixes update pap-203-0-113-0-24 --announce-prefix

From outside, RIPEstat's validator should call the prefix valid for AS396982: curl "https://stat.ripe.net/data/rpki-validation/data.json?resource=396982&prefix=203.0.113.0/24".

Mistakes that cost a day

  • Two networks announcing. Overlap includes a more specific route: a /24 announced elsewhere inside a /23 you bring counts. Google warns of "unexpected routing and packet loss".
  • v1 announces itself. A global (v1) prefix is announced as soon as its delegated prefix is provisioned. Google says not to create delegated prefixes until nobody else announces the block.
  • A lapsed ROA. If the ROA expires and you do not renew it within four weeks of Google's renewal notification, Google stops advertising the prefix.
  • Names and regions are fixed. Renaming a prefix means deleting and recreating it, and moving a delegated prefix to another region "can take approximately eight weeks". Pick names like pap-203-0-113-0-24 and delegate only what you are sure of.
  • Removing the ROA too early. After you delete a public advertised prefix, wait 14 days before you remove the ROA for Google's ASN.

If you lease the block

Google publishes no rule on whose name the block is registered in, and asks for no letter of authorization. Its two checks, the ROA and the PTR record, both sit with the holder of a leased block. The holder creates the ROA for AS396982 or AS19527, and the one for your ASN if you want it. The holder also creates the PTR record with Google's name, or delegates the block's reverse zone to name servers you control. Agree that the ROA is renewed for as long as Google announces the block, and kept for 14 days after you leave.

Where RTM Networks fits

We lease /24s and larger from our own RIPE NCC address space, and sell blocks in the RIPE NCC, ARIN and APNIC regions. For space leased from us, we create the ROA for Google's ASN and the PTR record with Google's name (lease IPv4). If you need fewer than 256 addresses on a Compute Engine VM, we announce a block ourselves and deliver it over GRE or WireGuard, in any size down to a single address (GRE and WireGuard tunnels). How the hourly IPv4 charge adds up at the large clouds: the real cost of cloud IPv4. Other providers: BYOIP guides.

Contact

Uw eigen IP meenemen naar Google Cloud?

Vertel ons de provider, de regio en hoeveel adressen u nodig heeft. Wij verhuren /24's en groter met het registry-werk voor uw provider gedaan, verkopen blokken, of leveren minder adressen via een tunnel. Wij reageren meestal in 1-3 kantooruren.

Neem contact op

FAQ

Google Cloud BYOIP: vragen

Does Google Cloud support BYOIP?

Yes, natively. You prove control of a /24 or larger with a ROA naming Google's ASN and a PTR record carrying a name Google gives you, then delegate parts of it to regions and projects. Google charges nothing for the addresses, idle or in use, but provisioning takes weeks.

Which ASN does the ROA need for Google Cloud?

AS396982 on Premium Tier, the default, for the prefix at its exact length. On Standard Tier, which is in Preview, AS19527, preferably in one ROA for each prefix you provision. Google also recommends a second ROA with your own ASN, so the block stays valid if you ever announce it yourself.

How long does Google Cloud BYOIP take?

About two weeks after validation for a regional (v2) prefix and about four weeks for v1 and global ones, and Google says provisioning cannot be accelerated. Delegated prefixes then take minutes on v2. Deleting a prefix takes as long again, so plan the regions before you start.

Can I use part of my block in Google Cloud?

Yes. You split the prefix into delegated prefixes and sub-prefixes down to a /28, each tied to one region and project, and v2 prefixes created after 13 December 2025 also let you create single addresses. The prefix you bring must still be a /24 or larger.

Can I bring leased space to Google Cloud?

Google publishes no rule on whose name the block is registered in, and asks for no letter of authorization. The holder creates the ROA for Google's ASN and either creates the PTR record or delegates the reverse zone to you. For space leased from us, we create both.