Facturation API Google Cloud : qui paie vos appels ?

Google Cloud facture la plupart des dépenses cloud à des projets. Mais à quel projet ?

La réponse est simple pour un service basé sur des Ressources comme Google Compute Engine : les frais sont imputés au projet qui contient la Ressource, par exemple une VM.

En revanche, lorsque vous appelez l'API d'un service Google Cloud comme Vision, Translate ou BigQuery, le modèle de facturation est plus souple. Tout ou partie des frais sont rattachés à un projet Client que vous spécifiez, ce qui permet d'imputer les coûts à différentes unités métier ou à différents projets.

Cet article vous explique :

Ce que désigne le projet Client et comment le spécifier.
Les principaux schémas de rattachement de la facturation à un projet, selon les types de services.
Pourquoi la documentation Google emploie presque exclusivement l'expression quota project lorsqu'elle parle de facturation, et le lien avec le billing project.
Comment identifier, pour un appel d'API donné, le projet qui a été facturé.
Comment relever le défi de l'imputation des coûts à des catégories métier.

Définir le Quota/Billing Project

Lorsqu'un appel d'API atteint l'infrastructure Google Cloud, celle-ci évalue la hiérarchie suivante pour déterminer le projet Client, qui sert également à la facturation pour les services non basés sur des Ressources. (Je détaille les notions de quota project et de billing project plus bas.)

L'évaluation est effectuée par le Service Infrastructure/Service Control de Google, qui assure un comportement unifié entre les services gérés par Google.
Permissions : pour autoriser la désignation d'un projet comme Client, le principal qui effectue l'appel — Service Account, utilisateur, Workforce Identity Federation ou Workload Identity Federation — doit disposer du rôle Service Usage Consumer sur ce projet. (Peu importe que le Service Account soit défini dans ce projet ou dans un autre.)
Cela s'applique aux services Google Cloud Platform, mais pas nécessairement aux autres services Google comme Workspace ou Maps.
Vous spécifiez le projet Client à l'aide des techniques suivantes, par ordre de priorité.

Comment spécifier le Client

1. Spécifié dans la requête

En-tête HTTP : l'en-tête HTTP X-goog-user-project peut être transmis directement dans la requête. Utile pour les appels REST bruts, par exemple avec curl.
Configuration de la bibliothèque cliente : le projet défini via les options client dans les SDK Google Cloud. Voici un exemple avec la bibliothèque cliente Python Google Cloud.

from google.cloud import translate_v3
from google.api_core.client_options import ClientOptions
# 1. Define the billing project
options = ClientOptions(quota_project_id="your-billing-project-id")
# 2. Inject it when creating the client
client = translate_v3.TranslationServiceClient(client_options=options)

2. Variable d'environnement

La valeur de la variable d'environnement GOOGLE_CLOUD_QUOTA_PROJECT. Définir cette valeur est une bonne pratique pour fixer dynamiquement le quota project dans les environnements conteneurisés sans le coder en dur via ClientOptions.

3. Clé API

Le projet dans lequel a été générée la clé API utilisée pour l'appel.

4. ADC Quota Project

Pour l'environnement local (généralement en développement), ce paramètre se définit avec gcloud auth application-default set-quota-project.

Le piège du développement local : Si vous lancez gcloud auth application-default login sans définir de projet Client pour le quota et la facturation, vos scripts locaux s'authentifieront auprès de la plupart des API avec un projet spécial et limité (le Cloud SDK project 764086051850). Comme ce projet est partagé à l'échelle mondiale, l'usage est fortement bridé et les erreurs "Quota exceeded for project 764086051850" apparaissent presque immédiatement. On évite cela en définissant la valeur Client.

5. Jeton d'authentification

Service Account : le projet propriétaire du Service Account qui effectue la requête (y compris pour les Service Accounts impersonnés).
OAuth Client ID : le projet propriétaire du Client ID OAuth 2.0 utilisé pour générer le jeton de l'utilisateur final.

6. Workforce Identity Federation

Si le principal de l'API est un utilisateur Workforce Identity Federation, c'est le projet utilisateur du workforce pool qui est utilisé.

Pourquoi Google parle-t-il de Quota project et non de Billing project ?

La documentation et les paramètres de Google Cloud emploient majoritairement le terme quota project, tandis que billing project est rarement utilisé.

Il existe des exceptions. Par exemple, la documentation gcloud utilise de façon assez déroutante les deux termes côte à côte, alors qu'il s'agit du même paramètre : billing/quota_project pour la configuration persistante de l'outil et --billing-project pour le flag en ligne de commande.

