aurora_analyticsとは？Aurora PostgreSQLからS3のIceberg・Parquetを直接読む設定手順と採用判断

aurora_analyticsは、Aurora PostgreSQLの中に組み込まれたDuckDBを使って、Amazon S3上のApache IcebergやParquetを外部テーブルとして直接SQLで読む拡張です。AWSが2026年9月30日に発表し、Aurora PostgreSQL 17.11以上と18.6以上で使えます。Aurora PostgreSQL自体の対応バージョンや拡張機能の全体像はAurora PostgreSQLとは？対応バージョン・拡張機能とBabelfish・RDSからの移行判断を実装者目線で解説にまとめてあります。この記事では拡張に絞って、有効化までの設定、外部テーブルの作り方、運用で詰まりやすい箇所、似た仕組みとの使い分けを、2026年10月時点の公式ドキュメントに沿って整理しました。

まとめ｜ETLなしでデータレイクを読むAurora PostgreSQLの読み取り専用外部テーブル

• データレイクのIcebergとParquetを、Auroraの業務テーブルと同じ接続先・同じSQLで読めます。コピーを作る逆方向のETLパイプラインが要らなくなる点が最大の効用です。
• 有効化は4段階です。IAMロールを機能名 AuroraAnalytics で付ける、S3とGlueへの経路を通す、パラメータ aurora_analytics.enabled を true にする、DBごとに CREATE EXTENSION を実行する、の順に進めます。
• 外部テーブルは読み取り専用です。INSERT・UPDATE・DELETE はできず、JSONBや配列型も扱えません。
• 拡張そのものの追加料金はありません。ただしクエリが使うAuroraの計算資源とS3のリクエストには課金されます。
• 重い分析を本番のライターで回すと業務処理と資源を奪い合います。分析が日常的に走るなら、専用のリーダーを1台切り出すのが前提です。

aurora_analyticsの内部構造｜DuckDBによる外部テーブルの実行

aurora_analyticsはAurora PostgreSQLに組み込まれた拡張で、一言でいえば、PostgreSQLの外部データラッパー（FDW）の皮をかぶった列指向の分析エンジンです。利用者から見えるのは普通の外部テーブルで、裏側の実行はDuckDBが受け持ちます。

発表と対応バージョン｜2026年9月30日発表・17.11以上と18.6以上

AWS News Blogの発表記事は2026年9月30日付で、提供範囲をすべての商用リージョンとAWS GovCloud (US)としています。東京リージョンも、この提供範囲の対象です。Aurora ユーザーガイドの機能ページによれば、対応はAurora PostgreSQL 17.11以上と18.6以上で、Aurora Serverless v2も含まれます。

16系以前のクラスタでは使えません。既存クラスタで試すには、まずエンジンの更新計画が要ります。版の上げ方と互換性の確認は親記事の範囲なので、ここでは「17.11未満なら先にアップグレード」とだけ押さえてください。

内部の構成｜外部データラッパーとDuckDBとローカルキャッシュの分担

拡張を入れると、外部データラッパーと aurora_analytics_server という名前の外部サーバーが自動で作られます。外部テーブルへのクエリは、PostgreSQLの中に組み込まれたDuckDBが実行します。DuckDBそのものの特徴やSQLite・PostgreSQLとの違いはDuckDBとは？特徴・用途とSQLite・PostgreSQLとの違いを実測で解説で扱いました。

速さを支える仕掛けは3つあると公式は説明しています。条件をS3側の読み出しに押し込む述語プッシュダウン、必要な列だけを読む列の刈り込み、そしてインスタンスのローカルストレージに載せる読み取りキャッシュです。初回はS3との往復が乗り、2回目以降は手元のNVMeかEBSから読みます。

読める場所と形式｜S3とS3 TablesとGlue Data Catalogの3経路

形式はParquetとIcebergの2つです。置き場所は、S3のURIを直接指す方法、S3 TablesのARNを指す方法、Glue Data CatalogのテーブルARNを指す方法の3通りがあります。Glue Data Catalogのフェデレーションを経由すれば、AWSの外にあるIceberg REST Catalog互換のカタログのテーブルも読めます。

