Qu'est-ce que la Prefix Delegation de l'AWS VPC CNI ?

La Prefix Delegation permet à une ENI de réserver un préfixe IPv4 /28 au lieu d'une seule IP, augmentant considérablement la limite de pods par nœud sur les types d'instances plus petits.

Comment Cilium gère-t-il les environnements à forte volatilité (high-churn) ?

Très bien. Puisque Cilium gère son propre état dans les maps eBPF, il peut gérer des milliers de mises à jour de politiques réseau par seconde sans les blocages 'iptables-restore' observés dans les clusters Kubernetes standards.

Puis-je utiliser Cilium pour résoudre l'épuisement des adresses IP VPC ?

Oui, en utilisant Cilium en mode 'Encapsulation' (VXLAN), les adresses IP des pods sont complètement séparées des adresses IP VPC, vous permettant d'exécuter un cluster massif sur un très petit CIDR VPC.

Quel est le principal avantage de SGP ?

Les Security Groups for Pods (SGP) vous permettent d'utiliser AWS IAM et des pare-feu au niveau du VPC pour les pods, ce qui est souvent plus facile à auditer pour les équipes de conformité d'entreprise que les politiques natives de Kubernetes.

Y a-t-il une différence de latence significative entre VPC CNI et Cilium ?

En mode de routage natif, VPC CNI est légèrement plus rapide pour le débit brut (RAW throughput) en flux unique, mais Cilium l'emporte dans les scénarios réels impliquant de nombreuses petites connexions et des règles de politique complexes.

Le réseau AWS EKS en 2026 : Pourquoi vous devriez probablement abandonner VPC CNI pour Cilium

En 2026, le choix « par défaut » pour le réseau AWS EKS – l'AWS VPC CNI – n'est plus le roi incontesté pour les environnements à grande échelle et axés sur la sécurité. Bien qu'AWS ait ajouté des fonctionnalités essentielles comme la Prefix Delegation et les Security Groups for Pods (SGP), celles-ci restent des « abstractions fuyantes » (leaky abstractions) qui lient vos microservices aux contraintes héritées du plan de contrôle VPC, tandis que Cilium exploite l'eBPF pour contourner entièrement le goulot d'étranglement de la pile IPTables de Linux. Cet article soutient qu'à moins d'avoir une exigence réglementaire stricte concernant les politiques réseau basées sur IAM natives d'AWS, Cilium est l'architecture supérieure pour tout cluster EKS dépassant 100 nœuds ou nécessitant une observabilité granulaire.

L'écart architectural : Plans de données IPAM vs. eBPF

Pour comprendre pourquoi un choix est nécessaire, nous devons examiner comment ces plugins CNI gèrent le trafic des couches 3 et 4 du modèle OSI. L'AWS VPC CNI (Amazon VPC Container Networking Interface) est un modèle « IP secondaire ». Il alloue des Elastic Network Interfaces (ENIs) à vos nœuds de travail EC2 et attribue des adresses IPv4 privées secondaires à ces ENIs. Chaque pod reçoit une IP directement de votre sous-réseau VPC.

En revanche, Cilium (fonctionnant en mode chaining ou comme un remplacement complet) se concentre sur le plan de données eBPF (Extended Berkeley Packet Filter). Alors que VPC CNI s'appuie sur les vieillissantes iptables ou ipvs au sein du noyau Linux — dont la performance scale linéairement avec le nombre de services — Cilium utilise des programmes eBPF pour intercepter les paquets et les router via des tables de hachage en O(1). Si votre cluster compte plus de 5 000 services, la latence d'évaluation des iptables ajoute des millisecondes mesurables à chaque requête ; Cilium ne le fait pas.

AWS VPC CNI : L'argument de l'intégration native

