コンテナワークロードのネットワーク設計

1. コンテナネットワークの設計単位

コンテナのネットワーク設計は、サービス名を覚えるのではなく、タスク / PodがVPC上で何を消費するかから考えます。

ネットワーク単位は？
↓
最大タスク / Pod数は？
↓
IP / ENI / ウォームプールのどこが容量になる？
↓
ボトルネックに合う対策を選ぶ
↓
セキュリティグループ / アウトバウンド / ロードバランサーを設計

通常のEC2なら、まずEC2台数分のプライマリIPアドレスを考えます。しかしコンテナでは、ノード数より多いタスク / PodがVPCのIPアドレスを消費します。

EC2ノード × 10
その上で Pod × 500

Amazon EKSの標準的なVPC CNIではPod自体がVPCのIPアドレスを消費します。Amazon ECSのawsvpcモードでは各タスクが独自ENIを持ちます。したがってノード数だけ確認してサブネットサイズを決めるのは危険です。

2. ECS `awsvpc`とタスクENI

ECSのネットワークモード

Amazon ECSのEC2上のLinuxタスクでは主に次のネットワークモードを利用できます。

Windows EC2 タスクではdefaultとawsvpcが利用できます。AWSは一般的なECSワークロードでawsvpcを推奨しており、AWS Fargateではawsvpcが必須です。

SAP-C02では各Dockerネットワークモードの内部実装を暗記するより、Fargate → awsvpc必須、awsvpc → タスクがVPCネットワークへ直接参加を理解します。

`awsvpc`とタスクENI

awsvpcでは、各ECSタスクへ独自のElastic Network Interface（ENI）が割り当てられます。

VPC
├─ タスク A
│   └─ ENI 10.0.10.10
├─ タスク B
│   └─ ENI 10.0.10.11
└─ タスク C
    └─ ENI 10.0.10.12

タスクはEC2インスタンスと同じようにVPC内のIPアドレスを持ち、タスクENIへセキュリティグループを適用できます。

1つのECSタスク内にアプリケーション / ログ記録 / プロキシなど複数コンテナが存在していても、awsvpcではタスク単位でENIが割り当てられます。同じタスク内のコンテナはネットワーク名前空間を共有し、localhostで相互通信できます。

3コンテナ ≠ 3 ENI
1タスク = 1タスクENI

ECS Fargate

AWS Fargate上のECSタスクではawsvpcが必須です。各Fargateタスクには1つのENIとプライマリプライベートIPv4アドレスが割り当てられます。デュアルスタック構成ならIPv6アドレスもタスクENIへ割り当てられます。1つのFargateタスクに同時に関連付けられるENIは1つです。

3. ECSのセキュリティグループと接続性

パブリックサブネットでのECS Fargate

ECS Fargateタスクをパブリックサブネットへ配置する場合、タスクENIへパブリックIPv4アドレスを割り当てる構成が可能です。

インターネット
   │
インターネットゲートウェイ
   │
パブリックサブネット
   │
Fargateタスク
パブリックIPあり

プライベートサブネットならNAT ゲートウェイなどのアウトバウンド経路を利用できます。

プライベートサブネットのアウトバウンド

プライベートサブネットのコンテナが必要としているのがAmazon ECR、Amazon CloudWatch Logs、AWS Systems ManagerなどAWSサービスへのアクセスだけなら、要件によってはVPCエンドポイントを利用してパブリックインターネットへの依存を減らせます。

プライベートコンテナ
→ 必ずNAT ゲートウェイ

と固定せず、必要な接続先を確認してインターネットアクセスかVPCエンドポイントかを判断します。必要な接続先に応じてVPCエンドポイントも候補になります。

タスク単位のセキュリティグループ

awsvpcではコンテナホスト全体ではなくタスクへセキュリティグループを適用できます。

ALB
 │ TCP 443
 ▼
ウェブタスクSG
 │ TCP 8080
 ▼
APIタスクSG
 │ TCP 5432
 ▼
データベース SG

