AWS Glueとは｜ETLとデータカタログの仕組み・Athena連携の使い方

AWS Glueとは何をするサービスか

結論から言えば、Glueは「散らばったデータを、分析できる状態に整えるための一式」です。単体のETLツールという説明は、現在の機能範囲に対してやや狭すぎます。

AWSのAWS Glue 公式ドキュメントでは、Glueの機能は次の3カテゴリに整理されています。

サーバーレスなので、EC2インスタンスやSparkクラスタそのものを立てて管理する必要はありません。ここがAmazon EMRとの一番わかりやすい違いです。ただし「運用不要」という意味ではなく、IAMの権限設計、VPC接続、S3のパス設計、ジョブ設定やワーカー数の調整は利用側の仕事として残ります。

「ETLツール」と呼ぶには広すぎる

Glueは、ETLもELTもストリーミングも1つのサービスで扱います。カタログ機能を持っている点も、一般的なETLツールの範囲を超えています。

実務では、Glueの機能のうちData Catalogだけを使い、変換処理は別のツールに任せる構成もよく見かけます。たとえば変換はdbtとは｜データ変換(ELT)の仕組み・使い方・案件単価で解説しているdbtに寄せ、オーケストレーションはApache Airflowとは｜DAGの仕組み・dbt/Dagsterとの違い・案件単価のAirflowに任せる、といった分担です。

Glueを使わない選択肢もある

データ量が小さく、変換もほとんど不要なら、Glueのジョブを書くより素直にLambdaで処理したほうが速いケースもあります。AWS Lambdaとは？特徴・できること・料金・フリーランス案件の単価をエンジニア視点で解説で触れているとおり、小さい処理の実行単位としてはLambdaのほうが軽量です。

判断の目安は「Sparkの分散処理が要るか」です。数GB程度までの単純な整形で、Lambdaの実行時間・メモリ・一時ストレージの制限に収まる処理なら、Glueジョブを立てるメリットは薄くなります。逆に、処理時間が読めない、ファイル数が多い、結合や集計が重い、といった条件が重なるならGlue側が候補になります。

ミニFAQ：GlueはAWS環境でしか使えない？

ジョブの実行環境はAWS上ですが、AWS Glue 公式ドキュメントでは、オンプレミスを含む70を超えるデータソースへの接続に対応すると説明されています。VPC接続を設定すれば、社内のRDBMSからS3へ吸い上げるパイプラインも組めます。

AWS Glueの主要コンポーネント

Glueを理解するときの近道は、コンポーネントごとに「何の役割か」を切り分けることです。全部を同時に使う必要はありません。

Data Catalog（メタデータの一元管理）

Data Catalogは、データの場所・スキーマ・パーティション情報を保持するメタデータストアです。実データは保持しません。中身はS3やRDSに置いたまま、「どこに何があるか」だけをカタログが持ちます。

重要なのは、このカタログがGlue専用ではない点です。Athena、Amazon EMR、Redshift Spectrumが同じカタログを参照します。Hiveメタストアの代替として使える、と理解しておくと腹落ちしやすいでしょう。

アクセス制御をテーブル単位・列単位まで細かく掛けたい場合は、AWS Lake Formationを重ねます。Lake FormationはData Catalogに対する認可レイヤーという位置づけです。カタログ運用そのものの実務や案件の内容はデータガバナンス案件の単価相場｜データカタログ実務と探し方・参入ルートで扱っています。

クローラー（スキーマの自動推論）

クローラーは、指定したデータストアをスキャンしてスキーマを推論し、Data Catalogにテーブル定義を作成・更新するコンポーネントです。

便利ですが、クローラーは万能ではありません。後述の「よくある失敗」で触れるとおり、設定を詰めずに動かすとテーブルが乱立します。日付のように規則的なパーティション構造で、将来とりうる範囲まで定義できる場合は、クローラーを回すよりAthena側のパーティション射影（Partition Projection）で済ませたほうが、カタログ更新の運用を減らせることがあります。構造が不規則なデータには向きません。

ETLジョブ（Spark／Spark Streaming／Python shell）

これから新規に作るジョブについては、主にSpark・Spark Streaming・Python shellの3タイプを押さえておけば足ります（Ray実行環境の現状は後述します）。

Python shellは分散処理をしません。「Glueジョブ＝Spark」と思い込んでいると、小さな処理にまでSparkのオーバーヘッドを払うことになります。

Glue Studio・ノートブック・インタラクティブセッション

Glue Studioは、変換フローをGUIで組み立ててコードを自動生成するエディタです。Sparkを書いた経験がなくても、取り込み・結合・書き出しの基本形は作れます。

一方で、手を動かして試しながら書きたい場面ではインタラクティブセッションやジョブノートブックが使えます。ジョブを毎回サブミットして結果を待つ開発サイクルは効率が悪いので、検証段階ではセッション側を使うのが定石です。

