Amazon Aurora DSQLとは？DPU課金の仕組みとPostgreSQL非対応機能・採用可否の判断基準

Amazon Aurora DSQLは、2024年12月3日にプレビューとして発表され、2025年5月27日に一般提供（GA）が開始されたサーバーレスの分散リレーショナルデータベースです。PostgreSQL 16互換をうたいながら外部キーやトリガーには対応せず、課金単位もインスタンス時間ではなくDPU（Distributed Processing Unit）へ置き換わっています。つまり「PostgreSQL互換」という言葉から想像する移行の手軽さと、実際に必要な書き換え量には差があります。この記事では、AWS公式ドキュメントとAWS Price List APIで確認した2026年8月時点の料金・上限値・非対応機能を整理し、どのワークロードなら採用でき、どこで想定外のコストと改修が発生するのかを判断できる材料をまとめます。

まとめ

• Aurora DSQLは2025年5月27日にGA。プレビュー期間は終了しており、2026年8月時点で東京・大阪を含む20リージョンで利用できます。
• 課金はDPUとストレージの2項目のみ。東京リージョンの単価は1 DPUあたり0.00001ドル（100万DPUで10ドル）、ストレージは0.40ドル／GB・月で、毎月10万DPUと1GBは無料枠です。
• PostgreSQL 16互換ですが、外部キー・トリガー・PL/pgSQL・一時テーブル・TRUNCATEは使えません。整合性チェックはアプリケーション層へ移す前提の設計です。
• 1トランザクションで変更できるのは3,000行・10 MiB・5分まで。接続は60分でタイムアウトします。大量バッチ処理をそのまま持ち込む用途には向きません。
• ロックではなく楽観的同時実行制御（OCC）を使うため、コミット時のシリアライズエラーを前提としたリトライ実装が必須です。
• トランザクション単位の最小課金（読み取り2,048バイト相当、書き込み1,024バイト相当）があり、小さな書き込みを1件ずつ投げる設計はDPUを大きく浪費します。AWSの公式計算例（1行INSERT 0.06175 DPU／100行一括INSERT 0.70875 DPU）から計算すると、100行を1件ずつ挿入した場合のDPUは一括挿入の約8.7倍になります。

Aurora DSQLの現在地とプレビュー版からの変更点

Aurora DSQLは、トランザクション処理に最適化されたサーバーレスの分散リレーショナルデータベースです。アクティブ・アクティブ構成によって、単一リージョンで99.99%、マルチリージョンで99.999%の月間稼働率が正式なSLAとして定められています（2025年5月27日付。下回ると10%、99.0%を割ると25%、95.0%を割ると100%のサービスクレジット）。インスタンスサイズの指定もパッチ適用のためのメンテナンス時間もなく、コンピュート・I/O・ストレージが自動的にスケールします。

GA後に確定した提供条件

GA時点の提供リージョンはバージニア北部・オハイオ・オレゴン・大阪・東京・アイルランド・ロンドン・パリの8つでしたが、2026年8月時点では20リージョンまで拡大しています。プレビュー期間中に書かれた「利用可能なリージョンは限定的」「本番利用は不可」といった前提は、すでに当てはまりません。

GA後に追加された機能のうち実務上の影響が大きいのは次の2つです。1つは2025年11月に追加された、クエリプランへの文単位コスト見積り表示。もう1つは2026年7月8日に一般提供が始まった変更データキャプチャ（CDC）で、挿入・更新・削除の結果を変更イベントとしてAmazon Kinesis Data Streamsへ配信できます。CDCを有効にしたクラスターにはStream DPUが加算されます。

データベース層を支える構成要素

Aurora DSQLは、リレーおよび接続、コンピュートとデータベース群、トランザクションログ・並行性制御・分離、ストレージという4つのマルチテナントコンポーネントで構成され、コントロールプレーンがこれらを統括します。AWSはこの構造を「クエリ処理層・コミット層・ストレージ層がそれぞれ独立してスケールする」と説明しており、DPUがコンピュート・読み取り・書き込みに分かれて計測されるのもこの分離に対応しています。各コンポーネントは3つのアベイラビリティーゾーン（AZ）にまたがって冗長化されており、障害時は健全なインフラへ自動的にリクエストが振り向けられます。従来のAuroraのようにライターとリーダーを意識してフェイルオーバーを設計する作業自体が不要になる、という点が構造上の違いです。

