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

分析に回す前のCSVから、欠損値を埋めて表記ゆれを揃え、型を直す。この工程をPythonのスクリプトで書いてきた現場が、画面操作で組める仕組みへ寄せられないか検討する場面があります。AWS Glue DataBrewは、その前処理をコードなしで組み立てるサーバーレスサービスです。本記事では守備範囲と料金に加え、AWS Glue本体との切り分け、AWS CLIで動かす手順、Glue Studioへの移行で詰まる箇所までを実装の順序で並べます。

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

AWS Glue DataBrewは、250以上の組み込み変換を画面で選んで並べ、整形手順を「レシピ」として保存できるデータ準備サービスです。クラスタの構築もサーバー管理もなく、結果はAmazon S3へ書き出されます。AWS Glue DataBrew開発者ガイドの概要では、独自開発の前処理に比べ準備時間を最大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ドル（AWS Glueの料金ページの記載、2026年9月時点）。判断で効いてくるのは、2024年7月9日にAWS Glue Studio側へノーコードのデータ準備機能が加わり、レシピをインポートできる経路が公式に用意された点でしょう。ただしインポートに対応しない変換が6つあり、そこが移行コストを分けます。

AWS Glueの構成要素の中でDataBrewが受け持つ工程を切り分ける

Data CatalogとクローラーとETLジョブが分担する役割

DataBrewの位置づけを掴むには、AWS Glueという名前が指す範囲を先に分解したほうが早い。AWS Glue開発者ガイドのコンセプト解説は、主要コンポーネントとしてData Catalog、クローラー、ETLジョブ、トリガーの4つを挙げています。Data Catalogはテーブル定義とジョブ定義を保持するメタデータストア、クローラーはデータストアへ接続してスキーマを推論しカタログへ登録するプログラム。ETLジョブはApache Sparkのスクリプトで変換を実行する本体で、トリガーはスケジュールかイベントでジョブを起動する仕組みです。

DataBrewはこの4つのどれでもありません。カタログを作る役でも、Sparkスクリプトを書く役でもなく、「読み込んだ後のデータをどう整えるか」だけを画面で組み立てる別サービスとして並んでいます。実際、レシピは読み込み方も書き出し方も持たず、そこはGlue Studio側のソースノードとターゲットノードが担当するとレシピのインポート手順のドキュメントに明記されています。

Data Catalogを軸にした全体の組み立てと、クローラーやWorkflowsの扱いはAWS Glueの機能とWorkflowsの仕組みの解説で扱いました。カタログの権限をアカウント横断で絞る段になるとAWS Lake Formationによるデータレイクの権限管理の領域へ入ります。

DataBrewとGlue StudioとGlue ETLジョブの選び分け

同じAWS Glueの傘の下に、変換を組み立てる手段が3つ並んでいます。コードを書かない画面操作がDataBrew、ジョブ全体をノードで組むビジュアルエディタがGlue Studio、PySparkかScalaのスクリプトを書くのがETLジョブ。どれを選ぶかは、変換の複雑さと担当者の顔ぶれで決まります。

整理すると、単一データセットの整形で担当者にアナリストが混ざるならDataBrew、ソースからターゲットまで含めた処理の流れを画面で組みたいならGlue Studio、条件分岐や複数テーブルの結合が中心ならETLジョブ。抽出・変換・格納という工程全体の設計思想はETLの仕組みとELTとの違い・ツール選定の解説のとおりで、DataBrewは変換の部分を画面へ寄せた道具にあたります。

ワーカー種別とDPU課金がDataBrewのノード課金と違う点

費用の考え方も別建てです。Glue ETLジョブはData Processing Unit（DPU）を単位に課金され、ワーカー種別はStandard、G.1X、G.2X、G.4X、G.8X、G.12X、G.16X、G.025X、メモリ容量を重視したR.1XからR.8Xまで用意されています。対してDataBrewはノード数で指定し、ワーカー種別という概念がありません。

単価だけを並べるとDataBrewのノード時間0.48ドルはETLの1DPU時間0.44ドルより高く見えます。ただし比べる対象は単価ではなく総額でしょう。DataBrewは編集中のセッションにも課金が乗る一方、スクリプトの実装工数はゼロ。ETLジョブ側は実行単価が安いかわりに、設計とテストの人件費が別に積み上がります。どちらが安いかは、月あたりの実行回数と改修頻度を置いてみないと決まりません。

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

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

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

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

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

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

レシピは他のデータセットへ再利用でき、バージョンとして保存されます。毎月同じ形式で届くファイルに同じ整形をかける運用では、この再利用が効く場面。整えた結果をどこへ置くかという設計はデータレイクとデータウェアハウス・レイクハウスの違いで扱った論点につながります。

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

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