Le principal argument en faveur de l'AWS VPC CNI est son statut de « citoyen de première classe ». Puisque les pods sont natifs du VPC, ils sont visibles par tous les outils AWS. Vous pouvez utiliser les VPC Flow Logs pour auditer le trafic au niveau du pod sans installer d'agents supplémentaires. Plus important encore, les fonctionnalités introduites fin 2023 et affinées jusqu'en 2025, comme la Prefix Delegation, ont atténué le problème de « l'épuisement des IP ».

# Activer la Prefix Delegation pour augmenter la densité de Pods par nœud
kubectl set env daemonset aws-node -n kube-system ENABLE_PREFIX_DELEGATION=true
# Cela permet à une seule ENI de gérer un préfixe /28 au lieu d'une seule IP,
# augmentant la densité de pods sur un m5.large de 29 à plus de 110 pods.

Les Security Groups for Pods (SGP) constituent l'autre « fonctionnalité clé ». En définissant une ressource personnalisée SecurityGroupPolicy, vous pouvez attribuer un Security Group AWS directement à un déploiement. C'est essentiel pour les environnements où un pod doit accéder à une instance RDS ou à une base de données On-Premise via Direct Connect, et l'équipe de sécurité refuse de whitelister une large plage CIDR. Vous utilisez efficacement l'API AWS comme contrôleur de pare-feu.

Cilium : La révolution eBPF dans EKS

Si vous construisez pour 2026, vous vous tournez probablement vers Isovalent Cilium (désormais partie de Cisco). Le virage vers Cilium n'est pas seulement une question de vitesse ; c'est aussi une question de Hubble. Hubble offre une observabilité consciente de la couche 7 (L7) que le VPC CNI ne peut tout simplement pas égaler. Les VPC Flow Logs vous montreront que 10.0.1.5 a communiqué avec 10.0.1.10 sur le port 80. Hubble vous indiquera que service-frontend a appelé service-checkout sur le chemin /api/v1/pay et a reçu une erreur 403 Forbidden.

Service Mesh sans sidecar

Avec Cilium, vous pouvez implémenter le mutual TLS (mTLS) et la gestion du trafic sans la surcharge des sidecars d'Istio ou de Linkerd. En déplaçant la logique vers la couche eBPF, vous réduisez la consommation mémoire d'environ 30 à 40 Mo par pod. Pour un cluster de 1 000 pods, cela représente 40 Go de « taxe de sidecar » récupérée. Pour des informations plus approfondies sur l'optimisation de ces coûts, consultez notre guide sur l'optimisation des coûts de calcul EKS.

Calico : Quand le Multi-Cloud est le seul critère

Calico de Tigera reste une solution puissante, particulièrement pour ceux qui gèrent des environnements hybrides (EKS + OpenShift / K8s upstream On-prem). La force de Calico réside dans son moteur de Global Network Policy. Si vous avez besoin d'un seul fichier YAML qui dicte la politique de sécurité à travers un cluster AWS EKS et un cluster bare-metal dans une installation de colocation, Calico est l'outil. Cependant, dans un environnement AWS uniquement, le mode basé sur iptables de Calico semble de plus en plus dépassé par rapport aux performances eBPF de Cilium, bien que Calico propose désormais une option de plan de données eBPF.

Comparaison des performances : Débit et latence

Lors de nos tests en laboratoire avec netperf sur des instances c6i.4xlarge, la différence devient nette à haute concurrence :

AWS VPC CNI : Performances de référence. Débit de ligne de 25 Gbit/s atteignable, mais la CPU monte en flèche sur le nœud lors des recherches conntrack pour le trafic à petits paquets à haute vitesse.
Cilium (Direct Routing) : 10-15 % d'utilisation CPU inférieure à VPC CNI au même débit. Réduction spectaculaire de la latence de queue (p99) car elle évite la traversée iptables.
Calico (Standard) : Similaire à la surcharge VPC CNI, mais la gestion de la mesh BGP devient un goulot d'étranglement lorsque le nombre de nœuds dépasse 500, à moins d'utiliser des Route Reflectors.

