Google Cloud : déployer un service Cloud Run avec authentification
Google Cloud fournit à la demande des services de calcul, de stockage, de bases de données et de réseau. Vous pouvez louer une machine virtuelle ou confier une application à la plateforme, qui démarre les instances et prend en charge les requêtes. Inutile de mémoriser le catalogue pour commencer : il faut d'abord savoir où se trouvent les ressources, qui peut les utiliser et qui paie.
Ce guide suit une petite application HTTP Python qui renvoie du JSON : exécution locale, déploiement sur Cloud Run avec authentification, mise à jour, retour à une révision précédente et nettoyage. Elle ne nécessite ni base de données, ni cluster Kubernetes, ni clé de compte de service.
Les étapes locales n'appellent pas Google Cloud. L'installation des outils et le téléchargement de Python, des dépendances ou des images de conteneur peuvent toutefois nécessiter un accès réseau. Les commandes cloud sont des instructions à exécuter seulement si vous souhaitez poursuivre : elles connectent un compte, téléversent le code, modifient des ressources et peuvent entraîner des frais. Pour comprendre le fonctionnement sans déployer, arrêtez-vous après le test local.
1. Comprendre les projets, les emplacements et les autorisations
À quel projet appartient la ressource ?
La hiérarchie administrative de Google Cloud comprend une organisation, des dossiers facultatifs, des projets et leurs ressources. Une organisation représente généralement une entreprise ou un établissement ; les dossiers servent à regrouper les ressources et à déléguer leur administration. Les autorisations IAM et les règles d'organisation des niveaux supérieurs s'appliquent aux descendants : un projet n'est donc pas automatiquement isolé des règles de l'entreprise. Un exercice personnel ne nécessite pas de créer une organisation ou un dossier. Voir la documentation sur la hiérarchie des ressources.
Un projet regroupe des ressources, des paramètres, des autorisations et des métadonnées. Distinguez ces identifiants :
Le compte de facturation détermine qui paie, pas qui peut appeler une API. Une API est une interface permettant à un programme d'utiliser un service cloud. L'activer dans un projet rend ce service disponible, sans autoriser n'importe quel appelant à l'utiliser.
Où la ressource s'exécute-t-elle ?
Une région est un emplacement géographique de déploiement ; une zone est une subdivision d'une région. Une machine virtuelle Compute Engine nécessite généralement le choix d'une zone, tandis que ce service Cloud Run utilise une région. La portée géographique dépend du produit, sans règle universelle. Voir la présentation de Google Cloud.
Choisissez REGION en fonction des utilisateurs, des exigences de résidence des données, des services associés, de la disponibilité des produits et des tarifs régionaux. Une base de données dans une autre région peut ajouter de la latence et des frais de transfert. Ne supposez pas que tous les produits existent dans toutes les régions.
Qui agit ?
Identity and Access Management (IAM), la gestion des identités et des accès, répond à la question « qui peut faire quoi sur quelle ressource ? ». Un principal peut être une personne, un groupe, un compte de service ou une identité fédérée. Un rôle regroupe des autorisations ; son attribution s'applique à un périmètre, par exemple un projet ou un service précis. Une attribution au niveau du projet touche généralement davantage de ressources qu'une attribution sur un seul service.
Un compte de service est une identité d'application, pas un serveur ni un fichier JSON qu'il faudrait télécharger. Une personne déploie, un système de construction produit une image, puis l'application s'exécute : ces tâches ont des besoins d'autorisation différents. Privilégiez les rôles prédéfinis adaptés à la tâche plutôt que Owner ou Editor comme solution de dépannage. Voir l'identité de service Cloud Run.
2. Choisir les services de calcul et de données
Choisissez le calcul selon les opérations que vous devez maîtriser. Le tableau donne des points de départ, pas une comparaison exhaustive ; les catégories sont décrites dans la présentation de Google Cloud.
Une image de conteneur regroupe l'application et ses dépendances d'exécution. Une instance est l'environnement en cours d'exécution démarré depuis cette image. « Sans état » signifie qu'une requête ne dépend pas de fichiers ou de données en mémoire laissés sur une instance particulière. Cette application renvoie un contenu fixe, adapté à Cloud Run.
Choisissez les services de données selon leur modèle plutôt que de considérer tous les stockages comme interchangeables :
Ce tutoriel n'ajoute pas de base de données. Faites d'abord fonctionner le déploiement et les identités, puis choisissez un produit selon un besoin réel.
3. Séparer connexion CLI, identifiants applicatifs et identité d'exécution
Une interface en ligne de commande (CLI) permet d'utiliser un logiciel en saisissant des commandes ; gcloud est celle de Google Cloud. L'authentification établit qui vous êtes ; les autorisations IAM déterminent ce que vous pouvez faire. Une connexion réussie ne donne pas le droit de déployer. La documentation des identifiants par défaut des applications (ADC) distingue les identifiants de la CLI de ceux des applications.
ADC définit comment les bibliothèques trouvent leurs identifiants : configuration d'environnement correspondante, identifiants ADC locaux, puis identifiants du compte de service associé. Une connexion ADC locale ne change pas le compte actif de la CLI ; gcloud auth login ne configure pas automatiquement les identifiants de toutes les applications locales.
Workload Identity Federation, la fédération d'identité des charges de travail, permet à un programme externe d'échanger une identité issue d'un fournisseur de confiance contre des identifiants de courte durée. Il peut ensuite accéder aux ressources autorisées ou emprunter l'identité d'un compte de service autorisé. Cette méthode réduit la gestion et les risques d'exposition des clés de longue durée. Workforce Identity Federation, destiné aux personnes, est un autre mécanisme.
Ne placez pas de fichiers JSON d'authentification, de jetons ou de clés privées de compte de service dans le code, les images ou les journaux. Cet exercice ne demande ni création ni téléchargement de clé de compte de service.
4. Créer et tester l'application localement
Préparer les outils et un dossier dédié
Utilisez Python 3.12 déjà installé, uv et curl. Les commandes emploient la syntaxe Bash/zsh ; sous Windows, utilisez un environnement adapté tel que WSL, sans les coller telles quelles dans PowerShell. Pour les environnements, fichiers de verrouillage et commandes d'exécution, voir les environnements Python avec uv.
Commencez dans un nouveau dossier vide pour éviter de téléverser ensuite un projet privé existant :
mkdir cloud-run-hello
cd cloud-run-hello
uv init --bare --python 3.12
uv add 'flask~=3.0' 'gunicorn~=23.0'
Flask gère les routes HTTP. Gunicorn est le serveur qui reçoit les requêtes et exécute l'application Python. Les contraintes de dépendances suivent le démarrage rapide Python de Google, sans prétendre désigner les dernières versions. Conservez pyproject.toml et uv.lock ; uv gère .venv, et le fichier de verrouillage enregistre les versions effectivement résolues.
Créez main.py :
from flask import Flask
app = Flask(__name__)
@app.get("/")
def hello():
return {"message": "Hello from Cloud Run", "version": "v1"}, 200
Dans un premier terminal, lancez :
uv run gunicorn --bind 127.0.0.1:8080 main:app
main:app désigne l'objet app du fichier main.py. Dans un second terminal :
curl --fail --silent --show-error http://127.0.0.1:8080/
Le résultat attendu est HTTP 200 avec du JSON contenant message et "version":"v1" ; l'espacement et l'ordre des clés n'importent pas. Si la connexion est refusée, vérifiez que le serveur tourne toujours dans le premier terminal et utilise le bon port. Cette requête reste sur votre machine et ne nécessite aucun compte cloud. Arrêtez ensuite le serveur avec Ctrl+C : le proxy utilisé plus loin occupe aussi le port 8080.
Définir explicitement la construction du conteneur
Les buildpacks détectent le langage d'une application et construisent une image de conteneur à partir de ses sources. Ici, créez un Dockerfile pour que Cloud Build utilise uv et les dépendances verrouillées, sans supposer que les buildpacks reconnaissent un projet uv :
FROM python:3.12-slim-trixie
COPY --from=ghcr.io/astral-sh/uv:0.12.13 /uv /uvx /bin/
WORKDIR /app
ENV UV_NO_DEV=1
COPY pyproject.toml uv.lock main.py ./
RUN uv sync --locked
ENV PATH="/app/.venv/bin:$PATH"
CMD ["sh", "-c", "exec gunicorn --bind 0.0.0.0:${PORT:-8080} main:app"]
Ces étiquettes d'image proviennent des exemples d'intégration Docker de uv ; elles ne sont pas présentées comme les dernières versions. Une étiquette peut être réaffectée. Pour une meilleure reproductibilité en production, vérifiez puis fixez les empreintes des images. uv sync --locked contrôle la cohérence du verrouillage avec le projet au lieu de le réécrire discrètement pendant la construction. Ce projet simple ne déclare pas de moteur de création de paquet Python.
Le contrat d'exécution Cloud Run impose au processus d'entrée d'écouter sur 0.0.0.0 et sur le PORT fourni par la plateforme. Ne reprenez pas l'adresse 127.0.0.1 du test local dans le conteneur cloud. TLS, le protocole qui chiffre les connexions HTTPS, se termine hors du conteneur : aucun certificat n'est nécessaire dans l'application. exec transmet les signaux d'arrêt à Gunicorn.
Le système de fichiers inscriptible du conteneur consomme la mémoire de l'instance et n'est pas persistant. Ne comptez pas sur la conservation des fichiers après son arrêt ; placez les fichiers téléversés dans un stockage persistant adapté. Un nombre minimal d'instances ne transforme pas un répertoire local en disque durable. En cas d'échec au démarrage, vérifiez d'abord l'installation de Gunicorn et l'adresse et le port d'écoute, puis les journaux de démarrage.
Créez .dockerignore et .gcloudignore, avec ce même contenu dans chacun :
.git/
.venv/
__pycache__/
*.pyc
.env
.env.*
*.pem
*.key
*credentials*.json
*service-account*.json
.gcloudignore contrôle le téléversement du code source ; .dockerignore contrôle le contexte de construction Docker et ne suffit pas à empêcher un téléversement. La référence de déploiement décrit les dossiers sources et les fichiers d'exclusion. Ne gardez que les fichiers du tutoriel dans ce dossier et vérifiez leur liste avant l'envoi. Ces motifs ne prouvent pas qu'un dossier quelconque ne contient aucun secret. N'excluez pas Dockerfile, main.py, pyproject.toml ou uv.lock.
5. Décider de poursuivre ou non les étapes cloud facturables
Il faut un projet existant dédié à l'exercice, un compte de facturation associé que vous êtes autorisé à utiliser, une région adaptée et un administrateur capable d'activer les API et d'accorder les accès. Une organisation peut limiter les régions, les sources de construction, les dépôts d'images et les comptes de service. Vérifiez ses règles plutôt que de les contourner.
Configurer d'abord les notifications de coût
Dans Cloud Billing, créez un budget limité au projet du tutoriel, choisissez les seuils de notification et vérifiez les destinataires. Un budget avec alertes uniquement envoie des notifications ; il n'arrête pas automatiquement les services au montant défini.
Au 2026-09-12, Google documente aussi des budgets facultatifs avec plafond de dépenses, signalés en préversion dans la page d'entrée des budgets. Chaque budget mensuel couvre un seul projet et un seul service éligible, dont Cloud Run. Ce n'est pas un plafond exact pour l'ensemble du compte de facturation : les nouveaux usages peuvent être bloqués, mais les requêtes en cours, les délais de remontée des coûts et les ressources conservées peuvent encore entraîner des frais dus. Un plafond Cloud Run ne doit pas être supposé couvrir Cloud Build, le stockage des images ou les bases de données.
La tarification Cloud Run distingue les régions, les modes de facturation et les frais supplémentaires. Les constructions, images Artifact Registry, stockages associés, transferts sortants et ressources réseau supplémentaires peuvent être facturés séparément. L'usage gratuit est agrégé par compte de facturation, sans nouvelle allocation pour chaque projet. Ce tutoriel ne promet pas un exercice gratuit et ne dépend pas d'un crédit d'essai.
Le paramètre --min=0 utilisé plus loin permet de descendre à zéro instance, sans garantir la suppression immédiate des instances inactives ni l'absence de frais. --max=2 limite la capacité, pas un montant. Les quotas limitent certaines ressources ou certains usages ; ils ne remplacent pas les contrôles de facturation.
Installer la CLI et choisir son contexte
Suivez les instructions officielles d'installation de Google Cloud CLI adaptées au système. L'environnement Python de la CLI est distinct de l'environnement uv de l'application.
Remplacez toutes les valeurs fictives avant ces étapes cloud :
export PROJECT_ID="YOUR_PROJECT_ID"
export REGION="YOUR_SUPPORTED_REGION"
export SERVICE="tutorial-hello"
export RUNTIME_SA_NAME="tutorial-hello-runtime"
export RUNTIME_SA_EMAIL="${RUNTIME_SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com"
gcloud auth login
gcloud config set project "$PROJECT_ID"
gcloud init propose une autre méthode guidée de connexion et de configuration ; inutile d'exécuter les deux parcours. Une configuration CLI contient des valeurs par défaut, pas une frontière de sécurité. Les commandes suivantes précisent donc toujours le projet et la région. Si vous utilisez plusieurs comptes, confirmez l'identité active dans la CLI ou la console avant d'agir. Cette application n'a pas besoin de gcloud auth application-default login.
6. Faire préparer les identités et la construction par un administrateur
Le déploiement depuis les sources utilise Cloud Build pour construire une image, la stocke dans Artifact Registry, puis crée une révision Cloud Run. Une révision est une configuration de déploiement immuable du service. Les autorisations du déployeur, du compte de construction et du compte d'exécution ont des usages distincts. Voir les rôles requis pour le déploiement depuis les sources.
Les agents de service gérés par Google assurent les opérations de la plateforme. Ils ne sont ni le compte de construction ni l'identité de l'application ; ne modifiez pas leurs droits arbitrairement pour résoudre une erreur. La consultation des journaux peut nécessiter des droits de lecture supplémentaires. Les rôles minimaux de déploiement ne couvrent pas toutes les opérations d'exploitation.
Un administrateur autorisé effectue cette préparation. Ne recréez pas des ressources existantes du même nom et ne considérez pas un nom de tutoriel comme une preuve d'usage exclusif :
gcloud services enable run.googleapis.com cloudbuild.googleapis.com \
artifactregistry.googleapis.com --project "$PROJECT_ID"
gcloud iam service-accounts create "$RUNTIME_SA_NAME" \
--display-name="Tutorial hello runtime" --project "$PROJECT_ID"
Confirmez le compte de construction réellement utilisé par défaut dans les paramètres Cloud Build du projet avant de remplir BUILD_SA_EMAIL. La documentation actuelle du déploiement depuis les sources indique le compte de service Compute Engine par défaut, mais l'historique de configuration et les règles d'organisation peuvent changer ce choix. Ne devinez pas l'adresse à partir de l'âge du projet. Cet exemple utilise l'identité de construction par défaut effective ; la variable shell sert seulement à lui accorder les droits ci-dessous et ne sélectionne pas une autre identité.
export DEPLOYER_MEMBER="user:YOUR_EMAIL"
export BUILD_SA_EMAIL="YOUR_CONFIRMED_BUILD_SERVICE_ACCOUNT_EMAIL"
gcloud projects add-iam-policy-binding "$PROJECT_ID" \
--member="$DEPLOYER_MEMBER" --role=roles/run.sourceDeveloper
gcloud projects add-iam-policy-binding "$PROJECT_ID" \
--member="$DEPLOYER_MEMBER" --role=roles/serviceusage.serviceUsageConsumer
gcloud iam service-accounts add-iam-policy-binding "$RUNTIME_SA_EMAIL" \
--project "$PROJECT_ID" --member="$DEPLOYER_MEMBER" \
--role=roles/iam.serviceAccountUser
gcloud projects add-iam-policy-binding "$PROJECT_ID" \
--member="serviceAccount:${BUILD_SA_EMAIL}" --role=roles/run.builder
Notez les attributions nouvelles pour cet exercice. Les changements IAM peuvent prendre du temps à se propager ; vérifiez le principal et le périmètre avant de réessayer plutôt que d'accorder Editor. Service Account User sur l'identité d'exécution permet au déployeur d'utiliser cette identité, sans donner à l'application des droits d'administration du projet. Voir la configuration de l'identité de service.
Le déploiement depuis les sources peut créer ou réutiliser un dépôt Artifact Registry et conserver des ressources auxiliaires, notamment les sources de construction. Faites confirmer par l'administrateur que les règles de création de dépôt, de construction et de stockage autorisent ce parcours. Notez les dépôts, images et emplacements sources effectivement utilisés ; un dépôt créé automatiquement n'appartient pas nécessairement à ce seul exemple.
7. Déployer et appeler le service avec authentification
Depuis cloud-run-hello, la personne autorisée à déployer exécute :
gcloud run deploy "$SERVICE" \
--source . \
--project "$PROJECT_ID" \
--region "$REGION" \
--service-account "$RUNTIME_SA_EMAIL" \
--port 8080 \
--min=0 \
--max=2 \
--no-allow-unauthenticated \
--invoker-iam-check
Cette étape téléverse le code et lance une construction cloud potentiellement facturable. Si un Dockerfile est présent, --source l'utilise ; sinon, la construction repose sur les buildpacks Google. --min et --max sont des paramètres du service, contrairement à --min-instances et --max-instances, qui concernent les révisions. Voir la référence des paramètres de déploiement.
Les paramètres d'accès refusent l'autorisation anonyme et activent la vérification IAM des appelants. « Privé » signifie ici accès avec authentification IAM, pas adresse réseau privée ni restriction du trafic réseau entrant. Modifier explicitement les règles d'accès peut nécessiter des droits d'administration IAM du service au-delà des rôles minimaux de déploiement. Faites autoriser ou exécuter l'opération par un administrateur ; n'ouvrez pas l'accès anonyme pour contourner une erreur de permission.
Si la construction échoue, consultez les journaux de cette exécution Cloud Build et l'étape en échec. Vérifiez le verrouillage, le Dockerfile, les API, l'identité de construction effective et les droits du dépôt. L'absence de journaux applicatifs Cloud Run est normale tant que la construction n'a pas réussi. Un refus dû aux règles d'organisation nécessite aussi l'intervention d'un administrateur.
Une fois le service créé, un administrateur autorisé à modifier sa politique IAM accorde l'accès à l'appelant désigné :
gcloud run services add-iam-policy-binding "$SERVICE" \
--project "$PROJECT_ID" --region "$REGION" \
--member="$DEPLOYER_MEMBER" --role=roles/run.invoker
Avec l'identité de déploiement, lancez le proxy local Cloud Run :
gcloud run services proxy "$SERVICE" \
--project "$PROJECT_ID" --region "$REGION"
Laissez-le fonctionner et envoyez la requête depuis un autre terminal :
curl --fail --silent --show-error http://127.0.0.1:8080/
Le JSON attendu indique à nouveau v1. Malgré l'adresse localhost, cette requête traverse le proxy jusqu'à Google Cloud avec l'identité du compte actif et peut être facturée. Vérifiez que le précédent processus Gunicorn local est arrêté : un port déjà occupé ne doit pas vous faire prendre une réponse locale pour un appel cloud réussi.
En cas de 403, vérifiez le compte actif et son attribution roles/run.invoker sur ce service. Une erreur actAs pendant le déploiement concerne plutôt l'autorisation d'utiliser l'identité d'exécution. N'ajoutez pas allUsers pour dépanner. En production, les appels entre services doivent utiliser des jetons d'identité destinés au service cible, pas un proxy sur le poste d'un développeur ni des jetons copiés.
8. Consulter les journaux, mettre à jour et revenir en arrière
Consultez les journaux du service et la liste des révisions :
gcloud run services logs read "$SERVICE" \
--project "$PROJECT_ID" --region "$REGION" --limit=20
gcloud run revisions list --service "$SERVICE" \
--project "$PROJECT_ID" --region "$REGION"
Les journaux aident à distinguer les problèmes de démarrage, les exceptions applicatives et les échecs de requêtes. N'y inscrivez ni identifiants d'authentification ni données personnelles des requêtes. Si la lecture est refusée, demandez les droits de consultation adaptés, sans élargir ceux du compte d'exécution.
Le service porte l'URL et les paramètres de trafic ; une révision contient la configuration d'un déploiement. Dans la console ou la liste, identifiez et notez la révision v1 qui reçoit actuellement le trafic. Ne supposez pas qu'il s'agit de la première ligne :
export PREVIOUS_REVISION="YOUR_VERIFIED_V1_REVISION"
Remplacez v1 par v2 dans main.py. Arrêtez le proxy, puis répétez le test local avec uv run et curl de la section 4. Confirmez v2 et arrêtez le serveur local. Réexécutez la commande complète de déploiement de la section 7.
Dans la console, vérifiez que la nouvelle révision est prête. Si vous souhaitez lui envoyer tout le trafic, sélectionnez explicitement la dernière révision prête :
gcloud run services update-traffic "$SERVICE" \
--project "$PROJECT_ID" --region "$REGION" \
--to-latest
Ne lancez pas d'autres déploiements en parallèle pendant l'exercice. --to-latest vise la dernière révision prête et influence aussi le trafic des déploiements suivants. Relancez le proxy et confirmez v2. Une répartition du trafic existante peut affecter un nouveau déploiement : sa réussite ne suffit donc pas à identifier la version qui répond. Voir la référence de modification du trafic.
Pour revenir à la révision v1 vérifiée :
gcloud run services update-traffic "$SERVICE" \
--project "$PROJECT_ID" --region "$REGION" \
--to-revisions="${PREVIOUS_REVISION}=100"
Appelez de nouveau le service via le proxy : la réponse doit indiquer v1. Ce retour en arrière modifie le trafic ; il n'annule pas une migration de base de données, ne supprime pas les nouvelles images et ne défait pas les écritures dans des systèmes externes. Lors du prochain déploiement, vérifiez explicitement la destination souhaitée du trafic.
9. Ajouter du réseau lorsqu'une base privée le nécessite
Un Virtual Private Cloud (VPC) fournit un réseau virtuel, du routage et des contrôles de pare-feu. Dans Google Cloud, les réseaux VPC sont globaux et les sous-réseaux régionaux. Connectivité et IAM sont deux contrôles distincts : joindre une base ne donne pas le droit de la lire, et une autorisation ne garantit pas un chemin réseau.
L'authentification à l'entrée de Cloud Run répond à « qui peut appeler ce service ? ». Pour une base privée, la question devient « comment ce service peut-il envoyer du trafic vers la base ? ». Direct VPC egress permet à Cloud Run d'envoyer du trafic vers un VPC sans connecteur Serverless VPC Access. Ne créez pas de connecteur simplement pour renvoyer du JSON.
Distinguez ces termes :
- Private Services Access utilise une plage d'adresses allouée et une connexion privée pour joindre les ressources prises en charge dans le réseau d'un fournisseur de services. Cette connexion repose sur VPC Network Peering.
- Private Service Connect propose un autre mécanisme d'accès privé, par exemple des points de terminaison de service dans le VPC du consommateur.
- La sortie VPC de Cloud Run configure le chemin des instances vers un VPC. Elle ne constitue pas à elle seule l'un de ces mécanismes de connexion aux services gérés et n'accorde aucun droit de connexion à la base.
Pour intégrer réellement Cloud SQL, concevez la connexion selon l'instance et le mécanisme réseau retenus, puis configurez l'identité applicative et l'authentification de la base. Les appels d'API entre projets ne nécessitent pas systématiquement un appairage VPC, et cet appairage n'accorde pas d'autorisations API. Cet exemple reste sans base de données ni ressource VPC supplémentaire.
10. Nettoyer uniquement les ressources du tutoriel
Arrêtez le proxy local, vérifiez l'ID du projet, la région et le nom du service, puis confirmez dans la console que la cible appartient à cet exercice. Les commandes suivantes suppriment des ressources. Conservez les demandes de confirmation ; n'ajoutez pas d'option de confirmation automatique.
Supprimez le service Cloud Run :
gcloud run services delete "$SERVICE" \
--project "$PROJECT_ID" --region "$REGION"
Après avoir confirmé qu'aucun autre service n'utilise le compte d'exécution, vous pouvez supprimer ce compte de service :
gcloud iam service-accounts delete "$RUNTIME_SA_EMAIL" \
--project "$PROJECT_ID"
La suppression du service ne retire pas automatiquement toutes les images construites, les sources téléversées, les journaux ou les autres stockages. À partir des emplacements notés auparavant, vérifiez dans la console chaque image ou objet source et ne supprimez que ceux du tutoriel qui ne sont plus utilisés. Ne supprimez pas tout un dépôt automatique partagé. Demandez à l'administrateur si les règles de conservation ou l'appartenance des ressources sont incertaines.
Un administrateur peut retirer les attributions IAM ajoutées pour l'exercice et devenues inutiles, mais le nom d'un rôle ne prouve pas qu'une attribution est nouvelle. Ne retirez pas les droits préexistants, ne supprimez pas le compte de construction par défaut, ne désactivez pas les API partagées et ne supprimez pas le projet entier pour éviter de vérifier les ressources.
Enfin, consultez le détail de facturation et les ressources restantes. Les frais peuvent apparaître tardivement. S'ils continuent, examinez séparément les constructions, images, stockages, journaux, réseaux et autres dépendances : l'absence de requêtes vers le service ne prouve pas l'arrêt de tous les frais. Pour une erreur de quota ou de débit, vérifiez le projet, la région et le quota cités dans l'erreur plutôt que de réessayer indéfiniment ou de confondre quotas et allocations gratuites.
Pour d'autres outils pratiques, revenez à Outils et méthodes de travail.