AWS NETWORKING
Amazon VPC CNI
完全ガイド
KubernetesのPodがVPCのIPアドレスを持つ仕組みを、たとえ話でやさしく解説
🎯 結論：VPC CNIを使うと、KubernetesのPodが普通のEC2インスタンスと同じようにVPC内でIPを持ち、直接通信できる
— NATなし・追加ルーティングなし・シンプル！
たとえ話で理解する
マンションの部屋番号に例えると…
複雑なネットワーク設定も、マンション管理に例えるとスッキリ理解できます
🏠 アナロジー
「各Podは独立した部屋を持つマンション住人」
🏢 マンションの世界
🏙️
都市（VPC）
すべての建物と住人が属する大きなエリア
🏢
マンション（Node/EC2）
複数の部屋を持つ建物
📮
部屋番号（IPアドレス）
住人への郵便が届く一意の番号
🔑
管理人（VPC CNI）
新しい住人に部屋番号を割り当てる
☁️ AWSの世界
🌐
VPC（Virtual Private Cloud）
独自のIPアドレス空間（例: 10.0.0.0/16）
🖥️
EC2インスタンス（EKS Node）
Podが動作する物理サーバー相当
🐳
Pod（コンテナグループ）
アプリが動くKubernetesの最小単位
🔢
VPC内IPアドレス（例: 10.0.1.42）
VPC CIDRから割り当てられる一意のIP
🔌
Amazon VPC CNI Plugin
PodにVPC IPを自動で割り当てるプラグイン
アーキテクチャ図
PodとIPアドレスの関係を視覚化
VPC CNIにより、PodはVPC CIDRから直接IPアドレスを割り当てられます
VPC 10.0.0.0/16 内のEKSクラスター構成
🌐 VPC — 10.0.0.0/16
全Podのアドレスはこの範囲から
🖥️ Node 1 (EC2)
10.0.1.10
🔌 ENI (ネットワークカード)
↑ VPC CIDRから直接割り当て
🖥️ Node 2 (EC2)
10.0.2.10
🔌 ENI (ネットワークカード)
↑ VPC CIDRから直接割り当て
⬇️
✅ Pod A → Pod C への直接通信
10.0.1.41 → 10.0.2.55 NATなし・追加ルーティングなし・シンプル！
仕組みを追う
PodにIPが割り当たるまでの4ステップ
CNIプラグインが裏側で何をしているか、順番に見てみましょう
1
Pod作成要求
KubernetesがNodeにPodをスケジュール
2
CNI呼び出し
kubeletがCNIプラグイン（VPC CNI）を呼び出し
3
ENIからIP取得
NodeのENIからVPC CIDRのIPを確保
4
Pod起動完了
PodはVPC IPを持ち通信可能に！
3つの主要な特徴
VPC CNIが実現すること
Podに直接VPC IPを付与することで、以下3つのメリットが生まれます
🔢
一意のIPアドレス
各PodはVPCのCIDR範囲内から一意のIPを持ちます。同じVPC内のEC2インスタンスやRDSと同様に扱えます。
🌐
直接アクセス可能
NATや特別なルーティング設定なしに、VPC内の他リソースからPodへ直接通信できます。
🔒
VPCセキュリティ制御
セキュリティグループやネットワークACLをPodレベルで適用可能。きめ細かいアクセス制御が実現できます。
セキュリティ
Podレベルのネットワーク制御
VPCの強力なセキュリティ機能をそのままPodに適用できます
🛡️
セキュリティグループ（SG）
EC2と同様に、Pod単位でインバウンド・アウトバウンドのトラフィックルールを定義できます。
例：WebサーバーPodはポート80/443のみ許可、DBは3306のみ。
📋
ネットワークACL（NACL）
サブネットレベルで適用されるステートレスなファイアウォール。Pod が配置されたサブネットのNACLルールが自動的に適用されます。
例：特定のCIDRブロックからのアクセスをサブネット全体で拒否。
比較表
他のCNIプラグインとの違い
VPC CNIが他プラグインと何が違うのか、主要ポイントで比較
セキュリティグループをPodに適用
✅ 対応
❌ 非対応
AWSサービスとの統合
✅ ネイティブ
△ 追加設定必要
オーバーレイネットワーク
❌ 不使用（シンプル）
✅ 使用
EKSデフォルト採用
✅ デフォルト
❌ 追加インストール
⚡
IPアドレス枯渇に注意！
VPC CNIはPodごとにVPC IPを消費します。大規模クラスターでは、適切なVPC CIDRサイズの設計が重要です。例えば /21 サブネット（2,048 IP）でも、大量のPodを動かすと枯渇する場合があります。CIDR設計は余裕を持って計画しましょう。
トラフィック制御
externalTrafficPolicy
Kubernetesサービスの設定パラメータで、外部トラフィックの処理方法を定義します。Cluster と Local の2つの値があります。
🔑 ポイント：ソースNATが発生するかどうかが最大の違いです
Cluster
🌐 クラスター全体に分散
トラフィックはクラスター内の任意のノードに分散されます。ノード間でのトラフィック転送時にソースNATが発生し、クライアントのIPが書き換えられます。
📦 通信フロー（ソースNAT発生）
↓ 接続先NodeB（Podなし）
↓ 転送（ノード間ホッピング）
⚠️ 元のクライアントIPが失われる
Local
📍 Podがあるノードに限定
トラフィックはターゲットPodがあるノードにのみ送信されます。ノード間転送が不要なためソースNATが発生せず、クライアントIPを保持できます。
📦 通信フロー（ダイレクト配送）
↓ 直接 Node A へ（Podあり）
✅ クライアントIPがそのまま保持される
📊 負荷分散
Cluster：均等分散
Local：Podのあるノードのみ
🔀 ソースNAT
Cluster：発生する
Local：発生しない
💡 主なユースケース
Cluster：一般的なWebアプリ
Local：クライアントIP取得が必要なアプリ
よくある質問
FAQ
初心者がつまずきやすいポイントをまとめました
Q
VPC CNIはEKSで必ず使わないといけないの？
AWSの Amazon EKS ではデフォルトでVPC CNIが採用されています。他のCNI（Calico, Ciliumnなど）も技術的には使用できますが、AWSとのネイティブ統合（セキュリティグループのPod適用など）を活用したい場合はVPC CNIが最適です。
Q
ENI（Elastic Network Interface）って何ですか？
ENIはEC2インスタンスの「ネットワークカード」に相当します。1枚のネットワークカードに複数のIPを割り当てられるイメージです。VPC CNIはEC2インスタンスのENIから「セカンダリIPアドレス」を取り出して、各Podに割り当てています。
Q
1つのNodeに配置できるPodの数に制限はありますか？
はい、あります。EC2インスタンスタイプによってアタッチできるENIの数と、1ENIあたりのIPアドレス数が異なるため、Node当たりの最大Pod数が決まります。例えばm5.largeは最大29個のPodが目安です。これは設計時の重要な制約です。
Q
Podが別のAZのリソースに通信できますか？
はい、VPC内であれば別のアベイラビリティゾーン（AZ）のリソースとも直接通信できます。ただし、AZ間通信にはデータ転送料金が発生する場合があるため、パフォーマンスとコストのバランスを考慮した設計が推奨されます。