Voici l'explication. Dans Google Cloud, les paramètres Client ne font qu'une chose au niveau de l'infrastructure : ils définissent le projet de quota utilisé par la passerelle d'API, tandis que la facturation est imputée au projet de la Ressource. Toutefois, pour les services non basés sur des Ressources, le système de facturation ne trouve aucune Ressource côté serveur à facturer ; la facturation se rabat alors par défaut sur le quota project.

Services basés sur des Ressources ou non

La principale différence se situe entre les services facturés à la Ressource et les autres. Commençons par un récapitulatif :

Type de service	Élément déclencheur de la facturation	Élément déclencheur du quota	Exemples
Basé sur des Ressources	Projet contenant la ressource	Projet Client	Compute Engine, Spanner, Cloud Run
Basé sur le Client	Projet Client (Quota)	Projet Client	Vision API, Translate API

API basées sur des Ressources : un projet identifiable côté serveur

Il s'agit des API d'infrastructure, de stockage et de calcul de Google. Elles sont avec état. Lorsque vous les appelez, vous demandez à Google de lire, de modifier ou de supprimer un actif ou des données spécifiques qui résident dans un projet. Le projet de facturation est celui où se trouve la Ressource, et il est généralement spécifié dans l'URL. À l'inverse, le quota project est déterminé par le paramétrage du Client.

Il existe quelques cas particuliers comme Cloud Storage, Pub/Sub et BigQuery, détaillés ci-dessous.

Quelques exemples :

Compute Engine API : gestion des machines virtuelles, des disques et des réseaux. GET https://compute.googleapis.com/compute/v1/projects/{project}/zones/{zone}/instances
Cloud Spanner API : interrogation ou gestion de bases de données relationnelles. POST https://spanner.googleapis.com/v1/projects/{project}/instances/{instance}/databases/{database}/sessions
Cloud Run est serverless, mais c'est vous qui pilotez le service Cloud Run, pas Google ; la facturation est donc basée sur les Ressources. L'URL du service Cloud Run ne comporte pas de projet et n'est pas hébergée sur le domaine googleapis.com.

Quota et facturation basés sur le Client : pas de Ressource côté serveur

Pour les API sans état, qui se résument à un algorithme partagé à l'échelle mondiale, il n'existe aucune Ressource dans aucun projet et aucun serveur n'apparaît dans l'URL REST. La facturation est alors déterminée par le paramétrage du Client.

Quelques exemples :

Cloud Natural Language API : vous lui transmettez un paragraphe, elle renvoie une analyse de sentiment. POST https://language.googleapis.com/v1/documents:analyzeSentiment
Cloud Video Intelligence API : vous lui transmettez une vidéo, elle renvoie des étiquettes désignant les objets qu'elle contient. POST https://videointelligence.googleapis.com/v1/videos:annotate

Cloud Storage : l'option Requester Pays

Cloud Storage est un service basé sur les Ressources, même si l'URL ne contient pas d'identifiant de projet sous cette forme : GET https://storage.googleapis.com/storage/v1/b/{bucket}/o/{object}

Il possède malgré tout un projet côté serveur, identifié par la passerelle d'API à partir du nom du bucket.

Comme pour les autres API basées sur les Ressources, la facturation est attribuée au projet du bucket, tandis que le quota est attribué au Client spécifié.

Ce comportement peut toutefois être modifié via l'option Requester Pays, propre à Cloud Storage. Lorsque le propriétaire du bucket active Requester Pays, l'appelant de l'API doit fournir un projet facturable (via les paramètres Client mentionnés plus haut), et c'est ce projet qui est facturé pour les opérations d'API et l'egress (le propriétaire du bucket continuant à payer le stockage).

BigQuery : deux types de Ressources distincts

BigQuery a la particularité de permettre au stockage et au calcul de résider dans des projets différents.

Le stockage est facturé au projet propriétaire de la Ressource : le dataset contenant les données stockées.
Le traitement des requêtes est facturé au projet où s'exécute le job. Bien qu'un job soit un type de calcul, il est traité comme une Ressource distincte et avec état. Il est facturé à son projet, qui peut différer du projet de stockage et du projet d'où le job a été initié.

Pub/Sub : Topics et Subscriptions peuvent résider dans des projets différents

Comme pour les autres services basés sur les Ressources, les coûts de Pub/Sub sont liés à la propriété de la Ressource, indépendamment de l'auteur de l'appel d'API, et les paramètres Client servent uniquement au calcul des quotas.

Pub/Sub se distingue toutefois en ce que les Ressources elles-mêmes peuvent être réparties entre plusieurs projets :

