7 min de lecture<\/p>\n
\u00c9tat : 22.04.2026<\/span><\/p>\n Le 20 avril 2026, AWS a rendu les instances EC2 C8in et C8ib g\u00e9n\u00e9ralement disponibles. La C8in offre jusqu\u2019\u00e0 600 Gbps de bande passante r\u00e9seau et \u00e9volue jusqu\u2019\u00e0 384 vCPU, tandis que la C8ib propose jusqu\u2019\u00e0 300 Gbps de bande passante EBS. Toutes deux fonctionnent sur des processeurs custom Intel Xeon Scalable de 6\u1d49 g\u00e9n\u00e9ration et les cartes Nitro de 6\u1d49 g\u00e9n\u00e9ration. Pour les bases de donn\u00e9es en m\u00e9moire, l\u2019analytique en streaming et les clusters HPC, cela repousse les limites sup\u00e9rieures chez AWS.<\/strong><\/p>\n L’essentiel en bref<\/p>\n En relation<\/span>AWS et Google Cloud : Cross-Cloud Interconnect en disponibilit\u00e9 g\u00e9n\u00e9rale<\/a> \/<\/span> Kubernetes 1.36 est arriv\u00e9<\/a><\/p>\n C8in et C8ib sont les variantes optimis\u00e9es pour le r\u00e9seau et le stockage de la famille C8. La g\u00e9n\u00e9ration de base, C8i et C8i-flex, est disponible depuis octobre 2025 et offre, selon AWS, jusqu\u2019\u00e0 15 % de performances en plus que les C7i. C8in ajoute 600 Gbps de bande passante r\u00e9seau, tandis que C8ib propose 300 Gbps pour l\u2019EBS. La logique derri\u00e8re cette convention de nommage reste coh\u00e9rente depuis des ann\u00e9es : \u00ab n \u00bb signifie Network (r\u00e9seau), et \u00ab b \u00bb Block-Storage (stockage par blocs). Ceux qui ont d\u00e9j\u00e0 travaill\u00e9 avec des C6in ou C7in connaissent le principe \u2013 la nouveaut\u00e9 r\u00e9side dans le delta.<\/p>\n Ce delta provient de deux \u00e9volutions. Premi\u00e8rement : la sixi\u00e8me g\u00e9n\u00e9ration des processeurs custom Intel Xeon Scalable, utilis\u00e9s exclusivement par AWS au sein de sa flotte. Avec des barrettes DDR5-7200, une bande passante m\u00e9moire accrue et un meilleur comportement en mode Turbo sous charge mono-thread. Deuxi\u00e8mement : la nouvelle g\u00e9n\u00e9ration Nitro, qui rend possible la mont\u00e9e en puissance du r\u00e9seau \u00e0 600 Gbps. Nitro 6 int\u00e8gre le chemin PCIe Gen5 \u00e0 la carte r\u00e9seau (NIC) et r\u00e9duit davantage la charge DMA sur le CPU. Pour les \u00e9quipes ayant d\u00e9j\u00e0 explor\u00e9 les benchmarks iperf3 sur C7i et M7i, c\u2019est ici que les anciennes limites tombent.<\/p>\n Pour la prise de d\u00e9cision d\u2019achat, cela signifie que ceux qui optaient jusqu\u2019\u00e0 pr\u00e9sent pour des X2iedn pour les bases de donn\u00e9es en m\u00e9moire ou des C7gn pour le d\u00e9bit r\u00e9seau disposent d\u00e9sormais d\u2019une seconde option sur la voie x86 avec C8in. La gamme Graviton reste, quant \u00e0 elle, la solution la plus \u00e9conomique pour les workloads compatibles ARM. C8in cible la fraction des utilisateurs contraints de rester sur x86 pour des raisons de licences ou de binaires.<\/p>\n La bande passante th\u00e9orique n\u2019int\u00e9resse que l\u00e0 o\u00f9 une charge de travail peut r\u00e9ellement saturer le r\u00e9seau. En pratique, cela concerne trois cas de figure. Premi\u00e8rement : les bases de donn\u00e9es en m\u00e9moire et les couches de cache comme Valkey, KeyDB ou Dragonfly, qui, en r\u00e9plication multi-ma\u00eetre, saturent le chemin r\u00e9seau entre les n\u0153uds. Ceux qui optimisaient jusqu\u2019ici pour 100 Gbps et constataient des temps d\u2019inactivit\u00e9 CPU, car la carte r\u00e9seau (NIC) \u00e9tait le goulot d\u2019\u00e9tranglement, trouvent avec le C8in une r\u00e9ponse g\u00e9n\u00e9rationnelle. Deuxi\u00e8mement : l\u2019analytique en streaming, o\u00f9 les brokers Kafka, les workers Flink et les sinks de stockage d\u2019objets convergent au sein d\u2019un m\u00eame VPC. Avec des topics affichant des d\u00e9bits soutenus \u00e0 deux chiffres en Go\/s, l\u2019architecture \u00e9voluait jusqu\u2019ici vers des configurations multi-NIC \u2013 600 Gbps sur une seule NIC r\u00e9duit une partie de cette complexit\u00e9.<\/p>\n Troisi\u00e8mement : les clusters HPC et d\u2019entra\u00eenement d\u2019IA qui ne misent pas sur Inferentia ou Trainium, mais sur une architecture x86 classique avec GPU ou CPU-only. Ici, EFA est d\u00e9terminant. AWS a int\u00e9gr\u00e9 EFA sur les grandes tailles du C8in \u2013 48xlarge, 96xlarge, metal-48xl, metal-96xl. Si vous avez besoin d\u2019un Elastic Fabric Adapter dans votre cluster, impossible de d\u00e9marrer avec des tailles plus petites pour ensuite monter en charge sans changer de famille d\u2019instances. Cela impose une d\u00e9cision architecturale pr\u00e9coce.<\/p>\n La quatri\u00e8me cat\u00e9gorie de workloads, souvent cit\u00e9e par r\u00e9flexe, est le traitement vid\u00e9o. Dans les faits, le C8in y est moins performant que pr\u00e9vu : la plupart des pipelines de transcodage sont soit li\u00e9s au GPU, soit ex\u00e9cut\u00e9s sur des instances acc\u00e9l\u00e9r\u00e9es comme VT1. Les 600 Gbps sont utiles l\u00e0 o\u00f9 l\u2019ingestion H.265 en temps r\u00e9el s\u2019effectue avec plusieurs sources simultan\u00e9es \u2013 un segment tr\u00e8s sp\u00e9cifique.<\/p>\n Le C8ib est la moins discut\u00e9e des deux instances, mais aussi la plus simple \u00e0 adopter. Les charges de travail n\u00e9cessitant un d\u00e9bit EBS \u00e9lev\u00e9 \u2013 bases de donn\u00e9es transactionnelles avec des journaux d\u2019\u00e9criture anticip\u00e9e volumineux, data warehouses avec des taux de commit massifs, instances SAP HANA single-node classiques avec des flux de sauvegarde \u2013 sont depuis des ann\u00e9es limit\u00e9es par le stockage, et non par le calcul. Si vous utilisez aujourd\u2019hui une instance r6idn ou i4i et constatez que le CPU n\u2019est pas satur\u00e9 tandis que la profondeur de la file d\u2019attente EBS reste constamment \u00e9lev\u00e9e, le C8ib offre une voie directe vers une meilleure saturation EBS.<\/p>\n Il est crucial de bien distinguer le stockage EBS du stockage local d\u2019instance. Le C8ib utilise EBS, et non des disques NVMe locaux. Si vous avez besoin d\u2019un espace de travail NVMe \u2013 par exemple pour des shuffles Spark ou des pipelines de type HDFS \u2013 restez sur les variantes \u00ab d \u00bb (C8id, M8id, R8id), disponibles depuis fin 2025 dans certaines r\u00e9gions. Le positionnement produit d\u2019AWS est clair : EBS intensif rime avec C8ib, NVMe local avec C8id.<\/p>\n \n”<\/span><\/p>\n R\u00e9seau et stockage sont deux goulots d\u2019\u00e9tranglement distincts. Celui qui a besoin des deux simultan\u00e9ment doit construire deux clusters \u2013 ou attendre l\u2019instance qui les combinera. Aujourd\u2019hui, la s\u00e9paration entre C8in et C8ib est plus propre qu\u2019une solution interm\u00e9diaire.<\/p>\n<\/blockquote>\n<\/figure>\n La question pratique pour les architectes et les responsables d’infrastructure n’est pas \u00ab\u00a0est-ce plus rapide\u00a0\u00bb, mais \u00ab\u00a0quelle part de cette vitesse b\u00e9n\u00e9ficie r\u00e9ellement \u00e0 ma charge de travail\u00a0\u00bb. Avec les bases de donn\u00e9es en m\u00e9moire, le taux de paquets par seconde compte autant que la bande passante nominale. Nitro 6 am\u00e9liore les deux simultan\u00e9ment, mais l’\u00e9cart d\u00e9pend de la charge de travail. Ceux qui utilisent aujourd’hui des C6in avec des clusters Valkey ou Redis et mesurent une r\u00e9plication inter-n\u0153uds inf\u00e9rieure \u00e0 50 % de la capacit\u00e9 NIC voient un gain mod\u00e9r\u00e9 avec les C8in. Ceux qui restent constamment \u00e0 la limite des 80 % r\u00e9cup\u00e8rent, gr\u00e2ce au triplement de la bande passante r\u00e9seau, une v\u00e9ritable marge de man\u0153uvre pour la croissance.<\/p>\n Pour les clusters Kafka et Flink, la logique est similaire, avec une variable suppl\u00e9mentaire : la r\u00e9plication broker-\u00e0-broker. Avec un facteur de r\u00e9plication de 3 et Acks=all, le d\u00e9bit d’\u00e9criture \u00e9volue avec la bande passante NIC des brokers \u2013 pas avec le CPU. Ici, 600 Gbps par n\u0153ud repr\u00e9sentent un r\u00e9el soulagement si les structures de topics devaient jusqu’\u00e0 pr\u00e9sent \u00eatre r\u00e9parties sur quatre ou cinq brokers pour obtenir le d\u00e9bit r\u00e9seau n\u00e9cessaire. Avec les C8in, les m\u00eames charges tournent avec moins de brokers, r\u00e9duisant ainsi la complexit\u00e9 op\u00e9rationnelle.<\/p>\n Pour les charges de travail gourmandes en bases de donn\u00e9es, le tableau est diff\u00e9rent. Avec PostgreSQL ou MySQL en r\u00e9plication synchrone, le r\u00e9seau est rarement le goulot d’\u00e9tranglement \u2013 ce qui compte, c’est la latence fsync et le taux d’IOPS EBS. En cons\u00e9quence, les C8ib, et non les C8in, sont le bon choix, m\u00eame si les deux instances ont \u00e9t\u00e9 annonc\u00e9es en m\u00eame temps. Ceux qui les utilisent en parall\u00e8le \u2013 par exemple un cluster PostgreSQL avec des C8ib et un fanout Kafka avec des C8in dans le m\u00eame VPC \u2013 en tirent un double avantage, sans \u00eatre contraints \u00e0 une instance de compromis. C’est l\u00e0 le v\u00e9ritable message des deux variantes : AWS s\u00e9pare d\u00e9lib\u00e9r\u00e9ment la marge r\u00e9seau et la marge de stockage, au lieu de les regrouper dans une instance combin\u00e9e plus co\u00fbteuse, dont beaucoup d’\u00e9quipes n’ont pas besoin.<\/p>\n La situation des r\u00e9servations et des capacit\u00e9s sera le v\u00e9ritable test dans les semaines \u00e0 venir. AWS a initialement d\u00e9ploy\u00e9 les instances C8in et C8ib dans certaines r\u00e9gions s\u00e9lectionn\u00e9es, comme annonc\u00e9 au lancement ; Francfort, l’Irlande et la Virginie sont g\u00e9n\u00e9ralement parmi les premi\u00e8res zones concern\u00e9es. Toute \u00e9quipe souhaitant migrer une charge de travail vers ces instances doit consulter la matrice des zones de disponibilit\u00e9 dans la console de gestion et ne souscrire \u00e0 des Savings Plans que lorsque la famille d’instances est disponible dans les trois \u00e0 cinq r\u00e9gions cibles.<\/p>\n Pour les migrations existantes, le rapport co\u00fbt\/b\u00e9n\u00e9fice par rapport \u00e0 la famille actuelle est d\u00e9terminant. AWS n’a pas encore confirm\u00e9 officiellement les tarifs \u00e0 la demande sp\u00e9cifiques \u00e0 la r\u00e9gion DACH pour toutes les zones au moment du lancement. Pour la C8i, la prime par rapport \u00e0 la C7i se situait entre sept et dix pour cent, selon la r\u00e9gion. Un surco\u00fbt similaire pour les C8in et C8ib par rapport aux C7in et C7i est r\u00e9aliste. Les \u00e9quipes qui calculent leurs mod\u00e8les FinOps en fonction des co\u00fbts par Gbps devraient d’abord comparer cet \u00e9cart avec le taux d’utilisation r\u00e9el avant de s’engager sur un Savings Plan.<\/p>\n Le troisi\u00e8me point de v\u00e9rification concerne la pile logicielle. La compatibilit\u00e9 des AMI avec les fonctionnalit\u00e9s des Xeon de 6\u1d49 g\u00e9n\u00e9ration est g\u00e9n\u00e9ralement sans probl\u00e8me, mais les versions de noyau inf\u00e9rieures \u00e0 5.15 peuvent pr\u00e9senter des probl\u00e8mes de pilotes avec les cartes r\u00e9seau Nitro 6 dans certains cas. Ceux qui utilisent Ubuntu 22.04 LTS ou Amazon Linux 2023 b\u00e9n\u00e9ficient des pilotes pr\u00eats \u00e0 l’emploi ; en revanche, ceux qui d\u00e9pendent de RHEL 8 ou d’une version ant\u00e9rieure doivent pr\u00e9voir des tests de migration en amont. Pour les environnements SAP HANA et Oracle, il est \u00e9galement essentiel de consulter la liste des certifications : les d\u00e9ploiements HANA en mode single-node sur C8i et C8ib devraient \u00eatre certifi\u00e9s, tandis que la C8in, surdimensionn\u00e9e pour les charges HANA pures, reste plus adapt\u00e9e aux sidecars analytiques comme Spark ou Trino.<\/p>\n Le quatri\u00e8me point concerne l’observabilit\u00e9. Surveiller 600 Gbps simultan\u00e9ment n’est pas une t\u00e2che par d\u00e9faut pour CloudWatch. Le Enhanced Monitoring avec un intervalle d’une seconde engendre des co\u00fbts suppl\u00e9mentaires et g\u00e9n\u00e8re des donn\u00e9es qui, sans seuils d’alerte adapt\u00e9s, se noient rapidement dans le bruit. Les \u00e9quipes qui franchissent le pas misent g\u00e9n\u00e9ralement sur Prometheus ou OpenTelemetry au niveau des n\u0153uds et exportent les statistiques des interfaces r\u00e9seau. Comme l’a montr\u00e9 l’arriv\u00e9e des instances \u00e0 200 Gbps : sans une mesure de r\u00e9f\u00e9rence pr\u00e9cise, impossible de savoir si la nouvelle instance exploite r\u00e9ellement sa capacit\u00e9 ou si elle reste simplement inactive \u00e0 un co\u00fbt plus \u00e9lev\u00e9.<\/p>\n Enfin, le cinqui\u00e8me point rel\u00e8ve de la perspective FinOps : les C8in et C8ib r\u00e9duisent les co\u00fbts par Gbps, mais pas par vCPU. D\u00e9ployer cette famille d’instances sans avoir v\u00e9rifi\u00e9 le profil de la charge de travail revient \u00e0 payer la prime r\u00e9seau m\u00eame si l’application n’utilise que 4 Gbps. Ce sch\u00e9ma a d\u00e9j\u00e0 \u00e9t\u00e9 observ\u00e9 lors du lancement des M6in et R6in : dans les premiers mois suivant leur disponibilit\u00e9 g\u00e9n\u00e9rale, les \u00e9quipes migrent par r\u00e9flexe vers la nouvelle famille et ne r\u00e9alisent qu’au trimestre suivant qu’une M7i ou une C7i aurait pu accomplir la m\u00eame t\u00e2che pour un budget moindre. La bonne approche reste donc : mesurer le profil, identifier le goulot d’\u00e9tranglement, puis changer de famille d’instances.<\/p>\n \u00c0 lire aussi<\/p>\n C8in est optimis\u00e9 pour le r\u00e9seau avec une bande passante allant jusqu\u2019\u00e0 600 Gbps, tandis que C8ib est optimis\u00e9 pour le stockage avec une bande passante EBS atteignant 300 Gbps. Tous deux fonctionnent sur la m\u00eame g\u00e9n\u00e9ration 6th-gen Intel Xeon Scalable et Nitro-6, mais se distinguent par leurs caract\u00e9ristiques d\u2019E\/S.<\/p>\n<\/details>\n Les bases de donn\u00e9es en m\u00e9moire avec r\u00e9plication multi-ma\u00eetre, l\u2019analytique en streaming avec Kafka\/Flink\/Object-Store dans un VPC et les clusters HPC avec EFA. La r\u00e8gle : si le goulot d\u2019\u00e9tranglement est la carte r\u00e9seau et non le CPU, C8in fait la diff\u00e9rence.<\/p>\n<\/details>\n Oui, mais uniquement pour les tailles 48xlarge, 96xlarge, metal-48xl et metal-96xl. Les tailles inf\u00e9rieures ne prennent pas en charge l\u2019EFA \u2013 pour les clusters HPC et d\u2019entra\u00eenement IA, cela implique une d\u00e9cision architecturale pr\u00e9coce.<\/p>\n<\/details>\n Non. C8in et C8ib reposent sur des processeurs Intel Xeon Scalable de 6\u1d49 g\u00e9n\u00e9ration personnalis\u00e9s. Pour les workloads compatibles ARM, la gamme Graviton (C7gn, C8g d\u00e8s sa disponibilit\u00e9) reste la solution la plus \u00e9conomique.<\/p>\n<\/details>\n AWS lance g\u00e9n\u00e9ralement les versions GA de cette famille dans les principales r\u00e9gions comme US-East-1, US-West-2, Irlande et Francfort. La matrice de disponibilit\u00e9 actuelle doit \u00eatre v\u00e9rifi\u00e9e dans la console EC2 avant de r\u00e9server des instances ou des Savings Plans.<\/p>\n<\/details>\n\n
Ce que C8in et C8ib changent vraiment<\/h2>\n
O\u00f9 600 Gbps font vraiment la diff\u00e9rence<\/h2>\n
Quand le C8ib est le bon choix<\/h2>\n
Benchmark : quand le changement vaut-il le coup ?<\/h2>\n
Ce que les \u00e9quipes doivent v\u00e9rifier d\u00e8s maintenant<\/h2>\n
\n
Questions fr\u00e9quentes<\/h2>\n
Quelle est la diff\u00e9rence entre C8in et C8ib ?<\/strong><\/summary>\n
Quels workloads b\u00e9n\u00e9ficient le plus des instances C8in ?<\/strong><\/summary>\n
Elastic Fabric Adapter est-il disponible sur C8in ?<\/strong><\/summary>\n
Existe-t-il des variantes C8in et C8ib en Graviton ?<\/strong><\/summary>\n
Dans quelles r\u00e9gions C8in et C8ib sont-elles disponibles ?<\/strong><\/summary>\n