Amazon Athena の仕組みとメリット ── S3 データをサーバーレスで分析する

本記事では、S3 上のデータをそのまま SQL で分析する Amazon Athena について解説します。 S3 に蓄積されたデータへの SQL クエリ実行、Redshift・Glue との使い分け判断、そしてスキャン量を抑えるコスト最適化の方法を順に整理します。 Athena の仕組みを把握して、用途に合ったデータ分析基盤を選択しましょう。

Athena の位置付け ── S3 上のデータをサーバーレスで分析するクエリエンジン

Amazon Athena は、Amazon S3 に保存されたデータを標準 SQL で直接分析できるインタラクティブクエリサービスです。「データを S3 に置いたまま、ストレージとコンピュートを切り離してクエリ時だけ計算する」 ── この設計選択が、サーバーレス・スキャン量課金・パフォーマンス特性のすべての出発点になっています。

AWS 公式ドキュメントの定義では、Athena は「S3 上の非構造化・半構造化・構造化データを分析するためのクエリサービス」と位置付けられています。データを Athena にロードする必要はなく、S3 上のファイルに対してそのままクエリを実行できます。

この設計のおかげで、S3 に蓄積されたログや CSV を 分析のためだけにデータウェアハウスへ取り込む必要がなくなります。一方で、後述するスキャン量課金やフォーマット最適化の重要性は、同じ設計選択の裏側として現れます。

主なユースケース ── ログ分析からコスト分析まで

AWS 公式ドキュメントが挙げる Athena の主なユースケースを以下に示します。

1. アドホッククエリと探索的分析
S3 に蓄積されたデータに対して、インフラを用意せず即座に SQL で問い合わせたい場面です。新しいデータセットの中身を確認したり、仮説を素早く検証したりする用途に適しています。

2. ウェブ/アプリケーションログの分析
CloudFront や ALB のアクセスログは S3 に直接出力されます。Athena を使えば、これらのログに対してクエリを実行し、エラー率や遅延の原因を素早く特定できます。

3. AWS コスト・使用状況レポートの分析
AWS Cost and Usage Report (CUR) を S3 に出力し、Athena でクエリを実行する構成は AWS 公式が推奨するパターンです。コスト分析のためだけにデータウェアハウスを起動する必要がありません。

4. ETL 前の検証とサンプリング
Glue ETL ジョブを実行する前に、入力データの品質や件数を確認する目的にも使えます。加工処理の前段として、Athena でデータの中身を確認する流れは実務でよく見られます。

5. QuickSight との連携によるダッシュボード
Amazon QuickSight のデータソースとして Athena を指定し、S3 上のデータを可視化するパターンです。Redshift や RDS を用意しなくても、S3 データのダッシュボードを構築できます。

仕組みの核心 ── Trino エンジンと Glue Data Catalog の連携

クエリエンジンの基盤

Athena のクエリエンジンは、オープンソースの分散 SQL エンジン Trino / Presto をベースに構築されています。

現行のエンジンバージョン 3 は、Trino と Presto 両方の OSS から継続的インテグレーション方式で機能を取り込む方針へ転換しています。旧バージョン 2 (Presto ベース) と比較して、パフォーマンスと SQL 関数が拡張されています。

v2 から v3 への主な変化は次のとおりです。

エンジン v3 は v2 のすべての機能を内包しています。既存のワークグループで v3 に移行する際は、一部のクエリ構文に破壊的変更が含まれます。例として GROUP BY の入れ子カラムへのダブルクォート必須化があるため、移行前に動作確認を行うことを推奨します。

Glue Data Catalog との連携

Athena がクエリを実行する際、テーブルのスキーマ情報 (列名・データ型・S3 パス) を AWS Glue Data Catalog から参照します。Glue Data Catalog はメタデータストアとして機能し、Athena はその情報をもとに S3 上の実データを読み込みます。

テーブルの作成手順は次のとおりです。まずデータを S3 に配置し、Glue クローラーでスキーマを自動検出するか、Athena の DDL で手動定義します。以下のコードは動作未確認の例です。

-- テーブル手動定義の例
CREATE EXTERNAL TABLE access_logs (
  request_time STRING,
  http_method  STRING,
  request_uri  STRING,
  status_code  INT,
  bytes_sent   BIGINT
)
ROW FORMAT DELIMITED
FIELDS TERMINATED BY '\t'
LOCATION 's3://my-bucket/access-logs/'
TBLPROPERTIES ('skip.header.line.count'='1');

