Un service ne répond qu’à peu de requêtes et génère pourtant plus de coûts que prévu. Un autre traite à moindre coût de nombreux appels courts. Si l’on limite exclusivement le nombre de requêtes, on ne mesure donc pas automatiquement ce qui figurera plus tard sur la facture d’infrastructure. Le contrôle des coûts et le contrôle de la charge interviennent à des endroits différents.
Google a annoncé le 12 octobre 2026 la disponibilité générale des Budget spend caps pour Cloud Run. Un plafond de dépenses configuré peut mettre en pause les charges de travail concernées. Il s’agit d’un changement d’infrastructure significatif. Mais on ne le comprend vraiment qu’en distinguant l’alerte budgétaire, le plafond de dépenses et la limitation de requêtes individuelles.
Trois questions, trois limites différentes
Une limite de requêtes répond par exemple à la question : combien d’appels un client donné peut-il envoyer sur une période ? Une limitation du travail simultané demande : combien de travail peut s’exécuter en parallèle ? Une limite de coûts considère en revanche la consommation de ressources valorisée dans son périmètre d’application. Ces grandeurs sont liées, mais pas interchangeables.
Notre service fictif a deux tâches. L’une renvoie une courte réponse d’état. L’autre traite un document volumineux. Toutes deux commencent par exactement une requête, mais demandent une quantité de travail différente. Même si les deux utilisateurs obtiennent le même nombre d’appels, il n’en résulte pas une charge d’infrastructure identique. Un compteur unique passe sous silence la signification différente de ses entrées.
Une alerte budgétaire n’est pas pour autant un arrêt
La documentation officielle de Billing distingue les simples budgets d’alerte des spend caps. Les plafonds décrits s’appuient sur des coûts bruts estimés ; les économies et les crédits n’y sont pas pris en compte. Le périmètre est un projet unique et un service pris en charge, la période est mensuelle. Un exploitant devrait prendre expressément connaissance de ces conditions avant toute configuration.
L’application du plafond n’est pas non plus instantanée. Google précise que les dépassements dus à des retards restent tout de même facturés. Un montant saisi ne constitue donc pas une promesse mathématique que la facture finale s’arrêtera exactement là. La nouveauté offre une intervention technique, pas un substitut à la compréhension de sa facturation.
Pour Cloud Run, la documentation du produit décrit des effets concrets : les services ne peuvent plus traiter de requêtes et renvoient des erreurs de la plage 5xx ; d’autres types de ressources ont leurs propres conséquences. Un arrêt pour raison de coûts est donc en même temps une décision de disponibilité. Cette conséquence se prend en compte dès la planification, et non une fois l’incident signalé.
Un exercice à blanc montre quelle règle s’applique, et quand
Vous n’avez pas besoin d’arrêter un service en cours d’exécution pour comprendre le modèle. Notez trois compteurs indépendants : les appels par client, le travail exécuté simultanément et les coûts estimés sur la période considérée. Associez à chacun une réaction. La première règle rejette les appels supplémentaires d’un client, la deuxième limite le parallélisme, la troisième peut mettre en pause tout un périmètre de service défini.
Limite par client : qui peut envoyer des requêtes, et à quelle fréquence ?
Limite de parallélisme : combien de travail s’exécute simultanément ?
Plafond de dépenses : quand le service considéré est-il mis en pause ?Déroulez ensuite deux cas fictifs : de nombreuses requêtes courtes et peu de requêtes lourdes. N’inscrivez que des différences qualitatives, aucun montant en euros imaginé. L’exercice montre quelle règle perçoit réellement chacun de ces cas. C’est un modèle de réflexion, pas un test de charge ou de coûts mesuré.
L’infrastructure de l’exploitant n’est pas le quota du client
KENJTEC utilise Cloud Run pour des services de plateforme ; cela peut être vérifié dans les sources d’infrastructure et de déploiement du projet. Il n’en découle pas que la nouvelle fonctionnalité de Google ait été activée automatiquement. Il n’en résulte pas davantage un plafond d’infrastructure réglable individuellement pour chaque compte client KENJTEC. Un projet d’exploitant et un abonnement client constituent des périmètres de facturation distincts.
En pratique, la question importante est donc : quelle utilisation une limite doit-elle protéger, et quel travail serait également interrompu lors de son déclenchement ? Un plan pertinent décrit ensemble l’alerte, l’intervention et la reprise. Ce n’est qu’ensuite que l’on peut évaluer comment un plafond de dépenses s’articule avec les limites de requêtes et vos propres exigences de disponibilité.
Sources et état des informations
État des recherches et de la documentation : 25 octobre 2026. Cloud Run release notes — October 12, 2026 · Billing settings for services — Budget spend caps · Manage spend cap budgets.
