We’re going to need default hard budget caps on pretty much everything

On a toutes et tous déjà eu cette frayeur, sur son compte AWS perso, d'avoir un pic de facturation qui nous laisse un goût très amer en fin de mois. Sur AWS, on déploie des ressources dont la consommation peut sortir des clous pour x ou y raisons, et cela ne vaut pas que pour AWS.

Je me souviens d'un certain matin. J'arrive à mon poste, j'ai un DAG en rouge. J'investigue, je cherche, et je vois que l'erreur vient d'une query qui n'a pas pu s'exécuter sur un data warehouse Snowflake. Pourquoi ? Parce qu'il y avait une hard limit, laquelle nous a permis d'éviter une facture très salée. Elle l'était déjà, mais pas dramatiquement. Un dev avait lancé une query qui aurait tourné très longtemps et consommé beaucoup plus que la hard limit.

Depuis ce jour, je vérifie deux fois les hard limits des services que j'utilise. Si le service ne les propose pas nativement, j'essaie de mettre en place une rustine qui atteint le même objectif : préserver le compte bancaire de mon client.

Cette expérience met aussi en avant l'importance, certes moindre, des soft limits (peut-être à 80 % de la hard limit ?) et d'un système d'alerting à l'atteinte de cette soft limit. Bien évidemment, un système de détection d'anomalie est un plus non négligeable.

Dans tous les cas, dans cette ère agentique, avec de nombreux agents de coding ou personnels qui auront potentiellement accès aux comptes AWS, aux warehouses Databricks... et qui eux-mêmes utilisent souvent des tokens facturés en pay as you go, les hard limits sont plus importantes que jamais.

• Pour les consumers de produits : mettez des hard limits.
• Pour les producers : donnez la possibilité d'en définir. AWS semble enfin avoir entendu cette requête, il n'y a pas de raison que vous non plus...