AWS en 2025 : ce que vous pensez savoir, mais qui est désormais faux

 (lastweekinaws.com)
8 points par GN⁺ 2025-08-21 | 3 commentaires | Partager sur WhatsApp
  • Les services clés d’AWS évoluent rapidement
  • Des fonctions majeures comme EC2, S3 et Lambda offrent désormais des performances et une flexibilité qui dépassent les attentes d’autrefois
  • De nombreux changements et optimisations ont aussi eu lieu dans le réseau, l’authentification et les stratégies de réduction des coûts
  • Des anciens billets de blog ou informations obsolètes peuvent encore semer la confusion
  • Connaître les dernières mises à jour et les politiques actuelles est indispensable pour bien exploiter AWS

AWS 2025 : un présent différent des idées héritées du passé

  • AWS est une plateforme cloud avec près de 20 ans d’existence, et les « évidences » autour de ses services n’ont cessé d’évoluer
  • Même pour les utilisateurs expérimentés, le rythme des changements rend difficile le suivi des nombreuses améliorations des fonctions essentielles
  • Comme beaucoup de billets de blog continuent encore à diffuser des informations anciennes, il est important de bien comprendre ce qui a réellement changé dans les configurations actuelles

EC2

  • Il est désormais possible de modifier les groupes de sécurité et les rôles IAM d’une instance EC2 sans interruption
  • Sur une instance en cours d’exécution, on peut redimensionner, attacher ou détacher des volumes EBS
  • Il est désormais possible de forcer l’arrêt ou la terminaison d’instances EC2 récentes, sans avoir à attendre un long délai d’expiration
  • La migration à chaud entre hôtes physiques a été introduite, ce qui rend beaucoup plus rares les alertes de dégradation des performances d’instance
  • La fiabilité des instances a fortement progressé, et il est désormais très rare qu’une instance disparaisse sans préavis comme autrefois
  • Les variations de prix des instances Spot sont devenues plus progressives, ce qui réduit le besoin de les surveiller en temps réel comme sur un marché spéculatif
  • Les cas nécessitant des instances dédiées sont devenus extrêmement rares (même un HIPAA BAA n’est presque plus nécessaire depuis près de 10 ans)
  • AMI Block Public Access est activé par défaut sur les nouveaux comptes (et s’applique depuis 2023 aussi aux comptes n’ayant possédé aucune AMI publique depuis plus de 90 jours)

S3

  • S3 n’est plus Eventually Consistent et fournit désormais une Read-After-Write Consistency
  • Il n’est plus nécessaire d’aléatoiriser le début des clés d’objet, ce qui réduit les préoccupations liées à la distribution des données et aux hotspots
  • Les ACLs (Access Control List) ne sont plus recommandées et sont désactivées par défaut sur les nouveaux buckets
  • Les nouveaux buckets ont Block Public Access activé par défaut
  • Le chiffrement des données stockées est appliqué automatiquement
  • Avant de devenir une classe de stockage de S3, Glacier était un service distinct ; il est désormais intégré, et il n’en reste que des traces dans la facturation et quelques détails similaires
  • Les coûts et délais de restauration Glacier sont devenus bien plus prévisibles et moins chers qu’auparavant. Les anciens récits effrayants sur les coûts de restauration ne sont plus d’actualité

Réseau (Networking)

  • EC2-Classic a complètement disparu
  • Les adresses IPv4 publiques ne sont désormais plus gratuites et sont facturées au même tarif que les Elastic IP
  • À la place de VPC Peering, de meilleures options ont émergé comme Transit Gateway, le partage de VPC/ressources et Cloud WAN
  • VPC Lattice et Tailscale permettent de résoudre facilement des problèmes réseau complexes
  • Le temps de propagation des mises à jour de CloudFront est passé d’environ 45 minutes à environ 5 minutes (même si cela peut encore sembler long lors de l’attente d’un déploiement CloudFormation)
  • ELB Classic facturait le trafic inter-AZ, tandis qu’ALB ne facture que les LCU. Il faut noter que NLB facture toujours le trafic inter-AZ
  • La prise en charge des groupes de sécurité a été ajoutée au Network Load Balancer
  • Les identifiants de zones de disponibilité (Availability Zone) différaient selon les comptes, mais il est désormais possible d’aligner les Zone ID avec Resource Access Manager

