Je suis revenu sur AWS, et j’ai compris à nouveau pourquoi je l’avais quitté

• J’ai soutenu AWS dès ses débuts, mais avec l’accumulation de frustrations comme un *système de facturation complexe et la complexité générale de la plateforme, j’ai fini par ne plus l’apprécier.
• Le coût élevé de DynamoDB, des frais d’egress atteignant 9 centimes par gigaoctet, ainsi qu’une facturation double ou triple pour les transferts de données internes restent, à mes yeux, chers et difficiles à comprendre.
• Je suis revenu pour tester Claude sur AWS Bedrock et effectuer un benchmark sur une machine à 192 cœurs, mais l’activité soudaine sur un compte dormant a déclenché une alerte de suspicion de compromission de sécurité, et le compte a été suspendu.
• À cause de cette suspension, même AWS WorkMail pour mon activité professionnelle a été interrompu, et malgré le plan de support gratuit, le compte n’a pas été rétabli pendant 4 jours.
• J’en suis arrivé à la conclusion qu’il fallait aussi migrer tous les services restés sur AWS et partir complètement.

---

Du soutien initial à AWS à la rupture

• Je soutenais fortement AWS depuis l’époque où la plateforme se limitait encore à des services plus modestes comme SQS, S3, EC2 et SimpleDB, et j’avais même organisé à Melbourne le premier événement local où un responsable AWS venu des États-Unis présentait AWS.
• Le cloud computing a été un grand tournant, permettant aux startups d’exploiter leur propre système informatique en quelques minutes sans avoir à installer ni gérer des systèmes dans un datacenter.
• Pendant environ 15 ans, j’ai profondément cru en AWS, mais avec le temps les éléments pénibles se sont accumulés, jusqu’au moment où j’ai cessé d’aimer AWS.

Les frustrations envers AWS accumulées avec le temps

• Bibliothèques clientes et transition Python

  • Pendant ses six premières années, AWS n’a pas développé ses propres bibliothèques clientes et a laissé la communauté implémenter des bibliothèques pour des langages comme Python, ce qui a été perçu comme un transfert de charge vers des développeurs donnant gratuitement de leur temps.
  • Le fait qu’AWS ait mis beaucoup trop longtemps à passer de Python 2 à Python 3 est aussi resté une grande source de frustration.

• DynamoDB et l’expérience des coûts

  • Dès le premier jour d’utilisation de DynamoDB, une facture de 75 dollars est tombée, et au-delà du coût, le système lui-même m’a semblé conçu de la pire manière imaginable.

• Coûts de transfert de données et facturation complexe

  • Les frais de sortie de données d’AWS étaient autrefois de 20 centimes par Go, puis sont descendus à 9 centimes par Go, mais ils restent selon moi extrêmement élevés.
  • Des frais s’appliquent aussi aux mouvements de données entre systèmes internes à AWS, avec une structure qui peut donner l’impression d’une double ou triple facturation, au point qu’il est difficile d’éviter les pièges tarifaires sans une compréhension approfondie.

• IAM et la complexité d’ensemble

  • IAM (système d’authentification et de contrôle d’accès) est un système d’une complexité extrême.
  • Les défenseurs d’AWS affirment qu’il faut utiliser AWS parce qu’exploiter soi-même Linux, le matériel, le réseau et la sécurité est trop complexe, mais j’estime que presque tous les pans d’AWS portent eux aussi une complexité énorme, si bien qu’au final il faut aussi une équipe de spécialistes coûteuse.

• AWS Lambda et le verrouillage fournisseur

  • J’ai été séduit par la promesse de « montée en charge », mais les cold starts lents et l’énorme complexité de développement posent problème.
  • Il n’y a pas d’avantage concret par rapport à un serveur web géré soi-même, et les inconvénients sont plus nombreux ; au moment de quitter AWS, Lambda a été la partie la plus difficile à démonter, à tel point que le vendor lock-in y est sévère.

