Amazon DynamoDBとは：機能の全体像からローカル起動・キー設計・容量モード選定まで

Amazon DynamoDBは、AWSが提供するサーバーレスでフルマネージドなNoSQLデータベースです。公式ドキュメントは、DynamoDBのスキーマ設計を「答えるべき問いが決まるまで始めるべきではない」と定義しています。正規化から先に考えるリレーショナルデータベースの手順とは順序が逆になる点に注意が必要です。この記事では、まず公式定義と標準で備わる機能を整理し、DynamoDB Localをdocker composeで8000番に立ち上げ、複合キーとグローバルセカンダリインデックスを持つテーブルを作り、AWS CLIとPythonの両方でqueryまで通します。あわせて、読み込み4KB・書き込み1KBという課金単位、新規テーブルが最初から出せるスループット、モード切り替えの回数制限を公式クォータの実数値で押さえ、受託開発で採用する条件と見送る要件まで言い切ります。

まとめ：DynamoDBを採用する判断と容量モード選定の結論

先に結論を置きます。

• Amazon DynamoDBはサーバーとバージョンを持たないNoSQLです。公式の定義はサーバーレス・フルマネージド・分散NoSQLで、3つのアベイラビリティゾーンへの自動複製と可用性SLA 99.99%が既定で付きます。
• 設計順序がRDBと逆になります。公式のNoSQL設計指針は、アクセスパターンを先に確定させ、テーブル数をできるだけ少なく保つことを求めています。正規化して後から結合する前提では機能しません。
• 手を動かす最短路はDynamoDB Localです。Dockerイメージ amazon/dynamodb-local を8000番で起動し、AWS CLIに --endpoint-url を渡すだけで、課金なしにcreate-tableからqueryまで通せます。
• 容量モードはオンデマンドが既定であり、公式も既定として推奨しています。新規テーブルは最初から毎秒4,000書き込み・毎秒12,000読み込みを支えられます。
• 切り替えには回数制限があります。プロビジョンドからオンデマンドへの変更は24時間のローリングウィンドウで4回まで。逆方向は随時です。
• 採用の線引きは「キーで引けるか」です。アクセス経路が固定でキー引き中心なら採用、集計と横断検索が主要件ならRDBを選びます。

DynamoDBという製品そのものの位置づけ、料金体系の全体像、RDSとの機能比較を先に押さえたい場合は、AWS DynamoDBとは？特徴・使い方・料金・RDSとの違いで概要を確認してから戻ると、以降のコマンドとクォータの意味が取りやすくなります。

Amazon DynamoDBとは：公式定義と標準で備わる機能の全体像を確認

製品名で調べている段階なら、手を動かす前に「何が最初から付いていて、何を自分で設定するのか」を押さえておくと、後の設計判断で迷いません。ここでは公式ドキュメントの記述だけを根拠に整理します。

サーバーレス・フルマネージド・NoSQLの3要素で読む公式の定義

公式ドキュメント「What is Amazon DynamoDB?」は、DynamoDBを「サーバーレスでフルマネージドな分散NoSQLデータベースで、どの規模でも1桁ミリ秒の性能を出す」と定義しています。提供開始は2012年です。

3つの要素を実装者の言葉に直すと次のとおりです。サーバーレスとは、サーバーの調達もパッチ適用も不要という意味にとどまりません。公式は、DynamoDBにはメジャー・マイナー・パッチのバージョンが存在せず、メンテナンスウィンドウも無いと明記しています。RDBで毎年発生するエンジンのバージョン更新作業が、そもそも発生しない構造です。

NoSQLとして扱えるデータモデルは、キー・バリュー型とドキュメント型の両方です。一方でJOIN演算子は持たず、公式は往復回数を減らすためにデータを非正規化するよう勧めています。強整合性の読み込みとACIDトランザクションには対応しているため、注文確定のように複数項目をまとめて更新する処理も書けます。

認証の考え方もRDBと異なります。DynamoDBへのアクセスはIAMで制御し、データベース用のユーザー名とパスワードは存在しません。接続文字列を秘匿する代わりに、IAMポリシーの範囲をどう絞るかが守りの中心になります。

