コンピュートの全体像
AWS のコンピュートサービスは大きく3層に分かれる。
判断フロー
💡 ECS vs EKS の選び方
ECS（Elastic Container Service）は AWS 独自のオーケストレーターで、Kubernetes の知識なしに使える。EKS（Elastic Kubernetes Service）は Kubernetes をマネージドで使いたい場合、または他のクラウドと同じ Kubernetes エコシステムを使いたい場合に選ぶ。オンプレからの移行で Kubernetes の運用経験がなければ、まず ECS で十分なことが多い。
EC2 を選ぶとき
以下のいずれかに該当する場合は EC2 が適切だ。
- OS レベルの設定が必要：カーネルパラメータ調整、カスタムドライバ、独自の起動スクリプトなど
- レガシーアプリ：コンテナ化が困難なモノリシックアプリ、Windows 専用アプリ
- 特定のライセンス条件：BYOL（ライセンス持ち込み）が必要な Oracle や SQL Server
- 移行速度優先：Rehost 戦略でとにかく早く AWS へ移す
EC2 を選んだ後の考慮点：
- インスタンスタイプの選定：CPU/メモリ比でファミリーを決める（汎用 m 系、CPU 最適化 c 系、メモリ最適化 r 系）
- 購入オプション：常時稼働なら Reserved Instance（1〜3年）、短期・開発環境はオンデマンド、バッチは Spot Instance
- Auto Scaling：負荷変動があるなら Auto Scaling Group で台数を自動調整
⚠️ EC2 の落とし穴：オンプレのスペックをそのまま持ち込まない
オンプレでは「ピーク＋余裕」でサーバースペックを決めるが、AWS では Auto Scaling で台数増減できる。ピーク対応のために常時大きいインスタンスを立てると、オフピーク時のコストが無駄になる。移行後は AWS Compute Optimizer で推奨インスタンスタイプを確認しよう。
ECS / Fargate / EKS を選ぶとき
アプリをコンテナ化できる場合は、ECS (Fargate) が「運用コスト・スケーラビリティ・デプロイ速度」のバランスで最もコスパが良い選択肢になることが多い。
ECS on Fargate の特徴：
- サーバー（EC2 ノード）の管理が不要。AWS がインフラを管理
- コンテナ単位でリソース（CPU/メモリ）を指定し、使った分だけ課金
- Auto Scaling が容易（ECS Service Auto Scaling）
- デプロイは新コンテナ起動→旧コンテナ終了のローリング更新が標準
ECS on EC2 を選ぶケース：
- GPU インスタンスが必要（ML 推論など）
- 特定のカーネル設定や大量のコンテナを同一ノードで動かしてコスト最適化したい
- Spot Instance を使ってコストを下げたい
💡 コンテナ化の進め方
既存アプリをコンテナ化する場合、一気にすべてを変えようとせず、まず「アプリを Docker イメージにする」「ECR にプッシュして ECS で動かす」という最小ステップで始めるのが現実的だ。CI/CD（CodePipeline）との統合は動作確認後に追加できる。
Lambda を選ぶとき
Lambda は以下のユースケースで真価を発揮する。
- イベント駆動処理：S3 へのファイルアップロードをトリガーに処理を実行
- API バックエンド：API Gateway + Lambda でサーバーレス API
- 定期バッチ：EventBridge Scheduler で定期実行（Cron の代替）
- データ変換・ETL：DynamoDB Streams や Kinesis からのデータ処理
Lambda の制約を知っておく：
- 実行時間は最大 15分（それ以上かかる処理は向かない）
- コールドスタートがある（初回実行時に起動時間がかかる。Provisioned Concurrency で緩和可能）
- デプロイパッケージのサイズ制限（ZIP: 50MB、解凍後: 250MB）
- ステートレスが基本（状態の保持が必要なら DynamoDB や ElastiCache と組み合わせる）
⚠️ Lambda でやりがちな設計ミス
長時間バッチを Lambda に載せて15分制限に引っかかるケースが多い。30分以上かかる処理は ECS タスク（Fargate） か Step Functions との組み合わせを検討しよう。
比較表：ざっくり整理
| 観点 | EC2 | ECS / Fargate | Lambda |
|---|---|---|---|
| 移行コスト | 低い（最速） | 中（コンテナ化が必要） | 高（コードの書き換えが必要） |
| サーバー管理 | 自分で管理 | Fargate なら不要 | 完全不要 |
| スケーラビリティ | Auto Scaling で対応 | コンテナ単位でスケール | 自動スケール（リクエスト単位） |
| コスト構造 | 稼働時間課金 | vCPU/メモリ使用量課金 | リクエスト数＋実行時間課金 |
| 起動速度 | 分単位 | 秒〜数十秒 | ミリ秒（コールドスタートあり） |
| 向いているアプリ | レガシー・OS依存 | Web API・常時起動サービス | イベント駆動・短時間処理 |
実務での判断ポイント
コンピュート選定で迷ったときの実務的な判断軸をまとめる。
- 「常時起動が必要か」：Yes なら EC2 か ECS。No（イベント駆動）なら Lambda
- 「OS を触るか」：Yes なら EC2 一択
- 「コンテナ化の工数を払えるか」：No なら Rehost（EC2）からスタートして後でコンテナ移行
- 「スケールの予測が難しい」：Fargate か Lambda が自動スケールで安心
✅ 次の章では…
PART 03 では データベースの選び方を解説する。RDS / Aurora / DynamoDB / ElastiCache など、データの性質と用途から適切な DB サービスを選ぶ判断フローを整理する。