• Projets open source et revenus de l’hébergement

  • Selon moi, AWS a poussé OpenSearch, Valkey et DocumentDB alors même que des projets comme Elasticsearch, Redis et MongoDB avaient exprimé leur refus de voir leur travail copié et monétisé.
  • Après que ces communautés et entreprises ont créé le marché, AWS en a capté les revenus d’hébergement, ce qui a, selon moi, favorisé la montée de licences défensives comme la SSPL, l’Elastic License, la RSAL et des modèles source-available.

Les quelques services laissés après avoir quitté AWS

• Une fois mon attachement à AWS rompu, j’ai tout déplacé hors d’AWS et presque entièrement fermé mes comptes.
• J’ai toutefois laissé en place certains services qui me semblaient alors être de vraies bonnes solutions.
• Les domaines sont restés sur Route53, certaines sauvegardes sur S3, et l’e-mail professionnel sur AWS WorkMail.
  • AWS WorkMail avait déjà notifié une fin de service dans les 12 mois.

Pourquoi je suis brièvement revenu sur AWS

• Je me suis récemment reconnecté à AWS pour de la recherche et des tests.
• Je voulais voir à quel point Claude/Anthropic fonctionnait bien sur AWS Bedrock ; avec Claude Code, le fonctionnement est le même, mais c’est plus lent et bien plus cher qu’un abonnement Anthropic.
• Mon équipement personnel le plus rapide disposait d’un CPU 20 cœurs et de 32 Go de RAM, et je voulais benchmarker la vitesse d’exécution de mon code sur une machine à 192 cœurs avec 1 To de RAM.
• Il y a environ un mois, les tests sur AWS Bedrock se sont terminés sans problème, puis tout a été arrêté.
• AWS Bedrock peut être utile si l’on a besoin de confidentialité, mais à cause du coût je n’utiliserai plus Claude via AWS Bedrock.

Restriction du compte pendant un test EC2 Spot

• Ensuite, alors que je faisais tourner pendant environ 3 heures une instance EC2 Spot à 192 cœurs, j’ai reçu un e-mail d’AWS indiquant « Suspected security breach of your account ».
• Je pense que le fait qu’un compte presque inactif se mette soudainement à consommer des ressources de calcul coûteuses a probablement déclenché une alerte de sécurité interne chez AWS.
• Je comprends et j’évalue positivement l’intention d’AWS de vouloir protéger ses utilisateurs.
• Mais AWS a suspendu ou restreint le compte, et en conséquence mon adresse e-mail professionnelle principale, hébergée sur AWS WorkMail, a cessé de fonctionner.
• Plus personne ne pouvait m’envoyer d’e-mail, et je ne pouvais plus créer aucune ressource AWS, ce qui m’a empêché de poursuivre les tests prévus.

Réponse du support et délais

• J’ai répondu à l’alerte du support AWS pour expliquer que le compte n’avait pas été piraté et qu’il n’y avait ni incident ni anomalie de facturation, mais je n’ai reçu aucune réponse.
• Comme je n’avais pas de support premium, j’ai dû attendre le délai de réponse de 24 heures annoncé par AWS, et même après 3 jours aucune réponse du support n’était arrivée.
• Après avoir demandé de l’aide sur le forum AWS, on m’a conseillé de suivre les instructions reçues par e-mail et d’utiliser le chat plutôt que le web.
• J’ai effectué toutes les actions demandées, comme changer le mot de passe, supprimer les jetons d’accès et vérifier la facturation ; après environ 30 minutes d’attente avant d’obtenir le chat, j’ai eu un long échange avec un représentant AWS.
• Le représentant semblait satisfait et a dit qu’il demanderait au service interne concerné de traiter le dossier, mais 24 heures plus tard la restriction n’était toujours pas levée.
• Huit heures plus tard, quand j’ai relancé, on m’a seulement répondu « veuillez patienter ».

Une conclusion confirmée une nouvelle fois

