Amazon Athena（アテナ）とは？仕組み・使い方・料金・クエリの書き方とRedshiftとの違いを解説

Amazon Athena（アテナ）は、Amazon S3に保存したデータに対して標準SQLで直接クエリを実行できる、AWSのサーバーレス分析サービスです。サーバーやデータベースを事前に用意する必要がなく、テーブル定義をしてSQLを書くだけで、すぐに分析を始められます。本記事では、Athenaの仕組み・基本的な使い方・クエリの書き方・料金体系、そして混同しやすいAmazon Redshiftとの違いまでを、実例を交えて整理します。

まとめ

Amazon Athena（アテナ）は、S3のデータを置いたまま標準SQLで分析できる、サーバーレスのクエリサービスです。準備の手間がなく、スキャン量に応じた従量課金で始められるため、ログ解析やアドホックなデータ探索に適しています。コストと性能はスキャン量で決まるため、Parquetなどの列指向フォーマット・圧縮・パーティション設計でスキャン量を抑えることが、Athenaを使いこなす最大のポイントです。大規模で反復的なDWH処理にはRedshiftを組み合わせるなど、用途に応じた使い分けを検討してみてください。

Amazon Athena（アテナ）とは

読み方は「アテナ」。AWSが提供するインタラクティブなクエリサービスで、最大の特徴はサーバーレスである点です。クラスターやサーバーを起動・管理する必要がなく、S3上のCSV・JSON・Parquet・ORCといったファイルに、そのままSQLを投げて結果を得られます。利用した分（スキャンしたデータ量）だけ課金されるため、使っていないときにコストは発生しません。

内部のクエリエンジンはオープンソースの分散SQLエンジンTrino（旧PrestoSQL）をベースにしており、2022年10月以降の「エンジンバージョン3」では、ANSI SQLへの準拠強化や多数の関数追加、クエリ性能の向上が図られています。テーブルのメタデータ（スキーマ）はAWS Glueデータカタログで管理します。アドホックな集計やログ解析を、準備の手間なく素早く行いたい場面に向いたサービスです。

Amazon Athenaの仕組み（S3・Glue・Trino）

Athenaは「データの保存場所（S3）」「メタデータ（Glueデータカタログ）」「クエリエンジン（Trino）」の3つを組み合わせて動きます。データはS3に置いたまま動かさず、Athenaがクエリ実行時に必要な範囲だけをスキャンして結果を返します。

クエリを投げると、Athenaはまずスキーマ（どのS3パスに、どんな列構成のデータがあるか）をGlueデータカタログから読み取り、Trinoエンジンが分散処理でS3上のファイルをスキャンします。このとき、列指向フォーマット（Parquet／ORC）を使うと必要な列だけを読み込めるため、スキャン量が減り、速度とコストの両方が改善します。スキーマ管理の中核を担うのがAWS Glueで、列指向フォーマットの詳細はParquet形式の解説記事、エンジンのベースである分散SQLエンジンはTrinoの解説記事もあわせてご覧ください。

Amazon Athenaの使い方（基本の3ステップ）

初めてAthenaを使うときの流れはシンプルです。

ステップ1：S3にデータとクエリ結果の保存先を用意する

分析対象のデータをS3バケットに置きます。あわせて、Athenaのクエリ結果を出力するためのS3バケット（結果の保存先）を設定します。初回はこの結果出力先の指定が必要です。

ステップ2：テーブルを定義する（スキーマ作成）

S3上のデータ構造に合わせてテーブルを定義します。手動でDDL（CREATE EXTERNAL TABLE）を書く方法のほか、Glueクローラーに自動でスキーマを推定させる方法もあります。

ステップ3：SQLでクエリを実行する

テーブルを作成したら、あとは標準SQLで分析するだけです。クエリ結果は画面に表示され、CSVなどの形式でS3にも保存されるため、BIツールや他サービスとの連携も容易です。

Amazon Athenaのクエリの書き方【実例】

ここでは、実務でよく使うSQLの型を具体例で示します。Athenaは標準SQLに準拠しているため、SQLの基礎があればすぐに書き始められます。

テーブルを作成する（CREATE EXTERNAL TABLE）

