AWS Athena の使いどころ — 「とりあえずS3に溜めたデータ、どう分析する？」問題を解決する

そもそも Athena って何者？

一言で言うと、S3に置いたファイルをそのままSQLで分析できるサービスです。

データベースサーバーを立てる必要はありません。データをどこかにロードする必要もありません。S3にあるCSVやParquet、JSONファイルに対して、直接 SELECT * FROM ... が叩けます。課金はスキャンしたデータ量に応じた従量制（1TBあたり約$5）なので、使った分だけ払えばOK。

こんな場面で使いたくなる

1. ログ分析 — 「ALBのアクセスログを調べたい」

AWSの各サービスはログをS3に出力します。ALBのアクセスログ、CloudFrontのログ、CloudTrailの監査ログなど、どれも膨大なテキストファイルです。

これをAthenaでテーブルとして定義すれば、こんなクエリが書けます。

Elasticsearch や CloudWatch Insights でも似たことはできますが、Athena は「すでにS3にあるログ」に対して追加コストほぼゼロで即座に始められるのが強みです。

2. データレイク分析 — 「とりあえず全部S3に溜めてある」

「ひとまずデータはS3に放り込んでいるけど、ちゃんと分析できていない」という状況、よくあります。Redshift や RDS に入れ直すのはコストも手間もかかる。

Athenaならスキーマを後から定義するだけで分析を始められます。ETLパイプラインが整う前の探索的分析（EDA）フェーズに特に重宝します。

3. アドホッククエリ — 「月次レポートで1回だけ集計したい」

常時稼働するデータウェアハウスを用意するほどでもない、でも手動集計は辛い——そんな「月に数回だけ走らせる集計」にAthenaはぴったりです。RDSやRedshiftなら24時間インスタンスを起動し続けるコストがかかりますが、Athenaはクエリを実行したときだけ課金されます。

4. QuickSight や他サービスとの連携

AthenaはAWSの他サービスとの親和性が高く、QuickSightのデータソースとして指定するだけでBIダッシュボードが作れます。GlueのData Catalogと組み合わせれば、クローラーが自動でスキーマを検出してくれるので、手動でテーブル定義を書く手間も減ります。

コスト削減のコツ — スキャン量を減らせ

thenaの料金はスキャンしたデータ量で決まるので、ここを工夫するとコストが大幅に変わります。

Parquet / ORC 形式を使う　CSVをそのままクエリするより、列指向フォーマットに変換するだけでスキャン量が10分の1以下になることも。

パーティションを切る　year=2024/month=01/day=15 のようなディレクトリ構造にしておき、クエリの WHERE 句でパーティションを指定すると、不要なファイルを読み飛ばせます。

SELECT * を避ける　必要な列だけ指定するのが基本です。

逆に向いていないケース

Athenaはあくまで分析用途なので、以下のような用途には向きません。

1. リアルタイムのトランザクション処理（レイテンシが秒単位なのでWebアプリのバックエンドには不向き）
2. 頻繁に更新・削除が発生するデータ（S3は追記が基本のため）
3. 毎秒のように走る高頻度クエリ（その場合はRedshiftやRDSの方がトータルコストで有利になる）