Histoires d’horreur du serverless

• Les cas de facturation massive et inattendue sont fréquents sur divers services SaaS et serverless, et cette page les répertorie de manière claire
• Des cas montrent que des utilisateurs payant normalement leur abonnement mensuel ont reçu, en une seule journée, des factures de plusieurs dizaines à plusieurs centaines de milliers de dollars à cause d’une attaque DoS ou d’une consommation débridée des ressources
• Sur certains services, des dépassements ont été facturés même après avoir défini une limite de dépenses, mettant en évidence des limites systémiques
• Dans la communauté des développeurs, le partage de ce type d’expérience met en avant comme principaux problèmes des modèles de facturation aberrants et un manque de transparence
• Dans les environnements serverless et cloud, une simple erreur ou une seule attaque peut entraîner des pertes financières massives, d’où la nécessité d’une vigilance accrue

---

Recueil de cas de surfacturation sur des services serverless et SaaS

#1 Facturation élevée chez Webflow

• Alors qu’un utilisateur était sur une offre à 69 $ par mois, 1,189.42 $ ont été facturés pour un mois, sans raison apparente

#2 Cas d’attaque DoS sur un site de jeux WebGL

• Après une attaque DoS, l’exploitant d’un site de taille moyenne permettant d’uploader des jeux WebGL a reçu une facture de plus de 100,000 $ en une journée de la part de Google Firebase

#3 Vercel Pro et dépassement de la limite de dépenses

• En utilisant l’offre Vercel Pro à 20 $ par mois et en définissant une limite de dépenses de 120 $, des frais supplémentaires inattendus ont tout de même été facturés

#4 Facturation de projet et montant extrêmement élevé

• Un projet qui coûtait 50 $ par mois a un jour généré, au réveil, une facture atteignant 70,000 $

#5 Utilisation de BigQuery et problème de facturation sur un dataset public

• En utilisant BigQuery dans un environnement Playground, une facture énorme de plus de 22,000 $ a été émise

#6 Frais d’hébergement excessifs malgré un faible trafic

• Malgré 9,000 visiteurs mensuels, des frais de 250 $ par mois ont été facturés, soit 3,000 $ sur un an

#7 Problème survenu après une modification de code par Devin (AI)

• Retour d’expérience sur les conséquences inattendues après qu’une IA nommée Devin a effectué des modifications dans une codebase

#8 Facturation soudaine après usage gratuit

• Alors qu’aucun paiement n’avait jamais été effectué, une facture soudaine de 530 $ est apparue un jour

#9 Facturation de sites de documentation et autres petits projets

• Même des services à faible usage, comme un simple site de documentation, peuvent recevoir des factures élevées, parfois proches de 400 $

#10 L’horreur du free tier

• Même une facture d’environ 103 $ est perçue comme problématique. En particulier, l’apparition soudaine d’une facture pendant l’utilisation du free tier est source d’inquiétude

#11 Cloudflare, AWS et autres problèmes

• Chez Cloudflare, il existe des cas où un service a été suspendu avec une demande de paiement de 120,000 $ sous 24 heures
• Sur AWS S3, une facturation inattendue est survenue même après la création d’un bucket vide et privé
• Sur Netlify, une facture impayée de 104,500 $ a été reçue, montrant que des cas similaires se répètent chez divers fournisseurs

#12 Attaque DoS, emails et perte de données

• Lors d’une attaque DoS, l’envoi d’emails a entraîné 11,000 $ de dépenses, avant qu’une base de données ne soit également perdue

#13 Facturation massive chez Vercel, problèmes de comptes et d’essais

• Chez Vercel, une attaque de spam a généré une facture de 23,000 $ en une journée, avec 56,000 comptes et essais activés

#14 Frais inattendus lors de tests ou déploiements

• Des fonctionnalités déployées sur Vercel et d’autres services à des fins de test ont entraîné des montants inattendus
• Un fichier sitemap (sitemap.txt) a consommé des centaines de Go de bande passante, provoquant une forte facturation

#15 Coût des tests Firebase et Cloud Run

• Deux simples tests sur Firebase et Cloud Run ont englouti 72,000 $, mettant le service au bord de la faillite

