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 権限

仕様・制限・クォータ

• CPU とメモリはタスク単位で指定する。利用できる組み合わせには決まったパターンがあり、メモリは選んだ vCPU に応じた範囲から選ぶ
• 各タスクは 専用のカーネルを持ち、他テナントと隔離される（マルチテナント環境での分離）
• ネットワークは awsvpc モードで、タスクごとに ENI（Elastic Network Interface）と固有の IP が割り当てられる
• 永続ストレージが必要な場合は EFS をマウントできる。タスク内には一時的なエフェメラルストレージも付与される
• アーキテクチャは x86 のほか ARM（Graviton） も選択でき、Windows コンテナにも対応する
• 同時実行タスク数などにはアカウント / リージョン単位のクォータがあり、引き上げ申請が可能

内部の仕組み

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

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

EC2 起動タイプと異なり、ホストの空き容量を気にしてタスクを詰め込む（ビンパッキング）必要がなく、AWS 側がコンピュートを用意します。一方で、ホストへの細かい制御や GPU を含む特殊なインスタンス選択は EC2 起動タイプの方が柔軟です。

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

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

運用・監視

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

コスト

• 課金は タスクに割り当てた vCPU とメモリの量 × 実行時間で決まる。EC2 のようにアイドルなホスト全体ではなく、宣言したリソース分を秒単位で支払う
• ホストを共有して詰め込む運用が不要な反面、割り当てを過大にすると無駄になるため、適正サイズが重要
• 中断許容ワークロードは Fargate Spot で割引を受けられる
• 長期定常で稼働量が大きい場合は 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