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

• J’ai soutenu AWS dès ses débuts, mais avec l’abandon des bibliothèques clientes à la communauté pendant un temps, le retard de la transition vers Python 3, la facturation complexe et IAM, ainsi que le verrouillage d’AWS Lambda, les frustrations se sont accumulées au point que je n’apprécie plus AWS
• Après avoir utilisé DynamoDB, je me suis retrouvé avec une facture de 75 dollars en une journée. Le coût de sortie des données est bien passé de 20 à 9 cents par Go, mais le fait de facturer encore les transferts de données internes reste, à mes yeux, cher et difficile à comprendre
• Après avoir quitté AWS, j’ai fermé la plupart de mes comptes, mais j’ai conservé les domaines Route53, une partie des sauvegardes S3 et AWS WorkMail. J’ai ensuite reçu un avis indiquant que WorkMail serait arrêté dans les 12 mois
• Récemment, je me suis reconnecté à AWS pour tester le fonctionnement de Claude/Anthropic sur AWS Bedrock et un test EC2 Spot avec 192 cœurs et 1 To de RAM. J’ai conclu que Bedrock fonctionne de la même manière, mais plus lentement et pour un coût bien supérieur à un abonnement Anthropic
• Pendant un test EC2 Spot d’environ 3 heures, après une alerte Suspected security breach, mon compte a été restreint, bloquant mon e-mail professionnel sur WorkMail et la création de ressources. Même après les démarches demandées et un échange avec le support, la restriction n’a pas été levée pendant 4 jours, ce qui m’a décidé à migrer aussi AWS WorkMail et Route53

---

Du soutien initial à AWS à la rupture

• Je soutenais fortement AWS à l’époque où l’offre se limitait à quelques services comme SQS, S3, EC2 et SimpleDB, et j’ai organisé à Melbourne le premier événement où un représentant AWS venu des États-Unis est venu présenter AWS
• Le cloud computing a représenté un grand changement, en permettant aux startups d’exploiter leur propre système informatique en quelques minutes sans avoir à installer et gérer des systèmes dans un datacenter
• J’ai fortement cru en AWS pendant environ 15 ans, mais au fil du temps, les irritants se sont accumulés, jusqu’au moment où je me suis rendu compte que je n’aimais plus AWS

Les griefs accumulés contre AWS au fil du temps

• Bibliothèques clientes et transition Python

  • Pendant ses six premières années, AWS n’a pas créé ses propres bibliothèques clientes et a laissé la communauté implémenter les bibliothèques pour des langages comme Python, ce qui a été perçu comme une manière de faire porter la charge à des programmeurs donnant gratuitement de leur temps
  • Le temps excessif qu’AWS a mis pour passer de Python 2 à Python 3 est aussi resté un motif majeur de mécontentement

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

  • Après avoir utilisé DynamoDB, j’ai reçu une facture de 75 dollars à la fin de la journée, et au-delà du coût, le système lui-même m’a semblé conçu de la pire façon imaginable

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

  • Les frais de sortie des données d’AWS étaient autrefois de 20 cents par Go et sont ensuite descendus à 9 cents par Go, mais cela reste selon moi très cher
  • Des frais s’appliquent aussi aux mouvements de données entre systèmes internes à AWS et, selon les cas, la structure peut donner l’impression d’une double ou triple facturation, au point qu’il est difficile d’éviter les pièges tarifaires sans en maîtriser profondément les détails

• IAM et la complexité générale

  • IAM est un système qui gère l’authentification et les règles d’accès, mais il est perçu comme excessivement complexe
  • Les défenseurs d’AWS disent 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 presque tous les domaines d’AWS portent eux aussi une énorme complexité, au point qu’il faut finalement une équipe d’experts coûteuse