Parquetはファイル形式、Icebergはその上に載るテーブル形式という関係です。両者の違いはApache IcebergとParquetの違い｜テーブル形式とファイル形式の関係を整理を参照してください。スナップショットを指定した読み出しや権限の一元管理を考えるなら、Icebergでカタログに登録しておく形のほうが扱いやすくなります。

有効化までの設定手順｜IAMロール・VPCエンドポイント・パラメータの順

前提条件のページは、準備を5つの手順に分けています。IAMポリシーの作成、IAMロールの作成、クラスタへの付与、ネットワークの用意、パラメータグループでの有効化です。

IAMロールの付与｜機能名AuroraAnalyticsでクラスタへ結び付けるCLI

必要な権限は読み方で変わります。S3の単一ファイルなら s3:GetObject だけ、ディレクトリ指定なら s3:ListBucket も要ります。Glue経由なら glue:GetTable が加わり、S3 Tablesなら s3tables 系の4権限です。SSE-KMSで暗号化しているなら kms:Decrypt も足します。ロールを作ったら、機能名を指定してクラスタに付けます。

# 信頼ポリシーでRDSに引き受けを許したロールを作る
aws iam create-role \
  --role-name AuroraAnalyticsRole \
  --assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"rds.amazonaws.com"},"Action":"sts:AssumeRole"}]}'

# 読み取り権限のポリシーを付ける（ARNは自分のアカウントのものに置き換える）
aws iam attach-role-policy \
  --role-name AuroraAnalyticsRole \
  --policy-arn arn:aws:iam::123456789012:policy/AuroraAnalyticsReadAccess

# 機能名 AuroraAnalytics でクラスタに付与する
aws rds add-role-to-db-cluster \
  --region ap-northeast-1 \
  --db-cluster-identifier my-analytics-cluster \
  --feature-name AuroraAnalytics \
  --role-arn arn:aws:iam::123456789012:role/AuroraAnalyticsRole

機能名を取り違えるのが典型的な失敗です。S3からのインポートに使う s3Import とは別の機能名なので、既存のインポート用ロールを流用するつもりでも、AuroraAnalytics として付け直す必要があります。付与後、コンソールでロールの状態が Active になれば完了です。

VPCエンドポイントの準備｜S3はゲートウェイ型でGlueはインターフェース型

プライベートサブネットに置いたクラスタは、そのままではS3にもGlueにも届きません。公式が推奨するのはVPCエンドポイントで、S3はゲートウェイ型、Glueはインターフェース型です。S3のゲートウェイ型には時間あたりの料金がかかりません。NATゲートウェイ経由でも届きますが、公開経路を通るうえにデータ処理料金が発生します。

Glueのインターフェース型は、クラスタと同じサブネットに置き、プライベートDNSを有効にし、VPCのCIDRかクラスタのセキュリティグループからTCP 443を許可します。classmethodの検証記事では、エンドポイントが無い状態で外部テーブルを読むと curlCode 28 のタイムアウトで失敗したと報告されています。接続エラーではなく待たされて落ちるので、原因に気づきにくい箇所です。

拡張の導入手順｜パラメータによる有効化とデータベース単位の作成条件

パラメータ aurora_analytics.enabled は既定で false です。動的パラメータなので再起動なしで反映されます。ただし既定のパラメータグループは変更できません。既定のまま運用しているクラスタは、カスタムのクラスタパラメータグループを作って付け替える必要があり、付け替え自体にはインスタンスの再起動が伴います。

# カスタムのクラスタパラメータグループで機能を有効にする
aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name my-analytics-params \
  --parameters "ParameterName=aurora_analytics.enabled,ParameterValue=true,ApplyMethod=immediate"

-- psqlで接続し、使うデータベースごとに拡張を入れる
CREATE EXTENSION aurora_analytics;

-- rds_superuser以外に作成を任せる場合
GRANT rds_extension TO app_admin;
ALTER USER app_admin SET rds.allowed_delegated_extensions = 'aurora_analytics';

