Amazon DynamoDBとは？仕組み・使い方・料金とRDSとの違いを実装目線で解説

Amazon DynamoDBは、AWSがフルマネージドで提供するキーバリュー型のNoSQLデータベースです。サーバーの構築や容量設計をせずに、数ミリ秒台の応答を保ったまま秒間数百万リクエストまで自動でスケールできます。一方で、テーブルをまたぐ結合やSQLのGROUP BYのような集計はもともと苦手で、RDS（リレーショナルデータベース）と同じ感覚で設計すると破綻するため、アクセスパターンを先に決める設計が前提です。この記事では、DynamoDBの仕組みと用語、上限値、RDSとの使い分け、DynamoDB LocalとAWS CLI・Python（boto3）での具体的な操作、テーブル設計のベストプラクティス、2024年11月の値下げを反映した料金の考え方、そして採用しない場面までを、実装の判断に使える粒度で整理します。仕様と数値は2026年10月時点のAWS公式の開発者ガイドと料金ページで確認したものです。

まとめ：Amazon DynamoDBの正体と選ぶ条件・選ばない条件

先に結論から押さえます。詳細は各章で掘り下げます。

• 正体：AWSのフルマネージドNoSQL。キー（パーティションキー＋任意のソートキー）でアイテムを引く設計が前提で、サーバー運用は不要。
• 得意：単純なキー検索を大量・低レイテンシで捌く用途（セッション、カート、IoT、ゲームのスコア、リアルタイム更新）。
• 苦手：結合、範囲を横断する検索、SUM/COUNT/GROUP BYのようなサーバー側集計。ここはRDSやDynamoDB外の分析基盤に逃がす。
• 上限：1アイテム400KBまで、Queryの結果は1回1MBまで。大きなファイルはS3に置き、DynamoDBにはキーとメタデータだけを持たせる。
• RDSとの分岐：アクセスパターンが事前に決まり、スケールと運用の手離れを優先するならDynamoDB。複雑なクエリ・トランザクション・後からの検索軸追加を優先するならRDS。
• 料金：オンデマンドはリクエスト量、プロビジョンドは確保容量に課金。2024年11月にオンデマンドのスループット単価が50%引き下げられ、小規模なら月数ドルから始められる。

判断に迷ったら「読み方を3〜5パターンに書き出せるか」で決めてください。書き出せないうちはRDSかAuroraを選び、DynamoDBは見送ります。

Amazon DynamoDBとは｜AWSのフルマネージドNoSQLデータベースの仕組み

DynamoDBは、テーブルの作成以外にインフラ管理を必要としないNoSQLデータベースです。レプリケーション、パッチ適用、スケーリング、フェイルオーバーはすべてAWS側が担い、利用者はデータとアクセスパターンの設計に集中できます。複数のアベイラビリティゾーンへ自動で冗長化されるため、単一障害点を意識せずに高可用な構成を組めます。MongoDB互換のドキュメント指向データベースをAWSで使いたい場合はAmazon DocumentDBの仕組みと採用判断、Apache Cassandra互換のサーバーレスNoSQLを探すならAmazon Keyspacesの仕組みと料金が、DynamoDBと並ぶAWS内の選択肢です。

キーバリュー型とサーバーレス運用という2つの核で決まる設計上の性格

DynamoDBの性格を決めているのは、キーバリュー（＋ドキュメント）モデルと、サーバーレスな運用の2点です。データは「キーで一意に引く」ことを前提に格納し、キーで指すアクセスは件数が増えても応答時間がほぼ一定に保たれます。裏側のパーティション増減やスループット調整は自動で行われるため、アクセス急増に備えたキャパシティのプロビジョニングを人手で先読みする必要がありません。

この「事前に容量を積まなくてよい」性質が、トラフィックの読めないサービスでDynamoDBが選ばれる最大の理由です。キーバリューストアという分類そのものの考え方は、KVS（キーバリューストア）の仕組みとRDBとの使い分けでRedisを動かしながら説明しています。

