【SAS対策】Amazon ECS(Elastic Container Service) / Amazon EKS(Elastic Kubernetes Service)

Amazon ECS（Elastic Container Service）

概要

• AWSが提供するフルマネージドなコンテナオーケストレーションサービス

• コンテナを簡単にデプロイ・管理・スケーリングできる

• 代表的な起動タイプ

  • EC2起動タイプ：EC2インスタンス上で動かす
  • Fargate起動タイプ：サーバーレスで基盤を意識せず動かす

ECSの主要コンポーネント

1. クラスタ（Cluster）

• ECSの基盤となる入れ物
• タスクやサービスを実行する場所
• EC2インスタンスやFargateリソースをまとめる単位

2. タスク定義（Task Definition）

• タスクの設計図

• 記載する内容：

  • 使用するDockerイメージ
  • CPU・メモリの割り当て
  • 環境変数
  • ポート設定
  • コンテナ数（1つ以上）

3. タスク（Task）

• タスク定義から実際に起動したインスタンス
• 実際にアプリケーションが稼働する単位
• 1つのタスクの中に複数のコンテナを含めることも可能

4. サービス（Service）

• タスクを安定稼働させる仕組み

• 機能：

  • 指定した数のタスクを維持（オートヒーリング）
  • ALB/NLBと連携してロードバランシング
  • ローリング更新やブルー/グリーンデプロイ

• サービスなしで単発タスク実行も可能（バッチ処理など）

5. コンテナ（Container）

• 実体のアプリケーション
• タスク内で動くプロセス
• Dockerイメージから起動
• サイドカー構成（例：アプリ＋ログ収集）も可能

関係性イメージ（テキスト図解）

ECS クラスタ（Cluster）
│   ← コンテナを動かす基盤（EC2/Fargate）
│
├─ サービス（Service）
│    │   ← タスク数を維持・デプロイ管理
│    │
│    ├─ タスク（Task）
│    │    │   ← タスク定義から起動された実体
│    │    │
│    │    ├─ コンテナ（Container）
│    │    │     ← アプリ本体
│    │    └─ コンテナ（Container）
│    │          ← サイドカー（ログ収集など）
│    │
│    └─ タスク（Task）
│         └─ コンテナ（Container）
│
└─ （サービスを使わず単発で動かすタスクも可能）

• クラスタ = 実行基盤（工場）
• タスク定義 = 設計図（どんなアプリをどう動かすか）
• タスク = 設計図から実際に動いたインスタンス（生産ライン）
• サービス = タスクを管理して安定稼働させる仕組み（工場の監督）
• コンテナ = アプリケーションの実体（機械）

ECSのローリングアップデート（Rolling Update）

• ECS サービスに対して新しいタスク定義を適用すると、古いタスクを順次停止し、新しいタスクを起動していく
• これにより「アプリを落とさずにバージョンを切り替えられる」

制御パラメータ

サービス定義時に次の2つを設定できる：

• minimumHealthyPercent

  • デプロイ中に「最低限維持すべき稼働中タスクの割合」
  • 例: 100 → 現行タスクを止める前に必ず新タスクを立ち上げる

• maximumPercent

  • デプロイ中に「最大で何％までタスクを増やして良いか」
  • 例: 200 → 一時的に2倍までスケールアウトして更新

• 例：サービスに10タスクがあるとき

  • min 50%, max 200% に設定すると、更新中は 5〜20タスクの範囲で入れ替え が進む

ECSのスケーリング

ECSのスケーリングには大きく2種類あります。

1. Service Auto Scaling

• タスク数を自動でスケール

• トリガー例：

  • CPU利用率が70%を超えたらタスクを+2
  • SQSのキュー長に応じてタスク数を増減

• EC2起動タイプでもFargate起動タイプでも使える

• アプリケーションレベルのスケール

2. Cluster Auto Scaling（EC2起動タイプの場合）

• クラスタに属するEC2インスタンス自体をスケール
• Service Auto Scalingでタスク数を増やすと、インスタンスが足りなくなる場合あり
• その場合、自動的にEC2インスタンスを追加起動してキャパシティを確保
• インフラレベルのスケール

（Fargate起動タイプではAWSが基盤を管理するので、クラスタスケーリングを意識する必要なし）

Amazon ECS vs Amazon EKS

共通点

• どちらも AWSのコンテナオーケストレーションサービス
• コンテナをデプロイ・スケーリング・管理する基盤
• Fargate を利用すれば両方とも「サーバレスでコンテナ実行」が可能

ECS（Elastic Container Service）

• AWS独自のオーケストレーションサービス
• タスク定義 / サービス / クラスタ というシンプルな概念
• 学習コストが低い（AWS独自用語だけ理解すればOK）
• 他のAWSサービス（ALB, CloudWatch, IAM, App Meshなど）とシームレス統合
• Kubernetesの知識が不要

EKS（Elastic Kubernetes Service）

• マネージドKubernetes（オープンソースK8s互換）
• Kubernetes API がそのまま使える（kubectl / Helm / ArgoCDなど）
• 移植性が高く、オンプレや他クラウドのKubernetesともほぼ同じ運用が可能
• ただし学習コストが高い（Pod, Deployment, Service, Ingress, Namespace... などK8sの概念が必要）
• 運用管理も複雑になりがち

ECS vs EKS 比較表

項目	ECS	EKS
管理モデル	AWS独自（シンプル）	標準Kubernetes
学習コスト	低い（AWS知識中心）	高い（Kubernetes知識必須）
AWS連携	ネイティブ統合が強い	追加設定が必要な場合も
移植性	低い（AWS依存）	高い（他クラウド/オンプレ可）
規模	小〜中規模向き	中〜大規模、マルチクラウド向き
起動タイプ	EC2 / Fargate	EC2 / Fargate

ポイント

• ECS = AWS専用、シンプル、学習コスト低
• EKS = Kubernetes標準、移植性高、複雑
• どちらもFargateでサーバレス実行可能
• マルチクラウドやK8s運用経験がある場合はEKSが適切