Le Topic est la Ressource qui détermine la facturation pour la publication de messages.
Une subscription Pub/Sub est sa propre Ressource, qui peut être créée dans un projet distinct de celui du Topic ou du Client appelant. Elle détermine la facturation du débit de livraison, du transfert de données (egress) et du stockage au niveau de la subscription.

Identifier le projet facturé pour un appel de service

Voici quelques moyens d'identifier le projet facturé pour un appel donné. Il n'existe pas de champ standard billed_project dans les logs des API Google Cloud, mais l'information peut généralement être retrouvée.

Prérequis : pour suivre les appels d'API, vous devez d'abord activer les Data Access Audit logs pour l'API concernée (par exemple Cloud Storage, BigQuery) dans le projet que vous soupçonnez d'être facturé. Cela se fait dans la console Google Cloud sous IAM & Admin -> Audit Logs.

Pour les services Google Cloud en général

Filtrez les logs sur le service concerné :

logName=~"cloudaudit.googleapis.com"
protoPayload.serviceName="[SERVICE_NAME].googleapis.com"

Éventuellement par méthode, par exemple :

logName=~"cloudaudit.googleapis.com/data_access"
protoPayload.serviceName="vision.googleapis.com"
protoPayload.methodName="google.cloud.vision.v1.ImageAnnotator.AnnotateImage"

Repérez le champ resource.labels.project_id dans l'entrée du log. Ce champ identifie le projet facturé, qu'il s'agisse du projet basé sur la Ressource ou du projet basé sur le Client. (L'exception concerne les buckets Cloud Storage en Requester Pays.) Cette information reste visible même lorsque vous consultez un mélange de données issues de plusieurs projets via un Log Sink multi-projets.

Pour les jobs de calcul BigQuery

Comme BigQuery sépare le calcul du stockage, vous devez consulter spécifiquement les logs d'exécution du calcul, et non ceux du stockage. Exécutez la requête suivante dans Logs Explorer et, comme pour les autres services Google, repérez le champ resource.labels.project_id.

resource.type="bigquery_project"
protoPayload.methodName=("google.cloud.bigquery.v2.JobService.InsertJob" OR "google.cloud.bigquery.v2.JobService.Query")
protoPayload.metadata."@type"="type.googleapis.com/google.cloud.audit.BigQueryAuditMetadata"

Pour GCS Requester Pays

Pour les buckets Cloud Storage en Requester Pays, les audit logs indiquent le numéro du projet facturé (en hexadécimal) sous protoPayload.authorizationInfo.resource, à la suite de projects/, par exemple projects/0000004d9813b13.

La solution pour l'imputation des coûts

Une fois que vous savez faire remonter ces logs de facturation, le défi suivant consiste à les rapprocher de votre activité : par exemple à des départements ou à des projets métier précis.

Mon rôle d'Architecte Cloud chez DoiT International consiste à conseiller les clients sur l'optimisation de leurs coûts, et DoiT propose dans DoiT Cloud Intelligence une suite d'outils puissants pour y parvenir. Par exemple, DoiT Cost Allocation regroupe et impute les coûts par dimension métier.

Certains services prennent en charge des labels qui facilitent l'imputation des coûts :

Pour les services basés sur les Ressources, vous pouvez allouer par Ressource et, éventuellement, ajouter des labels à la Ressource pour les faire correspondre à vos catégories métier.
Cas exceptionnel : l'appel d'API de nombreux modèles Generative AI peut recevoir des labels de coût personnalisés, utilisables pour l'imputation.
Les pipelines Vertex AI offrent par ailleurs une fonctionnalité d'imputation des coûts inédite. Le Pipeline lui-même représente un coût modeste, mais surtout il peut générer plusieurs types de ressources. Vertex AI attache automatiquement le label vertex-ai-pipelines-run-billing-id à chaque Ressource ainsi générée, ce qui aide à imputer les coûts à l'exécution du Pipeline dans son ensemble.

En revanche, pour la plupart des services non basés sur des Ressources, les données de coût GCP ne sont pas étiquetées par utilisateur ni par d'autres informations qui permettraient de distinguer les catégories métier.

Voici une solution : créez plusieurs projets pour servir de Client. Les organisations Google Cloud utilisent couramment de nombreux projets, organisés en folders. Ces projets peuvent ensuite être désignés comme Client pour répartir les coûts par catégorie métier. Les projets peuvent par ailleurs rester vides, et vous n'êtes pas obligé d'exécuter le code client dans le projet de facturation : ce qui compte, c'est le projet Client associé à l'appel. Les projets eux-mêmes font alors office de label désignant l'unité métier.