テーブル・アイテム・属性・キーの用語をRDBの表・行・列と対応づけ

RDBの表・行・列とは用語が対応しつつも意味が違うため、最初に揃えておきます。

DynamoDBは固定スキーマを持ちません。列を後から追加するといったマイグレーションは不要で、アイテムごとに属性を変えられます。ただしキー（パーティションキー、必要ならソートキー）だけはテーブル作成時に決め、後から変更できません。キー設計＝アクセスパターン設計であり、ここが後述のベストプラクティスの中心になります。

得意なことと苦手なこと：結合・サーバー側集計は非対応という前提

DynamoDBが強いのは、キーで一意に、あるいはソートキーの範囲で引く操作を、データ量に関係なく安定した速度で捌く点です。逆に、テーブル同士の結合（JOIN）はサポートせず、キー以外の条件での全件検索（Scan）はテーブル全体を読むため遅く高コストになります。SUM・COUNT・GROUP BYのようなサーバー側集計もありません。

「あらゆる切り口で自由に検索・集計したい」という要件には向かず、その場合はRDSや分析基盤を併用します。この弱点を正面から扱う方法は後半の集計の章で具体化します。

設計前に知っておく上限値：アイテム400KB・Query1MB・GSI20個

DynamoDBには、設計を縛る固定の上限があります。後から引き上げられない値もあるため、キー設計の前に確認しておきます。数値は公式の制約一覧（Constraints）とクォータ一覧（Service Quotas）の2026年10月時点の記載です。

実務で最初に当たるのは、400KBと1MBの2つです。属性名もサイズに数えるため、customer_shipping_addressのような長い属性名を何百万件にも持たせると、そのぶん容量と読み書きユニットを食います。

RDS・RDB（リレーショナルデータベース）との違いと使い分けの判断基準

「dynamodb rds」「dynamodb rds 使い分け」といった比較の検索が多く、実務でも最初に迷うのがここです。DynamoDB（NoSQL）とRDS（Amazon RDS＝MySQLやPostgreSQL等のマネージドRDB）は、設計思想が逆と言ってよいほど違います。RDB全般とNoSQLの選び方はデータベースとは？種類・DBMS・RDBとNoSQLの選び方でも整理しています。

DynamoDBを選ぶ判断基準とRDSを選ぶ判断基準をアクセスパターンで切る

選定では「アクセスパターンが読めるか」を判断軸に据えて、DynamoDBとRDSの使い分けを決めます。DynamoDBが向くのは、引き方（誰が・どのキーで・どんな範囲で読むか）が設計時点でほぼ確定していて、その少数のパターンを大量に・低レイテンシで叩くケースです。ユーザーセッション、ショッピングカート、IoTの時系列、ゲームの状態管理などが典型です。

逆にRDSを選ぶべきは、検索軸が後から増える／決めきれない場合、複数テーブルの結合や複雑な集計レポートが要件の中心にある場合、そして厳密なトランザクション整合性が業務要件になっている（会計・在庫の整合など）場合です。「とりあえず柔軟に検索できる状態にしておきたい」ならRDSが無難で、DynamoDBを選んで後から検索軸を足そうとすると、GSIの追加や設計変更で苦しみます。接続数の多いRDS構成ではRDS Proxyによる接続プーリングも検討材料になります。

RDBを選ぶがスケールと可用性も欲しい、という中間の要件なら、AWSではAuroraが受け皿です。違いはAmazon Auroraの仕組みとRDSとの違いで比べています。

DynamoDB LocalとAWS CLIの使い方｜テーブル作成・CRUDの手順

概念だけでは掴みにくいので、手元で実際に触る流れを示します。AWSに課金されずに試すならDynamoDB Localから始め、同じコマンドを本番のAWSに向けるときは--endpoint-urlを外すだけです。本番に向ける場合は、事前にAWS CLIの設定（aws configure）とDynamoDBへの権限が必要です。ここではオンデマンドモード（PAY_PER_REQUEST）で作成し、容量設計を省きます。

