固定のインスタンス料金がないデータベースは、上限が見えない代わりに、使った分だけ請求が伸びる。Aurora DSQL を本番に寄せ始めた運用担当が最初に困るのは、「今月いくら使っていて、どこで気づけるのか」だろう。2026年10月13日に公式ブログが、コンソールでの確認と CloudWatch アラームによる見張り方を整理した。その要点を、運用の手順に落とす。
この記事の結論
- 費用の単位は DPU（Distributed Processing Unit）。コンピューティング・読み取り・書き込みを合計した TotalDPU が基本になる。ストレージは DPU とは別に容量で課金される。
- コンソールの Usage and cost パネルで、DPU の合計・推定コスト・ストレージの大きさを期間別に見られる。内訳は CloudWatch で見る。
- アラームは
AWS/AuroraDSQLのTotalDPUを、合計・1 時間の期間で置く。しきい値は月間予算の 1 時間分の 80% が目安。 - 1 時間単位の判定なので、月初からの累計は追わない。累計は AWS Budgets を併用する。
- CDC（StreamDPU）やマルチリージョン（MultiRegionWriteDPU）は、別のメトリクスを別に見る。
何が起きたか
公式ブログは、Aurora DSQL のコストを、コンソールと CloudWatch アラームで見張る方法を示した。コンソールのクラスターの Summary タブにある Usage and cost パネルでは、過去 24 時間・7 日間・30 日間の DPU 合計と推定コスト、ストレージの大きさを確認できる。ただし、読み取り・書き込み・コンピューティングの内訳はここには出ない。内訳は Monitoring タブの CloudWatch グラフで見る。マルチリージョンのクラスターは、リージョンごとにコンソールで見る。アラームは AWS/AuroraDSQL 名前空間の TotalDPU を、統計は Sum、期間は 1 時間で置く。しきい値は、月間予算で許容できる DPU を 730 時間で割って 1 時間分を求め、その 80% を目安にする。通知は SNS で受ける。単価は公式の料金ページで確かめて、予算の DPU への換算に使う。公式ブログ（日本語）
仕組みとして何が変わったか
固定のインスタンス料金という上限がない代わりに、使った量が直接費用になる。そのため「どこで気づくか」を運用側が決める必要がある。見張りは3段に分ける。
Aurora DSQL のコスト
3段で見張る：把握・気づく・累計
-
コンソールで把握する
Usage and cost：DPU 合計・推定コスト
-
CloudWatch アラームで気づく
TotalDPU を 1 時間の合計で見る
-
AWS Budgets で累計を押さえる
月初からの積み上げは別に置く
| 見たいもの | 使うもの | 注意 |
|---|---|---|
| 期間ごとの合計と推定コスト | コンソールの Usage and cost | 内訳は出ない |
| 読み書きの内訳 | Monitoring タブの CloudWatch グラフ | コンソールの別画面 |
| 1 時間ごとの急な増加 | TotalDPU のアラーム |
累計は追わない |
| 月初からの累計 | AWS Budgets | アラームとは別に置く |
| CDC のコスト | StreamDPU のアラーム |
ストリームごと |
| マルチリージョンの書き込み | MultiRegionWriteDPU |
リージョンごとにアラームを置くと場所を特定しやすい |
CHECK 1ここまでの確認
Aurora DSQL のコンソールの Usage and cost パネルで確認できないものはどれか?
答えと解説
答え: 2. 読み取り・書き込み・コンピューティングの DPU の内訳
内訳はパネルには出ず、Monitoring タブの CloudWatch グラフで見る。「コンソールで見えるもの」の項を読み直す。
1 時間単位の判定には癖がある。月全体では予算内でも、ある 1 時間の山でアラームが鳴ることがあるし、緩やかな増加が続いて累計だけ予算を超える場合には鳴らない。急増の検知（アラーム）と累計の管理（Budgets）は役割を分けて両方置く。メトリクスはほぼリアルタイムだが、わずかな遅延がある。EXPLAIN ANALYZE VERBOSE が示す DPU の値は目安で、請求額の正確な値ではない。
CHECK 2ここまでの確認
TotalDPU の 1 時間アラームだけでは防げないのはどれか?
答えと解説
答え: 2. 月初からの累計が予算に近づいていること
アラームは 1 時間ごとの判定で、累計は追わない。累計の追跡には AWS Budgets を併用する。
どんなものに活用できそうか
- 本番投入前の予算ガード。 月の予算から 1 時間分の DPU を割り出し、その 80% にアラームを置いて、負荷試験の段階から通知の頻度を見る。
- バッチやマイグレーションの暴走の検知。 夜間の大量書き込みが想定より重いとき、翌朝の請求ではなく数時間以内に気づける。
- マルチリージョン構成の原因切り分け。 リージョンごとにアラームを置いておけば、増えた場所がすぐ分かる。
使わない方がよい場面もある。アラームだけで月の予算管理を済ませる使い方は避ける。累計は追えないので、Budgets を併用する。
立場ごとに何が変わるか
- 未経験: いまは関係ない。まずはデータベースの種類と、課金の単位が違うという考え方だけ掴めれば足りる。
- 学習中: 「使った分だけ課金される」サービスでは、費用の監視も設計の一部だという例になる。CloudWatch アラームの基本の復習にもなる。
- 実務: Aurora DSQL を使う、または検討している案件では、アラームと Budgets を最初から設計に入れる。
- プロ: 予算を DPU に換算する考え方、CDC・マルチリージョンの別メトリクス、アラームの限界を、運用設計のレビュー項目にする。
まとめ
DPU で使った分だけ費用が出るデータベースでは、「上限がない」ことが運用の不安になる。コンソールで全体を掴み、TotalDPU のアラームで急増に気づき、Budgets で累計を押さえる、という3段で見張れば、サーバーレスの利点を残したまま費用を追える。CDC やマルチリージョンを使うなら、そのぶんのメトリクスも忘れずに足す。
参照ソース
- Aurora DSQL コンソールと CloudWatch アラームで Amazon Aurora DSQL のコストをモニタリングする（2026年10月時点）
- Amazon Aurora DSQL の料金（2026年10月時点。単価・無料利用枠はこのページで確認する）
