AWS Glue DataBrewとは？ノーコードのデータ準備の仕組み・料金・Glue Studioとの使い分けを実装視点で解説

分析に回す前のCSVから、欠損値を埋めて表記ゆれを揃え、型を直す。この工程をPythonのスクリプトで書いてきた現場が、画面操作で組める仕組みへ寄せられないか検討する場面があります。AWS Glue DataBrewは、その前処理をコードなしで組み立てるサーバーレスサービスです。

まとめ：DataBrewの守備範囲と料金・Glue Studioとの分岐点

AWS Glue DataBrewは、250以上の組み込み変換を画面で選んで並べ、整形手順を「レシピ」として保存できるデータ準備サービスです。クラスタの構築もサーバー管理もなく、結果はAmazon S3へ書き出されます。AWSの説明では、独自開発の前処理に比べ準備時間を最大80パーセント削減できるとされています。

設計で先に確かめるのは入出力の制約です。入力はS3、AWS Glue Data Catalog、JDBC、Amazon AppFlow、AWS Data Exchangeの5系統。ところが出力先に使えるのはS3とData CatalogとRDS経由のJDBCだけで、AppFlowとData Exchangeは指定できません。S3側もStandard・Reduced Redundancy・Standard-IA・One Zone-IAの4クラスに限られ、それ以外は黙って読み飛ばされます。

料金は2本立てです。画面で編集している間のインタラクティブセッションが30分あたり1.00ドル、ジョブ実行がノード時間あたり0.48ドル。判断で効いてくるのは、2024年7月9日にAWS Glue Studio側へノーコードのデータ準備機能が加わり、レシピをインポートできる経路が公式に用意された点でしょう。

AWS Glue DataBrewが引き受ける範囲と4つの構成要素

Pythonでの前処理スクリプトとDataBrewで分かれる担当範囲

pandasやPySparkで前処理を書く構成と比べたとき、DataBrewが肩代わりするのは4領域です。計算資源の確保と後始末、250以上の変換ロジックの実装、変換前後の差分を目視で確かめる画面、手順を記録して別データへ再適用する仕組み。テラバイト規模でもクラスタ設計は不要です。

引き受けない部分も明確です。どの列をどう直せば分析に耐えるかという業務判断、S3のバケット設計とIAMの権限設計、実行のスケジューリングと失敗時のリカバリ設計。DataBrewは「整える」工程の担当で、カタログ管理や大規模ETLジョブはAWS Glueの機能とWorkflowsの仕組みの解説で扱う本体側の守備範囲です。

データセット・プロジェクト・レシピ・ジョブという4要素の関係

DataBrewの操作は4つの概念で構成されます。データセットはデータの所在を指す定義、プロジェクトは変換を組み立てる作業場、レシピは変換手順の集まり、ジョブは処理を走らせる実行単位です。

レシピは他のデータセットへ再利用でき、バージョンとして保存されます。毎月同じ形式で届くファイルに同じ整形をかける運用では、この再利用が効く場面。抽出・変換・格納という工程全体の設計思想はETLの仕組みとELTとの違い・ツール選定の解説のとおりで、DataBrewは変換の部分を画面へ寄せた道具にあたります。

250以上の変換とレシピを再利用する仕組み・データ系統の可視化

用意されている変換は250種類以上あり、ポイント＆クリックで選びます。中身はnullの除去、欠損値の補完、スキーマの不整合の修正、関数を使った列の生成といった定番に加え、自然言語処理で文を句に分割する変換まで。異常値のフィルタリングもコードを書かずに組み合わせられます。

変換を選ぶ前段では、データ品質を評価するプロファイリングが使えます。値の分布とチャートを画面上で確認でき、見つけにくい品質の問題はDataBrew側が候補を提示。型の崩れや外れ値を先に洗い出してから手順を組む流れです。