同じEC2 コンテナインスタンス上に存在するから同じファイアウォールポリシー、とは限りません。

ロードバランサーへの登録

awsvpc タスクはEC2インスタンスそのものではなくタスクENIでネットワークへ参加します。そのため、タスクを直接ターゲットにする場合はIPターゲットを使用します。

ALB / NLB
   │
ターゲットグループ
ターゲットタイプ = IP
   │
タスクENI IP

4. ECSをスケールさせるときのネットワークキャパシティ

`awsvpc`で指定できるネットワーク設定

awsVpcConfigurationでは、現行仕様上、サブネットは最大16、セキュリティグループは最大5を指定できます。

SAP-C02では16 / 5の丸暗記より、複数AZのサブネットを指定し、タスクへ適切なセキュリティグループを適用できることが重要です。

サブネット IP容量

例えばFargateサービスを30タスクから500タスクへスケールします。各タスクが1つのENIとプライベートIPv4を消費するなら、サブネット内に大量の空きIPアドレスが必要です。

/24は通常251個の利用可能IPv4なので、1つの/24だけでは500タスク分を収容できません。さらにロードバランサー、NAT ゲートウェイ、その他ENIなどもアドレスを消費します。

コンテナの最大タスク数から逆算してサブネットを設計する必要があります。

EC2側のENI容量

EC2上でawsvpc タスクを実行する場合、タスクENIはコンテナインスタンスへ接続されます。EC2インスタンスタイプにはENI数の上限があるため、CPU / メモリに空きがあってもENI容量不足でタスクを追加できない場合があります。

コンテナ容量
= CPU + メモリ + ENI + IPアドレス

ENIトランキング

EC2上のAmazon ECSでは、対応インスタンスタイプでENIトランキングを利用し、awsvpc タスクをより高密度に配置できます。これはインスタンス側のENI容量制限を緩和しますが、サブネットのIPアドレスそのものが無限になるわけではありません。

ENI容量改善 ≠ サブネットIP枯渇解消

5. EKSとAmazon VPC CNI

ECSではタスクがネットワーク単位でした。Amazon EKSでは基本的にPodを見ます。Amazon EKSは標準でAmazon VPC CNIを使用し、AWS上のノードで動くPodへVPCネットワークからIPアドレスを割り当てます。

Amazon VPC CNI

標準的なIPv4 EKS構成では、Amazon VPC CNIがノード上のENIとIPアドレスを管理し、PodへVPCのIPを割り当てます。

EC2 ワーカーノード
├─ プライマリENI
├─ セカンダリENI
│   ├─ Pod IP
│   ├─ Pod IP
│   └─ Pod IP
└─ セカンダリENI
    ├─ Pod IP
    └─ Pod IP

EKS標準VPC CNIではPod IPがVPCネットワークと統合されています。Pod IPは単なるノード内部専用オーバーレイアドレスではなくVPC側のアドレスとして扱われるため、VPCフローログ、VPCルーティング、セキュリティ制御などAWSネットワーク機能との統合性が高くなります。

Pod数とサブネット IP

例えばEC2ノードが20台、Podが1,000個の場合、ノードが20台だから20個程度のIPv4で足りるとはなりません。デフォルトVPC CNIではPodがVPC CIDRのIPアドレスを使用するため、大規模クラスターではサブネットのIPv4枯渇が重要な設計要因になります。

ウォームプール

VPC CNIのipamdはPod起動を高速化するため、ENI / IPアドレス / プレフィックスのウォームプールを維持します。現在実行中のPod数とサブネットから消費されるIP数が必ず一致するとは限りません。Podで使用中のIPに加えて将来のPod起動用として事前確保されるIPも存在し得るため、サブネット容量を限界まで使う設計は避けます。

6. EKSのノード当たりPod キャパシティ

ノード当たりのネットワークキャパシティ

EC2ノードで標準VPC CNIを利用する場合、Pod密度はノードへアタッチ可能なENI数と、各ENIが持てるIP / プレフィックス数の影響を受けます。vCPU / メモリが大きいインスタンスだから必ず大量Podを配置できる、とは限りません。ネットワーク容量も確認します。

