AWS ETLとは？Glue・Lambda・EMRの使い分けと構成例を解説

AWSでETL処理を実装しようとしたとき、AWS Glue・Lambda・EMRのどれを選べばよいか迷うケースは少なくありません。それぞれ得意な処理規模や用途が異なるため、「とりあえずGlueを使う」という判断が後からコスト超過や性能不足につながることもあります。

サービス選定の基本軸は、データ量・処理の複雑さ・リアルタイム性・コストの4点です。数GB以下の準リアルタイム変換にはLambda、日次バッチや複数データソースの統合にはGlue、ペタバイト級の分散処理にはEMRが、それぞれ適合しやすい選択肢となります。

以降では、ETLの基本概念から各AWSサービスの特性、具体的な構成パターンまでを順に整理します。

なお、ETLをゼロから組むだけでなく、データ統合から活用までを一気通貫で進めたい場合は、GENIEE CDPのようなCDPを併用する選択肢も有効です。

ETLとは何か：Extract・Transform・Loadの3ステップ

ETLとは、複数のデータソースからデータを抽出（Extract）し、分析に適した形式へ変換（Transform）し、分析基盤へ格納（Load）する一連のデータ統合プロセスです。データ活用の土台となる工程であり、この処理なしには散在するデータを分析に使える状態にできません。

なお、似た概念としてELTがあります。ETLがロード前に変換するのに対し、ELTはデータウェアハウス（DWH）へ先にロードしてからDWH側で変換する方式です。DWHの処理能力が高い場合や大量データを扱う場合に選ばれる傾向があります。

Extract（抽出）：データソースからデータを集める

抽出ステップでは、分析に使うデータを各種データソースから収集します。対象はRDB（MySQL・PostgreSQLなど）、SaaS（Salesforce・kintoneなど）、ログファイル、REST APIなど多岐にわたり、データソースの種類によって接続方式が異なります。

抽出方式には大きく2種類あります。フルロードは全件を毎回取得する方式で、実装がシンプルな反面、データ量が増えると処理時間とコストが増大します。差分抽出（CDC：Change Data Capture）は前回取得以降に変更されたレコードのみを取得する方式で、更新頻度が高いテーブルや大規模データに適しています。データ量と更新頻度に応じてどちらを採用するかを判断することが、パイプライン設計の最初の選択肢となります。

Transform（変換）：分析に使えるデータへ加工する

変換ステップは、ETLの3工程の中で最も処理内容が多様で、サービス選定にも直結する工程です。代表的な処理としては、データ型の統一（型変換）、欠損値の補完（NULL補完）、重複レコードの排除（重複排除）、複数テーブルの結合、集計処理、個人情報の匿名化（マスキング）などが挙げられます。

変換処理が単純な型変換や文字列整形にとどまる場合と、複数テーブルの結合・集計・機械学習向けの特徴量生成まで含む場合とでは、必要な処理能力が大きく異なります。この複雑さの違いが、次章で整理するサービス選定の重要な判断軸になります。

Load（格納）：分析基盤へデータを書き込む

格納ステップでは、変換済みのデータを分析・可視化に使う基盤へ書き込みます。格納先は用途によって異なり、大量の生データや加工済みデータを低コストで保持するデータレイク（Amazon S3）、SQLによる高速な集計・分析に使うデータウェアハウス（Amazon Redshift）、アプリケーションが参照するリレーショナルDB（Amazon RDS）、BIツールへの直接連携などが代表的な選択肢です。

格納先の特性はパイプライン全体の設計に影響します。たとえばRedshiftへ格納する場合は列指向ストレージに適したデータ形式への変換が求められ、S3へ格納する場合はParquetなどの圧縮フォーマットを選ぶことで後続のAthenaクエリコストを抑えられます。

ETLとELTの違いはこの格納ステップに現れます。ETLは格納前に変換を完了させるのに対し、ELTはまずDWHへロードしてからDWH側のSQLで変換します。DWHの処理能力が高く、変換ロジックをSQLで表現できる場合はELTが有効ですが、変換処理が複雑でPythonやSparkのコードが必要な場合はETLの方が柔軟に対応できます。

AWSで使えるETLサービスの全体像

ETLの3ステップを理解したうえで、AWSにはこれを実現するサービスが複数存在します。それぞれ担う役割が異なるため、「ETL＝Glue」と単純に決めるのではなく、処理の性質に応じて使い分けることが重要です。