S3上のJSONログを読むテーブルの例です。LOCATIONでデータのあるS3パスを指定します。

CREATE EXTERNAL TABLE access_logs (
  request_time string,
  user_id     string,
  region      string,
  status      int
)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
LOCATION 's3://your-bucket/access-logs/';

条件を絞って抽出する（SELECT / WHERE）

必要な列だけを選び、WHEREで対象を絞り込むのがコスト削減の基本です。

SELECT user_id, region, status
FROM access_logs
WHERE region = 'ap-northeast-1'
  AND status >= 400;

集計する（GROUP BY）

SELECT region, COUNT(*) AS error_count
FROM access_logs
WHERE status >= 500
GROUP BY region
ORDER BY error_count DESC;

パーティションでスキャン量を抑える（パーティション射影）

日付などでS3のフォルダを分け、パーティションとして扱うと、WHEREで指定した範囲だけをスキャンできます。CloudTrailなどのログ解析では特に効果的です。

CREATE EXTERNAL TABLE events (
  event_name string,
  user_id    string
)
PARTITIONED BY (dt string)
STORED AS PARQUET
LOCATION 's3://your-bucket/events/'
TBLPROPERTIES (
  'projection.enabled' = 'true',
  'projection.dt.type' = 'date',
  'projection.dt.range' = '2025-01-01,NOW',
  'projection.dt.format' = 'yyyy-MM-dd',
  'storage.location.template' = 's3://your-bucket/events/${dt}/'
);

SELECT event_name, COUNT(*) AS cnt
FROM events
WHERE dt = '2026-06-15'
GROUP BY event_name;

集計結果を別テーブルに保存する（CTAS）

CTAS（CREATE TABLE AS SELECT）を使うと、集計結果をParquet形式で保存し直して、次回以降のスキャン量を減らせます。

CREATE TABLE daily_summary
WITH (format = 'PARQUET')
AS
SELECT dt, region, COUNT(*) AS cnt
FROM events
GROUP BY dt, region;

Amazon Athenaの料金体系とコスト最適化

Athenaの基本はスキャンしたデータ量に応じた従量課金です。東京リージョンの場合、スキャンしたデータ1TBあたり5 USDが目安で、クエリごとに最小10MB分が課金されます。CREATEやALTERなどのDDL、パーティション管理、失敗したクエリには課金されません。ただし、実行を途中でキャンセルしたクエリは、キャンセル時点までにスキャンしたデータ量に応じて課金される点には注意が必要です。

コストを抑える要点は「スキャン量を減らす」ことに尽きます。具体的には、(1)ParquetやORCなど列指向フォーマットで保存する、(2)GZIP・Snappyで圧縮する、(3)日付などでパーティション分割しWHEREで絞る、(4)SELECT *を避け必要な列だけを取得する、の4点が効果的です。なお料金は変動するため、最新の正確な金額は必ずAWS公式の料金ページで確認してください。

効果をイメージしやすいよう具体例で見てみましょう。1 TBのCSVファイルに対して全列を読むSELECT *を実行すると、1 TB分（東京で約5 USD）がそのまま課金されます。一方、同じデータをParquetに変換し、日付でパーティション分割したうえで必要な列だけを取得すれば、実際にスキャンされるのは100 GB程度まで減り、課金は約0.5 USDに下がります。データの持ち方を変えるだけで10倍前後のコスト差が生まれるため、データ量が増えるほど、フォーマット変換とパーティション設計の効果は大きくなります。Athenaのコストは「クエリの回数」よりも「1回あたりのスキャン量」で決まる、と覚えておくとよいでしょう。

Amazon AthenaとAmazon Redshiftの違い

どちらもS3のデータを分析できますが、設計思想が異なります。Athenaは「サーバーレスで、S3のデータを置いたままアドホックに分析する」サービス、Redshiftは「クラスター（またはServerless）にデータを集約し、大規模・反復的なデータウェアハウス処理を高速に行う」サービスです。

まれにしか実行しないログ集計やデータ探索ならAthena、毎日大量の構造化データを処理する基幹的なBI・DWH用途ならRedshiftが向いています。両者は併用も可能です。Redshiftの詳細はAmazon Redshiftの解説記事を参照してください。

Amazon Athenaの主なユースケース