もう1つの機能がデータ系統の可視化でしょう。データがどのソースから来て、どの変換を経てどこへ出力されたかを図として追えます。整形手順が属人化しやすい工程だけに、引き継ぎと監査の負担が下がります。

接続できるデータソースと出力先・S3ストレージクラスの制限事項

入力に使えるデータソースとJDBCで接続できるデータベース6種

データセットの入力元は5系統です。Amazon S3、AWS Glue Data Catalog、JDBCドライバ経由のデータベース、Amazon AppFlow、AWS Data Exchange。S3はフォルダのURLも指定でき、その場合は配下の複数ファイルをまたぐ1つのデータセットとして扱われます。

JDBC接続で公式にサポートされるのは6種類です。

Amazon RedshiftとSnowflake Connector for Sparkの2つだけは、単一テーブルの指定に加えて複数テーブルにまたがるSQLクエリでの定義も選べます。一覧にないJDBCドライバも、JDK 8と互換であればS3へ置いて参照できます。

Amazon AppFlowを挟めば、SalesforceやZendesk、Slack、ServiceNowといったSaaSのデータも入力にできます。ただしAppFlow側のフローの宛先がS3である必要があり、それ以外のフローはDataBrewのコンソールに表示されません。

出力先はS3中心・AppFlowとData Exchangeが使えない制約

設計時に見落としやすいのが、入力に使えるソースと出力に指定できる先が一致しない点です。レシピジョブの出力先はAmazon S3、AWS Glue Data Catalog、Amazon RDS経由のJDBCデータベースの3つに限られます。Amazon AppFlowとAWS Data Exchangeは、入力には使えても出力先には指定できません。

この制約が効くのはSaaSへ書き戻したい要件のときで、DataBrew単体では往復させられません。

Data Catalog経由で出力する場合は、テーブル側の準備も要ります。DataBrewから使うData CatalogのS3テーブルには、データ形式を示すclassificationというプロパティ（値はcsv、json、parquetのいずれか）と、typeOfDataがfileである指定が必要。付けていなければGlueのコンソールから後で追加できます。

S3ストレージクラスと空ファイルで起きる読み飛ばしの落とし穴

DataBrewが読めるS3のストレージクラスは4つだけです。Standard、Reduced Redundancy、Standard-IA、S3 One Zone-IA。これら以外のクラスのファイルは無視されます。エラーで止まらず、対象から外れて処理が進む挙動に注意が必要です。

実務で問題になるのはライフサイクルルールとの組み合わせでしょう。一定日数を過ぎたオブジェクトをGlacier系へ移す設定のバケットでは、フォルダ指定のデータセットから古い月のファイルだけが静かに抜け落ちます。件数が合わないのに例外も出ない、調査しにくい形での表面化。ストレージクラスごとの特性はAmazon S3のストレージクラスと料金の解説のとおりで、DataBrewを使う前提のバケットはルールの対象から外す運用を先に決めておきます。

0バイトの空ファイルも同様に無視されます。フォルダ単位でデータセットを作る場合は、対象になったファイル数をプロファイルジョブで確かめてから本番のレシピジョブへ進みます。

データセット作成からレシピジョブ実行までの実装手順と権限設計

データセットを作成しプロジェクト画面でレシピを組み立てる流れ

実装は5段階です。第1にデータセットを作り、S3のURLかData Catalogのテーブル、あるいはJDBC接続を指定。第2にプロジェクトを作成し、そのデータセットとIAMロールを紐づけます。プロジェクトを開くとデータがグリッド状の画面に表示され、列ごとの値の分布やチャートが見える状態に。

第3にプロファイリングでデータの傾向を掴み、第4に変換を選んでレシピのステップとして積み上げる。変換を1つ加えるたび、変換前と変換後の一部が即座にプレビューされ、全件へ適用する前に手順を直せます。

第5がジョブの実行です。組み上がったレシピを対象データ全体へ適用し、結果をS3などへ書き出します。この段階で初めてノード時間の課金が発生する点は、費用設計でも押さえたい区切りでしょう。

