AWS Fargate

解決する課題

コンテナを本番で動かすには、従来は EC2 のクラスタを自前で用意し、台数の見積もり・OS のパッチ・スケールを運用し続ける必要がありました。Fargate なら：

• コンテナを動かすための EC2 を一切持たなくてよい（サーバーレス）
• OS やホストの パッチ・キャパシティ計画から解放される
• タスク単位で 必要な分だけ起動・課金でき、運用負荷を最小化できる

Fargate 自体は単独の「コンテナサービス」ではなく、ECS や EKS の データプレーン（実行基盤） である点が重要です。オーケストレーションは ECS / EKS が担い、その下でコンテナを実際に走らせる土台を Fargate が提供します。

主要概念と用語

• データプレーン: コンテナが実際に動く実行基盤。Fargate はこの役割を担う
• コントロールプレーン: タスクの配置・希望数維持・スケールを決める層（ECS / EKS）
• 起動タイプ / キャパシティプロバイダー: タスクを Fargate で動かすか EC2 で動かすかの選択
• タスク: ECS における実行単位。1つ以上のコンテナをまとめたもの
• ポッド: EKS における実行単位。Fargate プロファイルで対象を指定する
• タスク実行ロール: イメージ取得やログ送信のために Fargate 基盤が使う IAM 権限
• タスクロール: コンテナ内のアプリが他の AWS サービスを呼ぶための IAM 権限
• Fargate Pod 実行ロール: EKS が Fargate Pod のイメージ取得などに使う基盤側の権限。Pod 内アプリの権限とは分ける

仕様・制限・クォータ

• CPU とメモリは実行単位で指定する。組み合わせは固定表から選び、ECS の Linux タスクは最大 32 vCPU・244 GB、EKS の Pod は最大 16 vCPU・120 GB まで選べる。EKS は Pod 要求へ Fargate の管理用余白を加えてサイズを決める
• 各タスクは 専用のカーネルを持ち、他テナントと隔離される（マルチテナント環境での分離）
• ネットワークは awsvpc モードで、タスクごとに ENI（Elastic Network Interface）と固有の IP が割り当てられる
• EFS は ECS と EKS で利用できる。EKS Fargate は静的プロビジョニングのみで EBS はマウントできない。ECS Linux Fargate は EFS に加えて、起動時に新規作成する EBS を 1 タスク 1 本まで接続できる
• 一時領域は 20 GB が料金に含まれる。ECS Linux Fargate は 20〜200 GiB を指定でき、20 GB 超過分は別料金になる
• ARM（Graviton）と Windows は ECS のみ。EKS Fargate は Linux/x86、Fargate Spot は ECS の Linux タスクだけで、EKS は Spot に対応しない
• 主要クォータはタスク数ではなく、リージョンごとの On-Demand / Spot の同時 vCPU 数と起動レートで管理される。初期既定値は低い場合があるため、Service Quotas と AWS/Usage を監視する

内部の仕組み

横にスクロール

ECS / EKS が「どのタスクをいくつ動かすか」を決め、Fargate がその要求を受けて マイクロ VM 上にコンテナを起動します。各タスクは独立した仮想化境界で隔離されるため、同じ物理ホストを他の利用者と共有していても互いに干渉しません。これがサーバーレスでありながら強い分離を実現する仕組みです。

• タスク起動時に ENI が動的に作られ、指定したサブネットとセキュリティグループにアタッチされる
• イメージは ECR などから取得され、その際の権限は タスク実行ロールが担う
• 利用者はホストの存在を意識せず、CPU とメモリの希望値を宣言するだけでよい

EC2 起動タイプと異なり、ホストの空き容量を気にしてタスクを詰め込む（ビンパッキング）必要がなく、AWS 側がコンピュートを用意します。一方でホストは選べず、GPU は Fargate で利用できません。GPU や特権処理が必要なら EC2 ベースの実行先を選びます。

設計パターン / ベストプラクティス

• 運用を最小化したい常駐サービスやマイクロサービスは Fargate を第一候補にする
• ステートレスに設計し、状態は外部（RDS / DynamoDB / S3 / ElastiCache）へ逃がして自由にスケールさせる
• ALB とサービスを組み合わせてローリングデプロイと自己修復を効かせる
• ECS の中断を許容できる Linux バッチや非同期処理は Fargate Spot でコストを下げる。EKS Fargate には Spot がない
• ARM 対応アプリなら Graviton ベースを選び、価格性能比を改善する
• 起動の速さやコールドスタートが極端に重要な超短時間処理は、Lambda の方が向く場合がある

運用・監視

• CloudWatch Logs へログを送る（ECS の awslogs ドライバ等）。タスク実行ロールに送信権限が要る
• Container Insights でタスク / サービス単位の CPU・メモリ使用率を可視化
• タスクが起動しない場合は、イメージ取得権限（ECR とタスク実行ロール）、CPU / メモリの組み合わせ、サブネットとセキュリティグループ、NAT 経由の外部到達性を確認する
• 稼働中コンテナの調査は、ECS では ECS Exec、EKS では kubectl exec を使い、ホスト SSH に依存しない
• スケールは ECS のサービス Auto Scaling（ターゲット追跡など）で希望数を自動調整する

コスト

• 課金は要求した vCPU、メモリ、20 GB を超える一時領域、OS、CPU アーキテクチャと実行時間で決まる。イメージ取得開始から終了まで秒単位で計算し、Linux は最低 1 分、Windows は最低 5 分
• ホストを共有して詰め込む運用が不要な反面、割り当てを過大にすると無駄になるため、適正サイズが重要
• ECS の中断許容 Linux ワークロードは Fargate Spot でオンデマンドより最大 70% の割引を受けられる
• 長期定常で稼働量が大きい場合は Compute Savings Plans の対象にでき、コミットによる割引が効く

セキュリティ

• アプリの権限は タスクロールで最小化し、アクセスキーのハードコードを避ける
• イメージは ECR に置き、脆弱性スキャンをかける
• タスクは プライベートサブネット + セキュリティグループに配置し、外向き通信は NAT 経由にする
• DB パスワードや API キーは Secrets Manager / SSM Parameter Store から渡し、コンテナ定義に直書きしない
• タスクごとにカーネルが分離されるため、マルチテナント環境でも他タスクからの干渉を受けにくい

Well-Architected の観点

• 運用上の優秀性: ホストのパッチ・スケール管理が不要で、宣言的なデプロイと自己修復に集中できる
• コスト最適化: 使った vCPU / メモリ分のみ課金、Spot や Savings Plans、適正サイズで最適化
• パフォーマンス効率: タスク単位でリソースを宣言し、Graviton など適切なアーキテクチャを選べる

試験で問われるポイント

関連サービス・比較

同じコンテナの起動先である EC2 起動タイプとよく比較されます。

ハンズオン / CLI例

# ECS サービスを Fargate 起動タイプで作成
# タスク定義 web:1 は登録済みとする
aws ecs create-service \
  --cluster app-cluster \
  --service-name web \
  --task-definition web:1 \
  --desired-count 2 \
  --launch-type FARGATE \
  --network-configuration "awsvpcConfiguration={subnets=[subnet-aaa,subnet-bbb],securityGroups=[sg-xxx],assignPublicIp=DISABLED}"

# 稼働中タスクの一覧を確認
aws ecs list-tasks \
  --cluster app-cluster \
  --service-name web