Cloud Functions Locations

Cloud Functions is regional, which means the infrastructure that runs a Cloud Function is located in a specific region and is managed by Google to be redundantly available across all the zones within that region.

When selecting a region to run your Cloud Functions in, your primary considerations should be latency and availability. You can generally select the region closest to your Cloud Function's users, but you should also consider the location of the other Google Cloud products and services that your app uses. Using services across multiple locations can affect your app's latency, as well as pricing.

The available regions for Cloud Functions are listed below. The different versions of Cloud Functions have different regional availability - see the "Supported product versions" column in the tables.

Tier 1 pricing

Cloud Functions is available in the following regions with Tier 1 pricing:

Region Location Supported product versions CO2 emissions
asia-east1 Taiwan 1st gen, 2nd gen
asia-east2 Hong Kong 1st gen
asia-northeast1 Tokyo 1st gen, 2nd gen
asia-northeast2 Osaka 1st gen, 2nd gen
europe-north1 Finland 2nd gen leaf icon Low CO2
europe-southwest1 Madrid 2nd gen
europe-west1 Belgium 1st gen, 2nd gen leaf icon Low CO2
europe-west2 London 1st gen
europe-west4 Netherlands 2nd gen
europe-west8 Milan 2nd gen
europe-west9 Paris 2nd gen leaf icon Low CO2
me-west1 Tel Aviv 2nd gen
us-central1 Iowa 1st gen, 2nd gen leaf icon Low CO2
us-east1 South Carolina 1st gen, 2nd gen
us-east4 Northern Virginia 1st gen, 2nd gen
us-east5 Columbus 2nd gen
us-south1 Dallas 2nd gen
us-west1 Oregon 1st gen, 2nd gen leaf icon Low CO2

Tier 2 pricing

Cloud Functions is available in the following regions with Tier 2 pricing:

Region Location Supported product versions CO2 emissions
asia-east2 Hong Kong 2nd gen
asia-northeast3 Seoul 1st gen, 2nd gen
asia-southeast1 Singapore 1st gen, 2nd gen
asia-southeast2 Jakarta 1st gen, 2nd gen
asia-south1 Mumbai 1st gen, 2nd gen
asia-south2 Delhi, India 2nd gen
australia-southeast1 Sydney 1st gen, 2nd gen
australia-southeast2 Melbourne 2nd gen
europe-central2 Warsaw 1st gen, 2nd gen
europe-west2 London 2nd gen
europe-west3 Frankfurt 1st gen, 2nd gen leaf icon Low CO2
europe-west6 Zurich 1st gen, 2nd gen leaf icon Low CO2
europe-west10 Berlin 2nd gen
europe-west12 Turin 2nd gen
me-central1 Doha 2nd gen
me-central2 Dammam 2nd gen
northamerica-northeast1 Montreal 1st gen, 2nd gen leaf icon Low CO2
northamerica-northeast2 Toronto 2nd gen leaf icon Low CO2
southamerica-east1 São Paulo 1st gen, 2nd gen leaf icon Low CO2
southamerica-west1 Santiago, Chile 2nd gen
us-west2 Los Angeles 1st gen, 2nd gen
us-west3 Salt Lake City 1st gen, 2nd gen
us-west4 Las Vegas 1st gen, 2nd gen

Selecting the region

You can select a region for your function during deployment.

gcloud

If you are using the Google Cloud CLI, you can specify the region by using the --region flag:

gcloud functions deploy FUNCTION_NAME --region=REGION ...

Where REGION is one of the regions listed above.

Console

If you are using the Google Cloud console, you can select the region when you create and deploy a function.

  1. In the Google Cloud console, go to the Cloud Functions Overview page.

    Go to the Cloud Functions Overview page

    Make sure that the project for which you enabled Cloud Functions is selected.

  2. Click Create Function.

  3. In the Region field, select a region.

You can deploy functions to different regions within a project, but once the region has been selected for a function it cannot be changed.

Functions in a given region in a given project must have unique (case sensitive) names, but functions across regions or across projects can share the same name.

Setting a default region

You can set a default region using the Google Cloud CLI as follows:

gcloud config set functions/region REGION

For example:

gcloud config set functions/region europe-west1

Data residency

Cloud Functions provides a data residency guarantee at the function execution scope (Scope A Compliance—function execution), wherein a given function provides for data residency for the function invocation/execution.

This compliance applies to both HTTP functions and event-driven functions. For event-driven functions, Cloud Functions is data residency-compliant from the moment the upstream product (triggering product) delivers the event to Cloud Functions. Hence, it's important to ensure that the upstream product (such as Cloud Storage or Pub/Sub) is itself data residency-compliant.

Best practices for changing region

If you need to change a region where a function is deployed, follow the recommendations below.

HTTP functions

For HTTP functions, we recommend that you first redeploy your HTTP function to the destination region (it can have the same name), and then alter your original function to redirect its HTTP request to the new function. If clients of your HTTP function support redirects, you can simply change your original function to return an HTTP redirect status (301) along with the URL of your new function. If your clients do not handle redirects well, you can proxy the request from the original function to the new function by initiating a new request from the original function to the new function. The final step is to ensure that all clients are calling the new function.

Event-driven functions

Event-driven functions adopt an at-least-once event delivery semantic, which means that under some circumstances they can receive duplicate events, and so should always be implemented to be idempotent. If your function is already idempotent then you can simply redeploy the function in the new region with the same event trigger, and remove the old function after you verify that the new function is correctly receiving traffic. During this transition both functions will receive events.

If your function is not currently idempotent, or its idempotency does not extend beyond the region, then we recommend that you first implement idempotency before moving the function.