DynamoDB Localをdocker composeで起動し無料で手元検証する手順

DynamoDB LocalはAWSが配布するローカル実行版で、2026年10月時点の公式ドキュメントではv3.x系が現行（v2.x系はレガシー）と案内されています。Dockerイメージamazon/dynamodb-localを使えば、Javaのインストールなしで起動が可能です。次のdocker-compose.ymlを置いてdocker compose up -dを実行します。

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

ローカル版は認証情報の中身を検証しませんが、値そのものは必須です。ダミー値を環境変数に入れ、接続先をhttp://localhost:8000に向けて疎通を確かめます。

export AWS_ACCESS_KEY_ID=dummy
export AWS_SECRET_ACCESS_KEY=dummy
export AWS_DEFAULT_REGION=ap-northeast-1
aws dynamodb list-tables --endpoint-url http://localhost:8000

{"TableNames": []}が返れば準備完了です。以降のコマンドは、ローカルで試す間は末尾に--endpoint-url http://localhost:8000を付けてください。キー設計やGSIまで手元で詰める手順は、DynamoDB LocalでのキーとGSI設計から容量モード選定までの実装手順にまとめています。

テーブル作成とキー設計：create-tableでパーティションキーとソートキー

ユーザーの注文履歴を例に、パーティションキーUserIdとソートキーOrderIdの複合キーでテーブルを作ります。ソートキーを持たせることで「あるユーザーの注文を範囲で引く」アクセスが可能になります。

aws dynamodb create-table \
  --table-name Orders \
  --attribute-definitions \
    AttributeName=UserId,AttributeType=S \
    AttributeName=OrderId,AttributeType=S \
  --key-schema \
    AttributeName=UserId,KeyType=HASH \
    AttributeName=OrderId,KeyType=RANGE \
  --billing-mode PAY_PER_REQUEST

KeyType=HASHがパーティションキー、RANGEがソートキーです。AttributeType=Sは文字列型（数値はN、バイナリはB）。キーに使う属性だけをattribute-definitionsで宣言し、それ以外の属性はここに書きません（書き込み時に自由に付けられます）。

データの書き込みと読み取り：put-item・get-item・queryの3操作

アイテムを1件書き込み、キーで取り出します。属性値は型を明示したJSON（{"S":"..."}は文字列）で渡します。

# 書き込み
aws dynamodb put-item --table-name Orders --item '{
  "UserId":  {"S": "u001"},
  "OrderId": {"S": "2026-07-0001"},
  "Amount":  {"N": "12800"},
  "Status":  {"S": "paid"}
}'

# キー完全一致で1件取得
aws dynamodb get-item --table-name Orders \
  --key '{"UserId":{"S":"u001"},"OrderId":{"S":"2026-07-0001"}}'

あるユーザーの注文を範囲でまとめて引くにはQueryを使います。パーティションキーを固定し、ソートキーの条件を添えるのがDynamoDBらしい引き方です。全件を舐めるScanと違い、Queryは対象パーティションだけを読むため速く安価です。

aws dynamodb query --table-name Orders \
  --key-condition-expression "UserId = :u AND begins_with(OrderId, :ym)" \
  --expression-attribute-values '{":u":{"S":"u001"},":ym":{"S":"2026-07"}}'

Python（boto3）でQueryを書き1MB上限をページングで越える実装例

アプリケーションから使う場合は、AWS SDKを通します。Pythonならboto3のDynamoDBリファレンスが一次情報です。Queryの結果は1回1MBで打ち切られるため、応答にLastEvaluatedKeyが含まれる間は続きを取りに行くループが必要になります。これを書き忘れると、データが増えた時点で「一部しか返らない」不具合になります。

import boto3
from boto3.dynamodb.conditions import Key

