Cloud Functions is regional, which means the infrastructure that runs your 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 what 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.
Cloud Functions is available in the following regions with Tier 1 pricing:
us-central1(Iowa)us-east1(South Carolina)us-east4(Northern Virginia)europe-west1(Belgium)europe-west2(London)asia-east2(Hong Kong)asia-northeast1(Tokyo)asia-northeast2(Osaka)
Cloud Functions is available in the following region with Tier 2 pricing:
us-west2(Los Angeles)us-west3(Salt Lake City)us-west4(Las Vegas)northamerica-northeast1(Montreal)southamerica-east1(Sao Paulo)europe-west3(Frankfurt)europe-west6(Zurich)australia-southeast1(Sydney)asia-south1(Mumbai)asia-southeast2(Jakarta)asia-northeast3(Seoul)
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 insensitive) names, but functions across regions or across projects can share the same name.
Note that you can retrieve the latest set of locations programmatically using the project.locations/list method from the Cloud Functions API.
Selecting the region
You can select a region for your function during deployment.
gcloud
If you are using the gcloud command-line tool, you can specify the region
by using the --region flag. For example:
gcloud functions deploy FUNCTION_NAME --region REGION FLAGS...
Where REGION is one of the regions listed above.
In the above example, FLAGS... refers to other
arguments that you pass during deployment of your function. For a complete
reference for the deploy command, see
gcloud functions deploy.
Console
If you are using the Cloud Console, you can select the region when you create and deploy a function.
In the 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.
Click Create Function.
Expand the More menu.
Under Region, select your region.
Setting a default region
You can set a default region using the gcloud command-line tool 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 background functions. For background 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.
Background functions
Background 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.