AWSのETL関連サービスは大きく2系統に分けられます。ETL処理そのものを担う処理系（AWS Glue・Amazon EMR・AWS Lambda）と、複数の処理ステップを連携・管理するワークフロー管理系（AWS Step Functions・Glue Workflow・Amazon MWAA）です。

これらのサービスをつなぐ共通ストレージとして機能するのがAmazon S3です。抽出したデータの一時保管、変換前後のデータ保持、格納先としての利用など、S3はETLパイプラインの中心に位置します。サービス選択の方向性はデータ量・処理の複雑さ・リアルタイム性の3軸で判断でき、詳細な基準は後の章で整理します。

AWS Glue：サーバーレスで動くETL専用サービス

AWS GlueはAWSが提供するフルマネージドのETL専用サービスです。サーバーレスアーキテクチャを採用しているため、処理クラスターのプロビジョニングや管理が不要で、ETLジョブの実装と実行に集中できます。

主要コンポーネントは4つあります。データソースのスキーマ・メタデータを一元管理するデータカタログ、データソースを自動スキャンしてスキーマを検出・更新するクローラ、PythonまたはScala/Sparkで処理を記述・実行するETLジョブ、そしてGUIでジョブを視覚的に設計できるGlue Studioです。

これらが一体となって提供されている点が、他のETL手段と比べたときのGlueの特徴です。

Amazon EMR：大規模データの分散処理基盤

Amazon EMRは、Apache SparkやHadoopなどのオープンソースフレームワークをAWS上で実行できるマネージドサービスです。ETL専用サービスではありませんが、大規模データの分散処理基盤としてETLパイプラインに組み込まれるケースが多くあります。

EMRの強みはスケーラビリティとカスタマイズ性にあります。ペタバイト級のデータ処理にも対応でき、Sparkのコードをほぼそのまま移行できるため、既存のSparkジョブをAWS上で動かしたい場合や、Glueでは対応しきれない複雑な処理が必要な場合に選ばれます。

その反面、クラスター管理やチューニングの知識が必要で、Glueと比べると運用負荷は高くなります。なお、2022年以降はクラスター管理不要の EMR Serverless も利用可能です。EMR Serverlessはワークロードに応じてリソースを自動プロビジョニング・解放するため、Glueに近い運用負荷でEMRの処理能力を活用できます。既存のSparkコードをそのまま移行したいが、クラスター管理は避けたいというケースでは、EMR Serverlessが有力な選択肢となります。

AWS Lambda：イベント駆動の軽量ETL処理

AWS LambdaはETL専用サービスではありませんが、S3へのファイルアップロードやAPI Gatewayのリクエストなどをトリガーにした小規模・準リアルタイムの変換処理に適しています。コードをデプロイするだけで実行環境が自動的に用意されるため、シンプルな変換処理であれば最も手軽に実装できます。

ただし、最大実行時間が15分という制約があります。この制限を超える処理や、大量データのバッチ処理にはLambdaは不向きです。また、メモリ上限もあるため、処理するデータ量が増えるにつれてGlueやEMRへの移行を検討する必要が出てきます。

ワークフロー管理サービス：Step FunctionsとGlue Workflow

ETL処理が複数のジョブで構成される場合、ジョブ間の依存関係・実行順序・エラー時のリトライを管理するオーケストレーション層が必要になります。AWSではこの役割を担うサービスが3つあります。

Glue WorkflowはGlueジョブ・クローラ・トリガーを組み合わせたパイプラインを管理する機能で、Glueを中心に構成する場合に最もシンプルに使えます。

AWS Step FunctionsはGlue・Lambda・EMRなど複数のAWSサービスをまたいだ処理フローを定義でき、エラーハンドリングやリトライロジックを細かく制御できます。

Amazon MWAA（Managed Workflows for Apache Airflow）はApache Airflow互換の環境をマネージドで提供するサービスで、複雑な依存関係を持つパイプラインや、既存のAirflowワークフローをAWSへ移行する場合に適しています。

AWS Glueの主要機能・料金・メリットとデメリット

AWSのETLサービスの中でも、Glueは最も選ばれやすい選択肢です。サーバーレスでインフラ管理が不要なこと、データカタログやGlue Studioなどの付随機能が充実していること、他のAWSサービスとの連携がスムーズなことが主な理由です。