Le piège de la « Prefix Delegation »

De nombreux ingénieurs activent la Prefix Delegation sur VPC CNI pensant que cela résout tous les problèmes d'IP. Ce n'est pas le cas. Lorsqu'un nœud démarre, il pré-alloue un préfixe à partir du VPC. Si vous avez de nombreux petits nœuds (par exemple, t3.medium) dans un petit sous-réseau (par exemple, /24), vous pouvez « manquer » d'IP dans le sous-réseau parce que les nœuds « accaparent » des blocs /28 qu'ils n'utilisent même pas encore. Cilium, lorsqu'il est utilisé avec le mode overlay (Geneve/VXLAN), découple complètement les IPs des pods du CIDR VPC, vous permettant d'exécuter 10 000 pods sur un seul sous-réseau VPC /24. C'est un avantage architectural majeur pour les environnements d'entreprise legacy « en manque d'IP ».

Implications financières pour 2026

AWS VPC CNI est « gratuit », mais il vous contraint à des types d'instances plus grands ou à une consommation d'IP plus élevée, ce qui peut entraîner des coûts de peering VPC ou de Transit Gateway coûteux si vous avez besoin de plus de sous-réseaux. Cilium (Open Source) est gratuit, mais la version Entreprise (avec conformité FIPS et détection avancée des menaces) peut coûter plus de 2 000 $ par nœud et par an. Cependant, les gains d'efficacité compensent généralement cela. En réduisant la surcharge CPU de kube-proxy et en supprimant les sidecars, nous avons constaté que des clients réduisaient leur facture EC2 de 15 à 20 % simplement en migrant vers Cilium eBPF.

Extrait de configuration : Cilium avec Chaining VPC CNI

Si vous souhaitez le meilleur des deux mondes – le réseau natif AWS pour certains pods et la sécurité Cilium pour d'autres – utilisez le mode Chaining Mode. Cela permet à AWS de gérer les adresses IP, mais à Cilium de gérer la politique de sécurité.

# cilium-config-values.yaml
cni:
  chainingMode: aws-cni
enableIPv4Masquerade: false
tunnel: disabled
endpointRoutes:
  enabled: true
# Cette configuration préserve le modèle "ENI-par-Pod" tout en activant
# l'observabilité Hubble et les politiques réseau eBPF.

Matrice de décision

Choisissez AWS VPC CNI si :

Vous êtes une petite équipe (moins de 5 ingénieurs) et souhaitez la surcharge opérationnelle la plus faible.
Vous utilisez les Security Groups AWS comme principal mécanisme de pare-feu.
Vous n'avez pas de contraintes d'adresses IP dans votre VPC.

Choisissez Cilium si :

Vous travaillez à l'« EKS Scale » (plus de 200 nœuds).
Vous avez besoin d'une visibilité L7 (méthodes HTTP, en-têtes) pour le dépannage.
Vous êtes contraint par les adresses IP et avez besoin d'un réseau overlay.
Vous souhaitez éliminer la surcharge de latence/CPU de kube-proxy et iptables.

Verdict final

Pour un cluster EKS de production en 2026, Cilium est le choix par défaut correct. L'AWS VPC CNI est une solution de repli robuste, mais sa dépendance au plan de contrôle VPC pour chaque allocation IP et son manque d'observabilité approfondie en font un goulot d'étranglement pour les équipes DevOps modernes. Si vous démarrez un nouveau projet greenfield sur EKS, déployez Cilium en mode « Native Routing » avec eBPF activé. La courbe d'apprentissage initiale est plus raide, mais les performances et les capacités de dépannage sont bien supérieures à celles de la concurrence legacy.

Besoin d'aide pour refactoriser votre réseau de pods ou migrer votre CNI sans interruption de service ? Explorez nos services d'ingénierie avancée de plateforme AWS sur techleague.io pour optimiser l'efficacité de votre infrastructure.