Conclusion et enseignements

• Dans les environnements serverless et cloud, la structure des coûts peut être opaque ou très vulnérable aux attaques et aux erreurs
• De nombreux cas de facturation inattendue ont été signalés, rendant indispensables une surveillance attentive de l’exploitation, la gestion de la consommation et la définition de seuils autorisés
• Si les fonctions d’automatisation et de monitoring sont insuffisantes, un simple test ou une seule attaque externe peut provoquer des pertes inattendues de plusieurs dizaines de milliers de dollars
• Pour les développeurs, startups et autres utilisateurs de SaaS, l’importance de la gestion des coûts et de la conscience des risques ne cesse de croître

[ahwjdekf]

J’ai travaillé sur un développement pour le DW interne d’un grand groupe : il s’agissait de migrer les données on-premise existantes vers AWS. Mais même après plusieurs mois de développement et de tests, le projet a finalement été abandonné, car la facture mensuelle risquait d’être bien plus élevée que prévu. Même pour un grand groupe, les dépenses cloud ne sont pas faciles à assumer.

[regentag]

Moi aussi, j’avais créé un compte AWS pour apprendre, et je me suis retrouvé à payer une petite somme.
Mon compte avait été compromis et quelqu’un avait créé et fait tourner des instances avec...
Je les ai arrêtées assez vite, donc les frais sont restés limités. Mais comme je ne pouvais pas consacrer du temps à la gestion, j’ai finalement choisi de supprimer complètement le compte.

[ifmkl]

Avant de se lancer dans le cloud, je recommanderais plutôt de mettre en place un environnement de mini-serveur avec des machines de type n100 ou n150, très répandues en ce moment, afin d’accumuler un peu d’expérience en test et en exploitation.

[crawler]

Même pour un tout petit projet, j’ai l’impression que dès qu’on le met sur une plateforme, la moindre vulnérabilité peut vraiment se transformer en perte financière, et c’est ça qui fait peur.

J’avais mis Cloudflare devant mon contenu, mais un hacker a trouvé des objets non mis en cache et les a bombardés plus de 100 millions de fois. Quand j’ai bloqué ça, il a même retrouvé directement l’adresse du bucket d’origine pour l’attaquer.

Je me demande s’ils remboursent les frais même dans un cas comme celui-ci.

[GN⁺]

Avis sur Hacker News

