[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-09-03。"],[],[],null,["# Planning for bring your own IP addresses\n========================================\n\nBring your own IP addresses (BYOIP) lets you provision and use your own public\nIPv4 addresses for Google Cloud resources. After the IP addresses are imported,\nGoogle Cloud manages them in the same way as Google-provided IP addresses,\nwith these exceptions:\n\n- The IP addresses are available only to the customer who brought them.\n\n- There are no charges for idle or in-use IP addresses.\n\nPlanning your deployment\n------------------------\n\nIt's important to plan your deployment, because provisioning and deletion\nprocesses require multiple weeks to complete. For more information about the\nprovisioning timeline and allowed prefix sizes, see\n[Limitations](/vpc/docs/using-bring-your-own-ip#limitations).\n\nHere are some decisions that should be considered when you plan your deployment:\n\n- **Who is responsible for administering BYOIP addresses?**\n This is typically an administrator or group, but is not typically the same users\n who manage individual projects. Use IAM roles and permissions to distinguish who\n has privileges for the public advertised prefixes and public delegated prefixes\n that you plan to provision.\n\n- **How are prefixes managed?**\n It is likely that you want to use your BYOIP addresses in different projects.\n You can manage prefixes centrally in a project distinct from the ultimate\n destinations of the IP addresses. We recommend that you isolate prefix\n administration in a project of its own, including its own users and groups with\n Public IP Admin permissions. This isolation helps to prevent confusion about\n prefix administration and inadvertent or unauthorized use of prefixes. For more\n information, see [Project architecture](#architecture).\n\n- **How are prefixes named?** Every BYOIP resource (public advertised prefix,\n public delegated prefix, sub-prefix) requires a name, and the name is used to\n manage each resource. You assign the name during resource creation, and names\n can't be changed without deleting and recreating the resource. For this reason,\n we recommend that you create generic names that won't need to change---for\n example, `pap-203-0-113-0-24`, `pdp-203-0-113-0-25`,\n `sub-203-0-113-0-28`, where the letters denote the resource type, and the\n numbers denote the specific prefix and prefix length.\n\n- **Where are the IP addresses provisioned?**\n It's useful to think of the provisioning process as \"stocking\" IPs into regions\n (or the global scope). The provisioning process for stocking IP addresses takes\n multiple weeks to complete, so it's useful to plan and deploy public delegated\n prefixes long before they are needed.\n\n You don't have to use all IPs in a public delegated prefix immediately. If\n you aren't sure where you need them, provision only the public delegated\n prefixes that you're certain you need to use. Moving a public delegated\n prefix requires complete deletion and then recreation, which can take\n approximately eight weeks.\n\n After public delegated prefix provisioning is complete, you can delegate\n sub-prefixes to projects and create addresses for use with resources. If you\n anticipate needing BYOIP addresses in a region, complete the public\n delegated prefix provisioning process in advance, so you can later fulfill\n addressing needs on-demand.\n\n For example, if you need some IP addresses in `us-central1` and some IP\n addresses for global load balancers, and you want to reserve some IP\n addresses for the future, you should create the following plan.\n\n The remaining IP addresses are reserved for future use.\n\nProject architecture\n--------------------\n\nWe recommend that you use organizations to benefit from\nfeatures such as IAM permissions at the organization level and\n[Shared VPC](/vpc/docs/shared-vpc).\nSee [creating and managing organizations](/resource-manager/docs/creating-managing-organization#creating-projects)\nfor more information about using an organization.\n\n### BYOIP address administration in an organization\n\nIn this example of a project belonging to an organization, there is a dedicated\nproject, `Public IP project`, used to manage BYOIP addresses. The Public IP\nAdmin for the organization has created the public advertised prefix and public\ndelegated prefixes in the `Public IP project`.\n\nWhen the `VPC project` needs public IP addresses, the Public IP Admin for the\norganization creates the IP addresses in the `VPC project`.\n\nThe organization can contain multiple projects, and the Public IP Admin can\ndelegate IP addresses to them all from the `Public IP project`.\n[](/static/vpc/images/byoip-vpc-standalone.svg) **Figure 1.** You can use organizations and projects to manage BYOIP\naddresses.\n\n### BYOIP addresses administration with Shared VPC\n\nIn this example of an organization that contains Shared VPC, there is a\ndedicated project, `Public IP project`, used to manage BYOIP addresses. The\nPublic IP Admin for the organization has created the public advertised prefix\nand public delegated prefixes in the `Public IP project`.\n\nWhen the `Shared VPC host project` or the related service projects need public\nIP addresses, the Public IP Admin for the organization creates the IP addresses\nin the `Shared VPC host project`. The host project and the service projects can\naccess the BYOIP addresses from the host project.\n\nCreating IP addresses in a Shared VPC service project is not supported.\n[](/static/vpc/images/byoip-vpc-shared.svg) **Figure 2.** You can delegate BYOIP addresses to a Shared VPC host\nproject, but not to a Shared VPC service project. However, a service\nproject can use BYOIP addresses that were delegated to the host project.\n\n### BYOIP address administration without an organization\n\nIf you use a project that does not belong to an organization, you can't create a\nseparate project for BYOIP address administration. Create the public advertised\nprefix and public delegated prefixes in the same project that needs the BYOIP\naddresses.\n\nWhat's next\n-----------\n\n- [Create a public advertised prefix](/vpc/docs/create-pap)"]]