• Quatre jours après la restriction du compte, il me restait toujours des tâches que je voulais tester sur une grosse machine, et je me suis même mis à redouter de devoir refaire une demande de « quota » pour cela.
• Le système d’e-mail professionnel ne fonctionne toujours pas.
• Cette expérience de retour a confirmé à nouveau les raisons pour lesquelles j’avais quitté AWS, et j’ai conclu qu’il fallait sortir d’AWS WorkMail, transférer aussi les domaines de Route53, et ne plus jamais revenir.
• J’étais très heureux d’avoir déjà quitté AWS auparavant, mais le système d’e-mail que j’avais gardé par confiance a été interrompu au moment de mon retour sur AWS, causant un préjudice bien réel.
• AWS lèvera peut-être un jour la restriction du compte, mais impossible de savoir quand.

[GN⁺]

Réactions sur Hacker News

• Il y a quelques années, j’ai rejoint une entreprise pour diriger l’équipe de développement, avec pour consigne de lancer le produit en moins de 3 mois. En voulant ajouter une nouvelle machine sur AWS, le fait que le prix ne soit pas visible dans l’interface m’a semblé être en soi le signe d’une relation hostile et extractive.
  Il fallait ouvrir séparément le tableau des spécifications et la grille tarifaire pour les comparer, et d’après mes expériences passées, si je voyais ce genre de signal sans partir, la suite relevait de ma responsabilité.
  J’ai donc créé un compte DigitalOcean, tout migré, configuré le déploiement CI/CD dessus, puis consacré les deux mois restants au produit, avec un lancement un mois avant la date promise.
  J’avais vu autrefois une vidéo où l’on creusait un trou près d’une rivière et on le reliait à la rivière par un tuyau pour que les poissons entrent d’eux-mêmes dans le piège ; ça m’est resté comme l’image parfaite de ce qui arrive quand on choisit le chemin de moindre résistance et qu’on ne revient pas sur ses erreurs

  • Une des choses que j’apprécie chez Azure, c’est qu’ils ne te martèlent pas le prix à chaque création d’élément, mais qu’il y a en général un bon équilibre avec l’affichage du prix pour les éléments qui peuvent coûter cher.
    Je n’ai encore jamais eu de mauvaise surprise sur la facture
  • La culture d’ingénierie d’Amazon est assez centrée sur des produits pilotés par les ingénieurs, donc j’ai l’impression que les développeurs y portent souvent aussi la responsabilité de l’UX et du flux.
    J’avais recruté un junior qui venait de finir un stage chez AWS ; il m’a montré un tableau de bord qu’il avait conçu seul pendant l’été, sans aide produit ni design, et c’était vraiment affreux.
    Certains développeurs ont un bon sens produit/UX, mais la majorité est sérieusement faible en UX, donc c’était sans doute moins intentionnel qu’un simple produit d’une mauvaise culture UX
  • La bonne approche, c’est de choisir un fournisseur d’infrastructure qui aide à livrer.
    AWS est bien, mais pas adapté à tout le monde ; il existe un espace entre des services comme Heroku et le bare metal, où beaucoup de maintenance est abstraite tout en laissant une part de contrôle sur l’architecture de montée en charge.
    Autrement dit, en tant que cloud provider, AWS aide à scaler, mais ce n’est pas l’outil idéal pour bâtir la configuration la plus simple et la moins chère.
    Si on a du financement VC et un discours orienté croissance, AWS peut être un choix prudent, et grâce aux crédits startup de 2 ans via certains accélérateurs, on peut se concentrer sur la construction pendant les 18 premiers mois plutôt que sur le budget infra.
    Si on est en bootstrapping ou développeur indé, mieux vaut choisir quelque chose de simple et abordable ; Hetzner ou DigitalOcean suffisent largement
  • AWS a un calculateur de prix plutôt correct et des préréglages utilisables, mais c’est évidemment une application totalement séparée.
    Amazon veut probablement qu’il y ait un peu de friction pour consulter facilement les prix, mais la raison principale ressemble surtout à la loi de Conway.
    AWS continue de refléter son organigramme dans ses produits
  • Je suis d’accord dans une certaine mesure, mais la tarification AWS n’est pas assez simple pour qu’un chiffre statique affiché dans l’UI suffise à dire ce que vous allez payer.
    Si ouvrir deux onglets pour comparer les coûts vous gêne, il vaut peut-être mieux éviter non seulement AWS mais tous les cloud providers.
    Dès qu’on ajoute NAT Gateway, CloudFront, S3, l’auto-scaling, des load balancers, le calcul des coûts relève plus de l’art que d’une science exacte.
    Si vous n’utilisez pas ce genre de choses, il y a peu de raisons d’aller sur AWS, et les fournisseurs de VPS bon marché ne manquent pas