テーブルを定義したら、通常の SQL と同じ構文でクエリを実行できます。

-- ステータスコード別のリクエスト数を集計する例
SELECT
  status_code,
  COUNT(*) AS request_count
FROM access_logs
WHERE request_time LIKE '2026-05-%'
GROUP BY status_code
ORDER BY request_count DESC;

Athena は S3 上のデータを直接読み込みます。WHERE 句の条件によりスキャン範囲が変わりますが、パーティションを設定していない場合は全ファイルを読み込むため注意が必要です (詳細は「スキャン量を膨らませる落とし穴」のセクションで説明)。

対応データフォーマット

Athena は以下のフォーマットを読み込めます。

コスト最適化の観点では、Parquet または ORC への変換が最も効果的です。列指向フォーマットは特定列のみを読み込む述語プッシュダウンに対応しており、CSV と比較してスキャン量を大幅に削減できます。

他サービスとの使い分け ── Redshift / BigQuery / Glue との違い

S3 のデータを分析する手段は Athena だけではありません。Athena の「ストレージを S3 に置く」設計に対し、他のサービスは異なる設計選択を持ち、それが用途の違いとして表れます。

実務では、データの置き場所・クエリ頻度・インフラ管理の可否という 3 点を出発点に考えると判断が絞りやすくなります。

• Athena を選ぶ場合: S3 上のデータにインフラ不要で SQL を実行したい。アドホックな分析やログの探索が主な用途。クエリ頻度が低く、常時起動のコストを避けたい。
• Redshift を選ぶ場合: 複数システムのデータを統合した DWH が必要。複雑な JOIN や高同時実行のレポーティングが主な用途。データを長期間構造化して蓄積したい。
• Glue を選ぶ場合: データの変換・クレンジング・移動が目的。ETL パイプラインとしての用途。スキーマ自動検出やデータカタログ管理が必要。
• BigQuery を選ぶ場合: すでに Google Cloud 環境を使っているか、Google Analytics 4 など Google サービスとのデータ連携が主目的。

BigQuery との課金モデルはどちらもスキャン量課金ですが、データの保管場所が異なります。BigQuery はデータを BigQuery のストレージに取り込んで管理するモデルのため、S3 から BigQuery へのデータ移動コストが発生します。

一方 Athena は S3 上のデータをそのまま参照するため、すでに S3 を使っている AWS 環境なら追加のデータ移動なしに導入できます。

東京リージョンの料金とスキャン量を抑える運用

Athena の「S3 に置いたデータをクエリ時だけ読み込む」設計は、スキャン量課金とフォーマット選択を運用側に移したトレードオフでもあります。料金の基本構造と、スキャン量を膨らませる典型的な落とし穴を整理します。

料金の基本構造

Athena のオンデマンド料金は スキャンしたデータ量に対して課金されます。東京リージョン (ap-northeast-1) の標準的な単価は $5.00 / TB スキャン (約 800 円 / TB、1 USD = 160 円換算、2026-05-04 確認) です。最新の正確な値は 公式料金ページ で確認してください。

課金の単位は 1 TB で、最低課金量は 10 MB です。10 MB 未満のスキャンでも 10 MB 分の料金が発生します。

DDL クエリ (CREATE TABLE, ALTER TABLE, DROP TABLE) はスキャンを伴わないため無料です。また、Athena 自体に無料枠は設定されていません。

コスト試算例

数値は概算です (1 USD = 160 円換算、2026-05-04 確認)。実際のスキャン量はデータの圧縮率・クエリのフィルタ条件によって変動します。

スキャン量を膨らませる落とし穴

1. CSV のままにしておくとスキャン量が肥大化する

CSV は行指向フォーマットです。3 列中 1 列だけ取り出すクエリでも、全列のデータを読み込みます。同じデータを Parquet に変換するだけでスキャン量を大幅に削減できます。

Athena の公式ベストプラクティスでは、CSV から Parquet への変換に CTAS (Create Table As Select) を使う方法が推奨されています。以下のコードは動作未確認の例です。

-- CSV データを Parquet に変換して新テーブルとして保存する例
CREATE TABLE access_logs_parquet
WITH (
  format = 'PARQUET',
  parquet_compression = 'SNAPPY',
  external_location = 's3://my-bucket/access-logs-parquet/'
)
AS SELECT *
FROM access_logs;

変換後のテーブルに対してクエリを実行することで、スキャン量の削減効果を確認できます。

2. パーティション未設定による全スキャン