ただし、DPU課金の仕組みを理解せずに使い始めると、想定外のコストが発生するリスクもあります。

Glueを導入する前に、主要コンポーネントの役割・料金体系・メリットとデメリットを把握しておくことが、後のトラブルを防ぐうえで重要です。

データカタログとクローラ：メタデータの自動管理

データカタログは、S3・RDS・Redshiftなど各種データソースのスキーマ・メタデータを一元管理する機能です。テーブル定義やパーティション情報を中央で管理できるため、Amazon AthenaやAmazon EMR、Redshift Spectrumからカタログを共有して参照できます。分析基盤全体でメタデータを統一管理できる点は、データソースが増えるほど効いてきます。

クローラはデータソースを自動スキャンしてスキーマを検出・更新する機能です。S3に新しいデータが追加されたり、RDSのテーブル定義が変更されたりした場合でも、クローラを定期実行することでカタログを最新の状態に保てます。スキーマ変更のたびに手動でカタログを更新する手間を省けるため、データソースの変更頻度が高い環境で特に有効です。

ETLジョブとGlue Studio：処理の実装方法

GlueのETLジョブは、PythonまたはScala/Sparkで変換処理を記述して実行する機能です。ジョブタイプは処理規模と用途に応じて選択します。Python Shellは軽量なPythonスクリプトを実行するタイプで、小規模な変換処理に向いています。Sparkは分散処理エンジンを使うタイプで、大規模データの並列処理に対応します。Rayは機械学習ワークロードや分散Pythonに特化したタイプです。

Glue Studioは、ビジュアルETL（ドラッグアンドドロップによるジョブ設計）、インタラクティブなノートブック開発、データ品質チェック（Glue Data Quality）を統合した開発・運用環境です。ノーコードでジョブを構成しながら、生成されたPython/Sparkコードを直接編集することもできます。また、Amazon SageMaker Unified Studioとの統合により、データエンジニアリングとML開発を一元的に管理できる環境へと進化しています。

。データソースの接続・変換処理・格納先をキャンバス上で繋いでいくだけでジョブを構成できるため、Sparkのコーディングスキルが限られたチームでも利用しやすい設計になっています。

生成されたコードはPython/Sparkとして確認・編集もできるため、ノーコードで始めてコードで細かく調整するという使い方も可能です。

料金体系：DPU課金の仕組みとコスト管理のポイント

GlueはDPU（Data Processing Unit）単位の従量課金です。現行のGlue（バージョン2.0以降）では、ワーカータイプ（G.1X・G.2X・G.4X等）とワーカー数の組み合わせで処理能力を指定します。G.1Xワーカーは4 vCPU・16 GBメモリを1単位とし、ETLジョブの実行は「DPU数 × 実行時間」で課金され、秒単位課金（最低1分）です。

ジョブが終了すれば課金も止まるため、常時稼働のサーバーを持つ必要はありません。

データカタログ自体は、カタログオブジェクト（テーブル定義・パーティション等）100万件、アクセスリクエスト100万回/月まで無料で利用できます（Always Free枠）

。ただし、ETLジョブの実行コストはDPU数と実行時間の積で決まるため、DPU数を必要以上に多く設定したままにしておくと、処理が短時間で終わっても課金が積み上がります。

コスト管理の基本は3点です。まず、ジョブに必要なDPU数を実際の処理量に合わせて適切に設定すること。次に、ジョブのタイムアウト値を設定して無限ループや想定外の長時間実行を防ぐこと。そして、クローラの実行スケジュールを必要な頻度に絞り、不要な実行を抑制することです。小規模な変換処理では、DPU課金のGlueよりもリクエスト数課金のLambdaの方がコストを抑えられる場合があります。

AWS ETLサービスの選び方：Glue・Lambda・EMRの使い分け基準

3つのサービスの特性を把握したうえで、実際の選定では「データ量」「処理の複雑さ」「リアルタイム性」「コスト許容度」の4軸で判断するのが実践的なアプローチです。どれか1つの軸だけで決めようとすると、後から別の軸で問題が出ることが多いため、4軸を組み合わせて評価することが重要です。

まず全体感を掴むために、3サービスの主要な特性を比較します。

