Cloud Functions locations

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 products and services that your app uses. Using services across multiple regions can affect your app's latency, as well as pricing.

Cloud Functions is available in the following regions:

  • us-central1 (Iowa)
  • us-east1 (South Carolina)
  • europe-west1 (Belgium)
  • asia-northeast1 (Tokyo)

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

Best Practices for Changing Region

By default, functions run in the us-central1 region. Note that this may be different from the region of an event source, such as a Storage bucket. If you need to change the region where a function runs, follow the recommendations in this section.

To set the region where a function runs, set the region parameter in the function definition as shown:

exports.myStorageFunction = functions
    .region('europe-west1')
    .storage
    .object()
    .onFinalize((object) => {
      // ...
    });

See change a function's region for more information on recommended procedures.

HTTP and Client Callable Functions

For HTTP and callable functions, we recommend that you first set your function to the destination region, or closest to where most expected customers are located, and then alter your original function to redirect its HTTP request to the new function (they can have the same name). 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.

Client-side location selection for callable functions

Regarding the callable function, client callable setups should follow the same guidelines as HTTP functions. The client can also specify a region, and must do so if the function runs in any region other than us-central1.

To set regions on the client, specify the desired region at initialization:

Swift

lazy var functions = Functions.functions(region:"us-central1")

Objective-C

@property(strong, nonatomic) FIRFunctions *functions;
// ...
self.functions = [FIRFunctions functionsWithRegion:@"us-central1"];

Web


var functions = firebase.app().functions('us-central1');

Android

private FirebaseFunctions mFunctions;
// ...
mFunctions = FirebaseFunctions.getInstance("us-central1");

C++

firebase::functions::Functions* functions;
// ...
functions = firebase::functions::Functions::GetInstance("us-central1");

Unity

firebase.Functions.FirebaseFunctions functions;

functions = Firebase.Functions.FirebaseFunctions.GetInstance("us-central1");

Background Functions

Background functions adopt an at-least-once event delivery semantic, which means that under some circumstances they may receive duplicate events, and so should always be implemented to be idempotent. If your function is already idempotent then you can redeploy the function in the new region with the same event trigger, and remove the old function once you have verified that the new function is correctly receiving traffic. During this transition both functions will receive events. See change a function's region for the recommended sequence of commands to change regions for functions.

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.

Optimal region recommendations differ by event trigger type:

Trigger Type Region Recommendation
Firestore Closest to where the Firestore instance is (see next section)
Realtime Database Always us-central1.
Storage Closest to where the storage bucket is (see next section)
Others If you are interacting with Realtime Database, a Firestore instance, or a storage bucket inside of the function, then the recommended region is the same as if you had a function triggered by one of those resources. Otherwise, use the default region of us-central1.

Selecting regions for Firestore and Storage

Regions for functions do not match precisely with the regions available for Firebase projects. If you specified a region while creating your Firebase project, then that is the same region that your Firestore instance is created in, and is also the default region for Cloud Storage buckets. Here's a mapping of the closest function region for Firestore and storage-triggered functions:

Firestore/Storage region/multi-region Nearest Functions region
us-central multi-region us-central1
us-east1 (South Carolina) us-east1
us-east4 (Northern Virginia) us-east1
northamerica-northeast1 (Montreal) us-central1
europe-west multi-region europe-west1
europe-west2 (London) europe-west1
europe-west3 (Frankfurt) europe-west1
asia-northeast1 (Tokyo) asia-northeast1
asia-south1 (Mumbai) asia-northeast1
australia-southeast1 (Sydney) asia-northeast1
southamerica-east1 (Sao Paulo) us-east1

Оставить отзыв о...

Текущей странице
Нужна помощь? Обратитесь в службу поддержки.