ECS vs EKS — コンテナオーケストレーション選択基準

ECS と EKS の基本比較

特徴	ECS	EKS
オーケストレーター	AWS独自	Kubernetes
管理の複雑さ	シンプル	高い（K8sの知識が必要）
コントロールプレーン	マネージド（追加料金なし）	マネージド（$0.10/時間）
学習コスト	低	高
ポータビリティ	AWS専用	マルチクラウド対応
エコシステム	AWS統合に優れる	Kubernetesエコシステム
Fargate対応	✅	✅（Fargate Profile）

ECS のアーキテクチャ

ECSクラスター
  ├── EC2起動タイプ: ECS Agent がインストールされたEC2インスタンス
  │     → ユーザーがEC2を管理（AMI更新、パッチ等）
  │
  └── Fargate起動タイプ: サーバーレス
        → インフラ管理不要
        → タスク定義でCPU/メモリを指定

ECSの特徴:
  - タスク定義 = Dockerコンテナの仕様書
  - サービス = タスクの実行数管理
  - クラスター = リソースのグループ
  - ELBとのネイティブ統合が容易

EKS のアーキテクチャ

EKSクラスター
  ├── コントロールプレーン（AWSマネージド）: APIサーバー、etcd等
  │
  └── データプレーン（ユーザー管理）
        ├── マネージドノードグループ（EC2）
        │     → EC2の管理をAWSが補佐
        ├── セルフマネージドノード
        │     → EC2をフルコントロール
        └── Fargate Profile
              → サーバーレスノード

EKSの主要コンポーネント:
  Pod: コンテナの最小デプロイ単位
  Deployment: Podのレプリカ管理
  Service: Pod群へのアクセスエンドポイント
  Ingress: L7ルーティング（ALBと統合）

ネットワーキングの違い

ECS（awsvpcモード）:
  → タスクごとにENIを割り当て
  → AWSセキュリティグループを直接適用
  → シンプルなVPC統合

EKS:
  → Pod IPはVPC IPアドレスを使用（Amazon VPC CNI）
  → NetworkPolicyで細かいPod間通信制御
  → Calico/Cilium等のCNIプラグインも選択可能

EKS + ALB Ingress（AWS Load Balancer Controller）:
  → K8s Ingressリソースが自動的にALBを作成
  → アノテーションでALBの設定を制御

# EKS Ingress の設定例
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
spec:
  rules:
  - http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 8080

スケーリングの違い

ECS のスケーリング:
  Application Auto Scaling → タスク数をスケーリング
  → CPU/メモリ/カスタムメトリクスでスケール
  
EKS のスケーリング:
  Horizontal Pod Autoscaler (HPA) → Podをスケーリング
  Cluster Autoscaler → ノード（EC2）をスケーリング
  KEDA → イベント駆動スケーリング（SQSキュー深度等）
  
Karpenter（EKS向け）:
  → ノードプロビジョニングの自動化
  → Spot + On-Demand の混在が容易
  → より高速なスケールアウト

コスト比較

ECS:
  コントロールプレーン: 無料
  EC2起動タイプ: EC2インスタンス料金のみ
  Fargate: タスクのCPU/メモリに対して課金

EKS:
  コントロールプレーン: $0.10/時間 = 約$73/月/クラスター
  EC2ノード: EC2インスタンス料金
  Fargate: タスクのCPU/メモリに対して課金
  
開発環境でのEKSコスト削減:
  → 夜間にノードグループを0にスケールダウン
  → ただしコントロールプレーン費用は発生し続ける

選択ガイドライン

ECSを選ぶべきケース:
  ✅ AWS専用で開発・運用する場合
  ✅ Kubernetesの知識がないチーム
  ✅ シンプルさを優先する場合
  ✅ 小〜中規模のサービス
  ✅ コスト最小化（コントロールプレーン無料）

EKSを選ぶべきケース:
  ✅ マルチクラウドまたはオンプレミスへの移植性が必要
  ✅ Kubernetesエコシステム（Istio, Helm, Argo CD等）を活用したい
  ✅ 既存のKubernetesワークロードを移行する
  ✅ Service Meshが必要（Istio/App Mesh）
  ✅ 高度なカスタムスケーリング要件

試験頻出ポイント

シナリオ	回答
AWSネイティブでシンプルなコンテナ実行	ECS
KubernetesワークロードをAWSで実行	EKS
コントロールプレーンの料金	ECS: 無料、EKS: $0.10/時間
EKSでポッド間通信制御	NetworkPolicy（Calico等）
サーバーレスでコンテナを実行	ECS Fargate または EKS + Fargate Profile

まとめ

ECSはAWSネイティブでシンプルな管理、EKSはKubernetesの豊富なエコシステムと移植性を提供する。チームのスキル、マルチクラウド要件、エコシステム活用の必要性で選択する。コストを重視するならECSが有利だ。

S	公式ソース確認済み
A	成功実績多数・失敗例少数
B	賛否両論
C	動作未確認・セキュリティリスク高
Z	個人所感