Suivre le guide officiel d’AWS Amplify m’a valu 1 100 $ de frais

 (elliott-king.github.io)
1 points par GN⁺ 2024-11-15 | 1 commentaires | Partager sur WhatsApp
  • Après avoir expérimenté avec le guide officiel d’intégration d’OpenSearch d’AWS Amplify, les coûts d’Amazon OpenSearch Service sont montés jusqu’à 1 124,88 $ sur un mois malgré une faible utilisation
  • Les coûts se sont accumulés parce que le domaine OpenSearch créé par npx ampx sandbox restait en place même après l’arrêt et la suppression du sandbox, et qu’un nouveau domaine s’ajoutait à chaque exécution suivante
  • La configuration officielle crée par défaut une instance r5.large.search, et ce coût de base d’au moins 134 $ par mois n’apparaissait pas clairement dans le code boilerplate ni dans le guide
  • Le support AWS a accordé un crédit exceptionnel pour OpenSearch et le stockage, et a demandé la mise en place d’AWS Budgets pour éviter que cela ne se reproduise
  • Lorsqu’on utilise Amplify avec OpenSearch, il faut vérifier soi-même les ressources restantes après suppression du sandbox ainsi que le type d’instance par défaut afin d’éviter une facturation inattendue

Facturation OpenSearch inattendue

  • Après avoir suivi le guide officiel d’intégration d’OpenSearch dans AWS Amplify, la facture AWS a dépassé 1 200 $ quelques semaines plus tard
  • Le service identifié par la demande au support était Amazon OpenSearch Service, pour un total mensuel de 1 124,88 $
  • L’auteur avait déjà utilisé Amplify et OpenSearch en 2020, et pour un usage personnel cela coûtait généralement environ 50 $ par mois : cher, mais rien à voir avec 1 200 $
  • Après examen détaillé, l’AWS Customer Support a appliqué un ajustement de facturation sous forme de geste commercial ponctuel pour ces coûts imprévus
  • Pendant la procédure de support, des crédits ont été accordés pour OpenSearch et les services de stockage, et la configuration d’AWS Budgets a aussi été demandée
    • AWS Budgets permet d’estimer les dépenses futures pour un service donné ou pour l’ensemble d’AWS, et d’envoyer des alertes quand un dépassement de budget est probable

Les ressources créées par le guide officiel

  • Le quickstart d’Amplify crée, à partir de code fourni par AWS, une application jouet de notes TODO, et Amplify génère une base de données DynamoDB ainsi que des requêtes CRUD authentifiées
  • Une exécution locale est possible, mais Amplify crée aussi un domaine accessible
  • À l’étape de configuration d’OpenSearch, on écrit du boilerplate TypeScript pour déclarer les ressources Amplify
    • Une table DynamoDB est définie comme variable pour être référencée dans le pipeline
    • Une instance OpenSearch, un index et un indexMapping sont créés
    • Une requête permettant d’accéder aux données dans OpenSearch est écrite
    • Un pipeline OpenSearchIngestionService est créé pour copier les données de DynamoDB vers OpenSearch
  • La configuration associée est gérée dans le dépôt sous forme de fichiers TypeScript/JavaScript avec le code frontend
  • npx ampx sandbox démarre les services AWS et modifie automatiquement les services existants lorsqu’il détecte des changements de configuration

Des domaines encore présents après suppression du sandbox

  • Cette configuration inclut plusieurs ressources : une base DynamoDB, un service OpenSearch, un pipeline OSIS, des rôles IAM, etc.
  • Le boilerplate officiel crée par défaut une instance OpenSearch r5.large.search
    • Cette valeur par défaut n’apparaissait pas explicitement dans le code boilerplate ni dans le guide
    • r5.large.search coûte au minimum 134 $ par mois
  • À la fin d’une journée de travail, lorsqu’on arrête le sandbox avec CTRL-C, une invite demande s’il faut le supprimer définitivement, et l’utilisateur peut répondre Y
  • À ce moment-là, DynamoDB est supprimé, mais dans la console AWS le domaine OpenSearch reste présent
  • Le lendemain, si l’on relance npx ampx sandbox, une nouvelle instance OpenSearch est créée, et npx ampx sandbox delete ne supprime pas non plus l’instance d’origine
  • En répétant ce processus, plusieurs domaines OpenSearch restent en arrière-plan pour un même projet, ce qui fait grimper les coûts

