導入
「新しいワークロードをどこで動かすか」は、新規設計の最初の分岐点です。SAAでは「EC2で十分」と即答できた場面でも、SAPでは「運用チームの人数」「デプロイ頻度」「トラフィックの波」まで加味して選び直す必要があります。
説明
コンピューティングの選択肢は、制御の自由度と運用負荷のトレードオフで一直線に並びます。
flowchart LR
A["EC2<br/>OS・ミドルウェアまで自分で管理"] --> B["ECS/EKS on EC2<br/>コンテナオーケストレーションを自分で運用"]
B --> C["ECS/EKS on Fargate<br/>サーバーレスコンテナ"]
C --> D["Lambda<br/>関数単位・完全サーバーレス"]
左に行くほど自由度が高く運用負荷も高い、右に行くほど運用が楽になる代わりに制約が増える、という一本の軸で覚えると迷いません。
| 選択肢 | 向いている状況 | SAPでの判断ポイント |
|---|---|---|
| EC2 | 特殊なOS/カーネル設定、既存資産の踏襲（リホスト） | 「移行元と同じOS」「カスタムドライバが必要」で残る |
| ECS（Fargate） | コンテナ化済みで運用は楽をしたい | 「コンテナは使うがサーバー管理はしたくない」で第一候補 |
| EKS | 既にKubernetesの運用ノウハウ・マニフェスト資産がある | 「Kubernetesで統一したい」「マルチクラウド前提」で選ぶ |
| Fargate（ECS/EKS共通） | サーバーのパッチ・容量管理を丸ごと手放したい | 「運用のオーバーヘッドを最小に」に最も強く反応する |
| Lambda | イベント単位の短時間処理、トラフィックの波が大きい | 「使った分だけ」「スパイクに自動対応」に強く反応する |
SAPの問題文では、「運用チームが小さい」「頻繁にデプロイする」「トラフィックが予測不能」といった記述があれば、右側（Fargate/Lambda）に寄せるのが定石です。逆に「既存のカーネルモジュールに依存」「ライセンスの都合でOSを固定」といった制約があれば、あえてEC2に留まる判断も正解になります。
具体例
同じ「Webアプリを動かす」でも、組織の制約が違えば軸の左右どちらに寄せるかが変わります。
- 運用チーム3人、トラフィックは予測不能（新規SaaS） … サーバーのパッチや容量管理に手が回らない。→ 軸の右へ。コンテナ化済みならFargate、イベント単位ならLambda。運用のオーバーヘッドを最小化し、スパイクにも自動追従。
- 既存のカーネルモジュールに依存する基幹システム … OSレベルの特殊設定が必須で、マネージド環境では動かない。→ あえて軸の左、EC2に留まるのが正解。「新しいから右が正義」ではない。
- すでにKubernetesのマニフェスト資産と運用ノウハウがある大企業 … その資産を活かしマルチクラウドも見据える。→ EKS。
判断は「誰が・何を運用したくないか」という制約から。運用チームが小さい・頻繁にデプロイ・波が大きいなら右（Fargate/Lambda）、特殊OS依存・ライセンス固定なら左（EC2）、と要件から逆算します。
読んでみよう
SAPでは「コンテナ化すべきか」自体が論点になることがあります。EC2上のECS/EKSとFargateの違い（ノード管理の有無）、ECSとEKSの違い（AWS独自の統合か、Kubernetes標準に寄せるか）を、単なる機能表としてではなく「誰が何を運用したくないか」という制約から選べるようにしておきましょう。