2026.09.25 aws

DynamoDBの料金を東京リージョンの実額で試算する：請求が跳ねる設計と単価の下げ方

DynamoDBの料金を東京リージョンの実額で試算する：請求が跳ねる設計と単価の下げ方

DynamoDBの請求は、書き込み100万回あたり0.715USDという単価だけでは読めません。同じ1回の書き込みでも、項目が1.1KBなら2回分、グローバルセカンダリインデックス（GSI）を2本持つテーブルなら3回分が課金されるからです。この記事では、東京リージョンの単価をAWS Price List APIの実測値で並べ、AWS CLIで1リクエストあたりの消費ユニットを確かめる手順、月額を出すPythonの試算コード、請求が想定の数倍に跳ねる設計の条件を順に扱います。容量モードとテーブルクラスの切り替え、予約キャパシティとDatabase Savings Plansを選ぶ条件まで、数値はすべて2026年9月時点の一次情報に基づきます。

まとめ：DynamoDB料金の実額を決める単価と請求が跳ねる設計の要点

東京リージョンのオンデマンドは、書き込みが100万リクエストユニットあたり0.715USD、読み込みが0.1425USDです。ストレージは25GBまで無料で、超過分が1GB月あたり0.285USD。小さな業務システムなら月数USDで収まります。

見積もりが外れる原因は単価ではありません。請求を押し上げる要因は影響の大きい順に次の4つです。

  • Scanの常用：50GBのテーブルを毎時フルScanすると、読み込みだけで月672USDになります
  • GSIの本数と射影：GSIを2本持つテーブルは、書き込みの課金が本体の3倍になります
  • 項目サイズの切り上げ：書き込みは1KB、読み込みは4KB単位で切り上げるため、境界をわずかに超えただけで2倍です
  • トランザクションとPITR：トランザクション書き込みは1項目2ユニット、PITRはテーブル1GB月あたり0.228USDが乗ります

単価を下げる手段は、利用率が29%を超える安定負荷ならプロビジョンドへの切り替え、ストレージ費がスループット費の50%を超えるならStandard-IA、1年以上同じ規模で動くことが確定しているなら予約キャパシティです。DynamoDBという製品の位置づけとRDSとの違いはAWS DynamoDBとは？特徴・使い方・料金・RDSとの違いで整理しているため、本記事は金額の話に絞ります。

東京リージョンのDynamoDB単価とPrice List APIで確かめる課金項目

Amazon DynamoDBの料金ページは表示をリージョン選択で切り替える作りのため、社内資料に米国東部の単価がそのまま紛れ込みがちです。ここでは東京リージョン（ap-northeast-1）の値だけを扱い、出典は機械可読のPrice List APIに置きます。

オンデマンドとプロビジョンドの東京単価をPrice List APIで取得する手順

Price List APIは認証なしで叩けるオファーファイルを公開しており、リージョン別の最新版URLを索引から引けます。次のスクリプトは標準ライブラリだけで動き、読み書きとストレージの単価を出力します。

# 東京リージョンのDynamoDB単価をAWS Price List APIから取得する（Python 3標準ライブラリのみ）
import json, urllib.request

BASE = "https://pricing.us-east-1.amazonaws.com"
def get(path):
    with urllib.request.urlopen(BASE + path, timeout=120) as r:
        return json.load(r)

idx = get("/offers/v1.0/aws/AmazonDynamoDB/current/region_index.json")
offer = get(idx["regions"]["ap-northeast-1"]["currentVersionUrl"])
print("version", offer["version"])
for sku, p in offer["products"].items():
    usage = p["attributes"].get("usagetype", "")
    if usage.endswith(("RequestUnits", "CapacityUnit-Hrs", "TimedStorage-ByteHrs")):
        for term in offer["terms"]["OnDemand"].get(sku, {}).values():
            for d in term["priceDimensions"].values():
                print(usage, d["beginRange"], d["endRange"], d["pricePerUnit"]["USD"])

# 出力の一部（版 20260911124422）
# APN1-WriteRequestUnits 0 Inf 0.0000007150
# APN1-ReadRequestUnits 0 Inf 0.0000001425
# APN1-WriteCapacityUnit-Hrs 18600 Inf 0.0007420000
# APN1-TimedStorage-ByteHrs 25 Inf 0.2850000000

取得した値を整理したのが下表です。Standard-IAは読み書きが約25%高く、ストレージが60%安い設定になっています。