可用性SLAとバックアップ・暗号化など標準で付く運用機能の一覧

同じ公式ドキュメントに並ぶ運用機能を、追加の設定が要るかどうかで分けました。

既定で付くのは複製と暗号化の2つです。暗号化はAWS所有のKMSキーを使う既定方式なら追加料金がかからず、カスタマー管理キーへ切り替えることもできます。ポイントインタイム復旧（PITR）の保持期間は1〜35日の範囲で指定でき、復旧処理がプロビジョンド容量を消費しない点も明記されています。

注意したいのは課金の範囲です。公式は、読み書きと保存量に加えて「有効化したオプション機能」にも課金すると説明しています。PITRやバックアップ、Streamsを本番で一括有効にする前に、どの機能に費用が乗るかを料金ページで確認してください。常時無料枠は25GBのストレージと、25WCU・25RCUのプロビジョンド容量です。

RDS・Auroraと比べたときの立ち位置と公式が挙げる3つの用途

公式ドキュメントは代表的な用途として3つの業種を挙げています。金融では取引台帳やローン管理、ゲームではゲーム状態・プレイヤーデータ・リーダーボード、動画配信ではコンテンツのメタデータ索引や視聴リストです。いずれも利用者や作品といった主体のキーで引き、時間帯によって負荷が大きく動くという共通点があります。

AWSのデータベースを選ぶときに並ぶのが、RDBのマネージドサービスです。MySQLやPostgreSQLといった既存エンジンをそのまま動かす構成はAmazon RDSの仕組みと対応エンジン・料金モデルで、ストレージを分離して高可用性を高めたRDS互換の構成はAmazon AuroraとRDSの違い・料金モデルで扱っています。比較の軸は次の表のとおりです。

表の差は、どちらが優れているかではなく、何を先に決めるかの違いです。DynamoDBはクエリの形を先に固める代わりに運用作業を手放せます。RDBはクエリの自由度を残す代わりに、エンジンの版やインスタンスの継続的な管理が必要です。この違いが、後半の採用判断の章で使う基準につながります。

DynamoDBの構成要素とRDBとは逆になる設計順序の実装前チェック

コマンドを打つ前に、DynamoDBが何をどう格納しているかを押さえます。ここを飛ばすとキー設計で詰まります。

テーブル・項目・属性の3階層構造とネスト32段までの制約の確認

DynamoDBの構造は3階層です。公式のコアコンポーネント解説では、テーブルが項目（item）の集合であり、項目が属性（attribute）の集合だと定義されています。RDBのテーブル・行・列に対応しますが、決定的に違うのはプライマリキー以外にスキーマが無い点です。

同じテーブルの中で、ある項目は Phone を持ち、別の項目は Address という入れ子のオブジェクトを持つ構造が許されます。入れ子は32段まで許容されると明記されており、テーブル内の項目数とバイト数に実質的な上限はありません。書き込む側の規律を保つ仕組みが無いと、3か月後に status と Status が混在したテーブルが残ります。

パーティションキーとソートキーで決まる物理配置とデータ型の制限

プライマリキーには2種類あります。パーティションキー単独の単純キーと、パーティションキーとソートキーを組み合わせた複合キーです。パーティションキーの値は内部のハッシュ関数に渡され、その出力で項目の格納先パーティションが決まります。

複合キーを選ぶと、同じパーティションキー値を持つ項目が物理的に近接し、ソートキー順に並んで格納されます。この性質が範囲クエリの効率を生む仕組みです。Artist だけを指定すればそのアーティストの全曲が返り、SongTitle の範囲を添えれば部分集合だけを取れます。

キー属性に使える型は3つだけです。文字列・数値・バイナリのスカラー値に限られ、リストやマップはキーにできません。設計時に「日付をキーにしたい」と考えたら、ISO 8601形式の文字列にするか数値のエポック秒にするかを、この時点で決めておきます。

DynamoDB LocalをDockerで起動しテーブル作成まで通す手順

AWSアカウントに課金せずに挙動を確かめられるよう、まずローカルで動かします。手順は公式のDynamoDB Localデプロイ手順に沿います。

docker composeでDynamoDB Localを8000番に立ち上げる設定

