AWS認定 クラウドプラクティショナー（CLF-C02）で最大配点のドメイン3（34%）。その中心が「コンピューティング＝処理を動かす場所」です。AWSには大きく仮想サーバー（EC2）・コンテナ（ECS/EKS）・サーバーレス（Lambda/Fargate）の3系統があり、試験では「この要件ならどれ？」という使い分けが繰り返し問われます。この記事で3つの違いと、弾力性を支えるAuto Scaling・ロードバランサーまで一気に押さえましょう。全体像は CLF対策トップ へ。
① Amazon EC2：クラウド上の仮想サーバー
EC2（Elastic Compute Cloud）は、必要なときに必要なだけ起動できる仮想サーバー。OSを選び、好きなソフトを入れて自由に使えます（その代わりOSのパッチなど管理も自分の責任→責任共有モデル）。用途に合わせてインスタンスタイプを選ぶのがポイントです。
| タイプ | 得意なこと | 例 |
|---|---|---|
| 汎用 | バランス型・迷ったらここ | Webサーバー、小〜中規模アプリ |
| コンピュート最適化 | CPUパワー重視 | バッチ処理、動画エンコード、HPC |
| メモリ最適化 | 大容量メモリ重視 | インメモリDB、大規模データ処理 |
| ストレージ最適化 | 高速・大量のディスクI/O | データウェアハウス、大規模DB |
関連サービス：もっと手軽に固定価格でサーバーを立てたいなら Amazon Lightsail、コードを上げるだけでEC2環境を自動構築する AWS Elastic Beanstalk も選択肢です。
② コンテナ：ECS / EKS でアプリを箱に詰めて動かす
コンテナは、アプリと必要な部品を「箱（コンテナ）」にまとめ、どこでも同じように動かす技術です。AWSでコンテナを動かす管理サービス（オーケストレーター）が2つあります。
- Amazon ECS：AWS独自のコンテナ管理。シンプルで学習コストが低い
- Amazon EKS：マネージドなKubernetes。Kubernetes標準を使いたい・他環境と揃えたい場合に
- Amazon ECR：コンテナイメージの保管庫（レジストリ）
「Kubernetesを使いたい＝EKS」「AWS流のシンプルなコンテナ管理＝ECS」。この対比だけ押さえればOKです。なお、これらの“動かす土台”はEC2にするかFargateにするかを選べます（次項）。
③ サーバーレス：Lambda / Fargate でサーバー管理ゼロ
サーバーレスは、サーバーの存在を意識せず、使った分だけ課金で処理を動かせる方式。OSのパッチもキャパシティ管理も不要で、運用がぐっと軽くなります。
- AWS Lambda：イベント（ファイル到着・APIリクエスト等）に応じて短いコードを実行。サーバーを常時立てずに済み、実行時間ぶんだけ課金
- AWS Fargate：コンテナをサーバーレスで動かすエンジン。ECS/EKSの土台としてEC2の代わりに選べ、インスタンス管理が不要になる
使い分けの軸：「イベント駆動の小さな処理」＝Lambda、「コンテナをサーバー管理なしで動かす」＝Fargate。
弾力性を支える：Auto Scaling とロードバランサー
クラウドの強みである弾力性（elasticity）＝必要に応じて自動で増減する仕組みを、2つのサービスが支えます。混同しやすいので役割を分けて覚えましょう。
| サービス | 役割 | ひとことで |
|---|---|---|
| Auto Scaling | 負荷に応じてインスタンス数を自動で増減 | 台数を変える（弾力性） |
| Elastic Load Balancing（ELB） | 複数のサーバーへトラフィックを振り分け | 負荷を分散する（可用性） |
セットで効きます：ELBで複数台に均等に流し、Auto Scalingで台数を需要に合わせる。これで「アクセス急増にも自動で耐え、暇な時間はコストを抑える」が実現します。
3系統まるごと比較
| EC2 | コンテナ(ECS/EKS) | サーバーレス(Lambda) | |
|---|---|---|---|
| 自分で管理する範囲 | 多い（OSも） | 中くらい | 少ない（コードだけ） |
| 向いている用途 | 自由度の高い既存アプリ | 移植性の高いアプリ群 | イベント駆動の小さな処理 |
| 課金イメージ | 起動している時間 | 土台(EC2/Fargate)に準ずる | 実行した分だけ |
確認クイズ
Q1. 画像がS3にアップロードされるたびに、サーバーを常時立てずにサムネイルを生成する短い処理を実行したい。最適なサービスは？
Q2. アクセスが時間帯で大きく変動するWebサービスで、負荷に応じてEC2の台数を自動で増減させたい。使うべき仕組みは？
Q3. すでにKubernetesでアプリを運用しており、その標準をそのままAWSのマネージド環境で使いたい。適切なサービスは？
Q4. コンテナアプリを動かしたいが、EC2インスタンスの管理（パッチ・キャパシティ）はしたくない。最適な土台は？
よくある質問（FAQ）
Q. EC2・コンテナ・サーバーレス、結局どう選ぶ？
A. 管理の手間と自由度のトレードオフです。自由度がほしい・既存アプリをそのまま動かす＝EC2、移植性とリソース効率＝コンテナ、運用を最小化したい小さな処理＝サーバーレス（Lambda）。迷ったら「サーバー管理をどれだけ減らしたいか」で考えます。
Q. Auto Scaling と ロードバランサーの違いは？
A. Auto Scalingは「台数を増減」、ELBは「トラフィックを分散」。役割が別で、ふつうは併用します。ELBで複数台に均等に流しつつ、Auto Scalingで需要に応じて台数を調整します。
Q. Fargate と Lambda はどちらもサーバーレス。違いは？
A. 動かす対象が違います。Fargateは「コンテナ」をサーバーレスで動かす土台、Lambdaは「関数（短いコード）」をイベント駆動で実行します。コンテナならFargate、小さなイベント処理ならLambdaです。
まとめ
- 3系統＝EC2（仮想サーバー）・コンテナ（ECS/EKS）・サーバーレス（Lambda/Fargate）。右ほど管理が軽い
- コンテナはKubernetes＝EKS／AWS流＝ECS、土台はEC2かFargateを選べる
- サーバーレスはイベント処理＝Lambda／コンテナ土台＝Fargate
- 弾力性はAuto Scaling（台数増減）＋ELB（負荷分散）のセットで実現
- ➡ 関連：ストレージ（S3/EBS/EFS/Glacier） ／ 責任共有モデル
- ➡ CLF対策トップに戻る
※本記事はAWS公式試験ガイド(CLF-C02)および各サービスの公開ドキュメントに基づき、エンジニアKが作成しています。サービス仕様は更新されることがあるため、最新は必ずAWS公式でご確認ください。本サイトはAmazon Web Services, Inc.の公式サイトではありません。AWSは同社の商標です。
コメント