# ローカル検証時は endpoint_url を指定し、本番では外す
dynamodb = boto3.resource("dynamodb", endpoint_url="http://localhost:8000")
table = dynamodb.Table("Orders")

def orders_of_month(user_id: str, ym: str) -> list[dict]:
    items, kwargs = [], {
        "KeyConditionExpression": Key("UserId").eq(user_id) & Key("OrderId").begins_with(ym)
    }
    while True:
        resp = table.query(**kwargs)
        items.extend(resp["Items"])
        if "LastEvaluatedKey" not in resp:
            return items
        kwargs["ExclusiveStartKey"] = resp["LastEvaluatedKey"]

print(len(orders_of_month("u001", "2026-07")))

JavaScript（Node.js）で同じことをする場合は、v3 SDKのクライアント分割とページネーターの使い方をAWS SDK for JavaScript v3の使い方とDynamoDBの実装例で扱っています。

PartiQLでSQLライクに操作するときもScan相当になる条件

SQLに慣れているなら、DynamoDBが対応するPartiQL（SQL互換のクエリ言語）で書けます。SELECT・INSERT・UPDATE・DELETEをSQLに近い構文で扱えますが、内部で走るのはあくまでキー検索であり、パーティションキーを指定しないSELECTはScan相当になって遅くなる点は変わりません。SQL構文が使えても、RDBの自由なクエリが手に入るわけではないと理解しておきます。

aws dynamodb execute-statement \
  --statement "SELECT * FROM Orders WHERE UserId = 'u001'"

テーブル設計とアクセスパターン設計のベストプラクティスと失敗パターン

DynamoDBの性能とコストは、テーブル設計でほぼ決まります。RDBのように正規化してから考えるのではなく、「どんなクエリを何回叩くか」を先に列挙し、そのアクセスパターンを満たすキーとインデックスを逆算するのが定石です。

パーティションキー設計とホットパーティションを避けるキーの選び方

最も避けたいのがホットパーティション、つまり特定のパーティションキーにアクセスが集中して、そこだけがスループット上限に張り付く状態です。日付（2026-07-18のような値）や、特定の人気ユーザーIDをそのままパーティションキーにすると、読み書きが1点に集まって性能が頭打ちになります。

回避策は、値の分布が広い属性をキーに選ぶこと、必要なら末尾にランダムなサフィックスを付けて書き込みを複数パーティションへ散らすこと（ライトシャーディング）です。設計段階でキーのカーディナリティ（取り得る値の多様さ）を確認しておきます。考え方の原典は公式のパーティションキー設計のベストプラクティスにあります。

GSIとLSIの使い分け：後から足せるGSIを基本にする判断

キー以外の属性で検索したいときは、セカンダリインデックスを使います。GSI（グローバルセカンダリインデックス）は別のパーティションキー／ソートキーを持てるインデックスで、後から追加でき、テーブルとは別にスループットを持ちます。LSI（ローカルセカンダリインデックス）は同じパーティションキーのまま別のソートキーで引くもので、テーブル作成時にしか作れません。

実務ではまずGSIで足ります。LSIはテーブル作成時に必要性が確定しているとき限定と考えてよく、迷ったらGSIを選びます。ただしGSIは対象属性の書き込みごとに追加の書き込みコストが発生するため、乱立させないでください。1テーブルあたりの既定上限は20個ですが、5個を超えたあたりで「アクセスパターンの洗い出しが甘いのでは」と疑うのが健全です。

シングルテーブル設計を採るか実体ごとに分けるかの要件別の判断基準

DynamoDBには、複数の実体（ユーザー・注文・商品など）を1つのテーブルに混在させ、キーの命名規則で引き分ける「シングルテーブル設計」という流儀があります。結合が使えないDynamoDBで、1回のQueryで関連データをまとめて取得するための設計です。