JARを直接叩く方法もありますが、チームで環境を揃えるならcomposeが早いです。公式手順の定義をそのまま使います。-sharedDb を付けると、認証情報やリージョンが違っても同じデータベースファイルを参照するため、CLIとアプリの両方から同じテーブルが見えます。

services:
  dynamodb-local:
    command: "-jar DynamoDBLocal.jar -sharedDb -dbPath ./data"
    image: "amazon/dynamodb-local:latest"
    container_name: dynamodb-local
    ports:
      - "8000:8000"
    volumes:
      - "./docker/dynamodb:/home/dynamodblocal/data"
    working_dir: /home/dynamodblocal

起動は docker compose up の1行です。-dbPath とボリュームの組み合わせにより、コンテナを落としてもデータはホスト側に残ります。省略するとインメモリ動作になり、再起動のたびにテーブルが消えます。

AWS CLIのendpoint-url指定でテーブル作成と項目投入を確認

DynamoDB Localは任意の認証情報を受け付けます。公式手順でも fakeMyKeyId のようなダミー値で構わないと明記されています。接続先を切り替えるのは --endpoint-url です。注文データを想定して、複合キーとGSIを持つテーブルを作ります。

aws dynamodb create-table \
  --table-name Orders \
  --attribute-definitions \
      AttributeName=PK,AttributeType=S \
      AttributeName=SK,AttributeType=S \
      AttributeName=Status,AttributeType=S \
  --key-schema \
      AttributeName=PK,KeyType=HASH \
      AttributeName=SK,KeyType=RANGE \
  --billing-mode PAY_PER_REQUEST \
  --global-secondary-indexes '[{"IndexName":"StatusIndex","KeySchema":[{"AttributeName":"Status","KeyType":"HASH"},{"AttributeName":"SK","KeyType":"RANGE"}],"Projection":{"ProjectionType":"KEYS_ONLY"}}]' \
  --endpoint-url http://localhost:8000

属性定義に並べるのはキーに使う属性だけです。Amount のような非キー属性を書くと、インデックスで使われていないという理由でエラーになります。作成できたら項目を1件入れ、前方一致でクエリを投げます。

aws dynamodb put-item \
  --table-name Orders \
  --item '{"PK":{"S":"CUSTOMER#1001"},"SK":{"S":"ORDER#2026-09-07#001"},"Status":{"S":"SHIPPED"},"Amount":{"N":"12800"}}' \
  --endpoint-url http://localhost:8000

aws dynamodb query \
  --table-name Orders \
  --key-condition-expression "PK = :pk AND begins_with(SK, :prefix)" \
  --expression-attribute-values '{":pk":{"S":"CUSTOMER#1001"},":prefix":{"S":"ORDER#2026-09"}}' \
  --endpoint-url http://localhost:8000

ソートキーを ORDER#日付#連番 の順に並べておくと、begins_with で「2026年9月の注文だけ」を1回のqueryで取り出せます。この設計が効くかどうかはキー文字列を決めた時点で確定し、テーブルを作り直さずに後から変える手段はありません。

boto3でDynamoDB Localに接続し項目を読み書きするPythonコード

アプリケーションから触る段階では、SDKを使います。PythonならBoto3のDynamoDBガイドが示すリソースAPIが扱いやすく、CLIで必要だった {"S": ...} のような型記述子を書かずに、Pythonの辞書のまま読み書きできます。先ほど作った Orders テーブルに接続する例です。

import boto3
from boto3.dynamodb.conditions import Key

# ローカル検証用の接続。本番では endpoint_url と認証情報の行を消し、IAMロールに任せる
dynamodb = boto3.resource(
    "dynamodb",
    endpoint_url="http://localhost:8000",
    region_name="ap-northeast-1",
    aws_access_key_id="fakeMyKeyId",
    aws_secret_access_key="fakeSecretAccessKey",
)
table = dynamodb.Table("Orders")

table.put_item(
    Item={
        "PK": "CUSTOMER#1001",
        "SK": "ORDER#2026-09-25#002",
        "Status": "PENDING",
        "Amount": 5400,
    }
)

res = table.query(
    KeyConditionExpression=Key("PK").eq("CUSTOMER#1001")
    & Key("SK").begins_with("ORDER#2026-09")
)
for item in res["Items"]:
    print(item["SK"], item["Status"], item["Amount"])