レシピジョブとプロファイルジョブの2種類の違いと実行時の設定

ジョブには2種類あります。レシピジョブは組み立てた変換をデータ全体へ適用して結果を出力するもの、プロファイルジョブは統計情報と品質評価だけを生成するもの。前者は成果物を作る実行、後者は状態を測る実行です。

実行時に決めるのは、出力先のパスとファイル形式、ノード数、スケジュール、使用するIAMロール。ノード数は処理時間と費用の両方に直結し、大きくすれば速く終わる代わりに単位時間あたりの課金額が増えます。分単位の課金のため、極端に大きなノード数で短時間に終わらせる構成が必ずしも安くなるとは限りません。

運用へ乗せる段では、定期実行するジョブがどのレシピバージョンを参照するかを固定します。固定しなければ、編集が意図せず本番へ反映される事故につながります。

IAMロールに必要な権限とカスタムSQLの3分タイムアウト制限

DataBrewに渡すIAMロールには、入力側S3バケットの読み取り、出力先バケットへの書き込み、Data Catalogを使う場合はGlueのテーブル参照権限が要ります。別アカウントのData CatalogにあるS3テーブルを参照する構成なら、Data Catalog側のリソースポリシーと、対象S3ロケーションの一覧取得およびオブジェクト取得の権限も必要です。

JDBC接続でカスタムSQLを使う場合は、仕様の癖を先に押さえたいところです。DataBrewはデータセット作成の時点でSQLを検証しません。クエリが渡されるのは、プロジェクトを開いたときかジョブを実行したとき。誤りのあるクエリでも作成自体は成功し、失敗するのは使用時になります。

妥当性を事前に確かめるValidate SQLの機能は、Amazon Redshiftベースのデータソースでのみ利用できます。他のデータベースでは、自分でクエリを流して確認してからデータセットを作る手順に。加えてプロジェクトで使うデータセットは、読み込み時のタイムアウトを避けるためクエリ実行時間を3分未満に抑えることが推奨されています。

DataBrewの料金体系とセッション・ジョブ費用の試算方法

インタラクティブセッションとノード時間の2本立てになる課金体系

費用は2つの軸で決まります。1つはインタラクティブセッションで、プロジェクト画面を開いてレシピを組み立てている時間に対する課金。料金ページの記載では30分あたり1.00ドルです。もう1つがジョブの実行で、DataBrewノードの時間あたり0.48ドルが基準になります。

ジョブ側は分単位で計算されます。料金ページの計算例も6分の1時間といった端数で示されており、10分で終わったジョブに1時間分が請求される仕組みではありません。環境を常時起動する型のサービスとは、費用の積み上がり方が違います。

単価はリージョンによって変わる旨がページに明記されており、アジアパシフィック（東京）の個別単価は計算例に示されていません。以下の試算は基準単価をもとにした概算です。

毎日1回のデータ準備を1か月回した場合の費用試算と削りどころ

条件を置いて概算します。レシピの組み立てに開発期間中10時間（セッション20回）、本番では5ノードのレシピジョブを1回20分、毎日1回・月30回実行するケースです。

セッション費用は20回×1.00ドルで20ドル。ジョブ費用は5ノード×3分の1時間×0.48ドルで1回あたり0.80ドル、月30回で24ドル。合計は月44ドル前後。開発が済んだ後の定常費用は24ドルだけで、セッション分は初月に寄ります。

削る余地は2か所です。1つ目はセッション時間で、プロジェクト画面を開いたまま席を離れる運用をやめるだけで直接効きます。2つ目はノード数と実行頻度。日次で回している処理が週次で足りるかを見直せば、そのまま比例して下がります。

AWS Glue Studioのデータ準備機能との違いと移行経路

Glue Studioのデータ準備レシピが2024年に加わった経緯

