DynamoDB のコストモデル: なぜ SQL は請求を見えなくするのか

DynamoDB に対して本物の SQL を実行できるのは強力です — ネイティブにはそのどれも提供しないデータベースの上で、JOIN、GROUP BY、任意の WHERE 句が手に入ります。しかし SQL は、クエリプランナーとすべての列に対するセカンダリインデックスを備えたエンジンのために設計されており、DynamoDB はそのどちらも持ちません。まったく正当な SELECT が、テーブル内のすべてのアイテムを読み取り — そして課金する — フルテーブル Scan にコンパイルされることがあります。

これが SQL という抽象化の諸刃の剣です。高コストなアクセスパターンを無料に見せてしまうのです。このガイドではその下にあるコストモデルを解説し、この利便性が予期せぬ請求に変わらないようにします。そして DynoTable がクエリを実行する前にコストを可視化する方法を示します。

DynamoDB 上の SQL は、なぜ見た目より高くつくのか?

リレーショナルデータベースは WHERE status = 'active' を効率的に処理できます。指定した任意の列に対してインデックスを構築するからです。DynamoDB はそうしません。効率的に処理できるのはただ1つ、パーティションキーだけです (オプションでソートキーや グローバルセカンダリインデックスによって絞り込めます)。それ以外はすべて Scan です。

パーティションキーの等価条件は Query です。 DynamoDB はそのキー配下のアイテムに直接ジャンプし、それらだけを読み取ります。範囲が限られていて安価です。
それ以外はすべて Scan + Filter です。 DynamoDB はテーブル内のすべてのアイテムを読み取り、その後で WHERE を FilterExpression として適用します — 読み取りの後にです。課金されるのは Scan したすべての分であって、返ってきたわずかな行の分ではありません。

この最後の点が罠です。WHERE 句は作業量を絞り込むように見えます。しかしキー以外の属性では、絞り込むのは出力だけで — 読み取りコストはすでに費やされています。

Query vs Scan: RCU の計算

DynamoDB は読み取りを読み取りキャパシティユニット (RCU) で課金します:

1 RCU = 最大 4 KB までのアイテム1件の強力な整合性のある読み取り1回。結果整合性のある読み取りはその半分のユニットで済みます。読み取りは 4 KB ごとに切り上げられます。
Query は1つのパーティションキー配下のアイテムだけを読み取ります — コストはテーブルではなく、一致したアイテムに比例します。
Scan はテーブル全体を 4 KB ずつ読み取ります。1 GB のテーブルは、1回のフルパスでおよそ 262,000 結果整合性のある RCU になります — パスのたびに、毎回です。

FilterExpression はその数値を減らしません。フィルタリングは読み取りの後に行われるので、フィルターありの Scan はフィルターなしの場合とまったく同じコストがかかります。自分のデータでの実際の数値は、アイテムサイズ計算ツールと料金計算ツールで算出してください。

下のカーブは、読み取りの多い Scan ワークロードを2つのキャパシティモードで料金計算したものです — 平均使用率をスライドさせて、予約したスループットに支払うほうがリクエストごとに支払うより安くなるのはどこからかを確かめてください。

オンデマンド対プロビジョンド: コストと使用率

平均使用率 20% のとき: 月額でオンデマンド $328.50、プロビジョンド $474.50。

プロビジョンドピークの平均使用率が 28.9% を下回るとオンデマンドが安く、上回るとプロビジョンドが有利です。

使用率	オンデマンド	プロビジョンド	割安
10%	$164.25	$474.50	オンデマンド
25%	$410.63	$474.50	オンデマンド
28.9%損益分岐点	$474.50	$474.50	—
50%	$821.25	$474.50	プロビジョンド
75%	$1,231.88	$474.50	プロビジョンド
100%	$1,642.50	$474.50	プロビジョンド

料金: 米国東部 (バージニア北部)、強い整合性のある読み取り、無料利用枠なし。リクエストコストのみ — ストレージはどちらのモードでも同じ料金で課金され、損益分岐点を動かすことはありません。ピーク: 読み取り 3,000 回/秒、書き込み 100 回/秒、アイテムサイズ 4 KB。