• Quand j’apprenais la programmation dans un bootcamp, j’ai essayé de créer gratuitement une instance Elastic Beanstalk. Il fallait une carte de crédit pour la vérification d’identité, et à l’époque je ne pensais pas que ça poserait problème. Mais ensuite mon serveur a subi une attaque de bots spam et Amazon m’a facturé 100 000 dollars. J’ai fini par être remboursé, mais depuis ce jour je déteste Amazon et je me suis juré d’utiliser un autre service si je devais faire du cloud computing. Je n’aimais pas ce tableau de bord complexe ni cette structure pensée pour embrouiller les clients et leur faire perdre de l’argent. Il aurait suffi d’utiliser la carte de crédit uniquement comme moyen de vérification et de bloquer les bots. Quand on compare ça au simple fait d’acheter des cookies dans une épicerie avec une carte de crédit, on voit bien qu’on pourrait utiliser la fintech de façon réellement utile, mais que ça n’a pas été fait
  • C’est l’une des raisons pour lesquelles l’hébergement cloud fait peur. Pas seulement Amazon, Azure et Google Cloud remboursent eux aussi « en général ». Mais si mon projet de démo avec 5 visiteurs par semaine se fait soudain DDOS et que l’hébergeur décide que, cette fois, on n’est pas dans le cas « en général » et me demande un virement, je peux me retrouver au bord de la faillite
  • J’ai actuellement 25 000 dollars de frais facturés. J’avais activé l’audit du data plane de SQS et branché en pratique un flux d’événements d’audit en temps réel. Résultat, chaque événement d’audit pur déclenchait un événement de journalisation en boucle infinie. Un compte qui me coûtait en moyenne 2 dollars par jour depuis presque 10 ans s’est soudain mis à coûter 3 000 dollars par jour, sans aucun avertissement ni intervention d’AWS
  • Je me demande pourquoi tu détestes Amazon alors qu’ils t’ont remboursé 100 000 dollars. Dans mon cas, AWS m’a toujours remboursé même quand la facture énorme venait entièrement de mon erreur. S’il existait une politique du type « tout arrêter quand le budget est dépassé », on aurait aussi vu plein d’autres tragédies du genre « j’ai subi un DDOS, AWS a coupé toutes mes EC2 et j’ai même perdu les données écrites sur le stockage temporaire »
  • « C’est pourtant très simple : un if d’une ligne qui éteint les instances quand le compte dépasse sa limite et qui bascule le service sur un disque statique. Ils ne le voulaient simplement pas — ils veulent utiliser leur taille pour maximiser les revenus sur le dos des clients. Ceux qui ont compliqué la vie de tout le monde avec le cloud computing essaient maintenant aussi de tirer un bénéfice économique des coûts de l’IA grâce à leur conquête du marché. Aujourd’hui, si l’edge compute devient plus facile, c’est parce que les cryptos ont poussé les gens à surinvestir dans les disques durs. Au final, le marché encourage les bulles et les mauvais comportements, et permet facilement à ceux qui abusent du marché par la force au lieu de construire de la confiance de dominer le jeu. Les pires plaies du secteur, ce sont ces méchants intelligents qui prennent une attitude sournoise du genre : “Tu ne comprends tout simplement pas ! (au fait, donne encore un peu d’argent avant que le marché ne s’effondre)”. Même une compagnie de taxi ne te facture pas mille dollars parce qu’elle n’est pas allée à destination. J’ai du mal à croire qu’on ne puisse pas mettre un if sur un serveur. Est-ce qu’Amazon est vraiment pire qu’une compagnie de taxi ? Peut-être bien. C’est d’ailleurs comme ça que “Waymo” a commencé (ou peut-être pas, c’est une blague) »
• Je pensais qu’on allait parler de la souffrance du serverless en matière d’hébergement/développement/debug, mais c’était une histoire d’explosion des prix. Les coûts de bande passante ne me paraissent pas vraiment concrets, donc j’ai survolé la plupart des articles sur le sujet, mais celui-ci m’a paru assez étonnant — dans le cas où un bucket S3 vide peut faire exploser une facture AWS, il est question du fait qu’on peut transférer les coûts à quelqu’un d’autre rien qu’en envoyant des appels API non authentifiés vers son S3. C’était nouveau pour moi
  • Je crois qu’une mesure a été prise juste après que ce billet de blog a fait le buzz : Amazon S3 ne facture plus certains codes d’erreur
  • L’un des vrais problèmes des environnements serverless, c’est que la plateforme elle-même est opaque comme une boîte noire (ce qui fait aussi partie de la proposition de valeur du serverless). Nous avons hérité d’un gros backend Lambda, et quand il y a des problèmes internes à la plateforme, comme des coupures intermittentes de socket lors de la connexion à l’extension secrète, c’est extrêmement pénible à tracer. Le fait que l’environnement de test local soit très différent de l’environnement de déploiement réel rend ça encore plus pénible. Faire joujou à la maison avec Google Cloud Functions, ça marche bien, mais pour un vrai projet je préférerais largement déployer moi-même des serveurs HTTP / consommateurs de file dans des conteneurs comme ECS
  • L’idée, c’est : « Imaginons que je crée un bucket S3 privé vide dans ma région préférée. Par hasard, un outil open source populaire est configuré par défaut pour stocker ses sauvegardes sur S3, et il utilise comme placeholder exactement le même nom que le bucket que j’ai créé. » Je me demande à quelle fréquence ce genre de chose arrive réellement — je ne sais pas à quel point les collisions de noms sont fréquentes en pratique
  • Ça donne presque l’impression qu’on pourrait utiliser cette méthode pour éliminer des concurrents. C’est aussi pour ça que je n’aime pas trop AWS. Il n’y a absolument aucun effort pour protéger les petits clients des factures-surprises. Azure n’est pas tellement mieux, mais il y a quand même quelques protections en plus
  • Moi aussi je m’attendais à un cas classique de verrouillage cloud où tout est attaché au serverless, à Lambda et à DynamoDB, alors qu’en réalité un VPS à 20 dollars avec sqlite suffirait largement, donc j’ai été un peu déçu que ce ne soit pas ça
