分析基盤を任されると、Athena・Redshift・EMR・Glue が並んで出てきます。どれも「データを分析するサービス」に見えるため、どれがクエリ用で、どれが変換用で、選ぶと何を自分で運用することになるのかを言葉にできないまま、名前の印象で決めてしまいがちです。この記事では、4 つを役割で 2 つに分け、要件から選ぶ軸を整理します。
この記事の結論
- Glue は変換とカタログを担う「作る側」です。Athena と Redshift は SQL で答える側、EMR は自前のコードで大規模処理をする側です。
- たまに・アドホックに S3 を引くなら Athena です。サーバーを持たずに始められます。
- 多数のソースを集めて結合の多いクエリを日常的に回すなら、データウェアハウスの Redshift が向きます。
- Spark などを自前のコードで細かく制御したいなら EMR です。ただし決める設定と持つものが増えます。
- 実務では組み合わせます。同じ S3 と Glue Data Catalog を、Athena・EMR・Redshift Spectrum が共有できます。
- 判断軸は「クエリの頻度と形」「データの構造」「運用で持てる範囲」「コストの出方」の 4 つです。
分析サービスの選び方は何を軸にするのか
最初にやることは、サービスの名前を並べることではなく、役割で 2 つに分けることです。
- クエリを受ける側（答える側）: Amazon Athena、Amazon Redshift。人や BI ツールが SQL を投げ、結果を返します。
- データを作る側（用意する側）: AWS Glue（変換とカタログ）、Amazon EMR（自前のコードによる大規模処理）。生のデータを分析しやすい形に整えます。
この区別だけで、「Glue でクエリを引こうとする」「Athena で重い変換を回そうとする」といった種類違いの選択を避けられます。Glue が提供する Data Catalog は、表の名前と列の定義を持つ台帳で、答える側のサービスがここを参照します。データレイクとして S3 に置く形そのものは「データレイクとは」の記事で扱っているので、ここでは触れません。
READ ALSO — 実務向け・段3 基盤
データレイクとは何か｜S3・Glue Data Catalog・Athena の基本形と、データウェアハウスとの違い
そのうえで、選ぶときに見る軸は 4 つです。
| 軸 | 問い |
|---|---|
| クエリの頻度と形 | たまにか、毎日か。単純な絞り込みか、結合の多い集計か |
| データの構造 | S3 のファイルのままか、複数のソースを集めて整理し直すか |
| 運用で持てる範囲 | クラスターやノードの構成を自分で決めて持てるか |
| コストの出方 | クエリごとに払うか、確保した計算資源に対して払うか |
料金の具体額は変わるので、この記事には書きません。比較するときは公式の料金ページで、自分のクエリ量を置いて試算してください。
WHICH ENGINE頻度と形で選ぶ
クエリの頻度と形で、答える側を選ぶ
クエリの形
たまに × 単純 → Athena
S3 を直接引く。運用なし
日常 × 結合が多い → Redshift
多ソースを集めた定常クエリ
たまに × 結合が多い → Athena から
頻度が増えたら Redshift を足す
自前コードで制御 → EMR
Spark などの構成を自分で決める
クエリの頻度
Athena を選ぶのはどんなときか
Amazon Athena は、S3 に置いたデータを SQL で直接分析できるサーバーレスのクエリサービスです。クラスターを用意せず、S3 のデータと Data Catalog の表定義があればクエリを投げられます。
向くのは次のような場面です。
- 月に数回、調査や集計のために S3 のログや CSV を引きたい（アドホックな分析）
- 分析用の専用基盤を作る前に、まずデータの中身を確かめたい
- 運用担当を置けない、または置きたくない
選ぶ理由は「何も運用しなくて済む」ことと「始めやすい」ことに尽きます。データを別の場所へロードし直さなくても、置いてある場所のまま引けます。
一方で、Athena は S3 のファイルを読んで答えます。ファイルの形式やパーティションの切り方がクエリの効率とコストを左右します。このスキャン量の仕組みは別の記事にまとめているので、そちらに送ります。
READ ALSO — 実務向け・段3 基盤
Athena のクエリが S3 を読む仕組み｜パーティション・列指向形式・スキャン量で「速さと料金」が決まる理由
CHECK 1ここまでの確認
月に数回、S3 に溜まったログを SQL で調べたいだけのとき、最初に検討するのはどれか?
答えと解説
答え: 1. Amazon Athena
Athena は S3 のデータを直接 SQL で引け、サーバーを持たずに始められます。「Athena を選ぶのはどんなときか」の章を読み直してください。
Redshift を選ぶのはどんなときか
Amazon Redshift は、大量の構造化データに複雑な分析クエリを回すためのデータウェアハウスで、ペタバイト規模までを対象にしたマネージドサービスです。構成には、容量を確保して使う provisioned と、Serverless があります。
向くのは次のような場面です。
- 業務データベースや各種ログなど、多数のソースを一か所に集めて分析したい
- テーブル同士の結合が多い集計を、日常的・定常的に回す
- 同じ集計を BI ツールから繰り返し呼ぶ
データウェアハウスは、分析クエリが速く返るようにデータを整理して持つ設計です。複雑な結合を日常的に回す用途では、この整理が効いてきます。そのぶん、データを取り込む工程（ロード）と、テーブル設計をどうするかを考える責任が生まれます。分散や並び順の細かい設計はこの記事では扱いません。
また、Redshift に全部を置く必要はありません。直近の使用頻度が高いデータは Redshift に、年に数回しか使わない古い履歴は S3 に置いたまま、Redshift Spectrum の外部テーブルとして参照する、という分担ができます。ロードせずに参照できるので、まれにしか触らない履歴のために Redshift の容量を使わずに済みます。
CHECK 2ここまでの確認
多数のソースを集め、結合の多い集計を毎日定常的に回す場合、中心に置く候補はどれか?
答えと解説
答え: 1. Amazon Redshift
複雑な結合を日常的に回す用途はデータウェアハウスである Redshift の得意分野です。「Redshift を選ぶのはどんなときか」の章を確認してください。
EMR と Glue は何を担うのか
ここからは、答える側ではなく「作る側」です。
Amazon EMR：自前のコードで大規模処理する
Amazon EMR は、Hadoop や Spark などのフレームワークを動かすマネージドなクラスタープラットフォームです。処理の中身を自分のコードで書き、クラスターの構成も自分で決めたい場合に向きます。
- 既存の Spark / Hadoop の資産をそのまま動かしたい
- フレームワークの設定や拡張を細かく制御したい
自由度が高い反面、ノードの構成や設定を決める責任が増えます。クラスター管理をしたくない場合は、サーバーレスで Spark を動かせる EMR Serverless という選択肢もあります。使っていない時間のクラスターを持ち続ける無駄を避けたいときの見直し先になります。
AWS Glue：サーバーレスの ETL とカタログ
AWS Glue は、データを抽出・変換・ロード（ETL）する処理をサーバーレスで実行できるサービスです。あわせて、表の定義を持つ Data Catalog も提供します。
- 形式の違うデータを整えて S3 に書き出す（スケジュール実行もできる）
- クローラーで S3 のデータからスキーマを推定し、Data Catalog に表として登録する
Glue は「答える」サービスではありません。Athena や Redshift Spectrum が読む表を整え、Data Catalog に登録する、データの用意役です。
Glue と EMR の選び分け
どちらも変換処理ができるため迷いやすいところです。目安は次のとおりです。
- 構成を持たずに ETL を回したい、カタログも一緒に欲しい → Glue
- 自前のフレームワークの制御や既存資産の持ち込みが必要 → EMR
Glue で足りる処理に EMR を選ぶと、持たなくてよい構成を持つことになります。
CHECK 3ここまでの確認
Spark のコードを自分で書いて、処理の構成まで細かく制御したいときに向くのはどれか?
答えと解説
答え: 2. Amazon EMR
自前のコードとフレームワークを制御したいなら EMR です。ただし構成を決める分、持つものが増えます。「EMR と Glue は何を担うのか」の章に戻ってください。
組み合わせ方：S3 と Data Catalog を共有する 3 つの型
実務では 1 つに絞らず、S3 を土台にして Data Catalog を共有する形が基本です。Glue Data Catalog を共通のメタデータストアにすると、Athena・EMR・Redshift Spectrum が同じ S3 のデータを同じ表定義で読めます。サービスごとにテーブル定義を持つと、列を足したときに食い違いが出るため、定義を一か所に寄せる意味があります。
SHARED FOUNDATION共有する土台
土台はS3 と Data Catalog、上に変換と答える側を足す
Athena 中心
- Amazon S3 — データそのものの置き場
- Glue Data Catalog — 表と列の定義を一か所で持つ
- Glue / EMR — データを整える（作る側）
- Athena / Redshift — SQL で答える（答える側）
Redshift 中心
- Amazon S3 — データそのものの置き場
- Glue Data Catalog — 表と列の定義を一か所で持つ
- Glue / EMR — データを整える（作る側）
- Athena / Redshift — SQL で答える（答える側）
EMR 中心
- Amazon S3 — データそのものの置き場
- Glue Data Catalog — 表と列の定義を一か所で持つ
- Glue / EMR — データを整える（作る側）
- Athena / Redshift — SQL で答える（答える側）
自分で決めて持つ層サービスが担う層
代表的な組み合わせは 3 つです。
- S3 + Glue + Athena: Glue で整えたデータを、Athena で必要なときに引く。始めやすく、運用が軽い
- S3 + Glue + Redshift（+ Spectrum）: 日常の集計は Redshift で、まれに使う履歴は S3 に置いたまま Spectrum で参照する
- S3 + EMR + Athena / Redshift: 自前のコードで大規模に加工した結果を S3 に出し、答える側から引く
どの型でも「データは S3、表定義は Data Catalog」が共通の土台です。誰がどの列を読めるかという権限の設計は、次の記事で扱います。
READ ALSO — プロフェッショナル向け・段4 設計
AWS Lake Formation とは何か｜データレイクの権限を列・行・タグで一元管理し、IAM との分担を説明する
CHECK 4ここまでの確認
Athena・EMR・Redshift Spectrum から同じ S3 のデータを同じ表定義で読ませたいとき、共通に置くものは?
答えと解説
答え: 2. AWS Glue Data Catalog
Data Catalog を共通のメタデータストアにすると、表定義を一か所で持てます。「組み合わせ方」の章を読み直してください。
要件から選ぶ判断表
ここまでを、要件から引ける表にまとめます。
| 要件 | 向く選択 | 持つもの | コストの出方 |
|---|---|---|---|
| たまに・アドホックに S3 を引く | Athena | ほぼ無し（表定義とクエリ） | クエリに対して払う形。公式の料金ページで確認 |
| 多ソースの結合が多い定常クエリ | Redshift | ロードの工程とテーブル設計 | 確保した計算資源に対して払う形。Serverless もある。公式の料金ページで確認 |
| 自前の Spark で細かく制御したい | EMR | クラスターの構成と設定 | 使った資源に対して払う形。公式の料金ページで確認 |
| 形式の違うデータを整え、カタログを作る | Glue | ジョブとカタログの定義 | ジョブの実行に対して払う形。公式の料金ページで確認 |
ATHENA VS REDSHIFT答える側の違い
Athena は運用なしで始め、Redshift は定常の結合に備える
Athena
S3 を直接引く
- 持つもの：表定義とクエリ
- 向く要件：アドホックな分析
- コスト：クエリに対して払う形
Redshift
整理して持つ
- 持つもの：ロードとテーブル設計
- 向く要件：多ソース・結合の多い定常クエリ
- コスト：確保した計算資源に対して払う形
よくある選び間違いと見直しの合図
選び間違いは、たいてい要件ではなくサービス名の印象から始まります。
| 選び間違い | 見直しの合図 | 見直し先 |
|---|---|---|
| 毎日の定常集計を、毎回 Athena で重い結合のまま回している | 同じ結合のクエリが繰り返され、遅さや費用が気になってきた | 日常分は Redshift に置く |
| まれにしか見ない古い履歴まで Redshift にロードしている | 使われない履歴が容量とロードの手間を占める | S3 に置いたまま Spectrum で参照する |
| Glue で足りる ETL のために EMR を常時起動している | 使っていない時間のクラスターの費用が目立つ | Glue、または EMR Serverless |
| サービスごとに表定義を作っている | 列を足すたびに食い違いが出る | Glue Data Catalog に寄せる |
迷ったら、S3 に置いて Athena から始め、クエリの頻度と結合が増えたら Redshift を足す、という順が無理のない進め方です。最初から全部を揃える必要はありません。
Cloudory 執筆者（AWS 認定 全冠）
「Athena か Redshift か」は二者択一の問いではなく、置き場（S3）と台帳（Data Catalog）を共通にしたうえで、答える側を足していく順番の問いです。最初の一歩を軽くしておけば、後から役割を足すときの手戻りが小さくなります。
参照ソース
- Amazon Athena ユーザーガイド：Athena・EMR・Redshift の使い分け — 3 サービスの使い分けの考え方の根拠
- Amazon Redshift 管理ガイド — ペタバイト規模のマネージドなデータウェアハウスであること、Serverless と provisioned の構成の根拠
- Amazon EMR 管理ガイド：What is Amazon EMR? — Hadoop や Spark を動かすマネージドクラスタープラットフォームであることの根拠