Risque de bug et type d’instance par défaut

  • Ce comportement ressemblait à un gros piège, et même après l’ouverture d’un ticket au support AWS, le problème ne semblait pas résolu à ce moment-là
  • Il existait d’anciens signalements de bug liés à ce sujet, mais rien de trouvé sur l’année écoulée
  • Il est possible que les domaines OpenSearch aient bien été supprimés en v1 mais plus en v2, sans que la cause exacte soit confirmée
  • Le flux actuel ne passe plus par l’Amplify CLI mais s’exécute via npx
  • Le fait que r5.large.search soit le type de machine par défaut reste aussi un facteur de risque
    • Il semblerait préférable d’en faire un champ obligatoire sans valeur par défaut
    • Si le guide affichait explicitement r5.large.search comme valeur par défaut, les utilisateurs le remarqueraient plus facilement
    • Cette valeur par défaut ne relève pas spécifiquement d’Amplify mais d’AWS CDK, donc ce n’est pas uniquement la responsabilité de l’équipe Amplify

Points d’attention lors de l’usage d’Amplify avec OpenSearch

  • Il était attendu que des outils accélérant le développement de nouvelles technologies coûtent plus cher que du bare metal, mais ici la facture a largement dépassé ce niveau
  • La console budget d’AWS permet de recevoir des alertes quand les dépenses prévues dépassent le budget défini
  • Même en suivant uniquement la section OpenSearch, de nombreuses ressources cachées sont créées : compte IAM, domaine OpenSearch, pipeline OSIS, groupe de logs, stockage S3
  • OpenSearch est souvent utilisé par des clients d’entreprise, donc peut être considéré comme un service « avancé », avec l’hypothèse que l’utilisateur connaît mieux l’écosystème AWS
  • OpenSearch a été utilisé en raison du support des requêtes de boîte englobante geo_point, mais l’auteur n’est pas certain qu’un produit plus simple n’aurait pas suffi
  • D’après une mise à jour, le guide AWS a ensuite été corrigé ; il ne l’était pas encore trois mois avant la remontée initiale du problème, mais un travail de PR sur la documentation semblait avoir commencé avant la publication de l’article

À lire aussi