• La vraie douleur du serverless, ce n’est pas une énorme facture à cause d’un incident unique, mais les coûts qui gonflent petit à petit chaque mois. On peut très facilement créer des ressources puis les laisser traîner. Tous les un ou deux mois, ça monte de quelques milliers de dollars, puis quand le COO s’en aperçoit, c’est urgence générale pour faire redescendre la facture sous les 10 000 dollars. Et puis ça recommence. Sur plusieurs années, le gaspillage cumulé dépasse ce qu’on perdrait en une seule fois
  • C’est en pratique le business model d’AWS. Tu l’as déjà entendu appeler le modèle « Planet Fitness » ? S’inscrire ou dépenser de l’argent est incroyablement facile, mais résilier ou arrêter les paiements est volontairement très pénible
  • On dirait que les organisations n’apprennent absolument rien de ces périodes de facturation exorbitante. Je me demande quelle était la cause de cette hausse continue des coûts et s’il n’y avait pas un moyen de la prévenir en amont
  • Ce genre de problème arrive aussi souvent on-premise. On finit par avoir des serveurs (souvent des VM) qui font tourner des applis inutilisées. Bien sûr, le coût d’une VM n’est pas nul non plus
• Il y a souvent un flou sur la responsabilité. Les clients veulent des outils magiques et sans friction qui permettent de déployer une infrastructure matérielle en un clic. Si un utilisateur inexpérimenté configure mal quelque chose et se retrouve avec une facture énorme, la réputation du cloud en pâtit si le fournisseur facture quand même, mais si le fournisseur trie les utilisateurs à l’avance et impose des limites, alors même les petits développeurs qui tentent une startup se retrouvent face à une porte fermée. Dans ce genre de cas, je me demande toujours, d’un point de vue philosophique, qui devrait payer jusqu’à quel montant lorsqu’une facture soudaine de 10 000 dollars tombe, et jusqu’où va la responsabilité pour des coûts causés par erreur. Si mon code consomme les ressources de façon dix fois plus inefficace, est-ce que ça doit rester « ton mauvais paramétrage, ta responsabilité » ? Et, du point de vue du client, est-ce qu’il devrait ou non se soucier de savoir si le cloud utilisé est AWS, un autre géant, ou une petite startup qui fournit une API ?
  • Et si on mettait en place des systèmes de dépassement de budget / coupe-circuit (plafond de dépenses) ? Ça ne semble pas être un problème insoluble
  • En réalité, la réponse est simple — fixer une limite de budget
  • C’est aussi pour ça que j’utilise de vrais serveurs au lieu du serverless
• Chez Hetzner, on peut avoir 16TBx2 HDD, 1TBx2 SSD, 64GB de RAM et 20TB de trafic gratuit pour 70 $ par mois. À l’inverse, j’ai utilisé 1TB de trafic sur une micro-instance AWS et j’ai payé 150 dollars (si je me souviens bien). Il n’y a aucune raison de faire ça
• À propos de l’histoire « j’avais mis Cloudflare devant mon contenu, puis un hacker a trouvé des objets non mis en cache et les a martelés plus de 100 millions de fois. Quand je l’ai bloqué, il a même retrouvé directement l’adresse du bucket d’origine et l’a attaqué », je me demande si ça ne peut pas arriver à n’importe qui. Je ne sais pas non plus si le fait qu’un objet non mis en cache ait fuité est une erreur aussi grave que de laisser le port 22 ouvert avec un mot de passe faible, et pour les ressources S3 (en particulier les images), n’est-il pas normal qu’elles soient accessibles autant de fois que n’importe qui le veut ?
  • Pas du tout. Un bucket S3 doit impérativement être privé, avec des règles de sécurité qui n’autorisent l’accès que via le CDN. C’est comme ça qu’on force effectivement tout le trafic à passer par le CDN
  • Ça donne l’impression de quelqu’un qui se vanterait de laisser traîner une vulnérabilité du top 10 OWASP. La configuration du contrôle d’accès n’est pas si difficile que ça, et si quelqu’un fait une erreur aussi basique là-dessus, il y a de fortes chances qu’il soit aussi négligent ailleurs. Je n’aurais pas confiance dans un système géré par une telle personne
  • La base absolue, c’est de garder les objets S3 privés et de mettre au minimum un proxy CloudFront devant. Les images et ce genre d’éléments doivent impérativement passer par le cache