DPU課金の内訳と東京リージョンの実単価

Aurora DSQLの請求書に並ぶ項目は、DPUとストレージの2つだけです。ただしDPUは内部的に複数の要素の合計であり、どの操作がどの要素を押し上げるのかを理解しないとコストを見積もれません。

DPUを構成する5つの要素と計算式

単一リージョンのクラスターでは、1トランザクションのDPUはコンピュート・読み取り・書き込みの3要素の合計です。マルチリージョンではMultiRegion Write DPU、CDC有効時はStream DPUが加算されます。

読み取りは「返した行」ではなく「スキャンした行」で課金されます。AWSの計算例では、100行をスキャンして条件で10行に絞り込むクエリは100行分のRead DPUを請求されます。丸めは読み書きの双方にあります。書き込みは128バイト未満の行を128バイトとして計算し、読み取りは1ストレージパーティションあたりの応答が128バイト未満の場合に128バイトへ切り上げます。さらに書き込みトランザクションは、主キーの一意性確認のためにRead DPUも発生します。

東京リージョンの単価と無料枠

単価はリージョンごとに異なります。AWS Price List API（AuroraDSQLの版20260714190804）で確認した実値は次のとおりです。AWS公式の料金ページが見出しに掲げる「100万DPUあたり8ドル」はオハイオ（us-east-2）基準の数字であり、東京は25%高い点に注意してください。

AWSの公式計算例にある1行INSERT（0.06175 DPU）を東京の単価に当てはめると、100万回で0.62ドルです。同じく単一行の点検索（0.00675 DPU）なら100万回で0.07ドルにとどまります。小規模なサービスであれば毎月の無料枠10万DPUだけで、1行INSERT換算でおよそ162万回分をまかなえる計算になります。アイドル時はDPU消費がスケールゼロし、時間単位の最低料金もないため、断続的にしかアクセスがないワークロードではプロビジョニング型より安くなります。ただし完全にゼロ円にはならず、ストレージ料金と、統計更新やコンパクションといったバックグラウンド処理の分は発生します。単価は改定されるため、最終的な金額はAWS公式の料金ページで確認してください。

コストを支配するのはトランザクション最小課金

Aurora DSQLのコストで最初に効いてくるのは、行数でもデータ量でもなくトランザクションの粒度です。読み取りは合計2,048バイト未満でも2,048バイト分（0.00375 DPU）、書き込みは1,024バイト未満でも1,024バイト分（0.05 DPU）が課金されます。128バイトの行を1件挿入しても、行サイズの8倍にあたる1,024バイト分で請求されるということです。

AWSの公式計算例から計算すると差は明確です。100行を1件ずつ挿入すると0.06175 DPU × 100 = 6.175 DPU、同じ100行を1文の一括INSERTにまとめると0.70875 DPUで、約8.7倍の開きが出ます（コンピュート時間はAWSの例が置いた前提値なので、実際の比率は処理時間に依存します）。ORMのループで1行ずつ保存する実装や、レコード単位でトランザクションを切るバッチ処理をそのまま持ち込むと、この差がそのまま請求額に乗ります。移行前に、書き込みをまとめられる箇所を洗い出しておくべきです。

見積りにはEXPLAIN ANALYZE VERBOSEを使います。Aurora DSQLはこの出力の末尾に文単位のDPU見積りを追加します。VERBOSEを付けないEXPLAIN ANALYZEではDPU情報は出力されません。

EXPLAIN ANALYZE VERBOSE SELECT * FROM test_table;

Statement DPU Estimate:
  Compute: 0.01607 DPU
  Read: 0.04312 DPU
  Write: 0.00000 DPU
  Total: 0.05919 DPU

トランザクション最小課金が効く場合は、Read: 0.00307 DPU (Transaction minimum: 0.00375) のように括弧で最小値が併記されます。1文だけのトランザクションを見積もるときは、括弧内の値を採用してください。

ただしAWSはこの値を「請求グレードの指標ではない」と明示しています。文単位の見積りである一方、実際の課金はトランザクション単位の最小値が適用され、CloudWatchには非同期ANALYZEやコンパクションなどのバックグラウンド処理も含まれるためです。クエリ間の相対比較とチューニングに使い、確定値はCloudWatchのTotalDPUや請求レポートで確認する、という使い分けになります。

