導入
「新しいワークロードをどこで動かすか」は、新規設計の最初の分岐点です。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に留まる判断も正解になります。
読んでみよう
SAPでは「コンテナ化すべきか」自体が論点になることがあります。EC2上のECS/EKSとFargateの違い（ノード管理の有無）、ECSとEKSの違い（AWS独自の統合か、Kubernetes標準に寄せるか）を、単なる機能表としてではなく「誰が何を運用したくないか」という制約から選べるようにしておきましょう。