強力ですが学習コストが高く、アクセスパターンが将来変わると作り直しが重くなります。小〜中規模で要件が動くうちは、実体ごとにテーブルを分ける素直な設計のほうが保守しやすく、シングルテーブル設計は「アクセスパターンが固まり、コストと性能を極限まで詰める段階」で検討する、という順序が現実的です。

料金体系とキャパシティモード｜オンデマンドとプロビジョンドの選び方

DynamoDBの課金は、スループット（読み書きの処理量）とストレージが柱です。スループットの課金方式に、オンデマンドとプロビジョンドの2モードがあります。オンデマンドは実際のリクエスト量に応じた従量課金で容量設計が不要、プロビジョンドは1秒あたりの処理容量を事前に確保して単価を抑える方式です。トラフィックが読めない立ち上げ期はオンデマンド、定常的で予測可能な負荷になったらプロビジョンド＋オートスケーリング、という移行が定番です。プロビジョンドからオンデマンドへの切り替えは24時間で4回までという制約があるため、頻繁な往復は想定しないでください。

読み書きユニット（RRU・WRU）の計算方法：4KBと1KBと整合性の関係

処理量は読み書きの単位で数えます。読み取りはRRU（オンデマンド）／RCU（プロビジョンド）、書き込みはWRU／WCUで、サイズと整合性で消費量が決まります。

旧版のこの記事には「1日100万回・各4KBの強整合読み取りで月約780ドル」という記述がありましたが、これは単価の誤りで、実勢の200倍ほど高く見積もっていました。正しくは、1日100万回の強整合読み取り（各4KB以下）は1日100万RRU、月3,000万RRUです。後述のus-east-1のオンデマンド単価（100万RRUあたり約0.125ドル）で計算すると、月およそ3.75ドルにすぎません。結果整合ならさらに半額です。

書き込みは1KB単位で切り上がる点に注意してください。1.2KBのアイテムを1回書くと2WRUを消費します。DynamoDBは「アイテムを小さく保ち、強整合が不要な読み取りは結果整合にする」だけで読み取りコストが半分になる、というのがコスト設計の勘所です。

2024年11月の50%値下げとDatabase Savings Plansの費用削減

AWSの発表によると、2024年11月1日からオンデマンドのスループット単価が50%引き下げられ、グローバルテーブルも最大67%引き下げられました。この改定で、従量課金のオンデマンドが以前より格段に選びやすくなっています。

2026年10月時点の料金ページの計算例では、us-east-1（バージニア北部）のオンデマンドは書き込みが100万WRUあたり0.625ドル、読み取りが100万RRUあたり0.125ドル、Standardテーブルクラスのストレージが1GB月あたり0.25ドルです。東京リージョン（ap-northeast-1）はこれより高めで、単価はリージョンと時期で変わるため、確定値は必ず公式の料金ページで確認してください。東京リージョンの実額と月額の試算手順はDynamoDBの料金を東京リージョンの実額で試算するにまとめています。

定常負荷にはプロビジョンドのリザーブドキャパシティに加え、2025年12月2日に発表されたDatabase Savings Plansも選択肢になります。DynamoDBではオンデマンドで最大18%、プロビジョンドで最大12%の割引で、契約は1年単位です。オンデマンドに効くコミットメント割引はこれが初めてなので、「容量は読めないが月額の下限は読める」サービスと相性が良い仕組みです。

DynamoDBで集計・分析する方法｜サーバー側集計がない弱点と3つの回避策

「dynamodb 集計」「dynamodb 分析」で来る読者がつまずくのがここです。前述のとおりDynamoDBにサーバー側の集計（SUM／COUNT／GROUP BY）はなく、Scanでアプリ側集計するとテーブル全体を読んで遅く高コストです。分析用途にDynamoDB単体を選ぶべきではありません。代わりに、次の3つで役割を分けます。