DataBrewとの使い分け

AWS Glue DataBrewは、コードを書かずにデータをクレンジング・正規化するビジュアルツールです。アナリストやビジネス側のユーザーを想定しています。コードレビューやCI/CD、処理の再利用性を重視するエンジニア主導の定常パイプラインでは、DataBrewよりGlue Studioやスクリプトのほうが扱いやすいケースがあります。一方、非エンジニアが前処理を自走する体制ならDataBrewが適することもあります。

GlueとAthenaはどう組み合わせるのか

ここが「Glue Athena」で検索される最大の論点です。短く言えば、Glueが準備、Athenaが分析。そしてその接点がData Catalogです。

役割分担の対応表

AthenaでCREATE TABLEを実行すると、その定義はGlue Data Catalogに書き込まれます。逆にGlueのクローラーが作ったテーブルは、そのままAthenaから見えます。2つのサービスが同じカタログを読み書きしている、という構造です。

最小構成は3段階で動く

最小構成は「S3に置く → Glueでカタログ登録 → Athenaでクエリ」の3段階です。実際の作業では、クローラーの設定と結果確認を含めて次の流れになります。IAM権限とサンプルデータが用意済みで、Athenaのクエリ結果保存先も設定済みであれば、慣れている人なら30分から1時間程度で一巡できます。

1. S3バケットにデータを置く（CSVでもJSONでも可）。AWS S3とは｜オブジェクトストレージの仕組み・料金・案件単価をフリーランスエンジニア視点で解説の基本構成で足ります

2. Glueでデータベースを作り、対象パスにクローラーを設定する

3. クローラーを実行し、Data Catalogにテーブルが作られたことを確認する

4. Athenaのクエリエディタで、そのテーブルにSELECTを投げる

5. 結果が返ったら、Parquet変換とパーティション設計に進む

ETLジョブは4の時点では不要です。まずカタログとクエリを通し、必要になってから変換ジョブを足す。この順番で進めると、無駄なジョブを作らずに済みます。

変換が必要になるのはどの時点か

CSVのままAthenaで分析を続けると、スキャン量が増えてクエリ単価が効いてきます。ここでGlueのETLジョブ、またはAthenaのCTASでParquetへ変換する流れになります。

テーブルフォーマットにIcebergを選ぶ場合は、Apache Icebergとは｜テーブルフォーマットの仕組みと案件要件の整理が参考になります。2026年11月7日時点の公式ドキュメントでは、Glue 5.1系にIceberg 1.10.0、Glue 6.0にIceberg 1.11.0が同梱されています。

ミニFAQ：Athenaだけで完結させることはできる？

できます。Athenaのクエリエディタからテーブルを定義し、CTASで変換すれば、Glueのジョブを使わずに分析基盤を回せます。Glueが必要になるのは、定期実行のパイプラインを組みたいときと、Athenaだけでは手に負えない変換処理が出てきたときです。

バージョンと実行環境（2026年11月7日確認）

Glueはジョブ単位でバージョンを指定します。ここを把握していないと、公式ドキュメントのサンプルが手元で動かない、という事故が起きます。以下は2026年11月7日時点でAWS公式ドキュメントに掲載されている内容です。Glueはバージョン更新とサポート方針の変更が比較的多いサービスのため、移行を判断する際は対象リージョンと最新の公式ページを必ず再確認してください。

バージョン対応表

AWS Glue バージョン一覧から、2026年11月7日時点で公開されている内容を整理しました。

Glue 0.9・1.0・2.0は、バージョンサポートポリシーにあるとおり2026年4月1日にサポート終了しています。保守案件でこれらが残っている場合は、参画前にアップグレード計画の有無を必ず確認してください。古いバージョンが動いていること自体は珍しくありませんが、Spark 2.4系やPython 3.7系のままだと依存ライブラリのEOLと併発している可能性があります。

なお、Glue 5.0ではGlueContextベースのLake Formationテーブル単位アクセス制御が使えなくなり、Sparkネイティブのきめ細かなアクセス制御（FGAC）に置き換わりました。4.0から5.0への移行で詰まりやすい箇所です。

Glue for Rayは新規受付を終了している

2026年11月7日時点の公式ドキュメントAWS Glue for Ray end of supportでは、Glue for Rayは2026年4月30日をもって新規のお客様向けの提供を終了したと案内されています。既存ユーザーは引き続き利用できますが、セキュリティと可用性の改善を除き、新機能の追加予定はないとされています。代替としてAWSが案内しているのはAmazon EKS上でKubeRayを使う構成です。

「GlueはSparkとRayから選べる」という説明は、これから新規に始める人にとってはもう当てはまりません。

ワーカータイプの選び方

