Pour simplifier les recherches et améliorer votre expérience avec la documentation, nous divisons les documentations consacrées à la 1re génération et à la 2e génération en ensembles distincts.

Emplacements de Cloud Functions

Les fonctions Cloud Functions sont régionales. Cela signifie que l'infrastructure qui exécute votre fonction Cloud Functions se situe dans une région spécifique et est gérée par Google, qui veille à ce qu'elle soit disponible de manière redondante dans toutes les zones de cette région.

Au moment de sélectionner la région dans laquelle vos fonctions Cloud Functions vont s'exécuter, vos principales considérations doivent être la latence et la disponibilité. En règle générale, vous pouvez sélectionner la région la plus proche des utilisateurs de votre fonction Cloud, mais vous devez également tenir compte de l'emplacement des autres produits et services Google Cloud exploités par votre application. L'utilisation de services dans plusieurs zones peut avoir des répercussions sur la latence de votre application, ainsi que sur les tarifs.

Les régions disponibles pour Cloud Functions sont répertoriées ci-dessous. Les différentes versions de Cloud Functions ont une disponibilité régionale différente. Consultez la colonne "Versions de produit compatibles" des tableaux.

Tarifs de niveau 1

Cloud Functions est disponible dans les régions suivantes avec des tarifs de niveau 1 :

Une région	Emplacement	Versions de produit compatibles	Émissions de CO_₂
`asia-east1`	Taïwan	1st gen, 2nd gen
`asia-east2`	Hong Kong	1re génération
`asia-northeast1`	Tokyo	1st gen, 2nd gen
`asia-northeast2`	Osaka	1st gen, 2nd gen
`europe-north1`	Finlande	2e génération	Faibles émissions de CO₂
`europe-southwest1`	Madrid	2e génération
`europe-west1`	Belgique	1st gen, 2nd gen	Faibles émissions de CO₂
`europe-west2`	Londres	1re génération
`europe-west4`	Pays-Bas	2e génération
`europe-west8`	Milan	2e génération
`europe-west9`	Paris	2e génération	Faibles émissions de CO₂
`me-west1`	Tel Aviv	2e génération
`us-central1`	Iowa	1st gen, 2nd gen	Faibles émissions de CO₂
`us-east1`	South Carolina	1st gen, 2nd gen
`us-east4`	Virginie du Nord	1st gen, 2nd gen
`us-east5`	Columbus	2e génération
`us-south1`	Dallas	2e génération
`us-west1`	Oregon	1st gen, 2nd gen	Faibles émissions de CO₂

Tarifs de niveau 2

Cloud Functions est disponible dans les régions suivantes avec des tarifs de niveau 2 :