課金項目 Standard Standard-IA
オンデマンド書き込み（100万WRU） 0.715USD 0.89USD
オンデマンド読み込み（100万RRU） 0.1425USD 0.178USD
プロビジョンド書き込み（1WCU・時） 0.000742USD 0.0009275USD
プロビジョンド読み込み（1RCU・時） 0.0001484USD 0.0001855USD
ストレージ（1GB・月） 0.285USD 0.114USD

プロビジョンドを月730時間で換算すると、1WCUが月0.5417USD、1RCUが月0.1083USDです。複製先リージョンへの書き込み（レプリケーション書き込み）も、Standardでは通常の書き込みと同じ単価で定義されています。

ストレージ・PITR・バックアップ・Streamsの付帯単価と無料の範囲

読み書き以外の単価も同じオファーファイルに入っています。PITR（ポイントインタイムリカバリ）は1GB月あたり0.228USDで、ストレージ単価の8割に相当します。PITRを有効にしたテーブルは、保存費がほぼ倍になると見積もってください。

  • オンデマンドバックアップの保存：0.114USD／GB月
  • バックアップからの復元とS3からのインポート：0.171USD／GB
  • S3へのエクスポート（全量・増分とも）：0.114USD／GB
  • DynamoDB Streamsの読み込み：月250万リクエストまで無料、超過分は100万あたり0.228USD
  • Kinesis Data Streamsへの変更データ送出：100万単位あたり0.11415USD

無料で使える範囲は、Price List API上でプロビジョンドの25WCU・25RCU（月18,600ユニット時間）、Standardストレージの最初の25GB、Streams読み込み250万件として定義されています。Standard-IAのストレージには無料の段階がありません。バックアップを複数サービス横断で管理するなら、AWS Backupとは？対応サービス・料金・バックアッププラン作成と復元手順の料金体系とあわせて比較してください。

読み書きの消費ユニットをAWS CLIで実測する手順とサイズの切り上げ規則

単価に掛ける「ユニット数」を想定で置くと、見積もりは簡単に2倍ずれます。本番と同じ形の項目を1件書き、消費量をDynamoDB自身に返させるのが確実です。

put-itemとqueryに消費ユニットを返させるAWS CLIの実行例と出力の読み方

書き込み・読み込みの各APIは --return-consumed-capacity を受け付けます。INDEXES を指定すると、テーブル本体とGSIごとの内訳まで返ります。

# 本番と同じ形の項目を1件書き、テーブル本体とGSIごとの消費ユニットを確認する
aws dynamodb put-item \
  --table-name Orders \
  --item file://order-sample.json \
  --return-consumed-capacity INDEXES \
  --region ap-northeast-1

# 同じパーティションを読み、読み込みの消費ユニットを確認する
aws dynamodb query \
  --table-name Orders \
  --key-condition-expression "customerId = :c" \
  --expression-attribute-values '{":c":{"S":"C-1001"}}' \
  --return-consumed-capacity TOTAL \
  --region ap-northeast-1

put-itemの応答に含まれる ConsumedCapacity は、Table と GlobalSecondaryIndexes の値を足した合計が CapacityUnits に入る形式です。1KB未満の項目でGSIを2本持つテーブルなら、合計は3.0になります。この3.0が、次章の試算で書き込み回数に掛ける係数です。消費量をテーブル単位の月次で追うなら、請求側の集計はAWS Cost Explorerとは？コスト可視化・分析の仕組みと料金の使用タイプ別フィルタで確認できます。

書き込み1KB・読み込み4KB単位の切り上げで課金が2倍になる項目サイズ

読み書きの消費規則によると、書き込みは項目サイズを1KB単位、読み込みは4KB単位で切り上げます。1.1KBの項目は2WRU、4.1KBの項目の強い整合性読み込みは2RRUです。結果整合性の読み込みはその半分、トランザクションは2倍になります。

見落とされやすい規則が3つあります。UpdateItemの課金の基準は、更新した属性の大きさではなく、更新前後で大きいほうの項目全体のサイズです。条件付き書き込みは条件が偽で失敗しても消費が発生し、トランザクションはキャンセルされても2ユニットを消費します。存在しない項目を読んだ場合も読み込みユニットは消費されます。

数字に落とすと、属性名を短くして項目を1KB未満に収めるだけで書き込み課金が半分になる場面があります。customerEmailAddress を em に縮めるような設計は、1日100万件書き込むテーブルでは月21USDの差です。

月間リクエスト数から月額を出すPythonの試算コードと業務システムの例

