# Aurora DSQL での請求の仕組み
Amazon Aurora DSQL では、前払いコストなしで、使用した分のみお支払いいただきます。このセクションでは、Aurora DSQL でデータベースアクティビティを計測し、それを AWS 請求書の料金に変換する方法について説明します。リージョン別の現在の料金については、[Aurora DSQL の料金ページ](https://aws.amazon.com/rds/aurora/dsql/pricing/)を参照してください。
**Topics**
+ [計測の仕組み](#billing-how-metering-works)
+ [DPU コンポーネントの計測の説明](#billing-dpu-components)
+ [マルチリージョン請求](#billing-multiregion-write-dpu)
+ [CloudWatch による DPU 使用状況のモニタリング](#billing-cloudwatch-monitoring)
+ [EXPLAIN ANALYZE VERBOSE を使用したコスト認識](#billing-explain-analyze)
+ [コスト見積もりのベストプラクティス](#billing-best-practices)
## 計測の仕組み
プロビジョニングした容量に対して課金する従来のデータベースとは異なり、Aurora DSQL では実際に実行した作業に対してのみ課金されます。Aurora DSQL は、2 つの主要コンポーネントを計測します。分散処理ユニット (DPU) で測定するデータベースアクティビティと、GiB-月で測定するストレージです。
DPU は、SQL ワークロードを実行するためにシステムが費やす作業量を測定します。シングルリージョンクラスターの場合、これは 3 つのコンポーネント (コンピューティング DPU、読み取り DPU、書き込み DPU) で構成されます。マルチリージョンクラスターの場合は、追加のマルチリージョン書き込み DPU コンポーネントが発生します。詳細については、「[マルチリージョン請求](#billing-multiregion-write-dpu)」を参照してください。
次の表は、Aurora DSQL がデータベースアクティビティを計測するために使用するコンポーネントをまとめたものです。請求書には 2 つの明細項目のみが表示されます。1 つはストレージ用です。もう 1 つは DPU 用で、個々のコンポーネントの合計です。
| 計測単位 | アクティビティタイプ | 測定 |
| --- | --- | --- |
| コンピューティング DPU | クエリ処理 | CPU 時間 |
| 読み取り DPU | データベースからのデータの読み取り | ストレージから読み取られたバイト数 |
| 書き込み DPU | データベースへのデータの書き込み | ストレージに書き込まれたバイト数 |
| Storage | テーブルストレージ | GiB-月 |
## DPU コンポーネントの計測の説明
トランザクションごとに、Aurora DSQL は合計 DPU を、コンピューティング DPU、読み取り DPU、書き込み DPU の 3 つのコンポーネントの合計として計算します。以下のセクションでは、Aurora DSQL で各コンポーネントを計測する方法について説明します。
```
Total DPU = ComputeDPU + ReadDPU + WriteDPU
```
### コンピューティング DPU
コンピューティング DPU は、結合、関数、集計、ソート、クエリ計画など、クエリの実行に費やされた合計処理時間を使用して測定されます。クエリの一部は並行して処理される場合があるため、コンピューティング DPU はクエリのウォールクロック時間ではなく、すべての処理時間の合計を反映します。
次の式は、コンピューティング DPU の計算方法を示しています。
```
ComputeDPU = Total Compute time (in seconds)
```
### 書き込み DPU
トランザクションごとに、Aurora DSQL はストレージに書き込まれた合計バイト数で書き込み DPU を測定します。書き込み DPU には、ベーステーブルに書き込まれた合計データとセカンダリインデックスが含まれます。Aurora DSQLは、ベーステーブルおよびセカンダリインデックスに書き込まれた 128 バイト未満の各行を、128 バイトとして計算して請求します。Aurora DSQL は、1,024 バイト未満の書き込みトランザクションを、1,024 バイトを書き込んだものとして請求します。
**注記**
Aurora DSQL はプライマリキーインデックスを読み取って一意性を検証してから書き込みを行うため、書き込みオペレーションにも読み取り DPU 料金が発生します。
次の式は、書き込み DPU を計算するステップを示しています。
**ステップ 1: 書き込まれたバイト数を計算する**
```
Bytes Written = Sum of max(size of each row, 128 bytes) for all rows written
```
**ステップ 2: 書き込み DPU を計算する**
```
WriteDPU = max(Bytes Written, 1024) × 0.00004883
```
### 読み取り DPU
トランザクションごとに、Aurora DSQL は、ストレージから読み取った合計バイト数で読み取り DPU を測定します。読み取り DPU には、ベーステーブルから読み取られたデータとセカンダリインデックスが含まれます。
**パーティションあたりの最小値:** Aurora DSQL は、行ごとではなく、ストレージパーティションごとに読み取られたバイト数を測定します。ストレージパーティションへの読み取りリクエストが 128 バイト未満を返す場合、Aurora DSQL はそれを 128 バイトに切り上げます。例えば、クエリが 4 つのパーティションから読み取るとします。1 つのパーティションからは 200 バイト、他の 3 つの各パーティションからは 50 バイトを読み取る場合、3 つの 50 バイトの読み取りはそれぞれ 128 バイトに切り上げられ、合計 200 \+ 128 \+ 128 \+ 128 = 584 バイトとして請求されます。
**トランザクションの最小値:** Aurora DSQL は、合計 2,048 バイト未満の読み取りトランザクションを 2,048 バイトの読み取りとして請求します。
次の式は、読み取り DPU を計算するステップを示しています。
**ステップ 1: 読み取られたバイト数を計算する**
```
Bytes Read = # of rows read × size of each row
```
**注記**
実際に読み取られたバイト数は、ストレージパーティション間でのデータの分散方法によって異なります。パーティションあたりの最小値である 128 バイトが適用されるためです。すべての行サイズが 128 バイトを超える場合は、読み取られた行数に各行のサイズを掛けるだけです。
**ステップ 2: 読み取り DPU を計算する**
```
ReadDPU = max(Bytes Read, 2048) × 0.00000183105
```
### 請求例
以下の例は、Aurora DSQL が一般的なオペレーションの DPU を計算する方法を示しています。これらの例のコスト値では、us-east-1 リージョン料金を使用しています。他のリージョンの料金については、[Aurora DSQL の料金ページ](https://aws.amazon.com/rds/aurora/dsql/pricing/)を参照してください。
#### 例: シンプルなポイントルックアップ (読み取り)
この例では、トランザクションの最小値が適用されるポイントルックアップの読み取り DPU 計算を示します。
**スキーマ:**
```
CREATE TABLE orders (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
customer_id VARCHAR(50) NOT NULL,
order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
total_amount DECIMAL(10,2),
status VARCHAR(20)
);
-- Average row size: ~100 bytes
```
**クエリ:**
```
SELECT * FROM orders WHERE customer_id = 'cust-12345';
```
**シナリオ:** クエリは 5 行 (各行約 100 バイト) を返します。すべての行が 1 つのストレージパーティションに存在すると仮定すると、読み取られる総バイト数は 5 × 100 = 500 バイトです。500 バイトは、パーティションあたりの最小値である 128 バイトを超えているため、パーティションごとの最小値は適用されません。
**読み取り DPU を計算する:**
```
ReadDPU = max(500, 2048) × 0.00000183105 = 2048 × 0.00000183105 = 0.00375
```
500 バイトは 2,048 バイト未満であるため、トランザクションの最小値である 2,048 バイトが適用されます。
**合計トランザクションコスト:**
クエリ実行時間を 3 ミリ秒 (0.003 秒) と仮定します。
```
ComputeDPU: 0.003
ReadDPU: 0.00375
WriteDPU: 0.0
-------------------
Total DPU: 0.00675
```
#### 例: フィルタリングされた範囲スキャン (読み取り)
**スキーマ:**
```
CREATE TABLE orders (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
customer_id VARCHAR(50) NOT NULL,
order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
total_amount DECIMAL(10,2),
status VARCHAR(20)
);
-- Average row size: ~100 bytes
-- Table contains 100 orders for customer 'cust-12345'
```
**クエリ:**
```
SELECT * FROM orders
WHERE customer_id = 'cust-12345'
AND total_amount > 500.00;
```
**シナリオ:** クエリはお客様「cust-12345」について 100 行をスキャンしますが、`total_amount > 500.00` フィルターは結果を減らして 10 行のみを返します。Aurora DSQL は、スキャンされた 100 行すべてに対して請求します。すべての行が 1 つのストレージパーティションに存在すると仮定すると、読み取られる総バイト数は 100 × 100 = 10,000 バイトです。
**読み取り DPU を計算する:**
```
ReadDPU = max(10000, 2048) × 0.00000183105 = 10000 × 0.00000183105 = 0.01831
```
10,000 バイトはトランザクションの最小値である 2,048 バイトを超えているため、実際に読み取られたバイト数が使用されます。
**合計トランザクションコスト:**
クエリ実行時間を 8 ミリ秒 (0.008 秒) と仮定します。
```
ComputeDPU: 0.008
ReadDPU: 0.01831
WriteDPU: 0.0
-------------------
Total DPU: 0.02631
```
**重要**
読み取り DPU コストを最小限に抑えるには、必要な行のみをスキャンするようにクエリとインデックスを設計します。この例では、`(customer_id, total_amount)` にインデックスを追加することで、クエリがスキャンする行数を減少できるようにします。
#### 例: 単一挿入 (読み取りと書き込み)
**スキーマ:**
```
CREATE TABLE orders (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
customer_id VARCHAR(50) NOT NULL,
order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
total_amount DECIMAL(10,2),
status VARCHAR(20)
);
-- Average row size: ~100 bytes
```
**クエリ:**
```
INSERT INTO orders (customer_id, total_amount, status)
VALUES ('cust-67890', 150.00, 'pending');
```
**シナリオ:** 約 100 バイトの 1 行を挿入します。
**書き込み DPU の計算:**
*ステップ 1 - 書き込まれたバイト数を計算する:*
```
1 row × max(100 bytes, 128 bytes) = 1 × 128 = 128 bytes
```
*ステップ 2 - 書き込み DPU を計算する:*
```
WriteDPU = max(128, 1024) × 0.00004883 = 1024 × 0.00004883 = 0.05
```
128 バイトは 1,024 バイト未満であるため、トランザクションの最小値である 1,024 バイトが適用されます。
**読み取り DPU (プライマリキーチェック):**
Aurora DSQL はプライマリキーインデックスを読み取って一意性を検証してから書き込みます。これにより、トランザクションの最小読み取り料金が発生します。
```
ReadDPU = 0.00375 (transaction minimum)
```
**合計トランザクションコスト:**
クエリ実行時間を 8 ミリ秒 (0.008 秒) と仮定します。
```
ComputeDPU: 0.008
ReadDPU: 0.00375
WriteDPU: 0.05
-------------------
Total DPU: 0.06175
```
#### 例: 一括挿入 (読み取りと書き込み)
**スキーマ:**
```
CREATE TABLE orders (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
customer_id VARCHAR(50) NOT NULL,
order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
total_amount DECIMAL(10,2),
status VARCHAR(20)
);
-- Average row size: ~100 bytes
```
**クエリ:**
```
INSERT INTO orders (customer_id, total_amount, status)
VALUES
('cust-001', 100.00, 'pending'),
('cust-002', 150.00, 'pending'),
... -- 100 rows total
('cust-100', 200.00, 'pending');
```
**シナリオ:** 100 行 (各行約 100 バイト) を挿入します。
**書き込み DPU の計算:**
*ステップ 1 - 書き込まれたバイト数を計算する:*
```
100 rows × max(100 bytes, 128 bytes) = 100 × 128 = 12,800 bytes
```
*ステップ 2 - 書き込み DPU を計算する:*
```
WriteDPU = max(12800, 1024) × 0.00004883 = 12800 × 0.00004883 = 0.625
```
**読み取り DPU (プライマリキーチェック):**
Aurora DSQL は、各行のプライマリキーインデックスを読み取り、一意性を検証します。100 個のキールックアップがすべて 1 つのストレージパーティションに存在すると仮定すると、読み取られる総バイト数は 100 × 16 バイト (UUID) = 1,600 バイトです。
```
ReadDPU = max(1600, 2048) × 0.00000183105 = 2048 × 0.00000183105 = 0.00375
```
1,600 バイトは 2,048 バイト未満であるため、トランザクションの最小値である 2,048 バイトが適用されます。
**合計トランザクションコスト:**
クエリ実行時間を 80 ミリ秒 (0.08 秒) と仮定します。
```
ComputeDPU: 0.08
ReadDPU: 0.00375
WriteDPU: 0.625
-------------------
Total DPU: 0.70875
```
## マルチリージョン請求
マルチリージョンクラスターでは、標準のコンピューティング DPU、読み取り DPU、書き込み DPU に加えて、追加のマルチリージョン書き込み DPU コンポーネントが発生します。このセクションは、マルチリージョンクラスターにのみ適用されます。シングルリージョンクラスターの場合、この料金は発生しません。
マルチリージョン書き込み DPU は、ピアリングされたリージョンに書き込まれた合計バイト数を測定します。Aurora DSQL はピアリングされたリージョンに書き込むデータを同期的にレプリケートするため、マルチリージョン書き込み DPU 値は書き込み DPU と同等です。Aurora DSQL は、ピアリングされたリージョンではなく、書き込みが発生したリージョンでこの DPU に課金します。
```
MultiRegionWriteDPU = WriteDPU
```
## CloudWatch による DPU 使用状況のモニタリング
Aurora DSQL は Amazon CloudWatch に使用状況メトリクスを発行するため、消費状況をほぼリアルタイムでモニタリングできます。
### 使用可能な DPU メトリクス
**DPU メトリクス**
| CloudWatch メトリクス | 説明 | ディメンション |
| --- | --- | --- |
| WriteDPU | 書き込み使用量コンポーネント | ClusterId |
| ReadDPU | 読み取り使用量コンポーネント | ClusterId |
| ComputeDPU | クエリ処理コンポーネント | ClusterId |
| MultiRegionWriteDPU | マルチリージョンレプリケーション (マルチリージョンクラスターのみ) | ClusterId |
| TotalDPU | すべての DPU コンポーネントの合計 | ClusterId |
### DPU メトリクスの表示
**CloudWatch で DPU メトリクスを表示するには**
1. [CloudWatch コンソール](https://console.aws.amazon.com/cloudwatch)を開きます。
1. **[メトリクス]**、**[AuroraDSQL]**、**[ClusterId]** の順に移動します。
1. モニタリングするクラスターと DPU メトリクスを選択します。
**ヒント**
DPU メトリクスの **[合計]** 統計を使用して、一定期間の合計使用量を確認します。**LAST** ラベルを追加して、最新の値を表示します。
### 追加のオブザーバビリティメトリクス
Aurora DSQL のメトリクスとモニタリング機能の詳細なリストについては、「[Aurora DSQL のモニタリングとログ記録](monitoring-overview.md)」を参照してください。
**オブザーバビリティメトリクス**
| メトリクス | 説明 |
| --- | --- |
| ClusterStorageSize | 現在のストレージサイズ (バイト単位) |
| TotalTransactions | 実行されたトランザクションの合計 |
| ReadOnlyTransactions | 実行された読み取り専用トランザクション |
| QueryTimeouts | 制限時間を超えたクエリ |
| OccConflicts | OCC の競合により中止されたトランザクション |
| BytesWritten | ストレージに書き込まれた生のバイト数 |
| BytesRead | ストレージから読み取られた生のバイト数 |
## EXPLAIN ANALYZE VERBOSE を使用したコスト認識
Aurora DSQL は `EXPLAIN ANALYZE VERBOSE` を拡張して、ステートメントレベルの DPU 使用量の見積もりを出力の最後に含めます。これにより、クエリコストがすぐに可視化され、ワークロードのコスト要因の特定、クエリのパフォーマンスの調整、リソース使用量の予測に役立ちます。
**注記**
DPU の見積もりを表示するには、`EXPLAIN ANALYZE VERBOSE` (VERBOSE 付き) を使用する必要があります。VERBOSE を付けずに `EXPLAIN ANALYZE` だけを使用すると、DPU 情報は表示されません。
### 例 1: SELECT クエリ
```
EXPLAIN ANALYZE VERBOSE SELECT * FROM test_table;
```
```
QUERY PLAN
----------------------------------------------------
Index Only Scan using test_table_pkey on public.test_table (cost=125100.05..171100.05 rows=1000000 width=36) (actual time=2.973..4.482 rows=120 loops=1)
Output: id, context
-> Storage Scan on test_table_pkey (cost=125100.05..171100.05 rows=1000000 width=36) (actual rows=120 loops=1)
Projections: id, context
-> B-Tree Scan on test_table_pkey (cost=125100.05..171100.05 rows=1000000 width=36) (actual rows=120 loops=1)
Query Identifier: qymgw1m77maoe
Planning Time: 11.415 ms
Execution Time: 4.528 ms
Statement DPU Estimate:
Compute: 0.01607 DPU
Read: 0.04312 DPU
Write: 0.00000 DPU
Total: 0.05919 DPU
```
この例では、SELECT ステートメントはインデックスのみのスキャンを実行するため、ほとんどのコストは、ストレージから取得されたデータを表す読み取り DPU (0.04312) と、結果を処理して返すために使用されるコンピューティングリソースを反映したコンピューティング DPU (0.01607) から発生します。クエリはデータを変更しないため、書き込み DPU はありません。合計 DPU (0.05919) は、コンピューティング \+ 読み取り \+ 書き込みの合計です。
### 例 2: INSERT クエリ
```
EXPLAIN ANALYZE VERBOSE INSERT INTO test_table VALUES (1, 'name1'), (2, 'name2'), (3, 'name3');
```
```
QUERY PLAN
----------------------------------------------------
Insert on public.test_table (cost=0.00..0.04 rows=0 width=0) (actual time=0.055..0.056 rows=0 loops=1)
-> Values Scan on "*VALUES*" (cost=0.00..0.04 rows=3 width=122) (actual time=0.003..0.008 rows=3 loops=1)
Output: "*VALUES*".column1, "*VALUES*".column2
Query Identifier: jtkjkexhjotbo
Planning Time: 0.068 ms
Execution Time: 0.543 ms
Statement DPU Estimate:
Compute: 0.01550 DPU
Read: 0.00307 DPU (Transaction minimum: 0.00375)
Write: 0.01875 DPU (Transaction minimum: 0.05000)
Total: 0.03732 DPU
```
このステートメントは主に書き込みを実行するため、ほとんどのコストは書き込み DPU に関連付けられます。コンピューティング DPU (0.01550) は、値を処理して挿入するために行われた作業を表します。読み取り DPU (0.00307) は、マイナーシステム読み取り (カタログルックアップまたはインデックスチェックの場合) を反映します。
読み取り DPU と書き込み DPU の横に表示される括弧内のトランザクションの最小値に注意してください。これらの最小値はトランザクションレベルで適用されます。つまり、トランザクション全体の読み取り DPU または書き込み DPU の合計がこれらの値を下回ることはありません。`EXPLAIN ANALYZE VERBOSE` を使用してコストを予測しており、これがトランザクションの唯一のステートメントである場合は、raw ステートメントの見積もりではなく、トランザクションの最小値を使用します。トランザクションに複数のステートメントが含まれている場合、最小値はすべてのステートメントの集計に適用されます。`EXPLAIN ANALYZE VERBOSE` はステートメントレベルの見積もりを報告し、請求はトランザクションレベルの最小値を適用するため、これらの値は CloudWatch メトリクスや請求データと正確に一致しない場合があります。
### 最適化のための DPU 情報の使用
ステートメントごとの DPU 見積もりは、実行時間を超えてクエリを最適化する強力な方法を提供します。一般的ユースケースには以下が含まれます。
+ **コスト認識:** クエリが他のクエリと比較してどのくらいのコストがかかるかを把握します。
+ **スキーマの最適化:** インデックスまたはスキーマの変更がパフォーマンスとリソース効率の両方に与える影響を比較します。
+ **予算計画:** 観測された DPU 使用量に基づいてワークロードコストを見積もります。
+ **クエリ比較:** 代替クエリアプローチを相対的な DPU 消費量で評価します。
### DPU 情報の解釈
`EXPLAIN ANALYZE VERBOSE` の DPU データを使用する場合は、次のベストプラクティスに注意してください。
+ **方向的に使用する:** 報告されたDPUを、CloudWatchメトリクスや請求データとの厳密な一致ではなく、クエリの*相対的な*コストを理解する手段として扱います。`EXPLAIN ANALYZE VERBOSE` はステートメントレベルのコストを報告し、CloudWatch はトランザクションレベルのアクティビティを集計するため、差異が想定されます。CloudWatch には、`EXPLAIN ANALYZE VERBOSE` が意図的に除外するバックグラウンドオペレーション (非同期 ANALYZE や圧縮など) とトランザクションオーバーヘッド (`BEGIN`/`COMMIT`) も含まれます。
+ **概念実証の代表的なデータを使用してテストする:** 概念実証を実行してコストを評価するときは、予想される本番ワークロードと同様のデータボリュームとディストリビューションがテーブルに含まれていることを確認します。DPU の見積もり (`EXPLAIN ANALYZE VERBOSE` によるか CloudWatch メトリクスによるかを問わず) は、空のテーブルに基づいているか、データがまばらなテーブルに基づいている場合、実際のコストを反映しません。
+ **実行間の DPU の変動は分散システムでは正常**であり、エラーを示すものではありません。キャッシュ、実行計画の変更、同時実行、バックグラウンドオペレーション (非同期 ANALYZE など)、データ分散のシフトなどの要因により、同じクエリでも実行するたびに異なるリソースを消費する可能性があります。
+ **小規模なオペレーションのバッチ化:** ワークロードで多数の小さなステートメントを発行する場合は、より大きな書き込みオペレーションにバッチ化して 1 つのトランザクションにまとめることを検討してください (変更はトランザクションあたり 10 MB を超えることはできませんが、読み取りの制限は 5 分間のトランザクションタイムアウトのみです)。これにより、作業量を増やしてトランザクションの最小値が適用されないようにすることで、より意味のあるコスト見積もりが生成されます。
+ **請求ではなく調整に使用する:** `EXPLAIN ANALYZE VERBOSE` の DPU データは、コスト認識、クエリ調整、最適化のために設計されています。請求グレードのメトリクスではありません。信頼できるコストと使用状況データについては、常に CloudWatch メトリクスまたは毎月の請求レポートに依存します。
## コスト見積もりのベストプラクティス
+ **最適化前にモニタリングする:** 最適化を決定する前に、CloudWatch メトリクスを使用して現在の使用状況パターンを理解します。詳細については、「[CloudWatch による DPU 使用状況のモニタリング](#billing-cloudwatch-monitoring)」を参照してください。
+ **トランザクション効率を重視する:** 最小値はトランザクションレベルで適用されるため、関連するオペレーションをバッチにまとめることで最低料金が適用されないようにします。
+ **開発中に EXPLAIN ANALYZE VERBOSE を使用する:** 開発中に重要なクエリで `EXPLAIN ANALYZE VERBOSE` を実行して、コスト特性を理解します。概念実証を実行してコストを評価する場合は、代表的なデータボリュームとディストリビューションを持つテーブルに対してテストを行います。空のテーブルまたはデータのまばらなテーブルに基づく見積もりは、本稼働コストを反映しません。詳細については、「[EXPLAIN ANALYZE VERBOSE を使用したコスト認識](#billing-explain-analyze)」を参照してください。
+ **CloudWatch アラームの設定:** DPU メトリクスにアラームを作成して、予期しない使用量の急増の通知を受け取ります。