• Si l’on ne parle que d’OpenSearch et de Valkey, l’explication selon laquelle « AWS a créé des forks et provoqué des changements de licence » est totalement inversée.
  AWS n’a forké qu’après que les projets upstream ont changé de licence, et Valkey en particulier a été créé par des membres de l’ancienne équipe principale de Redis

  • Beaucoup de ces projets fonctionnent avec un modèle où le produit principal est open source, puis les revenus viennent des services avancés, de l’installation, de la maintenance ou du fully managed.
    AWS les a contournés en proposant un service managé complet, donc sur ce point je me range du côté des créateurs du projet.
    En gros, AWS leur a pris leur gagne-pain, et ils ont été forcés de changer de licence
  • Ce changement de licence lui-même était une réponse au fait qu’AWS monétisait leur travail d’une manière insoutenable pour le projet upstream
  • Je me demande quel impact cela aurait si Amazon reversait ne serait-ce qu’1 centime par période de facturation aux créateurs et mainteneurs des logiciels open source qu’ils vendent.
    Je me demande aussi combien cela représenterait pour les équipes open source, et si cela pourrait les encourager à contribuer à l’amélioration du produit sans prise de risque
  • Depuis la première fois où j’ai envoyé un patch à Redis, et qu’un committer a ignoré mon message pour intégrer ce patch sous son propre nom, j’ai perdu une grande partie de ma sympathie pour la philosophie de nombreux projets open source.
    Ils méritaient Valkey.
    Je me souviens encore de JBoss et de Marc Fleury
  • Il est évident qu’AWS n’a forké qu’après le changement de licence destiné à l’empêcher de gagner de l’argent avec le code de ces projets.
    C’est précisément tout l’enjeu

• J’ai fait plusieurs allers-retours entre services cloud et self-hosting.
  Au début, j’utilisais Vercel ; comme le projet était en Next.js, l’expérience était correcte, mais payer 20 dollars par mois pour un projet avec moins de 100 utilisateurs me semblait cher pour un service avec peu d’exigences de performance.
  Ensuite, j’ai monté mon propre serveur avec Hetzner et Coolify : comme Coolify est open source, je ne payais que le coût du VPS, et 5 dollars par mois suffisaient pour faire tourner une instance PostgreSQL et un serveur web.
  Mais la maintenance de PostgreSQL et Redis demandait toujours beaucoup de travail, et même avec des conteneurs Docker, faire passer des variables système et d’environnement entre services restait pénible.
  J’ai donc fini par migrer vers Cloudflare Workers, D1 Database et Cloudflare KV, que je peux appeler directement depuis les Workers sans avoir à transmettre de variables d’environnement.
  L’expérience de développement local est bonne, le prix raisonnable, et depuis je continue d’utiliser toute la gamme Cloudflare

  • Les offres de Cloudflare se rapprochent davantage de ce que j’attendais d’AWS.
    Le déploiement de fichiers et d’applications full-stack basiques y est beaucoup plus simple, et AWS est devenu bien plus compliqué que le self-hosting
  • Je me demande si Docker a vraiment facilité l’administration de PostgreSQL.
    Le seul problème que j’ai avec PostgreSQL, c’est un peu de travail de migration lors du passage à une nouvelle version majeure.
    Je me demande aussi si le fait de transmettre des variables système et d’environnement entre services n’est pas devenu plus difficile à cause de Docker
  • J’avais envie d’aimer Cloudflare Workers, et il y a sans doute de bonnes raisons techniques, mais le fait de devoir passer par un projet Wrangler pour des tâches comme l’activation de l’e-mail donnait l’impression d’être à deux doigts d’un lock-in plateforme.
    Pour autoriser l’e-mail, il fallait configurer les bindings nécessaires, mais on ne pouvait pas le faire depuis la console, et une fois que Wrangler les avait configurés, on avait l’impression de ne même plus pouvoir les voir

