Les instances C8gn Graviton4 à 600 Gbps arrivent à Paris et couvrent désormais 30 régions AWS
Le 28 août 2026, AWS a rendu disponibles dans Europe (Paris) les instances EC2 C8gn, portées par Graviton4 et capables de 600 Gbps de bande passante réseau, le maximum de la gamme réseau-optimisée. Pour les équipes qui exploitent des appliances réseau virtuelles ou des charges d’analyse à fort débit, cette extension européenne change le calcul coût-performance de la migration arm64.
28 août 2026. AWS annonce la disponibilité des instances EC2 C8gn dans la région Europe (Paris). 600 Gbps. C’est la bande passante réseau maximale de ces instances, la plus élevée de toute la gamme réseau-optimisée d’EC2. 30 régions. C’est désormais l’étendue du déploiement mondial de cette famille Graviton4. En une annonce, le haut de gamme réseau d’AWS bascule sur arm64 et devient accessible aux charges européennes à fort débit.
Ce qu’est C8gn, en chiffres
La famille C8gn est la déclinaison réseau-optimisée de la génération Graviton4. Trois chiffres la définissent. Jusqu’à 30 % de performance de calcul en plus que les instances C7gn basées sur Graviton3. 600 Gbps de bande passante réseau, le maximum parmi les instances réseau-optimisées. Et 6e génération de cartes Nitro, le socle qui décharge les fonctions réseau et stockage vers du matériel dédié.
La montée en gamme est continue jusqu’au 48xlarge, avec jusqu’à 384 Gio de mémoire et jusqu’à 120 Gbps de bande passante vers EBS. Sur les tailles 16xlarge, 24xlarge, 48xlarge et les versions metal, les instances supportent l’Elastic Fabric Adapter (EFA), le réseau basse latence conçu pour les grappes HPC et les charges fortement couplées.
L’intention d’AWS est explicite : positionner C8gn sur les appliances réseau virtuelles, l’analyse de données et l’inférence IA/ML sur CPU. Trois familles de charges où le débit réseau, plus que le calcul brut, est le goulot d’étranglement.
Pourquoi 600 Gbps changent la donne
Le suffixe « n » de C8gn désigne la gamme network-optimized. Historiquement, ce segment a été dominé par des instances x86 : pare-feu virtuels, appliances de sécurité, sondeurs de paquets, équilibreurs et passerelles. Ces charges déplacent des volumes massifs de paquets et se fichent souvent de l’architecture du cœur — elles veulent du débit déterministe.
Porter 600 Gbps sur Graviton4 revient à offrir ce débit au tarif arm64, structurellement moins cher que l’équivalent x86. Le calcul coût-performance change de nature : le poste de coût dominant des charges réseau-optimisées — la bande passante et les cartes Nitro — reste identique, mais le cœur qui l’accompagne coûte moins cher.
Le chiffre de 30 % face à C7gn compte aussi. Il signifie que la migration d’une génération à l’autre ne se paie pas en régression : on gagne en calcul en même temps qu’on gagne en débit, sans changer de famille d’instances.
Une lignée réseau-optimisée qui a fait ses preuves
Le suffixe « n » n’est pas nouveau. AWS a construit la gamme réseau-optimisée Graviton par itérations : les C6gn de la génération Graviton2, les C7gn de Graviton3, et désormais les C8gn de Graviton4. À chaque génération, la bande passante a fait un bond, tandis que le rapport débit-par-euro s’améliorait au profit de l’arm64.
Cette trajectoire compte parce qu’elle réduit le risque perçu de la bascule. Une charge réseau-optimisée qui migre de C7gn vers C8gn ne change pas de paradigme : elle reste sur arm64, conserve ses images, et gagne 30 % de calcul ainsi qu’un débit supérieur. La rupture n’existe que pour qui vient du monde x86, et c’est là que se concentre le travail de préparation.
La famille Graviton4 ne se limite d’ailleurs pas au réseau. Elle décline C8g pour l’usage général, C8gd pour le stockage NVMe local, ou R8g pour la mémoire. Le fait que le haut de gamme réseau rejoigne cette famille complète le portefeuille arm64 et simplifie la décision d’une organisation qui veut homogénéiser sa flotte sur une seule architecture.
Le vrai prérequis : l’arm64, partout
La bascule vers C8gn n’est pas un simple changement de taille d’instance. C’est un changement d’architecture. Toute l’image — système, dépendances, binaires — doit exister en arm64, et l’écosystème n’est pas encore uniforme.
Les images de base des grands systèmes sont largement multi-architectures. Les applications compilées, en revanche, peuvent encore dépendre de binaires x86 non portés. Une appliance réseau propriétaire livrée uniquement en x86_64 ne tournera pas sur C8gn sans émulation, et l’émulation détruit précisément le bénéfice de débit recherché.
La conséquence est simple : avant toute migration, auditer les images et les binaires. Une charge conteneurisée moderne avec des images multi-architectures migre en quelques heures ; une appliance legacy mono-architecture peut exiger une refonte que l’annonce d’AWS ne mentionne pas.
Paris et l’Europe : ce que l’extension change
L’arrivée de C8gn à Paris n’est pas cosmétique. Elle s’ajoute à Francfort, Stockholm, Irlande, Londres, Espagne, Zurich et Milan — huit régions européennes au total. Pour une charge réseau-optimisée, la proximité régionale détermine la latence de premier octet et le coût de transfert inter-régions.
Pour les équipes soumises à des contraintes de résidence des données ou de latence sur le marché français, disposer du haut de gamme réseau en région Paris évite l’arbitrage entre conformité et performance. On ne choisit plus une région lointaine pour accéder au 600 Gbps ; on le trouve au plus près des utilisateurs.
L’extension s’inscrit dans un mouvement plus large d’AWS : densifier chaque région avec l’ensemble des familles Graviton4, y compris les déclinaisons réseau, stockage et calcul intensif. Paris rattrape ainsi un retard relatif sur les régions américaines historiques.
Où C8gn se situe face au GPU
C8gn n’est pas une instance d’entraînement de modèles. Pour cela, AWS pousse les P6-B300, équipées de Blackwell Ultra et de 6,4 Tbps de réseau EFA, elles-mêmes étendues à de nouvelles régions le même 28 août. C8gn vise un autre créneau : le plan de données et l’inférence sur CPU, où le débit réseau et le coût du cœur comptent plus que la puissance de calcul tensorielle.
Les deux familles ne sont pas en concurrence, elles se complètent. Une architecture d’inférence type route le trafic par des appliances C8gn avant d’atteindre les GPU, ou sert les modèles légers directement sur arm64. Comprendre cette répartition évite de surdimensionner un GPU pour une charge que 600 Gbps de Graviton4 absorbent déjà.
Ce qu’il faut vérifier avant de migrer
La migration vers C8gn se prépare en trois contrôles. D’abord, l’inventaire arm64 : confirmer que chaque image, chaque dépendance et chaque binaire embarqué existe en arm64. Ensuite, l’éligibilité EFA : le réseau EFA, utile aux grappes couplées, n’est disponible que sur certaines tailles — vérifier qu’elle correspond aux besoins avant de dimensionner. Enfin, la compatibilité des appliances : une appliance réseau virtuelle fournie par un éditeur doit être explicitement validée pour arm64 par ce dernier.
Le bénéfice se mesure sur les charges qui dominent la facture réseau. Une appliance de filtrage à plusieurs dizaines de Gbps, une plateforme d’analyse en flux ou une passerelle d’inférence CPU verront le coût du cœur baisser sans toucher au débit. À l’inverse, une charge liée à un logiciel x86 exclusif n’a rien à gagner à court terme.
Le benchmark, enfin, doit se faire sur des tailles réelles. Le débit 600 Gbps n’est atteint que sur les grandes tailles ; une appliance modeste ne verra qu’une fraction du plafond. Dimensionner sur le débit réellement consommé, pas sur le maximum annoncé, est ce qui sépare une migration rentable d’un surcoût inutile.
Verdict
Si vos charges réseau-optimisées sont conteneurisées ou multi-architectures, benchmarkez C8gn contre vos instances x86 actuelles : à débit équivalent, le cœur Graviton4 coûte moins cher, et le gain de 30 % face à C7gn rend la bascule quasi gratuite.
Si vous dépendez d’appliances ou de binaires x86 exclusifs, ne forcez pas la migration : évaluez d’abord le coût du portage ou de l’émulation, qui peut annuler l’économie. Le 600 Gbps n’est un avantage que pour qui peut l’exploiter en arm64.