AWS EC2 C8in/C8ib : débit réseau 600 Gbps pour BD et analyse

7 min de lecture

État : 22.04.2026

Le 20 avril 2026, AWS a rendu les instances EC2 C8in et C8ib généralement disponibles. La C8in offre jusqu’à 600 Gbps de bande passante réseau et évolue jusqu’à 384 vCPU, tandis que la C8ib propose jusqu’à 300 Gbps de bande passante EBS. Toutes deux fonctionnent sur des processeurs custom Intel Xeon Scalable de 6ᵉ génération et les cartes Nitro de 6ᵉ génération. Pour les bases de données en mémoire, l’analytique en streaming et les clusters HPC, cela repousse les limites supérieures chez AWS.

En relationAWS et Google Cloud : Cross-Cloud Interconnect en disponibilité générale  /  Kubernetes 1.36 est arrivé

Ce que C8in et C8ib changent vraiment

C8in et C8ib sont les variantes optimisées pour le réseau et le stockage de la famille C8. La génération de base, C8i et C8i-flex, est disponible depuis octobre 2025 et offre, selon AWS, jusqu’à 15 % de performances en plus que les C7i. C8in ajoute 600 Gbps de bande passante réseau, tandis que C8ib propose 300 Gbps pour l’EBS. La logique derrière cette convention de nommage reste cohérente depuis des années : « n » signifie Network (réseau), et « b » Block-Storage (stockage par blocs). Ceux qui ont déjà travaillé avec des C6in ou C7in connaissent le principe – la nouveauté réside dans le delta.

Ce delta provient de deux évolutions. Premièrement : la sixième génération des processeurs custom Intel Xeon Scalable, utilisés exclusivement par AWS au sein de sa flotte. Avec des barrettes DDR5-7200, une bande passante mémoire accrue et un meilleur comportement en mode Turbo sous charge mono-thread. Deuxièmement : la nouvelle génération Nitro, qui rend possible la montée en puissance du réseau à 600 Gbps. Nitro 6 intègre le chemin PCIe Gen5 à la carte réseau (NIC) et réduit davantage la charge DMA sur le CPU. Pour les équipes ayant déjà exploré les benchmarks iperf3 sur C7i et M7i, c’est ici que les anciennes limites tombent.

Pour la prise de décision d’achat, cela signifie que ceux qui optaient jusqu’à présent pour des X2iedn pour les bases de données en mémoire ou des C7gn pour le débit réseau disposent désormais d’une seconde option sur la voie x86 avec C8in. La gamme Graviton reste, quant à elle, la solution la plus économique pour les workloads compatibles ARM. C8in cible la fraction des utilisateurs contraints de rester sur x86 pour des raisons de licences ou de binaires.

Où 600 Gbps font vraiment la différence

La bande passante théorique n’intéresse que là où une charge de travail peut réellement saturer le réseau. En pratique, cela concerne trois cas de figure. Premièrement : les bases de données en mémoire et les couches de cache comme Valkey, KeyDB ou Dragonfly, qui, en réplication multi-maître, saturent le chemin réseau entre les nœuds. Ceux qui optimisaient jusqu’ici pour 100 Gbps et constataient des temps d’inactivité CPU, car la carte réseau (NIC) était le goulot d’étranglement, trouvent avec le C8in une réponse générationnelle. Deuxièmement : l’analytique en streaming, où les brokers Kafka, les workers Flink et les sinks de stockage d’objets convergent au sein d’un même VPC. Avec des topics affichant des débits soutenus à deux chiffres en Go/s, l’architecture évoluait jusqu’ici vers des configurations multi-NIC – 600 Gbps sur une seule NIC réduit une partie de cette complexité.