比較項目	AWS Lambda	AWS Glue	Amazon EMR
適したデータ量	数GB以下	数GB〜数TB	数TB〜PB級
処理の複雑さ	単純な変換	標準的なETL	複雑な分散処理
リアルタイム性	イベント駆動・準リアルタイム	定期バッチ向き	定期バッチ向き
課金モデル	リクエスト数・実行時間	DPU×実行時間	インスタンス時間
インフラ管理	不要	不要	一部必要
最大実行時間	15分	最大10080分	制限なし

データ量と処理の複雑さで選ぶ

データ量と処理の複雑さは、サービス選定で最初に確認すべき軸です。

数GB以下の単純な変換処理であれば、Lambdaが最もシンプルで低コストな選択肢です。S3へのファイルアップロードをトリガーに変換処理を走らせるような用途に向いています。ただし、15分の実行時間制限があるため、処理対象のデータ量が増えてきた場合は早めにGlueへの移行を検討する必要があります。

数GB〜数TBの標準的なETL処理にはGlueが最も適合しやすい選択肢です。複数のデータソースを統合してRedshiftやS3へ格納する日次・週次バッチ処理は、Glueの典型的なユースケースです。データカタログやGlue Studioも活用できるため、開発・運用の両面でコストを抑えやすくなります。

数TB〜PB級のデータや、複雑な分散処理・機械学習前処理が必要な場合はEMRを選びます。Sparkのコードをフルカスタムできるため、Glueでは対応しきれない処理要件にも対応できます。ただし、クラスター設定やSparkチューニングの知識が必要で、Glueと比べると導入・運用のハードルは上がります。

選定時の落とし穴として、初期のデータ量見積もりが甘いケースがあります。「今は数GBだからLambdaで十分」と判断して実装したものの、半年後にデータ量が急増してGlueへの移行が必要になるというパターンは珍しくありません。将来のデータ量増加を見越した選定が重要です。

リアルタイム性とコストで選ぶ

処理のタイミング要件とコスト許容度は、データ量・複雑さと並んで重要な選定軸です。

イベント駆動・準リアルタイムの処理が必要な場合はLambdaが最適です。S3へのファイル到着・SQSメッセージ・API Gatewayのリクエストなど、様々なイベントをトリガーにして即座に処理を起動できます。定期バッチ処理であれば、GlueのスケジュールトリガーやEMRのStep実行をEventBridgeで定期起動する構成が一般的です。

コスト面では、各サービスの課金モデルの違いを理解することが重要です。Lambdaはリクエスト数と実行時間の組み合わせで課金され、無料利用枠もあるため小規模処理では最も安価になりやすいです。GlueはDPU×実行時間の課金で、処理が重くなるほどコストが増えます。EMRはクラスターを構成するEC2インスタンスの稼働時間で課金されるため、処理が終わったらクラスターを停止することがコスト管理の基本です。

処理規模に応じた試算を事前に行うことで、想定外のコスト超過を防げます。特にGlueはDPU数の設定を誤ると、処理時間が短くても課金が積み上がるため注意が必要です。

運用・開発体制で選ぶ

チームのスキルセットと運用負荷も、サービス選定に影響する現実的な軸です。技術的に最適なサービスでも、チームが運用・保守できなければ意味がありません。

インフラ管理を避けてETL専用の機能を使いたい場合はGlueが適しています。サーバーレスのためクラスター管理が不要で、データカタログやGlue Studioによって開発・運用の両面で工数を抑えやすくなります。

Spark/Hadoopの既存スキルを活かしたい場合や、細かいチューニングが必要な場合はEMRが向いています。既存のSparkコードをほぼそのまま移行できるため、オンプレミスのHadoopクラスターからの移行にも適しています。

シンプルな実装を優先したい場合や、既存のLambda関数とETL処理を統合したい場合はLambdaが選択肢になります。

AWSでのETLパイプライン構成例とワークフロー管理

サービスの選定基準を理解したうえで、実際のパイプライン構成をイメージすることが次のステップです。AWSのETLパイプラインはAmazon S3をデータレイクの中心に置き、データソース→抽出→変換→格納→分析・可視化の流れで設計するのが基本パターンです。

処理規模によって適した構成が異なります。小規模・準リアルタイムはLambda+S3、中規模バッチはGlue+S3+Athena、大規模分散処理はEMR+S3+Redshiftが典型的な構成です。ワークフロー管理にはGlue WorkflowやStep Functionsを組み合わせます。

