コンテナ化されたアプリケーションを本番運用する上で欠かせないのがコンテナオーケストレーション基盤の選定です。本記事ではECSとEKS、そして起動タイプとしてのFargateを整理します。

SAA レベル：基礎概念

ECSとEKSの基本的な違い

項目	ECS	EKS
オーケストレーション	AWS独自	Kubernetes（業界標準）
学習コスト	比較的低い	Kubernetesの知識が必要
マルチクラウド移植性	低い（AWS専用）	高い（Kubernetes標準API）

SAA 試験のポイント

すでにKubernetesの運用経験・エコシステム（Helm等）を活用したい、または将来的なマルチクラウド戦略がある場合はEKS、AWSに特化しシンプルに始めたい場合はECSが選ばれやすい、という基本的な判断軸がSAAで問われます。

起動タイプ：EC2 vs Fargate

項目	EC2起動タイプ	Fargate
インフラ管理	自分でEC2インスタンスを管理	サーバーレス（インスタンス管理不要）
柔軟性	インスタンスタイプ・OS等を細かく制御可能	制約はあるが運用負荷が低い
コスト特性	インスタンス単位の課金、最適化次第で割安	タスク単位の従量課金

SAP レベル：高度な設計シナリオ

EC2とFargateの選定基準

SAP 試験のポイント

GPU利用や特殊なカーネルパラメータ設定が必要なワークロード、または大量のタスクを高密度に配置してコストを最適化したい場合はEC2起動タイプが適しています。一方、運用負荷を最小化したい、需要変動が激しくインフラのキャパシティプランニングを避けたい場合はFargateが適しています。SAPでは「Fargateであれば常にコスト効率が良い」という単純化は誤りで、恒常的に高い使用率で稼働するワークロードは、適切に最適化されたEC2の方が割安になるケースが多いという論点が問われます。

マルチAZ配置戦略

ECS/EKSともに、タスク（Pod）を複数のAZに分散配置することが高可用性の基本
ECSではタスク配置戦略 (Placement Strategy) でspread（AZ間で均等分散）を指定
EKSではPod Topology Spread Constraintsを使い、AZラベルに基づいてPodを分散させる

設計上の落とし穴

デフォルト設定のままではタスクやPodが特定のAZに偏って配置されるケースがあります。SAPレベルでは、明示的な配置戦略・分散制約を設定しない限り、AZ障害時に想定以上の容量が失われるリスクがあるという点を見落としがちな設計上の落とし穴として認識しておく必要があります。

EKSのマネージドノードグループとKarpenter

マネージドノードグループ: AWSがノードのライフサイクル（起動、更新、終了）を管理する、Auto Scalingグループベースの仕組み
Karpenter（2-1のAuto Scaling記事でも紹介）: Podの要求に応じて動的に最適なインスタンスを選定・起動する、より柔軟なスケーリング方式

観点	マネージドノードグループ	Karpenter
ノードタイプの管理	事前定義したインスタンスタイプに限定	Podの要求に応じて動的に最適なタイプを選択
スケール速度	ASGのスケーリングに準じる	より高速、直接EC2 Fleet APIを利用

サービスメッシュとの統合

マイクロサービス間の通信の可観測性・セキュリティ（mTLS）を強化するため、AWS App Meshやサードパーティのサービスメッシュ（Istio等）と統合する設計もSAPレベルの大規模構成では検討対象になる

まとめ

SAA: ECSとEKSの基本的な違い、EC2起動タイプとFargateのトレードオフを理解する。
SAP: ワークロード特性に応じたEC2/Fargateの選定、マルチAZ配置戦略の明示的な設定、Karpenterによる高度なスケーリング設計ができる。

ここまでで 2-1 高可用性・スケーラブルなアーキテクチャ の全6記事が完了しました。次は 2-2 疎結合・イベント駆動アーキテクチャ に進みます。