SparkジョブのG系ワーカーでは、1 DPU＝4 vCPU／16GBメモリが基準単位です。ワーカータイプによってメモリ比率や利用できる条件は異なるため、単純換算できる前提では考えないほうが安全です。ジョブプロパティの設定から主要なワーカータイプを抜き出しました。

R系の詳細なvCPU・メモリ・ディスク構成と提供リージョンは変動しうるため、ここでは用途のみ整理しています。選定時は公式のジョブプロパティのページで確認してください。

迷ったらG.1Xから始めるのが無難です。公式もG.1Xを「大半のジョブに対してスケーラブルでコスト効率の良い選択肢」と位置づけています。OutOfMemoryで落ちる場合は、いきなりG.8Xへ飛ぶ前に、まずSpark UIでデータスキューとシャッフル量を確認し、パーティション設計・ワーカー数・ワーカータイプの順に見直すのが安全です。原因がスキューであればワーカーを増やしても解消しません。

タイムアウトの既定値はバージョンで異なります。Glue 4.0以前は2,880分、Glue 5.0以降は480分。上限はどちらも7日（10,080分）です。意図せず長時間走って課金が膨らむのを避けるため、ジョブごとに妥当な値を明示的に設定しておきたいところ。

料金の考え方とコスト削減の定石

Glueの課金

以下は2026年11月7日時点でAWS Glue 料金ページに表示されている代表例です。同ページにも「料金は AWS リージョンによって異なります」と明記されているとおり、金額はリージョンごとに違い、改定もあります。見積もり時は必ず利用リージョンを選択して最新の表示を確認してください。

カタログだけなら、小〜中規模では実質無料枠に収まります。コストが出るのはジョブとクローラーの実行時間です。

Athenaの課金

2026年11月7日時点のAmazon Athena 料金ページによると、SQLクエリはスキャンしたデータ量に対して5 USD／TBと表示されています（リージョンにより異なります）。注意点として、成功したクエリだけでなく失敗したクエリも課金対象です。フェデレーテッドクエリにはクエリあたり10MBの最低課金があります。

公式ページには、3:1の圧縮率でParquetへ変換し、かつ1列だけを読む場合に「圧縮で3倍、列指向の読み取りで4倍」の節約となり、15 USDのクエリが1.25 USDになる例が示されています。

コストを下げる4つの手順

1. Parquetなどの列指向フォーマットへ変換する。効果が最も大きく、最初に着手すべき項目です

2. パーティションを切る。日付など、WHERE句で必ず絞る軸をパーティションキーにします

3. **SELECT * をやめる**。列指向フォーマットの恩恵は、読む列を絞って初めて出ます

4. Flex実行クラスを使う。緊急でないジョブ（検証・一時的なロード）向けで、Glue 3.0以降のG.1XとG.2Xで利用できます

ミニFAQ：クローラーのコストが無視できない規模になった

パーティションが日々増えるテーブルでクローラーを毎日フル実行すると、スキャン対象が線形に増えます。新規パーティションのみをクロールする設定に変えるか、パーティション射影へ切り替えるのが対策です。射影ならカタログへのパーティション登録自体が不要になります。

他サービスとの使い分け

DWH側をRedshiftにするか他を選ぶかは別の判断軸です。Amazon Redshiftとは｜BigQueryとの違い・案件単価を解説で整理しています。

ケース別：どの構成から始めるか

ケース1：まずアドホック分析をしたい

S3＋クローラー＋Athenaの3点で十分です。ETLジョブは作りません。Parquet化はAthenaのCTASで対応できます。この構成なら、Data Catalogのオブジェクト数とリクエスト数が無料枠に収まる限り、常時発生する費用はS3のストレージ料金が中心で、あとはクローラーとクエリの実行分だけになります。

ケース2：日次バッチのパイプラインを組む

GlueのSparkジョブを足し、トリガーかStep Functionsでスケジュールします。ジョブブックマークを有効にして、処理済みデータの再処理を避けます。ワーカーはG.1Xから始め、実行時間を見ながら調整するのが安全。

ケース3：準リアルタイムで取り込みたい

Spark Streamingジョブを使い、ワーカーはG.025Xから検討します。ただしストリーミングは監視と再処理の設計が一気に重くなるため、バッチで要件を満たせないかを先に検討するほうが結果的に早いケースが多いでしょう。

よくある失敗と対策

クローラーがテーブルを乱立させる

同一パス配下にスキーマの異なるファイルが混在していると、クローラーがテーブルを分割して作ることがあります。対策は、クロール対象のパス設計を先に決めること。1テーブル＝1プレフィックスを徹底し、スキーマ変更時の挙動（更新するか無視するか）もクローラー設定で明示します。

小さいファイルが大量にできてジョブが遅い