PostgreSQL互換の実際の範囲と移行時の書き換え箇所

Aurora DSQLはPostgreSQL 16をベースにしており、パーサー・プランナー・オプティマイザ・型システムといった中核部品と、標準のPostgreSQL v3ワイヤプロトコルを使います。psqlや既存のドライバー、主要なORMはそのまま接続できます。ただし認証はパスワードではなくIAMで、aws dsql generate-db-connect-admin-auth-token（管理者以外はgenerate-db-connect-auth-token）で発行した期限付きトークンをパスワード欄に渡します。既定の有効期限は15分、最長で604,800秒（1週間）です。接続確立後はトークンが失効しても接続自体は有効なままなので、詰まるのは再認証のタイミング設計、つまり接続プールの側です。もう一方の移行工数の実体が、分散アーキテクチャを成立させるために落とされた機能です。

非対応の機能と代替手段

シーケンスは「対応」ですが、既存スキーマをそのまま持ち込めるという意味ではありません。CREATE SEQUENCEはCACHEの明示指定を必須とし、受け付ける値はCACHE 1または65536以上に限られます。データ型もbigintのみです。サポートされるデータ型の一覧にserial・bigserialは含まれないため、連番の主キーをSERIALで定義している既存スキーマは、GENERATED AS IDENTITYか明示的なCREATE SEQUENCEへの書き換えが必要です。なおCACHEを65536以上にすると値の一意性は保たれますが、セッションをまたいだ厳密な昇順は保証されず、欠番も生じます。

jsonとjsonbも利用できます。1 MiBの上限は圧縮後のサイズに対して適用されるため、圧縮が効けば1 MiBを超える値も格納できます。ただしインデックスは張れないので、JSON内の属性で絞り込む設計は避けてください。「Aurora DSQLはJSON非対応」と書かれた解説は2026年前半までの情報です。

インデックス作成も構文が変わります。既存の行があるテーブルへインデックスを追加する場合は、CREATE INDEXではなくCREATE INDEX ASYNCを使います。このコマンドはロックを取らずジョブIDを即座に返すため、進捗はsys.jobsビューで確認し、完了を待つ必要があればsys.wait_for_job(job_id)で待機します。ビルドに失敗したインデックスは定義が残ったままINVALID状態になり、自動では削除されません。DROP INDEXで手動削除してから作り直す必要があります。データベースはUTF-8、照合順序はCのみ、システムタイムゾーンはUTC固定で、トランザクション分離レベルはRepeatable Readに固定されています。分離レベルをSerializableへ引き上げる、といった調整はできません。

楽観的同時実行制御を前提としたリトライ実装

Aurora DSQLはロックを取得せず、楽観的同時実行制御（OCC）でコミット時に競合を検出します。トランザクションがロック待ちでブロックされることがないためデッドロックは発生せず、遅いトランザクションが他をふさぐこともありません。その代わり、競合したトランザクションはシリアライズエラーで失敗します。

したがって、リトライ処理はオプションではなく前提条件です。捕捉すべきはSQLSTATE 40001で、内訳は2種類あります。同じ行を2つのトランザクションが更新しようとした場合のOC000（change conflicts with another transaction）と、セッションが保持するスキーマカタログのキャッシュが古くなった場合のOC001（schema has been updated by another transaction）です。後者はCREATE TABLEやALTER TABLEだけでなくGRANT・REVOKEでも発生するため、マイグレーション実行中にアプリ側が受け取る点に注意してください。トランザクションを冪等に設計し、これらを捕捉して再実行する仕組みを組み込む必要があります。AWSはあわせて、更新をキー空間に分散させるためにランダムな主キー（UUIDなど）を使うことを推奨しています。連番の主キーは書き込みが特定のパーティションに集中し、OCC競合の発生源になります。競合の実測はCloudWatchのOccConflictsメトリクスで追えます。

トランザクションとクラスターの上限値

移行可否を左右する数値上限は次のとおりです。とくに1トランザクション3,000行という制限は、既存のバッチ処理をそのまま持ち込めるかどうかの分かれ目になります。

加えて、DDLとDMLは同一トランザクションに混在できず、1トランザクションに含められるDDLは1文までです。マイグレーションツールが複数のDDLを1トランザクションにまとめて発行する構成になっている場合は、その前提から見直す必要があります。

マルチリージョンクラスターとwitnessリージョンの制約

