Zero-ETL統合は、Amazon AuroraやRDS、DynamoDBに書き込まれたデータを、Amazon Redshiftへほぼリアルタイムで自動複製するAWSのマネージド機能です。この記事では、Aurora MySQLを例に、パラメータグループとRedshift側の認可の準備から、統合と宛先データベースの作成、テーブル状態の監視までをCLIとSQLで示します。料金の内訳とETLが残る場面も、2026年10月時点の公式ドキュメントで整理しました。
まとめ：Zero-ETLが省くのは抽出と取り込みで変換はRedshift側に残る
Zero-ETL統合が肩代わりするのは、ソースDBからの変更の抽出と、Redshiftへの取り込みです。Redshiftの考慮事項のページは、複製の途中で変換はできず、データはソースのまま届くと明記しています。集計や名寄せのような変換は、複製後にRedshiftのマテリアライズドビューやdbtで組むことになります。
準備で詰まりやすいのは、ソース側の拡張binlogのパラメータ、Redshift側の大文字小文字区別、ソースを受け入れるリソースポリシーです。統合を作っても、RedshiftでCREATE DATABASE ... FROM INTEGRATIONを実行するまで複製は始まりません。
統合そのものは無料で、課金されるのはbinlogのI/OやRedshiftのコンピュートなど既存リソースの利用分です。複数ソースの名寄せや列単位のマスキングが要るなら、GlueなどのETLを併用する前提で設計してください。
Zero-ETLの対応ソースと東京リージョンの版・Redshift側の前提条件
Redshift全体の構成と料金体系はAmazon Redshift（レッドシフト）とは？RG・RA3・Serverlessの違いと東京の料金・使い方を解説で扱っています。ここでは、Zero-ETL統合を作る前に確かめる条件だけを絞って示します。
Aurora・RDS・DynamoDB・SaaSで分かれる対応ソースと複製の遅延
RedshiftのZero-ETLのページに載っている対応ソースは、ソースの種類ごとに複製の間隔が違います。
| ソースの系統 | 主な対象 | 複製の間隔 |
|---|---|---|
| AWSのリレーショナルDB | AuroraとRDSのMySQL等 | 既定は待ち時間0秒で連続 |
| DynamoDB | DynamoDBテーブル | 最小15分 |
| アプリケーション | Salesforce・SAP・Zendeskなど | 最小1時間 |
| 自己管理DB | MySQL・SQL Server等（DMS経由） | DMSの設定に依存 |
業務データを分単位の鮮度で見たいなら、AuroraかRDSをソースにする構成が第一候補です。DynamoDBとSaaSは間隔が長く、ダッシュボードの即時性を求める用途には向きません。この記事の手順はAurora MySQLを前提に書いています。
Aurora MySQL 3.05.2以上とPostgreSQL 16.4以上の対応版
対応リージョンとエンジンの一覧によると、2026年10月時点のアジアパシフィック（東京）は、Aurora MySQLがバージョン3.05.2以上、Aurora PostgreSQLが16.4以上・17.4以上・18.3以上です。Aurora MySQL 2系（MySQL 5.7互換）は対象外なので、古いクラスターは先にバージョンを上げる必要があります。
ソースとターゲットは同じリージョンに置くことが条件です。東京のAuroraから大阪のRedshiftへ、といったリージョンをまたぐ複製は組めません。Aurora自体の版の選び方はAmazon Auroraとは？仕組み・RDSとの違いと料金モデル・採用判断を実装者目線で解説を参照してください。
RA3かServerless・暗号化・大文字小文字区別を満たすRedshiftの条件
ターゲットのRedshiftは、RA3（またはRG）ノードのプロビジョンドクラスターか、Redshift Serverlessである必要があります。Auroraの準備手順のページは、RA3なら2ノード以上、プロビジョンドなら暗号化済みであることを条件に挙げています。DC2ノードのままでは作れません。
見落としやすいのがenable_case_sensitive_identifierです。既定では無効になっており、有効にしないと統合の作成に失敗します。小さく試すならServerlessが手軽で、基本の容量や課金の考え方はAmazon Redshift Serverlessとは｜サーバーレスDWHの仕組みと料金・実装・移行判断を解説にまとめています。
Aurora MySQLのパラメータとRedshiftの認可をCLIで準備する手順
コンソールの「Fix it for me」でも準備はできますが、検証環境と本番環境で設定をそろえるならCLIで残しておくと再現できます。以下の例では、ソースをorders-aurora、ターゲットをServerlessのワークグループanalytics-wgとします。
aurora_enhanced_binlogなど6項目のクラスターパラメータグループ作成
Aurora MySQL（aurora-mysql8.0ファミリー）で必要な値は、準備手順のページに6項目が列挙されています。カスタムのクラスターパラメータグループを作り、既存のクラスターに付け替えます。
# 1. Zero-ETL用のクラスターパラメータグループを作る
aws rds create-db-cluster-parameter-group \
--db-cluster-parameter-group-name zetl-mysql80 \
--db-parameter-group-family aurora-mysql8.0 \
--description "Aurora MySQL zero-ETL"
# 2. 拡張binlogとbinlog関連の値を設定する
aws rds modify-db-cluster-parameter-group \
--db-cluster-parameter-group-name zetl-mysql80 \
--parameters \
"ParameterName=aurora_enhanced_binlog,ParameterValue=1,ApplyMethod=pending-reboot" \
"ParameterName=binlog_backup,ParameterValue=0,ApplyMethod=pending-reboot" \
"ParameterName=binlog_format,ParameterValue=ROW,ApplyMethod=pending-reboot" \
"ParameterName=binlog_replication_globaldb,ParameterValue=0,ApplyMethod=pending-reboot" \
"ParameterName=binlog_row_image,ParameterValue=full,ApplyMethod=pending-reboot" \
"ParameterName=binlog_row_metadata,ParameterValue=full,ApplyMethod=pending-reboot"
# 3. 既存クラスターに付け替え、プライマリを再起動して反映する
aws rds modify-db-cluster \
--db-cluster-identifier orders-aurora \
--db-cluster-parameter-group-name zetl-mysql80
aws rds reboot-db-instance --db-instance-identifier orders-aurora-instance-1クラスター作成後にパラメータグループを付け替えた場合、プライマリインスタンスを再起動するまで統合は作れません。本番では再起動の時間帯を先に決めておきます。binlog_transaction_compressionをONにしている環境と、binlog_row_value_optionsがPARTIAL_JSONの環境も条件を満たさないので、既存のパラメータグループから値を引き継ぐときは確認してください。
Aurora PostgreSQLの場合は、rds.logical_replication=1、aurora.enhanced_logical_replication=1、aurora.logical_replication_backup=0、aurora.logical_replication_globaldb=0の4項目です。拡張論理レプリケーションを有効にするとWALに全列の値が書かれるため、ソースのIOPSが増えます。
大文字小文字区別とリソースポリシーでRedshiftに受け入れる設定
Serverlessのワークグループでは、大文字小文字区別をコンソールから変えられず、CLIのupdate-workgroupで設定します。続いて、Redshiftの認可設定のページにあるリソースポリシーを名前空間に付け、Auroraのクラスターを「認可された統合ソース」として登録します。
# 大文字小文字の区別を有効にする（Serverlessは再起動不要）
aws redshift-serverless update-workgroup \
--workgroup-name analytics-wg \
--config-parameters parameterKey=enable_case_sensitive_identifier,parameterValue=true
# 名前空間にリソースポリシーを付ける
aws redshift put-resource-policy \
--resource-arn "arn:aws:redshift-serverless:ap-northeast-1:111122223333:namespace/NAMESPACE_UUID" \
--policy file://rs-rp.jsonrs-rp.jsonの中身は次のとおりです。1つ目の文がRedshiftにソースのARNを継続して検証させるAuthorizeInboundIntegration、2つ目が統合を作るアカウントにCreateInboundIntegrationを許可する文です。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "Service": "redshift.amazonaws.com" },
"Action": "redshift:AuthorizeInboundIntegration",
"Resource": "arn:aws:redshift-serverless:ap-northeast-1:111122223333:namespace/NAMESPACE_UUID",
"Condition": {
"StringEquals": {
"aws:SourceArn": "arn:aws:rds:ap-northeast-1:111122223333:cluster:orders-aurora"
}
}
},
{
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::111122223333:root" },
"Action": "redshift:CreateInboundIntegration",
"Resource": "arn:aws:redshift-serverless:ap-northeast-1:111122223333:namespace/NAMESPACE_UUID"
}
]
}put-resource-policyは既存のポリシーを丸ごと置き換えます。2本目のソースを足すときは、get-resource-policyで現在の内容を取り出して文を足してから書き戻してください。1本目の文を消すと既存の統合が止まります。
create-integrationで統合を作り宛先データベースで複製を始める手順
準備が済んだら、統合を作り、Redshift側に宛先データベースを作ります。この2つがそろって初めて、ソースの行がRedshiftに現れます。
create-integrationとデータフィルタで複製範囲を絞る書き方
統合の作成手順のページのとおり、ソースとターゲットのARNを渡して作成します。複製するテーブルは、データフィルタ（Maxwellのフィルタ構文）で絞れます。
aws rds create-integration \
--integration-name orders-to-analytics \
--source-arn arn:aws:rds:ap-northeast-1:111122223333:cluster:orders-aurora \
--target-arn arn:aws:redshift-serverless:ap-northeast-1:111122223333:namespace/NAMESPACE_UUID \
--data-filter 'include: orders.*, exclude: orders.customer_pii, exclude: orders./tmp_.*/'
# 状態が Creating から Active に変わるまで待つ
aws rds describe-integrations \
--query "Integrations[].{name:IntegrationName,status:Status}"このフィルタは、ordersデータベースの全テーブルを含め、個人情報を持つcustomer_piiとtmp_で始まる作業用テーブルを外します。フィルタを1つでも書くと既定がexclude:*.*に切り替わり、書いた順に評価されます。広いincludeを先に、狭いexcludeを後に並べるのが基本です。パターンは1つの統合で最大99個、1個あたり256文字までです。
作成中はRedshift側がModifyingになり、クエリも設定変更も受け付けません。業務時間中に本番のRedshiftへ統合を足すと分析処理が止まるので、作成の時間帯は利用者と合わせておきます。
FROM INTEGRATIONで宛先データベースを作り初回同期を待つ
統合がActiveになったら、Redshiftに接続して統合IDを取得し、宛先データベースを作ります。手順は宛先データベースの作成ページのSQLどおりです。
-- 統合IDを確認する
SELECT integration_id FROM svv_integration;
-- 統合から宛先データベースを作る（Aurora MySQLの場合）
CREATE DATABASE orders_zetl FROM INTEGRATION 'INTEGRATION_ID';
-- 初回同期が終わったら、MySQLのDB名をスキーマとして参照する
SELECT order_date, COUNT(*) AS orders
FROM orders_zetl.orders."order_items"
GROUP BY order_date
ORDER BY order_date DESC
LIMIT 7;複製データの参照方法のページによると、Aurora MySQLのデータベースは宛先データベース内のスキーマとして現れます。大文字小文字を区別する設定なので、スキーマ名・テーブル名・列名はダブルクォートで囲むと取り違えを防げます。初回のデータ投入には、ソースの大きさに応じて20〜25分以上を見込んでください。
Aurora PostgreSQLで必須になるデータフィルタとDATABASE句の違い
Aurora PostgreSQLをソースにする場合、手順が2か所変わります。1つ目は、データフィルタが必須になることです。最低でもinclude: appdb.*.*のように、データベースを1つ含めるパターンを書きます。パターンはデータベース.スキーマ.テーブルの3階層で、正規表現はスキーマ名とテーブル名にしか使えません。
2つ目は、宛先データベースを作るときに、ソース側の名前付きデータベースをDATABASE句で指定することです。PostgreSQLのデータベースはRedshiftのデータベースに名前で対応付けられ、1つのRedshiftに対応付けられるのは最大100データベースです。
CREATE DATABASE "appdb_zetl" FROM INTEGRATION 'INTEGRATION_ID' DATABASE "appdb";ソースのデータベースはすべてUTF-8が条件です。宣言的パーティションは親テーブルではなく各パーティションが複製されるため、またいで集計するならRedshift側のビューで束ねます。
複製テーブルの状態監視と再同期・REFRESH_INTERVALの運用手順
統合がActiveでも、すべてのテーブルが同期しているとは限りません。テーブルごとに状態を持ち、1本だけFailedになっていることがあります。運用では、統合の状態とテーブルの状態を分けて見ます。
テーブル状態ビューでFailedとResyncRequiredを拾う監視SQL
SVV_INTEGRATION_TABLE_STATEには、テーブル単位の状態と、最後に状態が変わった理由が入ります。参照できるのはスーパーユーザーだけなので、監視用のジョブはその権限を持つユーザーで実行します。
SELECT target_database, schema_name, table_name,
table_state, reason, last_updated_timestamp
FROM svv_integration_table_state
WHERE table_state IN ('Failed', 'ResyncRequired', 'ResyncInitiated')
ORDER BY last_updated_timestamp DESC;table_stateは、Synced・Failed・Deleted・ResyncRequired・ResyncInitiated・DroppedSourceのいずれかです。このSQLを定期実行し、1行でも返れば通知する形にしておけば、利用者からの指摘で止まりに気付く事態を避けられます。
主キーなし・VARCHAR超過・DDLで止まる典型と復旧のALTER DATABASE
テーブルが止まる原因は、公式の制限事項を読むとおおむね次の4つに絞られます。
- 主キーの無いテーブル。複製できず失敗状態になる
- 65,535バイトを超える文字列。RedshiftのVARCHAR上限を超えた行でテーブルが止まる
- 非対応のデータ型。PostgreSQLの拡張が作る型やユーザー定義型は対象外
- ソースでの
ALTER TABLEなどのDDL。再同期が走り、その間はテーブルを参照できない
原因を直したら、ALTER DATABASEで該当テーブルを再同期します。文字列の超過で止めたくない場合は、TRUNCATECOLUMNSで切り詰めて取り込み続ける設定もあります。
-- エラー状態のテーブルだけをスキーマ単位で再同期する
ALTER DATABASE orders_zetl INTEGRATION REFRESH INERROR TABLES IN SCHEMA orders;
-- 上限を超えた文字列を切り詰めて取り込みを続ける
ALTER DATABASE orders_zetl INTEGRATION SET TRUNCATECOLUMNS = TRUE;Aurora MySQLでは、ON DELETE CASCADEなどの参照動作を持つ外部キーもテーブルを失敗状態にします。マイグレーションのレビュー項目に「主キーの有無」と「外部キーの参照動作」を入れておくと、止まってから気付く回数が減ります。
REFRESH_INTERVALとQUERY_ALL_STATESで鮮度と参照可否を調整
REFRESH_INTERVALは、1回の取り込みサイクルが終わってから次を始めるまでの待ち時間（秒）です。AuroraとRDSでは0〜432,000秒（5日）を指定でき、既定は0で、前のサイクルが終わり次第すぐ次を始めます。ALTER DATABASEのページは、書き込みが多い統合では60〜120秒の小さな値を勧めています。変更をまとめて取り込むほど、Redshift側のコンピュートの消費が減るためです。
-- 2分ごとにまとめて取り込む
ALTER DATABASE orders_zetl INTEGRATION SET REFRESH_INTERVAL 120;
-- 再同期中のテーブルも（古いデータのまま）参照できるようにする
ALTER DATABASE orders_zetl INTEGRATION SET QUERY_ALL_STATES = TRUE;Serverlessでは取り込み処理もRPUとして課金されるため、日次レポートしか見ない用途で既定の0秒のまま動かすのは割に合いません。ダッシュボードの更新頻度に合わせて間隔を延ばします。QUERY_ALL_STATESを有効にすると、再同期中も画面は出ますが、数字が古いことに利用者が気付きにくくなります。
Zero-ETLの料金の内訳とETLが残る場面・採用しない条件の判断基準
Zero-ETLは「ETLが要らなくなる」と紹介されがちですが、なくなるのはパイプラインの運用の一部です。費用と、引き続きETLが要る場面を具体的に示します。
統合は無料でもbinlogのI/OとRPU・AZ間転送が発生する料金
Auroraの料金ページとRedshiftの料金ページは、どちらもZero-ETL統合そのものに追加料金はかからないとしています。そのうえで、次の既存リソースの利用分は請求されます。
| 発生する場所 | 課金される内容 |
|---|---|
| Aurora | 拡張binlogで増えるI/Oとストレージ |
| Aurora | 初回シード用のスナップショットエクスポート |
| Redshift | 複製データの保存と取り込み処理（RPU） |
| ネットワーク | ソースからターゲットへのAZ間データ転送 |
| 監視 | CloudTrailとCloudWatchの利用分 |
ソースによっては別料金があり、Oracle Database@AWSには米国東部とオレゴンでCDC 1GBあたり2.00ドルなどの単価が示されています。Auroraの継続的な変更の処理は追加料金なしなので、見積もりはAurora側のI/Oの増加と、Redshift側の取り込み頻度の2点を押さえれば大きく外しません。
変換・複数ソース結合・列単位のマスキングはGlueやdbtの領分
Zero-ETLのデータフィルタはデータベースとテーブルの単位までで、列や行の単位では絞れません。個人情報の列だけを落として分析者に渡す要件があるなら、複製後にRedshiftでビューや列レベルの権限を組むか、Glueのジョブで取り出し時にマスキングします。Glueでのジョブの組み方はAWS GlueでETLジョブを動かす手順｜PySparkスクリプトとDPU課金の設計で扱っています。
複数の業務DBを顧客IDで名寄せする、コード値を名称に変換する、といった処理も同じです。Zero-ETLで生のテーブルをRedshiftに集め、変換はRedshiftの中でdbtやマテリアライズドビューとして書く「ELT」の形になります。ETLとELTの役割の違いはETLとは？仕組み・ELTとの違い・ツール選定から導入判断まで解説で整理しました。AWS以外のSaaSやDBが多い環境なら、Fivetranとは？ELTの仕組み・MAR課金・dbt統合後の構成を実装視点で解説のような外部のELTサービスのほうが対応ソースは広くなります。
Global DatabaseやBlue/Green切替がある構成で採用を見送る条件
採用してよいのは、ソースが東京のAurora MySQL 3.05.2以上またはPostgreSQL 16.4以上で、主キーのあるテーブルが中心、分析をRedshiftに寄せる方針が決まっている構成です。この条件なら、CDCのパイプラインを自前で書いて保守するより、Zero-ETLのほうが運用の手間は確実に小さくなります。自前で変更データを取る方式との比較はCDC（Change Data Capture）とは？3方式の仕組み・実装設定と採用判断を実装者目線で解説を参照してください。
見送るべきなのは次の構成です。Aurora Global Databaseのプライマリがセカンダリへフェイルオーバーすると統合は非アクティブになり、作り直すしかありません。Blue/Greenデプロイの切替も、事前に統合の削除が必要です。作り直すたびに初回同期が走るので、DR訓練や更新の多い構成ではRedshiftの数字が欠ける時間が定期的に生じます。分析先がRedshiftではなくS3上のデータレイクなら、aurora_analyticsとは？Aurora PostgreSQLからS3のIceberg・Parquetを直接読む設定手順と採用判断のように向きを逆にする選択肢もあります。
業務DBの棚卸しから、Zero-ETLで済む範囲とETLが要る範囲の切り分け、Redshift上の変換の設計までをまとめて進めるなら、データ分析基盤構築・MLOps構築支援で構成の検討から相談できます。
Zero-ETL統合の設定と運用で挙がるよくある質問と公式の回答
Zero-ETL統合を検討し始めたときに出やすい疑問に、AWSの公式ドキュメントの記述をもとに答えます。
Zero-ETLと従来のETLやELTは何が違いますか？
従来のETLは、抽出・変換・取り込みのパイプラインを自分で作って動かします。Zero-ETL統合では、抽出と取り込みをAWSがマネージドで受け持ち、ソースの変更が自動でRedshiftへ流れる仕組みです。変換は含まれないため、整形や集計は複製後にRedshiftの中で行う、ELTに近い構成になります。
Redshiftに複製されたテーブルを直接更新できますか？
できません。統合から作った宛先データベースは読み取り専用で、テーブルやビュー、マテリアライズドビューもその中には作れません。データを書き換えられるのはソースのAuroraだけです。集計用のテーブルやマテリアライズドビューは、同じRedshift上の別のデータベースに作り、データベースをまたぐクエリで複製データを参照します。
既存のAuroraクラスターに後から統合を追加できますか？
追加できます。必要な値を設定したクラスターパラメータグループに付け替え、プライマリインスタンスを再起動してから統合を作る流れです。本番では停止できる時間帯を選んでください。DBインスタンスが1台も無いクラスターや、AWS RAMで共有されたクロスアカウントのクローンはソースにできません。
1つのRedshiftに複数のAuroraをまとめられますか？
まとめられます。Auroraの統合のクォータは、1つのターゲットあたり50、1つのソースクラスターあたり5、アカウント全体（リージョンごと）で100が既定値です。ただし同じソースと同じターゲットの間に2本目の統合は作れません。複数の業務DBをRedshiftに集め、データベースをまたぐクエリで結合する使い方が想定されています。
DynamoDBやSalesforceもZero-ETLでRedshiftに送れますか？
送れます。Redshiftの対応ソースには、DynamoDBのほか、Salesforce・SAP・ServiceNow・Zendeskなどのアプリケーションが含まれます。ただし最小の複製間隔はDynamoDBが15分、アプリケーションが1時間で、Auroraほどの鮮度は出ません。DynamoDBの項目はRedshiftのSUPER型の列に入ります。DynamoDB自体の設計はAmazon DynamoDBとは？仕組み・使い方・料金とRDSとの違いを実装目線で解説、SaaSのデータ連携をノーコードで組む方法はAmazon AppFlowとは｜SaaS連携のノーコード統合の仕組み・料金・実装と採用判断を解説で扱っています。
関連記事
- AWS GlueでETLジョブを動かす手順｜PySparkスクリプトとDPU課金の設計：Zero-ETLで足りない変換をGlueのジョブで組む方法
- AWS Glue DataBrewとは？ノーコードのデータ準備の仕組み・料金・Glue Studioとの使い分けを実装視点で解説：コードを書かずにデータを整形する選択肢
- ETLとは？仕組み・ELTとの違い・ツール選定から導入判断まで解説：ETLとELTの役割分担の考え方
- Amazon Redshift（レッドシフト）とは？RG・RA3・Serverlessの違いと東京の料金・使い方を解説：複製先のRedshiftの構成と料金
- リバースETLとは？同期モードと差分検出の仕組み・API制約から実装判断を解説【2026年版】：分析結果を業務システムへ戻す逆向きの連携
