AWS conçoit ses propres processeurs de serveur depuis des années. Avec Graviton5, les équipes d’infrastructure ont une raison de plus d’examiner le coût d’exécution de leurs applications, et pas seulement la vitesse annoncée d’une puce plus récente.
Une entreprise migre ses applications vers le cloud en espérant davantage de flexibilité. Elle n’a plus besoin d’acheter des serveurs physiques ni de prévoir sa demande de calcul des années à l’avance. Quelques années plus tard, ses applications ont grandi, la facture AWS ne cesse d’augmenter et l’équipe d’infrastructure a besoin de plus de capacité sans dépenser toujours davantage.
Ajouter des serveurs est une option. Choisir des instances plus grandes en est une autre. Mais si l’entreprise pouvait tirer davantage de travail utile de la capacité de calcul qu’elle paie déjà ?
C’est là qu’AWS Graviton5 devient intéressant. Ce processeur conçu par Amazon utilise la technologie Arm plutôt que l’architecture x86 couramment associée aux serveurs Intel et AMD.
AWS indique que Graviton5 peut offrir, dans ses comparaisons, des performances de calcul jusqu’à 25 % supérieures à celles de Graviton4. AWS positionne aussi le nouveau processeur pour les applications au service d’agents d’IA. Ces affirmations méritent d’être examinées, mais aucune ne garantit une facture plus faible. L’annonce de lancement d’AWS de juin 2026 décrit la sortie et les charges de travail visées.
Pourquoi AWS conçoit ses propres processeurs
Un processeur suit un ensemble d’instructions de base lorsque le logiciel lui demande d’effectuer un travail. Cet ensemble s’appelle une architecture de jeu d’instructions (instruction-set architecture). Les processeurs de serveur Intel et AMD utilisent couramment x86, tandis qu’AWS Graviton utilise Arm.
Imaginez deux employés capables d’accomplir la même tâche, mais qui suivent des manuels d’instructions différents. Un logiciel préparé pour un jeu d’instructions peut devoir être reconstruit ou adapté pour fonctionner sur l’autre.
AWS a lancé en 2018 ses premières instances EC2 A1 équipées de Graviton. L’objectif n’était pas d’inventer un nouveau type d’application, mais de donner à AWS davantage de maîtrise sur les performances et l’efficacité du matériel qui exécute les charges de travail cloud. L’annonce initiale des instances A1 cite les serveurs web, les conteneurs, les caches et les magasins de données distribués parmi les cas d’usage visés.
Pour les clients, ce choix apporte à la fois une opportunité et une responsabilité. Une autre architecture de CPU peut améliorer l’économie de certaines applications, mais le logiciel et les outils qui l’accompagnent doivent être compatibles avec elle.
Ce que Graviton5 améliore, et ce qu’il ne peut pas promettre
Les instances EC2 à usage général M9g et M9gd équipées de Graviton5 sont devenues généralement disponibles le 10 juin 2026. Les instances EC2 sont des serveurs virtuels : les clients choisissent des configurations dotées de quantités précises de puissance de traitement, de mémoire, de capacité réseau et de stockage. La plus grande configuration M9g offre 192 vCPU et 768 GiB de mémoire.
Sur ces instances Graviton, un vCPU correspond à un cœur physique. Aligner le nombre de vCPU entre des instances Arm et certaines instances x86 ne garantit donc pas des performances égales. Les spécifications AWS des M9g détaillent les configurations et les capacités.
Le processeur apporte aussi une mémoire plus rapide, un cache partagé plus grand et la prise en charge de PCIe 6.0. Le cache est une mémoire rapide, proche du CPU, qui garde les informations fréquemment utilisées à portée plus immédiate. PCIe est une connexion à haut débit utilisée pour transférer des données entre le processeur et les périphériques connectés.
Le système AWS Nitro de sixième génération assure d’importantes fonctions de virtualisation, de réseau, de stockage et d’isolation pour EC2. Ces caractéristiques augmentent la capacité potentielle, mais une application n’en profite que si le nouveau matériel agit sur ce qui la limite réellement. La présentation technique du lancement par AWS décrit ces changements.
Par exemple, un traitement plus rapide peut aider un service web très sollicité. Il peut n’apporter presque rien à une application dont le temps de réponse consiste surtout à attendre un service externe. Lorsque AWS annonce des performances de calcul jusqu’à 25 % supérieures, et des gains plus importants sur certaines charges de travail de base de données, web et d’apprentissage automatique, il s’agit de résultats déclarés par le fournisseur, issus de comparaisons particulières, et non de promesses valables pour toutes les charges de travail.
Pourquoi un CPU à usage général compte pour les agents d’IA
Un assistant d’IA ne se contente pas d’appeler un modèle. Imaginez qu’un employé lui demande de résumer des comptes clients.
L’application vérifie les permissions, récupère les dossiers, prépare les informations, appelle un modèle de langage et peut utiliser d’autres outils métier. Les opérations mathématiques intensives du modèle peuvent s’exécuter ailleurs, sur des GPU ou des accélérateurs spécialisés. La récupération des données, le traitement des requêtes et l’orchestration qui les entourent peuvent s’exécuter sur des CPU.
Cela explique l’intérêt d’AWS pour Graviton5 dans les applications agentiques. Mais cela fixe aussi une limite : si l’essentiel de la requête se passe à attendre un modèle de langage hébergé à distance, remplacer le CPU de l’orchestrateur peut à peine changer l’expérience de l’utilisateur. La vraie question est de savoir où l’application consomme du temps de calcul, et non si le produit porte l’étiquette IA agentique. AWS cite explicitement le raisonnement en temps réel, la génération de code et l’orchestration en plusieurs étapes parmi les cas d’usage visés dans l’annonce de disponibilité des M9g.
Cinq générations de Graviton en un coup d’œil
Graviton5 n’est pas un lancement isolé. C’est la cinquième étape d’un effort de longue haleine d’AWS pour faire d’Arm un choix réaliste pour les services cloud ordinaires.
| Génération | Premières instances EC2 généralement disponibles | Changement clé | Comparaison déclarée par AWS |
|---|---|---|---|
| Graviton1 | 2018 | Premières instances A1 équipées d’Arm | Point de départ |
| Graviton2 | 2020 | Prise en charge plus large d’Arm pour l’usage général | Rapport prix/performances (price performance) jusqu’à 40 % meilleur que celui des instances M5 comparables basées sur x86 |
| Graviton3 | 2022 | Mémoire DDR5 et conception de calcul plus récente | Performances jusqu’à 25 % supérieures à celles de Graviton2 |
| Graviton4 | 2024 | Capacité de traitement et de mémoire accrue | Performances jusqu’à 30 % supérieures à celles de Graviton3 |
| Graviton5 | 2026 | Conception à 192 cœurs, cache plus grand, mémoire plus rapide et PCIe 6.0 | Performances de calcul jusqu’à 25 % supérieures à celles de Graviton4 |
Sources : annonces officielles d’AWS pour Graviton2, Graviton3, Graviton4 et Graviton5. Il s’agit de comparaisons du fournisseur, avec des références et des charges de travail différentes. Les pourcentages ne peuvent pas s’additionner.
Le changement important n’est pas simplement que les nouvelles générations sont plus rapides. Arm est devenu plus facile à évaluer pour des applications serveur de plus en plus ordinaires. Pour l’entreprise de notre exemple, la décision suivante comporte trois volets : Ses applications peuvent-elles migrer sans risque ? Les gains de performances observés par les clients se traduisent-ils en économies réelles ? Comment tester ces deux affirmations ?
1. Les applications existantes peuvent-elles passer à Arm ?
De nombreux environnements d’exécution courants, dont Java, Node.js, Python, Go et .NET, prennent en charge Arm64, l’architecture Arm 64 bits utilisée par Graviton. Les systèmes de conteneurs peuvent construire des images pour x86 comme pour Arm, ce qui rend une adoption progressive réaliste. Mais la prise en charge du langage de l’application ne garantit pas que chaque bibliothèque native, extension commerciale, agent de supervision ou outil de sécurité soit disponible pour Arm.
Un démarrage réussi prouve aussi moins qu’un test de production réussi. L’application doit encore respecter ses exigences de latence et de fiabilité, produire une télémétrie exploitable et rester maintenable. Dans les environnements Kubernetes ou ECS, les déploiements à architecture mixte peuvent permettre un essai plus restreint plutôt qu’un remplacement soudain de toute la flotte. Le guide de démarrage Graviton d’AWS fournit des conseils sur les dépendances et la migration.
Pour notre entreprise, un service web gourmand en CPU, aux dépendances modernes, pourrait être un premier candidat. Une application héritée liée à un produit d’éditeur disponible uniquement sur x86 ne le serait peut-être pas.
2. Graviton5 réduira-t-il vraiment la facture cloud ?
AWS a publié des résultats de tests déclarés par des clients, qui montrent pourquoi des comparaisons au niveau de la charge de travail sont plus instructives qu’un simple chiffre phare annoncé pour un processeur.
| Client | Résultat Graviton5 déclaré | Contexte important |
|---|---|---|
| ClickHouse | Performances en hausse de 36 %, 16 % de concurrence en plus | Premiers tests de Graviton5 par rapport à Graviton4 |
| Atlassian | Performances supérieures de 30 %, latence inférieure de 20 % | Tests de Jira sur M9g par rapport à la génération précédente |
| Honeycomb | Débit (throughput) par cœur supérieur de 36 %, latence inférieure de 28 % | Graviton5 par rapport à Graviton4, y compris une évaluation de l’ingestion en production |
| HubSpot | Requêtes plus courtes de 45 à 60 %, utilisation du CPU inférieure de 20 à 30 % | MySQL OLTP, M9g en préproduction par rapport à M8g |
| Hard Rock Bet | Utilisation du CPU inférieure de 23 %, latence p99 inférieure d’environ 6 % en traitant 9 % de requêtes par seconde en plus | Passerelles CockroachDB aux côtés d’une flotte Graviton4 existante |
Source pour toutes les lignes : déclarations des clients sur la page M9g d’AWS. Il s’agit de déclarations de clients sélectionnées et publiées par AWS, et non d’un benchmark standardisé de manière indépendante. Les tests, les références et les conditions de mesure diffèrent.
Ces résultats sont substantiels, mais un débit plus élevé et une latence plus faible ne sont pas la même chose que des économies vérifiées. Honeycomb pourrait utiliser le débit supplémentaire pour servir davantage de clients plutôt que pour réduire son nombre d’instances. HubSpot pourrait choisir de consacrer son gain à des réponses plus rapides aux requêtes. Un bénéfice financier dépend du prix réel des instances, de l’utilisation des ressources, du dimensionnement adapté (right-sizing) et des engagements d’achat.
HubSpot fait état séparément de coûts inférieurs d’environ 15 à 20 % à performances comparables, issus de son adoption antérieure de Graviton. C’est une donnée historique utile, mais elle ne doit pas être présentée comme un résultat de coût de Graviton5. L’entreprise devrait comparer le coût par unité de travail utile : par exemple, le coût par million de requêtes au temps de réponse requis, ou le coût par traitement par lots mené à terme. L’effort d’ingénierie de migration, les licences et le support continu font aussi partie du calcul.
Le stockage pose une décision connexe. M9gd dispose d’un stockage NVMe local rapide qui peut convenir aux caches et aux données de travail temporaires.
Mais les données du stockage d’instance (instance store) EC2 ne survivent pas à un arrêt, à une mise en veille prolongée (hibernation) ou à une résiliation. Elles ne doivent pas constituer la seule copie de données précieuses. Consultez les recommandations d’AWS sur le cycle de vie du stockage d’instance. Dans les environnements hybrides, un autre coût peut être la prise en charge simultanée d’Arm et de x86 : un logiciel Arm64 peut être portable, mais les caractéristiques matérielles propres à Graviton sont spécifiques à AWS.
3. Comment l’entreprise doit-elle tester le bénéfice ?
Commencez par un service représentatif. Relevez son trafic actuel, son débit, son utilisation du CPU et de la mémoire, ses temps de réponse, son taux d’erreur et son coût d’exploitation mensuel complet. Construisez une version compatible Arm, puis comparez-la sur une instance Graviton5 adaptée, avec le même trafic réaliste et les mêmes objectifs de niveau de service.
Ne supposez pas que deux instances ayant le même nombre de vCPU offrent la même capacité. Choisissez la bonne famille : M9g à usage général, C9g optimisée pour le calcul ou R9g optimisée pour la mémoire, selon la disponibilité et les besoins de la charge de travail.
Comparez le coût nécessaire pour servir la charge requise, et pas seulement le prix horaire. Incluez l’effort de préparation et d’exploitation du nouvel environnement, les tests de reprise après défaillance et le maintien d’une voie de retour arrière. Le guide de migration d’AWS fournit un point de départ.
Si l’amélioration en vaut la peine, l’équipe peut s’étendre progressivement à des services similaires. Si le bénéfice mesuré est faible ou si le coût de compatibilité est élevé, rester sur x86 peut être la décision d’ingénierie la plus judicieuse.
Le changement plus profond derrière Graviton5
AWS construit de plus en plus l’infrastructure qui sous-tend son cloud au lieu de s’appuyer entièrement sur les processeurs de serveur traditionnels. Cela offre aux clients un moyen supplémentaire d’améliorer leur efficacité, mais rend aussi la compréhension des charges de travail plus importante. On retrouve la même logique ailleurs : notre analyse de l’expansion d’AWS et de NVIDIA à deux millions de GPU couvre le volet GPU du développement de l’infrastructure d’AWS, et notre article sur Google Cloud au T3 2026 montre comment les systèmes TPU propres à Google ont contribué à la croissance de son chiffre d’affaires.
Pour l’entreprise dont la facture cloud augmente, la réponse n’est peut-être ni un serveur de plus, ni une migration complète vers Arm. Elle peut consister à identifier où ses services consomment réellement de la capacité de traitement, et à tester si une autre architecture peut produire le même résultat plus efficacement.
La valeur de Graviton5 ne tient pas simplement à un processeur plus rapide. Elle tient à la possibilité de payer moins cher le travail de calcul qui compte.
Pour aller plus loin
- Lancement d’AWS Graviton5 et présentation technique. Juin 2026, architecture, contexte de la sortie et gains déclarés par le fournisseur.
- Spécifications des M9g et résultats des clients. Caractéristiques actuelles des instances et déclarations de tests attribuées aux clients.
- Annonce d’AWS sur les C9g et C9gd. 30 juin 2026, instances Graviton5 optimisées pour le calcul et comparaison d’AWS avec les C8g basées sur Graviton4.
- Annonce d’AWS sur les R9g et R9gd. 31 août 2026, instances Graviton5 optimisées pour la mémoire et comparaison d’AWS avec les R8g basées sur Graviton4.
- Guide de démarrage AWS Graviton. Évaluation des dépendances, construction de logiciels compatibles et test des migrations.
- Persistance des données du stockage d’instance EC2. Cycle de vie et conséquences en matière de perte de données pour le NVMe local.
- Présentation technique de la famille Graviton. Contexte plus large sur la famille de processeurs et références.