Une région	Emplacement	Versions de produit compatibles	Émissions de CO_₂
`asia-east2`	Hong Kong	2e génération
`asia-northeast3`	Séoul	1st gen, 2nd gen
`asia-southeast1`	Singapour	1st gen, 2nd gen
`asia-southeast2`	Jakarta	1st gen, 2nd gen
`asia-south1`	Mumbai	1st gen, 2nd gen
`asia-south2`	Delhi, Inde	2e génération
`australia-southeast1`	Sydney	1st gen, 2nd gen
`australia-southeast2`	Melbourne	2e génération
`europe-central2`	Varsovie	1st gen, 2nd gen
`europe-west2`	Londres	2e génération
`europe-west3`	Francfort	1st gen, 2nd gen	Faibles émissions de CO₂
`europe-west6`	Zurich	1st gen, 2nd gen	Faibles émissions de CO₂
`europe-west10`	Berlin	2e génération
`europe-west12`	Turin	2e génération
`me-central1`	Doha	2e génération
`me-central2`	Dammam	2e génération
`northamerica-northeast1`	Montréal	1st gen, 2nd gen	Faibles émissions de CO₂
`northamerica-northeast2`	Toronto	2e génération	Faibles émissions de CO₂
`southamerica-east1`	São Paulo	1st gen, 2nd gen	Faibles émissions de CO₂
`southamerica-west1`	Santiago, Chili	2e génération
`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

Sélectionner la région

Vous pouvez sélectionner une région pour votre fonction lors du déploiement.

gcloud

Si vous utilisez Google Cloud CLI, vous pouvez spécifier la région à l'aide de l'option --region :

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

Où REGION est l'une des régions répertoriées ci-dessus.

Console

Si vous utilisez la console Google Cloud, vous pouvez sélectionner la région lorsque vous créez et déployez une fonction.

Dans la console Google Cloud, accédez à la page de présentation de Cloud Functions.

Accéder à la page Présentation de Cloud Functions

Vérifiez que le projet pour lequel vous avez activé Cloud Functions est sélectionné.
Cliquez sur Create Function (Créer une fonction).
Dans le champ Région, sélectionnez une région.

Vous pouvez déployer des fonctions dans différentes régions au sein d'un projet, mais une fois la région sélectionnée pour une fonction, elle ne peut plus être modifiée.

Les fonctions dans une région donnée au sein d'un projet donné doivent porter des noms uniques (non sensibles à la casse). En revanche, les fonctions interrégionales ou sur plusieurs projets peuvent partager le même nom.

Définir une région par défaut

Vous pouvez définir une région par défaut à l'aide de Google Cloud CLI comme suit :

gcloud config set functions/region REGION

Exemple :

gcloud config set functions/region europe-west1

Résidence des données

Cloud Functions garantit la résidence des données lors de l'exécution de la fonction (conformité du champ d'application A : exécution de la fonction) dans laquelle une fonction donnée fournit une résidence des données pour l'appel/l'exécution de la fonction.

Cette conformité s'applique à la fois aux fonctions HTTP et aux fonctions basées sur des événements. Pour les fonctions basées sur des événements, Cloud Functions est conforme à la résidence des données à partir du moment où le produit en amont (produit de déclenchement) diffuse l'événement dans Cloud Functions. Par conséquent, il est important de s'assurer que le produit en amont (tel que Cloud Storage ou Pub/Sub) est lui-même conforme à la résidence des données.

Bonnes pratiques pour modifier la région

Si vous devez modifier la région dans laquelle une fonction est déployée, suivez les recommandations ci-dessous.

Fonctions HTTP

Pour les fonctions HTTP, nous vous recommandons de commencer par redéployer votre fonction HTTP dans la région de destination (elle peut avoir le même nom), puis de modifier votre fonction d'origine pour rediriger sa requête HTTP vers la nouvelle fonction. Si les clients de votre fonction HTTP sont compatibles avec les redirections, vous pouvez simplement modifier votre fonction d'origine pour qu'elle renvoie un état de redirection HTTP (301) avec l'URL de votre nouvelle fonction. Si vos clients ne gèrent pas les redirections correctement, vous pouvez transférer la requête de la fonction d'origine vers la nouvelle fonction en envoyant une nouvelle requête de la fonction d'origine à la nouvelle fonction. La dernière étape consiste à vérifier que tous les clients appellent bien la nouvelle fonction.

Fonctions basées sur les événements

Les fonctions basées sur les événements adoptent la sémantique de diffusion d'événements "au moins une fois" : cela signifie que dans certaines circonstances, elles peuvent recevoir des événements dupliqués. Ces fonctions doivent donc toujours être mises en œuvre pour être idempotentes. Si votre fonction est déjà idempotente, vous pouvez simplement la redéployer dans la nouvelle région avec le même déclencheur d'événements et supprimer l'ancienne fonction après avoir vérifié que la nouvelle reçoit correctement le trafic. Pendant cette transition, les deux fonctions recevront des événements.

Si votre fonction n'est pas idempotente pour le moment ou si son idempotence ne s'étend pas au-delà de la région, nous vous conseillons de commencer par implémenter l'idempotence avant de déplacer la fonction.