Sparkの出力をそのまま書くと、パーティションごとに細かいファイルが量産されます。読み取り側のオーバーヘッドが効いてきて、Athenaのクエリも遅くなる。書き出し前にリパーティションするか、定期的なコンパクションを仕込みます。

ジョブブックマークを「冪等性の保証」と誤解する

ジョブブックマークは処理済みデータの状態を記録する機能で、トランザクション的な保証ではありません。ジョブが途中で落ちた場合の挙動は設計次第です。また、セルレベルフィルタが設定されたLake Formation管理テーブルにアクセスするジョブでは、ジョブブックマークやプッシュダウン述語がサポート対象外になります。

Athenaのコストが想定外に膨らむ

原因の大半は、パーティションを切っていないテーブルへのフルスキャンです。ワークグループ単位でクエリあたりのスキャン量上限を設定しておくと、事故を金額で止められます。失敗したクエリにも課金される点を踏まえると、上限設定は早い段階で入れておきたい防御策。

導入チェックリスト

案件で既存のGlue環境を引き継ぐとき、または新規に組むときに確認する項目です。

• Glueのバージョンはいくつか（4.0以前なら、Spark／Pythonのバージョン差と移行計画を確認する）

• Glue 0.9・1.0・2.0が残っていないか（サポート終了済み）

• Data CatalogはGlue専用か、AthenaやEMRからも参照されているか

• Lake Formationによる認可が入っているか（入っている場合、5.0移行でFGACへの切り替えが必要になる）

• クローラーの実行頻度とクロール対象範囲（フル実行になっていないか）

• 主要テーブルがParquetなどの列指向になっているか、パーティションキーは何か

• ジョブのタイムアウト値が明示設定されているか（未設定だとバージョン依存の既定値になる）

• ワーカータイプとワーカー数の根拠が残っているか

• Flex実行クラスを適用できる非緊急ジョブがないか

• ジョブブックマークの有効／無効と、再実行時の手順が文書化されているか

案件でGlueに触れる場面

フリーランス向けの公開案件を見る限りでは、Glueは「Glue専任」ではなく、データ基盤案件の構成要素の1つとして要件に並ぶことが多い技術です。S3、Athena、Redshift、Airflowなどと併記されるケースが目立ちます。

任されやすい作業としては、既存パイプラインの改修、クローラーとカタログの整備、ジョブのコスト最適化、旧バージョンからの移行あたり。ゼロからの基盤設計より、すでに動いているものの改善や移行のほうが入り口としては一般的です。

職種としての全体像はデータエンジニアとは？仕事内容・年収・将来性をわかりやすく解説にまとめています。レイヤー別の単価の目安はデータ基盤案件の単価相場｜ETL・DWH・BIレイヤー別の目安とスキル、AWS全般の単価レンジはAWSエンジニア フリーランスの単価相場｜経験・案件レイヤー別に解説で扱っているため、本記事では数値には踏み込みません。

案件を実際に見たい場合は、AWS案件の一覧から要件を確認できます。自分の経歴でどのくらいの単価を狙えるか知りたい方は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。複数案件から選ぶときの優先順位の付け方は案件の選び方｜フリーランスエンジニアが単価・稼働・スキルで決める優先順位が参考になります。

まとめ

AWS Glueは「データを整える側」、Athenaは「整ったデータに問い合わせる側」であり、両者はGlue Data Catalogを共有することでつながります。ここさえ押さえれば、構成の選択はほとんど迷いません。

• Glueの中核はData Catalog・クローラー・ETLジョブの3点。全部を同時に使う必要はない

• 立ち上げはS3→クローラー→Athenaの順。ETLジョブは必要になってから足す

• 2026年11月7日時点では、バージョン未指定のジョブはGlue 5.1が既定。0.9・1.0・2.0は2026年4月1日にサポート終了済み

• 同じく2026年11月7日時点で、Glue for Rayは2026年4月30日に新規受付を終了したと案内されている。代替はEKS＋KubeRay

• 課金はGlueがDPU時間、Athenaがスキャン量。削減策はParquet化とパーティション設計が中心

• 既存環境を引き継ぐときは、バージョン・Lake Formationの有無・クローラーの実行範囲を最初に確認する

次のステップとしては、検証用のS3バケットを1つ作り、クローラーからAthenaのSELECTまでを一度通してみるのが早いはずです。カタログの無料枠に収まる規模なら、試すコストはほぼかかりません。

参照した一次情報は以下のとおりです。

• AWS Glue とは（AWS 公式ドキュメント）

• AWS Glue バージョン一覧

• AWS Glue バージョンサポートポリシー

• AWS Glue for Ray end of support

• Spark ジョブのジョブプロパティの設定

• AWS Glue の料金

• Amazon Athena の料金

• Athena のパーティション射影