数え方には揺れがある点も押さえておきたい。製品ページと開発者ガイドの概要は「250以上の変換」と書く一方、レシピの解説ページは「200以上のレシピアクション」と表記します。API上の呼び名がレシピアクションで、画面上の変換メニューはそれを組み合わせた単位という差でしょう。見積書に「250種類の変換が使える」と書き写す前に、必要な変換が実際にリファレンスへ載っているかを確かめるほうが確実です。

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

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

レシピ1本に載せられる変換ステップの上限100と分割の判断基準

設計上の上限として、レシピの作成と利用のドキュメントには「1つのDataBrewレシピに含められるデータ変換は最大100まで」と明記されています。画面で1ステップずつ積み上げる作りのため、列数の多いテーブルを扱うと数字は思ったより早く埋まる。列ごとに型変換と欠損補完を当てるだけで、40列のテーブルなら80ステップに達します。

上限に近づいたときの手は2つです。1つはレシピを工程で分割し、ジョブを直列に並べる方法。前段のレシピジョブがS3へ書いた結果を、後段のデータセットが読む構成にします。もう1つは、機械的な型変換をレシピの外へ出す方法。データセット作成時のフォーマットオプションや、後段のクエリで済ませられる処理をレシピから外すと、ステップ数は目に見えて減ります。

ステップ数は移行コストの目安にもなります。100に迫るレシピは、画面で差分を追える範囲を超えている合図。その段階まで来たなら、コードとして書き直す時期が近いと読んだほうが後の手戻りは小さく済みます。

接続できるデータソースと出力先・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へ置いて参照できます。接続先の代表格であるRedshift側の設計はAmazon Redshiftの特徴・料金とアーキテクチャの解説にまとめました。

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単体では往復させられません。整えた結果をSaaSへ返す必要があるなら、S3へ出力したうえで別途連携の仕組みを組む前提で見積もります。

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

AWS CLIでデータセットを作成しレシピジョブを実行する手順と権限設計

AWS CLIでS3のCSVをデータセットとして登録するコマンド

画面で組む道具ではあるものの、資源の定義はAWS CLIとSDKからも作れます。AWS CLIのdatabrewコマンドリファレンスには、create-dataset、create-project、create-recipe、create-recipe-job、create-profile-job、start-job-run、describe-job-run、publish-recipe、list-recipe-versionsといったサブコマンドが並びます。環境の再構築とレビュー可能な定義を求めるなら、データセットとジョブはCLIで作り、レシピの中身だけを画面で詰める分け方が扱いやすい。

S3上のCSVをデータセットとして登録する最小の形は次のとおりです。区切り文字とヘッダ行の有無は、レシピを組む前にここで決めます。

aws databrew create-dataset \
  --name sales-raw \
  --format CSV \
  --format-options '{"Csv":{"Delimiter":",","HeaderRow":true}}' \
  --input '{"S3InputDefinition":{"Bucket":"example-raw","Key":"sales/2026/"}}' \
  --region ap-northeast-1

Keyの末尾をスラッシュで終えるとフォルダ指定になり、配下の複数ファイルが1つのデータセットとして扱われます。ここで前節のストレージクラスの制約が効いてくるため、フォルダ指定を選んだなら対象ファイル数の確認をセットで組み込みます。formatに指定できるのはCSV、JSON、PARQUET、EXCEL、ORCで、JSONは複数行かどうか、EXCELはシート名かシート番号かを別途指定する作りです。

レシピをJSONで書きpublish-recipeで版として確定する

レシピの実体はJSONの配列です。開発者ガイドの構造解説によれば、各ステップはAction（OperationとParameters）と、絞り込み条件を書くConditionExpressionsで構成されます。画面で組んだレシピはJSONかYAMLでダウンロードでき、逆にJSONを書いてCLIから登録することもできます。

[
  {
    "Action": {
      "Operation": "REMOVE_VALUES",
      "Parameters": { "sourceColumn": "customer_id" }
    },
    "ConditionExpressions": [
      { "Condition": "IS_MISSING", "TargetColumn": "customer_id" }
    ]
  },
  {
    "Action": {
      "Operation": "REPLACE_TEXT",
      "Parameters": {
        "sourceColumn": "pref",
        "pattern": "東京都",
        "value": "東京"
      }
    }
  }
]

Conditionに指定できるのはIS、IS_NOT、IS_BETWEEN、CONTAINS、NOT_CONTAINS、STARTS_WITH、ENDS_WITH、LESS_THAN、GREATER_THAN、IS_INVALID、IS_MISSINGなど15種類。型が壊れている行だけを落とすIS_INVALIDと、欠損行を落とすIS_MISSINGは、日次の取り込みで真っ先に使う条件でしょう。

