AWS EKS Networking in 2026: Warum Sie VPC CNI wahrscheinlich für Cilium aufgeben sollten

Im Jahr 2026 ist die „Standard“-Wahl für AWS EKS Networking – die AWS VPC CNI – nicht länger der unangefochtene König für hochskalierte, sicherheitsorientierte Umgebungen. Während AWS wesentliche Features wie Prefix Delegation und Security Groups for Pods (SGP) hinzugefügt hat, bleiben diese „leaky abstractions“, die Ihre Microservices an die Legacy-Einschränkungen der VPC-Kontrollebene binden. Cilium hingegen nutzt eBPF, um den Engpass des Linux-IPTables-Stacks vollständig zu umgehen. Dieser Beitrag argumentiert, dass Cilium, sofern Sie keine strengen regulatorischen Anforderungen für AWS-native IAM-basierte Netzwerkrichtlinien haben, die überlegene Architektur für jeden EKS-Cluster ist, der 100 Knoten überschreitet oder granulare Observability erfordert.

Die Architekturlücke: IPAM vs. eBPF Data Planes

Um zu verstehen, warum eine Wahl notwendig ist, müssen wir uns ansehen, wie diese CNI-Plugins den OSI-Layer-3- und 4-Traffic handhaben. Die AWS VPC CNI (Amazon VPC Container Networking Interface) ist ein "Secondary IP"-Modell. Sie weist Ihren EC2-Worker-Nodes Elastic Network Interfaces (ENIs) zu und vergibt diesen ENIs sekundäre private IPv4-Adressen. Jeder Pod erhält eine IP direkt aus Ihrem VPC-Subnetz.

Im Gegensatz dazu konzentriert sich Cilium (im chaining-Modus oder als vollständiger Ersatz) auf die eBPF (Extended Berkeley Packet Filter) Data Plane. Während VPC CNI auf den alternden iptables oder ipvs innerhalb des Linux-Kernels basiert – die linear mit der Anzahl der Services skalieren – verwendet Cilium eBPF-Programme, um Pakete abzufangen und über O(1)-Hash-Tabellen zu routen. Wenn Ihr Cluster 5.000+ Services hat, erhöht die iptables-Evaluierungslatenz messbare Millisekunden zu jeder Anfrage; Cilium tut dies nicht.

AWS VPC CNI: Das Argument für native Integration

Das Hauptargument für die AWS VPC CNI ist ihr Status als „First-Class Citizen“. Da Pods VPC-nativ sind, sind sie für jedes AWS-Tool sichtbar. Sie können VPC Flow Logs verwenden, um den Traffic auf Pod-Ebene ohne die Installation zusätzlicher Agenten zu auditieren. Noch wichtiger ist, dass Features, die Ende 2023 eingeführt und bis 2025 verfeinert wurden, wie zum Beispiel Prefix Delegation, das Problem der „IP-Erschöpfung“ gemildert haben.

# Enable Prefix Delegation zur Erhöhung der Pod-Dichte pro Knoten
kubectl set env daemonset aws-node -n kube-system ENABLE_PREFIX_DELEGATION=true
# Dadurch kann ein einzelnes ENI einen /28 Präfix anstelle einer einzelnen IP verwalten,
# wodurch die Pod-Dichte auf einem m5.large von 29 auf 110+ Pods erhöht wird.

Security Groups for Pods (SGP) ist das andere „Killer-Feature“. Durch die Definition einer SecurityGroupPolicy Custom Resource können Sie einer Bereitstellung direkt eine AWS Security Group zuweisen. Dies ist entscheidend für Umgebungen, in denen ein Pod auf eine RDS-Instanz oder eine On-Premise-Datenbank über Direct Connect zugreifen muss und das Sicherheitsteam sich weigert, einen breiten CIDR-Bereich auf die Whitelist zu setzen. Sie verwenden effektiv die AWS API als Ihren Firewall Controller.

Cilium: Die eBPF-Revolution in EKS

Wenn Sie für 2026 planen, schauen Sie wahrscheinlich auf Isovalent Cilium (jetzt Teil von Cisco). Die Verlagerung hin zu Cilium geht nicht nur um Geschwindigkeit; es geht um Hubble. Hubble bietet L7-aware Observability, die die VPC CNI einfach nicht erreichen kann. VPC Flow Logs zeigen Ihnen, dass 10.0.1.5 mit 10.0.1.10 auf Port 80 kommuniziert hat. Hubble wird Ihnen sagen, dass service-frontend service-checkout auf dem Pfad /api/v1/pay aufgerufen und eine 403 Forbidden-Antwort erhalten hat.

Sidecar-loser Service Mesh

Mit Cilium können Sie mutual TLS (mTLS) und Traffic Management ohne den Overhead von Istio- oder Linkerd-Sidecars implementieren. Durch die Verlagerung der Logik in die eBPF-Schicht reduzieren Sie den Speicherverbrauch um etwa 30-40 MB pro Pod. Für einen Cluster mit 1.000 Pods sind das 40 GB an „Sidecar-Steuern“, die zurückgewonnen werden. Für tiefere Einblicke in die Optimierung dieser Kosten, schauen Sie sich unseren Leitfaden zur Optimierung der EKS-Compute-Kosten an.

Calico: Wenn Multi-Cloud die einzige Metrik ist