採用判断に直結する動きとして、2024年7月9日にAWS Glue Studio側でノーコードのデータ準備オーサリング機能が提供開始されました。数百種類の組み込み変換をコードなしで選べる機能で、提供範囲はAWS Glue DataBrewが使えるすべての商用AWSリージョンとされています。

公式の案内では、DataBrewの利用者は既存のレシピを新しいGlueのデータ準備体験へインポートするか、Glue Studioで直接作成でき、レシピをスケールアップしてペタバイト規模のデータを処理できると説明されています。

2026年7月時点で提供終了や新規受付停止の記載はない一方、公式ドキュメントに「DataBrewからGlue Studioへの移行」というチェックリストが用意されているのも事実です。

レシピをGlue Studioへ移行するときJOINとUNIONが通らない

移行の手順そのものは軽く、3段階です。まずレシピとレシピバージョン、説明を取得できるようIAMポリシーへ権限を追加。次にGlue Studio側でレシピをインポートし、最後にビジュアルエディタ上で引き継いで編集します。

ただし制約が1点あります。JOINとUNIONの変換を含むレシピはインポートに対応していません。この2つを使っている場合は、Glue Studio側のJoinとUnionの変換を、Data Preparation Recipeノードの前か後に置く形へ組み替えます。結合処理までレシピへ畳み込んでいるほど、移行時の書き換え量が増える構図です。

将来の移行可能性を残すなら、設計段階から結合をレシピの外へ出す手があります。テーブルの結合はData Catalog側かSQL側で済ませ、レシピは単一データセットの整形に絞る。この分け方なら、移行時にインポートがそのまま通ります。

DataBrewを採用してよい3条件とGlue Studioへ寄せる場面

DataBrewを採用してよい3つの条件と使える規模の下限ライン

採用してよいのは、次の3条件が揃うときです。第1に、変換の中身をエンジニア以外の担当者がレビューまたは編集する運用が実際に想定されていること。画面で組める価値は、コードを読まない人が工程に参加してはじめて回収できます。エンジニアだけで完結する体制なら、Glue ETLジョブでコード管理するほうが再現性もテスト容易性も上回るでしょう。

第2に、入出力がS3とData Catalog、あるいはRDS経由のJDBCで完結すること。第3に、結合を伴わない単一データセットの整形が処理の中心であること。JOINとUNIONをレシピに載せた瞬間、Glue Studioへの移行経路が塞がります。

規模の下限はほぼありません。分単位課金で、日次20分のジョブなら月20ドル台に収まり、小さく始めて効果を測る使い方が成立します。判断が要るのはむしろ上限側。変換が数十ステップに膨らみ、条件分岐や外部データの参照が絡み始めた段階では画面で追える範囲を超えます。ステップ数が増え続けるなら、コードへ移す時期です。

Glue Studio・Glue ETLジョブ・SQLへ寄せるべき3場面

1つ目は、これから新規に仕組みを組む場面です。2024年7月にGlue Studio側へノーコードのデータ準備機能が入り、レシピのインポート経路まで公式に用意された以上、新規案件の第一候補はGlue Studioに置くのが筋の通った判断でしょう。DataBrewを新規に選ぶ理由は、既存のレシピ資産や社内の習熟がある場合に限られます。

2つ目は、複数テーブルの結合や複雑な条件分岐が処理の中心になる場面。Glue ETLジョブでコードとして書き、バージョン管理とテストの対象にします。ジョブの依存関係を組む段はWorkflowsの領域です。

3つ目は、そもそも整形をSQLで書けてしまう場面です。S3上のデータに対する型変換やフィルタ、集計であれば、Amazon Athenaの使い方とクエリ・料金の解説のとおりクエリ1本で済むケースが少なくありません。書ける人がいるなら、ツールを1つ増やさない選択のほうが運用は軽く済みます。

データ準備の仕組みを外部へ委託するとき見積書で確認する4項目