プレフィックス委任

大量Podを配置するときに利用できるのがプレフィックス委任です。IPv4ではENIの1スロットへ個々のIPを1つずつ割り当てる代わりに/28 プレフィックスを割り当てられます。/28には16個のIPv4アドレスが含まれます。

ENIスロット
  └─ /28
      ├─ IP
      ├─ IP
      └─ 16アドレス

これによりノード当たりのPod密度を高められます。IPv6ではENIスロットへ/80 プレフィックスを割り当てる方式が利用されます。

プレフィックス委任はIPv4アドレスを作り出す機能ではありません。サブネットから連続したプレフィックスをENIへ割り当てます。サブネット自体に空きアドレスがなければ解決できず、細かく断片化されていると必要な連続プレフィックスを確保できない場合もあります。

Pod密度を増やしたいからプレフィックス委任、だけで終わらず、サブネット容量も確保されているかまで確認します。

7. EKSのIP不足を原因別に解決する

利用可能なPod用アドレス空間を広げる

大規模なIPv4 EKSクラスターでは、ノード用サブネットとPod用IPが同じアドレス空間を消費し続けると、PodのスケールによってサブネットのIPv4アドレスが不足する場合があります。

ここでは、IP不足だから即カスタムネットワークとは判断しません。まず何を解決したいのかを分けます。

Podへ割り当てられるサブネットを増やしたい
→ 拡張サブネット検出

Podをノードとは別のサブネット / セキュリティグループへ
明示的に配置したい
→ カスタムネットワーク

ノード1台あたりのPod密度を上げたい
→ プレフィックス委任

IPv4そのものの枯渇を長期的に避けたい
→ IPv6を評価

拡張サブネット検出

Amazon VPC CNIでは、対応する追加サブネットを利用して、ノードのプライマリENIと同じサブネットだけではなく、同一VPC・同一AZ内の追加サブネットからPod用IPを割り当てられます。

単純にPodへ利用できるIPアドレス空間を増やしたいという要件なら、カスタムネットワークを組む前に検討します。

カスタムネットワーク

カスタムネットワークではENIConfigを利用し、Podへ使用するサブネットやセキュリティグループをAZ単位で明示的に指定できます。

ノード
→ 10.0.0.0/20

Pod
→ 100.64.0.0/16

既存RFC1918空間が不足し、IPv6へすぐ移行できず、Pod用ネットワークを明示的に分離したい場合は有力な選択肢です。

原因別の選択

EKSのIPv4不足対策は、すべて同じ問題を解決するわけではありません。

プレフィックス委任の責任

プレフィックス委任はノード当たりのPod密度を高めるための仕組みです。サブネットのIPv4総数を増やす機能ではありません。

プレフィックス委任
→ ENIスロットを効率利用
→ Pod密度向上

ただし

プレフィックス委任
≠ サブネットのIPv4総数を増加

カスタムネットワークのトレードオフ

カスタムネットワークでは、ノードのプライマリENIを通常のPod IP割り当てに使用しなくなるため、構成によってはノード当たりの最大Pod数が低下します。

また、セカンダリCIDR、Pod用サブネット、ENIConfig、AZごとの設定、セキュリティグループなど管理対象も増えます。

したがって、IPv4不足だから必ずカスタムネットワークではありません。単に利用可能なPod用サブネットを増やしたいなら拡張サブネット検出、ノード当たりのPod密度ならプレフィックス委任、新規設計でIPv6を採用可能ならIPv6も含めて比較します。

8. EKSのセキュリティグループ

Podのセキュリティグループ

標準構成では多くのPod通信はノードのENIに設定されたセキュリティグループの影響を受けますが、Amazon EKSではPodのセキュリティグループを使用して、選択したPodへEC2セキュリティグループを適用できます。

フロントエンドPod → SG-フロントエンド
バックエンドPod  → SG-バックエンド
データベース     → SG-データベース