• AWS Lambda et le verrouillage

  • AWS Lambda met en avant la scalabilité, mais il fallait accepter des temps de démarrage lents et une forte complexité de développement
  • Je n’y voyais pas de véritable avantage par rapport à l’exploitation de mon propre serveur web, mais beaucoup d’inconvénients, et lors de mon départ d’AWS, la partie la plus difficile à annuler a été AWS Lambda
  • L’usage d’AWS Lambda m’a laissé l’impression concrète que le verrouillage fournisseur existe réellement, comme un choix pour lequel il faut continuer à se convaincre soi-même que c’est mieux

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

  • Je considère qu’AWS a poussé OpenSearch, Valkey et DocumentDB alors même que des projets comme Elasticsearch, Redis et MongoDB avaient montré qu’ils ne voulaient pas voir leur travail copié et monétisé
  • Après que ces communautés et entreprises ont créé le marché, AWS a capté les revenus des services hébergés, ce qui a selon moi favorisé la multiplication de licences défensives comme la SSPL, l’Elastic License, la RSAL et des modèles source-available

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

• Une fois mon attachement à AWS rompu, j’ai tout déplacé hors d’AWS et fermé presque tous mes comptes
• Je n’ai conservé que quelques services que je considérais alors comme de vraies bonnes solutions
• Ce que j’ai gardé, c’étaient les domaines sur Route53, une partie des sauvegardes sur S3 et AWS WorkMail
• J’ai ensuite reçu une notification indiquant qu’AWS WorkMail serait arrêté 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 vérifier dans quelle mesure Claude/Anthropic fonctionnait bien sur AWS Bedrock, et dans le cas de Claude Code, j’ai estimé que cela fonctionnait pareil, mais plus lentement et pour un coût bien supérieur à un abonnement Anthropic
• Le matériel le plus rapide que j’avais chez moi disposait d’un CPU 20 cœurs et de 32 Go de RAM, et je voulais benchmarker la vitesse d’exécution du code sur une machine 192 cœurs avec 1 To de RAM
• Environ un mois plus tôt, mon test d’AWS Bedrock s’était terminé sans problème, et j’avais tout arrêté après les essais
• AWS Bedrock peut être utile si l’on a besoin de confidentialité, mais à cause du coût, je ne pense pas réutiliser Claude sur AWS Bedrock

Restriction de compte pendant le test EC2 Spot

• Ensuite, alors que je lançais une instance EC2 Spot à 192 cœurs pour un test d’environ 3 heures, j’ai reçu un e-mail d’AWS indiquant “Suspected security breach of your account”
• J’estime qu’il est possible que l’alerte de sécurité interne d’AWS ait été déclenchée parce qu’un compte presque inactif s’est soudain mis à consommer des ressources de calcul coûteuses
• Je comprends et j’évalue positivement l’intention d’AWS de protéger ses utilisateurs
• Mais AWS a suspendu ou restreint le compte, avec pour conséquence que mon adresse e-mail professionnelle principale utilisée sur AWS WorkMail a cessé de fonctionner
• Plus personne ne pouvait m’envoyer d’e-mail, et je ne pouvais plus créer la moindre ressource AWS, ce qui m’a aussi empêché de poursuivre le test initialement prévu

Réponse du support et retards

• J’ai répondu à l’alerte du support AWS pour signaler que mon compte n’avait pas été piraté et qu’il n’y avait ni problème 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, mais même après 3 jours, le support AWS n’avait toujours pas répondu
• 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 démarches demandées, notamment le changement de mot de passe, la suppression des jetons d’accès et la vérification de la facturation. Après environ 30 minutes d’attente avant d’être mis en relation via le chat, j’ai eu un long échange avec un représentant AWS
• Le représentant semblait satisfait et a dit qu’il demanderait à l’équipe interne concernée de traiter le dossier, mais même après 24 heures, la restriction n’avait pas été levée
• Huit heures plus tard, quand j’ai relancé, on m’a seulement répondu d’attendre

Une conclusion confirmée une nouvelle fois

• Quatre jours après la restriction du compte, j’avais toujours des tâches que je voulais tester sur de grosses machines, et je me suis mis à craindre de devoir à nouveau faire une demande de “quota” pour cela
• Mon système de messagerie professionnel ne fonctionnait toujours pas
• Cette expérience de retour a confirmé une nouvelle fois pourquoi j’avais quitté AWS, et j’ai décidé de sortir d’AWS WorkMail et de transférer aussi mes domaines Route53 pour ne plus jamais revenir
• J’étais très heureux d’avoir déjà quitté AWS par le passé, mais le fait que le système de messagerie auquel je faisais confiance et que j’avais conservé ait été interrompu au moment de ce retour sur AWS a été vécu comme un échec
• 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.