AWSコンピューティングサービスは、AWS上でコードやワークロードを実行するあらゆる手段を網羅している。Amazon EC2による従来型の仮想マシンから、Amazon ECSおよびAmazon EKSによるコンテナ化アプリ、AWS LambdaおよびAWS Fargateによる完全サーバーレス実行まで多岐にわたる。CLF-C02試験ガイドのタスクステートメント3.3では、ユースケースに応じてAWSコンピューティングサービスを特定する能力が問われる。本章は試験本番でサービスを素早く選択できるよう訓練する。AWSコンピューティングサービスはドメイン3の中で最大の出題範囲であり、実際のCLF-C02では少なくとも5〜8問のシナリオ問題が出題される。
AWSコンピューティングサービスとは何か？
AWSコンピューティングサービスとは、アプリケーションロジックの実行・データの処理・ワークロードのホスティングを担うAWSサービス群のことである。CLF-C02試験では、AWSコンピューティングサービスを3つのパラダイムに整理している。仮想マシン（Amazon EC2およびAmazon Lightsail）、コンテナ（Amazon ECS、Amazon EKS、起動タイプとしてのAWS Fargate）、そしてサーバーレス関数（AWS Lambda）である。AWS BatchやAWS Outpostsといった特化型サービスは、バッチジョブやオンプレミス拡張といった周辺ユースケースをカバーする。
CLF-C02試験ガイドの基礎レベルでは、以下の能力が求められる。
- 各AWSコンピューティングサービスの名称と一言ユースケースを答えられること。
- 運用責任とワークロード継続時間に基づいて、Amazon EC2・AWS Lambda・AWS Fargateを区別できること。
- Amazon ECSとAmazon EKSを「AWSネイティブのオーケストレーション」と「マネージドKubernetes」に対応付けられること。
- AWS Fargateは独立したコンピューティングエンジンではなく起動タイプであり、Amazon ECSとAmazon EKSの両方で動作することを知っていること。
- Amazon EC2 Auto ScalingとElastic Load Balancerを組み合わせてAmazon EC2に弾力性と高可用性をもたらす仕組みを理解していること。
AWSコンピューティングサービスのスコープは、デプロイ・運用方法（タスク3.1、例：AWS Elastic Beanstalk）や料金モデル（タスク4.1、例：Amazon EC2のオンデマンド・リザーブド・スポット）とも重複する。本章は「識別して区別する」レイヤーに集中し、デプロイの仕組みや料金の計算はそれぞれ専用の章に委ねる。
CLF-C02でAWSコンピューティングサービスが重要な理由
コンピューティングはCLF-C02のドメイン3の中で歴史的に最も言及されてきたテーマである。コミュニティの調査でも、「EC2対Lambda対Fargate」のシナリオ問題が受験者の混乱を最も招くAWSコンピューティングサービスとして上位に挙げられている。AWSコンピューティングサービスを正確に理解すれば、ドメイン3（試験全体の34%）の大きなブロックを確保でき、責任共有モデル・料金モデル・グローバルインフラストラクチャの問題にも直結する。
やさしい解説: AWSコンピューティングサービス
AWSコンピューティングサービスとは、実際にコードを実行するAWS提供物の総称である。CPUサイクルが消費され、アプリケーションロジックが動く場所だ。CLF-C02受験者にとって難しいのは、Amazon EC2・AWS Lambda・AWS Fargate・Amazon ECS/EKSが遠目には似て見えながら、運用責任・課金粒度・デプロイ速度がまったく異なる点だ。以下の3つの類比はそれぞれ別の角度からその混乱を解消する。コントロール対マネージド、コストモデル、デプロイ速度の3つのレンズを通して読めば、コンピューティングの一覧が暗記の羅列ではなく当然のトレードオフとして見えてくる。
Analogy 1 — 自動車（所有・タクシー・レンタカー）：コントロール対マネージド
移動手段で考えてみよう。マイカーの購入はAmazon EC2の稼働に相当する。車種と排気量を自分で選び（インスタンスファミリー）、鍵を自分が持ち、いつ走るかを自分で決め、オイル交換・タイヤ交換・駐車・保険といった維持管理をすべて引き受ける。完全なコントロール、最大の責任だ。タクシーの配車アプリで呼ぶのはAWS Lambdaの呼び出しに相当する。車はオンデマンドで来て短いトリップをこなし、終わったら消える。エンジンに触れることも、駐車することもなく、乗った分だけ支払う。法人レンタカーフリートから借りるのはAWS Fargateに相当する。特定のクラスの車（タスクあたりのvCPUとメモリ）が割り当てられ、給油・清掃・整備はフリート運営者が担う。自分は運転するだけで、ホストの健全性維持は任せられる。同じ目的地に向かうのに、3つのまったく異なる所有形態がある。
Analogy 2 — 住居（一軒家・マンション・ビジネスホテル）：コストモデル
毎月の請求書で考えよう。一軒家の所有はAmazon EC2を24時間365日稼働させることに相当する。住んでいようといまいと住宅ローン・固定資産税・光熱費を支払う。安定していて予測可能で、全平米を使い切れば割高感はないが、使わない時間は無駄になる。マンションの管理費あり区分所有はAmazon ECSまたはAmazon EKSをEC2で動かすことに相当する。区画（コンテナ）は自分で所有するが、共用部分のコスト（クラスターホスト）を住人で分担するため、密度が上がるほど1区画あたりのコストは下がる。出張者向けビジネスホテルの一泊料金はAWS Fargateに相当する。タスク単位の正確な課金で長期契約はなく、ドアの外のことはフロントがすべて面倒を見てくれる。コワーキングスペースの分単位デスク利用はAWS Lambdaに相当する。実際に座っている秒数だけ支払い、離席中のコストはゼロだ。同じニーズのフロアプランに対して、4種類のまったく異なる請求書が来る。
Analogy 3 — 食事の調達（専属料理人・屋台・自動販売機）：デプロイ速度
空腹のお客様に料理が届くまでの速度で考えよう。専属料理人を雇うのはAmazon EC2を起動することに相当する。候補者を面接し、キッチンを揃え、食材を仕入れ、シフトを組む。最初の一皿が出るまでに日単位の準備が必要だが、すべての料理をオーダーメイドにできる。祭りに屋台を出すのはAWS FargateまたはAmazon ECSに相当する。屋台（コンテナイメージ）はあらかじめ完成していて自己完結しているため、新しい場所に乗り込んで数分で提供を開始できる。キッチンの工事は不要だが、スタッフは引き続き必要だ。自動販売機はAWS Lambdaに相当する。お客様がボタンを押せば数秒で商品が落ちてくる。販売中以外は機械が眠っていて、スタッフは一人もいない。抽象化が上がるほどデプロイ速度が上がる。料理人（最も遅く、最もカスタマイズ可能）から屋台（速くてポータブル）、自動販売機（即時、完全自動化）へと。
この3つのレンズをまとめて読めば、AWSコンピューティングサービスのラインナップが暗記のドリルではなく、日常生活で当たり前に行うトレードオフとして見えてくる。
AWSコンピューティングサービスのコア動作原則
AWSコンピューティングサービスには、CLF-C02試験全体に登場する3つのコア動作原則がある。
原則1 — 管理スペクトラム
すべてのAWSコンピューティングサービスは「ハイパーバイザーより上をすべて自分で管理する」（Amazon EC2）から「AWSがすべてを管理する」（AWS Lambda）までのスペクトラム上に位置する。サービスが抽象化されるほど運用オーバーヘッドは減るが、コントロールも減る。Amazon EC2が最大のコントロールを与え、AWS Lambdaが最小のオーバーヘッドを提供し、AWS Fargate・Amazon ECS・Amazon EKSはその中間に位置する。
原則2 — オーケストレーションによる弾力性
AWSにおけるコンピューティングの弾力性はAmazon EC2単体の特性ではなく、Amazon EC2（またはコンテナ）をAmazon EC2 Auto ScalingとElastic Load Balancingと組み合わせることで生まれる。AWS Lambdaは設計上弾力的であり、ゼロから数千の同時実行数まで自動的にスケールする。AWS Fargateはホスト管理なしにタスクレベルでスケールする。
原則3 — 使った分だけ支払う
すべてのAWSコンピューティングサービスは従量課金に従うが、課金単位はサービスによって異なる。
- Amazon EC2: 秒単位（ほとんどのLinuxインスタンスで最初の60秒は最低課金）または時間単位。
- AWS Lambda: 実行時間のミリ秒 × 割り当てメモリのGB。
- AWS Fargate: タスクが予約したvCPUとメモリの秒単位。
- Amazon ECS / Amazon EKSコントロールプレーン: クラスター時間単位（EKS）または無料（ECSコントロールプレーン）。
- Amazon Lightsail: 定額月額料金（予算が立てやすい）。
AWSコンピューティングサービスとは、抽象化レベルに関わらず（仮想マシン・コンテナ・サーバーレス関数を問わず）、顧客のコードやワークロードを実行するAWSの提供物の総称である。 参照: https://aws.amazon.com/products/compute/
Amazon EC2 — Elastic Compute Cloudの詳細
Amazon EC2（Elastic Compute Cloud）は、AWSコンピューティングサービスの中核をなす仮想マシンサービスである。CLF-C02の試験では複数のAmazon EC2シナリオ問題が必ず出題されるため、Amazon EC2を完全に習得することは必須だ。
Amazon EC2とは何か？
Amazon EC2は、AWSクラウド上で動作する「インスタンス」と呼ばれるサイズ変更可能な仮想サーバーを提供する。オペレーティングシステム（Amazon Linux・Ubuntu・Windows・Red Hat・SUSE・macOS）、インスタンスタイプ（CPU・メモリ・ストレージ・ネットワークの組み合わせ）、リージョン/AZを自分で選択する。Amazon EC2は最初の1分経過後は秒単位で課金され、ブロックストレージのAmazon EBS・ネットワーキングのAmazon VPC・安全な認証情報管理のIAMロールと統合されている。
Amazon EC2インスタンスファミリー
Amazon EC2はインスタンスタイプをワークロードに最適化したファミリーにグループ化している。CLF-C02ではファミリー名の頭文字とワークロードカテゴリを対応付けることが求められる。
- 汎用（M、T、Mac） — CPU・メモリのバランス型。ウェブサーバー・小規模データベース・開発環境向け。Tシリーズはバースト可能で低ベーストラフィックに最適。
- コンピューティング最適化（C） — コスト対CPU比が最高。バッチ処理・ゲームサーバー・科学的シミュレーション・高性能ウェブサーバー向け。
- メモリ最適化（R、X、z） — 大容量RAM。インメモリキャッシュ・SAP HANA・リアルタイムビッグデータ分析向け。
- ストレージ最適化（I、D、H） — 高ローカルIOPSまたは高順次ディスクスループット。NoSQLデータベース・データウェアハウス・Hadoopクラスター向け。
- アクセラレーテッドコンピューティング（P、G、Inf、Trn、F） — GPU・AWS Inferentia・AWS Trainium・FPGA。ML学習・推論・グラフィックスレンダリング向け。
M = バランス（Main）、C = コンピューティング（Compute）、R = RAM、I = IOPSストレージ、D = 高密度HDD、P/G = GPU。頭文字を覚えるだけでCLF-C02のほとんどのAmazon EC2シナリオ問題が解ける。 参照: https://aws.amazon.com/ec2/instance-types/
Amazon EC2購入オプション（概要）
Amazon EC2は5種類の主要な料金モデルをサポートしている。詳細はpricing-modelsの章に委ねるが、CLF-C02レベルでは各名称を認識できれば十分だ。
- オンデマンド — 従量課金、コミットメントなし。
- リザーブドインスタンス（RI） — 1年または3年のコミットメントで最大72%割引。
- Savings Plans — コンピューティング費用の$/時をコミットしてAmazon EC2・AWS Fargate・AWS Lambdaにわたる柔軟性を確保。
- スポットインスタンス — 余剰キャパシティで最大90%割引、AWSは2分前通知でいつでも回収できる。
- Dedicated Hosts / Dedicated Instances — コンプライアンスまたはBYOL（持ち込みライセンス）シナリオ向けの物理サーバー分離。
CLF-C02はAmazon EC2の知識を本章（コンピューティングサービス、タスク3.3）と料金モデル（タスク4.1）に分割している。まずAWSコンピューティングサービスを特定し、次に料金の判断に進むこと。両者を混同することが試験でよくある罠である。 参照: https://aws.amazon.com/ec2/pricing/
Amazon EC2ストレージオプション
Amazon EC2インスタンスはさまざまなストレージタイプを接続できる。
- インスタンスストア — ホストに物理接続、エフェメラル。インスタンスが停止すると消える。
- Amazon EBS（Elastic Block Store） — 耐久性のあるブロックボリューム、インスタンスのライフサイクルを超えて存続し、スナップショットも可能。
- Amazon EFS（Elastic File System） — 複数のAmazon EC2インスタンスにまたがってマウントできる共有NFSファイルシステム。
ストレージの選択は独自のCLF-C02トピックだが、Amazon EC2のストレージ選択が耐久性・IOPS・コストに影響することを認識しておく必要がある。
Amazon EC2 Auto ScalingとElastic Load Balancing
AWSコンピューティングサービスについてのCLF-C02の議論は、Amazon EC2 Auto ScalingとElastic Load Balancingなしには完結しない。この2つが組み合わさって、AWSコンピューティングサービスの「弾力性」が実現される。
Amazon EC2 Auto Scalingグループ
Auto Scalingグループ（ASG）は、スケーリングポリシー（CPU使用率・リクエスト数・スケジュールイベント）に基づいて、Amazon EC2インスタンスの数を最小値と最大値の間で自動調整する。ASGは不健全なAmazon EC2インスタンスも自動的に置き換えるため、自己修復の振る舞いが得られる。
CLF-C02でのAuto Scalingの典型的なシグナル。
- 「需要に応じてAmazon EC2のキャパシティを自動的に追加または削除する」 → Auto Scalingグループ。
- 「N台の健全なAmazon EC2インスタンスからなるフリートを維持する」 → ASGヘルスチェック＋置き換え。
- 「業務時間中にAmazon EC2をスケールアウトし、夜間にスケールインする」 → スケジュールスケーリングポリシー。
Elastic Load Balancing（ELB）の種類
Elastic Load Balancingは、受信トラフィックを複数のAmazon EC2インスタンス・AWS Fargateタスク・AWS Lambda関数・オンプレミスのターゲットに分散する。CLF-C02では現行の3種類と廃止された1種類を認識することが求められる。
- Application Load Balancer（ALB） — レイヤー7（HTTP/HTTPS）。パスベースルーティング・ホストベースルーティング・WebSocketサポート。マイクロサービスとコンテナ化ウェブアプリに最適。
- Network Load Balancer（NLB） — レイヤー4（TCP/UDP/TLS）。超低遅延、毎秒数百万リクエスト、AZあたりの静的IP。高性能または非HTTP系ワークロードに最適。
- Gateway Load Balancer（GWLB） — サードパーティの仮想アプライアンス（ファイアウォール・IDS/IPS）をデプロイしスケールさせる。
- Classic Load Balancer（CLB） — レガシー、新しいワークロードには非推奨。古い学習教材に言及があるが、CLF-C02ではALBかNLBを選ぶこと。問題文に「Classic」とある場合のみ選択する。
シナリオがHTTP/HTTPS/ウェブアプリ/パスベースを述べている → ALB。TCP/UDP/毎秒数百万リクエスト/静的IPを述べている → NLB。ファイアウォールアプライアンスを述べている → GWLB。Classicを述べている → 古い教材の赤信号。 参照: https://aws.amazon.com/elasticloadbalancing/features/
AWS Lambda — サーバーレスコンピューティング
AWS Lambdaは、AWSコンピューティングサービスの中でサーバーレスを代表するサービスだ。AWS Lambdaはサーバーの責任モデルを再定義するため、CLF-C02試験で頻出のシナリオ問題が出題される。
AWS Lambdaとは何か？
AWS Lambdaは、サーバーをプロビジョニングせずにイベントに応じてコードを実行する。関数（Python・Node.js・Java・Go・.NET・Ruby、またはコンテナイメージ経由のカスタムランタイム）をアップロードし、トリガー（Amazon S3オブジェクトのアップロード・Amazon API Gatewayリクエスト・Amazon DynamoDBストリーム・Amazon EventBridgeイベント、他多数）を設定すれば、あとはAWS Lambdaがすべてを処理する。スケーリング・パッチ適用・複数AZにわたる高可用性を含む。
AWS Lambdaの課金は純粋な従量課金だ。
- コンピューティング: メモリのGB-seconds × 実行時間。
- 呼び出し: 100万リクエストあたりの定額。
- 無料枠: 毎月100万リクエストと400,000 GB-secondsが永続的に無料。
必ず覚えるべきAWS Lambdaのハードリミット
- 最大実行時間: 1呼び出しあたり15分（900秒）。
- メモリ: 128 MB〜10,240 MB（10 GB）が割り当て可能。
- エフェメラルストレージ /tmp: 最大10 GB。
- デプロイパッケージ: 50 MBの圧縮（直接）または250 MBの非圧縮、コンテナイメージ経由で10 GB。
- ペイロード: 同期呼び出しで6 MB、非同期イベントで256 KB。
AWS Lambdaは1呼び出しあたり900秒（15分）が上限である。ワークロードが15分を超えて実行する必要がある場合、AWS Lambdaは不適切だ。代わりにAmazon EC2・AWS Fargate・AWS Batchを選択すること。 参照: https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html
AWS Lambdaのコールドスタート
「コールドスタート」とは、AWS Lambdaが呼び出しを処理するために新しい実行環境を初期化しなければならない場合に発生する現象であり、ランタイムとパッケージサイズに応じて通常100ミリ秒から数秒のレイテンシが追加される。コールドスタートはProvisioned Concurrency（事前ウォームアップ済みのコンテナ）で軽減できるが、CLF-C02では用語を認識できれば十分だ。AWS Lambdaのコールドスタートは主な答えではなく、注意を誘うディストラクターとして出題されることが多い。
AWS Lambdaを使うべきケース
- イベント駆動の処理（Amazon S3へのアップロード → サムネイル生成）。
- Amazon API Gatewayの背後にある軽量なウェブバックエンド。
- スケジュールされたcron的なタスク（Amazon EventBridge Scheduler）。
- AWSサービス間のグルーコード。
- 実行時間が15分未満で、バースト性があり、アイドルコストゼロの課金から恩恵を受けるワークロード。
AWS Lambdaを使うべきでないケース
- 長時間実行プロセス（15分超）: Amazon EC2・AWS Fargate・AWS Batchを使うこと。
- 永続的な接続（ゲームサーバー、ステートフルセッションを持つ大規模WebSocket）: Amazon EC2またはコンテナを優先すること。
- AWS Lambdaの料金がAmazon EC2を上回る非常に高い安定したスループット: Pricing Calculatorで計算すること。
CLF-C02の典型的な罠として「3時間実行するバッチジョブ」に対してAWS Lambdaを提示することがある。AWS Lambdaには15分のハード上限がある。代わりにAWS Batch（キュー型の長時間ジョブ）またはAmazon EC2 / AWS Fargateを選ぶこと。コミュニティデータによれば、これはAWSコンピューティングサービスにおけるトップ5の罠の1つだ。 参照: https://aws.amazon.com/lambda/faqs/
AWS上のコンテナ — Amazon ECS vs Amazon EKS vs AWS Fargate
コンテナベースのAWSコンピューティングサービスはCLF-C02が好んでテストする3者択一のマトリックスを形成している。Amazon ECS対Amazon EKS対AWS Fargateの違いを明確に理解することは、試験で数点分の価値がある。
コンテナの基本概念
サービス比較に入る前に、5つのコンテナ基本用語を覚えておくこと。
- イメージ — アプリケーションコード・ランタイム・ライブラリ・依存関係を含む読み取り専用のテンプレート。Dockerfileからビルドされる。
- レジストリ — イメージが保存される場所。AWS上のネイティブな選択肢は**Amazon ECR（Elastic Container Registry）**だ。
- コンテナ — イメージの実行中インスタンス。
- タスク / ポッド — 一緒にデプロイされる1つ以上のコンテナのグループ（Amazon ECSではTask、Amazon EKSではPod）。
- クラスター — タスクまたはポッドを実行するコンピューティングキャパシティの論理的なグループ。
- サービス — Nコピーのタスクを稼働させ続けるロードバランサーと統合された長時間稼働のスケーラブルなコントローラー。
Amazon ECS — AWSネイティブのコンテナオーケストレーション
Amazon ECS（Elastic Container Service）は、AWSの独自の深く統合されたコンテナオーケストレーションプラットフォームだ。Amazon ECSはAWSネイティブのプリミティブ（タスク定義・サービス・クラスター）を使用し、すべてのAWSサービス（IAM・Amazon VPC・Elastic Load Balancing・Amazon CloudWatch・AWS Fargate・Amazon EC2）と最小限のグルーコードで連携する。Amazon ECSコントロールプレーンは無料であり、基盤となるコンピューティングにのみ支払う。
Amazon EKS — マネージドKubernetes
Amazon EKS（Elastic Kubernetes Service）はAWSのマネージドKubernetesサービスだ。Amazon EKSはアップストリームのCNCF準拠のKubernetesを実行しており、Google GKE・Azure AKS・セルフマネージドのベアメタルクラスターで見られるKubernetesと同じものだ。Amazon EKSは、クラウド間のポータビリティ・豊富なKubernetesツールのエコシステム・またはチームがKubernetesプリミティブ（Deployment・Service・Ingress・Helmチャート）に精通している場合に威力を発揮する。Amazon EKSコントロールプレーンはクラスターあたりの時間単位料金が発生する。
AWS Fargate — サーバーレスコンテナランタイム
AWS Fargateは独立したコンピューティングサービスではなく、起動タイプである。 AWS FargateはAmazon ECSとAmazon EKSの両方が、Amazon EC2ホストマシンを管理せずにタスク/ポッドを実行できるようにする。タスクあたりのCPUとメモリを定義すれば、AWS Fargateが基盤となるキャパシティを透過的にプロビジョニング・パッチ適用・スケーリングする。課金は予約したvCPUとメモリの秒単位だ。
この「起動タイプ」という区別は試験で非常に頻出だ。Amazon ECSをAmazon EC2起動タイプで実行することも、Amazon ECSをAWS Fargate起動タイプで実行することもできる。Amazon EKSでも同様の選択肢がある。
非常によくあるCLF-C02の罠は、AWS FargateをAmazon ECSと同格として扱うことだ。そうではない。AWS FargateはAmazon ECSとAmazon EKSのためのサーバーレス実行モードだ。「Amazon ECS on AWS Fargate」または「Amazon EKS on AWS Fargate」と答えることが正解であり、「Amazon ECSの代わりにAWS Fargate」は罠の答えだ。 参照: https://aws.amazon.com/fargate/
Amazon ECS対Amazon EKSの判断基準
- Amazon ECSを選ぶべき場合: チームがAWS中心、Dockerfileからプロダクションへのパスをできるだけスムーズにしたい、AWSネイティブのAPIを好む、コントロールプレーンのコストを最小化したい。
- Amazon EKSを選ぶべき場合: チームがすでにKubernetesを知っている、マルチクラウドまたはハイブリッドのポータビリティが必要、オープンソースのKubernetesツール（Helm・Istio・Argo CD）に依存している、KubernetesマニフェストとしてリリースされるベンダーソフトウェアをRunしている。
AWS Fargate対Amazon EC2起動タイプの判断基準
- AWS Fargateを選ぶべき場合: ホスト管理ゼロを望む、変動的なワークロード、タスク単位の課金、素早い起動、低い運用オーバーヘッド。
- Amazon EC2起動タイプを選ぶべき場合: 特定のインスタンスタイプ（GPU・ベアメタル）が必要、最大限のコントロールを求める、適用できるリザーブドインスタンスまたはSavings Plansがすでにある、ホストあたりのデーモン型ワークロードが必要。
Amazon ECS = AWSネイティブ（EはElastic、CはContainer）。Amazon EKS = Kubernetes（KはKubernetes）。試験のプレッシャー下で受験者はこれをよく混同する。K → Kubernetesのニーモニックを覚えれば、CLF-C02でこの区別を間違えることは二度とない。 参照: https://aws.amazon.com/containers/services/
AWS Batch — マネージドバッチコンピューティング
AWS Batchは、バッチワークロード向けのAWSコンピューティングサービスの特化型メンバーだ。AWS Batchはキュー型ジョブ（科学的シミュレーション・金融リスク計算・ゲノミクスパイプライン・メディアトランスコード）を実行するためにAmazon EC2またはAWS Fargateのキャパシティをオンデマンドでプロビジョニングする。CPUとメモリの要件とともにジョブを投入すれば、AWS Batchが適切なインスタンスタイプを選択し実行し、キューが空になったらシャットダウンする。AWS BatchはAmazon EC2スポットインスタンスと統合してコスト効率を最大化する。
CLF-C02でのAWS Batchの典型的なシグナル。
- 「自動スケジューリングで何千もの長時間実行コンピューティングジョブを実行する」 → AWS Batch。
- 「スポットインスタンスを使ったコスト最適化バッチコンピューティング」 → AWS Batch（スポットあり）。
- 「15分を超えるワークロード、リアルタイムではない」 → AWS BatchまたはAmazon EC2、AWS Lambdaは不可。
Amazon Lightsail — シンプルなVPS
Amazon Lightsailは、AWSコンピューティングサービスのエントリーレベルのメンバーだ。予測可能な月額料金（約$3.5/月から）・事前設定されたバンドル（LAMPスタック・Node.js・WordPress・Joomla・Magento・静的サイト）・シンプルなコンソールを備えたシンプルな仮想プライベートサーバー（VPS）だ。
CLF-C02でのAmazon Lightsailのユースケース。
- 小規模なウェブサイト・ブログ・テスト環境。
- 予測可能で低トラフィックの小規模ビジネスアプリケーション。
- Amazon EC2が複雑すぎると感じるAWS初学者の学習・プロトタイピング。
Amazon Lightsailは本番規模のエンタープライズワークロードや高度なネットワーキングには不向きだ。それらにはAmazon EC2・Amazon ECS・AWS Fargateに移行すること。ニーズが拡大した場合、LightsailインスタンスをAmazon EC2に「アップグレード」することもできる。
CLF-C02で「小規模ビジネス」「シンプル」「予測可能な月額料金」「初心者」などのキーワードがある場合、Amazon Lightsailが正解である可能性が高い。Amazon LightsailはGoDaddy・DigitalOcean・Bluehostを選ぶようなユーザーをターゲットにしている。 参照: https://aws.amazon.com/lightsail/features/
AWS Outposts — オンプレミスでのコンピューティング
AWS OutpostsはAWSコンピューティングサービスを自社のデータセンターに拡張する。AWSは物理ラック（42UのOutpostsラック）または1U/2UのOutpostsサーバーをオンプレミスに配送し、それらのラックでAWSサービスのサブセット（Amazon EC2・Amazon EBS・Amazon ECS・Amazon EKS・Amazon RDS・Amazon S3 on Outposts）を実行する。AWS OutpostsはAWSがリモートで管理する。
ユースケース。
- 低レイテンシ要件（製造フロア・リアルタイムトレーディング）。
- データが特定の建物や国から出ることを禁じるデータ主権要件。
- 一部のシステムを一時的にオンプレミスに残す必要がある移行の橋渡し。
CLF-C02では一文での識別だけが必要だ。「AWS Outpostsは自社のデータセンターでAWSコンピューティングサービスを実行する」。詳細なインフラストラクチャの話はglobal-infrastructureの章にある。
AWSコンピューティングサービス比較マトリックス
CLF-C02でAWSコンピューティングサービスの差異化を定着させるには、横並びのチートシートが最善の方法だ。
| AWSコンピューティングサービス | 抽象化 | 作業単位 | 最大継続時間 | 管理オーバーヘッド | 典型的なユースケース |
|---|---|---|---|---|---|
| Amazon EC2 | VM | インスタンス | 制限なし | 高い（OS＋ランタイム） | 長時間実行ワークロード全般、カスタムスタック |
| Amazon EC2 on Auto Scalingグループ | VMフリート | インスタンスフリート | 制限なし | 高い | 弾力的なウェブ層、エンタープライズアプリ |
| Amazon ECS on Amazon EC2 | コンテナ | タスク | 制限なし | 中程度（ホストを自分で運用） | コスト管理ありのAWSネイティブコンテナ |
| Amazon ECS on AWS Fargate | コンテナ（サーバーレス） | タスク | 制限なし | 低い | AWSネイティブコンテナ、ホストなし |
| Amazon EKS on Amazon EC2 | Kubernetes | ポッド | 制限なし | 中〜高い | K8sポータビリティ＋コスト管理 |
| Amazon EKS on AWS Fargate | Kubernetes（サーバーレス） | ポッド | 制限なし | 低い | K8sポータビリティ、ホストなし |
| AWS Lambda | 関数 | 呼び出し | 15分 | 最小限 | イベント駆動、バースト型、短時間ワークロード |
| AWS Batch | バッチジョブ | ジョブ | 制限なし | 低い | 科学的・スケジュールされたバッチ |
| Amazon Lightsail | シンプルVM | バンドル | 制限なし | 非常に低い | 小規模ウェブサイト、初学者 |
| AWS Outposts | オンプレVM/コンテナ | インスタンス/タスク | 制限なし | 中程度 | オンプレミスでのAWS拡張 |
AWSコンピューティングサービス全体の頻出ひっかけ問題
CLF-C02は同じAWSコンピューティングサービスの罠を繰り返し出題する。完全に把握しておけばポイントをもらったも同然だ。
罠1 — Amazon EC2対AWS Lambdaの境界線
問題はワークロードを説明して「どのサービスか？」と尋ねる。以下に注意すること。
- 長時間実行（15分超）→ AWS Lambdaではない。
- イベント駆動、ミリ秒〜分単位 → AWS Lambda。
- 安定した予測可能な24時間365日稼働 → Amazon EC2（リザーブドインスタンスまたはSavings Plans）。
- スパイク型・バースト型・短時間 → AWS Lambda。
罠2 — Amazon ECS対Amazon EKS
- 「AWSネイティブのオーケストレーション」 → Amazon ECS。
- 「マネージドKubernetes」または「アップストリームKubernetes」 → Amazon EKS。
- 「マルチクラウドのポータビリティ」または「Helmチャート」 → Amazon EKS。
- 「最低のコントロールプレーンコスト」 → Amazon ECS（コントロールプレーンは無料）。
罠3 — AWS Fargateを独立したサービスとして扱う
AWS Fargateは「どのオーケストレーター？」という問いの答えには絶対にならない。オーケストレーターはAmazon ECSまたはAmazon EKSだ。AWS Fargateは「どの起動タイプがホスト管理を排除するか？」という問いの答えだ。
罠4 — AWS Lambdaの時間制限
「時間単位」「一晩中」「重い長時間実行」に言及するシナリオはAWS Lambdaを除外する。
罠5 — Elastic BeanstalkとAmazon EC2
AWS Elastic Beanstalkはデプロイサービス（トピック3.1）であり、独立したコンピューティングエンジンではない。裏でAmazon EC2をプロビジョニングする。コンピューティングサービスの問題ではAmazon EC2が正しい基盤の答えであり、デプロイ方法の問題ではAWS Elastic Beanstalkが答えだ。
CLF-C02で最も頻繁に出るAWSコンピューティングサービスの罠は、Amazon EC2・AWS Lambda・AWS Fargateの2つが同時に妥当に見えるようにワークロードを組み立てることだ。このデシジョンツリーを使うこと: 15分を超えて実行するか？ → AWS Lambdaを除外。ホストを管理したいか？ → したい場合はAmazon EC2、したくない場合はAWS Fargate。本当にサーバーレス・イベント駆動・短時間か？ → AWS Lambda。 参照: https://docs.aws.amazon.com/whitepapers/latest/aws-overview/compute-services.html
重要数値と必ず覚える事実
- AWS Lambdaの最大タイムアウト: 15分（900秒）。
- AWS Lambdaの最大メモリ: 10,240 MB（10 GB）。
- Amazon EC2インスタンスファミリーの頭文字: M、T（汎用）、C（コンピューティング）、R、X（メモリ）、I、D、H（ストレージ）、P、G、Inf、Trn、F（アクセラレーテッド）。
- Amazon ECSコントロールプレーンのコスト: 無料（コンピューティングのみ支払う）。
- Amazon EKSコントロールプレーンのコスト: クラスターあたりの時間単位料金（無料ではない）。
- AWS Fargateの課金単位: 予約したvCPUとメモリの秒単位。
- Amazon Lightsailの最低価格: 約$3.5/月（最安バンドル）。
- Amazon EC2 Auto Scaling: 最小・希望・最大キャパシティの間で調整する。
- Elastic Load Balancerの種類: ALB（L7）、NLB（L4）、GWLB（アプライアンス）、CLB（非推奨）。
- AWS Batchの基盤コンピューティング: Amazon EC2またはAWS Fargate。
- AWS Outpostsのフォームファクター: ラック（42U）またはサーバー（1U/2U）。
AWSコンピューティングサービス対関連トピック — 境界線
CLF-C02はAWSコンピューティングサービス（タスク3.3）と隣接するトピックを慎重に区別している。境界線を理解すること。
- コンピューティングサービス対デプロイ・運用方法（3.3対3.1） — Amazon EC2はコンピューティングであり、AWS Elastic Beanstalk / AWS CloudFormation / AWS CDKはデプロイだ。コンピューティングの問いは「何がコードを実行するか？」であり、デプロイの問いは「コードはどのようにそこに到達したか？」だ。
- コンピューティングサービス対料金モデル（3.3対4.1） — 「どのサービスか？」はコンピューティングであり、「どう支払うか？」は料金だ。両者は相互作用するが（Amazon EC2にはオンデマンド・RI・スポットがある）、試験は明確に区別する。
- コンピューティングサービス対グローバルインフラストラクチャ（3.3対3.2） — Amazon EC2はリージョン内のAZで実行される。AWS Outpostsはオンプレミスで実行される。コンピューティングがどこにあるかはタスク3.2であり、コンピューティングが何かはタスク3.3だ。
- コンピューティングサービス対データベースサービス（3.3対3.4） — データベースをAmazon EC2上で（セルフマネージドのコンピューティングとして）実行することも、マネージドデータベース（Amazon RDS・Amazon Aurora・Amazon DynamoDB）を使うこともできる。CLF-C02は問題文が明示的に「セルフマネージド」と言わない限り、マネージドデータベースの回答を好む。
- コンピューティングサービス対ネットワークサービス（3.3対3.5） — Amazon EC2はAmazon VPCサブネットに存在するが、Elastic Load Balancingはコンピューティングに隣接しながらも試験ガイドでは正式にネットワーキングサービスとして分類される。
練習問題リンク — タスク3.3対応演習
/learn/aws/clf-c02/practice?task=3.3 の問題集を使ってAWSコンピューティングサービスのパターンを反復練習すること。
- 「サーバーをプロビジョニングせずにイベントに応じてコードを実行するAWSサービスはどれか？」 → AWS Lambda。
- 「3時間実行するバッチジョブに最適なサービスはどれか？」 → AWS BatchまたはAmazon EC2、AWS Lambdaは不可。
- 「アップストリームAPIとの互換性を持つマネージドKubernetesを必要としている企業。」 → Amazon EKS。
- 「最もシンプルなAWSマネージドコンテナオーケストレーションを望む企業。」 → Amazon ECS。
- 「Amazon EC2インスタンスを一切管理せずにコンテナを実行したい企業。」 → Amazon ECS on AWS FargateまたはAmazon EKS on AWS Fargate。
- 「事前設定されたWordPressスタックを定額月額料金で必要としている小規模ビジネス。」 → Amazon Lightsail。
- 「低レイテンシのためにAWSサービスをオンプレミスで実行したい企業。」 → AWS Outposts。
- 「CPU使用率に基づいてAmazon EC2キャパシティを自動的に調整するサービスはどれか？」 → Amazon EC2 Auto Scaling。
- 「HTTPSトラフィックのパスベースルーティングに最適なロードバランサーはどれか？」 → Application Load Balancer（ALB）。
- 「インメモリSAP HANAワークロードに最適なAmazon EC2インスタンスファミリーはどれか？」 → メモリ最適化（Rファミリー）。
FAQ — AWSコンピューティングサービスの頻出問題
Q1. CLF-C02のメインなAWSコンピューティングサービスは何か？
CLF-C02のコアなAWSコンピューティングサービスはAmazon EC2（仮想マシン）・AWS Lambda（サーバーレス関数）・Amazon ECS（AWSネイティブコンテナ）・Amazon EKS（マネージドKubernetes）・AWS Fargate（Amazon ECSとAmazon EKSのサーバーレスコンテナ起動タイプ）・AWS Batch（マネージドバッチジョブ）・Amazon Lightsail（シンプルVPS）・AWS Outposts（自社データセンター内のAWSコンピューティング）である。コンピューティング隣接サービスとしてElastic Load BalancingとAmazon EC2 Auto Scalingも覚えておくこと。
Q2. AWS LambdaとAmazon EC2のどちらを選ぶべきか？
ワークロードがイベント駆動・バースト型・短時間（15分未満）でアイドルコストゼロの課金から恩恵を受ける場合はAWS Lambdaを選ぶ。ワークロードが長時間実行・安定していて特定のOS設定が必要または永続的な接続に依存している場合はAmazon EC2を選ぶ。AWS Lambdaの15分タイムアウトがハードルールだ。ワークロードがそれより長く必要な場合、AWS LambdaはCLF-C02で自動的に不正解となる。
Q3. Amazon ECSとAmazon EKSの違いは何か？
Amazon ECSとAmazon EKSはどちらもAWSコンピューティングサービス上でコンテナをオーケストレーションする。Amazon ECSは独自APIとコントロールプレーン無料のAWSネイティブであり、AWS上での最短パスだ。Amazon EKSは完全なCNCF互換性・クラスターあたりの時間単位コントロールプレーン料金・マルチクラウドポータビリティの恩恵を持つアップストリームKubernetesを実行する。純粋なAWSシンプルさのためにはAmazon ECSを選ぶ。チームやエコシステムがすでにKubernetesを話す場合はAmazon EKSを選ぶ。
Q4. AWS FargateはAmazon ECSまたはAmazon EKSの代替か？
いいえ。AWS Fargateは起動タイプであり、Amazon ECSとAmazon EKSの両方がAmazon EC2ホストを管理せずにコンテナを実行するために使用する。AWS Fargate単独では使用できない。常にオーケストレーターを通じて機能する。CLF-C02で「Amazon ECSの代わりにAWS Fargate」は罠の答えだ。
Q5. サーバーレスのAWSコンピューティングサービスはどれか？
AWSコンピューティングサービスのうち厳密にサーバーレスなのはAWS Lambda（関数）とAWS Fargate（コンテナ、Amazon ECSまたはAmazon EKS経由で使用）の2つだ。AWSにおける「サーバーレス」とは、Amazon EC2ホストの管理なし・ゼロへの自動スケーリング（AWS Fargateは限りなくゼロに近い）・使った分だけ課金することを意味する。
Q6. 15分を超える長時間ワークロードをカバーするコンピューティングサービスはどれか？
15分を超えるワークロードには、AWS Lambdaを除外して以下から選択すること: Amazon EC2・Amazon ECS（Amazon EC2またはAWS Fargate上）・Amazon EKS（Amazon EC2またはAWS Fargate上）・AWS Batch・Amazon Lightsail。CLF-C02で長時間ジョブに最もよく出てくる正解は、Amazon EC2（カスタムスタック）・AWS Batch（キュー型コンピューティングジョブ）・AWS Fargate（コンテナ）だ。
Q7. Amazon EC2 Auto ScalingとElastic Load BalancingはAWSコンピューティングサービスとどう関連するか？
Amazon EC2 Auto ScalingとElastic Load Balancingは、Amazon EC2を弾力的で高可用性にするグルーだ。Auto ScalingはAmazon EC2インスタンスの数を調整し、Elastic Load Balancingはトラフィックを健全なインスタンス（またはAWS Fargateタスク、AWS Lambda）に分散する。2つが組み合わさって、生のAmazon EC2が弾力的で自己修復するコンピューティングフリートに変わる。
Q8. CLF-C02のコンピューティングトピックでAWS Elastic Beanstalkが問われるか？
AWS Elastic Beanstalkは技術的にはデプロイサービス（タスク3.1）であり、コンピューティングサービスではない。裏でAmazon EC2をプロビジョニングする。コンピューティングサービスの問題では、Amazon EC2が基盤となるコンピューティングであり、デプロイ方法の問題ではAWS Elastic Beanstalkがマネージドプラットフォームだ。この2つのトピックを分けて考えれば区別を確実に答えられる。
参考資料 — AWSの公式ドキュメント
CLF-C02のスコープを超えてAWSコンピューティングサービスをより深く理解するには以下を参照すること。
- AWSの概要ホワイトペーパー — コンピューティングサービスのセクション。
- AWSの Well-Architected Framework — パフォーマンス効率の柱、コンピューティングセクション。
- Amazon EC2ユーザーガイド — インスタンスタイプの選択。
- AWS Lambda開発者ガイド — イベントソースとデプロイパッケージ。
- Amazon ECS開発者ガイドおよびAmazon EKSユーザーガイド。
- 起動タイプ選択のガイダンスとしてのAWS FargateのFAQ。
- AWSコンピューティングブログ（発表および新しいAWSコンピューティングサービス）。
これらのリソースはCLF-C02の深さを超えるが、AWSコンピューティングサービスの抽象化と従量課金モデルのメンタルモデルを強化するのに役立つ。
まとめ — AWSコンピューティングサービス一覧
- AWSコンピューティングサービスは仮想マシン（Amazon EC2・Amazon Lightsail）・コンテナ（Amazon ECS・Amazon EKS、起動タイプとしてのAWS Fargate）・サーバーレス（AWS Lambda）・特化型バッチ（AWS Batch）・オンプレミス拡張（AWS Outposts）に及ぶ。
- 管理スペクトラムはAmazon EC2（最大のコントロール）からAWS Lambda（最小のオーバーヘッド）まで広がる。
- Amazon EC2の弾力性はAmazon EC2 Auto ScalingとElastic Load Balancingの組み合わせから生まれる。
- AWS Fargateは常に起動タイプであり、スタンドアロンのコンピューティングサービスではない。
- AWS Lambdaには15分のハード上限があり、長時間ワークロードにはAmazon EC2・AWS Fargate・AWS Batch・またはEC2上のAmazon EKS/Amazon ECSを使うこと。
- Amazon Lightsailは初学者向けのエントリーポイントであり、AWS OutpostsはオンプレミスへのAWS拡張だ。
- コンピューティングサービス（3.3）・デプロイ・運用方法（3.1）・料金モデル（4.1）・グローバルインフラストラクチャ（3.2）の境界線を理解しておくこと。
本章のAWSコンピューティングサービスをマスターすれば、CLF-C02のドメイン3のコンピューティング問題5〜8問を自信を持って回答できる。さらに、SAA-C03やDVA-C02へのAWS認定の道を進む場合も、同じメンタルモデルがそのまま活用できる。