書いたJSONをレシピとして登録し、版を確定するまでは次の2コマンドです。publish-recipeを通した版だけがジョブから参照でき、編集途中の状態が本番へ流れる事故を防げます。

aws databrew create-recipe \
  --name sales-clean \
  --steps file://recipe.json

aws databrew publish-recipe \
  --name sales-clean \
  --description "2026-09 initial"

レシピジョブとプロファイルジョブを作り分けて実行するときの設定

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

aws databrew create-recipe-job \
  --name sales-clean-daily \
  --dataset-name sales-raw \
  --recipe-reference Name=sales-clean,RecipeVersion=1.0 \
  --role-arn arn:aws:iam::123456789012:role/DataBrewJobRole \
  --max-capacity 5 \
  --outputs 'Location={Bucket=example-curated,Key=sales/clean/},Format=PARQUET,Overwrite=true'

aws databrew start-job-run --name sales-clean-daily
aws databrew describe-job-run --name sales-clean-daily --run-id RUN_ID

recipe-referenceでRecipeVersionを明示している点が要点です。省略すると編集中のレシピを参照する余地が残り、画面での実験が本番の日次処理へ流れ込みます。定期実行するジョブは版を固定し、レシピを直したら意図して版を上げてジョブ定義を更新する運用にします。

max-capacityがノード数で、費用と処理時間の両方に直結します。大きくすれば速く終わる代わりに単位時間あたりの課金額が増える。分単位の課金のため、極端に大きなノード数で短時間に終わらせる構成が必ずしも安くなるとは限りません。

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つ目はノード数と実行頻度。日次で回している処理が週次で足りるかを見直せば、そのまま比例して下がるでしょう。

Glue ETLジョブのDPU単価と並べて費用を比べるときの見方

同じ処理をGlue ETLジョブで書いた場合と比べるなら、料金ページに載る1DPU時間0.44ドルが比較対象になります。5ノード20分のDataBrewジョブが0.80ドル、同じ資源量をDPUに読み替えたETLジョブは0.73ドル前後。実行だけを見れば1割ほどETLが安い計算です。

ただしこの差は月30回でも2ドル程度にしかなりません。判断を分けるのは実行費用ではなく、スクリプトを書いて保守する工数のほうでしょう。逆に日次が時間次になり実行回数が30倍へ跳ねる構成なら、単価差は月60ドル規模まで開きます。回数が増えるほどコードへ寄せる合理性が上がる、という順序で見ると迷いにくい。

もう1つ、DataBrew側にだけ乗るのが編集中のセッション課金です。レシピを頻繁に直す運用では、この分が定常費用として残り続けます。改修が月1回未満に落ち着いているかどうかを、費用比較の前に確かめておきたい。

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

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

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

公式の案内では、DataBrewの利用者は既存のレシピを新しいGlueのデータ準備体験へインポートするか、Glue Studioで直接作成でき、レシピをスケールアップしてペタバイト規模のデータを処理できると説明されています。Glue Studio側ではソースノードとターゲットノードを別に持つため、レシピは「読み込んだ後の整形」に専念する形へ整理されます。

2026年9月時点で、AWS Glue DataBrewの製品ページと開発者ガイドの双方に提供終了や新規受付停止の記載はありません。一方でDataBrewからGlue Studioへの移行チェックリストが公式ドキュメントに用意されているのも事実で、AWSが示す推奨経路の向きは読み取れます。

レシピ移行でインポートできない6つの変換と回避する設計の組み方

移行の手順そのものは軽く、3段階です。まずレシピとレシピバージョン、説明を取得できるようIAMポリシーへ権限を追加。次にGlue Studio側でData Preparation Recipeノードを置いてレシピをインポートし、最後にビジュアルエディタ上で引き継いで編集します。インポートウィザードは既存レシピへの追加（Append）か上書き（Overwrite）を選べる作りです。

ただし、移行には制約がある点に注意が必要です。移行ガイドの表はJOINとUNIONを挙げていますが、インポート手順のページのNoteはより広く、JOIN、UNION、GROUP_BY、PIVOT、UNPIVOT、TRANSPOSEの6つがレシピインポートに対応せず、レシピのオーサリングモードでも使えないと書いています。JOINとUNIONだけを見て移行コストを見積もると、集計やピボットを畳み込んだレシピで想定が外れます。

将来の移行可能性を残すなら、設計段階からこの6つをレシピの外へ出す手があります。結合はData Catalog側かSQL側で済ませ、集計とピボットは後段のクエリへ寄せ、レシピは単一データセットの列単位の整形に絞る。この分け方ならインポートがそのまま通り、レシピを組み替える工数が消えます。