小規模構成：Lambda + S3 によるイベント駆動ETL

小規模・準リアルタイムのETLに適した構成です。データソースからS3（生データ保管）へファイルがアップロードされると、S3イベント通知がLambdaをトリガーし、Lambdaが変換処理を実行して加工済みデータをS3の別プレフィックスへ書き込みます。その後、AthenaやAmazon QuickSightから加工済みデータを参照する流れが典型的です。

この構成の利点はシンプルさにあります。インフラの設定が少なく、S3へのファイル到着から変換完了まで数秒〜数十秒で処理できます。ただし、15分の実行時間制限があるため、1ファイルあたりの処理が長くなる場合は設計を見直す必要があります。大量ファイルの同時アップロードが発生する場合は、Lambda関数の同時実行数の上限にも注意が必要です。

中規模構成：Glue + S3 + Athena によるサーバーレスETL

日次・週次バッチ処理や複数データソースの統合に適した構成です。RDS・SaaS・ログファイルなどのデータソースからS3（データレイク）へデータを取り込み、Glue Crawlerがスキーマを自動検出してデータカタログを更新します。Glue ETLジョブが変換処理を実行して加工済みデータをS3へ書き込み、AthenaやQuickSightから参照する流れが基本パターンです。

ジョブ間の依存関係とスケジューリングはGlue Workflowで管理します。「クローラ実行→ETLジョブ実行→後続ジョブ実行」という依存関係をワークフローとして定義することで、手動での実行管理が不要になります。Amazon EventBridgeと組み合わせることで、特定の時刻や条件でワークフローを自動起動できます。

この構成はGlueのデータカタログをAthenaと共有できるため、ETL後のデータをすぐにSQLで分析できる点が強みです。Apache IcebergなどのオープンテーブルフォーマットをS3上で使う場合も、GlueとAthenaの組み合わせで対応できます。Icebergはスキーマ変更やタイムトラベル（過去時点のデータ参照）に対応しており、データレイクの柔軟性を高めます。

大規模構成：EMR + S3 + Redshift による分散処理ETL

ペタバイト級データや機械学習前処理、複雑な集計処理に適した構成です。データソースからS3（データレイク）へデータを取り込み、EMRクラスター上でSparkジョブが分散処理を実行します。加工済みデータをS3へ書き込んだ後、Redshift Spectrumで直接参照するか、COPY命令でRedshiftへロードしてBIツールから分析する流れが典型的です。

複数のEMRステップ（Sparkジョブ）のオーケストレーションにはStep Functionsが適しています。各ステップの成功・失敗を検知して次のステップへ進む制御や、失敗時のリトライ・エラー通知をStep Functionsのステートマシンとして定義できます。EMRクラスターの起動・処理実行・クラスター停止という一連の流れもStep Functionsで管理することで、処理が終わったクラスターを自動停止してコストを抑えられます。

既存のオンプレミスHadoopクラスターからの移行や、Sparkコードの再利用が必要な場合もEMRが有力な選択肢です。GlueのSparkジョブとEMRは同じSparkコードを動かせますが、EMRの方がクラスター設定やSparkバージョンの自由度が高く、細かいチューニングが必要な処理に向いています。

まとめ

AWSでETLを実現するサービスは複数ありますが、選定の判断軸は「データ量」「処理の複雑さ」「リアルタイム性」「コスト許容度」の4点に集約されます。この4軸を組み合わせて評価することで、要件に合ったサービスを選びやすくなります。

基本的な選択の方向性は、小規模・準リアルタイムはLambda、中規模バッチや複数データソース統合はGlue、ペタバイト級・高度なカスタマイズが必要な場合はEMRです。Glueを選ぶ場合は、DPU課金の仕組みを理解したうえでDPU数の設定とタイムアウト設定を適切に行うことがコスト管理の基本になります。パイプライン設計はAmazon S3をデータレイクの中心に置き、要件に応じてGlue・Lambda・EMRを組み合わせる構成から始めるのが実践的です。

実際の導入では、要件定義→サービス選定→小規模PoCによる検証→本番構築の順で進めることをお勧めします。特にPoCの段階でデータ量・処理時間・コストの実測値を取ることで、本番構築時の見積もり精度が大きく上がります。