コンピューティング: EC2、Auto Scaling、Lambda、コンテナ
EC2 のインスタンスタイプと購入オプションの選び方、自動スケーリング、Lambda によるサーバーレス、ECS / EKS / Fargate 上のコンテナ。
- 分野弾力性のあるアーキテクチャ
- 分野高性能なアーキテクチャ
- 分野コスト最適化
- 図 15
- 出題パターン 10
- サービス 11
5 分で押さえる要点
- EC2 は OS を自分で管理する仮想マシンです。Lambda はイベントで関数を実行し、1 回あたり最大 15 分です。Fargate はサーバーを管理せずにコンテナを実行します。「運用負荷を最小に」という制約が出たら Lambda / Fargate を優先します。長時間実行、GPU、独自の OS が必要なら EC2 です。
- インスタンスファミリー: C = コンピューティング、R / X = メモリ、I / D = 高速なローカルディスク、P / G = GPU、T = バースト可能、M = バランス型。試験では世代の正確な名前は問われませんが、ワークロードの特徴からファミリーを選ばせる問題はよく出ます (インメモリキャッシュ → R、HPC → C、ML トレーニング → P)。
- EC2 の購入オプション: On-Demand (コミットなし)、Savings Plans / Reserved (1 年または 3 年のコミット)、Spot (最安だが中断される可能性あり)、Dedicated Host (ソケット / コア単位のライセンスが必要な場合)。24 時間 365 日安定して動くワークロード → Savings Plans または Reserved。中断に耐えられるワークロード (バッチ、CI) → Spot。物理サーバー単位の BYOL ライセンス → Dedicated Host。
- Spot は中断の 2 分前に警告を受け取ります (EventBridge とインスタンスメタデータ経由)。アプリケーションは中断に耐える必要があります。状態を外部 (S3、DynamoDB、SQS) に保存し、処理をチェックポイントします。
- Compute Savings Plans は EC2、Fargate、Lambda に適用され、ファミリー / Region / OS を自由に変更できます。EC2 Instance Savings Plans はより安いものの、1 つの Region 内でインスタンスファミリーが固定されます。「最も柔軟でありながら割引を受けたい」と問われたら → Compute Savings Plans。
- Auto Scaling group はインスタンス数を min と max の間に保ち、異常なインスタンスを置き換え、AZ 間に均等に配置します。デフォルトで使うべきポリシーは target tracking です。1 つのメトリクス (CPU 50%、ターゲットあたりのリクエスト数) を追跡してインスタンスを自動で増減します。scheduled scaling は時間帯が分かっている負荷向け、predictive scaling は周期的な負荷向けです。
- ALB: レイヤー 7 (HTTP/HTTPS)、パス / ホスト / ヘッダーでルーティング、ターゲットは EC2、IP、Lambda、コンテナ。NLB: レイヤー 4 (TCP/UDP/TLS)、非常に低いレイテンシー、AZ ごとに静的 IP。GWLB: サードパーティのセキュリティアプライアンスを挿入。固定 IP または UDP が必要 → NLB。/api、/images でルーティング → ALB。
- Placement group: cluster (同一 AZ、最速のネットワーク)、partition (AZ あたり最大 7 パーティション、Hadoop / Cassandra 向けにラックを分離)、spread (AZ あたり最大 7 インスタンス、1 台ずつ別ラック)。低レイテンシーの HPC → cluster。同時に故障してはならない少数の重要なインスタンス → spread。
- Lambda: メモリ 128 MB–10 GB (CPU はメモリに比例)、/tmp は最大 10 GB、同時実行数はデフォルトで Region あたり 1,000 (引き上げ申請可能)。速くしたい → メモリを増やす。応答時間を安定させたい関数のコールドスタート → provisioned concurrency。
- Lambda の同期呼び出し (API Gateway、ALB) はエラーを呼び出し元に返します。非同期呼び出し (S3、SNS、EventBridge) は自動で 2 回再試行し、その後 DLQ / destination に送ります。SQS、Kinesis、DynamoDB Streams からの読み取りは event source mapping です。Lambda がバッチ単位で自らポーリングします。
- ECS と EKS はコンテナオーケストレーター、Fargate または EC2 はコンテナの実行場所、ECR はイメージのリポジトリです。既に Kubernetes を使っていてそのまま AWS に移行したい → EKS。最もシンプルにしたい → ECS on Fargate。
- Elastic Beanstalk と App Runner はコード / イメージからインフラを自動構築します。AWS Batch はバッチジョブをキューに入れ、EC2 / Spot / Fargate 上で実行します。「開発チームがインフラに詳しくなく、Web を素早く公開したい」→ Beanstalk / App Runner。「数千件のバッチ処理ジョブ」→ Batch。
- EC2 Hibernate は RAM の内容を EBS ルートボリューム (暗号化済み) に保存して高速に再開します。user data は起動時にスクリプトを実行します。AMI は同一構成のインスタンスを作るためのテンプレートです。大きなメモリを読み込むため起動が遅いアプリケーション → hibernate または事前構築済み AMI (ゴールデン AMI)。
構成図
EC2 のライフサイクル: stop、hibernate、terminate
ステップ
- Launch: pending の後 running になります。running になった時点から秒単位 (最低 1 分) で課金されます。
- Reboot: 同じホストのままで、IP とインスタンスストアのデータを保持し、新たな課金期間は始まりません。
- Stop (EBS ベースのインスタンスのみ): インスタンスの課金が止まります。hibernate の場合は RAM をルートボリュームに保存し、stopping の間は課金されます。
- 再 start: 通常は新しいホストに移り、インスタンスストアのデータが失われ、Elastic IP を使っていなければパブリック IPv4 が変わります。
- Terminate: shutting-down になった時点で課金が止まります。ルートボリュームはデフォルトで削除されます (DeleteOnTermination)。
ALB の背後の Auto Scaling group、CPU に応じてスケール
ステップ
- ALB は Auto Scaling group 内の正常なインスタンスにリクエストを分散します (ALB のヘルスチェック)。
- 平均 CPU が 50% を超えると、target tracking が自動作成した CloudWatch アラームが発動します。
- ASG がインスタンスを追加し (インスタンスの少ない AZ に)、ヘルスチェックに合格すると ALB がリクエストの送信を開始します。
On-Demand と Spot を組み合わせた Auto Scaling group
ステップ
- ベースの On-Demand が最低限のサービスを維持し、Spot はインスタンスファミリーを分散させて同時に中断されるリスクを下げます。
- AWS が容量を必要とすると、EventBridge が 2 分前に "EC2 Spot Instance Interruption Warning" を受け取ります。
- 処理途中のジョブはキューに戻され、ASG が代替インスタンスを自動で要求します。
3 種類の placement group
ALB はパスでルーティング、NLB は静的 IP で TCP/UDP
ステップ
- ALB: パスに基づくリスナールール。ターゲットはコンテナ、EC2、IP、Lambda のいずれでも可能です。
- NLB: レイヤー 4、UDP 対応、静的 IP (Elastic IP を割り当て) で顧客がホワイトリスト登録できます。
イベント駆動で動く Lambda
ステップ
- 非同期呼び出し: S3 がイベントを送り、Lambda が実行され、失敗すると自動で 2 回再試行します。
- Event source mapping: Lambda が SQS を自らポーリングし、メッセージをバッチで受け取り、処理が終わるとメッセージを削除します。
- maxReceiveCount 回を超えて処理に失敗したメッセージは、確認のため DLQ に移されます。
Lambda の同期呼び出しと非同期呼び出し
ALB の背後の ECS on Fargate
ステップ
- ECS service は希望するタスク数を維持します。Fargate は ECR からイメージを取得してタスクを実行し、管理するサーバーはありません。
- ALB は各タスクの IP に直接リクエストを送ります (awsvpc ネットワークモード)。
- タスクは IAM task role で S3 にアクセスし、アクセスキーは不要です。
Amazon EKS: コントロールプレーンは AWS が管理
ステップ
- コントロールプレーン (AWS が管理、複数 AZ) が Pod を node group の EC2 ノードまたは Fargate にスケジュールします。
- Ingress は AWS Load Balancer Controller によって Pod を指す ALB に変換されます。
Spot でバッチジョブを実行する AWS Batch
ステップ
- EventBridge がスケジュールに従って Batch のキューにジョブを送信します。
- Batch はキューに足りる Spot インスタンスを用意してコンテナを実行し、結果を S3 に書き込みます。処理がなくなると 0 に縮小します。
Lambda: コールドスタート、ウォームスタートとコールドスタートの削減方法
ヘルスチェックと cross-zone load balancing
ステップ
- リクエストは ALB に届きます。ALB で有効にした各 AZ にロードバランサーのノードが 1 つあります。
- ヘルスチェックに連続して失敗したターゲットは unhealthy になり、ALB はそのターゲットへのリクエスト送信を停止します。
- cross-zone が有効: AZ ごとのインスタンス数に関係なく、すべての AZ の正常なターゲットにリクエストが均等に分散されます。
IMDSv2: 先にトークンを取得してからメタデータを読む
Auto Scaling group の Lifecycle hook
ステップ
- Scale out: hook がインスタンスを Pending:Wait に保ち、インストールスクリプトを実行します。complete-lifecycle-action を呼ぶか、待機時間 (デフォルト 1 時間) が切れるのを待ちます。
- インスタンスは InService になり、ロードバランサーからリクエストを受け始めます。
- Scale in: インスタンスはロードバランサーから外され、hook が Terminating:Wait に保ってログ取得やデータのバックアップを行います。
- 処理が終わる (または時間切れになる) とインスタンスは terminate されます。
コンピューティングサービスの選択
ステップ
- 15 分を超える処理や常時稼働の処理: Lambda には向きません。
- 既にコンテナがあり、ネットワークのカスタマイズ、サイドカー、複数のサービスが必要: Fargate 上の ECS または EKS で、サーバー管理は不要です。
- OS、GPU、レガシーソフトウェアの制御が必要: Auto Scaling group 内の EC2。
比較表
EC2、Lambda、Fargate
| EC2 | Lambda | Fargate (ECS / EKS) | |
|---|---|---|---|
| 自分で管理するもの | OS、パッチ適用、スケーリング | コードのみ | コンテナイメージ、タスクの CPU / メモリ |
| 実行時間 | 無制限 | 1 回あたり最大 15 分 | 無制限 |
| 課金 | 稼働中に秒単位 | 呼び出し回数と実行時間 × メモリ | タスクの vCPU とメモリ |
| 適した用途 | レガシーアプリ、GPU、独自 OS、24 時間 365 日稼働 | イベント処理、小規模 API、短時間のタスク | マイクロサービス、サーバー管理不要の長時間稼働コンテナ |
EC2 の購入オプション
| オプション | コミット | 最大割引率 | 使う場面 |
|---|---|---|---|
| On-Demand | なし | — | 短期、予測困難、検証用 |
| Compute Savings Plans | 1 年または 3 年、USD/時間で | 最大 66% | 安定した負荷、ファミリー / Region の変更や Fargate、Lambda への移行も想定 |
| EC2 Instance Savings Plans / Reserved Instances | 1 年または 3 年、インスタンスファミリー単位 | 最大 72% | 安定した負荷、インスタンスファミリーと Region が確定 |
| Spot | なし、中断される可能性あり (2 分前に通知) | 最大 90% | バッチ、CI、画像処理、中断可能な分析 |
| Dedicated Host | 時間単位または予約 | — | ソケット / コア単位のライセンス、専有物理サーバーのコンプライアンス要件 |
ALB、NLB、GWLB
| ALB | NLB | GWLB | |
|---|---|---|---|
| レイヤー | 7 (HTTP/HTTPS、gRPC、WebSocket) | 4 (TCP、UDP、TLS) | 3 (IP パケット、GENEVE プロトコル) |
| ルーティング | パス、ホスト、ヘッダー、クエリ | ポート単位 | 仮想アプライアンス経由 (ファイアウォール、IDS) |
| IP | 変動する、DNS 名を使用 | AZ ごとに静的 IP、Elastic IP を割り当て可能 | — |
| ターゲット | EC2、IP、Lambda、コンテナ | EC2、IP、ALB | セキュリティアプライアンス |
| 出題例 | マイクロサービス /api、/web | UDP のゲーム、IP のホワイトリスト登録が必要、数百万の接続 | すべてのトラフィックにサードパーティのファイアウォールを挿入 |
Placement group
| Cluster | Partition | Spread | |
|---|---|---|---|
| 範囲 | 単一 AZ | 複数 AZ、AZ あたり最大 7 パーティション | 複数 AZ、AZ あたり最大 7 インスタンス |
| 目的 | インスタンス間の低レイテンシー、高帯域幅 | ラックのグループ単位でハードウェア障害を分離 | 1 台ずつ別々のラック |
| 適した用途 | HPC、並列計算 | HDFS、HBase、Cassandra、Kafka | 少数の重要なインスタンス (primary / standby) |
ECS、EKS とコンテナの実行場所
| ECS | EKS | |
|---|---|---|
| オーケストレーション | AWS 独自、シンプル | 標準の Kubernetes (コントロールプレーンは AWS が管理) |
| 実行場所 | Fargate または EC2 | Fargate、managed node group、self-managed node |
| 選ぶ場面 | シンプルさと AWS との深い統合を重視 | 既に Kubernetes を使用、複数環境間の移植性 / K8s ツールが必要 |
| AWS へのアクセス権限 | タスクごとの task role (IAM) | service account 用の IAM role / Pod Identity |
よく出る出題パターン
1ALB の背後の EC2 で動く Web サービス。トラフィックは業務時間に急増し夜間に減少します。自動でスケールし、CPU を約 50% に保つ必要があります。
答えを見る
正解: 2 つ以上の AZ にまたがる Auto Scaling group を ALB のターゲットグループに関連付け、target tracking で平均 CPU を 50% に維持
target tracking は CloudWatch アラームを自動作成し、目標値に追従するようインスタンスを増減します。ASG は異常なインスタンスを置き換え、AZ 間に均等に配置します。
不正解: cooldown 300 秒の simple scaling policy
動作はしますが反応が遅く不安定です。AWS は target tracking を推奨しています。
不正解: インスタンスサイズを大幅に上げる
スケールアップは閑散時もコストがかかり、単一障害点のままです。
2毎晩 200 万枚の画像を処理します。中断されても処理はやり直せます。コストを最小にする必要があります。
答えを見る
正解: Spot Instances と複数のインスタンスファミリーを使う AWS Batch (または Auto Scaling group)。処理はキューから読み取り、中断時にやり直す
Spot は最大 90% 安くなります。インスタンスファミリーを分散させると同時に中断されるリスクが下がり、キューが未完了の処理を保持します。
不正解: 3 年の Reserved Instances
夜間の数時間しか動かないのに 1 日分の料金を払うことになります。
不正解: On-Demand
中断に耐えられる負荷では Spot よりかなり高額です。
3EC2 上で 24 時間 365 日安定して動く負荷ですが、会社は今後 3 年で段階的に Fargate と Lambda へ移行する予定です。
答えを見る
正解: Compute Savings Plans
USD/時間でコミットし、すべての Region の EC2、Fargate、Lambda に自動適用されます。
不正解: EC2 Instance Savings Plans
1 つの Region 内でインスタンスファミリーが固定され、Fargate / Lambda には適用されません。
不正解: Spot
重要な 24 時間 365 日の負荷は中断を許容すべきではありません。
4HPC クラスターで、ノード間のネットワークレイテンシーを可能な限り低くする必要があります。
答えを見る
正解: 1 つの AZ 内の Cluster placement group と、enhanced networking 対応のインスタンス
インスタンスが同じ高帯域幅のネットワークセグメントに配置されます。
不正解: Spread placement group
インスタンスを別々のラックに配置します。耐障害性は上がりますが、レイテンシーは下がりません。
不正解: インスタンスを 3 つの AZ に分散
AZ 間のレイテンシーは AZ 内より高くなります。
5UDP を使うゲームアプリケーションです。企業顧客がファイアウォールを開けるため、ロードバランサーの固定 IP を要求しています。
答えを見る
正解: 各 AZ に Elastic IP を割り当てた Network Load Balancer
NLB はレイヤー 4 で動作し、UDP に対応し、AZ ごとに静的 IP を持ちます。
不正解: Application Load Balancer
ALB は UDP に対応せず、IP も変動します。
6ユーザーが S3 にアップロードすると Lambda 関数が画像を処理します。ときどき失敗してイベントが失われます。
答えを見る
正解: 非同期呼び出しに SQS / SNS を宛先とする on-failure destination (または DLQ) を設定し、監視して再処理する
非同期呼び出しは 2 回再試行され、その後イベントは失われずに destination に送られます。
不正解: timeout を 15 分に延ばす
実際に失敗したイベントの問題は解決しません。
7Lambda 上の API で、月曜の朝にコールドスタートのためレイテンシーが不安定になります。
答えを見る
正解: provisioned concurrency (ピーク時間帯に合わせてスケジュール設定も可能)
初期化済みの実行環境を一定数待機させるので、呼び出しがコールドスタートの影響を受けません。
不正解: reserved concurrency を増やす
reserved concurrency は枠の確保 / 上限設定のみで、実行環境をウォームアップしません。
8コンテナ化されたマイクロサービスアプリケーションがあり、サーバーやクラスターを管理したくなく、運用負荷を最小にしたい企業です。
答えを見る
正解: ECS on Fargate、イメージは ECR、前段に ALB
管理するサーバーがありません。タスクごとに専用の ENI と IAM role を持ちます。
不正解: self-managed node group を使う EKS
ノードのパッチ適用、スケーリング、管理が依然として必要です。
不正解: 自分でインストールした EC2 上で Docker を実行
運用負荷が最も大きくなります。
9オンプレミスに Kubernetes のマニフェストとツールが多数あり、デプロイ方法を変えずに AWS へ移行したいです。
答えを見る
正解: Amazon EKS (managed node group または Fargate)
標準の Kubernetes API で、コントロールプレーンは AWS が管理します。
不正解: ECS
task definition を書き直し、Kubernetes のツールを捨てる必要があります。
101 回の動画処理タスクに 40 分かかります。
答えを見る
正解: ECS / Fargate のタスクまたは AWS Batch (EventBridge / Step Functions 経由のイベントで起動)
コンテナは実行時間に制限がなく、サーバー管理も不要です。
不正解: Lambda
1 回の実行は 15 分が上限です。
早見表
コードをどこで実行するか?
| やりたいこと | 使うもの |
|---|---|
| 短時間 (15 分未満) のイベント処理、不規則なトラフィック | Lambda · 図を見る |
| コンテナ、サーバー管理は不要 | ECS on Fargate · 図を見る |
| 既に Kubernetes を使用 | EKS · 図を見る |
| OS の完全な制御、GPU、レガシーソフトウェアが必要 | EC2 + Auto Scaling group · 図を見る |
| 大量のバッチジョブ、中断可能 | AWS Batch on Spot · 図を見る |
| Web アプリ、開発者がインフラに不慣れ | Elastic Beanstalk または App Runner · 図を見る |
| HTTP、パス / ホストでルーティング | Application Load Balancer · 図を見る |
| TCP / UDP、静的 IP、超低レイテンシー | Network Load Balancer · 図を見る |
| 長年安定した負荷、Fargate / Lambda への移行の可能性あり | Compute Savings Plans |
| 中断可能な負荷、最安が必要 | Spot (インスタンスファミリーを分散) · 図を見る |
| インスタンス間のネットワークレイテンシーを最小にしたい | Cluster placement group · 図を見る |
落とし穴
- 15 分を超える処理に Lambda を使う。
- 1 日数時間しか動かない負荷に Reserved / Savings Plans を選ぶ: Spot または On-Demand + スケーリングの方が安い。
- 中断を許容できない重要な負荷 (プライマリデータベース、RAM に保持するユーザーセッション) に Spot を使う。
- reserved concurrency (上限 / 枠の確保) と provisioned concurrency (ウォームアップ、コールドスタート対策) を混同する。
- UDP や静的 IP が求められる場面で ALB を使う: 正解は NLB。
- Auto Scaling group が 1 つの AZ のみ: その AZ が障害になるとすべて失われる。
- 低レイテンシーが必要な HPC に spread placement group を使う (正しくは cluster)、または spread で AZ あたり 7 台を超えて配置する。
- ASG 内の EC2 のディスク / RAM にユーザーセッションを保存する: インスタンスが置き換えられると失われる。セッションは ElastiCache / DynamoDB に外出しする。
- Fargate をオーケストレーターだと考える: Fargate は実行場所で、オーケストレーターは ECS / EKS。
- task role / Pod 用の IAM role ではなく、環境変数のアクセスキーでコンテナに AWS 権限を与える。
- EC2 Instance Savings Plans が Lambda / Fargate に適用されると考える: 適用されるのは Compute Savings Plans のみ。
このモジュールのサービス
変わりやすい数値 (AWS ドキュメントで確認済み)
- Lambda の 1 回の実行は最大 15 分 (900 秒)、メモリは 128 MB–10,240 MB、/tmp は 512 MB–10,240 MB。 2026-10-16 確認 ↗
- Lambda の同時実行数はデフォルトで Region あたり 1,000 (数万まで引き上げ申請可能)。 2026-10-16 確認 ↗
- Lambda: ペイロードは同期呼び出しで 6 MB、非同期呼び出しで 1 MB。zip パッケージは 50 MB (圧縮) / 250 MB (展開後)、コンテナイメージは最大 10 GB。 2026-10-16 確認 ↗
- Spot Instance は停止 / 終了の 2 分前に警告を受け取る (EventBridge とインスタンスメタデータ)。 2026-10-16 確認 ↗
- Spot は On-Demand と比べて最大 90% 割引。 2026-10-16 確認 ↗
- Compute Savings Plans は最大 66% 割引で EC2、Fargate、Lambda に適用。EC2 Instance Savings Plans は最大 72% 割引。期間は 1 年または 3 年。 2026-10-16 確認 ↗
- Partition placement group は AZ あたり最大 7 パーティション。spread placement group は AZ あたり実行中インスタンス最大 7 台。cluster placement group は 1 つの AZ 内。 2026-10-16 確認 ↗
- Fargate Spot: タスクは 2 分前の警告とともに中断される。 2026-10-16 確認 ↗
- Auto Scaling のデフォルトの cooldown は 300 秒で、simple scaling policy にのみ適用される。AWS は target tracking を推奨。 2026-10-16 確認 ↗
- Lambda SnapStart は Java 11+、Python 3.12+、.NET 8+ に対応。provisioned concurrency とは併用できない。 2026-10-19 確認 ↗
- ALB はロードバランサーレベルで cross-zone load balancing が常に有効。NLB と GWLB はデフォルトで無効。 2026-10-19 確認 ↗
- IMDSv2: トークンは PUT で取得し、TTL は最大 21,600 秒。PUT レスポンスの hop limit はデフォルトで 1。 2026-10-19 確認 ↗
- Auto Scaling group の Lifecycle hook: インスタンスは Pending:Wait / Terminating:Wait で待機し、デフォルトで最大 1 時間 (heartbeat で延長可能)。 2026-10-19 確認 ↗