はじめに
AWS Solutions Architect Associate (SAA) の学習中に整理した Athena / Redshift / Glue / EMR / QuickSight / OpenSearch などの分析サービスの知識をまとめました。
「S3 上のデータにどうやって SQL クエリするか」「リアルタイム検索に何を使うか」「MPP + サーバーレスは？」など、サービス選択の問題が頻出です。
本記事は個人の学習ノートをベースにしています。誤りがあればコメントでご指摘いただけると助かります。
サービス概要
分析 / ML 関連サービスの比較
| サービス | タイプ | MPP | サーバーレス | SQL ベース ML |
|---|---|---|---|---|
| Redshift Serverless | DWH | ✅ | ✅ | ✅（Redshift ML） |
| Redshift（プロビジョニング） | DWH | ✅ | ❌ | ✅ |
| Athena | クエリエンジン | △ | ✅ | △（Athena ML） |
| RDS / Aurora | OLTP DB | ❌ | △ | △（Aurora ML） |
| EMR | ビッグデータ処理 | ✅ | △ | ❌（コード必要） |
| OpenSearch | 検索 / 分析 | - | △ | - |
S3 データへの SQL クエリ方法
| 方法 | サーバーレス | データ移動 | コスト | メンテナンス |
|---|---|---|---|---|
| Athena | ✅ | 不要 | 最低（スキャン量課金） | 最小 |
| Redshift | ❌ | 必要 | 高い | 高い |
| Redshift Spectrum | ❌（クラスタ必要） | 不要 | 中 | 中 |
| EMR + SparkSQL | ❌ | 必要 | 中〜高 | 高い |
S3 上のデータに最もコスト効率よくクエリするなら Athena です。
検索 / 分析サービス
| サービス | リアルタイム検索 | 全文検索 | 主な用途 |
|---|---|---|---|
| OpenSearch | ✅ | ✅ | ログ分析、リアルタイム検索 |
| Athena | ❌（バッチ） | ❌ | S3 アドホッククエリ |
| Redshift | ❌（DWH） | △ | 大規模分析（OLAP） |
| DynamoDB | ❌ | ❌ | Key-Value |
Athena
- S3 上のデータに直接 SQL クエリ
- サーバーレス（インフラ管理不要）
- 従量課金（スキャンデータ量のみ）
- 圧縮形式（Parquet、ORC）を直接クエリ可能
Glue
- サーバーレス ETL
- スキーマ変換には使えない（DMS の SCT を使う）
AI / ML サービスの対象データ型
| サービス | 対象 | 用途 |
|---|---|---|
| Textract | ドキュメント（PDF、画像） | OCR、テーブル・フォーム抽出 |
| Comprehend | テキスト | 感情分析、エンティティ抽出 |
| Rekognition | 画像・動画 | 顔認識、物体検出 |
| Transcribe | 音声 | 音声 → テキスト変換 |
| Translate | テキスト | 翻訳 |
| SageMaker | 任意 | カスタム ML モデル |
試験で問われる設計パターン
サービス選択系
サーバーレス + MPP + SQL ベース ML → Glue + Redshift Serverless + Redshift ML
シナリオ: データの ETL、大規模分析、SQL での ML モデル構築をすべてサーバーレスで実現したいです。どの構成が最適でしょうか？
正解: AWS Glue → Redshift Serverless → Redshift ML
- Redshift Serverless = MPP サーバーレス
- Redshift ML = SQL で ML モデル（Python コード不要）
- Athena は MPP ではない
- RDS / Aurora は OLTP
S3 上のデータに SQL クエリ + コスト効率 + メンテナンス最小 → Athena
シナリオ: S3 に保存されたデータに SQL でアドホッククエリしたいです。コスト効率とメンテナンスの手間を最小にする方法は？
正解: Amazon Athena
- サーバーレス、データ移動不要
- Redshift / EMR / RDS はデータ移動 + インフラ管理が必要
Redshift コールドデータ + SQL クエリ維持 + コスト最小 → S3 Standard-IA + Athena
シナリオ: Redshift に保存されている30日以上アクセスのないコールドデータのコストを削減したいです。SQL クエリは引き続き必要です。
正解:
- 30日後に S3 Standard-IA に移動
- Athena で分析
- Redshift にストレージクラスの概念はない
- Glacier は即時クエリ不可
リアルタイム分析系
リアルタイム検索 + 分析プラットフォーム → Kinesis + OpenSearch + QuickSight
シナリオ: ストリーミングデータをリアルタイムで検索・分析し、ダッシュボードで可視化したいです。
正解: Kinesis Data Streams → OpenSearch → QuickSight
- OpenSearch = リアルタイム検索 + 分析
- Athena はバッチクエリ
- DynamoDB は全文検索に対応していない
リアルタイムストリーミング分析パイプライン → Kinesis + Data Analytics + Firehose + S3
シナリオ: ストリーミングデータをリアルタイムで SQL 分析し、結果を S3 に保存したいです。
正解: Kinesis Data Streams → Kinesis Data Analytics → Kinesis Data Firehose → S3
- Data Analytics がリアルタイム SQL 分析を担当
- Athena はバッチクエリ
- QuickSight は Kinesis Data Streams をソースとして直接使用できない
データレイク系
データレイクのコスト最適化 → Raw: Glacier Deep Archive / Refined: 圧縮形式
シナリオ: データレイクの Raw Zone（5年間の保持義務）と Refined Zone（アドホッククエリ用）のコストを最適化したいです。（2つ選択）
正解:
- Raw Zone を1日後に Glacier Deep Archive
- Refined Zone を Glue ETL で圧縮形式（Parquet / ORC）に変換
- Athena は圧縮形式を直接クエリ可能
おわりに
分析サービスの選択は「S3 にクエリ → Athena」「MPP + サーバーレス → Redshift Serverless」「リアルタイム検索 → OpenSearch」「ETL → Glue」という判断パターンで整理できます。特に Athena の「サーバーレス + スキャン量課金 + データ移動不要」という特徴は、コスト最適化の問題で非常に高い頻度で問われます。
間違いや補足があればぜひコメントで教えてください。