ECSとの粒度比較

コンテナだからセキュリティグループを使えない、ではありません。VPCネイティブネットワークを使うことでコンテナワークロードもAWSのネットワークセキュリティ制御へ統合できます。

9. EKS Fargate

ネットワーク単位

Amazon EKSでもAWS Fargateを利用できます。EKS Fargateでは各Podが独立したコンピューティング境界を持ち、ENIも他Podと共有しません。

Fargate Pod A
└─ ENI / IP

Fargate Pod B
└─ ENI / IP

Fargate Pod数が増えるほどサブネットIP容量も重要です。

ECS Fargateとの違い

ECS Fargateはパブリックサブネットを使用し、タスクENIへパブリックIPを割り当てる構成が可能です。

EKS FargateはFargateプロファイルにプライベートサブネットのみ指定可能で、Fargate PodにはパブリックIPアドレスが割り当てられません。

AWS Fargate = 全部同じネットワーク仕様

ではありません。ECSで使うFargateかEKSで使うFargateかを区別します。

アウトバウンド

EKS Fargate Podはプライベートサブネットで動作します。外部通信が必要ならNAT ゲートウェイなどを利用でき、インターネットアクセスを持たないプライベートクラスターでは必要なAWSサービスへのVPCエンドポイントなどを設計します。

ロードバランサー

EKS Fargate PodをApplication Load BalancerやNetwork Load Balancerのターゲットにする場合、IPターゲットタイプが必要です。ノードのインスタンスIDをターゲットにする方式は使用できません。

ALB / NLB
   │
ターゲットタイプ = IP
   │
Fargate Pod IP

EC2 ノード上のEKSとの差

EC2ノード上のEKSワークロードではインスタンスターゲットまたはIPターゲットを構成できます。IPターゲットならロードバランサーからPodへ直接トラフィックを転送できるため、NodePort等の追加ホップを減らせます。

10. ECS / EKS / Fargateのネットワーク単位比較

ネットワーク単位

これを理解すると、何個のIPアドレスが必要かを判断しやすくなります。

比較

11. 最大スケールからIP容量を逆算する

次の環境を考えます。

ECS Fargate
最大400タスク

EKS
最大 3,000 Pod

現在
/24 サブネット × 2

/24のサブネットを2つ用意しただけでは、ECS タスク、EKS ノード / Pod、ロードバランサー、NAT ゲートウェイ、その他ENI、VPC CNIのウォームプールなどが消費するIPアドレスを収容できない可能性があります。

ここでは単にサブネットを大きくするのではなく、最大タスク / Pod数から必要なIP容量を見積もり、何がボトルネックかを分けます。

最大タスク / Pod数
↓
必要なIP容量を見積もる
↓
何がボトルネック？

├─ サブネットそのもののIP不足
│   → CIDR / サブネット追加
│
├─ EKSで利用可能なPod サブネット不足
│   → 拡張サブネット検出
│
├─ ノードとPodのアドレス空間を明示分離
│   → カスタムネットワーク
│
├─ ノード当たりのPod密度不足
│   → プレフィックス委任
│
└─ 新規設計でIPv6採用可能
    → IPv6を評価

12. スケールできないときの切り分け

コンテナが起動できない場合、CPU / メモリ不足だけを見るのは不十分です。

確認対象には、サブネットの利用可能IP、ENIクォータ、インスタンスのENI容量、セキュリティグループ、ルートテーブル、NAT / エンドポイント、ロードバランサーのターゲットなども含めます。

ECS awsvpcではENI不足によりタスク配置が失敗する場合があり、EKSではIP不足がPodのスケールの障害になり得ます。

13. SAP-C02判断フロー

コンテナワークロード
        │
        ▼
ECS / EKS？
        │
        ▼
EC2 / Fargate？
        │
        ▼
ネットワーク単位は？
タスク / Pod
        │
        ▼
最大いくつまでスケール？
        │
        ▼