Tigera’s Calico bleibt ein Kraftpaket, insbesondere für diejenigen, die Hybrid-Umgebungen (EKS + On-prem OpenShift/Upstream K8s) betreiben. Calicos Stärke ist seine Global Network Policy Engine. Wenn Sie eine einzige YAML-Datei benötigen, die die Sicherheitsrichtlinie über einen AWS EKS-Cluster und einen Bare-Metal-Cluster in einem Colocation-Center festlegt, ist Calico das richtige Tool. In einer reinen AWS-Umgebung wirkt Calicos iptables-basierter Modus jedoch im Vergleich zur eBPF-Leistung von Cilium zunehmend veraltet, obwohl Calico inzwischen auch eine eBPF-Data-Plane-Option anbietet.

Performance-Vergleich: Durchsatz und Latenz

In unseren Labortests mit netperf auf c6i.4xlarge Instanzen wird der Delta bei hoher Parallelität deutlich:

• AWS VPC CNI: Basisleistung. 25 Gbps Leitungsrate erreichbar, aber CPU-Spitzen auf dem Knoten während conntrack-Lookups bei hochvolumigem Kleinstpakettraffic.
• Cilium (Direct Routing): 10-15% geringere CPU-Auslastung als VPC CNI bei gleichem Durchsatz. Dramatische Reduzierung der Tail Latency (p99), da die iptables-Traversierung vermieden wird.
• Calico (Standard): Ähnlicher Overhead wie VPC CNI, aber die Verwaltung des BGP-Meshes wird zu einem Engpass, wenn die Knotenanzahl 500 überschreitet, es sei denn, Route Reflectors werden verwendet.

Die „Prefix Delegation“ Falle

Viele Ingenieure aktivieren Prefix Delegation auf VPC CNI und denken, es löse alle IP-Probleme. Das tut es nicht. Wenn ein Knoten startet, pre-alloziiert er ein Präfix aus der VPC. Wenn Sie viele kleine Knoten (z.B. t3.medium) in einem kleinen Subnetz (z.B. /24) haben, können Ihnen die IPs im Subnetz „ausgehen“, weil Knoten /28-Chunks „horten“, die sie noch gar nicht nutzen. Cilium, wenn es mit Overlay-Modus (Geneve/VXLAN) verwendet wird, entkoppelt Pod-IPs vollständig vom VPC CIDR, sodass Sie 10.000 Pods in einem einzigen /24 VPC-Subnetz betreiben können. Dies ist ein massiver architektonischer Vorteil für „IP-starved“ Legacy-Unternehmensumgebungen.

Kostenimplikationen für 2026

AWS VPC CNI ist „kostenlos“, zwingt Sie aber zu größeren Instance Types oder höherem IP-Verbrauch, was zu teuren VPC Peering- oder Transit Gateway-Kosten führen kann, wenn Sie mehr Subnetze benötigen. Cilium (Open Source) ist kostenlos, aber die Enterprise-Version (mit FIPS-Konformität und erweiterter Bedrohungserkennung) kann über 2.000 US-Dollar pro Knoten pro Jahr kosten. Die Effizienzgewinne gleichen dies jedoch in der Regel aus. Durch die Reduzierung des CPU-Overheads von kube-proxy und die Eliminierung von Sidecars haben wir bei Kunden eine Reduzierung der EC2-Rechnung um 15-20% allein durch die Migration zu Cilium eBPF beobachtet.

Konfigurationsausschnitt: Cilium mit VPC CNI Chaining

Wenn Sie das Beste aus beiden Welten wünschen – AWS native Netzwerke für einige Pods und Cilium Security für andere – verwenden Sie den Chaining Mode. Dies ermöglicht AWS die Verwaltung der IP, aber Cilium die Verwaltung der Policy.

# cilium-config-values.yaml
cni:
  chainingMode: aws-cni
enableIPv4Masquerade: false
tunnel: disabled
endpointRoutes:
  enabled: true
# Diese Einrichtung bewahrt das "ENI-per-Pod"-Modell, während 
# Hubble Observability und eBPF-Netzwerkrichtlinien aktiviert werden.

Entscheidungsmatrix

Wählen Sie AWS VPC CNI, wenn:

• Sie ein kleines Team (unter 5 Ingenieuren) sind und den geringsten operativen Aufwand wünschen.
• Sie AWS Security Groups als primären Firewalling-Mechanismus verwenden.
• Sie keine IP-Adressbeschränkungen in Ihrer VPC haben.

Entscheiden Sie sich für Cilium, wenn:

• Sie in „EKS Scale“ (200+ Knoten) arbeiten.
• Sie L7-Sichtbarkeit (HTTP-Methoden, Header) zur Fehlerbehebung benötigen.
• Sie IP-eingeschränkt sind und ein Overlay-Netzwerk benötigen.
• Sie den Latenz-/CPU-Overhead von kube-proxy und iptables eliminieren möchten.

Endgültiges Urteil

Für einen produktionsreifen EKS-Cluster im Jahr 2026 ist Cilium der korrekte Standard. Die AWS VPC CNI ist ein robuster Fallback, aber ihre Abhängigkeit von der VPC Control Plane für jede einzelne IP-Zuweisung und ihr Mangel an tiefer Observability machen sie zu einem Engpass für moderne DevOps-Teams. Wenn Sie ein neues Greenfield-Projekt auf EKS starten, setzen Sie Cilium im „Native Routing“-Modus mit aktiviertem eBPF ein. Die anfängliche Lernkurve ist steiler, aber die Performance- und Troubleshooting-Fähigkeiten sind den Legacy-Konkurrenten weit voraus.

Benötigen Sie Hilfe beim Refactoring Ihres Pod-Netzwerks oder bei der Migration Ihres CNI ohne Ausfallzeiten? Entdecken Sie unsere erweiterten AWS Platform Engineering Services auf techleague.io, um Ihre Infrastruktur mit höchster Effizienz zu betreiben.