キー条件は boto3.dynamodb.conditions の Key で組み立てます。eq と begins_with を & でつないだ式は、CLIの key-condition-expression と同じ意味の条件式です。まとまった件数を投入するときは、同じガイドにある batch_writer() を使うと、バッファリングと未処理項目の再送をSDK側が引き受けます。

型の扱いで1つ詰まりやすい点があります。リソースAPIは数値属性を decimal.Decimal で返し、書き込みでもPythonの float をそのまま渡すとエラーになります。金額や割合を小数で持つなら、Decimal("12.5") のように文字列から変換して渡してください。1回のqueryで返るのは最大1MBまでのため、件数が多いときは応答の LastEvaluatedKey を次の呼び出しに渡してページングします。

Node.jsで書く場合の書き方とv2からの移行手順はAWS SDK for JavaScript v3の使い方とDynamoDBの実装例に、LambdaとAPI Gatewayを前段に置いてREST APIとして公開するまでの流れはLambda・DynamoDB・API GatewayでREST APIを作るハンズオンにまとめています。

JRE 17以上とv3系への移行で必要になるimport文の書き換え

DynamoDB Localには3つの系統があります。公式ドキュメントはv3.x を現行（Current）、v2.x をレガシー（Legacy）、v1.x を非推奨（Deprecated）と区分し、ローカルでのテストと開発にはv3.xを勧めています。

実行環境の条件も明示されています。v2.6.0以降を動かすにはJava実行環境（JRE）17.x以降が必要で、それより古いJREでは起動しません。CIコンテナのベースイメージがJava 11のままなら、ここで落ちます。

Javaアプリのテストに組み込む場合、v2.xからv3.xへの移行ではimport文の書き換えが必要です。com.amazonaws.services.dynamodbv2 から software.amazon.dynamodb へ変わり、Maven利用者は依存の指定も更新します。公式ドキュメントが例示しているアーティファクトのバージョンは3.3.0系（2026年9月時点）。稼働中のバージョンはJARに -version を渡せば確認できます。

起動したDynamoDB LocalにGUIで接続し、テーブル設計をアクセスパターンから検証する手順はNoSQL Workbenchの使い方：DynamoDBの設計・ローカル接続・操作手順で解説しています。

アクセスパターンから決めるキー設計とGSI・LSIの使い分け

ローカルで動いたら、次は本番を見据えた設計です。DynamoDBで失敗する案件のほとんどは、この工程を後回しにしています。

設計を始める前に確定させるデータ量・形状・速度の3つの前提条件

公式のNoSQL設計指針は、設計の第一歩を「システムが満たすべきクエリパターンを特定すること」と定義しています。そのうえで、着手前に理解しておく性質を3つ挙げています。

• データ量（Data size）：一度にどれだけ格納し、どれだけ要求されるかがパーティション分割の方針を決めます。
• データ形状（Data shape）：RDBのようにクエリ時に整形するのではなく、クエリされる形のままデータを並べておきます。
• データ速度（Data velocity）：ピーク時のクエリ負荷を先に把握し、I/O容量を使い切れるようキーを分散させます。

指針はRDBとの得手不得手の差も言い切っています。限られた方法なら効率よくクエリできる一方、その範囲を外れたクエリは高価で遅くなる、という記述です。この一文が採用判断の基準になります。

テーブル数を絞る設計とGSIで別クエリ経路を足すときの判断基準

公式指針は「DynamoDBアプリケーションではテーブル数をできるだけ少なく保つべき」と明記しています。理由はスケーラビリティ、権限管理の単純化、オーバーヘッドとバックアップコストの削減です。関連データを1か所にまとめる参照の局所性が応答時間の改善につながる、という説明も添えられています。

例外も示されています。大量の時系列データを扱う場合と、アクセスパターンがまったく異なるデータセットを持つ場合の2つです。当てはまらないなら、単一テーブルに寄せてキーの前置詞で実体を区別する設計が既定路線になります。

