Un an après l’annonce de son lancement, Amazon Web Services (AWS) a annoncé la mis en service de Rainier, son cluster de calcul haute performance, dont l’infrastructure est répartie sur plusieurs centres de données aux États-Unis.
Le projet s’appuie sur les puces Trainium2, développées en interne par Amazon pour l’apprentissage automatique. Environ 500 000 unités sont intégrées dans la première phase du cluster, interconnectées via un réseau à très faible latence destiné à optimiser les échanges entre nœuds de calcul.
AWS met en avant la scalabilité et la résilience multi-site de l’ensemble. Le cœur du dispositif se situe dans l’État de l’Indiana, où Amazon investit plus de 11 milliards $ dans un centre de données de nouvelle génération. D’autres installations complémentaires sont prévues sur plusieurs sites américains afin d’assurer la continuité de service et la répartition de la charge.
Anthropic, premier utilisateur du cluster
Le principal client identifié est Anthropic, concepteur du LLM Claude, qui exploitera Rainier pour l’entraînement de ses modèles de grande taille, avec un objectif d’utilisation de plus d’un million de puces Trainium2 d’ici fin 2025.
Avec Rainier, Amazon renforce son positionnement dans le cloud haute performance et les infrastructures d’IA. Le groupe entend se placer comme un fournisseur clé d’environnement d’entraînement à grande échelle, aux côtés des autres hyperscalers qui développent également leurs propres architectures dédiées.
Quel point commun entre ecoinvent, GaBi et imec.netzero ? Tout au moins, celui d’alimenter la calculette carbone d’AWS (CCFT, Customer Carbon Footprint Tool). Ou, plus précisément, la méthodologie qui sous-tend l’outil.
Une nouvelle version de cette méthodologie (3.0) vient d’être publiée. Avec elle, AWS vient englober, en partie, le fameux scope 3. C’est-à-dire les émissions indirectes dans sa chaîne de valeur.
Une partie des émissions entrant dans ce périmètre sont liées à l’extraction, à la production et au transport de l’énergie consommée dans les datacenters. Calculées au niveau des clusters, elles sont dites « opérationnelles ». Cela inclut l’électricité achetée, ainsi que les carburants et les fluides frigorigènes utilisés dans les générateurs de secours ou les systèmes de climatisation.
D’autres émissions sont amorties sur la base de la durée de vie des assets auxquels elles se rattachent. En fait partie l’empreinte carbone embarquée :
Du matériel informatique (extraction des matières premières, fabrication des composants, processus d’assemblage, acheminement vers les datacenters)
Des datacenters
Des équipements non informatiques (centrales de traitement d’air, unités de distribution d’énergie…)
4 options de modélisation pour les équipements IT
La méthodologie v3 ne couvre pas l’ensemble du scope 3. Elle fait notamment l’impasse sur la fin de vie de toutes ces composantes (recyclage de matériel, destruction de bâtiments, etc.).
Pour les émissions opérationnelles, AWS propose des estimations basées sur la localisation ou sur le marché. Il prend en compte les pertes qui surviennent lors de la transmission et de la distribution.
Pour les équipements informatiques, l’estimation repose sur une modélisation au niveau des composants. Sont priorisés ceux présents en plus grand nombre dans l’infrastructure et/ou pesant le plus lourd dans l’empreinte carbone globale.
Un modèle « en cascade » est employé pour s’adapter aux éventuels manques de données.
La préférence va à une ACV (analyse de cycle de vie) par processus, autant que possible à partir des données des fabricants. À défaut, on collecte des attributs techniques (types de matériaux, processus de fabrication et masse, principalement) et on exploite éventuellement des estimations moyennes de l’industrie.
Pour certains types de composants à l’empreinte importante et dont les propriétés technologiques peuvent facilement être caractérisées à partir de quelques indicateurs (CPU, GPU, SSD, HDD, RAM, cartes mères…), on peut procéder par extrapolation. En l’occurrence, via une relation paramétrique entre les résultats de l’ACV par processus et les caractéristiques-clés de ces composants.
Autre option : l’analyse entrées-sorties (EIO, Economic Input-Output). Elle lie l’activité économique aux impacts environnementaux grâce à des facteurs d’émission sectoriels (en kg CO2e/$), rapportés au coût unitaire des composants.
Pour les composants qu’on trouve peu fréquemment et pour lesquels l’EIO ne produit pas de résultats précis, il y a l’option RCA-LCA (Representative Category Average Life Cycle Assessment). Elle se fonde sur la masse mesurée ou estimée des composants, combinée à une classification KNN (algorithme des k plus proches voisins) pour les associer à des facteurs d’émissions représentatifs appropriés.
Des sources en Belgique, en Suisse et au Canada
Parmi les sources qu’AWS exploite pour la partie informatique, il y a donc ecoinvent, GaBi et imec.netzero. Le premier – une base de données environnementales – est portée par une entreprise à mission de droit suisse. Le second est un logiciel d’ACV rattaché à la base Sphera. Le troisième donne un aperçu de l’impact environnemental de circuits intégrés. On le doit à l’Imec, institut de recherche universitaire belge en microélectronique et nanotechnologies.
Pour ce qui est des datacenters, AWS suit principalement les lignes directrices du Conseil national de recherches du Canada en matière d’ACV de l’ensemble du bâtiment. Ces guidelines se fondent sur la norme européenne EN 15978:2011.
Les modèles d’ACV pour les carcasses et les salles s’appuient essentiellement sur des EPD (déclarations environnementales de produits) tiers validés et sur la base ecoinvent.
Des données recalculées jusqu’à 2022
Pour passer du niveau du cluster à celui des racks, on se réfère à la puissance absorbée. Et on y ajoute le carbone embarqué amorti sur une durée de vie de 6 ans.
Exemple pour un cluster auquel on a attribué 500 MT CO2e et qui tire 1000 KVA : un rack consommant 600 KVA se verra allouer 60 % de l’empreinte carbone, soit 300 MT CO2e. Le carbone amorti associé à ce rack (par exemple, 100 MT CO2e) est ajouté pour obtenir les émissions totales, sur une base mensuelle.
Pour passer des racks aux services, on fait la différences entre les services « fondateurs » (qui ont des racks dédiés dans des datacenters) et « non fondateurs » (qui reposent sur d’autres services).
Exemple dans un rack dont le modèle identifie qu’il consomme 1000 Go-mois. Un service qui consomme 250 Go-mois se verra attribuer 25 % des émissions du serveur.
Pour les services « fondateurs », l’attribution d’une empreinte à chaque client se fait par allocation « physique » (basée sur les usages). Pour les services « non fondateurs », elle se fait par allocation « économique » (basée sur le revenu).
Pour permettre des analyses rétrospectives de tendances, AWS a recalculé ses données avec la nouvelle méthodo jusqu’à janvier 2022.
Une région cloud vous manque est tout est dépeuplé…
L’image est probablement exagérée, mais elle illustre le niveau de centralisation qui demeure chez AWS. Sa principale région (us-east-1, qui est aussi la plus ancienne) apparaît comme un point faible, ne serait-ce que par le nombre de services qui y ont leur plan de contrôle. On a pu le mesurer cette semaine avec un incident au retentissement mondial parti d’un problème de DNS interne.
Cet incident n’est pas, et de loin, le premier à avoir eu comme épicentre la région us-east-1. En témoigne, en particulier, une liste publique de post-mortem qu’AWS a consacrés aux problèmes qu’il considère avoir eu « un impact clent significatif ».
Avril 2011 : EBS part en boucle infinie
EC2 a connu des perturbations dues essentiellement au dysfonctionnement d’un sous-ensemble de volumes EBS dans une AZ. Ils n’acceptaient plus les opérations de lecture et d’écriture.
À l’origine, il y a une modification destinée à augmenter la capacité du réseau primaire – celui qui porte la communication entre les nœuds EBS, les instances EC2 et le plan de contrôle.
La redirection du trafic a été mal exécutée. Au lieu de basculer vers un routeur secondaire sur ce même réseau, tout a été acheminé sur le réseau secondaire, dédié à la réplication et dont les capacités étaient plus faibles. De sorte qu’il a saturé.
Certains nœuds se sont ainsi retrouvés privés des deux réseaux et ont perdu le lien avec leurs répliques. Dès la reconnexion, ils ont enclenché massivement un re-mirrorring, dépassant rapidement les capacités du cluster et entrant par là même dans une boucle infinie.
Le cluster ne pouvait plus répondre aux requêtes API visant à créer des volumes. Or, puisque cette API avait un long timeout, les appels se sont accumulés jusqu’à épuiser les threads alloués au plan de contrôle. Lequel a fini par devoir basculer les traitements vers une autre AZ.
À cela s’est ajoutée une condition de concurrence dans le code des nœuds EBS. Elle favorisait les échecs lors de la fermeture simultanée d’un grand nombre de requêtes de réplication.
Dans ce contexte, le volume de négociations entre instances EC2 et nœuds EBS pour s’entendre sur la copie principale a explosé, pesant d’autant plus sur le plan de contrôle.
Juin 2012 : EC2, EBS, ELB et RDS secoués par un orage
À la suite d’une surtension causée par un orage, deux datacenters soutenant une même AZ basculent sur les groupes électrogènes. La procédure échoue toutefois sur l’un d’entre eux, faute d’une stabilisation de la tension. Les serveurs passent alors sur onduleur… jusqu’à épuisement de la réserve énergétique. La séquence se produit à deux reprises, l’alimentation ayant été brièvement rétablie.
Le datacenter problématique n’hébergeait qu’une petite partie des ressources de la région (environ 7 % des instances EC2, par exemple). Mais l’impact a été fort pour certains clients. Sur deux plans. D’un côté, l’indisponibilité d’instances et de volumes (limitée à l’AZ touchée). De l’autre, la dégradation de l’accès aux plans de contrôle (sur toute la région east-us-1).
Le délai de rétablissement d’EC2 a été allongé par un goulet d’étranglement au niveau du démarrage des serveurs. Il l’a aussi été pour EBS, vu l’incapacité à basculer rapidement vers un nouveau datastore primaire.
L’offre ELB a aussi été perturbée. L’alimentation revenue, un bug est survenu : le plan de contrôle a tenté de scaler les instances sous-jacentes. Le flux de requêtes qui en a résulté a occasionné une surcharge. Couplé aux requêtes d’association des nouvelles instances EC2 que créaient les clients, il a saturé le plan de contrôle, d’autant plus que celui-ci utilisait une file d’attente partagée pour toute la région.
RDS a été nettement tributaire de la récupération d’EBS. Il a aussi fallu faire avec un bug logiciel qui a empêché le failover sur certaines configurations multi-AZ.
Octobre 2012 : l’agent de collecte EBS frappe à la mauvaise adresse
Des nœuds EBS ont rencontré des problèmes dans une AZ. La cause : un bug dans l’agent collectant des données à des fins de maintenance.
La semaine précédente, un des serveurs destinés à héberger ces données avait été remplacé après une panne matérielle. Dans ce cadre, l’enregistrement DNS avait été actualisé. La mise à jour ne s’était néanmoins pas propagée correctement. Certaines instances de l’agent continuaient donc à tenter de joindre l’ancienne adresse.
Le service de collecte étant tolérant aux manques de données, le problème n’avait pas été immédiatement visible. Jusqu’à ce que l’agent en arrive à saturer la mémoire des serveurs à force de répéter les tentatives de connexion. À tel point que les serveurs EBS ne pouvaient plus répondre aux requêtes clients. Pour ne rien arranger, beaucoup étant tombés au même moment, il n’y en avait pas assez de rechange.
L’incident a entraîné des difficultés pour utiliser les API de gestion. A fortiori parce que la politique de plafonnement de débit mise en place par AWS pour assurer la stabilité lors de la phase de récupération était trop agressive.
Juin 2014 : SimpleDB (quasiment) injoignable
Pendant deux heures, presque aucun appel API vers ce datastore distribué n’a abouti. Il a ensuite fallu du temps supplémentaire pour que tout revienne à la normale, notamment sur la création et la suppression de domaines.
Le déclencheur fut une coupure de courant. Plusieurs nœuds de stockage étaient devenus indisponibles. Lorsqu’ils ont redémarré, la charge s’est accrue sur le service de verrouillage interne de SimpleDB.
Ce service sert à déterminer quel ensemble de nœuds est responsable d’un domaine donné. Chaque nœud le contacte régulièrement pour vérifier qu’il a toujours les responsabilités qu’il pense avoir.
Avec l’augmentation de la charge, la latence s’est accrue et les nœuds ne pouvaient pas finaliser le handshake avant le timeout. Ils finissaient ainsi par s’auto-éjecter du cluster. Ils ne pouvaient alors le rejoindre qu’en recevant une autorisant de la part des nœuds de métadonnées… qui étaient malheureusement eux-mêmes indisponibles.
Septembre 2015 : DynamoDB dépassé par ses index secondaires globaux
En septembre 2015, les index secondaires globaux (GSI, global secondary index) sont encore relativement nouveaux sur DynamoDB. Ils permettent d’accéder aux tables via des clés alternatives.
Les tables DynamoDB, rappelons-le, sont partitionnées et distribuées entre serveurs. L’attribution d’un groupe de partitions à un serveur est alors dite membership. Elle est gérée par un service de métadonnées interne auprès duquel les serveurs de stockage doivent périodiquement se renseigner. C’est le cas après une coupure réseau.
Il en est justement intervenu une. Sauf qu’à la relance, une partie des réponses du service de métadonnées a dépassé les délais de transmission autorisés. En conséquence de quoi les serveurs de données concernés ont arrêté d’accepter des requêtes.
L’adoption des GSI a pesé lourd. Ces derniers ont en effet leur propre ensemble de partitions. Ils contribuent ainsi à augmenter la taille des infos de membership. C’est ainsi que le temps de traitement de certaines a fini par dépasser les délais. Le phénomène a été accentué du fait de la sollicitation simultanée par un grand nombre de serveurs de données. Lesquels ont réitéré leurs requêtes, maintenant donc une charge élevée.
AWS a dû se résoudre à mettre la communication en pause pour pouvoir ajouter de la capacité (la charge continue l’empêchait d’effectuer ses requêtes administratives).
SQS, qui utilise une table DynamoDB interne décrivant les files d’attente, a été affecté, faute de pouvoir rafraîchir correctement son cache. Les erreurs API se sont par ailleurs multipliées sur l’autoscaling EC2, qui exploite lui aussi DynamoDB (stockage des infos sur les groupes et de configs de lancement). CloudWatch n’a pas été épargné, entre autres sur la partie métriques.
Février 2017 : S3 planté par une erreur de débogage
Au début, il y a une opération de débogage d’un problème qui causait des lenteurs sur le système de facturation de S3.
Une commande était censée retirer quelques serveurs d’un sous-système. Mais une entrée incorrecte en a retiré davantage, et liés à deux autres sous-systèmes. L’un, dit d’index, gérait les métadonnées et les infos d’emplacement de tous les objets S3 dans la région us-east-1. L’autre, dit de placement, permettait l’allocation de nouveaux espaces de stockage.
Il a fallu relancer les deux, qui ne l’avaient pas été depuis des années. Le processus de vérification d’intégrité a ainsi pris plus longtemps que prévu.
Pendant le redémarrage, S3 ne pouvait pas répondre aux requêtes. D’autres services ont été impactés dans la région pendant l’indisponibilité de ses API. Parmi eux, le lancement de nouvelle instances EC2 et la création de volumes EBS à partir de snapshots.
Novembre 2020 : Kinesis atteint son plafond de threads
Le déclencheur fut l’ajout de capacité sur le front-end.
Cette flotte de serveurs gère le routage vers le back-end. Elle assure pour cela l’authentification et le contrôle des débits ; tout en maintenant des informations de membership (shard-map), dont chaque serveur stocke une copie.
Ces infos sont obtenues par appel à un microservice et par récupération de données dans une table DynamoDB. Mais aussi par le traitement continu des messages des autres serveurs du front-end, un thread étant dédié à chacun.
Les nombreuses erreurs constatées se sont avérées ne pas toutes découler de l’ajout de capacité. La principale en résultait, néanmoins. La cause racine : le dépassement, sur tous les serveurs du front-end, du nombre maximal de threads autorisé par une configuration OS. Les caches n’étaient donc plus construits et les shard-maps devenaient obsolètes, ne permettant plus de diriger les requêtes.
Pour des raisons de concurrence, il n’a été possible de relaner que quelques centaines de serveurs par heure, alors que la flotte en comptait des milliers. Il existait effectivement une situation de compétition entre les ressources utilisées pour peupler le shard-map et celles utilisées pour traiter les requêtes entrantes. Une remise en ligne trop rapide aurait entraîné un risque de conflits et donc d’erreurs.
Parmi les services impactés, Cognito, qui exploite Kinesis Data Streams pour collecter et analyser les patterns d’accès aux API. Ou CloudWatch, qui s’en sert pour traiter logs et métriques… et qui a aussi eu un effet en cascade sur Lambda (l’invocation de fonctions supposait alors la publication de métriques vers CloudWatch).
Décembre 2021 : de la friture sur le réseau
AWS utilise un réseau interne pour héberger des services fondamentaux de type monitoring, DNS, autorisation… et une partie du plan de contrôle EC2. Des passerelles permettent de communiquer avec le réseau principal, où fonctionnent la majorité des services de la branche cloud d’Amazon ainsi que les applications des clients.
La mise à l’échelle automatique d’un service sur le réseau principal a déclenché de l’agitation sur le réseau interne. Un pic de connexions a surchargé les passerelles, accroissant latence et erreurs. Les tentatives répétées de connexion ont favorisé une congestion.
Cette congestion a limité les capacités de supervision et donc de résolution du problème. La redirection du trafic DNS a aidé, mais n’a pas tout résolu. Le délai s’est allongé d’autant plus que les systèmes internes de déploiement d’AWS étaient eux aussi touchés.
Parmi les services affectés ont figuré les API EC2 destinées à lancer et à décrire des instances. Et donc, par rebond, des services comme RDS, EMR et WorkSpaces.
Les API Route 53 ont aussi subi le choc (pas possible de modifier des enregistrements). Sur STS, la latence s’est accrue pour la communication d’authentifiants aux fournisseurs d’identité tiers. L’accès aux buckets S3 et aux tables DynamoDB via des endpoints VPC a également été perturbé.
Juin 2023 : le front-end Lambda en surcapacité
Lambda est architecturé en cellules composées de sous-systèmes. Sur chacune, le front-end réceptionne les invocations et en assure le routage, tandis qu’un gestionnaire met à disposition un environnement d’exécution.
Un jour de juin 2023, le front-end a scalé pour absorber un pic de trafic… et a atteint, dans une cellule, un palier de capacité « jamais vu auparavant ». Assez pour entraîner un problème logiciel : les environnements d’exécution alloués n’étaient pas complètement utilisés par le front-end. Les invocations produisaient ainsi davantage d’erreurs.
L’incident a impacté la console AWS dans la région us-east-1. Il a aussi touché STS (taux d’erreurs sur la fédération SAML, notamment), EKS (provisionnement de clusters) et EventBridge (jusqu’à 801 secondes de latence pour le routage vers Lambda).
Juillet 2024 : Kinesis perturbé par un profil de workload
Problème également dans une cellule pour Kinesis Data Streams. Plus précisément, une cellule utilisée exclusivement par les services AWS (par opposition à celles dédiées aux clients).
En toile de fond, une mise à niveau d’architecture, avec un nouveau système de gestion. Celui-ci n’a malheureusement pas réussi à gérer le profil de workload spécifique de la cellule en question (un très grand nombre de shards à très bas débit).
Ces shards n’ont pas été bien répartis entre les hôtes. Les quelques-uns qui ont hérité des « gros morceaux » se sont mis à transmettre des messages de statut volumineux qui n’ont pas pu être traités dans les délais autorisés. Le système de gestion, pensant avoir affaire à des nœuds défectueux, a commencé à redistribuer les shards. D’où un pic d’activité qui a surchargé un autre composant, utilisé pour établir des connexions sécurisées vers les sous-système du plan de données. Le traitement du trafic Kinesis s’en est trouvé affecté.
Parmi les services touchés, CloudWatch Logs (utilisant Kinesis comme tampon), la livraison d’événements dans S3, ainsi que l’invocation des API PutRecord et PutRecordBatch avec Data Firehose. Des effets en cascade ont été recensés sur ECS, Lambda, Glue ou encore Redshift.
Perplexity, Signal, Snapchat, Uber, le site Internet du fisc britannique… Quantité de services numériques ont connu, ce 19 octobre, des perturbations liées à un incident chez AWS.
Pas de bilan officiel pour l’heure, mais le dernier message sur la page de statut AWS donne une bonne idée de l’enchaînement des événements.
Il est environ 9 heures du matin en France quand les problèmes commencent. Les erreurs et la latence s’accroissent dans la région us-east-1. La conséquence d’un souci de résolution DNS au niveau des points de terminaison DynamoDB.
Vers 11 h 30, le fonctionnement est rétabli. Mais des désagréments persistent dans des briques dépendantes de DynamoDB. Par exemple, le sous-système qui lance les instances EC2.
AWS constate aussi des problèmes d’équilibrage de charge qui déteignent sur des services comme CloudWatch et Lambda. Ils sont définitivement éliminés vers 18 h30 après avoir plafonné temporairement des opérations telles que le traitement des files d’attente SQS.
Vers minuit, tout était revenu à la normale, selon le groupe américain. Avec cependant un backlog à écouler sur des services comme AWS Config, AWS Connect et Amazon Redshift.
Plusieurs niveaux de dépendance à la région us-east-1
AWS reconnaît – sans toutefois s’y attarder – que l’incident a impacté des services non localisés dans la région us-east-1, mais qui en dépendent. Il mentionne notamment l’IAM.
Ce dernier fait partie, dans sa nomenclature, des « services globaux uniques par partition« . Globaux, parce que leurs plans de contrôle et de données n’existent pas indépendamment dans chaque région. Leurs ressources sont « mondiales », en tout cas à l’échelle de leur partition AWS (ici, le cloud public/commercial, par opposition à celles dédiées à la Chine ou au gouvernement américain).
Pour la plupart de ces services, le plan de données est distribué, tandis que le plan de contrôle est hébergé dans une seule région AWS. Il se trouve ainsi dans la région us-east-1 pour l’IAM, comme pour AWS Organizations et Account Management (gestion des comptes cloud), ainsi que le DNS privé Route 53. Son indisponibilité est donc susceptible de compromettre les opérations CRUDL (create, read, update, delete, list) à l’échelle globale.
Les « services globaux en périphérie » ont eux aussi un plan de contrôle monorégion (leur plan de données étant distribué entre points de présence, et potentiellement aussi entre régions). Cette catégorie comprend, entre autres, le DNS public Route 53, AWS Shield Advanced (anti-DDoS) et le CDN CloudFront (ainsi que son WAF et son gestionnaire de contrôle d’accès).
Il existe aussi des services régionaux ou zonaux dépendants d’autres régions. Sur Amazon S3, par exemple, diverses opérations (tagging, réplication, monitoring, ACL…) passent par la région us-east-1. Dans cett même région se trouve doans le plan de contrôle Route 53, sollicité pour créer des enregistrements DNS lors du provisionnement de ressources sur un éventail de services : PrivateLink (endpoints VPC), API Gateway (API REST et HTTP), ELB (répartiteurs de charge), OpenSearch Service (domaines), ECS (découverte de services), etc.
Il y a également des services qui utilisent des endpoints globaux par défaut. Illustration avec STS (Security Token Service, qui génère des jetons d’authentification éphémères). Exploité dans le SDK ou le CLI AWS, il utilise par défaut la région us-east-1. Autres exemples : IAM Identity Center et S3 Storage Lens. Le premier utilise par défaut l’endpoint SAML global hébergé sur us-east-1. Avec le second, la configuration du dashboard et les métriques associées sont, en standard, stockées dans cette même région.
La région des nouveautés… et des tutos
Localisée en Virginie, sur le campus d’Ashburn, la région us-east-1 réunit, au dernier pointage, 159 datacenters. Elle est d’autant plus structurante pour le cloud AWS qu’elle en a été la base : c’est avec elle que tout a commencé, en 2006 (lancement de S3).
Parallèlement à son ancienneté, us-east-1 accueille plus de charges de travail que toute autre région AWS. Ce qui contribue d’autant plus à en faire, de manière générale, un point de défaillance potentiel.
Son attrait peut s’expliquer par une tarification historiquement plus basse, quoique l’écart avec les autres régions s’est réduit au fil du temps. Elle a aussi la particularité d’être, aujourd’hui encore, souvent la première à accueillir les nouveaux services AWS. Beaucoup de tutos et d’articles la mettent par ailleurs en avant et elle est la valeur par défaut dans nombre d’outils.
Les frais de réseau peuvent de surcroit s’avérer dissuasifs pour qui voudrait mettre en place une redondance multirégions. Même si AWS a fait évoluer en partie sa politique, en particulier pour peupler sa région us-east-2 (prix ramené au niveau de celui du trafic interzones).
La centralisation des plans de contrôle peut se justifier lorsqu’une cohérence immédiate est nécessaire, comme pour l’authentification ou la facturation. Une décentralisation aurait plus globalement un coût non négligeable pour AWS, tout en compromettant éventuellement les engagements de disponibilité.
Une panne AWS en US-EAST-1 liée à la résolution de noms perturbe des services dans le monde, Amazon confirme une reprise progressive et un suivi public détaillé.
Une panne d’envergure frappe actuellement Amazon Web Services (AWS), provoquant une interruption massive de services en ligne à travers le monde. Parmi les plateformes affectées figurent Amazon, Alexa, Snapchat, Fortnite, ChatGPT, Perplexity, Airtable, Canva, et même certaines applications d’entreprises comme McDonald’s. Une panne centrée sur la région US-EAST-1 Selon le tableau de bord officiel d’AWS, plusieurs […]
Amazon Web Services (AWS) annonce le lancement de quatre nouvelles certifications centrées sur l’intelligence artificielle (IA) et l’apprentissage automatique (ML). L’hyperscaler s’attaque à structurer la validation des compétences dans un domaine en forte expansion, en couvrant à la fois les profils non techniques et les ingénieurs spécialisés.
Elles couvrent différents niveaux de maîtrise, du plus généraliste au plus avancé.
Jusqu’à présent, AWS ne proposait qu’une seule certification dédiée au machine learning, de niveau « Specialty ». L’introduction de ces quatre nouveaux examens établit un parcours progressif, allant de la compréhension des concepts à la maîtrise opérationnelle des outils de l’écosystème AWS.
Une structuration plus claire des parcours IA
La certification AI Practitioner marque l’entrée dans cet univers, en abordant les principes fondamentaux de l’IA sans nécessiter de compétences en programmation. Les certifications Machine Learning Engineer – Associate et Data Engineer – Associate s’adressent à des profils techniques impliqués dans la mise en œuvre et la gestion des données nécessaires à l’entraînement des modèles. Enfin, Generative AI Developer – Professional, la plus avancée, cible les spécialistes capables d’intégrer et d’optimiser des modèles génératifs en production, notamment via des services comme Amazon Bedrock.
Ces certifications offrent un cadre de reconnaissance standardisé pour les professionnels souhaitant démontrer leur maîtrise des outils d’IA dans l’environnement AWS. Elles peuvent contribuer à clarifier les compétences sur le marché du travail, tout en favorisant la montée en qualification sur des technologies très demandées.
Elles restent toutefois étroitement liées à l’écosystème AWS, ce qui limite la transférabilité directe des compétences vers d’autres plateformes cloud. La rapidité d’évolution du secteur oblige par ailleurs à actualiser fréquemment les référentiels d’examen, afin de suivre les évolutions technologiques et les bonnes pratiques.
La version bêta de l’examen Generative AI Developer illustre cette dynamique : elle sera ajustée avant sa version finale en fonction des retours des premiers candidats.
Quatre certifications pour quatre niveaux de spécialisation
Nom de la certification
Niveau / catégorie
Public visé & prérequis
Contenu / compétences évaluées
Particularités (durée, format, langue, coût)
AWS Certified AI Practitioner
Fondamental (Foundational)
Professionnels non techniques ou débutants connaissant les bases de l’IA/ML
Concepts d’IA et de machine learning, cas d’usage, principes d’IA responsable, services AWS liés à l’IA
90 minutes, 65 questions, coût 100 USD, disponible en français, en ligne ou en centre Pearson VUE
AWS orchestre un grand ménage dans ses services de modernisation.
Migration Hub et Application Discovery Service sont passés en mode maintenance. Pour le moment jusqu’au 7 novembre 2025, date à partir de laquelle ils n’accepteront plus de nouveaux clients*. Il en sera de même à cette échéance pour les outils de modernisation .NET**. Tandis que Mainframe Modernization Service n’existera plus qu’en version autogérée.
Le palliatif désigné, lancé il y a quelques mois sous la bannière de l’IA agentique, s’appelle AWS Transform.
Quantité d’autres services passeront en mode maintenance à partir du 7 novembre 2025. En voici quelques-uns.
Amazon Cloud Directory
Magasin de données hiérarchisées, alternatif aux annuaires LDAP. Les écritures seront bloquées dans un deuxième temps (passé le 22 avril 2026). Puis le service fermera le 30 septembre 2026 et le contenu sera supprimé en parallèle. AWS n’y a plus ajouté de fonctionnalités depuis 2018 et le lancement d’Amazon Neptune, base de données orientée graphe vers laquelle il recommande aujourd’hui de migrer.
Amazon CodeCatalyst
À partir du 7 novembre, il ne sera alors plus possible, pour les utilisateurs existants, de créer de nouveaux espaces. AWS recommande de migrer vers l’offre GitLab Duo with Amazon Q. Ou alors vers CodeBuild (compilation et test de code), CodePipeline (orchestration CI/CD), CodeDeploy (déploiement d’applications) et Code Artifact (gestion de packages).
Amazon CodeGuru Reviewer
Service d’analyse de code Java et Python sur Bitbucket, CodeCommit, GitHub et S3). À partir du 7 novembre 2025, il ne sera plus possible de créer de nouvelles associations de dépôts. Options de migration recommandées : Amazon Q Developer et Amazon Inspector, qui couvrent l’un et l’autre GitHub et GitLab.
Amazon S3 Object Lambda
Ce service permet l’ajout de code aux requêtes S3 GET, HEAD et LIST pour modifier des données. Il n’acceptera plus de nouveaux utilisateurs à la même date. AWS recommande d’invoquer Lambda par d’autres moyens (via CloudFront, API Gateway ou les URL de fonctions) ou de traiter les données dans les applications clientes.
Amazon Glacier
Le passage en maintenance d’Amazon Glacier interviendra un peu plus tard. Le 15 décembre 2025 en l’occurrence. On parle là du service d’origine, autonome, basé sur un coffre-fort avec API REST. Les données stockées jusque-là resteront accessibles indéfiniment, assure AWS, qui recommande de faire la transition vers les classes de stockage Glacier dans S3. Lesquelles ont l’avantage d’une disponibilité plus large sur son cloud, d’une intégration avec ses autres services, d’un coût inférieur et d’une API niveau bucket.
AWS IoT SiteWise Monitor et Data Procesing Pack
Deux composantes de l’offre AWS IoT SiteWise passeront également en mode maintenance le 7 novembre 2025. D’une part, le Data Processing Pack (transformation, stockage et visualisation de données). De l’autre, Monitor (création de portails web pour visualiser et partager des données au sein d’une organisation). Pour remplacer le premier, AWS recommande soit l’open source (Node-RED pour la transformation, InfluxDB pour le stockage de séries chronologiques, Grafana pour la visualisation), soit des solutions de partenaires (CloudRail, EasyEdge, Litmus Edge). Au second, il conseille de substituer le plug-in Amazon Managed Grafana (en sachant qu’il n’y a pas de contrôle d’accès niveau asset ni d’intégration avec AWS IoT SiteWise Assistant) ou bien Grafana Cloud ou autohébergé.
AWS Snowball Edge
Appliances de transfert de données. L’offre n’acceptera plus non plus de nouveaux clients à compter du 7 novembre 2025. Successeurs recommandés : DataSync pour les transfert sur lien réseau et Data Transfer Terminal pour les transferts physiques (Seagate et Tsecond soit également cités). Pour remplacer l’appliance optimisée compute, il y a éventuellement l’offre AWS Outposts.
Amazon Fraud Detector
Détection de fraude à base de machine learning. En guise de remplacement, AWS avance son WAF (pare-feu pour applications web), son service SageMaker (MLOps)… et une bibliothèque open source dont il est à l’origine : AutoGluon (AutoML à partir d’images, de texte, de séries chronologiques et de données tabulaires).
Accès web à Amazon WorkSpaces sur PCoIP
AWS recommande d’installer, si possible, les clients Amazon WorkSpaces. Sinon, de migrer vers le protocole DCV. Qui a, entre autres avantages :
Meilleures performances
Fonctionnalités supplémentaires (SAML et authentification par certificats, notamment)
Disponibilité étendue (pas d’accès web sur PCoIP dans certaines régions AWS, dont Paris)
Gestion des bureaux Linux en plus de Windows
Fonctionnement dans Edge et Safari en plus de Chrome et Firefox
Gestion des écrans multiples et des GPU côté hôte
* Sur Migration Hub comme sur Application Discovery Service et Mainframe Modernization Service, les projets en cours pourront être menés à leur terme.
** Cela comprend Porting Assistant for .NET, AWS App2Container, AWS Toolkit for .NET Refactoring et AWS Microservice Extractor for .NET.
Aujourd’hui, dans Affaires Sensibles, le naufrage de l’USS Indianapolis, le 30 juillet 1945 : la pire catastrophe de l’histoire de la marine américaine
Connexion
