CiliumはAWS VPC CNIを完全に置き換えますか？

いいえ、Ciliumは完全に置き換えることもできますが、多くのユーザーはAWSネイティブIP管理を維持しながらeBPFセキュリティ機能を獲得するために、CiliumをVPC CNIの上にCNIチェーンとして実行します。

AWS VPC CNI Prefix Delegationとは何ですか？

Prefix Delegationは、ENIが単一のIPではなく/28 IPv4プレフィックスを予約することを可能にし、より小さなインスタンスタイプでのノードあたりのPod数の上限を大幅に増加させます。

Ciliumは高負荷環境をどのように処理しますか？

非常に高い水準で処理します。CiliumはeBPFマップ内で独自のステートを管理するため、標準的なKubernetesクラスターで見られる「iptables-restore」のロックアップなしに、1秒あたり数千のネットワークポリシー更新を処理できます。

Ciliumを使用してVPCのIP枯渇を解決できますか？

はい、Ciliumを「Encapsulation」（VXLAN）モードで使用することで、Pod IPはVPC IPから完全に分離され、非常に小さなVPC CIDR上で大規模なクラスターを運用できます。

SGPの主な利点は何ですか？

Security Groups for Pods（SGP）を使用すると、PodにAWS IAMとVPCレベルのファイアウォールを使用でき、これはKubernetesネイティブポリシーよりも企業コンプライアンスチームにとって監査が容易であることがよくあります。

VPC CNIとCiliumの間で顕著なレイテンシの違いはありますか？

ネイティブルーティングモードでは、シングルストリームのRAWスループットではVPC CNIがわずかに高速ですが、多くの小さな接続と複雑なポリシー規則が関与する実際のシナリオではCiliumが優れています。

2026年のAWS EKSネットワーキング：VPC CNIからCiliumへ移行すべき理由

2026年現在、AWS EKSネットワーキングの「デフォルト」の選択肢であったAWS VPC CNIは、大規模かつセキュリティを最優先する環境においては、もはや絶対的な王者ではありません。AWSはPrefix DelegationやSecurity Groups for Pods（SGP）といった必須機能をアドオンしてきましたが、これらは依然として「漏洩性の抽象化」であり、マイクロサービスをVPCコントロールプレーンのレガシーな制約に縛り付けています。一方、CiliumはeBPFを活用してLinuxのIPTablesスタックのボトルネックを完全に回避します。本稿では、AWSネイティブのIAMベースのネットワークポリシーに関する厳格な規制要件がない限り、100ノードを超えるEKSクラスターやきめ細かいオブザーバビリティを必要とするクラスターにとって、Ciliumが優れたアーキテクチャであると主張します。

アーキテクチャ上のギャップ：IPAMとeBPFデータプレーン

なぜ選択が必要なのかを理解するには、これらのCNIプラグインがOSIレイヤー3および4のトラフィックをどのように処理するかを見る必要があります。AWS VPC CNI（Amazon VPC Container Networking Interface）は「Secondary IP」モデルです。これはEC2ワーカーノードにElastic Network Interface（ENI）を割り当て、それらのENIにセカンダリプライベートIPv4アドレスを付与します。各PodはVPCサブネットから直接IPアドレスを取得します。

対照的に、Cilium（chainingモードまたは完全な代替として動作）はeBPF（Extended Berkeley Packet Filter）データプレーンに焦点を当てています。VPC CNIがLinuxカーネル内の古くなったiptablesまたはipvsに依存しているのに対し（これはサービス数に応じて線形にスケールします）、CiliumはeBPFプログラムを使用してパケットを傍受し、O(1)のハッシュテーブルを介してルーティングします。クラスターに5,000以上のサービスがある場合、iptablesの評価レイテンシはすべてのリクエストに測定可能なミリ秒を追加しますが、Ciliumはそうではありません。

AWS VPC CNI：ネイティブ統合のメリット

AWS VPC CNIの主要な利点は、その「ファーストクラスシチズン」としての位置付けです。PodはVPCネイティブであるため、すべてのAWSツールから可視化されます。追加のエージェントをインストールすることなく、VPC Flow Logsを使用してPodレベルでトラフィックを監査できます。さらに重要なことに、2023年後半に導入され2025年を通じて改良されたPrefix Delegationのような機能は、「IP枯渇」問題を緩和しました。

# Prefix Delegationを有効にしてノードあたりのPod密度を向上させる
kubectl set env daemonset aws-node -n kube-system ENABLE_PREFIX_DELEGATION=true
# これにより、単一のENIが単一のIPではなく/28プレフィックスを処理できるようになり、
# m5.largeインスタンスのPod密度が29から110以上に増加します。

Security Groups for Pods（SGP）はもう一つの「キラー機能」です。SecurityGroupPolicyカスタムリソースを定義することで、AWSセキュリティグループをデプロイに直接割り当てることができます。これは、PodがRDSインスタンスやDirect Connectを介したオンプレミスデータベースにアクセスする必要があり、セキュリティチームが広範なCIDR範囲をホワイトリストに登録することを拒否する場合に不可欠です。事実上、AWS APIをファイアウォールコントローラーとして使用しています。

Cilium：EKSにおけるeBPF革命

2026年向けに構築しているのであれば、おそらくIsovalent Cilium（現在はCiscoの一部）を検討しているでしょう。Ciliumへの移行は速度だけが理由ではありません。Hubbleがその理由です。HubbleはVPC CNIでは到底できないL7認識型のオブザーバビリティを提供します。VPC Flow Logsは10.0.1.5がポート80で10.0.1.10と通信したことを示します。Hubbleはservice-frontendがservice-checkoutをパス/api/v1/payで呼び出し、403 Forbiddenを受け取ったことを伝えます。