この工程を外部へ委託する場合、見積書で確かめたい項目が4つあります。第1に、レシピの設計だけでなくIAMロールとS3バケットのライフサイクル設定まで作業範囲に入っているか。ストレージクラスの読み飛ばしは、権限とバケット設計が分離した体制で起きやすい障害です。

第2に、プロファイルジョブによる品質確認が納品物に含まれるか。件数と分布を測った記録がなければ、抜け落ちに気づく手段が残りません。第3に、レシピのバージョン管理と定期実行の手順が文書化されるか。第4に、Glue StudioやGlue ETLジョブへ移す判断基準と移行コストの見立てが示されているか。

取り込みから整形、格納、分析までを一続きで設計する話になれば、範囲は前処理ツールの選定を越えるでしょう。データ分析基盤構築・MLOps構築支援では、基盤の設計から運用体制の整備までを支援しています。どの工程をノーコードへ寄せるかの線引きから相談できます。

よくある質問

DataBrewは日本語を含むデータでも使えますか？

日本語を含むCSVやJSONも扱えます。ただし文字コードは事前確認が要り、文字化けが起きる場合はS3へ置く前にUTF-8へ揃えるのが確実。自然言語処理の変換には文を句に分割する機能がありますが、日本語で期待どおり分割されるかはプレビューで確かめてください。

東京リージョンで使えますか？料金は同じですか？

DataBrewは商用リージョンで提供されており、2024年7月のGlue Studioデータ準備機能の案内でも「DataBrewが利用できるすべての商用AWSリージョン」という表現が使われています。料金はリージョンで変わる旨が明記される一方、東京の個別単価は計算例に示されていません。30分1.00ドルとノード時間0.48ドルは基準値のため、見積もりではコンソールでリージョンを指定してください。

作成したレシピはコードとして管理できますか？

レシピは保存のたびにバージョンとして記録され、APIやCLI経由で取得できます。取得したレシピをリポジトリへ格納する運用は組めるものの、Gitでの差分レビューを前提とした開発フローと噛み合うかは別問題。プルリクエストで変換ロジックをレビューする文化があるなら、最初からGlue ETLジョブのコードとして持つほうが素直です。

既存のAWS Glue ETLジョブと組み合わせられますか？

組み合わせられます。出力先がS3とData Catalogに対応しているため、整えた結果をカタログへ登録し、後段のGlue ETLジョブやクエリサービスから参照する構成が可能。逆に、Glueのクローラーでカタログ化したテーブルをDataBrewのデータセットにする経路も使えます。その場合もclassificationとtypeOfDataの指定が要ります。

DataBrewは今後も提供され続けますか？

2026年7月時点で、AWSの製品ページと開発者ガイドに提供終了や新規受付停止のアナウンスは掲載されていません。既存環境が急に止まる状況ではないでしょう。一方、同等のノーコード機能がGlue Studio側に用意され、移行チェックリストが整備されているのも事実。新規構築ではGlue Studioのデータ準備を第一候補に置き、DataBrewを選ぶ場合もレシピにJOINとUNIONを含めない設計にすると移行が軽く済みます。

関連記事

• データレイクとは？データウェアハウス・レイクハウスとの違いを実装視点で解説：整えたデータの置き場所の設計を扱います
• AWS Lake Formationとは？データレイクの権限管理・使い方・料金と実装判断を解説【2026年版】：Data Catalogの権限設計と併せて読めます
• Amazon QuickSightとは｜サーバーレスBIの機能・SPICE・料金・実装と採用判断を解説：整えた後の可視化手段を比較できます
• Amazon Redshiftとは？特徴・料金・使い方とアーキテクチャを実務目線で解説：JDBC接続先の代表格を詳しく扱います
• データ分析基盤の構築とは？5層アーキテクチャとBigQuery実装手順を技術視点で解説：前処理を含む基盤全体の設計を整理しています