マルチリージョンクラスターは、2つのリージョンにピアリングされたクラスターと、3つ目のwitnessリージョンで構成されます。ピアリングされた2つはそれぞれリージョナルエンドポイントを持ち、両方が読み書き可能なまま単一の論理データベースとして振る舞い、強い整合性を保ちます。witnessリージョンはエンドポイントを持たず、暗号化されたトランザクションログを限られた期間だけ保持して、コミット時のクォーラム判定に加わります。片方のアクティブリージョンが停止しても、残るアクティブリージョンとwitnessで多数派が成立するため、トランザクションは止まりません。

作成手順はwitnessリージョンの指定から始まります。ピアになる2つのクラスターを同じwitnessリージョンを指定して作成し、そのうえで互いのARNを登録してピアリングを成立させます。

aws dsql create-cluster \
  --region ap-northeast-1 \
  --multi-region-properties '{"witnessRegion":"ap-northeast-2"}'

aws dsql create-cluster \
  --region ap-northeast-3 \
  --multi-region-properties '{"witnessRegion":"ap-northeast-2"}'

aws dsql update-cluster \
  --region ap-northeast-1 \
  --identifier 'foo0bar1baz2quux3quuxquux4' \
  --multi-region-properties '{"witnessRegion":"ap-northeast-2","clusters":["arn:aws:dsql:ap-northeast-3:111122223333:cluster/foo0bar1baz2quux3quuxquux5"]}'

同じupdate-clusterを大阪側にも実行して双方向にピアを登録すると、両クラスターがPENDING_SETUPからCREATINGを経てACTIVEになります。片側だけではセットアップは完了しません。

日本国内で完結しないデータ配置

マルチリージョンクラスターを構成できる組み合わせはリージョンセット内に限られ、大陸をまたぐ構成はサポートされていません。アジアパシフィックのセットはムンバイ・大阪・ソウル・シンガポール・東京の5つです。

ここに日本国内のシステムにとって見落としやすい制約があります。日本にあるリージョンは東京と大阪の2つだけなので、この2つでマルチリージョンクラスターを組むと、3つ目のwitnessリージョンは必然的にソウル・シンガポール・ムンバイのいずれか、つまり国外になります。witnessは完全なデータのコピーを保持しませんが、暗号化されたトランザクションログを一定期間保持します。「データを国内に閉じる」ことが要件になっている案件では、この点を単一リージョン構成を選ぶ理由として最初に検討すべきです。単一リージョン構成でも3つのAZにまたがる冗長性と99.99%の可用性設計は得られます。

マルチリージョンでは課金も増えます。ピアリージョンへの書き込みはMultiRegion Write DPUとして、元の書き込みDPUと同額が追加で発生します。8 DPUの書き込みトランザクションは、合計16 DPU相当になる計算です。ストレージ料金もリージョンごとに個別に課金されます。一方、witnessリージョンにはDPUもストレージも課金されません。

Aurora PostgreSQL・DynamoDBとの使い分け

Aurora DSQLが向くのは、リレーショナルなデータモデルとACIDトランザクションを必要としつつ、トラフィックの変動が大きく、運用の手離れを優先したいワークロードです。マイクロサービス、サーバーレス、イベント駆動型アーキテクチャのバックエンドが典型例になります。

逆に、次のいずれかに当てはまるなら現時点では見送りを推奨します。第一に、外部キー・トリガー・PL/pgSQLに依存した既存スキーマをそのまま載せ替えたい場合。互換性の看板とは裏腹に、アプリケーション層への書き換えが必ず発生します。第二に、数万行単位の一括更新を行うETLやバッチ処理。3,000行・10 MiB・5分の上限に阻まれ、分割設計が必須になります。第三に、集計や分析が主体のクエリ。返した行ではなくスキャンした行にRead DPUが課金されるため、フルスキャンを伴う分析用途はコスト効率が悪化します。第四に、データを国内に閉じたうえでマルチリージョン化したい場合です。