Lambda

  • La durée d’exécution de Lambda est passée de 5 minutes à 15 minutes, avec l’ajout de la prise en charge des images de conteneur (Docker), du stockage partagé EFS, de jusqu’à 10 Go de RAM et de /tmp 10 Go
  • La vitesse d’exécution des Lambda dans un VPC s’est nettement améliorée
  • Le problème des cold starts a été très largement atténué par rapport au passé

EFS

  • Le réglage des performances d’E/S d’EFS peut désormais être ajusté indépendamment de la capacité, ce qui évite d’avoir à remplir l’espace avec des données inutiles

EBS

  • Les nouveaux volumes EBS peuvent atteindre immédiatement leurs performances maximales s’ils ne contiennent pas de données initiales
  • Les volumes créés à partir d’un snapshot peuvent être lents lors de la première lecture des données ; il est donc recommandé de lire une fois l’ensemble du disque (des options plus rapides existent aussi)
  • Les volumes io1 peuvent être attachés simultanément à plusieurs instances EC2, mais cela n’est recommandé que dans des cas très particuliers

DynamoDB

  • Les champs vides sont désormais autorisés dans les éléments
  • Les performances sont devenues beaucoup plus stables, ce qui réduit le besoin de surveiller les hot keys avec des outils dédiés comme auparavant
  • Avec les changements de tarification, le mode On Demand est désormais plus pertinent pour la plupart des utilisateurs

Options de réduction des coûts (Cost Savings Vehicles)

  • Les Reserved Instances sont progressivement en voie de disparition, et les Savings Plans deviennent la norme. Les remises des Savings Plans ont baissé par rapport aux RI, mais leur flexibilité a augmenté
  • L’usage EC2 étant facturé à la seconde, il est rentable même pour des démarrages d’instance très courts
  • Cost Anomaly Detector détecte avec une excellente précision les schémas d’utilisation inattendus et il est gratuit
  • Compute Optimizer fournit des recommandations fiables pour divers types de ressources, y compris EBS. Les recommandations de Trusted Advisor manquent encore de cohérence

Authentification (Authentication)

  • L’attribution des droits via les rôles IAM est recommandée, tandis que les utilisateurs IAM ne conviennent plus vraiment qu’aux applications legacy
  • IAM Identity Center remplace AWS SSO pour l’accès aux comptes, ce qui entretient encore un peu de confusion
  • Il est possible d’enregistrer plusieurs appareils MFA sur le compte root
  • Il n’est pas nécessaire de configurer séparément des identifiants root pour les comptes membres d’une organisation

Divers (Miscellaneous)

  • La fiabilité et la durabilité de us-east-1 se sont nettement améliorées. Les pannes fréquentes d’autrefois sont désormais suffisamment rares pour faire la une
  • La dépréciation des services AWS reste rare, mais la tendance est à la hausse ; il faut donc réfléchir à la dépendance aux services mineurs
  • Le phénomène où le dernier point des données CloudWatch apparaissait anormalement bas à cause d’incohérences ne se produit plus
  • Depuis le compte root, il est possible de fermer directement les comptes membres AWS au sein d’une organisation

À lire aussi

3 commentaires

 
roxie 2025-08-23

Wow, ça a vraiment beaucoup changé.
 
howudoin 2025-08-23

