コンピューティング・ストレージ・データベース・ネットワーキングの主要4分野を超え、AWSのポートフォリオはCLF-C02試験のタスクステートメント3.8が対象とする4つのサービスファミリーへと広がっている。AWSの統合サービス（Integration services）、AWS DevTools、AWS IoT、そしてAWSエンドユーザーコンピューティング（end-user compute）——これらはモダンなクラウドアーキテクチャを結びつけ、ソフトウェアデリバリーを加速し、物理デバイスを接続し、アプリケーションを人間に届ける役割を担う。本ページでは、Cloud Practitioner受験者が理解すべき統合サービス、AWS DevTools、AWS IoT、AWS end-user compute、Amazon WorkSpaces、AWS Step Functionsの要点を、ソリューションアーキテクト級の深度には踏み込まず整理する。
CLF-C02はこれらのカテゴリをユースケース認識の深度でテストする。「マイクロサービスをキューで疎結合にする」や「エンタープライズアプリをブラウザにストリーミングする」といったシナリオを読み、適切なAWSサービス名に対応付けられれば十分だ。設定・価格計算・デバッグの能力は問われない。そのため本ページ一枚で統合サービス、AWS DevTools、AWS IoT、end-user computeの幅広い領域をカバーできる。
AWSその他サービスカテゴリとは何か？
「その他サービスカテゴリ（Other service categories）」とは、CLF-C02試験ガイドがコンピューティング・ストレージ・データベース・ネットワーキングに収まらないサービス群を束ねる総称ラベルだ。タスクステートメント3.8はその傘下に4つのグループを挙げている。AWS統合サービス（メッセージング・ワークフロー・SaaSコネクター）、AWS DevTools（CI/CDパイプライン・IDE・IaCフレームワーク）、AWS IoT（デバイス接続とエッジ）、そしてAWS end-user compute（仮想デスクトップ・アプリストリーミング・ブラウザアクセス）の4つだ。
試験の焦点は広さ優先・深さ二次の確認だ。ドメイン3は試験全体の34%を占め、タスク3.8はその中で最も小さな割当となっている。しかしここに登場するサービスは、他ドメインのシナリオ問題でdistractorとして現れやすく、「メッセージキュー」や「仮想デスクトップ」と明確に示された問題では正答そのものにもなる。
4つのサブカテゴリ一覧
- AWS統合サービス — 他のサービスやSaaSアプリ間でメッセージ・イベント・データを転送するグルー（接着剤）サービス。例：Amazon SQS、Amazon SNS、Amazon EventBridge、AWS Step Functions、Amazon MQ、Amazon AppFlow。
- AWS DevTools — ソフトウェアのビルド・テスト・リリース・観測を支援するサービス。例：CodeBuild、CodeDeploy、CodePipeline、CodeArtifact、CodeCatalyst、CodeGuru、AWS X-Ray、AWS Cloud9、AWS CDK、AWS SAM、AWS Amplify。
- AWS IoT — 物理デバイスのフリートを接続・保護・管理・分析するサービス。例：AWS IoT Core、AWS IoT Greengrass、AWS IoT Analytics、AWS IoT Device Defender、AWS IoT SiteWise。
- AWS end-user compute — デスクトップ・アプリ・ブラウザセッションをエンドユーザーに届けるマネージドサービス。例：Amazon WorkSpaces、Amazon AppStream 2.0、Amazon WorkSpaces Web。
試験がこれらをまとめて扱う理由
4つのファミリーはすべて、Cloud Practitioner観点で共通の特徴を持つ。それは、コア（コンピューティング・ストレージ・データベース・ネットワーク）の配管設備の上に乗る特化型消費ポイントであるという点だ。統合サービス・パイプライン・デバイスフリート・エンドユーザーアクセスが必要になったときに追加するものであり、システム設計の出発点にはなりにくい。この特性を共有するため、試験ガイドでは一括りにされており、認識確認セットとして学習できる。
やさしい解説: AWSその他サービスカテゴリ
類比1 — 駅の荷物搬送システム（AWS統合サービス）
大規模なターミナル駅を思い浮かべてほしい。手荷物が預かりカウンターに届き、コンベアベルトで搬送され、仕分けゾーンを経て該当プラットフォームへ届けられる。Amazon SQSは待合ホームの整理券システムだ。乗客（メッセージ）が順番に並び、係員が一人ずつ呼び出す。下流の処理係が一度に大量の対応を迫られることはない。Amazon SNSは構内放送だ。「○番線に電車が到着します」という一つのアナウンスが、駅構内のすべてのスピーカーへ同時に届く。Amazon EventBridgeは中央指令室だ。駅全体で起きるあらゆる出来事（線路変更・遅延・乗換案内更新）を監視し、ルールに基づいて「新幹線に遅延が発生したら保守担当と案内板の両方に通知する」という形で振り分ける。AWS Step Functionsは乗車フローのチェックリストだ。切符確認→本人確認→荷物重量チェック→乗車という正確な手順を定義し、「重量オーバー → 追加料金徴収」「切符不正 → 係員に誘導」といった分岐も制御する。これがAWS統合サービス全体を理解するための頭の中の構造だ。
類比2 — 自動車の組み立てライン（AWS DevTools）
AWS DevToolsは現代の自動車組み立てラインと同じように動く。AWS CodeCommit（レガシーアカウント）はすべての設計図（ソースコード）を保管する部品倉庫だ。AWS CodeBuildは生の部品をサブアセンブリに変換するプレス・溶接工程（ソースコードをバイナリにコンパイルする）に相当する。AWS CodeDeployはエンジンとタイヤをシャシーに取り付ける最終組み立てロボット（EC2・Lambda・ECSへのデプロイ）だ。AWS CodePipelineは各工程を正しい順序で車体を送り出し、工程間に品質ゲートを設けるコンベアベルトの司令塔だ。AWS CodeArtifactは認定部品の在庫管理システム（プライベートパッケージレジストリ）に当たる。Amazon CodeCatalystは、これらすべてをプロジェクトテンプレートと開発環境で統合する新世代のグリーンフィールド工場全体だ。AWS X-Rayは完成車が試験走行中に取り付けられるテレメトリハーネスで、どのサブシステムが速度を落としたかを正確に記録する。AWS DevToolsのイメージ全体をこの一枚の絵で掴んでほしい。
類比3 — オフィスフロアの貸し出し（AWS end-user compute）
AWS end-user computeはオフィススペースの貸し出しと同じ仕組みで動く。Amazon WorkSpacesは長期契約のオフィスだ。社員それぞれに自分の名前のかかった個室（永続的な仮想デスクトップ）が与えられ、毎日同じ部屋に戻ってくる。ポスターは壁にかかったままで、ファイルも机の上に残っている。Amazon AppStream 2.0はフリーアドレス型コワーキングフロアだ。社員が空いているデスクを使い、退出時にすべての作業内容がリセットされる（エフェメラルなアプリストリーミング）。Amazon WorkSpaces Webは来訪者用受付の仮設端末だ。ゲストが建物の鍵を持たずに、セキュリティ保護されたブラウザを通じて承認済みのWebアプリにアクセスできる（マネージドセキュアブラウザ）。シナリオで「永続的なデスクトップ」とあればAmazon WorkSpaces、「単一アプリをオンデマンドでストリーミング」とあればAmazon AppStream 2.0が正解だ。
コア動作原則
AWS統合サービス・AWS DevTools・AWS IoT・AWS end-user computeのすべてのサービスは、CLF-C02が好んでテストする4つの動作原則を共有している。
原則1：マネージドコントロールプレーン、顧客データプレーン
このトピックに登場するすべてのサービスはマネージドサービスだ。AWSがインフラを運用し、ソフトウェアにパッチを当て、可用性を確保し、APIを提供する。持ち込むのはペイロードだ——メッセージ本文（統合サービス）、ソースコード（DevTools）、デバイスのフィンガープリント（IoT）、ユーザーセッション（end-user compute）。これは責任共有モデルに直接対応する。これらすべてのサービスにおいて、AWSは「クラウドのセキュリティ（Security OF the cloud）」を、顧客は「クラウド内のセキュリティ（Security IN the cloud）」を担う。
原則2：デフォルトでイベント駆動
ほとんどのAWS統合サービスはイベント駆動モデルで動作する。Amazon SQSのコンシューマーは準備できたときにポーリングする。Amazon SNSはメッセージがトピックに届いた瞬間にサブスクライバーへプッシュする。Amazon EventBridgeはイベントがバスに到着した瞬間にパターンマッチングでルーティングする。AWS Step Functionsは一つのステートを実行し、完了（またはイベント）を待って次のステートへ進む。「イベント駆動」を認識できるかどうかが、統合サービスの試験問題の半分を解く鍵だ。
原則3：従量課金
統合サービス・DevTools・IoT・end-user compute（Amazon WorkSpacesは月額バンドルもある点を除く）はすべて消費量に応じた課金だ。SQSはリクエスト100万件ごと、CodeBuildはビルド分ごと、IoT Coreはメッセージごと、AppStreamはストリーミング時間ごとに課金される。Amazon WorkSpacesは時間課金と月額バンドルの両方が存在する唯一の例外——この例外は暗記すること。
原則4：統合前提の設計
これらのサービスが単独で存在することはほとんどない。統合サービスはLambdaやECSと組み合わさる。DevToolsはEC2・Lambda・ECS・EKSにデプロイする。IoTはルールを介してS3・Kinesis・Lambdaへ転送する。end-user computeはFSxのファイルを読み込み、AWS Directory ServiceやIAM Identity Centerで認証する。試験シナリオは通常2つのサービス名を挙げ、特定のコンピューティング・ストレージの基盤に対して正しい統合サービスを選ばせる。
アプリケーション統合：AWS統合サービス詳細
AWS統合サービスはこのトピックの中で最も高い出題率を誇る。SQS対SNS対EventBridgeで少なくとも1問、AWS Step Functionsでも少なくとも1問は出ると見ておくべきだ。
Amazon SQS — キュー
Amazon Simple Queue Service（SQS）は、フルマネージドなメッセージキューだ。プロデューサーがメッセージをキューに書き込み、コンシューマーがキューをポーリングして1件ずつ処理する。メッセージは最大14日間（デフォルト4日）保持され、コンシューマーが削除するまでキューに残る。このプルベース・1コンシューマー・1メッセージのモデルにより、SQSはAWS統合サービスにおける定番の**疎結合（decoupling）**ツールとなっている。
SQSには2種類のキュータイプがある。**標準キュー（Standard queue）**は最低1回の配信とベストエフォートの順序保証を提供する——スループットはほぼ無制限だが、まれな重複配信や順序の入れ替わりが発生する可能性がある。FIFOキューはバッチ処理を用いて毎秒最大3,000メッセージを厳密な先入れ先出し順で正確に1回配信する。CLF-C02のシナリオで「厳密な順序」や「重複なし」が強調されていればFIFO、「大量スループット」や「順序は問わない」が強調されていればStandardを選べばよい。
Amazon SNS — トピック
Amazon Simple Notification Service（SNS）は、マネージドなパブリッシュ・サブスクライブサービスだ。パブリッシャーがトピックに1つのメッセージを送ると、SNSはそのメッセージをすべてのサブスクライバー（SQSキュー・Lambda関数・HTTPエンドポイント・メール・SMS・モバイルプッシュ）へプッシュする。**ファンアウト（fan-out）**が定義的なパターンだ——1つの在庫イベントが倉庫Lambda・分析SQSキュー・SMSアラートを同時にトリガーできる。
SNSトピックにもSQSと同様に標準版とFIFO版がある。
Amazon EventBridge — イベントバス
Amazon EventBridge（Amazon CloudWatch Eventsの後継）は、AWSサービス・SaaSパートナー（Zendesk・PagerDuty・Datadog・Shopify）・独自アプリケーションからイベントを受け取り、ルールによるパターンマッチングでターゲットへルーティングするサーバーレスのイベントバスだ。「バケットXでS3 PutObjectイベントが発生したら、Lambda YとSQS Zへメッセージをプッシュせよとするルール」を定義できる。EventBridgeはスキーマレジストリとイベントアーカイブもサポートしており、これらはAmazon SNSには存在しない機能だ。
Amazon EventBridge対Amazon SNS — 定番の落とし穴
この違いは微妙だが試験に出る。Amazon SNSはプッシュ専用のpub/subトピックで、フィルターポリシーを設定しない限りすべてのサブスクライバーがすべてのメッセージを受信する。Amazon EventBridgeはより機能が豊富だ。イベントには構造化されたJSONスキーマが付き、ルールは任意のイベント属性でマッチング（「detail-typeが'Object Created'かつsourceが'aws.s3'」）でき、監査やリカバリーのためにイベントのアーカイブと再生ができる。シンプルなファンアウトにはSNS、コンテンツベースのルーティング・SaaSイベントの取り込み・再生可能性が必要なときはEventBridgeを使う。
AWS Step Functions — ワークフローオーケストレーター
AWS Step Functionsはサーバーレスのワークフロー・ステートマシンサービスだ。JSONベースのワークフロー（Amazon States Language）を定義し、Lambda・ECSタスク・SageMakerジョブ・APIコール・人間の承認ステップを、分岐・並列処理・リトライ・エラーハンドリングを含む視覚的なフローとして組み上げる。CLF-C02試験が「複数のLambda関数をリトライ付きで信頼性高く順次実行するサービスはどれか」と問えば、答えはAWS Step Functionsだ。
ワークフロータイプは2種類ある。Standard（最大1年間、正確に1回実行、監査に適した記録）とExpress（最大5分、最低1回実行、イベント駆動アプリ向けの超高スループット）だ。
Amazon MQ — レガシーブローカー
Amazon MQはマネージドなApache ActiveMQおよびRabbitMQだ。特定のシナリオのために存在する。アプリケーションコードを書き直さずにオンプレミスのメッセージブローカーをAWSに移行する場合だ。オンプレのアプリがJMS・AMQP・MQTT・STOMPプロトコルを使っている場合、Amazon MQはこれらのワイヤープロトコルをそのまま維持する。クラウドネイティブの新設計ではSQSやSNSを優先すべきだ。
Amazon AppFlow — SaaS統合
Amazon AppFlowは、SaaSアプリ（Salesforce・Slack・ServiceNow・Zendesk・Google Analytics・Marketo・SAP）とAWSサービス（S3・Redshift）の間で、スケジュールまたはイベントベースでデータを移動させる、フルマネージドなSaaSデータ統合サービスだ。組み込みのフィルタリングと変換機能を持つ。試験で「SalesforceのデータをコードなしでS3に安全に転送する」とあればAmazon AppFlowが答えだ。
開発者ツール：AWS DevTools詳細
AWS DevToolsはこのトピックの第2の柱だ。CLF-C02試験では各サービスの1行の役割を認識できれば十分であり、設定能力は問われない。
AWS Codeスイート
AWS DevToolsの伝統的なラインナップ——AWS Codeスイート——はソースからプロダクションまでの完全なパイプラインをカバーする。
- AWS CodeCommit — プライベートGitリポジトリサービス。ステータス補足：CodeCommitは2024年半ば以降、新規AWSアカウントへの提供が終了している。既存顧客は引き続き使用できるが、新規アカウントはサードパーティのGit（GitHub・GitLab・Bitbucket）またはAmazon CodeCatalystを使う必要がある。
- AWS CodeBuild — フルマネージドなCIビルドサービス。ソースをコンパイルしてテストを実行し、アーティファクトを生成する。ビルド分ごとの課金。
- AWS CodeDeploy — EC2・Lambda・ECS・オンプレミスサーバーへの自動デプロイサービス。インプレース・ブルーグリーン・カナリアのデプロイメントをサポートする。
- AWS CodePipeline — CI/CDオーケストレーター。CodeCommit（またはGitHub）→CodeBuild→CodeDeployを、手動承認ゲートと並列ステージを含む繰り返し可能なパイプラインに組み上げる。
- AWS CodeArtifact — npm・PyPI・Maven・NuGet・Gradleなど向けのプライベートパッケージレジストリ。エアギャップ環境向けにパブリックパッケージのプロキシ・キャッシュとしても機能する。
この5つが組み合わさってソフトウェアデリバリーライフサイクルの全工程をカバーする。
Amazon CodeCatalyst — 統合された開発体験
Amazon CodeCatalystは、ソース管理（独自のGitまたはGitHub）・CI/CD・課題管理・クラウド開発環境を単一のプロジェクトベースUIに統合した統合ソフトウェア開発サービスだ。GitHub + GitHub Actions + GitHub Issues + Codespaceを一カ所にまとめたAWS版と考えると分かりやすい。「ソース・パイプライン・開発環境を数分でセットアップする新規プロジェクト」というシナリオはCodeCatalystを指す。
Amazon CodeGuru — レビューとプロファイラー
Amazon CodeGuruは2つのコンポーネントから成る。
- CodeGuru Reviewer — プルリクエスト内のセキュリティ問題・リソースリーク・AWSベストプラクティス違反をフラグするML駆動のコードレビュー。
- CodeGuru Profiler — 本番環境でコストが最も高いコード行とそのCPU・メモリのホットスポットを特定するランタイムアプリケーションプロファイラー。
AWS X-Ray — 分散トレーシング
AWS X-Rayは、分散アプリケーション全体（API Gateway・Lambda・ECS・DynamoDB・SNS・SQS）をリクエストが移動する経路を追跡し、ホップごとのレイテンシを含むサービスマップを生成する。どのダウンストリームサービスがボトルネックかを特定するために使う。試験で「マイクロサービスアーキテクチャの遅延しているコンポーネントを特定する」とあれば答えはX-Rayだ。
AWS Cloud9 — クラウドIDE
AWS Cloud9は、AWS CLIツールと端末アクセス・リアルタイム共同編集機能を内蔵したブラウザベースのIDEだ。EC2インスタンスまたは自前のサーバー上で動作する。任意のデバイスからの素早い編集やペアプログラミングに有用だ。
Infrastructure as Codeフレームワーク
AWS DevToolsの中でも、CloudFormationの抽象レイヤーであるIaCの2サービスは特記に値する。
- AWS CDK（Cloud Development Kit） — TypeScript・Python・Java・Go・C#でCloudFormationスタックを記述する。CDKはビルド時にCloudFormationテンプレートを合成する。
- AWS SAM（Serverless Application Model） — サーバーレスアプリ（Lambda・API Gateway・DynamoDB・SQS・SNS）向けのシンプルなCloudFormation DSL。SAMテンプレートは生のCloudFormationより短く、ローカルテスト用CLIも付属する。
AWS CDKとAWS SAMはいずれも最終的にCloudFormationを出力するため、CloudFormationのロールバックとドリフト検出の恩恵を受ける。
AWS Amplify — フルスタックアプリフレームワーク
AWS Amplifyは、ホスティング（VercelやNetlifyに相当）・CI/CD・認証（Cognito）・GraphQL/REST API（AppSync/API Gateway）・ストレージ（S3）・データ（DynamoDB）を単一CLIの後ろに束ねたフルスタックWebおよびモバイルフレームワークだ。「サインインとバックエンドAPIを備えたReactやFlutterアプリを素早くスキャフォールドする」というシナリオではAmplifyが正解だ。
AWS IoTサービス詳細
AWS IoTサービスは、インターネットに接続されたデバイス（サーモスタット・工場センサー・自動車・ドローン）のフリートを接続・保護・分析する。CLF-C02試験は認識レベルの問題のみを出題する。
AWS IoT Core — デバイス接続
AWS IoT Coreはデバイスのフロントドアだ。数百万の同時MQTT・HTTPS・WebSocket接続をデバイスから受け付け、X.509証明書で認証し、ルールエンジンを通じてメッセージを他のAWSサービスへルーティングする。あらゆるAWS IoTアーキテクチャはIoT Coreから始まる。
AWS IoT Greengrass — エッジランタイム
AWS IoT Greengrassはデバイスまたはオンプレゲートウェイ上で動作するエッジコンピューティングランタイムだ。Lambda関数・MLモデル・Dockerコンテナをデバイス上でローカルに実行できる——デバイスが断続的な接続環境にある場合や、サブ秒の応答時間が必要な場合に有用だ。Greengrassは接続が確立するたびにクラウドのIoT Coreと同期する。
AWS IoT Analytics
AWS IoT Analyticsは、IoT Coreから大量のデバイスデータを取り込み、クレンジング・変換・分析を行うマネージドサービスだ。処理結果の構造化データをQuickSightまたはMLパイプラインへ渡す。
AWS IoT Device Defender
AWS IoT Device Defenderは、セキュリティの設定ミスと異常なデバイス挙動（サーモスタットが突然ギガバイト単位のデータを送信し始めた場合など）に対してIoTフリートを監査・監視する。
AWS IoT SiteWise
AWS IoT SiteWiseは産業IoT専用サービスだ。工場設備・PLC・SCADAシステムからデータを収集・保存・整理・可視化する。
AWS end-user compute詳細
AWS end-user computeは、エンドユーザーへ職場環境——デスクトップ・アプリ・ブラウザアクセス——を物理ハードウェアの配布なしに届ける。Amazon WorkSpacesが代表的なサービスだ。
Amazon WorkSpaces — 仮想デスクトップ（DaaS）
Amazon WorkSpacesはマネージドな**Desktop-as-a-Service（DaaS）**だ。各ユーザーはAWSクラウド上の永続的なWindowsまたはUbuntu Linuxデスクトップを持ち、Windows・macOS・iPad・Chromebook・Androidのクライアント、またはブラウザからアクセスできる。ドキュメント・インストール済みアプリ・カスタマイズはセッション間で永続する——月曜にログインして保存したものが、火曜にそのまま残っている。
Amazon WorkSpacesは時間課金（断続的な利用者向け）と月額課金（毎日利用者向け）のどちらかで課金される——この時間対月額のトレードオフは試験に出る。Amazon WorkSpacesはActive Directory・AWS Directory Service・IAM Identity Centerと統合して認証を行う。試験シナリオで「リモート社員向けの永続的な仮想デスクトップ」とあればAmazon WorkSpacesがデフォルトの正解だ。
Amazon AppStream 2.0 — アプリケーションストリーミング
Amazon AppStream 2.0は、フルデスクトップではなく単一のアプリケーションをユーザーのブラウザへストリーミングする。アプリケーションはAWS上の一時的なEC2バックのストリーミングインスタンス上で実行され、ユーザーにはアプリウィンドウのみが表示される。ユーザーがログオフするとストリーミングインスタンスは破棄され、S3上のホームフォルダやユーザーデータを添付しない限りデフォルトでは何も永続しない。
Amazon AppStream 2.0をAmazon WorkSpacesより選ぶタイミング：ユーザーが毎日住み着くフルデスクトップではなく、1つの特定アプリ（CADツール・トレーニングシミュレーター・短期利用の有償デスクトップアプリ）だけを必要としている場合。
Amazon WorkSpaces Web — セキュアブラウザ
Amazon WorkSpaces WebはマネージドなAWSのセキュアブラウザサービスだ。ユーザーは自分のブラウザを通じてAWS上で動作する堅牢なChromiumブラウザセッションを取得する。IT部門は、VPNクライアントや仮想デスクトップを展開せずに、委託契約者・BYODユーザー・社内スタッフが社内WebアプリやSaaSポータルへ安全に一時アクセスできる手段として使う。
Amazon WorkDocs — 廃止済み
Amazon WorkDocsはマネージドなドキュメント共同作業サービス（エンタープライズ向けGoogle Driveのようなもの）だった。AWSは2025年4月にWorkDocsを廃止しており、新規顧客の受け付けは終了している。古い模擬問題に記載されている可能性があるが、現行のCLF-C02試験では正解として登場する可能性は低い。
重要な数値と暗記必須の事実
CLF-C02試験が正確な制限値をテストすることは稀だが、AWS統合サービス・DevTools・IoT・end-user computeにわたって一握りの数値とデフォルト値が出題される。
- Amazon SQSのメッセージ保持期間：1分〜14日、デフォルト4日。
- SQS FIFOのスループット：バッチ処理を使用して毎秒最大3,000メッセージ。
- AWS Step Functions Standardワークフローの実行時間：最大1年間。
- AWS Step Functions Expressワークフローの実行時間：最大5分。
- AWS IoT Coreのプロトコル：MQTT・MQTT over WSS・HTTPS。
- Amazon WorkSpacesの課金モード：時間課金（従量制）と月額課金（無制限）。
- AWS CodeCommitのステータス：2024年以降、新規アカウントへの提供終了。CodeCatalystまたはサードパーティのGitを使うこと。
- Amazon WorkDocsのステータス：2025年4月廃止。
試験頻出の落とし穴
落とし穴1：SQS対SNS — プルとプッシュ
Amazon SQSはプル（コンシューマーがキューをポーリングする）、Amazon SNSはプッシュ（メッセージが届いた瞬間にSNSがサブスクライバーへ送る）だ。「コンシューマーが自分のペースでメッセージを処理する」というシナリオはSQS、「複数のシステムに即座に通知する」はSNSだ。
落とし穴2：EventBridgeはSNSではない
既述のとおり、EventBridgeはスキーマ・コンテンツベースのパターンマッチング・SaaSパートナーイベント・イベントアーカイブ/再生をサポートする。SNSはよりシンプルなpub/subだ。シナリオでZendesk・Shopify・Datadog・スキーマ・再生に言及があればEventBridgeを指す。
落とし穴3：Step Functions対Lambda
AWS Lambdaはイベントによってトリガーされる1つの関数を実行する。AWS Step Functionsは分岐・リトライ・待機ステートを含むワークフローとして多数のLambda（および他のサービス）をオーケストレートする。シナリオが単一の関数を扱っていればLambda、「条件分岐を含む3つのLambdaを連携させる」とあればAWS Step Functionsを選ぶ。
落とし穴4：新規アカウントにおけるCodeCommitのステータス
CodeCommitは新規AWSアカウントへの提供が終了している。新規顧客がGitホスティングを設定するシナリオでは、GitHub/GitLab/Bitbucket + CodePipelineまたはAmazon CodeCatalystが正解だ。CodeCommitが利用可能だと思い込まないこと。
落とし穴5：WorkSpaces対AppStream
毎日利用する永続的なデスクトップ = Amazon WorkSpaces。オンデマンドの一時的な単一アプリ = Amazon AppStream 2.0。混同しないこと。
落とし穴6：CloudWatch Events対EventBridge
Amazon EventBridgeはAmazon CloudWatch Eventsのリブランド・進化版だ。同じ基盤サービスを共有している。新しいドキュメントはすべてEventBridgeと表記する。「CloudWatch Events」への古い言及は引き続き機能するが、頭の中ではEventBridgeへ読み替えること。
サービスのスコープ境界
タスク3.7（AI/ML・Analytics）対タスク3.8（その他サービスカテゴリ）
AI/MLサービス（Bedrock・SageMaker・Rekognition・Comprehend）と分析サービス（Athena・Redshift・Kinesis・Glue・QuickSight）はタスク3.7に属し、本ページの対象外だ。「MLモデルを実行する」や「S3データレイクをクエリする」というシナリオは3.7であり3.8ではない。
タスク3.1（デプロイメント）対タスク3.8（DevTools）
AWS CloudFormation・AWS Elastic Beanstalk・AWS OpsWorksはタスク3.1（デプロイメントおよび運用手法）に属する。AWS CDKとAWS SAMは最終的にCloudFormationを出力するが、AWS DevToolsに分類される。開発者向けCLIとともに提供され開発者をターゲットにしているため、試験ガイドではタスク3.8に分類されている。この境界は曖昧であり、実際の問題ではどちらのグループ分けでも出題される可能性がある。
タスク3.3（コンピューティング）対タスク3.8（end-user compute）
Amazon EC2・AWS Lambda・AWS Fargate・ECS・EKSはタスク3.3のコンピューティングだ。Amazon WorkSpaces・Amazon AppStream 2.0・Amazon WorkSpaces Webはタスク3.8のエンドユーザーコンピューティングだ。区別のポイント：タスク3.3のコンピューティングはアプリケーションコードを動かし、タスク3.8のAWS end-user computeは人間のために対話型デスクトップやアプリを動かす。
比較マトリックス
AWS統合サービス選択マトリックス
- プロデューサーとコンシューマーを疎結合にし1コンシューマーが1メッセージを処理する → Amazon SQS
- 1つのメッセージを多数のサブスクライバーへ（ファンアウト） → Amazon SNS
- コンテンツベースのルーティング・SaaSイベントの取り込み・イベントの再生 → Amazon EventBridge
- 分岐・リトライ・人間の承認を含む多ステップワークフロー → AWS Step Functions
- コード変更なしでオンプレのJMS/AMQP/MQTTブローカーを移行 → Amazon MQ
- Salesforce/Slack/SAPからS3/Redshiftへのゼロコードデータ転送 → Amazon AppFlow
AWS DevTools選択マトリックス
- プライベートGit（レガシーアカウントのみ） → AWS CodeCommit
- コードのコンパイルとテスト → AWS CodeBuild
- EC2/Lambda/ECS/オンプレへのアーティファクトデプロイ → AWS CodeDeploy
- ビルドとデプロイのステージをオーケストレート → AWS CodePipeline
- プライベートnpm/PyPI/Mavenレジストリ → AWS CodeArtifact
- 統合プロジェクト（リポジトリ + CI/CD + 課題管理 + 開発環境） → Amazon CodeCatalyst
- 自動コードレビューとランタイムプロファイリング → Amazon CodeGuru
- 分散トレーシング → AWS X-Ray
- ブラウザベースのIDE → AWS Cloud9
- TypeScript/PythonによるIaC → AWS CDK
- シンプルなサーバーレスIaC → AWS SAM
- フルスタックWeb/モバイルアプリフレームワーク → AWS Amplify
AWS end-user compute選択マトリックス
- 毎日利用する永続的な仮想デスクトップ → Amazon WorkSpaces
- 一時的な単一アプリのストリーミング → Amazon AppStream 2.0
- 社内WebアプリへのマネージドセキュアブラウザS → Amazon WorkSpaces Web
FAQ — AWSその他サービスカテゴリ 頻出6問
Q1：Amazon SQSとAmazon SNSはどう使い分ければよいか？
A：1コンシューマーが1メッセージを自分のペースで処理する必要があるときはAmazon SQSを使う。ファンアウト——1つのメッセージを多数のサブスクライバーへ同時に届ける——が必要なときはAmazon SNSを使う。SNSがトピックへパブリッシュし、複数のSQSキューへファンアウトする組み合わせパターンがよく使われる。
Q2：Amazon EventBridgeとAmazon SNSの違いは何か？
A：Amazon SNSはシンプルなプッシュ型pub/subトピックだ。Amazon EventBridgeは機能豊富なイベントバスで、構造化されたイベントスキーマ・任意のイベント属性に基づくコンテンツマッチング・SaaSパートナーイベントソース（Zendesk・Shopify・Datadog等）・イベントアーカイブ/再生をサポートする。より高度なルーティングが必要なときはEventBridge、シンプルなファンアウトにはSNSを選ぶ。
Q3：AWS CodeCommitはまだ利用できるか？
A：AWS CodeCommitは2024年半ばから新規AWSアカウントへの提供が終了している。既存顧客は引き続き使用できるが、新規アカウントはサードパーティのGitプロバイダー（GitHub・GitLab・Bitbucket）またはAmazon CodeCatalystを使う必要がある。試験ではこのステータス変更の認識がテストされると見ておくこと。
Q4：Amazon WorkSpacesとAmazon AppStream 2.0はどちらを選ぶべきか？
A：ユーザーが毎日戻ってくる永続的な仮想デスクトップ（フルな作業環境）が必要なときはAmazon WorkSpacesを選ぶ。セッション間で永続する必要のない1つの特定アプリ（トレーニングソフトウェア・CADツール・短期利用のライセンスアプリ）をオンデマンドで利用するときはAmazon AppStream 2.0を選ぶ。
Q5：AWS Step FunctionsはAWS Lambdaにできないことができるか？
A：AWS Lambdaは単一の関数を実行する。AWS Step Functionsは複数のLambda（および他のAWSサービス）を、分岐ロジック・並列実行・指数バックオフ付きリトライ・待機ステート・人間の承認ステップを含むワークフローとしてオーケストレートする。Step Functionsは視覚的なステートマシンダイアグラムを提供し、Lambdaはそのグラフのノードのひとつだ。
Q6：なぜAWSにはAmazon MQとAmazon SQSの両方が存在するのか？
A：Amazon MQは移行シナリオのために存在する——ActiveMQやRabbitMQを中心に構築されたオンプレアプリがすでに使っているJMS・AMQP・MQTT・STOMPのワイヤープロトコルをそのまま話せる。Amazon SQSはAWSネイティブのHTTP APIだ。クラウドネイティブの新設計にはSQSを優先すべきであり、Amazon MQは主としてブローカー依存の既存アプリのリフトアンドシフト向けだ。
練習問題リンク — タスク3.8対応演習
ドメイン3の予算100問のうちタスク3.8は最も問題数が少ないが、サービス数は最も多いトピックの一つだ。推奨する学習順序：
- AWS統合サービスのシナリオを演習する — SQS対SNS対EventBridge対Step Functions（約40問）。
- AWS DevToolsのサービス識別を演習する — Codeスイート + CodeGuru + X-Ray + Amplify（約30問）。
- AWS IoTのサービス認識を演習する — IoT Core対Greengrass対Analytics対Device Defender対SiteWise（約15問）。
- AWS end-user computeを演習する — Amazon WorkSpaces対AppStream対WorkSpaces Web（約15問）。
最終試験戦略
CLF-C02試験はこのトピックを軽くウェイト付けしている（ドメイン3の中で最も小さい割当）。学習のROIは認識スピードにあり、深度ではない。SQS/SNS/EventBridge/Step Functionsのマトリックスが最もシナリオ問題を生む出題源であるため、AWS統合サービスを最重要ファミリーとして扱う。AWS DevToolsは中程度の重要度として——Codeスイートの各サービス・CodeGuru・X-Ray・CDK・SAM・Amplifyの1行の役割を暗記する。AWS IoTとAWS end-user computeは認識のみで十分——IoTの5キーワードとend-user computeの3キーワードを暗記する。試験当日に本ページのサービス名が見えたら、そのサブファミリーにパターンマッチングして最も明白な適合を選ぶこと。
AWS統合サービス・DevTools・IoT・end-user computeを合わせると試験スコア全体の約5%に相当するが、他のドメインのシナリオ問題でのdistractorとして不釣り合いなほど多く登場する。Amazon WorkSpacesが永続的なデスクトップであり、AWS Step Functionsがワークフローオーケストレーターであることを知っておくだけで、タスク3.8だけでなく試験全体でポイントを守れる。