本記事の内容は 2026 年 9 月時点 の情報です。
はじめに
現状、RDS/Aurora をデータソースとするゼロ ETL 統合では、ターゲットは以下の 2 つ (いずれも Redshift) から選択することになります。
DynamoDB がデータソースの場合は S3 を指定可能ですが、現時点で RDS/Aurora は残念ながら、S3 は指定出来ません。。。
| # | ターゲット | 概要 |
|---|---|---|
| A | Glue Redshift マネージドカタログ | Glue のフェデレーテッドカタログ（Redshift 型カタログ）経由でデータを取り込む。SageMaker Unified Studio との統合に適する |
| B | Amazon Redshift（Serverless / Provisioned）直接 | Redshift データウェアハウスを直接ターゲットに指定する。 |
どちらも「ソースの RDS に書き込んだデータをニアリアルタイムでターゲットに複製できる」という点は共通です。
しかし、パターン A（Glue Redshift マネージドカタログ）の場合、以下の 2 点の大きな制約があります。
REFRESH_INTERVAL（複製間隔）を指定・調整できない- RPU（Redshift Serverless のキャパシティ）を指定・調整できない
パターン A （Glue Redshift マネージドカタログ）のデメリット（コスト観点）
パターン A では、データの実体は AWS Glue Data Catalog（Redshift マネージドカタログ）に対して自動的に作成されるマネージドワークグループに格納され、このワークグループは AWS 側で管理されるため、ユーザーがコスト最適化のためのパラメータを触れません。具体的には次の 2 点です。
デメリット 1：REFRESH_INTERVAL（CDC 間隔）を指定・調整できない
RDS/Aurora のゼロ ETL では、CDC (Change Data Capture) の頻度を REFRESH_INTERVAL で制御します。
- 短くすると CDC のリアルタイム性は上がるが、複製処理のためのコンピュートコストが上がる
- 長く（例：5 分以上）すると、リアルタイム性が不要なワークロードではコンピュート課金を抑えられる
公式ドキュメントでも、ゼロ ETL のコスト最適化手段として REFRESH_INTERVAL の調整が挙げられています。
Configure the REFRESH_INTERVAL of your target Redshift instance to balance freshness with cost. Shorter intervals ensure near real-time updates but drive up compute costs. Longer intervals (5 minutes or longer) reduce charges ...
現状、パターン A では、この REFRESH_INTERVAL をユーザー側で指定・調整する手段が無く、問答無用でデフォルトの 0 秒が適用されてしまいます。
そのため、リアルタイム性が不要なワークロードであっても CDC の間隔を伸ばしてコストを下げる、といったチューニングができません。
デメリット 2： Redshift の RPU（基本キャパシティ） を指定・調整できない
Redshift Serverless の課金は RPU（Redshift Processing Unit）ベースです。base RPU capacity を下げること（例：8 RPU）も、ゼロ ETL のコスト最適化手段として明記されています。
Use the lower base RPU capacity of 8 RPU where available for workloads.
パターン A では、ターゲットの Redshift Serverless がマネージドで、base/max RPU をユーザー側で指定・調整できない。
パターン B （Redshift Serverless 直接） ならコストを最適化できる
上記 2 点の裏返しですが、Redshift Serverless を直接、ゼロ ETL のターゲットにすると、両方を制御可能です。
-
REFRESH_INTERVALを調整して、リアルタイム性の要件とコストのバランスを取れる（ALTER DATABASEで後から変更も可能） - base/max RPU capacity を調整して、ワークロードに見合ったキャパシティに右サイズできる
出典: Cost optimization for Amazon Redshift Serverless with zero-ETL
比較まとめ（コスト観点）
| コスト最適化のレバー | A：Glue フェデレーテッドカタログ | B：Redshift Serverless 直接 |
|---|---|---|
REFRESH_INTERVAL（複製間隔） |
指定・調整不可 | 調整可能（ALTER DATABASE）0〜432,000 秒（5 日間） |
| RPU（Redshift キャパシティ） | 指定・調整不可 | 調整可能（UpdateWorkgroup など） |
SageMaker Lakehouse/Unified Studio との統合
公式ドキュメントだと、SageMaker Lakehouse/Unified Studio に対してゼロ ETL 統合を作成する場合には、パターン A の Glue Redshift マネージドカタログをターゲットにする方法が記載されています。
しかし、Redshift クラスターを Glue カタログに登録してフェデレーテッドカタログを作成し、対象カタログの Lake Formation 権限を Unified Studio のプロジェクト IAM ロールに対して付与することで、Unified Studio からもクエリが可能でした。
そのため、コストを優先する場合は、Redshift（Serverless / Provisioned）を直接ターゲットにする方針で良いと思っています。
Registering a cluster to the AWS Glue Data Catalog - Amazon Redshift
まとめ
リアルタイムな連携が必要、もしくは Redshift の運用負荷を抑えたい場合->パターン A （Glue Redshift マネージドカタログ）
リアルタイムな連携が不要、コストを抑えたい ->パターン B (Redshift 直接)