• L’appellation serverless n’est pas vraiment correcte, car dans les faits on fait toujours tourner des serveurs sur une infrastructure cloud. Au fond, on continue d’écrire des logiciels selon un modèle client-serveur, et les serveurs doivent tourner quelque part pour que les utilisateurs puissent s’en servir. À mon avis, le vrai « serverless », ce serait une forme de logiciel qu’un utilisateur télécharge une seule fois et peut ensuite utiliser sans Internet. Ou alors quelque chose qui, même si des données sont envoyées vers un serveur, ne dépend pas d’un lieu spécifique imposé par le développeur
  • Le terme « serverless » désigne essentiellement un « système de gestion où les ressources (serveurs) augmentent et diminuent automatiquement selon la charge », et c’est ça l’essentiel. Quand la charge augmente, les serveurs augmentent ; quand elle baisse, ils diminuent. Le serverless ne donne vraiment sa pleine valeur que lorsqu’on peut adapter toute la structure du code pour correspondre efficacement à ce type d’environnement. Autrement dit, c’est une architecture à utiliser uniquement quand on en a réellement besoin
  • En général, on appelle simplement ça un logiciel « local ». « Serverless » est un mauvais nom, mais il s’agit en réalité d’une structure de déploiement pour un backend particulier. Ce n’est pas une application sans backend
  • « Serverless », c’est un peu comme une « entreprise sans employés ». En réalité, il y a bien des gens qui rendent le service, mais ce sont tous des prestataires
  • Un « serveur », c’est généralement une machine unique avec un OS et plusieurs couches logicielles (y compris des outils de supervision), qui permet à l’utilisateur d’accéder à la logique métier. Utiliser directement des serveurs impose de s’occuper du choix de l’OS, de l’installation et des mises à jour des logiciels de support, ainsi que de la reprise en cas de panne. Le serverless relève du modèle « function as a service », donc on n’a à se soucier que de la logique métier (notre code). Pas besoin d’installer un OS sur le serveur, ni de gérer les logiciels de base comme le serveur HTTP. Pas besoin non plus de faire les mises à jour ou la maintenance. On téléverse simplement le code, et il s’exécute quand il est invoqué. C’est l’idée d’être complètement libéré du stress de l’exploitation des serveurs. C’est pour ça que ça s’appelle « serverless » — il y a bien des serveurs, mais on n’a pas besoin de les exploiter soi-même
• Le mot « serverless » ne veut pas dire qu’il n’y a réellement pas de serveurs, mais qu’on n’a pas besoin de les gérer directement ni de savoir sur quel serveur notre code s’exécute. C’est l’idée de dire : « Je te donne un peu de code, exécute-le toutes les heures. Où tu le fais tourner, ça ne m’importe pas »
  • Ce mot peut sembler gênant, mais d’un point de vue linguistique, ce n’est pas vraiment un problème orwellien. Dans 1984, la « novlangue » allait dans le sens d’une suppression de la diversité des expressions, alors que « serverless » est au contraire un néologisme créé pour désigner une nouvelle catégorie. Bien sûr, c’est un terme qui peut brouiller l’existence même des serveurs, mais l’appeler précisément orwellien ne semble pas juste. On pourrait imaginer un mot comme « servelet », au sens de « serveur léger »
  • On entend aussi souvent l’expression auto-dérisoire : « le cloud n’existe pas, c’est juste l’ordinateur de quelqu’un d’autre »
  • Au fond, le « serverless » donne l’impression d’être simplement une version tech-bro de l’ancien « hébergement mutualisé », avec « 10 000 % de marge » et une tarification à la requête
  • Les systèmes « no-code » tournent eux aussi sur du code. S’énerver parce qu’un PaaS ou autre utilise quand même des serveurs, c’est surtout chercher un prétexte