Athenaが特に活躍するのは、S3にたまっていく大量のログやイベントデータを、必要なときだけ分析する用途です。

• ログ解析：CloudTrail、VPCフローログ、ALB／WAFのアクセスログなどをSQLで横断的に調査する。
• クリックストリーム分析：Webサイトの行動ログから流入・離脱・コンバージョンを集計する。
• IoTデータ分析：センサーデータをS3に蓄積し、稼働状況や異常をクエリで確認する。
• BIとの連携：Amazon QuickSightなどのBIツールから、Athena経由でS3のデータを可視化する。

Amazon Athenaの注意点・デメリット

便利な一方で、性質を理解せずに使うと想定外のコストや性能問題につながります。

• スキャン量で課金される：SELECT *やフルスキャンを多用すると料金が膨らみます。列指向化・圧縮・パーティション設計が前提です。
• スキャン以外の費用に注意：大量の小さなファイルをクエリすると、S3へのリクエスト料金やデータ転送料がスキャン料金を上回ることがあります。
• リアルタイム／低レイテンシ用途には不向き：1件ずつの高頻度な更新・参照（OLTP）には向かず、ミリ秒単位の応答が必要な処理には別サービスが適します。
• 大規模・反復処理はRedshiftが有利：継続的に大量データを処理する定常ワークロードでは、DWH型のRedshiftのほうが効率的な場合があります。

Amazon Athenaの最新動向（2026年時点）

現在のAthenaはエンジンバージョン3（Trinoベース）が標準で、ANSI SQL準拠の強化や性能改善が進んでいます。データレイク向けのオープンテーブルフォーマットへの対応も拡充され、Apache Iceberg（参照・更新・削除に対応）、Apache Hudi、Linux Foundation Delta Lake（エンジンv3で参照に対応）を扱えます。

また、SQLのほかにApache Sparkを使った分析（Athena for Apache Spark）や、従量ではなく時間単位の定額で処理能力を確保するプロビジョニング容量も選べます。S3以外のデータソースに対しては、AWS Lambdaのコネクタを介した横串検索（Federated Query）でDynamoDBやリレーショナルデータベースなどにSQLでアクセスできます。各機能の対応状況やリージョンは更新されるため、利用前に公式ドキュメントで最新情報を確認することをおすすめします。

よくある質問（FAQ）

Amazon Athenaの読み方は？

「アテナ」と読みます。ギリシャ神話の女神アテナに由来する名称ですが、本サービスはAWSのデータ分析用クエリサービスです。

Athenaの料金はどれくらい？

東京リージョンでスキャン量1TBあたり約5 USDが目安です。少量のデータを対象にしたクエリなら、1回あたりの費用はごくわずかで済みます。最新の金額はAWS公式の料金ページで確認してください。

AthenaとRedshiftはどちらを使うべき？

準備なしでアドホックにS3のデータを分析したいならAthena、毎日大量の構造化データを高速・反復的に処理する基幹DWH用途ならRedshiftが向いています。

AthenaとGlueの関係は？

AWS Glueのデータカタログが、Athenaのテーブル定義（スキーマ）の保管先（メタストア）として使われます。GlueでスキーマやETLを整え、Athenaでクエリする、という役割分担になります。

料金を抑えるコツは？

Parquet／ORCでの列指向保存、圧縮、パーティション分割、必要な列だけのSELECTが基本です。スキャン量を減らすほど料金も下がります。

Athenaでリアルタイム分析はできる？

Athenaは事前のサーバー準備なしにS3のデータを集計・分析する用途に向いており、1件単位の高頻度な更新・参照（OLTP）やミリ秒単位の応答が必要なリアルタイム処理には向きません。ためたログをSQLで後から分析する「アドホック分析」「バッチ的な集計」が得意分野です。低レイテンシが必要な場合は、用途に応じて別のデータベースサービスと組み合わせることを検討してください。

関連記事

• Amazon Redshiftとは？データウェアハウスとしての概要と基本機能
• Trinoとは何か？その概要と基本的な特徴について
• Parquet形式とは？特徴と利用シーンを詳しく解説
• AWS Glueのワークフローとは何か？その概要と基本的な仕組み
• Apache Icebergの概要と基本的な定義