ユニットの係数が分かれば、月額は掛け算で出せます。表計算で組むとGSIの係数や整合性モードを取りこぼしやすいため、コードにしておくと前提の変更に強くなります。

GSI更新と整合性モードを含めて月額を計算するPythonスクリプト

次のスクリプトは、書き込み回数と項目サイズ、GSIの更新本数、読み込み回数と整合性モード、データ量からオンデマンドの月額を出します。単価は前章で取得した東京リージョンの値です。

# DynamoDBオンデマンドの月額を東京リージョン単価で試算する
import math

P = {"wru": 0.715 / 1e6, "rru": 0.1425 / 1e6, "storage": 0.285, "pitr": 0.228}

def wru(item_kb, transactional=False):
    u = math.ceil(item_kb)                  # 書き込みは1KB単位で切り上げ
    return u * 2 if transactional else u

def rru(item_kb, mode="eventual"):
    u = math.ceil(item_kb / 4)              # 読み込みは4KB単位で切り上げ
    return {"strong": u, "eventual": u / 2, "transactional": u * 2}[mode]

def on_demand(writes, write_kb, gsi_writes, reads, read_kb, read_mode,
              table_gb, gsi_gb, pitr=True):
    w = writes * wru(write_kb) * (1 + gsi_writes)   # GSI更新分も書き込みとして課金
    r = reads * rru(read_kb, read_mode)
    cost = {
        "書き込み": w * P["wru"],
        "読み込み": r * P["rru"],
        "ストレージ": max(table_gb + gsi_gb - 25, 0) * P["storage"],
        "PITR": table_gb * P["pitr"] if pitr else 0.0,
    }
    cost["合計"] = sum(cost.values())
    return cost

c = on_demand(writes=30_000_000, write_kb=0.8, gsi_writes=2,
              reads=150_000_000, read_kb=3.0, read_mode="eventual",
              table_gb=50, gsi_gb=8)
for k, v in c.items():
    print(f"{k} {v:.2f} USD")

# 実行結果
# 書き込み 64.35 USD
# 読み込み 10.69 USD
# ストレージ 9.40 USD
# PITR 11.40 USD
# 合計 95.84 USD

GSIのサイズはテーブルとは別にストレージ課金されるため、gsi_gb を独立した引数にしています。GSIの公式ドキュメントは、索引の1項目ごとに100バイトのオーバーヘッドが乗ると明記しています。

月3,000万書き込み・GSI2本の構成で書き込みが請求の3分の2を占める内訳

上の実行例は、1日100万件の受注を書き込み、1日500万件を結果整合性で読む業務システムを想定しています。月額95.84USDのうち、書き込みが64.35USDで全体の67%です。GSIが無ければ書き込みは21.45USDで済み、差の42.90USDはすべて索引の維持費にあたります。

この構成で最初に疑うべきは読み込みではなく、GSIが本当に2本必要かどうかです。管理画面の検索にしか使わない索引を1本外すだけで、月21USD下がります。読み込み側は月1.5億回でも10.69USDにとどまり、結果整合性で読む限り削減の余地は小さい領域です。

GSI・Scan・グローバルテーブルで請求が想定の数倍に跳ねる設計

試算表どおりに動かない請求の大半は、設計段階の3つの選択から生まれます。いずれもアプリケーションは正常に動くため、請求書が届くまで気づきにくい点が共通しています。

GSIのキー属性を書き換える更新で索引側に2回分の書き込みが乗る条件

GSIの書き込み課金は更新内容で変わります。公式ドキュメントの規則を課金回数で整理すると次のとおりです。

テーブル側の操作 GSI側の書き込み回数
索引キー属性を持つ項目の新規書き込み 1回
索引キー属性の値を書き換える更新（AからB） 2回（旧項目の削除と新項目の追加）
射影属性だけを書き換える更新 1回
索引キーにも射影にも無い属性だけの更新 0回

危ないのは、status のように頻繁に変わる属性をGSIのキーにする設計です。受注1件が「受付・出荷準備・出荷済み・完了」と3回遷移すれば、その索引だけで6回分の書き込みが乗ります。射影を ALL にすると更新のたびに索引へ全属性が書かれ、サイズの切り上げでさらに係数が増えます。書き込みが多く索引を引く頻度が低いテーブルは、公式の推奨どおり KEYS_ONLY から始めてください。

50GBテーブルを毎時フルScanすると読み込みだけで月672USDになる計算

Scanは返した項目ではなく、評価した項目のサイズで課金されます。フィルタ式で1件に絞っても、読んだ全量が課金対象です。