なおインポート後にステップの順序を入れ替えると、Glue側が検証を走らせます。列をリネームしてから削除したレシピで削除を先頭へ動かすと、リネームのステップが無効になる、といった具合です。順序を変えるつもりなら、依存関係を先に洗い出しておきます。

インポートに必要なIAM権限3つとiam:PassRoleの落とし穴

レシピをインポートするロールには、DataBrew側の3アクションが要ります。databrew:ListRecipes、databrew:ListRecipeVersions、databrew:DescribeRecipe。AWSGlueConsoleFullAccessを当てるか、次のインラインポリシーを足すかのどちらかです。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "databrew:ListRecipes",
        "databrew:ListRecipeVersions",
        "databrew:DescribeRecipe"
      ],
      "Resource": ["*"]
    }
  ]
}

詰まりやすいのはもう1つの権限で、Data Preparation Recipe変換を使うにはiam:PassRoleの追加が要ります。足りていないとAccessDeniedが返り、AWSGlueServiceRoleに対するiam:PassRoleがidentity-basedポリシーで許可されていない、というメッセージが出ます。移行作業を止める典型がここなので、レシピをいじる前に権限側から潰しておくと進みが速い。

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

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

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

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

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

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

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

2つ目は、複数テーブルの結合や複雑な条件分岐が処理の中心になる場面。Glue ETLジョブでコードとして書き、バージョン管理とテストの対象にします。その実装手順はAWS GlueでETLジョブを動かす手順｜PySparkスクリプトとDPU課金の設計にまとめました。ジョブの依存関係を組む段はWorkflowsの領域です。

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

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

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

第2に、プロファイルジョブによる品質確認が納品物に含まれるか。件数と分布を測った記録がなければ、抜け落ちに気づく手段が残りません。第3に、レシピのバージョン管理と定期実行の手順が文書化されるか。CLIでのジョブ定義とレシピJSONがリポジトリに入るかどうかまで踏み込んで確認します。第4に、Glue StudioやGlue ETLジョブへ移す判断基準と移行コストの見立てが示されているか。ここでインポート非対応の6変換に触れていない見積書は、移行時の書き換え工数を織り込んでいない疑いがあります。

取り込みから整形、格納、分析までを一続きで設計する話になれば、範囲は前処理ツールの選定を越えるでしょう。5層で組む全体像はデータ分析基盤の構築と5層アーキテクチャの解説で整理しました。データ分析基盤構築・MLOps構築支援では、基盤の設計から運用体制の整備までを支援しています。どの工程をノーコードへ寄せるかの線引きから相談することが可能です。AWS上のネットワークとアカウント設計から手を入れる段階ならインフラ構築（AWS・Google Cloud・Azure）の範囲になります。

よくある質問

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

日本語を含むCSVやJSONも扱えます。ただし文字コードは事前確認が要り、文字化けが起きる場合はS3へ置く前にUTF-8へ揃えるのが確実。AWS Glueの開発者ガイドも、テキスト系データはUTF-8でエンコードされている必要があると注記しています。自然言語処理の変換には文を句に分割する機能がありますが、日本語で期待どおり分割されるかはプレビューで確かめてください。

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

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

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

できます。レシピは保存のたびにバージョンとして記録され、画面からJSONかYAMLでダウンロードできるほか、CLIのcreate-recipeで file: 指定のJSONから登録することも可能です。ジョブ定義もcreate-recipe-jobで書けるため、レシピJSONとジョブ定義をリポジトリへ置く運用は成立します。ただしプルリクエストで変換ロジックをレビューする文化があるなら、最初からGlue ETLジョブのコードとして持つほうが素直でしょう。

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

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

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

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

関連記事

• AWS Glueとは？機能・Workflowsの仕組みと使い方を実装視点で解説：DataBrewの親サービスにあたるGlue本体を扱います
• AWS GlueでETLジョブを動かす手順｜PySparkスクリプトとDPU課金の設計：コードで書く側の実装とDPU費用を比べられます
• データレイクとは？データウェアハウス・レイクハウスとの違いを実装視点で解説：整えたデータの置き場所の設計を扱います
• AWS Lake Formationとは？データレイクの権限管理・使い方・料金と実装判断を解説【2026年版】：Data Catalogの権限設計と併せて読めます
• Amazon QuickSightとは｜サーバーレスBIの機能・SPICE・料金・実装と採用判断を解説：整えた後の可視化手段を比較できます
• Amazon Redshiftとは？特徴・料金・使い方とアーキテクチャを実務目線で解説：JDBC接続先の代表格を詳しく扱います
• データ分析基盤の構築とは？5層アーキテクチャとBigQuery実装手順を技術視点で解説：前処理を含む基盤全体の設計を整理しています