Cloudflare : un plafond de dépense pour Workers

Ce qui se passe

Cloudflare avait déjà des notifications d'usage et des alertes de budget pour les offres payantes, mais « informer n'est pas contrôler ». Spend Management, en bêta, ajoute un vrai plafond : vous fixez une limite de dépense, et Cloudflare met le produit en pause quand elle est atteinte, ce qui évite la facture imprévue. Il est ouvert à tout compte en paiement à l'usage, pour commencer avec Workers et Durable Objects. Pour l'inférence, il se combine avec les limites par utilisateur et par modèle d'AI Gateway.

Comment s'y prendre

Dans le tableau de bord, sous Billing puis Spend limits, activez le produit, fixez la limite, un e-mail de notification et un ou plusieurs seuils d'alerte. Même chose par la CLI cf (cf billing spend-policies create) ou par l'API :

curl --fail-with-body --request POST \
  "https://api.cloudflare.com/client/v4/accounts/${CLOUDFLARE_ACCOUNT_ID}/billing/spend-policies" \
  --header "Authorization: Bearer ${CLOUDFLARE_API_TOKEN}" \
  --header "Content-Type: application/json" \
  --data '{
    "name": "Workers spending cap",
    "product_id": "workers",
    "enabled": true,
    "threshold_cents": 10000,
    "action": "usage_block",
    "notification_email": "me@example.com"
  }'

threshold_cents: 10000 fixe le plafond à 10 000 cents, soit 100 dollars ; usage_block est l'action de blocage. Le tableau de bord affiche la dépense du cycle en cours en quasi temps réel (moins de 10 minutes) et un journal d'audit : qui a changé une limite, quand, et quand un plafond a été atteint.

Ce qui se passe au plafond

Les nouvelles invocations du produit sont refusées. Seules les invocations de code client qui coûtent sont suspendues : sur Workers, les Cron Triggers et les consommateurs de Queues s'arrêtent, mais les fichiers statiques restent servis. Pour reprendre :

• relever la limite au-dessus de la dépense accumulée du cycle ;
• désactiver ou supprimer la politique de blocage ;
• attendre le cycle de facturation suivant, où le blocage expire.

Le cycle commence à la date de début de l'abonnement payant, pas au premier du mois : un abonnement démarré le 10 octobre court généralement du 10 octobre au 10 novembre.

Pourquoi le blocage n'est pas instantané

Le moteur de calcul n'est pas dans le chemin des requêtes. La décision remonte une chaîne, puis redescend vers les serveurs :

L'usage est agrégé près de la source, en fenêtres d'une minute, puis de cinq. Le Rating Engine le convertit en dépense en appliquant les quotas inclus de l'abonnement : un million de millisecondes de CPU n'est pas forcément facturé. Si l'usage arrive avant les informations d'abonnement nécessaires pour le tarifer, il reste en attente au lieu d'être compté comme gratuit. Le plafond est ensuite poussé par Quicksilver, le magasin clé-valeur interne de Cloudflare, et chaque serveur l'applique avec son état local, au rythme de son rafraîchissement périodique.

Limites

• Entre la mesure et le blocage s'écoule un délai (moins de 10 minutes pour l'affichage, plus la diffusion) : la dépense peut dépasser la limite avant l'arrêt effectif. Cloudflare espère passer sous une minute.
• Seuls Workers et Durable Objects sont couverts. Des budgets par application ou par tâche d'agent sont prévus, pas livrés.

Source : Cloudflare, en anglais.