• 増分集計（Streams＋Lambda）：DynamoDB Streamsで変更イベントを捕捉し、Lambdaで集計値（合計・件数など）を別アイテムに逐次更新する。リアルタイムの累計を持ちたいときの定番。変更フィードという設計パターン自体はチェンジフィードの実装と採用判断で、Lambda側の課金とコールドスタートはAWS Lambdaの仕組みと料金体系で扱っている。
• S3エクスポート＋Athena：S3へのテーブルエクスポートは読み取りキャパシティを消費せずにテーブルをS3へ出せる（PITRの有効化が前提）。出したデータをAmazon AthenaやGlueでSQL分析する。バッチの集計・レポート向き。
• Zero-ETL連携：Amazon OpenSearch ServiceやAmazon Redshiftへ、ETLパイプラインを自作せずにデータを流し込む。全文検索や本格的な分析クエリを別エンジンに任せる。

いずれも「DynamoDBは書き込みと単純検索の源泉、集計・分析は別サービス」という分業です。DynamoDBのテーブル内で完結させようとしないことが、結果的にコストと性能の両方を守ります。

セキュリティ｜保存時暗号化とIAMによるアクセス制御の基本設定

DynamoDBは保存データを既定で暗号化します（保存時の暗号化）。鍵はAWS KMSで管理され、AWS所有のキー、AWSマネージドキー、自分で管理するカスタマーマネージドキー（CMK）から選べます。要件がなければ既定のままで保存時暗号化が効いており、通信はTLSで保護されます。

アクセス制御はIAMで行い、テーブルや項目・属性の単位まで権限を絞れます。誰がどのテーブルを読み書きしたかはAWS CloudTrailで追跡できるため、最小権限のIAMポリシーとCloudTrailの有効化を基本線に据えます。

主要機能の早わかり｜ストリーム・グローバルテーブル・TTL・PITR・ベクトル検索

設計時に押さえておきたい主要機能を、役割で一覧にします。

DynamoDB Streamsで時系列に記録した挿入・更新・削除は、Lambdaと連携して後続処理につなげます。グローバルテーブルでは、複数リージョン間の同期に使う整合性として、結果整合（MREC）と強整合（MRSC）を選択可能です。バックアップはオンデマンドで取得でき、PITRでは復旧期間を1〜35日で設定し、その期間内の任意時点へ秒単位で戻せます。ベクトルインデックスはSearchVectors APIで埋め込みベクトルを検索する機能です。対応するベクトルは最大4,096次元で、インデックスは1テーブル5個まで作成できます。

これらは必要になったテーブルで個別に有効化します。とくにStreamsは前述の増分集計や、他システムへのデータ連携の起点として使う頻度が高い機能です。グローバルテーブルの複製の仕組みと強整合性の条件はDynamoDB Global Tablesの複製の仕組みと料金、TTLの設定と削除タイミングはDynamoDB TTLの設定方法と自動削除の仕組みで個別に解説しています。

PITRはRecoveryPeriodInDaysで復旧期間を短くしても料金は変わらないと公式に明記されています。費用目的で短縮する意味はないので、監査要件で短くしたい場合を除き、復旧期間は既定の35日のままにする方針です。ベクトルインデックスは2026年に加わった新しい機能で、フィルタは等価条件のみ・結果は結果整合という制約があります。RAGの検索層を別のベクトルDBに分けずに済む反面、本格的な全文検索やハイブリッド検索まで求めるならOpenSearchのほうが向いています。

DynamoDBを採用しない場面と受託開発で設計を固める前の確認事項

ここまでの仕様を踏まえ、採用を見送る条件を言い切っておきます。次のどれかに当てはまるなら、DynamoDBは選びません。