Troisièmement : les clusters HPC et d’entraînement d’IA qui ne misent pas sur Inferentia ou Trainium, mais sur une architecture x86 classique avec GPU ou CPU-only. Ici, EFA est déterminant. AWS a intégré EFA sur les grandes tailles du C8in – 48xlarge, 96xlarge, metal-48xl, metal-96xl. Si vous avez besoin d’un Elastic Fabric Adapter dans votre cluster, impossible de démarrer avec des tailles plus petites pour ensuite monter en charge sans changer de famille d’instances. Cela impose une décision architecturale précoce.

La quatrième catégorie de workloads, souvent citée par réflexe, est le traitement vidéo. Dans les faits, le C8in y est moins performant que prévu : la plupart des pipelines de transcodage sont soit liés au GPU, soit exécutés sur des instances accélérées comme VT1. Les 600 Gbps sont utiles là où l’ingestion H.265 en temps réel s’effectue avec plusieurs sources simultanées – un segment très spécifique.

Quand le C8ib est le bon choix

Le C8ib est la moins discutée des deux instances, mais aussi la plus simple à adopter. Les charges de travail nécessitant un débit EBS élevé – bases de données transactionnelles avec des journaux d’écriture anticipée volumineux, data warehouses avec des taux de commit massifs, instances SAP HANA single-node classiques avec des flux de sauvegarde – sont depuis des années limitées par le stockage, et non par le calcul. Si vous utilisez aujourd’hui une instance r6idn ou i4i et constatez que le CPU n’est pas saturé tandis que la profondeur de la file d’attente EBS reste constamment élevée, le C8ib offre une voie directe vers une meilleure saturation EBS.

Il est crucial de bien distinguer le stockage EBS du stockage local d’instance. Le C8ib utilise EBS, et non des disques NVMe locaux. Si vous avez besoin d’un espace de travail NVMe – par exemple pour des shuffles Spark ou des pipelines de type HDFS – restez sur les variantes « d » (C8id, M8id, R8id), disponibles depuis fin 2025 dans certaines régions. Le positionnement produit d’AWS est clair : EBS intensif rime avec C8ib, NVMe local avec C8id.

Benchmark : quand le changement vaut-il le coup ?

La question pratique pour les architectes et les responsables d’infrastructure n’est pas « est-ce plus rapide », mais « quelle part de cette vitesse bénéficie réellement à ma charge de travail ». Avec les bases de données en mémoire, le taux de paquets par seconde compte autant que la bande passante nominale. Nitro 6 améliore les deux simultanément, mais l’écart dépend de la charge de travail. Ceux qui utilisent aujourd’hui des C6in avec des clusters Valkey ou Redis et mesurent une réplication inter-nœuds inférieure à 50 % de la capacité NIC voient un gain modéré avec les C8in. Ceux qui restent constamment à la limite des 80 % récupèrent, grâce au triplement de la bande passante réseau, une véritable marge de manœuvre pour la croissance.

Pour les clusters Kafka et Flink, la logique est similaire, avec une variable supplémentaire : la réplication broker-à-broker. Avec un facteur de réplication de 3 et Acks=all, le débit d’écriture évolue avec la bande passante NIC des brokers – pas avec le CPU. Ici, 600 Gbps par nœud représentent un réel soulagement si les structures de topics devaient jusqu’à présent être réparties sur quatre ou cinq brokers pour obtenir le débit réseau nécessaire. Avec les C8in, les mêmes charges tournent avec moins de brokers, réduisant ainsi la complexité opérationnelle.

Pour les charges de travail gourmandes en bases de données, le tableau est différent. Avec PostgreSQL ou MySQL en réplication synchrone, le réseau est rarement le goulot d’étranglement – ce qui compte, c’est la latence fsync et le taux d’IOPS EBS. En conséquence, les C8ib, et non les C8in, sont le bon choix, même si les deux instances ont été annoncées en même temps. Ceux qui les utilisent en parallèle – par exemple un cluster PostgreSQL avec des C8ib et un fanout Kafka avec des C8in dans le même VPC – en tirent un double avantage, sans être contraints à une instance de compromis. C’est là le véritable message des deux variantes : AWS sépare délibérément la marge réseau et la marge de stockage, au lieu de les regrouper dans une instance combinée plus coûteuse, dont beaucoup d’équipes n’ont pas besoin.

