--- title: "Zero-ETL統合の設定手順：AuroraからRedshiftへの複製と料金・ETLが残る場面【2026年10月】" url: "https://www.issoh.co.jp/tech/details/18577/" published: 2026-10-19 updated: 2026-10-19 categories: ["AWS"] publisher: "株式会社一創" --- # Zero-ETL統合の設定手順：AuroraからRedshiftへの複製と料金・ETLが残る場面【2026年10月】 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の考慮事項のページ](https://docs.aws.amazon.com/redshift/latest/mgmt/zero-etl.reqs-lims.html)は、複製の途中で変換はできず、データはソースのまま届くと明記しています。集計や名寄せのような変換は、複製後にRedshiftのマテリアライズドビューやdbtで組むことになります。 準備で詰まりやすいのは、ソース側の拡張binlogのパラメータ、Redshift側の大文字小文字区別、ソースを受け入れるリソースポリシーです。統合を作っても、Redshiftで`CREATE DATABASE ... FROM INTEGRATION`を実行するまで複製は始まりません。 統合そのものは無料で、課金されるのはbinlogのI/OやRedshiftのコンピュートなど既存リソースの利用分です。複数ソースの名寄せや列単位のマスキングが要るなら、GlueなどのETLを併用する前提で設計してください。 ## Zero-ETLの対応ソースと東京リージョンの版・Redshift側の前提条件 Redshift全体の構成と料金体系は[Amazon Redshift（レッドシフト）とは？RG・RA3・Serverlessの違いと東京の料金・使い方を解説](https://www.issoh.co.jp/tech/details/5170/)で扱っています。ここでは、Zero-ETL統合を作る前に確かめる条件だけを絞って示します。 ### Aurora・RDS・DynamoDB・SaaSで分かれる対応ソースと複製の遅延 [RedshiftのZero-ETLのページ](https://docs.aws.amazon.com/redshift/latest/mgmt/zero-etl-using.html)に載っている対応ソースは、ソースの種類ごとに複製の間隔が違います。 | ソースの系統 | 主な対象 | 複製の間隔 | | ------------- | ------------------------ | ------------ | | 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以上の対応版 [対応リージョンとエンジンの一覧](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.Aurora%5FFea%5FRegions%5FDB-eng.Feature.Zero-ETL.html)によると、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との違いと料金モデル・採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15447/)を参照してください。 ### RA3かServerless・暗号化・大文字小文字区別を満たすRedshiftの条件 ターゲットのRedshiftは、RA3（またはRG）ノードのプロビジョンドクラスターか、Redshift Serverlessである必要があります。[Auroraの準備手順のページ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/zero-etl.setting-up.html)は、RA3なら2ノード以上、プロビジョンドなら暗号化済みであることを条件に挙げています。DC2ノードのままでは作れません。 見落としやすいのが`enable_case_sensitive_identifier`です。既定では無効になっており、有効にしないと統合の作成に失敗します。小さく試すならServerlessが手軽で、基本の容量や課金の考え方は[Amazon Redshift Serverlessとは｜サーバーレスDWHの仕組みと料金・実装・移行判断を解説](https://www.issoh.co.jp/tech/details/15469/)にまとめています。 ## 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の認可設定のページ](https://docs.aws.amazon.com/redshift/latest/mgmt/zero-etl-using.redshift-iam.html)にあるリソースポリシーを名前空間に付け、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.json ``` `rs-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とデータフィルタで複製範囲を絞る書き方 [統合の作成手順のページ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/zero-etl.creating.html)のとおり、ソースとターゲットのARNを渡して作成します。複製するテーブルは、[データフィルタ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/zero-etl.filtering.html)（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を取得し、宛先データベースを作ります。手順は[宛先データベースの作成ページ](https://docs.aws.amazon.com/redshift/latest/mgmt/zero-etl-using.creating-db.html)の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; ``` [複製データの参照方法のページ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/zero-etl.querying.html)によると、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](https://docs.aws.amazon.com/redshift/latest/dg/r%5FSVV%5FINTEGRATION%5FTABLE%5FSTATE.html)には、テーブル単位の状態と、最後に状態が変わった理由が入ります。参照できるのはスーパーユーザーだけなので、監視用のジョブはその権限を持つユーザーで実行します。 ``` 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つに絞られます。 1. 主キーの無いテーブル。複製できず失敗状態になる 2. 65,535バイトを超える文字列。RedshiftのVARCHAR上限を超えた行でテーブルが止まる 3. 非対応のデータ型。PostgreSQLの拡張が作る型やユーザー定義型は対象外 4. ソースでの`ALTER TABLE`などのDDL。再同期が走り、その間はテーブルを参照できない 原因を直したら、[ALTER DATABASE](https://docs.aws.amazon.com/redshift/latest/dg/r%5FALTER%5FDATABASE.html)で該当テーブルを再同期します。文字列の超過で止めたくない場合は、`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の料金ページ](https://aws.amazon.com/rds/aurora/pricing/)と[Redshiftの料金ページ](https://aws.amazon.com/redshift/pricing/)は、どちらも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課金の設計](https://www.issoh.co.jp/tech/details/17472/)で扱っています。 複数の業務DBを顧客IDで名寄せする、コード値を名称に変換する、といった処理も同じです。Zero-ETLで生のテーブルをRedshiftに集め、変換はRedshiftの中でdbtやマテリアライズドビューとして書く「ELT」の形になります。ETLとELTの役割の違いは[ETLとは？仕組み・ELTとの違い・ツール選定から導入判断まで解説](https://www.issoh.co.jp/column/details/13364/)で整理しました。AWS以外のSaaSやDBが多い環境なら、[Fivetranとは？ELTの仕組み・MAR課金・dbt統合後の構成を実装視点で解説](https://www.issoh.co.jp/tech/details/15954/)のような外部のELTサービスのほうが対応ソースは広くなります。 ### Global DatabaseやBlue/Green切替がある構成で採用を見送る条件 採用してよいのは、ソースが東京のAurora MySQL 3.05.2以上またはPostgreSQL 16.4以上で、主キーのあるテーブルが中心、分析をRedshiftに寄せる方針が決まっている構成です。この条件なら、CDCのパイプラインを自前で書いて保守するより、Zero-ETLのほうが運用の手間は確実に小さくなります。自前で変更データを取る方式との比較は[CDC（Change Data Capture）とは？3方式の仕組み・実装設定と採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15871/)を参照してください。 見送るべきなのは次の構成です。Aurora Global Databaseのプライマリがセカンダリへフェイルオーバーすると統合は非アクティブになり、作り直すしかありません。Blue/Greenデプロイの切替も、事前に統合の削除が必要です。作り直すたびに初回同期が走るので、DR訓練や更新の多い構成ではRedshiftの数字が欠ける時間が定期的に生じます。分析先がRedshiftではなくS3上のデータレイクなら、[aurora\_analyticsとは？Aurora PostgreSQLからS3のIceberg・Parquetを直接読む設定手順と採用判断](https://www.issoh.co.jp/tech/details/18298/)のように向きを逆にする選択肢もあります。 業務DBの棚卸しから、Zero-ETLで済む範囲とETLが要る範囲の切り分け、Redshift上の変換の設計までをまとめて進めるなら、[データ分析基盤構築・MLOps構築支援](https://www.issoh.co.jp/service/ai/data-platform/)で構成の検討から相談できます。 ## 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との違いを実装目線で解説](https://www.issoh.co.jp/column/details/3025/)、SaaSのデータ連携をノーコードで組む方法は[Amazon AppFlowとは｜SaaS連携のノーコード統合の仕組み・料金・実装と採用判断を解説](https://www.issoh.co.jp/tech/details/15511/)で扱っています。 ## 関連記事 - [AWS GlueでETLジョブを動かす手順｜PySparkスクリプトとDPU課金の設計](https://www.issoh.co.jp/tech/details/17472/)：Zero-ETLで足りない変換をGlueのジョブで組む方法 - [AWS Glue DataBrewとは？ノーコードのデータ準備の仕組み・料金・Glue Studioとの使い分けを実装視点で解説](https://www.issoh.co.jp/tech/details/15782/)：コードを書かずにデータを整形する選択肢 - [ETLとは？仕組み・ELTとの違い・ツール選定から導入判断まで解説](https://www.issoh.co.jp/column/details/13364/)：ETLとELTの役割分担の考え方 - [Amazon Redshift（レッドシフト）とは？RG・RA3・Serverlessの違いと東京の料金・使い方を解説](https://www.issoh.co.jp/tech/details/5170/)：複製先のRedshiftの構成と料金 - [リバースETLとは？同期モードと差分検出の仕組み・API制約から実装判断を解説【2026年版】](https://www.issoh.co.jp/tech/details/16107/)：分析結果を業務システムへ戻す逆向きの連携 --- 出典: [Zero-ETL統合の設定手順：AuroraからRedshiftへの複製と料金・ETLが残る場面【2026年10月】]()（株式会社一創）