50GBのテーブルを結果整合性で1回フルScanすると、50GB ÷ 4KB × 0.5 で約655万RRU、0.934USDかかります。1回なら小さな額です。ところが集計バッチを毎時動かすと、月720回で672USD。前章の業務システム全体の7倍に達します。集計や横断検索が要件にあるなら、S3へのエクスポート（1GBあたり0.114USD）を挟んでAthenaなどで読むほうが桁違いに安く済みます。Scanを定期処理に組み込む設計は、テーブルが数GBを超えた時点で見直してください。

グローバルテーブルとTTL削除が複製先リージョンで課金される範囲

2024年11月1日の改定で、オンデマンドのスループット単価が50%、グローバルテーブルの複製書き込みが最大67%引き下げられました。複製書き込みの単価は単一リージョンの書き込みと同額です。それでも、2リージョン構成なら書き込み課金とストレージ課金がリージョン数だけ倍になる構造は変わりません。

TTLの扱いには例外があります。TTLの公式ドキュメントによると、期限切れ項目の削除は発生したリージョンでは書き込みを消費しません。一方、グローバルテーブルでは削除が複製先へ伝播し、複製先ごとに複製書き込みとして課金されます。複製の仕組みと強整合性の選択はDynamoDB Global Tables（グローバルテーブル）とは、TTL属性の設定手順はDynamoDB TTLとは｜設定方法・自動削除の仕組みで扱っています。

容量モードとテーブルクラスの切り替えで読み書き・保存の単価を下げる判断基準

使用量を変えずに単価側を動かす手段は、容量モードとテーブルクラスの2つです。どちらもアプリケーションのコードを変えずに切り替えられます。

平均利用率29%を境にプロビジョンドがオンデマンドより安くなる分岐点

1WCUを1か月使い切ると、毎秒1回 × 730時間で262万8,000回の書き込みになります。これをオンデマンドで払えば1.88USD、プロビジョンドなら0.5417USDです。割り算すると、プロビジョンドした容量の平均28.8%以上を実際に使うならプロビジョンドが安くなります。読み込みも28.9%で、ほぼ同じ境界です。

ただし、この分岐点はピークに合わせて容量を確保する前提を含みません。夜間にほぼゼロまで落ちる業務システムでは、オートスケーリングを組んでも平均利用率が29%に届かない場合が多く、オンデマンドのほうが安く付きます。オンデマンドは公式に既定かつ推奨のモードと位置づけられています。プロビジョンドへ移すのは、24時間平坦な負荷が数か月続いた実績を確認してからにしてください。プロビジョンドからオンデマンドへの切り替えは24時間で4回までという制約があり、仕組みはDynamoDBとは：ローカル起動からキー設計・容量モード選定までの実装手順で解説しています。

ストレージ費がスループット費の50%を超えたらStandard-IAへ移す判断

テーブルクラスの選択基準は、Standardでのストレージ費がスループット費の50%を超えるならStandard-IAで総額が下がると明記しています。ログや過去の注文履歴のように、溜まる一方で読まれないテーブルが対象です。

500GBの操作ログを保持し、月300万件書き込むテーブルで比べると、Standardは月137.52USD、Standard-IAは月59.67USDです。読み書き単価は上がりますが、ストレージが60%下がる効果が大きく、差は月77.85USDになります。変更は30日間に2回までのため、試しに切り替えて戻す運用は取れません。

オンデマンドの最大スループット設定で暴走時の請求に上限を掛ける手順

オンデマンドの弱点は、バグで無限ループした処理がそのまま請求になる点です。最大スループットの設定を使うと、テーブルやGSIごとに毎秒の上限を置けます。

# テーブルの読み書きに毎秒の上限を設定する（超過分はThrottlingExceptionで返る）
aws dynamodb update-table \
  --table-name Orders \
  --on-demand-throughput MaxReadRequestUnits=2000,MaxWriteRequestUnits=500 \
  --region ap-northeast-1

# ストレージ主体のテーブルをStandard-IAへ切り替える（30日間に2回まで）
aws dynamodb update-table \
  --table-name OperationLogs \
  --table-class STANDARD_INFREQUENT_ACCESS \
  --region ap-northeast-1

毎秒500WRUの上限なら、書き込みが上限に張り付いても1時間あたり1.29USDで止まります。公式ドキュメントはこの上限をベストエフォートと説明しており、バースト容量で一時的に超える場合があります。厳密な課金上限ではなく、暴走の規模を抑える安全弁として置いてください。構文はAWS CLIのupdate-tableリファレンスで確認できます。