• 業務アプリの管理画面で、検索条件の組み合わせを利用者が自由に選べる要件がある（受発注・顧客管理・在庫照会など）。GSIを足し続ける設計になり、RDSのほうが安く速く作れる。
• 月次の売上集計や帳票出力が主目的で、リアルタイム性が要らない。集計基盤を別に組むコストが、RDBで1本のSQLを書くコストを上回る。
• 複数テーブルにまたがる整合性（受注と在庫と請求の同時更新など）が日常的に発生し、100アイテム・4MBのトランザクション上限に収まらない。
• チームにDynamoDBのキー設計経験者がおらず、要件もまだ動いている。後からのキー変更はテーブル作り直しとデータ移行を伴う。

反対に、セッションやカート、IoTの計測値、APIのレート制御、通知の既読管理のように「キーが決まっていて量が読めない」データは、DynamoDBが最も費用対効果の高い置き場になります。現実の構成では、業務データの本体はRDSかAurora、高頻度で単純なデータはDynamoDB、と1システムの中でデータの性質に合わせて併用する構成が一般的です。LambdaとAPI Gatewayを組み合わせたサーバーレス構成の作り方はLambda・DynamoDB・API GatewayでREST APIを作る手順で通して確認できます。

どのデータをどちらに置くかの線引き、キー設計のレビュー、RDSとの併用構成やコスト試算を含めて外部に相談したい場合は、一創のAWSを中心としたインフラ構築サービスで、要件整理の段階から対応しています。

よくある質問

Amazon DynamoDBについて、検索の多い質問に短く答えます。

DynamoDBとRDSはどちらが安いですか？

一概には言えず、アクセスの形で決まります。少数のキー検索を大量に叩く用途では、アイドル時に課金されないオンデマンドのDynamoDBが安くなりやすい一方、複雑なクエリを常時流す用途では、インスタンス課金でも結合・集計を1クエリで済ませられるRDSのほうが総額で有利なことがあります。DynamoDBはアイテムを小さく保ち結果整合を使うほど安くなるので、まず読み書き量を見積もって比較してください。

DynamoDBは無料で使えますか？

料金ページでは、25GBのストレージとプロビジョンドの25WCU／25RCUが月ごとの無料枠として案内されています。ただしAWSの無料利用枠は2025年7月に仕組みが改定され、新規アカウントは6か月・最大200ドルのクレジットを使う無料プランと有料プランから選ぶ形になりました。どこまでが無料かはAWSを無料で使える範囲と6か月の期限で確認できます。課金を一切出さずに試すだけならDynamoDB Localが確実です。

DynamoDBでSQLは使えますか？

PartiQL（SQL互換のクエリ言語）でSELECT・INSERT・UPDATE・DELETEをSQLに近い構文で書けます。ただし内部の実体はキー検索のままで、パーティションキーを指定しないSELECTはScan相当になり遅く高コストです。SQL構文が使えても、RDBの自由な結合・集計が手に入るわけではありません。

DynamoDBのソートキーとは何ですか？

同じパーティションキーを持つアイテムの中で、並び順と範囲検索を担う任意のキーです。パーティションキーだけなら1件を一意に引く用途に限られますが、ソートキーを足すと「あるユーザーの注文を日付範囲で取得」のような範囲クエリ（begins_withや比較演算）が可能になります。1対多の関係を1テーブルで表現する要になります。値の長さは1024バイトまでです。

DynamoDBで集計はできますか？

サーバー側のSUM／COUNT／GROUP BYはありません。リアルタイムの累計はDynamoDB Streams＋Lambdaで集計値を別アイテムに逐次更新し、バッチ分析はS3エクスポート＋Athena、本格的な分析はOpenSearchやRedshiftへのZero-ETL連携で行うのが定石です。テーブル内で集計を完結させようとしないのがコスト面でも安全です。

関連記事

• データベースとは？種類・DBMS・RDBとNoSQLの選び方を実装目線で解説
• RDS Proxyとは？対応エンジン・料金・接続プールの仕組みと導入手順を解説
• MongoDBとは？ドキュメント指向データベースの構造・ドキュメント・使い方入門
• Serverless Frameworkとは？v4の料金・使い方・無料の代替まで【2026年最新】