サブネットのIP容量は十分？
        │
        ▼
EC2利用ならENI容量は十分？
        │
        ▼
ネットワークアクセスをどの粒度で分離？
タスク / Pod / ノード
        │
        ▼
外部通信先は？
インターネット / AWSサービス / VPC内部
        │
        ▼
ロードバランサーの対象は？
インスタンス / IP
        │
        ▼
EKSでIP不足？
        │
        ├─ ノード当たりPod密度
        │    → プレフィックス委任
        │
        ├─ Pod用サブネットを追加利用
        │    → 拡張サブネット検出
        │
        ├─ Pod用サブネット / SGを明示分離
        │    → カスタムネットワーク
        │
        └─ IPv6採用可能
             → IPv6を評価

重要なのは、対策名から選ぶのではなく、どのネットワーク容量が不足しているのかを先に特定することです。

14. 混同ポイント

失敗1：EKSノードが20台だから/24で十分

Pod自体が大量にVPC IPを消費する可能性を無視しています。

失敗2：ECS Fargateタスクにコンテナが3つあるのでENIも3つ必要

誤り。 1タスクで1 ENI。タスク内コンテナはネットワーク名前空間を共有します。

失敗3：FargateならサブネットIPを消費しない

誤り。 ECS FargateタスクやEKS Fargate PodもサブネットのIPアドレス容量を使用します。

失敗4：ECS FargateとEKS Fargateはパブリックサブネットの仕様も同じ

誤り。 ECS FargateではタスクへパブリックIPを割り当てられますが、EKS Fargate Podはプライベートサブネットのみです。

失敗5：EKSのIP枯渇をプレフィックス委任だけで解決する

プレフィックス委任もサブネット内のIPアドレスを利用するため、サブネットそのものの容量不足は残ります。

失敗6：EKSではPodへセキュリティグループを適用できない

誤り。 Podのセキュリティグループを利用できます。

失敗7：awsvpc タスクをロードバランサーへ登録するときインスタンスターゲットを必ず使う

誤り。 タスクENIを直接ターゲットにする構成ではIPターゲットを利用します。

失敗8：コンテナがスケールしないのでCPUを増やせばよい

サブネットIPやENI容量が原因ならコンピューティング容量を増やしても解決しません。

15. まとめ

ECS awsvpc
→ タスクごとにENI
→ タスクごとにVPC IP
→ タスク単位のセキュリティグループ

ECS Fargate
→ awsvpc必須
→ タスクENI
→ パブリック IP割り当て可能

EC2上のECS
→ CPU / メモリだけでなくENI容量
→ 必要ならENIトランキング
→ ただしサブネット IP容量は別問題

EKS
→ Amazon VPC CNI
→ PodがVPC IPを消費
→ ウォームプールも考慮

EKSでノード当たりPod密度不足
→ プレフィックス委任

EKSで利用可能なPod用サブネットを増やす
→ 拡張サブネット検出

EKSでPod用サブネット / セキュリティグループを明示分離
→ カスタムネットワーク
→ 運用負荷・Pod密度のトレードオフも確認

EKSでIPv4枯渇を長期的に避けたい
→ IPv6を評価

EKS Fargate
→ Podごとにネットワーク境界
→ プライベートサブネットのみ
→ パブリック IPなし

コンテナスケール
→ CPU / メモリ
+
ENI
+
IPアドレス
+
サブネット
+
接続性
を一体で設計

最重要ポイントは、コンテナの最大タスク / Pod数からネットワーク容量を逆算し、IP不足・ENI不足・Pod密度不足を別の問題として判断することです。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional（SAP-C02）試験ガイド
• SAP-C02対象サービス
• Amazon ECSのawsvpcタスクネットワーキング
• ECS Fargateのネットワーク
• Amazon EKS VPC CNI
• Amazon EKS IPアドレス使用率の最適化
• Podのセキュリティグループ
• Amazon EKS Fargate
• Amazon EKS 拡張サブネット検出
• Amazon EKS カスタムネットワーク