• Je suis surpris que l’auteur déteste DynamoDB.
  C’est un des services AWS que je préfère : très disponible, sans charge d’exploitation, et à chaque fois que je l’ai utilisé le coût est resté assez bas.
  En revanche, il faut passer du temps à concevoir le modèle de données à l’avance, ce qui suppose de lire et comprendre la documentation du service

  • DynamoDB est très bon si on l’utilise comme prévu.
    Il faut le voir comme un stockage clé-valeur relativement simple, avec une bonne persistance et une capacité de montée en taille de table presque infinie, et non comme une base SQL.
    Le moyen le plus simple de se retrouver avec 75 dollars de facture pour du code prototype, c’est de faire du vibe coding en le traitant comme une base SQL avec des JOIN et des GROUP BY.
    Là où il brille vraiment, c’est quand on a besoin d’une ou deux petites tables de stockage persistant sans vouloir gérer tout un SGBDR, ou quand on a une très grosse table à interroger simplement sans vouloir la faire entrer de force dans un modèle RDBMS
  • DynamoDB, Lambda et plusieurs autres services répondent à des cas d’usage très spécifiques.
    Il ne faut pas utiliser un joyeux key-value store comme une base de données
  • Il y a quelques années, en développant une application, j’avais besoin d’une base pour stocker environ 50 millions d’enregistrements, avec autour de 10 000 lectures + écritures par mois, et un index.
    Le coût de chargement initial était d’environ 50 dollars, puis la maintenance revenait à quelque chose comme 10 centimes par mois

• Ce genre de billet me fait toujours sourire.
  C’est juste et faux à la fois, et un système doit être « aussi simple que possible, mais pas plus simple ».
  Si vous pensez pouvoir survoler les détails, vous paierez plus tard en complications.
  IAM, c’est simplement compliqué.
  Je n’ai pas en tête d’exemple où utilisateurs, groupes, rôles, politiques, fournisseurs d’identité et OIDC auraient été mis en œuvre de façon vraiment simple.
  J’ai vu quelqu’un s’opposer jadis à l’adoption de Kubernetes parce que « c’est trop complexe », puis finir par réinventer Kubernetes de façon médiocre et bancale avec Vault, Consul, systemd, Nomad, iSCSI, Ansible, Jenkins, Puppet, Bash, de la salive et de la ficelle, en accumulant les erreurs.
  On pense parfois ne pas avoir besoin d’une fonctionnalité, puis on finit par en avoir besoin.
  Pour avoir été seul responsable infra dans une startup, AWS reste dans les capacités d’apprentissage de la plupart des gens, et ses pires aspects peuvent généralement être évités.
  Si vous n’aimez pas Lambda, ne l’utilisez pas ; prenez EKS, ECS ou EC2

  • Vu de l’intérieur, IAM propose des milliers d’options, mais au fond il s’agit de « à quoi ce rôle peut-il accéder et que peut-il faire (action + ressource) ? » et de « qui peut accéder à ce rôle ? ».
    Vu de très haut, c’est tout.
    Ce qui est bien avec IAM, c’est que cela s’applique exactement de la même manière à l’externe et à l’interne.
    Les équipes AWS internes n’ont pas plus d’accès par défaut ; si elles obtiennent le droit de faire quelque chose dans un compte client pour exécuter un service donné, c’est parce que le client a autorisé cet accès via une relation de confiance IAM avec le principal de service, et le client peut le voir et l’auditer.
    Par exemple, Lambda a un rôle Lambda, parce qu’on ne veut pas que le service Lambda puisse lire un bucket S3 simplement sous prétexte que « nous sommes AWS donc nous avons automatiquement accès ».
    Même les accès internes à AWS peuvent être clairement vus et contrôlés par le client
  • Le schéma du « X est trop complexe », suivi d’une réinvention bâclée de X, est étonnamment fréquent dans la tech et le logiciel.
    Certaines choses sont désormais des standards évidents, et pourtant beaucoup refusent toujours de consacrer du temps à vraiment les apprendre
  • AWS peut coûter plus cher que le self-hosting, mais l’économie réalisée est faible face au coût d’ingénierie.
    Si un bon ingénieur infra passe deux mois sur une configuration OVH « pour économiser de l’argent », cela revient plus cher que ce qu’on aurait économisé en n’utilisant pas simplement Fargate ou RDS