サイドカーレスサービスメッシュ

Ciliumを使用すると、IstioやLinkerdのようなサイドカーのオーバーヘッドなしで、相互TLS（mTLS）とトラフィック管理を実装できます。ロジックをeBPFレイヤーに移行することで、Podあたりのメモリ消費量を約30〜40MB削減します。1,000個のPodを持つクラスターの場合、それは約40GBの「サイドカー税」が回収されることを意味します。これらのコスト最適化に関する詳細については、EKSコンピューティングコストの最適化に関するガイドをご覧ください。

Calico：マルチクラウドのみが指標となる場合

TigeraのCalicoは依然として強力であり、特にハイブリッド環境（EKS + オンプレミスのOpenShift/アップストリームK8s）を実行している場合に有効です。Calicoの強みはグローバルネットワークポリシーエンジンです。AWS EKSクラスターとコロケーション施設内のベアメタルクラスター全体でセキュリティポリシーを規定する単一のYAMLファイルが必要な場合、Calicoがそのツールです。しかし、AWSのみの環境では、CalicoのiptablesベースモードはCiliumのeBPFパフォーマンスと比較して時代遅れに感じられます（ただし、Calicoも現在ではeBPFデータプレーンオプションを提供しています）。

パフォーマンス比較：スループットとレイテンシ

c6i.4xlargeインスタンスでのnetperfによるラボテストでは、高同時実行性においてその差が明確になります。

AWS VPC CNI：ベースライン性能。25Gbpsのラインレートは達成可能ですが、高速の小パケットトラフィックでのconntrackルックアップ中にノードのCPUが急上昇します。
Cilium（Direct Routing）：同じスループットでVPC CNIよりもCPU使用率が10〜15%低い。iptablesのトラバースを回避するため、テールレイテンシ（p99）が劇的に減少します。
Calico（標準）：VPC CNIのオーバーヘッドに似ていますが、ノード数が500ノードを超えると、BGPメッシュの管理が、ルートリフレクタを使用しない限りボトルネックになります。

「Prefix Delegation」の罠

多くのエンジニアは、Prefix DelegationをVPC CNIで有効にすればすべてのIP問題が解決すると考えていますが、そうではありません。ノードが起動すると、VPCからプレフィックスを事前割り当てします。小さなサブネット（例：/24）に多くの小さなノード（例：t3.medium）がある場合、ノードがまだ使用していない/28チャンクを「占有」しているため、サブネット内のIPを「使い果たしてしまう」可能性があります。Ciliumをオーバーレイモード（Geneve/VXLAN）で使用すると、Pod IPがVPC CIDRから完全に分離され、単一の/24 VPCサブネット上で10,000個のPodを実行できます。これは、「IPが不足している」レガシーエンタープライズ環境にとって大きなアーキテクチャ上の利点です。

2026年のコストへの影響

AWS VPC CNIは「無料」ですが、より大きなインスタンスタイプまたはより多くのIP消費を強制し、より多くのサブネットが必要な場合には高価なVPCピアリングまたはTransit Gatewayのコストにつながる可能性があります。Cilium（オープンソース）は無料ですが、エンタープライズバージョン（FIPS準拠と高度な脅威検出を含む）は、ノードあたり年間2,000ドルを超える可能性があります。しかし、効率性の向上が通常これを相殺します。kube-proxyのCPUオーバーヘッドを削減し、サイドカーを削除することで、クライアントがCilium eBPFに移行するだけでEC2の請求額が15〜20%削減された事例を見てきました。

設定スニペット：CiliumとVPC CNIのチェイニング

両方の良いとこ取り（一部のPodにAWSネイティブネットワーキング、他のPodにCiliumセキュリティ）をしたい場合は、チェイニングモードを使用します。これにより、AWSがIPを管理し、Ciliumがポリシーを管理できます。

# cilium-config-values.yaml
cni:
  chainingMode: aws-cni
enableIPv4Masquerade: false
tunnel: disabled
endpointRoutes:
  enabled: true
# この設定は、「ENI-per-Pod」モデルを維持しつつ、
# HubbleのオブザーバビリティとeBPFネットワークポリシーを有効にします。

意思決定マトリックス

AWS VPC CNIを選択する場合：

少人数のチーム（エンジニア5人未満）で、運用オーバーヘッドを最小限に抑えたい。
主なファイアウォールメカニズムとしてAWSセキュリティグループを使用している。
VPCにIPアドレスの制約がない。

Ciliumを選択する場合：

「EKSスケール」（200ノード以上）で運用している。
トラブルシューティングのためにL7レベルの可視性（HTTPメソッド、ヘッダー）が必要。
IPが制約されており、オーバーレイネットワークが必要。
kube-proxyとiptablesのレイテンシ/CPUオーバーヘッドを排除したい。

最終的な評価

2026年の本番稼働用EKSクラスターでは、Ciliumが正しいデフォルトです。AWS VPC CNIは堅牢な代替手段ですが、単一のIP割り当てごとにVPCコントロールプレーンに依存することや、深いオブザーバビリティの欠如は、現代のDevOpsチームにとってボトルネックとなります。EKSで新しいグリーンフィールドプロジェクトを開始する場合は、eBPFを有効にした「Native Routing」モードでCiliumをデプロイしてください。初期学習曲線は急ですが、パフォーマンスとトラブルシューティング機能はレガシーな競争相手をはるかに上回ります。

Podネットワーキングのリファクタリングや、ダウンタイムなしでのCNI移行にお困りですか？当社の高度なAWSプラットフォームエンジニアリングサービス（techleague.io）で、インフラを最高の効率で稼働させましょう。