--- title: "DynamoDBの料金を東京リージョンの実額で試算する：請求が跳ねる設計と単価の下げ方" url: "https://www.issoh.co.jp/tech/details/17798/" published: 2026-09-25 updated: 2026-10-30 categories: ["AWS"] publisher: "株式会社一創" --- # 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との違い](/tech/details/17453/)で整理しているため、本記事は金額の話に絞ります。 ## 東京リージョンのDynamoDB単価とPrice List APIで確かめる課金項目 [Amazon DynamoDBの料金ページ](https://aws.amazon.com/dynamodb/pricing/)は表示をリージョン選択で切り替える作りのため、社内資料に米国東部の単価がそのまま紛れ込みがちです。ここでは東京リージョン（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とは？対応サービス・料金・バックアッププラン作成と復元手順](https://www.issoh.co.jp/tech/details/3380/)の料金体系とあわせて比較してください。 ## 読み書きの消費ユニットを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とは？コスト可視化・分析の仕組みと料金](https://www.issoh.co.jp/tech/details/15628/)の使用タイプ別フィルタで確認できます。 ### 書き込み1KB・読み込み4KB単位の切り上げで課金が2倍になる項目サイズ [読み書きの消費規則](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/read-write-operations.html)によると、書き込みは項目サイズを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の公式ドキュメント](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GSI.html)は、索引の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%引き下げられました](https://aws.amazon.com/about-aws/whats-new/2024/11/amazon-dynamo-db-reduces-prices-on-demand-throughput-global-tables/)。複製書き込みの単価は単一リージョンの書き込みと同額です。それでも、2リージョン構成なら書き込み課金とストレージ課金がリージョン数だけ倍になる構造は変わりません。 TTLの扱いには例外があります。[TTLの公式ドキュメント](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TTL.html)によると、期限切れ項目の削除は発生したリージョンでは書き込みを消費しません。一方、グローバルテーブルでは削除が複製先へ伝播し、複製先ごとに複製書き込みとして課金されます。複製の仕組みと強整合性の選択は[DynamoDB Global Tables（グローバルテーブル）とは](https://www.issoh.co.jp/tech/details/5173/)、TTL属性の設定手順は[DynamoDB TTLとは｜設定方法・自動削除の仕組み](https://www.issoh.co.jp/tech/details/3677/)で扱っています。 ## 容量モードとテーブルクラスの切り替えで読み書き・保存の単価を下げる判断基準 使用量を変えずに単価側を動かす手段は、容量モードとテーブルクラスの2つです。どちらもアプリケーションのコードを変えずに切り替えられます。 ### 平均利用率29%を境にプロビジョンドがオンデマンドより安くなる分岐点 1WCUを1か月使い切ると、毎秒1回 × 730時間で262万8,000回の書き込みになります。これをオンデマンドで払えば1.88USD、プロビジョンドなら0.5417USDです。割り算すると、プロビジョンドした容量の平均28.8%以上を実際に使うならプロビジョンドが安くなります。読み込みも28.9%で、ほぼ同じ境界です。 ただし、この分岐点はピークに合わせて容量を確保する前提を含みません。夜間にほぼゼロまで落ちる業務システムでは、オートスケーリングを組んでも平均利用率が29%に届かない場合が多く、オンデマンドのほうが安く付きます。[オンデマンドは公式に既定かつ推奨のモード](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/on-demand-capacity-mode.html)と位置づけられています。プロビジョンドへ移すのは、24時間平坦な負荷が数か月続いた実績を確認してからにしてください。プロビジョンドからオンデマンドへの切り替えは24時間で4回までという制約があり、仕組みは[DynamoDBとは：ローカル起動からキー設計・容量モード選定までの実装手順](https://www.issoh.co.jp/tech/details/17453/)で解説しています。 ### ストレージ費がスループット費の50%を超えたらStandard-IAへ移す判断 [テーブルクラスの選択基準](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/WorkingWithTables.tableclasses.html)は、Standardでのストレージ費がスループット費の50%を超えるならStandard-IAで総額が下がると明記しています。ログや過去の注文履歴のように、溜まる一方で読まれないテーブルが対象です。 500GBの操作ログを保持し、月300万件書き込むテーブルで比べると、Standardは月137.52USD、Standard-IAは月59.67USDです。読み書き単価は上がりますが、ストレージが60%下がる効果が大きく、差は月77.85USDになります。変更は30日間に2回までのため、試しに切り替えて戻す運用は取れません。 ### オンデマンドの最大スループット設定で暴走時の請求に上限を掛ける手順 オンデマンドの弱点は、バグで無限ループした処理がそのまま請求になる点です。[最大スループットの設定](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/on-demand-capacity-mode-max-throughput.html)を使うと、テーブルや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リファレンス](https://docs.aws.amazon.com/cli/latest/reference/dynamodb/update-table.html)で確認できます。 ## 予約キャパシティとDatabase Savings Plansの契約判断と見送る条件 割引契約は、使用量が読めるテーブルにだけ効きます。条件を外すと、使わない容量の代金を1年分前払いする結果になります。 ### 予約キャパシティの1年54%・3年77%割引が使えるテーブルの条件 [予約キャパシティの公式ドキュメント](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/reserved-capacity.html)によると、割引は1年契約で最大54%、一部リージョンの3年契約で最大77%です。対象はプロビジョンドかつStandardクラスのテーブルに限られ、オンデマンド、Standard-IA、複製書き込み（rWCU）には使えません。購入は100ユニット単位で、一部前払いのうえ契約期間中はリージョンを移せず、解約もできません。 契約してよいのは、プロビジョンドで最低100WCUを1年間使い続けることが確定しているテーブルだけです。前章の分岐点を下回る負荷や、1年以内にアーキテクチャを見直す予定があるシステムでは見送ります。 ### Database Savings Plansの対象範囲と予約キャパシティの併用不可条件 2025年12月2日に[Database Savings Plans](https://aws.amazon.com/about-aws/whats-new/2025/12/database-savings-plans-savings/)が発表され、1年間の時間単価コミットでAuroraやRDSと並んでDynamoDBも割引の対象になりました。[Savings PlansのFAQ](https://aws.amazon.com/savingsplans/faqs/)には、DynamoDBのオンデマンドとプロビジョンドの両方のスループットが対象であること、同じワークロードで予約キャパシティと併用できないことが書かれています。最大35%はサービス全体の上限で、割引率はサービスと利用種別で変わります。 オンデマンドのまま割引を受けられる点が、予約キャパシティとの違いです。RDSやAuroraと合わせてデータベース全体で毎月一定額を使っている組織なら、DynamoDB単体で予約を積むよりSavings Plansのほうが無駄が出にくくなります。RDS側の東京リージョンの単価とリザーブドインスタンスの割引率は[AWS RDSの料金を東京リージョンの実額で計算する](https://www.issoh.co.jp/tech/details/17883/)で計算しています。DynamoDBの月額が数十USDの段階では、GSIとScanの見直しが先です。既存構成の請求を棚卸しして設計から見直したい場合は、[インフラ構築（AWS・Google Cloud・Azure）](https://www.issoh.co.jp/service/system/aws/)でテーブル設計の段階から相談を受けています。 ## よくある質問 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のほうが安く済みます。 ## 関連記事 - [AWS DynamoDBとは？特徴・使い方・料金・RDSとの違いを実装目線で解説](/tech/details/17453/)：製品の位置づけとRDSとの比較 - [DynamoDBとは：ローカル起動からキー設計・容量モード選定までの実装手順](https://www.issoh.co.jp/tech/details/17453/)：料金の前提となるキー設計と容量モードの仕組み - [DynamoDB Global Tables（グローバルテーブル）とは｜複製の仕組み・強整合性・料金](https://www.issoh.co.jp/tech/details/5173/)：複製書き込みが発生する構成 - [Lambdaの料金を東京リージョンの実額で計算する：付帯課金の内訳と単価を下げる手順](https://www.issoh.co.jp/tech/details/17740/)：サーバーレス構成の計算側の単価内訳 - [AWS Cost Explorerとは？コスト可視化・分析の仕組みと料金・使いどころを実装者目線で解説](https://www.issoh.co.jp/tech/details/15628/)：実際の請求をテーブル単位で追う手段 --- 出典: [DynamoDBの料金を東京リージョンの実額で試算する：請求が跳ねる設計と単価の下げ方]()（株式会社一創）