Il n’est plus possible de choisir et d’utiliser un seul service AWS.
Pour faire quoi que ce soit, il faut tout relier et utiliser un peu de tout.
Ce n’est absolument pas simple.
Pour l’utiliser dans une startup, il faut prévoir non seulement le coût du cloud, mais aussi les coûts salariaux DevOps.
Si on veut le mettre en place correctement, la charge de travail explose au point de dévorer tout le temps de développement.
En plus, comme il y a de plus en plus de cas où il vaut mieux utiliser des services managés, on devient déjà dépendant de la plateforme au niveau du code.
 
GN⁺ 2025-08-21
Avis sur Hacker News
  • Voir que le "Block Public Access" de S3 s’applique désormais par défaut aux nouveaux buckets me semble être une décision évidemment correcte, vu le nombre énorme de fuites de données causées par des buckets S3 mal configurés. Mais parfois, je veux simplement créer un bucket S3 avec lecture publique pour servir des fichiers publiquement, et à chaque fois quelque chose a changé, l’ancienne recette ne fonctionne plus, et je dois tout réapprendre depuis le début.
    • Je dirais qu’il faut regarder de près le paramètre "Block Public Access". C’est une sorte de garde-fou pour éviter aux gens de faire de grosses erreurs. Même si vous définissez une bucket policy très laxiste ou une ACL (ancienne, mais encore utilisée), si Block Public Access est activé, l’accès public reste impossible. À l’inverse, si vous désactivez Block Public Access, vous pouvez très bien utiliser une bucket policy soigneusement conçue. La bucket policy détermine entièrement qui peut accéder à quoi. Bien sûr, à long terme, la policy peut être modifiée accidentellement, un rôle IAM inattendu peut être ajouté ou une trust policy peut changer, donc il faut aussi bien gérer cet aspect.
    • Dans ce genre de situation, j’utilise souvent un LLM. Je lui demande de lire la documentation et d’extraire les morceaux de code de démo disséminés dans la documentation officielle AWS. Une fois que je les ai, je lui demande aussi directement les adaptations personnalisées dont j’ai besoin.
    • J’ai une impression de déjà-vu, comme si on avait déjà fait ça avant. Il y a dix ans aussi, tout le monde laissait ses buckets ouverts, donc j’ai l’impression que ce genre de mesure existait déjà.
    • À cause de ce genre de changements, la question en entretien "Vous connaissez bien cette technologie ?" devient très ambiguë. La techno change tous les mois, donc j’aurais envie de demander : à partir de quand faut-il la connaître ?
    • Pour l’apprendre officiellement, on vous fait payer 250 $ pour passer un examen de certification.
  • Sur EC2, pouvoir changer de security group ou de rôle IAM sans arrêter l’instance existe déjà depuis plusieurs années. Les instances Spot étaient autrefois un marché d’enchères, mais les enchères ont disparu, ce qui est bien mieux : il n’y a plus de variations de prix brutales ni de situations où seuls certains utilisateurs y ont accès. Et avant, il fallait rendre aléatoire le préfixe des clés d’objets pour éviter les hotspots, mais ce n’est plus nécessaire aujourd’hui. Il m’a fallu du temps pour convaincre mes collègues, mais de toute façon ils ne stockaient que des fichiers minuscules, sans aucun rapport avec les goulets d’étranglement du backend S3. Lambda avait autrefois une limite de 5 minutes et ne supportait pas les images de conteneur ; maintenant, c’est 15 minutes d’exécution, images Docker, partage EFS, jusqu’à 10 Go de RAM et 10 Go d’espace /tmp. Une chose que j’ai découverte moi aussi, c’est que le scope global Python survit également, un peu comme /tmp.
  • Les restaurations Glacier n’ont plus besoin d’être douloureusement lentes. En imaginant la chose à la Amazon, j’avais autrefois l’idée que l’ancien Glacier tournait peut-être quelque part dans un vrai entrepôt logistique Amazon : quand on demandait une donnée, un opérateur allait chercher un support amovible sur une étagère et le branchait sur un serveur. C’était un peu comme les sauvegardes sur bande des anciens systèmes en temps partagé, où il fallait physiquement changer les bandes.
    • En réalité, il est probable qu’ils utilisaient du matériel automatisé type robot à bandes, exemple en photo. Ce n’est pas un humain mais un robot qui va chercher la bande, l’insère dans le lecteur, avance jusqu’à l’offset, lit, rembobine puis la range. Le temps d’attente vient du temps nécessaire pour aller chercher la bande, la rembobiner et attendre qu’un lecteur se libère. Ils devaient probablement, pour l’efficacité, traiter toutes les requêtes concernant une bande tant qu’elle était montée avant de la retirer.
    • Je ne peux pas parler publiquement des détails internes, mais je n’ai encore jamais vu quelqu’un deviner correctement la conception de Glacier. J’ai travaillé chez AWS autrefois, et ce que je peux dire, c’est que Glacier tournait de toute façon dans les mêmes datacenters que les autres services AWS. En ingénierie comme en product management, l’important est de bien gérer les attentes des clients. Si vous dites que la limite d’upload est de 10 et que vous laissez en envoyer 12, le client finira par s’attendre à pouvoir toujours en envoyer 12. La gestion des attentes est essentielle.
    • Comme les disques durs sont uniformes, j’imagine qu’un entrepôt de ce type serait automatisé par des robots. On fait appel à des humains plutôt pour gérer des objets non standards, de tailles ou de formes variées.
    • Quoi qu’il en soit, ce genre d’équipement est robotisé depuis des dizaines d’années.
  • Je ne peux plus me connecter à mon compte AWS parce que je n’avais pas configuré la MFA à l’avance. Mais pour obtenir un appareil, il faut d’abord se connecter. On m’avait prévenu à l’avance, mais une structure où l’on ne peut pas demander de dispositif MFA sans connexion est assez frustrante.
    • Il vaudrait sans doute mieux contacter le support.
      Contacter AWS Support
    • Ça ressemble à un problème que le support devrait pouvoir résoudre facilement.
  • Je pense qu’il y a beaucoup de gens comme moi : au lieu de continuer à suivre la manière AWS habituelle — toute la complexité d’API Gateway, des Lambda serverless et des rôles IAM à ajuster — j’ai maintenant envie de laisser tomber, de prendre simplement une VPS EC2 ou LightSail, un bucket S3, de brancher le domaine avec Route53, et de ne plus me soucier du reste.
    • Si vous n’utilisez que stockage + VPS, un VPS traditionnel coûte bien moins cher qu’AWS. Personnellement, ma philosophie est plutôt que si l’on choisit AWS, il faut l’utiliser pleinement et correctement. Je délègue à Amazon tout ce qui peut l’être pour gagner en efficacité et réduire les coûts. Step Functions, Lambda et DynamoDB ont dépassé leurs alternatives. En revanche, je trouve dommage que les développeurs exploitent moins bien qu’ils ne le pourraient l’optimisation propre au fournisseur.
    • En pratique, beaucoup d’acteurs du secteur ont aussi simplifié leur usage du cloud, notamment à cause des restrictions régionales des services ou de la nécessité d’avoir une facturation prévisible.
    • La gestion d’IAM prend tellement de temps que j’ai l’impression que le temps autrefois consacré à l’administration système est maintenant entièrement absorbé par la gestion des permissions. IAM est si difficile que, dans les faits, c’est une perte nette. Il doit exister un point d’équilibre entre le VPS et la gestion minimale des privilèges en serverless poussée à l’extrême. Fargate pourrait être ce point d’équilibre, donc je compte encore expérimenter en migrant davantage de choses.
  • J’aimerais qu’AWS se concentre davantage sur les "services de base mais essentiels" qu’il fait déjà bien, plutôt que de se disperser dans l’IA pour suivre les autres avec toutes sortes d’annonces. J’ai l’impression que la direction d’AWS a perdu le cap sur la GenAI, alors qu’ils savent bien construire l’infrastructure de base. Avec cette panique autour de l’IA, ils paraissent dispersés, et du point de vue du client c’est inconfortable.
    • La direction actuelle semble vouloir rendre l’infrastructure disponible à tous de façon simple, afin que chacun puisse choisir un modèle et l’utiliser immédiatement, sans complexité de setup.
  • Il est vraiment absurde que lorsqu’un bucket S3 se trouve dans la même région qu’un VPC, passer par l’internet public déclenche quand même des frais de NAT Gateway. Le défaut devrait clairement être l’opt-out, alors qu’aujourd’hui c’est de l’opt-in, probablement parce qu’AWS génère ainsi des revenus supplémentaires. Très peu d’utilisateurs doivent réellement vouloir le chemin actuel.
    • C’est conçu ainsi au nom de la sécurité par défaut. Si vous ne configurez ni NAT Gateway, ni VPC Gateway Endpoint (S3), ni autre sortie internet, votre workload ne peut pas accéder à S3. Le réseau doit être fermé par défaut, et si l’utilisateur construit quelque chose sans bien comprendre les chemins réseau, c’est de sa responsabilité. Il faut considérer qu’AWS ne fournit que des outils bruts d’Infrastructure as a Service (IaaS).
    • Le S3 VPC Gateway Endpoint sert précisément à cela, et il est gratuit.
      Documentation officielle AWS
    • Une fois qu’on a tout configuré — VPC, subnets, endpoints PrivateLink, etc. — ça paraît vraiment absurde. Ils ont même bien travaillé le nom PrivateLink (qui a aussi un sens technique), mais j’estime que ce genre de chose devrait être fourni par défaut sans configuration. Même dans le cas des subnets privés, l’accès à S3 et à d’autres services n’est-il pas de toute façon possible uniquement via PrivateLink ? Tout cela semble étrange.
    • Je pense que tous les VPC endpoints devraient être activés gratuitement par défaut. Le fait de payer en plus pour utiliser l’API de leurs propres services est un peu excessif.
    • C’est fait pour segmenter les prix. Les clients peu sensibles aux coûts ne s’en préoccupent pas, ceux qui y font attention essaient de réduire leurs dépenses, et même dans ce cas, ils sont souvent quand même obligés d’utiliser AWS.
  • Cet article m’a rassuré. Je m’inquiète toujours qu’Amazon change brutalement quelque chose et force une migration, mais j’utilise mes instances EC2 depuis 2013 pratiquement sans avoir à m’en occuper. C’est rassurant de voir qu’il n’y a pas eu de changement imprévu.
  • Le fait que les Availability Zones aient autrefois un mapping aléatoire selon les comptes est stupéfiant.
    • C’était pour répartir la charge. Si plusieurs comptes choisissaient tous une AZ précise comme 1b, cela permettait tout de même de répartir la charge physique réelle. Plus tard, ils ont fourni des noms canoniques par AZ, probablement parce que les comptes qui créaient des hotspots n’étaient pas les mêmes que ceux qui avaient besoin de métadonnées.
    • J’imagine que l’objectif était d’éviter qu’avec les paramètres par défaut tout le monde choisisse us-east-1a et concentre ainsi la charge sur une seule AZ.
    • Au début, c’était bon pour l’équilibrage, mais quand il fallait connecter plusieurs comptes entre eux sur le réseau (PrivateLink, etc.), c’était très confus parce qu’il fallait vérifier manuellement quelle AZ correspondait à laquelle. Nous avions donc fini par créer une méthode de mapping un-à-un par compte et même une table de consultation interne. Plus tard, AWS a ajouté le zone ID dans les métadonnées, ce qui a permis de le retrouver facilement.
    • Cette politique m’a vraiment causé beaucoup de difficultés.
  • J’aimerais corriger ce point : même les trivia sans importance peuvent être entièrement renversés.
    Weird Al : Everything You Know is Wrong
    Firesign Theatre : Everything You Know is Wrong