プロビジョニング型の性能特性やバージョン管理を握りたい、あるいはPostgreSQLの拡張機能を使いたいなら、従来のAmazon Auroraが引き続き適します。負荷変動への追随を重視しつつPostgreSQLの機能を落としたくない場合は、Amazon Aurora Serverless v2が中間の選択肢になります。キーバリューのアクセスパターンが中心で結合を必要としないなら、DynamoDBのほうが単純です。Aurora DSQLは、この3つのどれでもない「SQLとACIDは必要だが、インスタンス管理はしたくない」という領域を埋めるサービスです。AWSの外まで視野を広げると、Google Cloud SpannerやCockroachDBと同じ分散SQL（NewSQL）の系譜にあたり、Aurora DSQLはそこにPostgreSQL互換とDPU従量課金という組み合わせで加わった選択肢だと捉えると位置づけが整理できます。

バックアップと運用まわりの前提

バックアップはAWS Backupとの統合で提供され、クラスター全体のバックアップ、スケジュールと保持ポリシーの自動化、クロスリージョンおよびクロスアカウントのコピー、Vault LockによるWORM（追記のみ）構成に対応します。運用設計で押さえておくべきなのは、復元の挙動です。AWS Backupはリストア時に必ず新しいクラスターを作成し、元のクラスターを上書きしません。既存クラスターを特定時点の状態に戻すという操作にはならないため、切り戻し手順はエンドポイントの切り替えを含めて設計する必要があります。マルチリージョンクラスターを復元する場合は、事前に対象となる全リージョンへ同一のバックアップコピーを用意しておくことが条件です。

監視面では、DPU系メトリクス（ReadDPU、WriteDPU、ComputeDPU、TotalDPU）に加えて、ClusterStorageSize、TotalTransactions、QueryTimeouts、OccConflictsがCloudWatchへ発行されます。OCC競合とクエリタイムアウトはアプリケーション設計の問題を映すため、DPUのアラームと合わせて最初に監視対象へ入れておくべき指標です。

よくある質問

Aurora DSQLはいつからプレビューではなく本番利用できますか？

2025年5月27日に一般提供（GA）が開始され、プレビュー期間は終了しています。GA時点では8リージョンでしたが、2026年8月時点では東京と大阪を含む20リージョンで利用できます。

Aurora DSQLの料金はいくらですか？

課金対象はDPUとストレージの2つだけです。東京リージョンでは1 DPUあたり0.00001ドル（100万DPUで10ドル）、ストレージは0.40ドル／GB・月です。オハイオリージョンはそれぞれ0.000008ドル、0.33ドル／GB・月と安価です。全リージョン共通で毎月10万DPUと1GB・月の無料枠があり、アイドル時はDPU消費がスケールゼロして時間単位の最低料金もかかりません。ただしストレージ料金とバックグラウンド処理分は発生します。

Aurora DSQLとAurora PostgreSQLの違いは何ですか？

Aurora PostgreSQLはインスタンス（またはACU）を割り当てるプロビジョニング型で、PostgreSQLの拡張機能や外部キー、トリガー、PL/pgSQLをそのまま使えます。Aurora DSQLはインスタンスの概念がないサーバーレスの分散型で、課金はDPU従量、代わりに外部キーやトリガーなど一部の機能に対応しません。既存スキーマの移行のしやすさではAurora PostgreSQL、運用の手離れと自動スケールではAurora DSQLが優位です。

既存のPostgreSQLアプリケーションはそのまま動きますか？

接続レイヤーは標準のPostgreSQL v3ワイヤプロトコルなので、ドライバーや主要なORMはそのまま使えます。ただし外部キー制約、トリガー、PL/pgSQL、一時テーブル、TRUNCATEは非対応で、これらを使っていれば書き換えが必要です。認証もパスワードではなくIAMで発行する期限付きトークンに変わり、既定の有効期限は15分です。加えて、コミット時のシリアライズエラー（SQLSTATE 40001）を再試行するリトライ処理の実装が前提になります。

1トランザクションで扱えるデータ量に制限はありますか？

変更できるのは3,000行まで、変更データ量は10 MiBまで、実行時間は5分までです。いずれも引き上げできません。読み取りの行数自体に上限はありませんが、5分のトランザクションタイムアウトに収まる必要があります。

関連記事

• Amazon Auroraとは？仕組み・RDSとの違いと料金モデル・採用判断を実装者目線で解説
• Amazon Aurora Serverless v2とは？料金・スケーリングの仕組みとv1移行を解説
• Aurora MySQL 8.4の全体像と移行を検討する読者が押さえる前提
• ScalarDB Clusterとは｜異種DB横断でACIDを実現する構造・ライセンス・Kubernetes導入を解説