導入手順のページのとおり、拡張はデータベース単位です。同じクラスタでも、別のデータベースで使うならそちらでも CREATE EXTENSION を実行します。

外部テーブルで試す手順｜Parquet・Iceberg・一括登録のSQL例

構文は外部テーブルのページにまとまっています。指定できるオプションは location・format・region・snapshot・timestamp の5つだけです。

Parquetの外部テーブル化｜列の自動推論とformat指定が必須の条件

列の定義を空の括弧にすると、ParquetやIcebergのメタデータから列名と型が自動で推論されます。S3のURIを指す場合、format は省略できません。拡張子やファイルの中身から形式を推測しない仕様だからです。

-- S3上のParquetディレクトリを外部テーブルにする（列は自動推論）
CREATE FOREIGN TABLE ft_orders ()
SERVER aurora_analytics_server
OPTIONS (
    location 's3://my-bucket/data/orders/',
    format 'parquet'
);

SELECT COUNT(*) FROM ft_orders;

列を明示した場合は、書いた列だけが読み出されます。業務で使う列が決まっているなら、明示しておくほうがS3から読む量を抑えられます。

Glue上のIcebergの参照｜ARN指定と時点指定のタイムトラベル

Glue Data CatalogやS3 TablesのARNを指す場合は、format を省略しても形式はカタログから読み取られます。Iceberg専用の snapshot と timestamp を使うと、過去の時点のテーブルを読めます。2つは同時に指定できません。

-- Glueに登録したIcebergテーブルの最新スナップショットを読む
CREATE FOREIGN TABLE ft_orders_ice ()
SERVER aurora_analytics_server
OPTIONS (location 'arn:aws:glue:ap-northeast-1:123456789012:table/sales_db/orders');

-- 前日時点のテーブルを読む（値は作成時に解決される）
CREATE FOREIGN TABLE ft_orders_yesterday ()
SERVER aurora_analytics_server
OPTIONS (location 'arn:aws:glue:ap-northeast-1:123456789012:table/sales_db/orders',
         timestamp 'yesterday');

-- Glueのデータベースから必要なテーブルだけ一括で登録する
IMPORT FOREIGN SCHEMA sales_db
    LIMIT TO (orders, customers)
    FROM SERVER aurora_analytics_server
    INTO analytics
    OPTIONS (location 'arn:aws:glue:ap-northeast-1:123456789012:catalog');

timestamp の値は外部テーブルを作った時点で解決されます。yesterday と書いても毎日ずれていくわけではないので、日次の比較に使うなら作り直すか snapshot で固定してください。IMPORT FOREIGN SCHEMA はGlueとS3 Tablesだけが対象で、1件でも失敗すると全体が取り消されます。

業務テーブルとの結合と取り込み｜JOINとCREATE TABLE ASの使い分け

外部テーブルは普通のテーブルと同じようにJOINできます。顧客マスタはAurora、購買履歴はデータレイクという分担のまま、1本のSQLで突き合わせられます。

-- Auroraの顧客テーブルとレイクの注文履歴を結合する
SELECT c.customer_id, c.name, SUM(o.total_amount) AS amount_5y
FROM customers c
JOIN ft_orders_ice o ON o.customer_id = c.customer_id
WHERE o.order_date >= CURRENT_DATE - INTERVAL '5 years'
GROUP BY c.customer_id, c.name;

-- 低遅延で引きたい集計だけをAuroraのテーブルに取り込む
CREATE TABLE order_summary AS
SELECT customer_id, COUNT(*) AS orders, SUM(total_amount) AS amount
FROM ft_orders_ice GROUP BY customer_id;

画面表示のたびに呼ばれる参照は、外部テーブルを毎回読ませず、取り込んだテーブルを使うのが筋です。発表記事も、1桁ミリ秒の応答が要る場合はAuroraのテーブルへ取り込むよう案内しています。取り込み系の処理はライターでしか実行できません。

本番運用で詰まる箇所｜メモリ配分・リーダー分離と制限事項の確認

機能を有効にするところまでは難しくありません。本番で問題になるのは、業務処理と分析が同じインスタンスの資源を取り合う部分です。