1 commentaires

 
GN⁺ 2024-11-15
Réactions sur Hacker News

  • Les alertes de facturation sont une blague ; ce qu’il faut vraiment, ce sont des plafonds stricts de dépenses
    Il faudrait aussi proposer un moyen de configurer cette limite pendant l’onboarding
    Bâtir un business sur des chèques en blanc et des frais accidentels est suspect, et ça crée aussi une forte barrière à l’adoption
    Plus je vois des cas du genre « j’ai suivi un tutoriel de 20 minutes et on m’a facturé l’équivalent de tout ce que j’ai économisé dans ma vie ; cette fois le support client a annulé la facture, mais la prochaine ils auraient presque emporté ma maison », moins j’ai envie d’explorer les produits AWS

    • Ce n’est pas propre à AWS ; les fournisseurs cloud semblent en gros se diviser en deux catégories
      D’un côté, ceux comme AWS ou DigitalOcean qui font porter le risque au client, et de l’autre, ceux qui vendent des offres « illimitées » ou « non mesurées » douteuses
      Aucune des deux approches ne me convient
      J’aimerais un fournisseur avec des limites claires et documentées permettant une vraie planification de capacité, où le risque de disponibilité reste côté client mais le risque financier est porté par le fournisseur
      Je serais même prêt à payer un forfait fixe plus élevé si ça reste raisonnable
    • Des plafonds stricts de dépenses seraient presque contre-productifs pour les clients entreprise, qui sont le cœur de cible d’AWS
      Il n’existe pratiquement aucune facturation accidentelle qui coûte moins cher qu’une indisponibilité ou une perte de données sur une application critique
      Même si ce n’était qu’une option, les équipes finance pourraient pousser à l’utiliser, avec le risque qu’un problème débouche sur un incident de perte de données
      Ça peut avoir du sens pour des fournisseurs cloud orientés développeurs indépendants ou PME
    • Il a été dit plusieurs fois dans les commentaires HN que le code de facturation d’AWS est un énorme plat de spaghetti, et qu’en interne il y a une vraie peur à l’idée d’y toucher pour faire de gros changements
      C’est l’un des détails internes les plus intéressants que j’ai appris ici
    • AWS m’a toujours intéressé, mais pour ce genre de raisons je n’y ai jamais vraiment mis les pieds
      Mieux vaut jouer la sécurité avec un VPS moins cher et à tarif fixe plutôt que de regretter après coup
    • Il faut réguler ça
      Demander à Amazon de faire quelque chose ne sert pas à grand-chose
      Il faut obliger Amazon et les autres à respecter l’argent des utilisateurs par la loi
      Les entreprises font, par nature, non pas ce qui est éthique ou économiquement sain, mais ce qui rapporte de l’argent

  • À côté de ça c’est mineur, mais j’ai essayé de déployer une appli sur ECS, j’ai reçu une facture de 100 dollars, et j’ai décidé de ne plus jamais utiliser AWS
    L’erreur qui empêchait le service de démarrer venait bien de mon application, mais CloudWatch ne sortait qu’environ 20 % des logs, donc pour obtenir des logs j’ai dû redéployer cinq fois, corriger, puis redéployer encore cinq fois
    Chaque déploiement raté était facturé ; après deux jours de galère, j’ai supprimé le compte et déployé sur DigitalOcean App Platform
    Là aussi le déploiement a d’abord échoué à cause d’une erreur dans l’appli, mais les logs étaient affichés à chaque fois, j’ai corrigé le problème en moins de 10 minutes, et la facture totale s’est élevée à quelques centimes
    Depuis ce jour, je me suis juré que s’il existe une alternative, je n’utiliserai jamais AWS et je ne le recommanderai jamais

    • Je n’ai utilisé qu’Azure, mais ECS semble correspondre à Azure Container Apps
      Pour du développement et des tests, le modèle de facturation à l’usage était très bon marché
      Je ne sais pas ce que ça donne sur de grosses charges, mais le fait d’être facturé à chaque déploiement paraît étrange
    • J’ai abandonné AWS quand j’ai compris qu’on ne pouvait pas déployer directement des conteneurs sur EC2 comme avec GCP
      Le support est peut-être meilleur sur de gros projets, mais sur des petits à moyens projets, GCP est bien supérieur
      Il propose les briques de base adaptées à l’usage moderne des conteneurs, et il y a aussi BigQuery

  • Le script exécuté par cette commande npx semble avoir un bug évident
    Si l’auteur a raison, alors pour un tutoriel il faudrait choisir à 100 % les ressources les moins chères, et l’exécution du sous-script delete devrait nettoyer les ressources
    Il n’est pas juste d’attendre qu’après avoir lancé ça, un développeur doive passer son compte AWS au peigne fin avec une paranoïa extrême pour traquer les ressources orphelines
    Si une startup fonctionnait comme ça, est-ce qu’on balayerait ça d’un « il faut être prudent, ce genre de chose arrive » ?
    Je ne comprends pas pourquoi AWS serait jugé selon un autre standard

    • C’est justement ce qui m’agace le plus avec AWS
      Il n’existe pas de moyen simple de voir facilement toutes les ressources pour lesquelles je paie actuellement
      Ou alors il y en a un et je ne l’ai jamais trouvé
      Sans vue d’ensemble facile à comprendre, j’ai l’impression de ne pas avoir un contrôle total sur mon compte
    • Quand je dois utiliser quelque chose de nouveau, la première chose que je vérifie, c’est si je peux avoir une facture fixe mensuelle
      Je regarde aussi ce qui se passe si je dépasse ce montant, et s’il est possible de limiter les frais imprévus
      Si ce n’est pas possible, je cherche autre chose
      Depuis le changement de facturation de Google Maps il y a quelques années, je fais aussi très attention à ne pas nous rendre trop dépendants de services Google « gratuits », et au final ça nous a coûté cher
    • Existe-t-il seulement un moyen simple de lister toutes les ressources présentes dans un compte AWS ?
      J’ai toujours dû vérifier service par service et région par région, ce qui était fastidieux et propice aux erreurs
    • Du point de vue d’Amazon, c’est un moyen facile de gagner 1000 dollars, donc ce n’est pas un bug, c’est une fonctionnalité
      Et même s’ils considèrent que c’est un bug, il passera probablement bien après d’autres sujets qui ont un impact direct sur leur profit et perte
    • Je suis d’accord pour dire qu’il n’est pas juste d’attendre des développeurs qu’ils fassent des vérifications paranoïaques
      Mais dans la réalité, c’est rationnel
      Quand on construit quoi que ce soit sur AWS, il faut traiter AWS comme une institution financière hostile partie en roue libre

  • C’est le genre de cas qui fait que je repousse depuis des années le moment de creuser AWS
    Il devrait exister un parcours de formation standard permettant aux gens d’expérimenter gratuitement sans avoir à fournir leur carte bancaire
    À la place, on dirait qu’il y a des employés de bureau qui calculent qu’on peut soutirer des milliers de dollars ici et là à cause d’une « erreur utilisateur »
    Ces frais sont difficiles à contester, et parfois même impossibles à faire annuler
    Je ne dois pas être le seul à avoir évité l’écosystème AWS par crainte raisonnable de se réveiller avec une facture énorme

    • Le fait qu’AWS ne rembourse pas dans une situation comme celle-ci est très inhabituel, donc il est difficile d’y voir une stratégie visant à presser des milliers de dollars à partir d’erreurs d’utilisateur
      Ils ont probablement jugé que traiter les remboursements leur coûtait moins cher que de fournir des tutoriels précis et peu coûteux
      Ça ne justifie pas leur comportement, mais on m’a déjà annulé une facture légitime de 600 dollars générée en utilisant AWS Textract
      À l’époque, je travaillais dans une entreprise valant plusieurs milliards de dollars
    • Si les gens se retrouvent dans ce genre de situation de facturation, c’est à mon avis parce qu’ils ne vont pas vraiment au fond d’AWS
      La grille tarifaire est facilement accessible et pas toujours simple à comprendre, mais la plupart des coûts augmentent presque linéairement, donc il est relativement facile de faire des tests
      Mieux vaut éviter les services wrappers comme AWS Amplify, CloudFormation et les divers trucs en Stack
      Il suffit d’utiliser directement les services de base
      Tous les services ont une API, et obtenir des clés API liées à un utilisateur IAM est aussi simple que de cliquer sur un bouton
      Le reste se gère avec un cache approprié et en alignant le modèle de coûts sur le modèle de revenus
      Il faut faire en sorte que le coût des services auto-scalables représente un pourcentage presque fixe du chiffre d’affaires, indépendamment de la demande du moment
      La bande passante est un vrai cauchemar chez AWS, mais ils proposent des remises automatiques sur le long terme dans la console, et en passant par un commercial on peut parfois obtenir un peu mieux encore
      C’est pour ça que j’évite EC2, et comme la bande passante interne d’EC2 coûte aussi plus cher, je préfère utiliser directement Lambda + S3 + CloudFront
      Au bout d’environ trois mois, il devenait assez facile de prévoir quelle combinaison de services serait la plus rentable pour implémenter une nouvelle fonctionnalité orientée utilisateur
    • A Cloud Guru / Pluralsight proposent une fonctionnalité appelée « Cloud Playground » ou « sandboxes »
      Ça peut peut-être convenir à cet usage, mais je ne l’ai pas testé moi-même, donc je ne peux pas l’affirmer avec certitude
    • L’argent tiré de ce type d’erreurs utilisateur représente probablement une goutte d’eau dans l’océan à l’échelle d’AWS
      D’après mon expérience, AWS avait plutôt tendance à vouloir éviter les problèmes qui leur coûteraient davantage en atteinte à leur réputation
      AWS n’est pas bon marché, et dans certains cas c’est même extrêmement cher, surtout pour le transfert de données, mais je ne pense pas que leur méthode consiste à piéger les clients pour leur faire dépenser accidentellement quelques centaines de dollars de plus

  • C’est bien dans le style d’AWS
    Il y a quelques mois, j’ai suivi le guide officiel de démarrage rapide SageMaker pour faire tourner Llama 2, et effectivement ça a démarré très vite, mais le lendemain j’ai découvert que ça me coûtait 400 dollars par jour
    La facturation a été annulée, mais j’ai bien retenu une chose : il ne faut pas faire confiance aux guides officiels

    • SageMaker est, du point de vue produit, l’axe le plus décevant, et un exemple limpide d’enshittification
      Au début du produit, en 2017-2018, la configuration était assez intuitive
      Il y avait des instances notebook, de l’inférence, une API REST pour le serving, un peu d’EFS, et il était clair que S3 était au centre du service
      La tarification était fermée, donc il n’y avait pas de mauvaise surprise
      Dans l’ensemble, ça faisait un peu penser à DigitalOcean, et même des data scientists avec quelques bases sur l’infrastructure et un peu de curiosité pouvaient monter une configuration simple, prévisible et peu coûteuse
      Aujourd’hui, il y a Wrangler, Feature Store, RStudio, l’expérience utilisateur de la console notebook est horrible, et en interne plusieurs services déplacent les données et les facturent

  • J’ai dû, par contrainte, envoyer des requêtes HTTP brutes au lieu d’utiliser le SDK AWS obèse, et ça échouait avec l’en-tête content-type: application/json, mais ça fonctionnait avec content-type: application/x-amz-json-1.0
    J’aimerais vraiment qu’on en finisse avec ce genre de nonsense

    • J’ai ressenti la même chose sur presque toutes les parties d’AWS que j’ai touchées au cours de ma carrière
      C’est inutilement massif, excessivement complexe, ou rempli d’implémentations maison bizarres sans bénéfice clair
    • Franchement, c’est juste des détails internes qui fuient à l’extérieur
      En interne, la plupart des applis utilisent l’ancien framework Coral, avec ce format JSON aux formes d’entrée, de sortie et d’erreur bien définies

  • Tous les guides officiels AWS sont conçus pour vous faire utiliser autant de services AWS que possible, et le risque de dépenses augmente d’autant
    Il faut regarder avec un esprit extrêmement critique tout ce qu’AWS recommande : les valeurs par défaut de l’interface graphique, les outils CLI, les guides, les architectures recommandées, etc.
    Ce n’est pas pour rien qu’il existe des postes très bien rémunérés dont le rôle est d’aider leurs collègues à utiliser AWS de manière rentable et avec un faible niveau de risque dans l’entreprise

    • Oui
      Pour les petits déploiements ou les tests, les éléments les plus chers sont presque toujours les à-côtés, ou les nouveaux services recommandés à la place d’alternatives plus simples

  • Si vous utilisez OpenSearch uniquement à cause des requêtes de boîte englobante sur geo_point, pourquoi pas PostgreSQL + PostGIS ?
    https://postgis.net/docs/using_postgis_query.html

  • Je pense que cette configuration sans friction, cette expérience utilisateur et ces interfaces peu intuitives, cette faible méfiance vis-à-vis de l’enregistrement d’une carte bancaire, et cette facturation groupée entre services comme AWS Batch + Lambda + EC2 font partie du business model
    Je ne sais pas trop comment le formuler, mais c’est un peu comme un parc d’attractions moderne où l’on paie l’entrée, puis chaque manège séparément, et même les toilettes en plus

    • J’ai le même ressenti
      Le modèle de facturation du cloud transfère la responsabilité vers l’utilisateur au nom de la « flexibilité » et de la « personnalisation »
      Imaginez une société de location de voitures qui facturerait chaque composant à la milliseconde — rotation de l’arbre à cames du moteur, rotation des pneus, activation des essuie-glaces, durée de chauffe des sièges — tout en affirmant que le client « contrôle » sa consommation et son budget parce qu’il peut configurer des alertes pour chaque ligne
      C’est un modèle de coûts hostile et dangereux pour l’utilisateur dès les valeurs par défaut