• J’ai utilisé le serverless d’AWS, et les tests locaux étaient pratiquement impossibles. En plus, pour faire tourner serverless run, il fallait obligatoirement utiliser un rôle IAM AWS, ce qui ouvrait de larges permissions sur l’ensemble du compte. Au final, ça créait un énorme problème, car dans les faits on avait presque l’impression de tester directement en production à chaque fois
  • Moi aussi, j’ai travaillé plusieurs années sur des projets serverless, et l’incapacité à faire tourner quoi que ce soit localement a été un vrai coût. Le temps de débogage était terriblement long. Même les outils censés servir de remplacement sont presque inutiles sur de vrais projets
  • Si on configure correctement le fichier ~/.aws/credentials, on peut faire des tests locaux avec les clés de sécurité AWS. On peut automatiser le déploiement des Lambda avec un makefile et créer un rôle IAM personnalisé pour chaque Lambda afin de gérer les exigences de sécurité dans des fichiers JSON. Le vrai avantage d’AWS, c’est que tout passe par la même API. On peut tout créer et gérer programmatiquement
  • 1. Déployer le tout dans une stack sur un compte séparé pour les développeurs (environnement de staging gratuit) 2) Tester localement avec le runtime Docker officiellement pris en charge 3) Écrire des tests unitaires comme d’habitude 4) Émuler sur sa machine l’environnement de staging avec des outils comme localstack — il y a tellement d’options que je ne vois pas comment on peut en arriver à une expérience aussi catastrophique
  • C’est une affirmation très éloignée des faits
• Je pense malgré tout que le terme « serverless » est un naming orwellien qui enjolive un système reposant bel et bien sur des serveurs
• J’ai du mal à croire que ces entreprises puissent facturer jusqu’à 550 dollars pour 1TB de bande passante. Même en louant un serveur avec un port garanti à 10Gb/s, j’estime qu’au-delà de 3 dollars par TB on est déjà dans l’arnaque. Je me demande comment le serverless peut justifier un coût 150 fois supérieur. Est-ce qu’il y a vraiment tant de gens que ça qui acceptent ces prix ? Pour un wiki de lecture, de la documentation technique ou un blog, un VPS à 10 dollars ou GitHub Pages suffit largement, et avec une configuration correcte, on peut sans problème encaisser 10 000 connexions simultanées

[benjamin]

Quand des personnes qui se lancent tout juste dans le développement créent quelque chose avec l’IA aujourd’hui, la plupart ne déploient-elles pas leur service avec des outils comme Vercel ou Supabase ?

Mais quand leur service commence à grandir, j’ai l’impression qu’elles ne calculent pas vraiment le prix qu’elles devront leur payer.
Avec l’idée de se dire qu’elles y réfléchiront à ce moment-là.

J’imagine bien les fondateurs de Vercel ou de Supabase répondre avec un grand sourire : « Oui, oui, vous pourrez y penser à ce moment-là ! »

Bien sûr, on peut y réfléchir à ce moment-là. À condition d’avoir les compétences pour en sortir rapidement.
Mais sans connaissances en informatique, ce ne sera pas facile.
Vous risquez de finir par leur reverser tout l’argent que vous commencez à peine à gagner.

En réalité, c’est exactement ce qui est en train de se passer.
Autrement dit… un énorme business est en train de s’ouvrir en se nourrissant de l’argent des débutants qui se lancent sans rien connaître à l’informatique.

Voilà pourquoi il faut continuer à creuser l’informatique en profondeur.
Certains dépensent 1 million de wons par mois pour un service qui commence tout juste à générer des revenus, alors que d’autres l’exploitent sans rien payer du tout.
Réduire les coûts d’exploitation, c’est aussi une compétence. N’est-ce pas un avantage concurrentiel énorme ?
Coder avec l’IA, créer des choses et y prendre du plaisir, c’est très bien, mais si vous ne faites pas l’effort d’aller plus en profondeur, vous ne pourrez au final pas créer de vraie différence.

https://jeho.page/essay/2025/09/08/sucker-developer.html