1つのキー構成では引けないクエリが出てきたら、グローバルセカンダリインデックス（GSI）を足します。GSIはベーステーブルと異なるパーティションキーとソートキーを持てるインデックスで、ローカルセカンダリインデックス（LSI）はパーティションキーが同一でソートキーだけが異なるもの。LSIはテーブル作成時にしか定義できないため、後から足せるのはGSIだけだと考えて設計します。

射影属性100とインデックス数のクォータから逆算する設計上限

インデックスは無制限には足せません。公式のクォータ一覧が示す上限から、設計の余地を逆算します。

射影属性の100という数字は見落とされがちです。これはローカルとグローバル両方のセカンダリインデックスを合計した数で、同じ属性名を2つのインデックスに射影すると2つとして数えられます。射影タイプが KEYS_ONLY または ALL のインデックスは対象外のため、INCLUDE を多用する設計だけがこの壁に当たります。

ストリームの制約も設計条件の一つです。単一リージョンのテーブルなら同一シャードを同時に読む処理は2つまで、グローバルテーブルで推奨されるのは1つです。購読者を増やす構成にするなら、間にファンアウトの層を置く判断になります。多リージョン複製そのものの挙動はDynamoDB Global Tablesの複製の仕組みと強整合性で扱っています。

オンデマンドとプロビジョンドの容量モード選定と切り替え回数の制約

DynamoDBの料金と性能は、容量モードの選択でほぼ決まります。

読み込み4KB・書き込み1KBを単位とする課金単位の数え方の確認

オンデマンドモードの公式解説は、課金単位を次のように定義しています。1読み込みリクエストユニット（RRU）は、4KBまでの項目に対する強整合性読み込み1回、または結果整合性読み込み2回に相当します。1書き込みリクエストユニット（WRU）は、1KBまでの項目に対する書き込み1回です。

この非対称性が見積もりの起点です。同じ1件のデータでも、読みは4KB刻み、書きは1KB刻みで数えられます。3KBの項目を1件書けば3WRU、同じ項目を強整合性で1件読めば1RRU。項目サイズを1KB以内に収める設計が、書き込みコストにそのまま効きます。この単位を東京リージョンの単価に当てはめた月額の試算と、GSIやScanで請求が跳ねる条件はDynamoDBの料金を東京リージョンの実額で試算するで扱っています。

プロビジョンドモードでは同じ単位がRCU・WCUという名前になり、毎秒あたりの容量として事前に確保します。公式の料金ページが案内する無料利用枠は、月あたり25WCU・25RCUと25GBのストレージ。検証環境やごく小規模な内部ツールなら、この枠内で運用できる場合があります。

新規テーブルの初期スループットと直近ピーク2倍までの即時拡張

「オンデマンドは無限にスケールする」という説明をよく見かけますが、公式ドキュメントはもっと具体的な数字を示しています。新規のオンデマンドテーブルは、毎秒4,000書き込みと毎秒12,000読み込みまでを支えられる状態で始まります。

そこから先は、直近ピークの2倍までを即座に受け止める挙動です。毎秒25,000〜50,000の強整合性読み込みで推移しているテーブルなら、毎秒100,000までは待たずに到達できます。その100,000を実際に出せば新しいピークとなり、次は200,000まで届きます。

注意すべきは30分の制約です。直近ピークの2倍を超える増加を30分以内に起こすと、スロットリングが発生しえます。公式が勧めるのは、事前ウォームを行うか、トラフィックの増加を30分以上かけて分散させることの2つ。キャンペーン開始時刻に負荷が跳ねる設計なら、この制約を前提に計画します。

切り替え回数の非対称性は運用に影響します。プロビジョンドからオンデマンドへ変えられるのは24時間のローリングウィンドウで4回まで、逆方向は随時です。負荷試験のたびにモードを往復させる運用は、この上限に当たります。プロビジョンドの容量引き下げも、1日4回から始まり毎時1回ずつ補充されて、24時間で最大27回という設計です。

ウォームスループットの事前引き上げと下げられない制約への対処

ウォームスループットは、テーブルが即座に処理できる読み書き操作数を表す値です。全テーブルとGSIに既定で設定され、過去の使用実績に応じてDynamoDBが自動で引き上げます。値の参照に費用はかかりません。