パーティションとは、S3 上のデータを year=2026/month=05/ のようなフォルダ構造で分割し、Athena がクエリの WHERE 条件に基づいてスキャン対象を絞り込める仕組みです。

パーティションを設定していないと、WHERE request_time = '2026-05-03' のような日付条件を指定しても、S3 上の全ファイルをスキャンします。大量データに対してこの状態でクエリを実行すると、意図せず高額な課金が発生することがあります。

パーティション構成のテーブル定義例を示します。

-- パーティション付きテーブルの定義例
CREATE EXTERNAL TABLE access_logs_partitioned (
  http_method STRING,
  request_uri STRING,
  status_code INT
)
PARTITIONED BY (
  year  STRING,
  month STRING,
  day   STRING
)
STORED AS PARQUET
LOCATION 's3://my-bucket/access-logs-parquet-partitioned/';

パーティション付きテーブルを作成しただけでは、Glue Data Catalog にパーティション情報は登録されていません。新しいパーティションが追加されたら、S3 上のパーティション構成を Glue Data Catalog に一括登録するコマンドを実行します。

-- S3 上の新しいパーティションを Glue Data Catalog に一括登録する
MSCK REPAIR TABLE access_logs_partitioned;

MSCK REPAIR TABLE は S3 上の新しいパーティションフォルダを検出して、Glue Data Catalog のメタデータに一括反映するコマンドです。実行を忘れるとクエリが新しいデータを返さないため、パーティション追加時の運用フローに組み込む必要があります。Glue クローラーを再実行することでも同じ効果が得られます。

パーティションの追加・削除が頻繁に発生する場合は、パーティションプロジェクション機能の利用を検討してください。DDL でパーティション範囲を宣言しておくだけで、Athena が自動的にパーティションを算出し、Glue への手動登録が不要になります。

3. Glue Data Catalog との連携で発生しやすい問題

Glue クローラーを使うと、S3 上のファイルを自動スキャンしてスキーマを検出できます。ただし、クローラーの設定で除外パターンを指定しても、Athena はその除外設定を認識しません。例えば、同一バケットに CSV と JSON が混在している場合、JSON を除外するクローラー設定を入れても、Athena は両方のファイルをスキャン対象とします。

また、Glue クローラーがデータの型を誤推定するケースがあります。特に CSV の場合、数値列が string として登録されるなど、型の不一致によるクエリエラーが発生することがあります。テーブル定義を手動で修正するか、型変換を含む DDL で再作成することで対処できます。

4. クエリのタイムアウト上限

Athena の DML クエリ (SELECT, CTAS, INSERT INTO) にはタイムアウト上限があります。デフォルト値はリージョンごとに異なりますが、Service Quotas コンソールから増加申請することで、最大 240 分まで引き上げられます。複雑な集計や大量データへのクエリが長時間実行される場合は調整してください。

クエリ実行後の Athena コンソールには「スキャンされたデータ量」が表示されます。この値を確認しながらフォーマット変換とパーティション設計を調整することが、コスト管理の第一歩です。

まとめ ── 設計選択とその表裏

Amazon Athena の本質は 「データを S3 に置いたまま、ストレージとコンピュートを切り離してクエリ時だけ計算する」設計選択 にあります。サーバー管理不要というメリットも、CSV のままだと課金が膨らむリスクも、同じ設計の表裏として現れます。

Redshift は内部ストレージに取り込んで複雑な JOIN を高並列に処理する設計、Glue は ETL を別プロセスに切り出す設計と、目的別に設計選択が異なります。

Athena を選ぶなら、Parquet 変換とパーティション設計の 2 施策が、設計のメリットを引き出してリスクを抑えるための具体的な運用作業になります。

参考文献

• What is Amazon Athena? — Amazon Athena 公式ドキュメント
• When should I use Athena? — Amazon Athena 公式ドキュメント
• Athena engine version 3 — Amazon Athena 公式ドキュメント
• Upgrade to Athena engine version 3 to increase query performance and access more analytics features — AWS Big Data Blog
• Use columnar storage formats — Amazon Athena 公式ドキュメント
• Partition your data — Amazon Athena 公式ドキュメント
• Service Quotas — Amazon Athena 公式ドキュメント
• Amazon Athena Pricing

Author

tgeas

大阪の SIer 勤務。Google Cloud Partner Top Engineer 2026 / 2025 JAPAN All AWS Certification Engineers。インフラ・ネットワークからデータ活用と生成 AI 活用支援まで幅広く対応。

profile