Solutions Architect – Associateの試験ガイドに登場するサービスについて、「主な用途」と「カテゴリ内での違い・使い分けポイント」を整理しました。これによってより深い理解が得られ、試験対策になると考えています。
part1では、分析サービス（Analytics）、アプリケーション統合（Application Integration）、AWS コスト管理、コンピューティング（Compute）、コンテナ（Containers）、データベース（Databases）、フロントエンドのウェブとモバイルまでを解説します。（part2はこちら）
分析サービス（Analytics）
| サービス | 主な用途 | 同カテゴリ内での違い・使い分けポイント |
|---|
| Amazon Athena | S3 上のファイルに対して、サーバレスで SQL クエリを実行 | DWH を持たずに S3 を直接クエリする軽量分析向け。Redshift は専用クラスタを持つ本格 DWH、EMR は Hadoop/Spark 等でがっつり処理するときに使う。Glue で ETL → S3 → Athena という組み合わせが典型。 |
| AWS Data Exchange | 外部の有償／無償データセットを購読して、自分のアカウントで利用 | 自分のデータをどう加工するか、というより「他社データの仕入れ口」。他の分析サービス（Athena/Redshift/EMR）は基本「自社データをどう処理するか」が主目的。 |
| AWS Data Pipeline | RDS・DynamoDB・S3 間などの定期バッチ ETL ワークフローを定義・実行 | 歴史的には ETL オーケストレーション用。最近は Glue（ETL 実行）＋ Step Functions/EventBridge（オーケストレーション） に置き換えやすく、既存ワークフローのメンテナンス用途で見ることが多い。 |
| Amazon EMR | Hadoop/Spark/Hive などを使ったビッグデータ処理クラスター | 「自由度の高い分散処理基盤」。Glue はサーバレス ETL 特化、Redshift は SQL ベース DWH、Athena は ad-hoc クエリ向け。カスタムライブラリや複雑な ML 処理をがっつりやるなら EMR。 |
| AWS Glue | サーバレスの ETL（抽出・変換・ロード）＋ Data Catalog | S3 等からデータを読み込み、Spark ベースジョブで ETL を実行。ETL 専用×サーバレスなのがポイント。Data Catalog によるスキーマ管理で Athena/Redshift/EMR と連携しやすい。 |
| Amazon Kinesis | ストリーミングデータの取り込み・処理・配信ファミリー（Data Streams / Data Firehose など） | リアルタイムストリーム用。MSK（Kafka）との違いは「AWS ネイティブ・マネージドでお手軽 vs Kafka 互換の柔軟さ」。SQS はジョブキュー、SNS は通知・ファンアウトが主目的で、Kinesis ほど連続ストリーム志向ではない。 |
| AWS Lake Formation | データレイク（S3）構築と、テーブルごとの権限管理・データガバナンス | Glue の Data Catalog と組で使い、「分析基盤全体の権限管理・ガバナンス」を担うサービス。単にクエリするだけなら Athena/Redshift、セキュアにレイク化して複数チームで使うなら Lake Formation。 |
| Amazon MSK | Apache Kafka 互換のマネージドメッセージストリーミング | ストリーミング用途だが、Kafka 互換が欲しいときの選択肢。Kinesis は AWS 独自 API で運用簡単、MSK は既存 Kafka エコシステムをそのまま持ち込みたいときに向く。 |
| Amazon OpenSearch Service | フルテキスト検索／ログ分析／メトリクス可視化 | 検索 & ログ分析特化。構造化データの DWH 分析は Redshift、S3 上のファイルに ad-hoc で SQL は Athena。OpenSearch は Kibana 互換 UI でログ・トレース・メトリクスを横断的に見る用途が得意。 |
| Amazon QuickSight | サーバレス BI・ダッシュボード | Athena/Redshift/各種 DB をバックエンドに持つ 可視化ツール。データを保持するのは Redshift / S3 / RDS 側で、QuickSight はレポート・ダッシュボード作成が主役。 |
| Amazon Redshift | DWH（データウェアハウス）での大規模 SQL 分析 | 本格的な DWH。大量データをカラムナストアで保持し、高速集計。Athena は S3 直接クエリで手軽、EMR は自由度高い分散処理、Redshift は「BI／定型分析の中心」として設計しやすい。 |
アプリケーション統合（Application Integration）
| サービス | 主な用途 | 同カテゴリ内での違い・使い分けポイント |
|---|
| Amazon AppFlow | Salesforce など SaaS ↔ S3/Redshift 間のデータ同期（ローコード） | SaaS 間・SaaS↔AWS のデータ連携専用 iPaaS。Glue は汎用 ETL、AppFlow は「SaaS コネクタが最初から用意されている」点が強み。 |
| AWS AppSync | GraphQL API のマネージドサービス（リアルタイム更新も） | GraphQL 用。REST API は API Gateway を使うのが一般的。EventBridge/SNS/SQS はバックエンドのメッセージングで、AppSync はクライアント向け API 層。 |
| Amazon EventBridge | SaaS・自作アプリ・AWS サービスのイベントをルーティングするイベントバス | SNS が「トピック単位の pub/sub」、SQS が「キュー」、EventBridge はイベントルーティング & ルールベース配送が得意。細かいフィルタや SaaS 連携をしたいときに向く。 |
| Amazon MQ | ActiveMQ / RabbitMQ 互換のマネージドメッセージブローカー | 既存システムが JMS/AMQP/STOMP などを使っているなら **「ほぼそのままクラウドへ」**ができる。新規クラウドネイティブなら SQS/SNS/EventBridge を優先しがち。 |
| Amazon SNS | Pub/Sub 通知（メール、HTTP エンドポイント、SQS など） | ファンアウト通知が得意。SQS はコンシューマがメッセージを 1 つずつ処理するワーカーパターン。SNS→複数の SQS キューへファンアウト、という組み合わせが基本パターン。 |
| Amazon SQS | 非同期処理のためのメッセージキュー | キューに溜めてワーカーで順次処理する「バッファ & 非同期化」役。Kinesis/MSK は連続ストリーム処理、SNS は通知用途。SQS は「1 メッセージ＝1 タスク」なバッチ/ジョブ向き。 |
| AWS Step Functions | サーバレスワークフロー（状態遷移図ベース） | SNS/SQS/EventBridge が「イベントやメッセージを運ぶ」のに対し、Step Functions は **「処理の順番と分岐（オーケストレーション）」**を定義。Lambda や各種サービスをつなぐ「進行役」。 |
AWS コスト管理
| サービス | 主な用途 | 同カテゴリ内での違い・使い分けポイント |
|---|
| AWS Budgets | 予算や利用量のしきい値を設定し、超過しそう／超過したらアラート | 「目標値（予算）に対する管理」。Cost Explorer が実績分析、Budgets は「超えたら通知して」の監視役。 |
| AWS Cost and Usage Report (CUR) | 最も詳細な課金明細を S3 に吐き出す | 生データ。Athena/Redshift/QuickSight でガチ分析する前提の素材。Cost Explorer はこの情報をいい感じにまとめた UI 版、とイメージすると分かりやすい。 |
| AWS Cost Explorer | コストの推移・サービス別内訳を可視化 | 管理コンソールから手軽に見る 標準分析ツール。Budgets のようにしきい値アラートは弱く、CUR のように生データでもない、ちょうど中間レイヤ。 |
| Savings Plans | 一定期間の利用コミットと引き換えに、EC2/Fargate/Lambda などの料金を割引 | 他の 3 つが「見える化／監視」なのに対し、Savings Plans は**「料金そのものを下げる契約」**。リザーブドインスタンスとの違いは柔軟さ（インスタンスタイプ変更など）と適用範囲。 |
コンピューティング（Compute）
| サービス | 主な用途 | 同カテゴリ内での違い・使い分けポイント |
|---|
| AWS Batch | バッチ／HPC ジョブをキューに投入すると、必要な EC2 を動的に起こして処理 | 「バッチ専用 ECS/EC2 オーケストレーション」のイメージ。EC2 を自前で管理する代わりに、ジョブ単位でリソースをお任せできる。Beanstalk は Web/アプリ向け、Lambda は関数単位。 |
| Amazon EC2 | 仮想サーバ。OS レベルから自由にカスタマイズ可能なコンピュート基盤 | このカテゴリの 最もベーシックな基盤。Auto Scaling は EC2 の台数調整、Beanstalk は EC2 を裏で使った PaaS、Outposts は EC2 をオンプレに持ち込むイメージ。 |
| Amazon EC2 Auto Scaling | 負荷・スケジュールなどに応じて EC2 インスタンス数を自動増減 | EC2 に対するスケール制御の仕組み。単体では何もしないので、ALB＋EC2＋Auto Scaling で Web フロントを構成、といった組み合わせで考える。 |
| AWS Elastic Beanstalk | コードを投げると、EC2/ALB/Auto Scaling などをまとめて構成してくれる PaaS | EC2 レイヤを意識したくない人向けの 「おまかせ Web/アプリホスティング」。ECS/EKS はコンテナ前提、Lambda は関数前提。Beanstalk は従来型アプリ（Java, PHP 等）に向く。 |
| AWS Outposts | AWS インフラをオンプレミスに置き、AWS と同じ API・管理モデルで利用 | 単なる VPN/Direct Connect と違い、EC2/EBS/RDS などを自社 DC 内で動かせる。レイテンシ要件やデータ所在地要件が厳しいときのハイブリッド選択肢。 |
| AWS Serverless Application Repository | Lambda ベースのサーバレスアプリを共有・再利用するためのカタログ | 計算リソースではなく、「サーバレスアプリの配布場所」。ECR がコンテナイメージ用レジストリなのに対し、Serverless App Repo は SAM/CloudFormation テンプレの集合体。 |
| VMware Cloud on AWS | vSphere, vSAN, NSX-T など VMware スタックを AWS 上でマネージド提供 | 既存の VMware ベース環境をほぼそのままクラウドに持ち込みたいときの選択肢。ネイティブ EC2 へ載せ替えるより 移行が早いが、クラウドネイティブ度は低め。 |
| AWS Wavelength | 5G キャリアのエッジロケーションにコンピュートを配置して超低遅延を実現 | 同じコンピューティングでも、Wavelength は**「モバイル端末から数 ms レベルのレイテンシ」**に特化。通常の EC2/Outposts はここまでのレイテンシ要件がないケースで使う。 |
コンテナ（Containers）
| サービス | 主な用途 | 同カテゴリ内での違い・使い分けポイント |
|---|
| Amazon ECS Anywhere | オンプレミスや他クラウド上のサーバを ECS クラスタに参加させる機能 | ECS 自体は AWS 上のコンテナオーケストレーション。**Anywhere は「場所を問わず ECS と同じ運用でコンテナを動かす」**ための拡張。EKS Anywhere/EKS Distro との違いは「ECS か Kubernetes か」。 |
| Amazon EKS Anywhere | オンプレなどで EKS と同じ運用モデルの Kubernetes クラスタを構築 | Kubernetes をオンプレにも広げたい場合の選択肢。ECS Anywhere は AWS 独自の ECS、EKS Anywhere は Kubernetes ベース。EKS（マネージド）は AWS 上でのクラスタ。 |
| Amazon EKS Distro | EKS と同じバージョン管理・コンポーネント構成の K8s ディストリビューション | EKS Anywhere が「構築ツール＋運用モデル」まで含むのに対し、EKS Distro は Kubernetes バイナリ一式。自分でクラスタ運用したいけど、EKS と互換にしたい場合に向く。 |
| Amazon ECR | コンテナイメージのプライベートレジストリ | ECS/EKS/Fargate などが pull する イメージ置き場。オーケストレーションをする ECS/EKS と役割が全く違い、「どこにイメージを置くか」の話。 |
| Amazon ECS | AWS ネイティブなコンテナオーケストレーション（タスク／サービス単位） | 制御プレーンが AWS 管理でシンプル。Kubernetes の学習コストをかけたくない場合は ECS が楽。EKS は K8s 標準エコシステムを使いたいときに選ばれる。 |
| Amazon EKS | マネージド Kubernetes クラスタ | オープンソース K8s の標準 API・ツールを使いたい場合の選択肢。ECS は AWS 独自だが簡単、EKS は標準的だがやや複雑。マルチクラウド・ポータビリティを重視するなら EKS になりやすい。 |
データベース（Databases）
| サービス | 主な用途 | 同カテゴリ内での立ち位置・使い分け |
|---|
| Amazon Aurora | MySQL/PostgreSQL 互換のクラウドネイティブ RDB | RDS よりも 高性能・高可用な商用級 RDB。既存 MySQL/PostgreSQL からの移行で、本番 OLTP の“本命候補”。 |
| Amazon Aurora Serverless | Aurora のサーバレス版。負荷に応じて自動スケール＆停止 | 常時起動が不要なワークロード向けの 可変トラフィック用 RDB。固定負荷なら通常の Aurora／RDS のほうが読みやすいことも多い。 |
| Amazon DocumentDB (MongoDB 互換) | MongoDB 互換 API を提供するドキュメント DB | JSON ドキュメント＋MongoDB エコシステム前提ならこれ。スキーマレス文書なら DynamoDB or DocumentDB、RDB なら Aurora/RDS。 |
| Amazon DynamoDB | フルマネージド NoSQL キー値／ドキュメント DB | 超スケーラブルな 低レイテンシ Key-Value ストア。複雑な JOIN/トランザクションが欲しければ Aurora／RDS、スケール優先なら DynamoDB。 |
| Amazon ElastiCache | Redis / Memcached ベースのインメモリキャッシュ | DB やアプリの前段で 読み取りを爆速化。永続保存は DB（Aurora/DynamoDB）で行い、ElastiCache は「キャッシュ層」として使う。 |
| Amazon Keyspaces (for Apache Cassandra) | Cassandra 互換のフルマネージド NoSQL | 既存 Cassandra ワークロードの移行先。Cassandra モデルに慣れているかどうかが DynamoDB との分かれ目。 |
| Amazon Neptune | グラフデータベース（ノード／エッジ格納） | ソーシャルグラフや経路探索など、グラフクエリが主役のケース用。通常のリレーショナルや Key-Value では表現しづらい関係性を扱う。 |
| Amazon QLDB | 改ざん検知可能な台帳型 DB | ブロックチェーンほど大げさにしたくないが、履歴と完全性保証が重要な台帳用途向け。普通の RDB／NoSQL と目的がかなり異なる。 |
| Amazon RDS | 各種 RDB（MySQL, PostgreSQL, Oracle, SQL Server 等）のマネージド | 汎用 RDB の第一選択肢。クラウドネイティブ性能を求めるなら Aurora、本格分析なら Redshift、NoSQL 系なら DynamoDB。 |
| Amazon Redshift | カラムナ型 DWH。分析・集計向け SQL DB | OLTP ではなく DWH 専用。トランザクション処理は Aurora/RDS、リアルタイム Key-Value は DynamoDB、バッチ分析や BI の中心は Redshift。 |
フロントエンドのウェブとモバイル
| サービス | 主な用途 | 同カテゴリ内での立ち位置・使い分け |
|---|
| AWS Amplify | フロントエンド／モバイルアプリ開発〜ホスティングの一体型プラットフォーム | React/Vue 等の SPA＋バックエンド（Cognito, AppSync, S3 等）を一気に構築したいときの フルスタック開発基盤。 |
| Amazon API Gateway | REST/HTTP/WebSocket API の入口となるマネージド API ゲートウェイ | バックエンド API の玄関。フロント側のホスティングは Amplify、GraphQL なら AppSync、REST なら API Gateway が鉄板。 |
| AWS Device Farm | 実機スマホ・タブレット・ブラウザでのテスト自動実行 | アプリ実行ではなく テスト専用サービス。CI/CD と組み合わせて、端末断面での UI テスト・回帰テストを回す。 |
| Amazon Pinpoint | メール／SMS／Push などのマルチチャネルキャンペーン配信 | 単発通知は SNS でもできるが、Pinpoint は セグメント／キャンペーン設計などマーケ用途に寄った“顧客コミュニケーション基盤”。 |
機械学習（Machine Learning）
| サービス | 主な用途 | 同カテゴリ内での立ち位置・使い分け |
|---|
| Amazon Comprehend | 感情分析・エンティティ抽出などの NLP | 文章解析が欲しいときの お手軽 API 型 NLP。モデル構築からやりたいなら SageMaker、時系列なら Forecast。 |
| Amazon Forecast | 時系列データから需要予測などを行う専用サービス | 時系列予測特化型。「売上予測」「需要予測」など典型タスクを GUI で。汎用 ML は SageMaker。 |
| Amazon Fraud Detector | 不正検知用 ML モデルを簡単に構築・運用 | クレカ不正等の 特化型 SaaS 的サービス。自前で特徴量設計〜モデル構築までやるなら SageMaker 側で。 |
| Amazon Kendra | 意味理解型の企業内検索 | 単なる全文検索(OpenSearch)より 自然文クエリに強い検索エンジン。ドキュメント検索 UX を上げたいときに。 |
| Amazon Lex | チャットボット・音声ボット（NLU＋ASR） | Bot フロントエンド。対話エンジンとしてコンタクトセンター等で使う。テキスト生成や一般 ML とは別レイヤ。 |
| Amazon Polly | テキスト読み上げ（TTS） | 文章→音声への変換。逆向き（音声→テキスト）は Transcribe、翻訳は Translate。 |
| Amazon Rekognition | 画像・動画のラベル付け／顔認識など | 画像系タスクの API ベース便利屋。より特殊な CV をやるなら SageMaker。 |
| Amazon SageMaker | ML モデルの開発・学習・デプロイの統合基盤 | このカテゴリの 汎用プラットフォーム枠。他のサービスはほぼ “用途特化の完成品”、SageMaker は自前モデル開発向け。 |
| Amazon Textract | スキャン文書からテキスト＋表・フォーム構造を抽出 | 単純 OCR 以上に、帳票としての構造を抽出。画像からの“ラベル認識”は Rekognition の領域。 |
| Amazon Transcribe | 音声→テキスト変換 | 会議録、コールログの文字起こしなど。そこから感情分析したければ Comprehend へ、翻訳したければ Translate へ。 |
| Amazon Translate | テキストの機械翻訳 | 多言語翻訳専用。文章理解は Comprehend、音声→翻訳のパイプラインなら Transcribe＋Translate＋Polly が定番。 |
コメント