同じ業務の費用と選択基準
DSQLの性能・利便性の利点には、どのような費用・制約が伴うか？
結果の要約
この実験では、同じ業務と同じ遅延目標を守る場合に、DSQLと既存サービスの費用が負荷の形によってどう変わるかを計算しました。最小範囲（MVP）として、新たにAWSリソースを立ち上げず、E002（スループット・DPU・ACU）とE009（アイドル時の動作）で測定した値にソウルリージョンのオンデマンド単価を掛けました。業務はE002の注文の組み合わせ（商品照会40%、注文履歴30%、注文作成20%、キャンセル10%）です。
DSQLは処理した量だけDPUで課金され、この業務ではリクエスト1回あたり0.029–0.032 DPUを使いました。ソウルの単価（100万DPUあたり$10）でリクエスト100万件あたり約$0.31、1,000 TPSを1時間維持すると約$1.12です。一方、RDS Multi-AZ（db.r6g.xlarge、gp3 400 GiB）は負荷に関係なく時間あたり約$1.22で、SLO内で5,839 TPSまで処理しました。したがって平均負荷が約1,100 TPSより低ければDSQLが安く、それより高い負荷が続けば固定インスタンスが安くなります。Aurora Provisioned（writer+reader、時間あたり約$1.25 + I/O）も同様の損益分岐を示します。
負荷の形によって差は大きくなります。1,000 TPSで24時間一定の負荷では、1日の費用はDSQL約$27、RDS Multi-AZ約$29でほぼ同じでした。8時間だけ1,000 TPSで稼働し16時間休むサービスでは、DSQL約$9、RDS約$29で、DSQLは約3分の1でした。リードレプリカを置いたAurora Serverless v2（A2）はwriterとreaderが一緒に拡大するため1,000 TPSで時間あたり約$3.4となり、最小容量のためにアイドル時間にも課金されて1日約$53でした。0 ACUの自動一時停止を使うと約$27に下がりますが、E009では最初の接続が15秒を超えて失敗しました。
本番利用の観点
費用だけを見ると、DSQLは「リクエストが少ない、または不規則なサービス」に有利で、「高い負荷が一日中続くサービス」には不利です。今回の業務での損益分岐は平均約1,100 TPSでした。それより低い負荷では、固定インスタンスを常時稼働させる費用がなくなり、高可用性も標準で含まれるためDSQLが安くなります。逆に数千TPSを継続して処理すると、リクエスト数に比例するDPU料金が固定インスタンスを上回ります。大きな集計も処理量に応じて課金されるため（E012）、分析業務が多いサービスは別途費用を計算する必要があります。この計算は1つの業務の組み合わせ、オンデマンド単価、1回の測定値に基づく推定です。
確認する問い
DSQLの性能・利便性の利点には、どのような費用・制約が伴うか？
実行条件
- 追加のAWS実行: なし。以下の測定値と単価で計算しました。
- 測定値の出典:
- DSQLのリクエストあたりDPU: E002の2回目の測定の2,400–26,285 TPSセルで、CloudWatch
TotalDPUの分ごとの合計 ÷ リクエスト試行数 = 0.029–0.032（計算には0.031を使用）。 - A2のACU: E002の1回目の測定セルにおけるwriter・readerの平均ACU。100–400 TPSで各5、1,600 TPSで各12、5,657 TPSで各28、11,559 TPS以上で各32（上限）。
- サービスごとのSLOを満たした最高スループット: E002（R1 5,839、A1 3,375、A2 11,559、DSQL 24,541 TPS以上）。
- アイドル時の動作: E009（A2は自動一時停止後の最初の接続が15秒超過で失敗、DSQLは即時応答）。
- DSQLのリクエストあたりDPU: E002の2回目の測定の2,400–26,285 TPSセルで、CloudWatch
- 単価（ソウル、オンデマンド、USD）: DSQL 100万DPUあたり$10、RDS PostgreSQL
db.r6g.xlargeMulti-AZ $1.079/h + gp3 400 GiB 2セット約$0.144/h、Auroradb.r6g.xlargeStandard $0.627/h（writer・readerの2台）、Aurora Serverless v2 Standard $0.20/ACU-h、Aurora I/O 100万あたり$0.24。確認日は2026-09-27（RDS・Aurora）と2026-09-11公開版（DSQL）。 - 含めなかったもの: ストレージ（ソウルでDSQL $0.40/GB-月、Aurora $0.12/GB-月、RDS gp3 $0.131/GB-月。今回の5 GiBのデータならDSQLは1日約$0.07と小さいですが、データが数TBに増えると、DSQLのストレージ単価がAuroraの約3.3倍である点が重要になります。DSQL単価の出典: AWS Price List API 2026-09-11公開版）、Aurora I/O（負荷ごとに分けて測定できなかった）、バックアップ、ネットワーク、負荷発生器、コミットメント割引とクレジット。
- 計画から変わった点： 24時間・8+16時間・急増のパターンを実際には実行せず、測定した単価で換算しました。成功業務100万件あたりの費用は、負荷時間に合わせた時間単価で代わりに計算しました。
性能結果
負荷ごとの時間あたり費用
| 平均負荷 | DSQL | RDS Multi-AZ（R1） | Aurora Provisioned（A1） | Aurora Serverless v2（A2） |
|---|---|---|---|---|
| 100 TPS | $0.11 | $1.22 | $1.25 + I/O | $2.0（10 ACU） |
| 400 TPS | $0.45 | $1.22 | $1.25 + I/O | $2.0（10 ACU） |
| 1,000 TPS | $1.12 | $1.22 | $1.25 + I/O | 約 $3.4（約17 ACU、補間） |
| 1,600 TPS | $1.79 | $1.22 | $1.25 + I/O | $4.8（24 ACU） |
| 5,657 TPS | $6.3 | $1.22 | SLO超過 | $11.2（56 ACU） |
| 11,559 TPS | $12.9 | SLO超過 | SLO超過 | $12.8（64 ACU、上限） |
| 24,541 TPS | $27.4 | SLO超過 | SLO超過 | SLO超過 |
- DSQLの費用 = 負荷（TPS）× 3,600 × 0.031 DPU × $10 / 100万。負荷が大きくなるほどリクエストあたりDPUがわずかに減るため、高負荷ではやや過大な推定です。
- 「SLO超過」は、E002でその負荷を遅延目標内で処理できなかった構成です。より大きなインスタンスに変えれば処理できますが、その費用は測定していません。
- A2はHAのためにreaderをwriterと同じ容量に追従させた構成です。readerがなければA2の費用は約半分になりますが、フェイルオーバー用の待機レプリカがありません。DSQLとR1はマルチAZの高可用性が価格に含まれています。
1日の費用シナリオ
| 負荷の形 | DSQL | R1 | A1 | A2 | 備考 |
|---|---|---|---|---|---|
| 1,000 TPS × 24時間 | 約 $27 | 約 $29 | 約 $30 + I/O | 約 $82 | 一定の負荷 |
| 1,000 TPS × 8時間 + 16時間アイドル | 約 $9 | 約 $29 | 約 $30 + I/O | 約 $53 | A2はアイドル時に最小4 ACU × 2 |
| 上と同じ、A2自動一時停止 | 約 $9 | - | - | 約 $27 | A2の最初の接続が15秒超過（E009） |
| 1,000 TPS × 23時間 + 10,000 TPS × 1時間 | 約 $37 | 処理不可 | 処理不可 | 約 $91 | 1時間の急増 |
- 損益分岐: DSQLがR1と同じ費用になる平均負荷は $1.22 ÷ ($0.31 × 3,600 / 100万) = 約1,100 TPSです。
開発・運用のしやすさ
- DSQLは容量を選んだり最小・最大容量を決めたりする作業がないため、費用の予測が「リクエスト数 × リクエストあたりDPU」と単純です。ただし、リクエストあたりDPUは業務のクエリによって異なるため、実際の業務で測定する必要があります。
- DSQLは負荷の増加に合わせてインスタンスを大きくする作業が不要でした。固定インスタンスはE002で256接続の負荷をSLO内で処理できなかったため、その負荷をまかなうにはより大きなインスタンスを選ぶ必要があります。
- 人の作業時間はE011で別途扱っており、この表には金額として合算していません。
費用
このレポート自体はAWSリソースを作成していません。参考として、今回の研究全体の実験費用は次のとおりです。
| 実行 | 範囲 | 費用 | 根拠 |
|---|---|---|---|
| E001 | SQL互換性 | 約 $0.08 | Cost Explorerの請求額 |
| E004 | 競合と整合性 | 約 $2.07 | Cost Explorerの請求額 |
| E002 1回目 | 4構成のパイロット・探索 | $48.57 | Cost Explorerの請求額 |
| E002 2回目 + E003・E008・E012 | DSQL単独 | $18.54 | Cost Explorerの請求額（推定約$18.6） |
| E005・E006・E007・E009 | 小規模のD1・A2 | $5.07 | Cost Explorerの請求額（推定約$5.1） |
| 2026-09-29の2実行で共用 | AZ間転送・EBS・パブリックIPv4 | $0.65 | Cost Explorerの請求額 |
結論と限界
- DSQLの費用はリクエスト数に比例し、固定インスタンスの費用は時間に比例します。今回の業務では、2本の線が交わる点は平均約1,100 TPSでした。
- アイドル時間が長いサービス、負荷が不規則なサービス、高可用性が必要な小さなサービスではDSQLが有利です。高い負荷が続くサービスでは固定インスタンスが安くなります。
- ストレージはDSQLがGB-月あたり$0.40で、Aurora（$0.12）の約3.3倍のため、データが大きいサービスはストレージ費用を別途比較する必要があります。
- 限界: 1つの業務の組み合わせの単位費用を線形に換算した推定です。Aurora I/O、ストレージ、バックアップ、ネットワーク、コミットメント割引は含めておらず、負荷パターンを実際に24時間実行してはいません。A2の1,000 TPSの値は測定点間の補間です。
後片付けの記録
- このレポートは新しいAWSリソースを作成していません。引用した3つの測定実行（
e002-20260928t033404z-e1b1、e002-20260929t081139z-4dce、e002-20260929t082035z-afbe）は、それぞれのレポートで残存リソース0を確認しています（2026-09-28 12:07:44、2026-09-29 11:10:30、10:20:27 UTC）。