どの SQL 構文がひそかに Scan に変わるのか?

パーティションキーの等価条件がない WHERE → 読み取り後にフィルターをかけるフル Scan。
JOIN → DynamoDB にサーバーサイドの結合はありません。結合される各テーブルは個別に取得され、クライアントサイドでつなぎ合わされます — N+1 のアクセスパターンで、結合される行ごとに1リクエストです。
COUNT、SUM、GROUP BY、集計 → サーバーサイドの集計は存在しないので、一致したすべてのアイテムが読み取られます。Scan の上では、それはテーブル全体を読み取ることを意味します。
キー以外の属性に対する ORDER BY や DISTINCT → 並べ替えと重複排除は、Scan された対象に対してクライアントサイドで行われます。

これらのどれも実行して間違いというわけではありません — Scan がまさに望むものであることもあります。肝心なのは、自分がいつ Scan を実行しているのかを知ることです。

SQL にコストについて正直でいてもらうには?

アクセスパターンを中心にキーを設計しましょう。 最も安価なクエリは、キースキーマがすでに答えられるものです。シングルテーブル設計ツールと Query vs Scan ガイドで計画しましょう。
WHERE にパーティションキーの等価条件を入れて、Scan の代わりに Query にしましょう。
GSI を追加して、Scan してフィルターする代わりに2つ目のアクセスパターンに対応しましょう。
実行する前にコストを読みましょう。 DynoTable の Workbench は SQL を実際の DynamoDB オペレーションにコンパイルし、プランをプレビューします — Scan か Query か、どのインデックスを使うか、キー条件と Scan 後のフィルターの違い — そしてテーブルをまたぐ JOIN による N+1 のリクエスト増幅をインラインで指摘します。これは DynamoDB が決して出荷しなかった EXPLAIN です。RCU の見積もりは、テーブルのメタデータが対応している場合にのみ表示されます。通常のパーティション Query では表示されません。 Scan はなぜ遅く高コストなのかとオンデマンド vs プロビジョンドキャパシティも参照してください。

DynoTable の SQL はコスト問題を悪化させるのか?

いいえ — むしろコストを可視化するからです。DynamoDB 上の SQL への批判はもっともです。 Scan を隠す抽象化は、自分の足を撃つことを許してしまいます。DynoTable の答えは、SQL を取り除くことではなく、その背後にコストの X 線を置くことです。

Workbench がプランをコンパイルできたときは、実行前にそのプランを表示します。だから SQL の使い心地と、ネイティブモデルが与えてくれるキー設計についての正直さの両方を保てます。表示された数値は、請求額ではなく実行前のヒントとして扱ってください。

これに AI エージェントは必要か?

いいえ — テーブルビューアー、SQL Workbench、コストプレビューはすべて、それなしで完全に機能します。AI エージェントは DynoTable の目玉機能の1つで — スキーマを理解したクエリを書き、データを変換し、さらに多くのことを行う DynamoDB ネイティブのコーディングエージェントです — 使いたいときにいつでもそこにあります。自分自身の AWS Bedrock 上で動作するので、 AWS に直接、原価で支払い (割増しなし)、データがアカウントから出ることは決してありません。役立つときにオンにしてください。どちらにしてもコアのクライアントは完結しています。

自分の作業は移行できるか?

はい。DynoTable は囲い込みではなく標準を話します。標準の SQL、標準の AWS 認証情報と SSO、 CSV/JSON エクスポート、TypeScript・JSON-Schema・Zod への推論スキーマエクスポート、そして自分のツールやエージェントが接続できる MCP サーバー。クエリ、設定、スキーマはきれいにエクスポートでき — 何もロックインされません。

試してみる

DynoTable をダウンロードして、自分のテーブルに対して SQL Workbench を開いてみてください — コストプレビューが、実行する前に各クエリの背後にあるプランを示してくれます。