販売開始やキャンペーンのように、要求が10倍・100倍に跳ねると分かっている場合は、事前にこの値を引き上げられます。これが事前ウォーム（pre-warming）で、課金モードやスループット設定を変えずに実行できる手段です。公式のCLI例ではテーブルとGSIを同時に更新しています。

aws dynamodb update-table \
  --table-name Orders \
  --warm-throughput ReadUnitsPerSecond=12345,WriteUnitsPerSecond=4567 \
  --region ap-northeast-1

ここには戻せない制約があります。ウォームスループットは一度引き上げると、その値を引き下げられません。既定値のままなら無料である一方、事前ウォームのために引き上げた分のリクエストには課金が発生します。「とりあえず上限まで上げておく」という運用は費用に跳ね返るため、想定ピークから逆算した値を1回で決める進め方にしてください。所要時間は設定値とテーブルやインデックスのサイズに依存します。

受託開発でDynamoDBを採用する条件と見送るべき業務要件の線引き

ここからは判断です。

キー引き中心の要件でDynamoDBを採用してよい3つの条件

採用してよいのは、次の3つがそろう場合に絞ります。第一に、アクセス経路が事前に列挙でき、大半がパーティションキーの指定で完結すること。第二に、1KB前後に収まる小さな項目の書き込みが主であること。第三に、平常時とピーク時でトラフィックが桁違いに動くこと。

この3条件に当てはまる典型は、セッション管理、イベントログ、注文や予約のような主体ごとに引く履歴データです。いずれも「誰の」「いつからいつまで」というキーで引き切れる形。有効期限を持つデータなら、期限切れ項目の自動削除で保存量を抑える手も取れます。設定手順はDynamoDB TTLの設定方法と自動削除の仕組みにまとめています。

逆に、条件を1つでも満たさないまま「サーバーレスだから」という理由で選んだ構成は、運用に入ってから苦しくなります。RDB前提の業務システムをAWSへ移す案件で、DynamoDBを選ぶ妥当性の見極めから設計に入りたい場合は、AWSインフラ構築の相談窓口で要件の棚卸しから対応しています。

集計と横断検索が主要件なら見送りRDBを選ぶべき失敗パターン

見送る場面ははっきりしています。月次の集計、条件を組み替えた横断検索、後から増えるレポート要件が業務の中心なら、DynamoDBは選びません。公式指針が言う「限られた方法を外れたクエリは高価で遅い」に該当し、実装はスキャンの連発に落ちます。

失敗の型はこうです。初期要件が「ユーザーIDで引くだけ」だったためDynamoDBを採用し、リリース後に「部署別の月次集計を出したい」「ステータス横断で検索したい」という要求が続く。GSIを足して凌ぐが、射影属性の合計100という上限に近づく。結果として、RDBなら1本のSQLで済む集計に、専用のインデックスとバッチを作り続けることになります。

判断基準を1つに絞るなら、「主要な読み取りの8割以上をキー指定で書けるか」です。書けないなら、Amazon RDSやAuroraを主に据え、キー引きが効く部分だけをDynamoDBへ切り出します。全部を1つのデータストアに寄せる必要はありません。集計だけが後から必要になった場合は、公式が案内するAmazon Redshiftとのゼロ ETL 統合で分析側へ渡す選択肢もあり、DynamoDB上で集計クエリを書き続けるより筋のよい逃げ道になります。

ベクトルインデックスのクォータから見る生成AI用途の適用範囲

DynamoDBのクォータ一覧には、ベクトルインデックスの項目が並んでいます。生成AIの検索拡張（RAG）用途で使えるかを判断するために、公式が示す数値を確認します。

公式は具体的な換算例まで示しています。768次元の埋め込みに1KBの非ベクトルデータを持たせると1項目は約4KBになり、パーティションキーあたりの上限は毎秒約250,000ベクトルの検索と毎秒2,500ベクトルの書き込みに相当する計算です。スループットはパーティションキー値をまたいで線形にスケールします。

