Regional and multiregional API endpoints overview

Google Cloud recommends using regional or multiregional endpoints in the following scenarios:

  • Data in transit must remain within a specific region or jurisdiction.
  • You need evidence of regional data handling for compliance or audit purposes.
  • You need regionally isolated failure domains for accessing Google Cloud services.

Regional and multiregional endpoints offer the most benefits to customers who require the use of location-specific services. These endpoints also ensure that in-transit data remains in a particular location. This data locality is maintained whether the data is accessed through private connectivity or through the public internet.

Regional and multiregional endpoints are different than Private Google Access. Private Google Access allows VMs in private subnets to reach Google APIs without traversing the internet. Regional endpoints provide stricter regional isolation and data residency, because the entire request path and service frontend are regionalized.

Regional endpoints

Regional API endpoints provide access to Google Cloud services through an API endpoint that is scoped to a single Google Cloud region. Traffic sent to a regional endpoint is processed and TLS terminated within the specified region.

For most Google Cloud services, you can use regional endpoints to work with regional resources within the specified region. Operations on global resources, multiregional resources, and out-of-region regional resources are typically not supported from the regional endpoint.

Multiregional endpoints

Multiregional API endpoints provide access to Google Cloud services through an API endpoint that is scoped to a set of Google Cloud regions within the same country, such as the United States, India, or Canada, or jurisdiction, such as the European Union. Traffic sent to a multiregional endpoint is processed and TLS terminated entirely within the specified jurisdiction.

For most Google Cloud services, you can use multiregional endpoints to work with multiregional resources within the specified multiregion. Operations on global resources, regional resources, and multiregional resources from other jurisdictions are typically not supported.

Benefits of regional and multiregional endpoints

Using regional and multiregional endpoints has the following benefits:

  • Data residency: helps meet strict data residency requirements by keeping data in transit within the chosen region. The TLS session is always terminated within the specified region.
  • Regional isolation: reduces cross-regional dependencies, which reduces problems due to failures in other regions.
  • Compliance: helps you comply with regulatory or policy requirements that mandate that data is processed and stored within specific geographic boundaries.

Limitations of regional and multiregional endpoints

  • Regional and multiregional endpoints are not accessible through Private Google Access. To connect to regional endpoints through private access, use Private Service Connect to create private endpoints. For more information, see Access regional Google APIs through private endpoints.

  • Many services don't support cross-regional operations from regional endpoints. To run cross-regional operations, use global endpoints. If the cross-regional operations remain within one jurisdiction, use multiregional endpoints.

  • Some Google Cloud services don't support regional or multiregional endpoints. For a complete list of supported services, see Regional service endpoints.

  • Regional and multiregional endpoints might have higher latency than global endpoints. Performance varies based on your location and the region that you're using.

Implement regional and multiregional endpoints

You can access regional or multiregional endpoints privately from your VPC through regional load balancers. For example, you can define a VPC Service Controls perimeter to isolate the cloud resources of a given project from the internet and from unauthorized networks. For a given perimeter, you decide which services to enforce VPC Service Controls for, and then you put projects within the perimeter. For more information, see the Use VPC Service Controls section in this document.

Public access

You can access regional and multiregional endpoints publicly over the internet. When you access regional endpoints from the internet, traffic is routed through the Google Cloud Standard Tier networking. The connection, including TLS termination, is handled within the destination region.

For more information, see Access regional Google APIs through public endpoints.

Private access

For private access to regional and multiregional endpoints, use Private Service Connect. Private Service Connect creates a private IP address in your Virtual Private Cloud (VPC). The private IP address routes to the regional service. Although global APIs often use standard Private Google Access by using special ranges, like private.googleapis.com, regional and multiregional endpoints require explicit private endpoint configuration.

For more information, see Access regional Google APIs through private endpoints.

Configure routing and firewalls

Follow these guidelines to correctly configure your routing and firewalls.

On-premises routing

If you connect to regional endpoints from on-premises environments over Cloud Interconnect or Cloud VPN, you must advertise the regional endpoint private IP ranges. This configuration ensures proper routing from your on-premises network to the Google Cloud services.

  • Cloud Router: use custom route advertisements to announce all private IP ranges over the hybrid connection.
  • On-premises firewalls: configure your on-premises firewalls to allow outbound traffic to the public or private virtual IP address ranges of the regional endpoints. For more information, see Use VPC firewall rules.

VPC firewall rules

Configure your egress firewall policies to allow traffic to the private IP addresses of the regional endpoints. If you remove default routes, verify that appropriate routes are in place for the regional endpoint virtual IP address (VIP) ranges:

  • For public VIP access, make sure that routes exist for the VIP ranges of the regional endpoints with the next hop set to the default internet gateway.

  • For Private Service Connect, use IP addresses or standard internal routing.