query_memとディスク退避｜shared_buffersとの取り合いと取消しの条件

資源管理のページによると、1クエリが使える作業メモリは aurora_analytics.query_mem で決まり、上限はインスタンスのメモリから shared_buffers を引いた量です。shared_buffers は既定でメモリの約3分の2を押さえていて、外部テーブルのクエリはこれを使いません。分析ばかりのインスタンスでは、shared_buffers を減らすのが最も効く調整だと公式は書いています。

query_mem を超えた分はローカルストレージへ退避され、遅くなっても完走します。一方、インスタンス全体のメモリが逼迫すると、メモリ保護機能が実行中のクエリを取り消し、Out of Memory Error を返します。rds_superuser のクエリは取消しの対象外なので、管理者ユーザーで分析を回すと保護が効きません。分析用のロールは必ず分けてください。インスタンスクラスの系統ごとの違いはAmazon Auroraとは？仕組み・RDSとの違いと料金モデル・採用判断を実装者目線で解説で整理しています。本番で使うなら、インスタンスクラスの選び方が勧めるとおり、キャッシュと退避をNVMeに置ける db.r8gd のようなd系が候補です。

分析専用リーダーの分離｜昇格優先度15とstatement_timeoutの設定

専用リーダーのページは、分析が重いワークロードではリーダーを1台切り出すよう勧めています。設定は次の4点です。

1. shared_buffers を下げ、query_mem を上げる
2. フェイルオーバーで昇格しないよう、昇格優先度を最も低い15にする
3. 分析の接続先はクラスタのリーダーエンドポイントでなく、インスタンスエンドポイントかカスタムエンドポイントにする
4. statement_timeout で1クエリの実行時間に上限を置く

4つ目を省くと副作用がライターに及びます。リーダーで長時間のクエリが走っている間、ライターはvacuumで不要な行を回収できず、性能が落ちていきます。ライター側では oldest_reader_feedback_xid_age を監視対象に加えてください。

制限事項の一覧｜読み取り専用・JSONB非対応・単一リージョンほか

制限事項のページから、設計に響くものを影響の大きい順に並べました。

書き込み制限の対象は、INSERT・UPDATE・DELETE・TRUNCATE・COPY FROMです。行の挿入や更新だけでなく、全件削除や外部テーブルへの取り込みもできません。

見落としやすいのはキャッシュです。フェイルオーバー直後は全データをS3から読み直すため、普段は速い集計がしばらく遅くなります。監視の閾値を決めるときは、この冷えた状態の実行時間も測っておいてください。

独自章｜pg_duckdb・Zero-ETL・逆ETLとの比較と採用条件

データレイクと業務DBをつなぐ手段には、pg_duckdb・Zero-ETL・逆ETLもあります。aurora_analyticsを選ぶかどうかは、データが流れる向きと、どこで結合したいかで決まります。

似た仕組みとの比較表｜pg_duckdb・Zero-ETL・逆ETLとの違い

pg_duckdbはDuckDB公式のPostgreSQL拡張で、EC2やコンテナで自前管理するPostgreSQLに入れる選択肢です。Zero-ETL統合はAuroraの更新をRedshiftへ流す仕組みで、向きが逆になります。逆ETLは、Glueのジョブなどでレイクのデータを定期的にAuroraへコピーする従来の方法です。Glueでのジョブの組み方はAWS GlueでETLジョブを動かす手順｜PySparkスクリプトとDPU課金の設計で扱いました。

Aurora上のアプリから、レイクの履歴を業務データと一緒に読みたい。この要件に正面から応えるのはaurora_analyticsだけです。分析担当がBIで大量の集計を回すのが主目的なら、結合の場所はRedshiftのような分析基盤に置くほうが自然です。

採用してよい条件｜参照中心でAuroraの業務データと結合する場面

