在以下示例中，服务边界包含两个项目：一个项目具有已获授权的 VPC 网络，另一个项目具有受保护的 Cloud Storage 资源。在 VPC 网络中，虚拟机实例必须位于启用了专用 Google 访问通道的子网中，并且只需要访问 VPC Service Controls 受限服务。从已获授权的 VPC 网络中的虚拟机实例到 Google API 和服务的查询会解析为 restricted.googleapis.com，并且可以访问受保护的资源。
[[["易于理解","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-04。"],[],[],null,["# Private Google Access with VPC Service Controls\n\nPrivate Google Access offers private connectivity to hosts in either a\nVPC network or an on-premises network that uses private IP addresses\nto access [Google APIs and services](https://developers.google.com/apis-explorer/#p/). You can extend a\nVPC Service Controls service perimeter to hosts in those networks to control access\nto protected resources.\n\nHosts in a VPC network must have a private IP address\nonly (no public IP address) and be in a subnet with Private Google Access\nenabled.\n\nFor on-premises hosts to reach restricted Google API services, requests\nto Google APIs must be sent through a VPC network, either through\na [Cloud VPN](/network-connectivity/docs/vpn) tunnel or a\n[Cloud Interconnect](/network-connectivity/docs/interconnect) connection.\n\nIn both cases, we recommend that you send all requests to Google APIs and\nservices to the\n[virtual IP (VIP) address ranges for `restricted.googleapis.com`](#ip-ranges). The\nIP address ranges are not announced to the internet. Traffic sent to the VIP\nstays within Google's network only.\n| **Note:** If you require access to other Google APIs and services that aren't supported by VPC Service Controls, you can use `private.googleapis.com`. However, private VIP can allow access to services that are not compliant with VPC Service Controls that might have data exfiltration risks. We recommend that you use `restricted.googleapis.com`, which integrates with VPC Service Controls and mitigates data exfiltration risks. Using `restricted.googleapis.com` denies access to Google APIs and services that are not supported by VPC Service Controls.\n\nFor more information about the `private.googleapis.com` and\n`restricted.googleapis.com` VIPs, see [Configure\nPrivate Google Access](/vpc/docs/configure-private-google-access).\n\nIP address ranges for `restricted.googleapis.com`\n-------------------------------------------------\n\nThere are two IP address ranges associated with the `restricted.googleapis.com`\ndomain:\n\n- IPv4 range: `199.36.153.4/30`\n- IPv6 range: `2600:2d00:0002:1000::/64`\n\nFor information about using the IPv6 range to access Google APIs,\nsee [IPv6 support](/vpc-service-controls/docs/set-up-private-connectivity#ipv6-support).\n\nVPC network example\n-------------------\n\nIn the following example, the service perimeter contains two projects: one that\nhas an authorized VPC network and another with the protected\nCloud Storage resource. In the VPC network, VM instances\nmust be in a subnet with [Private Google Access](/vpc/docs/private-google-access#pga) enabled and only require\naccess to VPC Service Controls restricted services. Queries to Google APIs and\nservices from VM instances in the authorized VPC network resolve\nto `restricted.googleapis.com` and can access the protected resource.\n[](/static/vpc-service-controls/images/pga-for-vpc-service-controls-1.svg) Private Google Access with VPC Service Controls (click to enlarge)\n\n- DNS was configured in the VPC network to map `*.googleapis.com` requests to `restricted.googleapis.com`, which resolves to `199.36.153.4/30`.\n- A custom static route was added to the VPC network that directs traffic with the destination `199.36.153.4/30` to the `default-internet-gateway` as the next hop. Even though `default-internet-gateway` is used as the next hop, traffic is routed privately through Google's network to the appropriate API or service.\n- The VPC network was authorized to access the `My-authorized-gcs-project` because both projects are in the same service perimeter.\n\nOn-premises network example\n---------------------------\n\nYou can use either static routing, by simply configuring a static route in the\non-premises router, or by announcing the restricted Google API address range\nthrough border gateway protocol (BGP) from [Cloud Router](/compute/docs/cloudrouter).\n\nTo use Private Google Access for on-premises hosts with VPC Service Controls,\n[set up private connectivity](/vpc/docs/configure-private-google-access-hybrid) for on-premises hosts and then configure\nVPC Service Controls. Define a service perimeter for the project that\ncontains the VPC network that's connected to your on-premises\nnetwork.\n\nIn the following scenario, the storage buckets in project `sensitive-buckets`\ncan only be accessed from VM instances in the project `main-project` and from\nconnected on-premises applications. On-premises hosts can access storage buckets\nin the project `sensitive-buckets` because traffic goes through a\nVPC network that's inside the same service perimeter as\n`sensitive-buckets`.\n[](/static/vpc-service-controls/images/pga-hybrid-use-case1.svg) Private Google Access for hybrid cloud use case (click to enlarge)\n\n- The on-premises DNS configuration maps `*.googleapis.com` requests to `restricted.googleapis.com`, which resolves to the `199.36.153.4/30`.\n- The Cloud Router was configured to advertise the `199.36.153.4/30` IP address range through the VPN tunnel. Traffic going to Google APIs is routed through the tunnel to the VPC network.\n- A custom static route was added to the VPC network that directs traffic with the destination `199.36.153.4/30` to the `default-internet-gateway` as the next hop. Even though `default-internet-gateway` is used as the next hop, traffic is routed privately through Google's network to the appropriate API or service.\n- The VPC network was authorized to access the `sensitive-buckets` projects, and on-premises hosts have the same access.\n- On-premises hosts can't access other resources that are outside of the service perimeter.\n\nThe project that connects to your on-premises network must be a member of the\nservice perimeter to reach restricted resources. On-premises access also works\nif the relevant projects are connected by a perimeter bridge.\n\nWhat's next\n-----------\n\n- To configure private connectivity, refer to [Setting up private connectivity](/vpc-service-controls/docs/set-up-private-connectivity)."]]