For more information, see Configure a hierarchical firewall policy to allow egress traffic from a specific VPC network.

Use VPC Service Controls

Regional endpoints are compatible with VPC Service Controls perimeters. For more information about VPC Service Controls, see Service perimeter details and configuration.

VPC Service Controls helps prevent data exfiltration from Google Cloud services by creating security perimeters. Because you can't access regional endpoints through Private Google Access, to access the endpoints within a VPC perimeter, you must use Private Service Connect to configure private endpoints.

  • Perimeter enforcement: When you add a service, such as storage.googleapis.com, to the Restricted services list in your VPC Service Controls perimeter, VPC Service Controls rules apply to all access methods for that service, including access through regional endpoints.

  • Service control checks: API requests to regional endpoints, whether public or private, are subject to policy checks by the Service Control API. The Service Control API evaluates the request against the VPC Service Controls perimeter configuration and reviews the source network, the source project, and the target resource project.

  • Inside the perimeter: Resources within a VPC Service Controls perimeter, such as VMs, can access services through regional endpoints if the service is part of the perimeter's accessible services. The network endpoint must be within your VPC perimeter, which requires you to create private regional endpoints by using Private Service Connect. For more information, see Access regional Google APIs through private endpoints.

  • Outside the perimeter: Attempts to access resources protected within the perimeter from outside of the perimeter using any endpoint type are blocked by VPC Service Controls, unless access levels or ingress and egress rules explicitly allow access.

For example, you define a VPC Service Controls perimeter to enforce a policy on Cloud Storage resources and then place secure_project within the perimeter. Only the VMs from secure_project can access the Cloud Storage resources of secure_project. In addition, the VMs are prevented from accessing Cloud Storage resources outside of the perimeter.

Benefits of VPC Service Controls

Using VPC Service Controls provides the following benefits:

  • You get the benefits of regional isolation and data residency along with the data exfiltration protection of VPC Service Controls.

  • With VPC Service Controls, access that is scoped to a single region is also governed by the security boundaries of your VPC Service Controls perimeters.

Configure VPC Service Controls

Within a VPC Service Controls perimeter, you must access private regional endpoints by using Private Service Connect from within a VPC perimeter. For more information, see Access regional Google APIs through private endpoints.

  • Standard public regional endpoint access might be blocked, because it appears to originate from outside of the perimeter.

  • Ensure that the service that you are accessing, such as compute.googleapis.com or bigquery.googleapis.com, is included in the list of services restricted by the perimeter.

Use organization policies for additional enforcement

Organization policies provide additional controls for your organization's cloud resources. The following two policies work with regional endpoints to enforce data residency and to improve regional isolation:

Enforce regional endpoint use

To enforce the use of regional endpoints, use the Restrict Endpoint Usage organization policy constraint to deny access to global endpoints. For more information, see Restricting endpoint usage in the Assured Workloads documentation.

Regional endpoints ensure that data in transit stays within a region, and the Restrict Endpoint Usage constraint ensures that the resources used to store data at rest are only created in the regions that you allow. Using both policies provides more comprehensive data residency protections for data at rest and for data in transit.

The Restrict Endpoint Usage constraint is set using a denylist, allowing requests to any supported services' API endpoints that are not explicitly denied. After you configure regional endpoints, global endpoints are still accessible unless you use the Restrict Endpoint Usage organization policy constraint.

The Restrict Endpoint Usage constraint controls the physical locations where users can create and store new Google Cloud resources, enforcing data residency at rest. This policy applies only to the creation of new resources for supported services. Existing resources are not impacted.

Enforce location constraints

The resource locations constraint policy (constraints/gcp.resourceLocations) controls the physical locations where new Google Cloud resources can be created and stored, which addresses data residency at rest. For more information, see Set the organization policy in the Resource Manager documentation.

When you use the resource location constraint policy, you define a list of allowed or denied Google Cloud locations. For the locations, you can use regions, zones, or multiregions. The policy applies only to the creation of new resources for supported services. Existing resources are not impacted.

Using this policy with regional endpoints is beneficial, because regional endpoints ensure that data in transit stays within a region, and the location constraint policy ensures that resources that store the the regions that you allow.

Combined enforcement

By using the Restrict Endpoint Usage policy to deny global endpoints and the resource locations constraint policy to restrict the locations where resources can be created, you enforce data at rest and data in transit.

  • Data at rest: resources are only created and stored in allowed regions.
  • Data in transit: API interactions with those resources are handled entirely within the specified region when using the corresponding regional endpoint.

Pricing

For private regional endpoints, pricing is based on Private Service Connect usage. Billing charges include the endpoint and data processing.

For public regional endpoints, ingress traffic is not billed. Egress traffic is billed based on Standard Tier network pricing.

Reference documentation

What's next