Bring your own IP
Bring your own IP (BYOIP) lets you provision and use your own public IPv4 addresses for Google Cloud resources. After the IP addresses are imported, Google Cloud manages them in the same way as Google-provided IP addresses, with these exceptions:
The IP addresses are available only to the customer who brought them.
There are no charges for idle or in-use IP addresses.
Live migration lets you control when Google starts advertising routes for your prefix. Live migration is not available by default. To request access, contact your Google Cloud representative.
To bring your own IP to Google, you create a public advertised prefix (PAP). Verification of ownership is done for this public advertised prefix using ROA and reverse DNS validation. After verification is complete, we configure the announcement of this prefix to the internet, but the prefix is not advertised until it is provisioned. It takes up to four weeks for the public advertised prefix to be provisioned.
While you wait for the public advertised prefix to provision, you split the prefix into public delegated prefixes (PDP), which you configure to have regional or global scope. You can then either divide the public delegated prefix further, or use it to create assignable IP addresses. It takes up to four weeks for the public delegated prefix to be provisioned.
Once provisioning of the public delegated prefix is complete, the public advertised prefix is advertised to the internet. If you're using live migration, see using live migration for additional steps.
Public advertised prefixes
A public advertised prefix (PAP) is a resource in Compute Engine that represents an IP prefix that you bring to Google Cloud. This lets you allocate IP addresses from your own prefix to Google Cloud resources. The public advertised prefix is a single unit of route advertisement. Google's global backbone advertises the public advertised prefix from all of its points of presence. IP addresses in the public advertised prefix always use the Premium Tier of Network Service Tiers.
When creating a new public advertised prefix, it must have an IPv4 IP range with
a minimum CIDR range of size
/24. A smaller CIDR range, for example
cannot be created as a new public advertised prefix. However, once created, you
can break up a public advertised prefix, say a
/23, into smaller
public delegated prefixes.
Public delegated prefixes
A public delegated prefix (PDP) is an IP block within your public advertised prefix that is configured within a single scope (a specific region or global). The IP blocks must be delegated and assigned to a scope before you can allocate IP addresses to your project or organization.
You can break up a public advertised prefix into multiple public delegated prefixes and configure each of them with whatever scope you want in your Google Cloud projects. You can break up a single public delegated prefix into multiple smaller blocks, but these blocks must have the same scope as the parent block. You can configure multiple non-contiguous public delegated prefixes in a given scope. These smaller blocks are public delegated prefixes, but are also referred to as sub-prefixes.
When you create IP addresses
from a public delegated prefix or sub-prefix, the IP addresses can be used only
within the project and scope that they are allocated to. All IP addresses in the
public delegated prefix or sub-prefix are made available; there is no reserved
network address or broadcast address. For example, if you use a
delegated prefix or sub-prefix to create IP addresses, 16 IP address resources
Anyone who has the appropriate IAM permissions in the project can use the IP addresses:
compute.addresses.*for regional IP addresses
compute.globalAddresses.*for global IP addresses
Public IP Admin role
You can designate an administrator for your BYOIP prefixes and addresses by
assigning them the Compute Public IP Admin
roles/compute.publicIpAdmin). This role lets them manage publicly routable
IPs in your organization.
The Public IP Admin can do the following tasks:
- Configure public advertised prefixes in a project they own.
- Configure the public advertised prefixes into public delegated prefixes in a project they own.
- Delegate sub-prefixes from the public delegated prefixes to specific projects in the organization.
- Revoke sub-prefixes that were previously delegated from the public delegated prefixes to a specific project in the organization.
- Delete public delegated prefixes.
Planning your deployment
It's important to plan your deployment, because provisioning and deletion processes require several weeks to complete. For more information about the provisioning timeline and allowed prefix sizes, see Limitations.
Here are some decisions that should be considered when you plan your deployment:
Who is responsible for administering BYOIP addresses? This is typically an admin or group, but is not typically the same users who manage individual projects. Use IAM roles and permissions to distinguish who has privileges for the public advertised prefixes and public delegated prefixes that you plan to provision.
How are prefixes managed? It is likely that you want to use your BYOIP addresses in different projects. You can manage prefixes centrally in a project distinct from the ultimate destinations of the IP addresses. We recommend that you isolate prefix administration in a project of its own, including its own users and groups with Public IP Admin permissions. This isolation helps to prevent confusion about prefix administration and inadvertent or unauthorized use of prefixes. For more information, see Project architecture.
How are prefixes named? Every BYOIP resource (public advertised prefix, public delegated prefix, sub-prefix) requires a name, and the name is used to manage each resource. You assign the name during resource creation, and names can't be changed without deleting and recreating the resource. For this reason, we recommend that you create names that are easy to manage. For example,
sub-203-0-113-0-28, where the letters denote the resource type, and the numbers denote the specific prefix and prefix length.
Where are the IP addresses provisioned? It's useful to think of the provisioning process as "stocking" IPs into regions (or the global scope). The provisioning process for stocking IP addresses takes several weeks to complete, so it's useful to plan and deploy public delegated prefixes long before they are needed.
You don't have to use all IPs in a public delegated prefix immediately. If you aren't sure where you need them, provision only the public delegated prefixes that you're certain you need to use. Moving a public delegated prefix requires complete deletion and then recreation, which can take up to eight weeks.
After public delegated prefix provisioning is complete, you can delegate sub-prefixes to projects and create addresses for use with resources. If you anticipate needing BYOIP addresses in a region, complete the public delegated prefix provisioning process in advance, so you can later fulfill addressing needs on-demand.
For example, say you have a
/24public advertised prefix. You know you need some IP addresses in
us-central1, some IP addresses for global load balancers, and you want to reserve some for future use. You could create the following plan:
Prefix type Prefix Scope Public advertised prefix 203.0.113.0/24 Public delegated prefix 203.0.113.0/28 us-central1 Public delegated prefix 203.0.113.16/28 global Remaining IP addresses reserved for future use
Live migration is a powerful feature that requires detailed planning and execution.
Use live migration to import a BYOIP prefix when any part of the prefix is already publicly advertised. Importing an advertised prefix without using live migration might cause unexpected routing and packet loss.
Live migration has limited availability. Contact your Google Cloud representative to get access before you create a public delegated prefix with live migration enabled.
You enable live migration when you create a public delegated prefix. To prevent Google from advertising the public advertised prefix to peers, you must ensure the following:
All public delegated prefixes within the public advertised prefix are configured with regional scope, not global scope. See live migration recommendations for more information.
No IP addresses in the range of the public advertised prefix are assigned to resources.
Figure 2 displays the same project with different configurations, one of which prevents the prefix from being advertised, and two which cause the public advertised prefix to be advertised.
Figure 2 illustrates the following scenarios:
In the first project example, all public delegated prefixes in the public advertised prefix are configured with live migration enabled. No VMs are configured with IP addresses from this prefix.
Result: The public advertised prefix is not advertised.
In the second project example, all public delegated prefixes in the public advertised prefix are configured with live migration enabled. One VM is configured with an IP address from this prefix.
Result: The public advertised prefix is advertised.
In the third project example, one public delegated prefix within the public advertised prefix is not configured with live migration enabled. No VMs are configured with IP addresses from this prefix.
Result: The public advertised prefix is advertised.
You control when the advertisement starts by assigning IP addresses from your public delegated prefix to Google Cloud resources. For more information, see Using live migration.
After your live migration is complete, contact your Google Cloud representative so that they can disable live migration for your prefix. By default, live migration is disabled 30 days after you start advertisement of the public advertised prefix. If you need to have the live migration option available for longer than 30 days, contact your Google Cloud representative.
Live migration limitations
When planning a live migration, it is important that you understand the following requirements and limitations:
Creating a public delegated prefix with live migration enabled is not supported if the scope is set to global. See live migration recommendations for information about managing live migration for global resources.
The longest prefix that can be migrated is a
/24is the maximum routable prefix-length on the internet.
Don't assume that all Google's peers respect the longest prefix between two sites. Some peers might not have full routing tables. As a result, a shorter prefix advertised by Google to those peers is the only (and therefore also the longest) prefix that the peer sees. As a result, the existence of any prefix from Google takes precedence, even if you are advertising a more specific route from your on-premises location.
A customer has a
/23which is actively routed from their on-premises location. The customer plans to disaggregate the
/24prefixes, and announce the more specific routes from their on-premises location. Following the disaggregation, they plan to configure a
/23public advertised prefix for BYOIP. They assume that the more specific routes from their on-premises location take precedence over the shorter BYOIP prefix, and that traffic continues to route to the more specific on-premises prefixes.
Unfortunately, this plan works only partially:
Google peers who have full routing tables prefer the more specific
Google peers who do not have full routing tables prefer the public advertised prefix announced from Google, since their routing tables don't include the more specific prefixes.
Your traffic is not delivered if Google receives traffic for a valid public advertised prefix for which you have not provisioned services, even if there is an active on-premises advertisement for the prefix.
A customer has an on-premises network comprising two
/24prefixes. Their public advertised prefix is the aggregate
The customer migrates a single
/24to Google and withdraws the on-premises prefix, but leaves the other
/24active in the on-premises location.
This configuration results in some of the traffic routing to Google for the whole
/23prefix, even though there is still a more specific
/24prefix announced from the on-premises location. This scenario is difficult to diagnose, since various Autonomous Systems deliver traffic to your on-premises location, but others deliver to Google, in which case the traffic is dropped.
Live migration recommendations
As a best practice, follow these recommendations when using live migration.
Disaggregate all live migration prefixes into the longest prefixes that reflect how you want to advertise these prefixes during migration. In the previous examples, the
/23should be disaggregated into two
/24prefixes and announced as such from their on-premises location before you create the public advertised prefix.
Create exact prefix length ROA requests, and do not rely on the maximum length parameter to be respected.
Make sure that RPKI ROA requests exist for both the on-premises origin ASN and Google's origin ASN. If there is no ROA for the on-premises prefix, the creation of a Google origin ROA might cause third-party ISPs to filter out those on-premises prefixes if they are using automatic RPKI filtering.
Create separate public advertised prefixes for global resources and regional resources if you need to use live migration. When you enable live migration on a public delegated prefix, you must specify a region for the scope. Specifying global scope for a public delegated prefix that has live migration enabled is not supported. If you create a public delegated prefix with global scope and live migration enabled, the prefix is advertised immediately.
Having regional prefixes in one public advertised prefix and global prefixes in another public advertised prefix lets you manage them separately. You can manage the live migration of the regional resources, and contact your Google Cloud representative to manage live migration of the global resources.
We recommend that you use organizations to benefit from features such as IAM permissions at the organization level and Shared VPC. See creating and managing organizations for more information about using an organization.
BYOIP address administration in an organization
In this example of a project belonging to an organization, there is a dedicated
Public IP Project, used to manage BYOIP addresses. The Public IP
Admin for the organization has created the public advertised prefix and public
delegated prefixes in the
Public IP Project.
VPC Project needs public IP addresses, the Public IP Admin for the
organization creates the IP addresses in the
The organization can contain multiple projects, and the Public IP Admin can
delegate IP addresses to them all from the
Public IP Project.
BYOIP addresses administration with Shared VPC
In this example of an organization that contains Shared VPC, there is a
Public IP Project, used to manage BYOIP addresses. The
Public IP Admin for the organization has created the public advertised prefix
and public delegated prefixes in the
Public IP Project
Shared VPC Host Project or the related service projects need public
IP addresses, the Public IP Admin for the organization creates the IP addresses
Shared VPC Host Project. The host project and the service projects can
access the BYOIP addresses from the host project.
Creating IP addresses in a Shared VPC service project is not supported.
BYOIP address administration without an organization
If you use a project that does not belong to an organization, you can't create a separate project for BYOIP address administration. Create the public advertised prefix and public delegated prefixes in the same project that needs the BYOIP addresses.
Quotas and limits
There are quotas and limits for public delegated prefixes (PDPs) and public advertised prefixes (PAPs). For more information, see VPC quotas and limits.