予約キャパシティとDatabase Savings Plansの契約判断と見送る条件

割引契約は、使用量が読めるテーブルにだけ効きます。条件を外すと、使わない容量の代金を1年分前払いする結果になります。

予約キャパシティの1年54%・3年77%割引が使えるテーブルの条件

予約キャパシティの公式ドキュメントによると、割引は1年契約で最大54%、一部リージョンの3年契約で最大77%です。対象はプロビジョンドかつStandardクラスのテーブルに限られ、オンデマンド、Standard-IA、複製書き込み（rWCU）には使えません。購入は100ユニット単位で、一部前払いのうえ契約期間中はリージョンを移せず、解約もできません。

契約してよいのは、プロビジョンドで最低100WCUを1年間使い続けることが確定しているテーブルだけです。前章の分岐点を下回る負荷や、1年以内にアーキテクチャを見直す予定があるシステムでは見送ります。

Database Savings Plansの対象範囲と予約キャパシティの併用不可条件

2025年12月2日にDatabase Savings Plansが発表され、1年間の時間単価コミットでAuroraやRDSと並んでDynamoDBも割引の対象になりました。Savings PlansのFAQには、DynamoDBのオンデマンドとプロビジョンドの両方のスループットが対象であること、同じワークロードで予約キャパシティと併用できないことが書かれています。最大35%はサービス全体の上限で、割引率はサービスと利用種別で変わります。

オンデマンドのまま割引を受けられる点が、予約キャパシティとの違いです。RDSやAuroraと合わせてデータベース全体で毎月一定額を使っている組織なら、DynamoDB単体で予約を積むよりSavings Plansのほうが無駄が出にくくなります。DynamoDBの月額が数十USDの段階では、GSIとScanの見直しが先です。既存構成の請求を棚卸しして設計から見直したい場合は、インフラ構築（AWS・Google Cloud・Azure）でテーブル設計の段階から相談を受けています。

よくある質問

DynamoDBの料金について繰り返し問われる論点に答えます。数値はいずれも東京リージョン・2026年9月時点のものです。

DynamoDBは無料で使えますか？

小規模なら無料の範囲に収まります。Price List API上で無料の段階として定義されているのは、プロビジョンドの25WCU・25RCU（月18,600ユニット時間）、Standardストレージの最初の25GB、Streams読み込み月250万件です。オンデマンドの読み書きには無料の段階が無く、1リクエスト目から課金されます。検証用テーブルはプロビジョンドで最小容量にしておくと枠内に収まりやすくなります。

オンデマンドとプロビジョンドはどちらが安いですか？

プロビジョンドした容量の平均利用率が29%を超えるならプロビジョンドが安く、下回るならオンデマンドが安くなります。1WCUを1か月使い切った場合、オンデマンドは1.88USD、プロビジョンドは0.5417USDです。夜間に負荷が落ちる業務システムでは平均利用率が29%に届かないことが多く、既定のオンデマンドから始めて実績を見て判断してください。

2024年以前の記事の単価はそのまま使えますか？

使えません。2024年11月1日にオンデマンドのスループット単価が50%引き下げられ、グローバルテーブルの複製書き込みも単一リージョンの書き込みと同額になりました。改定前の単価で見積もると、読み書き部分が2倍に出ます。ストレージ単価も記事によって古い値が残っているため、Price List APIのオファーファイルで版を確認してから使ってください。

GSIを追加すると料金はどれくらい増えますか？

GSIの索引キーを持つ項目を書くたびに、索引側で1回分の書き込みが追加されます。GSIが2本なら書き込み課金は最大3倍です。索引キーの値を書き換える更新では1本あたり2回分になります。ストレージも索引ごとに別に課金され、1項目あたり100バイトのオーバーヘッドが乗ります。射影は必要な属性だけに絞ってください。

TTLで項目を削除すると料金はかかりますか？

単一リージョンのテーブルでは、TTLによる削除は書き込みユニットを消費しません。削除が行われる時期は、期限切れから数日以内です。グローバルテーブルでは、削除が複製先リージョンへ伝播する際に複製書き込みとして課金されます。DeleteItemで消すと削除した項目のサイズ分の書き込みが発生するため、大量の期限切れデータを消す用途ではTTLのほうが安く済みます。

関連記事

この記事に関連するサービス

資料請求

RELATED POSTS 関連記事

一覧へ戻る