採用してよいのは次の場面です。逆ETLでレイクから毎晩コピーしている参照用テーブルがあり、その同期の保守に手が取られている。読む側は画面の明細や月次の照会で、数百ミリ秒から秒単位の応答で困らない。そして古い履歴をレイクへ逃がしてAuroraの容量とバックアップを軽くしたい。この3つのうち2つ以上が当てはまるなら、コピーを外部テーブルへ置き換える検証を始める価値があります。AIエージェントに業務データと過去の履歴を1つのSQL経路で読ませたい場合も、同じ判断が使えます。

見送るべき場面｜書き戻しや1桁ミリ秒応答、複数リージョンの横断

見送るべきなのは3つの場面です。1つ目は、レイクのデータをAurora側から更新したい場合。外部テーブルは読み取り専用なので、書き戻しの経路は別に要ります。2つ目は、画面の応答を1桁ミリ秒で返す必要がある参照を外部テーブルで直接受ける設計で、ここは取り込みが前提です。3つ目は、複数リージョンのS3を1つのクエリで横断する構成で、制限上そもそも組めません。

逆に、16系のAuroraをまだ動かしているなら、この拡張のためだけに急いで上げる理由はありません。エンジン更新の計画に組み込み、上げた後に検証する順序で十分です。業務DBとデータレイクのどちらに何を置くか、参照の経路をどう切るかは、機能選定より先に決まる設計の問題です。現行の構成やバージョン更新から整理したい場合は、データベース設計・移行支援で構成案の作成からご相談いただけます。

よくある質問

2026年10月時点の公式ドキュメントで答えられる範囲に限って回答します。

aurora_analyticsに追加料金はかかりますか？

拡張そのものに追加料金はありません。課金されるのは、外部テーブルへのクエリが使うAuroraの計算資源の増分と、データレイクのファイルを読むときのS3リクエストです。プライベートサブネットからNATゲートウェイ経由で読むと、NATのデータ処理料金も加わります。S3はゲートウェイ型のVPCエンドポイントで通しておくと、この分を避けられます。

Aurora PostgreSQL 16で使えますか？

使えません。対応はAurora PostgreSQL 17.11以上と18.6以上です。16系以前のクラスタで使うには、先にメジャーバージョンを上げる必要があります。拡張の互換性や延長サポートの扱いを含めた更新計画を立て、検証環境で17.11以上に上げてから有効化の手順に進んでください。

リードレプリカで実行できますか？

外部テーブルの読み取りは、ライターでもリーダーでも実行できます。分析の負荷が大きいなら、むしろ専用のリーダーで回すことが公式に推奨されています。CREATE TABLE AS SELECT や INSERT INTO … SELECT のような取り込み系の処理はライターでしか実行できない点に注意してください。

S3のParquetを置き換えたのに古い結果が返るのはなぜですか？

開いたままの接続がキャッシュ済みのファイルハンドルを持っているためです。資源管理のページによると、既存のParquetファイルを上書きした場合、開いている接続は短時間だけ古いデータを読むことがあります。接続し直せば最新のデータが返り、キャッシュを消す必要はありません。同じプレフィックスに新しいファイルを追加した場合は、次のクエリで自動的に検出されます。

pg_duckdbとは何が違いますか？

どちらもPostgreSQLの中でDuckDBを動かしますが、提供形態が違います。aurora_analyticsはAuroraの管理機能として組み込まれ、IAMロール・パラメータグループ・CloudWatchの指標と一体で運用する仕組みです。pg_duckdbはDuckDB公式のオープンソース拡張で、自分で管理するPostgreSQLに入れて使います。Auroraを使い続けるならaurora_analytics、自前のPostgreSQLを運用しているならpg_duckdbが検討の対象です。

関連記事

• Aurora PostgreSQLとは？対応バージョン・拡張機能とBabelfish・RDSからの移行判断を実装者目線で解説
• DuckDBとは？特徴・用途とSQLite・PostgreSQLとの違いを実測で解説
• Apache IcebergとParquetの違い｜テーブル形式とファイル形式の関係を整理
• ETLとは？仕組み・ELTとの違い・ツール選定から導入判断まで解説
• PostgreSQL 19の新機能｜Beta 4時点の確定機能と差し戻し・18からの移行で壊れる箇所