• Je me demande à quel moment on commencera à entendre la même chose à propos de sociétés comme Anthropic ou OpenAI.
  Le mouvement actuel autour de l’IA sent un peu les débuts d’AWS : tout le monde monte à bord, puis réalisera plus tard qu’il a accumulé une grosse dépendance difficile à retirer

• Lambda est vraiment génial, et c’est à mon avis la meilleure manière d’exploiter un service de déploiement avec des itérations rapides sans se prendre la tête.
  Il n’est pas nécessaire de partir en microservices ni de découper son code en des milliards de petits dépôts.
  Tant qu’on n’attend pas de partager l’état du serveur entre les requêtes, on peut porter un serveur web standard sur Lambda

• Je ne travaille pas dans ce domaine, donc AWS ne me sert qu’occasionnellement pour des projets perso amusants, et à chaque fois c’est un cauchemar.
  J’essaie juste de monter un serveur de jeu de cartes pour expérimenter, pas de créer une nouvelle institution financière, et pourtant tout semble pensé pour être prêt à scaler à l’infini dès demain, avec comme hypothèses une organisation de mille personnes et un budget VC.
  Heureusement, des services comme Netlify mettent une couche par-dessus, ce qui évite d’avoir à faire bouillir l’océan.
  Il faudra peut-être qu’un jour j’apprenne vraiment IAM, les VPN et je ne sais quoi d’autre, mais d’ici là j’ai l’impression que mes yeux vont sortir de leurs orbites chaque fois que je touche à AWS

  • Il suffit de lancer un VPS brut sur EC2 ou Lightsail, d’y attacher une IP publique, et c’est terminé.
    Il n’y a aucune obligation de mettre en œuvre tous les patterns enterprise
  • Il est impressionnant de voir à quel point Heroku avait déjà visé juste, il y a près de 20 ans, sur ce dont la plupart des applications web avaient besoin
  • Si vous n’avez jamais touché à Azure, vous pouvez croire qu’AWS seul ressemble à un cauchemar
  • Je suis passé à Cloudflare et j’ai vraiment eu l’impression de respirer à nouveau.
    Il y a tout ce qu’il faut et le prix reste raisonnable
  • AWS ne vise pas les projets personnels mais l’entreprise.
    Les projets personnels finissent surtout par ne faire compter que le prix, et n’apportent donc pas à AWS un chiffre d’affaires significatif

• Depuis 2023, les équipes techniques sont vidées de manière systématique chez AWS.
  Cela s’est fait via de grands licenciements ou deux vagues de plans d’amélioration des performances, et beaucoup de collègues compétents côté avant-vente ou support ne sont plus chez AWS.
  À l’inverse, j’ai souvent vu rester et être promues des personnes au parcours professionnel bien plus flou.
  AWS s’utilise à ses risques et périls, et Paul Vixie ne viendra pas vous sauver

• Depuis longtemps, ElastiCache me dérange particulièrement.
  RDS apporte de la valeur avec la scalabilité, des réglages raisonnablement optimisés et des sauvegardes dont on n’a pas à se soucier, donc je peux accepter de payer pour ça.
  Mais ElastiCache apporte très peu de valeur ajoutée, alors que son prix paraît abusif.
  C’est plus lent, moins optimisé et moins stable qu’une installation Redis standard ; et là où Redis sans configuration gère plusieurs bases, ElastiCache n’en gère qu’une seule.
  Il y a bien quelques améliorations de scalabilité, mais comme Redis standard sur des instances comparables dépasse tellement ElastiCache que ces gains ne sont en pratique presque jamais nécessaires

  • ElastiCache fait clairement partie des services pour lesquels le self-hosting mérite d’être envisagé.
    AWS n’y ajoute pas grand-chose en matière d’API ou de finition, tandis qu’à l’inverse Redis/Valkey fait partie des services les plus simples à héberger soi-même.