Cloud Functions is
regional
, which means the infrastructure that runs your
function is located in specific regions and is managed by Google to be
redundantly available across
all the zones within those regions
.
When selecting what regions to run your functions in, your primary
considerations should be latency and availability. You can
generally select regions close to your 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
.
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 Cloud Storage bucket.
Learn how to
specify the region where a function runs
later in this page.
Supported regions
In the lists in this section, the
energy_savings_leaf
icon indicates that the electricity for this region is produced with
low carbon emissions. For more information, see
Carbon free energy for Google Cloud regions
.
Cloud Functions is available in the following regions with
Tier 1 pricing
:
asia-east1
(Taiwan)
asia-east2
(Hong Kong) 1st gen only
asia-northeast1
(Tokyo)
asia-northeast2
(Osaka)
europe-north1
(Finland)
energy_savings_leaf
2nd gen only
europe-west1
(Belgium)
energy_savings_leaf
europe-west2
(London) 1st gen only
us-central1
(Iowa)
energy_savings_leaf
us-east1
(South Carolina)
us-east4
(Northern Virginia)
us-west1
(Oregon)
energy_savings_leaf
Cloud Functions is available in the following regions with
Tier 2 pricing
:
asia-east2
(Hong Kong) 2nd gen only
asia-northeast3
(Seoul)
asia-southeast1
(Singapore)
asia-southeast2
(Jakarta)
asia-south1
(Mumbai) 2nd gen only
australia-southeast1
(Sydney)
australia-southeast2
(Melbourne) 2nd gen only
europe-central2
(Warsaw)
europe-west2
(London) 2nd gen only
europe-west3
(Frankfurt)
europe-west6
(Zurich)
energy_savings_leaf
northamerica-northeast1
(Montreal)
energy_savings_leaf
northamerica-northeast2
(Toronto)
energy_savings_leaf
2nd gen only
southamerica-east1
(Sao Paulo)
energy_savings_leaf
southamerica-west1
(Santiago, Chile) 2nd gen only
us-west2
(Los Angeles)
us-west3
(Salt Lake City)
us-west4
(Las Vegas)
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 specifying a 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 Cloud Storage bucket. If
you need to specify the region where a function runs, follow the
recommendations in this section for each function trigger type.
To set the region where a function runs, set the
region
parameter in the
function definition as shown:
Node.js
exports.firestoreAsia = onDocumentCreated(
{
document: "my-collection/{docId}",
region: "asia-northeast1",
},
(event) => {},
);
Python
# Before
@firestore_fn.on_document_created("my-collection/{docId}")
def firestore_trigger(event):
pass
# After
@firestore_fn.on_document_created("my-collection/{docId}",
region="asia-northeast1")
def firestore_trigger_asia(event):
pass
You can specify multiple regions by passing multiple comma-separated region
strings in
region
. Also note that, when specifying a region for many
background trigger types, you'll need to specify the correct event filter
along with the region. In the example above, this is the Cloud Firestore
document
that emits the event. For a Cloud Storage trigger the event filter
could be
bucket
; for a Pub/Sub trigger it would be
topic
, and so on.
See
change a function's region
for more information on changing the region for a function that's handling
production traffic.
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:"europe-west1")
Objective-C
@property(strong, nonatomic) FIRFunctions *functions;
// ...
self.functions = [FIRFunctions functionsWithRegion:@"europe-west1"];
Web
var functions = firebase.app().functions('europe-west1');
Android
private FirebaseFunctions mFunctions;
// ...
mFunctions = FirebaseFunctions.getInstance("europe-west1");
C++
firebase::functions::Functions* functions;
// ...
functions = firebase::functions::Functions::GetInstance("europe-west1");
Unity
firebase.Functions.FirebaseFunctions functions;
functions = Firebase.Functions.FirebaseFunctions.GetInstance("europe-west1");
Background functions
Background functions adopt an at-least-once event delivery semantic, which means
that under some circumstances they may receive duplicate events. So, you should
implement functions 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 after you verify 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
|
Cloud Firestore
|
Closest region to the Cloud Firestore instance location (see next section)
|
Realtime Database
|
Always
us-central1
|
Cloud Storage
|
Closest region to the Cloud Storage bucket location (see next section)
|
Others
|
If you are interacting with a Realtime Database instance, a Cloud Firestore
instance, or a Cloud 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
.
Functions connected to Firebase Hosting can be in any region, but see
the hosting serverless overview
for recommendations.
|
Selecting regions based on Cloud Firestore and Cloud Storage locations
The available regions for functions do not always match precisely with the
regions available for your Cloud Firestore database and your Cloud Storage
buckets.
Note that if your function and your resource (database instance or Cloud Storage
bucket) are in different locations, then you could potentially experience
increased latency and
billing costs
.
Here's a mapping of the closest functions-supported regions for Cloud Firestore
and Cloud Storage, for cases where the same region is
not
supported:
Region/Multi-region for Cloud Firestore and Cloud Storage
|
Nearest region for functions
|
nam5
or
us-central
(multi-region)
|
us-central1
|
eur3
or
europe-west
(multi-region)
|
europe-west1
|
europe-west4
(Netherlands)
|
europe-west1
|
asia-south1
(Mumbai)
|
asia-east2
|
asia-south2
(Delhi)
|
asia-east2
|
australia-southeast2
(Melbourne)
|
australia-southeast1
|