Ce que les équipes doivent vérifier dès maintenant

La situation des réservations et des capacités sera le véritable test dans les semaines à venir. AWS a initialement déployé les instances C8in et C8ib dans certaines régions sélectionnées, comme annoncé au lancement ; Francfort, l’Irlande et la Virginie sont généralement parmi les premières zones concernées. Toute équipe souhaitant migrer une charge de travail vers ces instances doit consulter la matrice des zones de disponibilité dans la console de gestion et ne souscrire à des Savings Plans que lorsque la famille d’instances est disponible dans les trois à cinq régions cibles.

Pour les migrations existantes, le rapport coût/bénéfice par rapport à la famille actuelle est déterminant. AWS n’a pas encore confirmé officiellement les tarifs à la demande spécifiques à la région DACH pour toutes les zones au moment du lancement. Pour la C8i, la prime par rapport à la C7i se situait entre sept et dix pour cent, selon la région. Un surcoût similaire pour les C8in et C8ib par rapport aux C7in et C7i est réaliste. Les équipes qui calculent leurs modèles FinOps en fonction des coûts par Gbps devraient d’abord comparer cet écart avec le taux d’utilisation réel avant de s’engager sur un Savings Plan.

Le troisième point de vérification concerne la pile logicielle. La compatibilité des AMI avec les fonctionnalités des Xeon de 6ᵉ génération est généralement sans problème, mais les versions de noyau inférieures à 5.15 peuvent présenter des problèmes de pilotes avec les cartes réseau Nitro 6 dans certains cas. Ceux qui utilisent Ubuntu 22.04 LTS ou Amazon Linux 2023 bénéficient des pilotes prêts à l’emploi ; en revanche, ceux qui dépendent de RHEL 8 ou d’une version antérieure doivent prévoir des tests de migration en amont. Pour les environnements SAP HANA et Oracle, il est également essentiel de consulter la liste des certifications : les déploiements HANA en mode single-node sur C8i et C8ib devraient être certifiés, tandis que la C8in, surdimensionnée pour les charges HANA pures, reste plus adaptée aux sidecars analytiques comme Spark ou Trino.

Le quatrième point concerne l’observabilité. Surveiller 600 Gbps simultanément n’est pas une tâche par défaut pour CloudWatch. Le Enhanced Monitoring avec un intervalle d’une seconde engendre des coûts supplémentaires et génère des données qui, sans seuils d’alerte adaptés, se noient rapidement dans le bruit. Les équipes qui franchissent le pas misent généralement sur Prometheus ou OpenTelemetry au niveau des nœuds et exportent les statistiques des interfaces réseau. Comme l’a montré l’arrivée des instances à 200 Gbps : sans une mesure de référence précise, impossible de savoir si la nouvelle instance exploite réellement sa capacité ou si elle reste simplement inactive à un coût plus élevé.

Enfin, le cinquième point relève de la perspective FinOps : les C8in et C8ib réduisent les coûts par Gbps, mais pas par vCPU. Déployer cette famille d’instances sans avoir vérifié le profil de la charge de travail revient à payer la prime réseau même si l’application n’utilise que 4 Gbps. Ce schéma a déjà été observé lors du lancement des M6in et R6in : dans les premiers mois suivant leur disponibilité générale, les équipes migrent par réflexe vers la nouvelle famille et ne réalisent qu’au trimestre suivant qu’une M7i ou une C7i aurait pu accomplir la même tâche pour un budget moindre. La bonne approche reste donc : mesurer le profil, identifier le goulot d’étranglement, puis changer de famille d’instances.

Questions fréquentes

Source image de titre : Pexels / Brett Sayles (px:5050305)