ここから言えることは限定的です。テナントごと・製品カテゴリごとのように、パーティションキーで自然に分割できる類似検索なら現実的な選択肢になります。一方、全社横断で全文書を対象にした類似検索を1つのキーに寄せる設計は、パーティションあたりの上限に当たります。ベクトルインデックスの作成から検索までの手順と料金、索引漏れの落とし穴はDynamoDBのベクトル検索とは：SearchVectorsの手順・料金・S3 Vectorsとの使い分けで解説しています。

よくある質問

Amazon DynamoDBの導入検討で実際に問い合わせの多い5つに答えます。

Amazon DynamoDBとRDSはどちらを選べばよいですか？

主要な読み取りをキー指定で書けるかで分けます。ユーザーIDや注文IDのような主体キーで8割以上のクエリが完結するならDynamoDB、条件を組み替えた検索や集計が業務の中心ならRDSやAuroraです。公式のNoSQL設計指針も、限られた方法なら効率よく引ける一方、その範囲を外れたクエリは高価で遅くなると明記しています。両方を併用し、キー引きの部分だけDynamoDBに切り出す構成も選べます。

DynamoDBの料金は何で決まりますか？

読み書きの量とストレージ量、それに選んだ容量モードで決まります。オンデマンドでは、4KBまでの強整合性読み込み1回が1RRU、1KBまでの書き込み1回が1WRUとして数えられる仕組みです。プロビジョンドでは、実際の消費量ではなく確保した容量に対して時間課金されます。PITRやバックアップなど有効化したオプション機能も別に課金されます。無料利用枠は月25WCU・25RCUと25GBのストレージ。リージョン別の単価は公式の料金ページで時点を確認してください。

DynamoDB Localと本番環境の違いは何ですか？

DynamoDB Localは開発とテスト用のローカル実装で、認証情報の検証を行わずダミー値でも動きます。容量モードやスループットの設定は受け付けますが、実際のスロットリング挙動やレイテンシは本番と同一ではありません。API互換で作られているため、テーブル定義とクエリの検証には使えます。boto3などのSDKも接続先を endpoint_url で切り替えるだけで同じコードを流用できます。スループットの限界検証やコスト測定は、実際のAWS環境で行う前提にしてください。

容量モードは後から変更できますか？

変更できますが、方向によって制限が異なります。プロビジョンドからオンデマンドへの切り替えは、24時間のローリングウィンドウで4回まで。オンデマンドからプロビジョンドへは随時切り替えが可能です。プロビジョンドモードの容量引き下げは、1日4回から始まり毎時1回ずつ補充されるため、24時間で最大27回まで実行できます。負荷試験でモードを頻繁に往復させる運用は、この上限に当たります。

DynamoDBでスロットリングが起きたらどう対処しますか？

まず原因を、テーブル全体の上限とパーティション偏りのどちらかに切り分けます。オンデマンドで急激な増加が原因なら、直近ピークの2倍を超える増加を30分以内に起こしていないかを確認し、ウォームスループットの事前引き上げを検討します。特定のキーに集中しているなら、パーティションキーに接尾辞を付けて分散させる設計変更が必要です。テーブル既定の40,000という上限に届いているなら、Service Quotasから引き上げを申請します。

関連記事

• AWS DynamoDBとは？特徴・使い方・料金・RDSとの違いを実装目線で解説：製品の位置づけと料金体系の全体像を実装前に把握したい場合に。
• DynamoDBの料金を東京リージョンの実額で試算する：請求が跳ねる設計と単価の下げ方：課金単位を東京リージョンの単価に当てはめた月額試算です。
• Amazon RDSとは？仕組み・対応エンジンと料金モデル・採用判断を実装者目線で解説：RDBを選ぶ側の判断材料をまとめています。
• AWS サーバーレス ハンズオン｜Lambda・DynamoDB・API GatewayでREST APIを作る手順：本記事のテーブルをAPIとして公開する次の一歩に。
• DynamoDB Global Tables（グローバルテーブル）とは｜複製の仕組み・強整合性・料金：本記事で触れた多リージョン複製と整合性モードの詳細を扱っています。
• DynamoDB TTLとは｜設定方法・自動削除の仕組みと期限切れ項目の扱い：有効期限つきデータの保存量とコストを抑える具体的な設定手順です。
• インフラ構築（AWS・Google Cloud・Azure）：DynamoDBを含むAWS構成の設計と移行を請け負っています。