Amazon DynamoDBとは？現役AWSエンジニアが特徴・料金・テーブル設計をわかりやすく解説
「アクセスが急に増えてもDBが落ちないようにしたい。でも、そのためにサーバーの増強やチューニングに時間はかけたくない…」
Webサービスやアプリを運用していると、多くの方がこの悩みにたどり着きます。
ユーザー数が読めないサービスほど、データベースの容量設計は難しくなります。
用意しすぎれば無駄なコストがかかり、足りなければアクセス集中で止まってしまう…
そんな課題を解決する手段として、AWSのAmazon DynamoDB（アマゾン ダイナモDB）があります。
DynamoDBは、サーバーの管理をAWSに任せたまま、必要な分だけ自動でスケールするデータベースサービスとして、多くのサービスの裏側で使われています。
この記事では、DynamoDBとは何か、どんな特徴があり、RDSとどう使い分けるのか、料金はどう決まるのか、そして最大のつまずきポイントであるテーブル設計をどう考えればいいのかまでを、AWS認定資格を多数保有する現役AWSエンジニアによる実務目線で解説します。
「名前は聞くけれど、いつ使うサービスなのかピンとこない」という方が、自分のシステムに使うべきかどうかを判断できる状態を目指した内容です。
監修：KANADE
■保有資格
AWS Certified Cloud Practitioner / AWS Certified AI Practitioner / AWS Certified Solutions Architect - Associate / AWS Certified Developer - Associate / AWS Certified Machine Learning Engineer - Associate / AWS Certified SysOps Administrator - Associate / AWS Certified Data Engineer - Associate / AWS Certified DevOps Engineer - Professional / AWS Certified Solutions Architect - Professional / AWS Certified Security - Specialty / AWS Certified Database - Specialty / AWS Certified Data Analytics - Specialty / AWS Certified Machine Learning - Specialty / AWS Certified SAP on AWS - Specialty / AWS Certified Advanced Networking - Specialty / AWS Authorized Instructors食品業界からIT業界未経験でALHへ入社。AWS環境上で稼働するシステムインフラの設計から運用保守を担当。
運営元：ALH株式会社
ALH株式会社は、AWSパートナーネットワーク（APN）において、以下の認定を取得しているAWSパートナー企業です。◆ AWS 1000 APN Certification Distinction
AWS認定資格の取得数が1,000件を超えたパートナーに与えられる認定◆ AWS Training Partner
AWS公認の研修トレーニングを提供できるパートナー認定
◆ AWS Select Tier Services Partner
AWSサービスの構築・運用において一定の実績を持つパートナー認定
1. Amazon DynamoDBとは
Amazon DynamoDBは、AWSが提供するフルマネージドのサーバーレスNoSQLデータベースサービスです。サーバーの構築・運用をAWSがすべて引き受け、利用者はデータの読み書きだけに集中できます。
一番の特徴は、規模が変わっても性能が落ちないこと。データ量が数KBでも数百TBでも、リクエストへの応答は一桁ミリ秒（数ミリ秒）の速さを保ちます。この安定した高速性と、アクセス量に応じた自動スケールが評価され、ゲーム・広告・IoT・ECのカート機能など、大量のアクセスをさばくサービスの基盤として広く採用されています。
1-1. DynamoDBの特徴（フルマネージド・サーバーレス）
DynamoDBの特徴は、次の4つです。
| 特徴 | 内容 |
|---|---|
| フルマネージド | サーバーの構築・パッチ適用・バックアップ・故障対応をAWSが担う。利用者はインフラ管理が不要 |
| サーバーレス | 起動しておくサーバーがなく、リクエストが来たときだけ課金される。アクセスゼロならキャパシティ料金もゼロにできる |
| 自動スケール | アクセス量に応じて処理能力とストレージが自動で拡張・縮小する。事前のサイジングに悩まなくて済む |
| 高可用性 | データは自動的に複数のアベイラビリティゾーン（AZ）に複製され、一部の障害でもサービスが止まりにくい |
とくに実務でありがたいのが「フルマネージド」の部分です。従来のデータベースでは、OSのパッチ当て、バックアップの取得、ディスク容量の監視といった運用作業に多くの時間が取られていました。DynamoDBはこれらをAWS側が引き受けるため、エンジニアがアプリの開発そのものに集中できるようになります。
保管されるデータはデフォルトですべて暗号化されます。デフォルトの「AWS所有キー（AWS owned key）」であれば追加料金はかかりません（AWS公式のDynamoDB機能ページ）。セキュリティ設定を何もしなくても、暗号化された状態で保存される点は安心材料です。
1-2. そもそもNoSQLとは？RDBとの違い
DynamoDBを理解するうえで避けて通れないのが「NoSQL」という言葉です。結論から言うと、NoSQL（ノーエスキューエル）とは、行と列の表形式にとらわれない、柔軟なデータの持ち方をするデータベースの総称です。「Not only SQL」の略とされ、従来のリレーショナルデータベース（RDB）とは設計思想が異なります。
RDBとNoSQL（DynamoDB）の違いを整理すると次のとおりです。
| 観点 | リレーショナルDB（RDB） | DynamoDB（NoSQL） |
|---|---|---|
| データの形 | 行と列の「表」。事前にスキーマ（列定義）を固める | 「項目（アイテム）」の集まり。項目ごとに持つ属性が違ってよい |
| 得意な処理 | 複雑な条件での検索・テーブル結合（JOIN） | 決まったキーでの高速な読み書き |
| スケールの仕方 | 基本は1台を強くする（スケールアップ） | 複数に分散して増やす（スケールアウト） |
| 代表例 | Amazon RDS、Aurora、MySQL、PostgreSQL | DynamoDB、Cassandra、MongoDB |
DynamoDBは、データを「キー（鍵）」と「値」のペアで管理するのが基本です。たとえば「ユーザーID＝123のユーザー情報」のように、キーを指定して一発で目的のデータを取り出すのが得意です。逆に「30歳以上で東京在住のユーザーを名前順で」といった複雑な絞り込みや、複数テーブルをまたいだJOINは苦手としています。
この「得意・不得意」が、次の章で解説するRDSとの使い分けに直結します。
2. DynamoDBとRDS・Auroraはどう使い分ける？
結論を先に言うと、「決まったキーで大量に高速アクセスするならDynamoDB」「複雑な検索や集計、データ間の関係性が重要ならRDS・Aurora」という切り分けが基本です。どちらが優れているという話ではなく、データの使い方に合うほうを選びます。
AWSのデータベースには複数の選択肢があり、DynamoDBとRDS/Auroraはその代表格です。同じ「データを保存する」役割でも、向いている場面がはっきり分かれます。
2-1. DynamoDBが向いているケース
次のような要件があるなら、DynamoDBが有力な選択肢になります。
- アクセス量の変動が激しい／予測しづらい（キャンペーンやバズで急増するWebサービス、ゲームのイベントなど）
- 大量のデータを、決まったキーで高速に読み書きしたい（ユーザーのセッション情報、カート、IoTデバイスのログなど）
- ミリ秒単位の低レイテンシを常に維持したい
- サーバー運用の手間を極力なくしたい
たとえば、ECサイトの「買い物カゴ」は、ユーザーIDをキーにその人のカート情報を出し入れするだけのシンプルな処理です。こうした用途はDynamoDBの独壇場です。
2-2. DynamoDBが向かないケース（RDS・Auroraを選ぶべき場面）
一方で、次のような要件では無理にDynamoDBを使わず、RDSやAuroraを選ぶほうが素直です。
- 複雑な条件での検索や集計が中心（管理画面での多条件検索、月次レポートの集計など）
- テーブル同士を結合（JOIN）して扱う関係データが多い（受注・顧客・商品を突き合わせる基幹系など）
- 後から検索軸が増える可能性が高く、事前にアクセスパターンを固めきれない
DynamoDBは「あらかじめ決めたアクセスパターンに最適化する」データベースです。そのため、「どう検索するか」が固まっていない段階のシステムには不向きです。この点は5章のテーブル設計とも深く関わってきます。
| 使い分けの目安 | 選ぶサービス |
|---|---|
| キー指定の高速な読み書き・急なスケールが必要 | DynamoDB |
| 複雑な検索・集計・JOINが中心、SQLで柔軟に扱いたい | Amazon RDS / Aurora |
| まずは慣れたRDBで始め、要件が固まっていない | Amazon RDS / Aurora |
迷ったら「このデータをどう取り出すかが、すでに明確に決まっているか？」と考えてみてください。明確ならDynamoDB、まだ変わりそうならRDSが無難です。
▼Amazon RDSについてはこちら
3. DynamoDBの主要機能
DynamoDBは単なる保存箱ではなく、運用を助ける機能が一通りそろっています。ここでは実務でよく使う代表的な機能を紹介します。すべてを最初から使う必要はありませんが、「こういうことができる」と知っておくと設計の幅が広がります。
3-1. キャパシティモード（オンデマンド／プロビジョンド）
DynamoDBには、処理能力（キャパシティ）の決め方が2種類あります。この選択が料金にも直結するため、最初に理解しておきたいポイントです。
| モード | 仕組み | 向いているケース |
|---|---|---|
| オンデマンド | 事前設定なし。実際のリクエスト量に応じて自動で処理し、使った分だけ課金 | アクセスが読めない／変動が激しい、開発初期、ゼロまでスケールしたい |
| プロビジョンド | 1秒あたりの読み書き能力を事前に指定する。Auto Scalingで上下も可能 | アクセス量が安定して予測できる、コストを最適化したい |
迷ったら、まずはオンデマンドから始めるのがおすすめです。設定不要で、アクセスがなければキャパシティ料金がかからず、後からプロビジョンドへ切り替えることもできます（オンデマンドからプロビジョンドへの変更は回数制限なくいつでも可能です）。トラフィックの傾向が見えてきたら、コスト最適化のためにプロビジョンドを検討する、という流れが実務的です。
ただし、AWS無料利用枠の25 WCU・25 RCUはプロビジョンドモード専用です。読み書きも含めて無料枠内で学習したい場合は、あえてプロビジョンドモードを選ぶという判断もあります（詳しくは第4章）。
3-2. DynamoDB Streams（変更履歴の記録）
DynamoDB Streamsは、テーブルの項目に対する変更（追加・更新・削除）を時系列でほぼリアルタイムに記録する機能です。記録された変更履歴は24時間保存されます（AWS公式のDynamoDB機能ページ）。
この履歴をトリガーにしてAWS Lambdaを起動すれば、「データが更新されたら通知を送る」「別テーブルに集計値を書き込む」といった処理を自動化できます。DynamoDBとLambdaを組み合わせたイベント駆動アーキテクチャの中核を担う機能です。
▼Amazon Lambdaについてはこちら
3-3. TTL（データの自動削除）
TTL（Time to Live）は、項目ごとに有効期限を設定し、期限が過ぎたデータをDynamoDBが自動で削除してくれる機能です。
セッション情報や一時的なキャッシュ、一定期間だけ保持すればよいログなど、「古くなったら消したいデータ」に有効です。しかもTTLによる削除には追加料金がかからないため、不要データを溜め込まずストレージコストを抑える手段としても使えます。
3-4. グローバルテーブル（マルチリージョン対応）
グローバルテーブルは、複数のAWSリージョンにまたがってデータを自動複製し、どのリージョンからでも読み書きできるようにする機能です。AWS公式は、この構成で99.999%の可用性を実現するとしています（AWS公式のDynamoDB機能ページ）。
世界各地にユーザーがいるサービスで、それぞれの地域の近くから低レイテンシでアクセスさせたい場合や、あるリージョンで障害が起きても別リージョンでサービスを継続したい場合に使います。グローバル展開するアプリの災害対策（DR）としても選ばれます。
3-5. DAX（インメモリキャッシュ）
DAX（DynamoDB Accelerator）は、DynamoDBの前段に置くフルマネージドのインメモリキャッシュです。読み込みが集中するデータをメモリ上にキャッシュすることで、応答速度をミリ秒からマイクロ秒へと引き上げられます。
「同じデータへの読み込みが極端に多い」「さらに速い応答が必要」というケースで、アプリのコードをほとんど変えずに高速化できるのが利点です。ただし追加のコストがかかるため、まずは通常のDynamoDBで様子を見て、必要になったら導入するのが現実的です。
3-6. バックアップ（PITR）と暗号化
DynamoDBには、データ保護のための機能も備わっています。
- ポイントインタイムリカバリ（PITR）：過去35日間の任意の時点にデータを復元できる機能。オペレーションミスでデータを消してしまったときの保険になります（AWS公式のDynamoDB機能ページ）。
- オンデマンドバックアップ：任意のタイミングでテーブルの完全なバックアップを取得できます。規制対応で長期保管が必要な場合に使います。
- 暗号化：保管データはデフォルトで暗号化されます。デフォルトの「AWS所有キー（AWS owned key）」であれば追加料金はかかりませんが、より厳密な鍵管理のためにKMSのキー（AWSマネージドキー／カスタマーマネージドキー）を選ぶ場合は、KMS側のAPIリクエスト料金などが発生します。
▼暗号化の鍵管理を担うIAMやアクセス制御の考え方はこちら
4. DynamoDBの料金
DynamoDBの料金は、大きく分けて「キャパシティ（読み書きの処理量）」「データストレージ」「オプション機能」の3つで決まります。サーバーを立てっぱなしにする料金がない代わりに、「どれだけ読み書きしたか」「どれだけデータを保存しているか」で課金される従量制が基本です。
なお、以下で紹介する具体的な単価は、アジアパシフィック（東京）リージョン（ap-northeast-1）・オンデマンドモードの2026年7月時点の値です。リージョンや利用機能によって単価は変わるため、実際の見積もりはAWS公式のDynamoDB料金ページやAWS Pricing Calculatorで確認してください。
また、オンデマンド料金は2024年11月に大幅な値下げが行われています。他サイトの解説記事を参照する際は、引用されている単価が値下げ前の古い情報でないか、時点にご注意ください。
4-1. 課金される3つの要素
| 課金要素 | 内容 | 東京リージョンの単価（2026年7月時点） |
|---|---|---|
| 書き込みキャパシティ | データを書き込んだ量。オンデマンドでは「書き込みリクエストユニット（WRU）」で計算。1KBあたり1WRU | 100万WRUあたり0.715USD |
| 読み込みキャパシティ | データを読み込んだ量。「読み込みリクエストユニット（RRU）」で計算。4KBあたり0.5〜2RRU（一貫性レベルで変動） | 100万RRUあたり0.1425USD |
| データストレージ | 保存しているデータ量 | 0.285USD／GB・月（最初の25GBは無料枠） |
上記の単価はいずれもAWS公式のオンデマンド料金ページに記載の東京リージョンの値です。このほか、Streamsの読み込みやグローバルテーブルの複製など、使った機能に応じたオプション料金が加算されます。
4-2. オンデマンドとプロビジョンドのコスト感
同じデータ量でも、選ぶキャパシティモードでコストの出方が変わります。
- オンデマンド：アクセスがあった分だけ課金。トラフィックが少ない時間帯やアクセスゼロの時間はキャパシティ料金がかからない。読めない・変動が大きいワークロードで無駄が出にくい。
- プロビジョンド：あらかじめ処理能力を確保しておく方式。アクセスが安定していれば、オンデマンドより単価を抑えられることが多い。
ざっくりした指針としては、「常にある程度のアクセスが安定してある」ならプロビジョンド、「読めない・波が大きい」ならオンデマンドが合います。判断がつかないうちはオンデマンドで運用し、実測値を見てからプロビジョンドへの切り替えを検討すると、過剰な確保による無駄を避けられます。
4-3. 無料枠と、コストを抑えるコツ
DynamoDBにはAWS無料利用枠がありますが、内容がキャパシティモードによって異なる点に注意が必要です。
まず、モードを問わず適用される無料枠は次の2つです。
- データストレージ：25GB（Standardテーブルクラスの場合。超過分は0.285 USD/GB・東京）
- DynamoDB Streamsの読み込みリクエスト：250万件/月
一方、次の2つはプロビジョンドモード限定で適用されます。
- 書き込みキャパシティユニット（WCU）：25
- 読み込みキャパシティユニット（RCU）：25
つまり、オンデマンドモードのテーブルは最初のリクエストから読み書きの料金が発生します。「無料枠の範囲で読み書きを試したい」場合は、プロビジョンドモードで25 WCU・25 RCU以内に収める必要があります。このキャパシティ無料枠はアカウント・リージョン単位で全テーブルの合算になるため、テーブルを複数作ると超過しやすい点にも注意してください。
なお、オンデマンドモードでも小規模な検証であれば読み書きの料金はごく少額に収まるため、無料枠にこだわらずまずオンデマンドで動かしてみる、という判断も現実的です（無料枠の内容は改定されることがあるため、利用前にAWS公式の料金ページで最新条件を確認してください）。
コストを抑えるための実務的なコツは次のとおりです。
- Scan（全件走査）を避ける：後述するとおり、テーブル全体を読むScanは読み込みコストを一気に押し上げます。キーを指定するQueryを基本にします。
- TTLで不要データを自動削除する：古いデータを消し、ストレージ料金を抑えます。
- アクセスが少なくデータ量が多いテーブルはStandard-IAテーブルクラスへ：Standard-IA（Infrequent Access）テーブルクラスに変更すると、ストレージ料金が60%下がります（0.285 USD/GB → 0.114 USD/GB・東京）。ただし読み書きのスループット料金は約25%上がるため、ストレージがそのテーブルの総コスト（ストレージ＋スループット）の50%を超えている場合に限って有効です。ログや過去の注文履歴のように「量は多いがほとんど読まない」データが対象で、アクセス頻度の高いテーブルに適用すると逆にコストが増えます。標準はStandardテーブルクラスのままで問題ありません（AWS公式のDynamoDB機能ページ）。
- アクセスが安定したらプロビジョンドへ：実測に基づいてキャパシティを確保し、単価を下げます。
- 使用量が安定したらリザーブドキャパシティを検討する：100キャパシティユニット単位で購入し、1年契約で最大54%、3年契約で最大77%の割引を受けられます。プロビジョンドモード限定の仕組みなので、長期運用が見えている本番テーブルでは検討する価値があります。
5. DynamoDBのテーブル設計【最重要】
ここがDynamoDBで最もつまずきやすく、そして最も差がつくポイントです。結論を先に言うと、DynamoDBの設計は「どんなデータを持つか」ではなく「どうデータを取り出すか（アクセスパターン）」から考えるのが鉄則です。RDBに慣れた人ほど、この発想の転換でつまずきます。
RDBでは、まずデータを正規化してテーブルを分け、後からSQLで自由に検索するのが定石でした。DynamoDBはこの順序が逆になります。先に「どう検索したいか」を洗い出し、それを高速に実現できるようキーを決めるのです。
5-1. パーティションキーとソートキー
DynamoDBのテーブルは、各データを「項目（アイテム）」として持ちます。そして、どの項目かを特定する鍵がプライマリキーです。プライマリキーには2つの形式があります。
| キー構成 | 内容 |
|---|---|
| パーティションキーのみ | 1つの属性で項目を一意に特定する（例：ユーザーID） |
| パーティションキー＋ソートキー | 2つの組み合わせで特定する。同じパーティションキー内でソートキー順に並ぶ（例：ユーザーID＋投稿日時） |
- パーティションキー（Partition Key）：データを内部的にどのサーバー（パーティション）へ分散配置するかを決める鍵です。値がまんべんなくばらけるほど、負荷が分散して性能が安定します。
- ソートキー（Sort Key）：同じパーティションキーを持つ項目を並べ替える鍵です。「あるユーザーの投稿を新しい順に取得」のように、範囲指定や並び替えができるようになります。
たとえば「ユーザーごとの注文履歴」なら、パーティションキーに`ユーザーID`、ソートキーに`注文日時`を置くと、「特定ユーザーの注文を日時順に取得」が高速に行えます。キー設計は、この「取り出し方」から逆算して決めるのがポイントです。
5-2. アクセスパターンから設計する
DynamoDB設計の核心は、先にアプリケーションが必要とする「取り出し方（アクセスパターン）」をすべて書き出すことです。
たとえばブログシステムなら、次のようなアクセスパターンが想定されます。
- 記事IDを指定して1件の記事を取得する
- 特定ユーザーが書いた記事を新しい順に一覧する
- あるカテゴリの記事を一覧する
これらを先に洗い出したうえで、「1と2はこのキー構成で取れる」「3はこの後説明するGSIで対応する」と、キーとインデックスを設計していきます。RDBのように「とりあえず正規化して保存し、検索は後で考える」では、DynamoDBの性能を活かせません。むしろ後から「その取り出し方はできない」と詰まってしまいます。
このため、要件がまだ固まっていない・検索軸が今後増えそうなシステムは、DynamoDBに不向きだと2章で述べたわけです。
5-3. セカンダリインデックス（GSI／LSI）
プライマリキー以外の条件でも検索したい場合に使うのがセカンダリインデックスです。「別の切り口でも取り出せる索引を追加する」機能だと考えてください。2種類あります。
| 種類 | 特徴 | 数の上限 |
|---|---|---|
| GSI（グローバルセカンダリインデックス） | パーティションキーもソートキーも別の属性で新しく設定できる。柔軟性が高い | 1テーブルあたり20個（デフォルト） |
| LSI（ローカルセカンダリインデックス） | パーティションキーは同じまま、ソートキーだけ別の属性にできる。テーブル作成時のみ追加可能。同一パーティションキーのデータ量が10GBを超えられない制約があり、データが増え続けるテーブルではGSIのほうが安全 | 1テーブルあたり5個 |
GSI・LSIの上限はAWS公式のサービスクォータのドキュメントに基づく値です。実務では、5-2で洗い出したアクセスパターンのうち「プライマリキーだけでは取れないもの」をGSIでカバーする、という使い方が中心になります。
5-4. やりがちな設計アンチパターン
現場でよく見かける失敗を挙げておきます。設計時の注意点として押さえてください。
- RDBの感覚でテーブルを細かく分けてしまう：DynamoDBはJOINが苦手です。関連データを別テーブルに分けすぎると、何度も読み込みが発生してコストと複雑さが増します。関連するデータをまとめて持つ設計（シングルテーブル設計）が検討される理由がここにあります。
- パーティションキーの値が偏る：特定の値にアクセスが集中すると、その裏側のパーティションだけ負荷が高まり性能が落ちます（後述のホットパーティション）。値がばらける属性を選ぶことが重要です。
- アクセスパターンを洗い出さずに作り始める：最大の失敗です。後から「その検索はできない」と判明し、テーブルの作り直しになりがちです。
6. DynamoDBの使い方（はじめの一歩）
ここからは、実際にDynamoDBを触るときの流れを紹介します。難しい準備は不要で、AWSマネジメントコンソールから数分でテーブルを作れます。
6-1. Step1｜テーブルを作成する
AWSマネジメントコンソールでDynamoDBのページを開き、「テーブルの作成」を選びます。入力するのは基本的に次の3つだけです。
- テーブル名（例：`Users`）
- パーティションキー（例：`userId`）
- 必要ならソートキー（例：`createdAt`）
キャパシティモードは、まず動かしてみる段階であればデフォルトのオンデマンドのままで問題ありません（無料枠内で読み書きを試したい場合はプロビジョンドを選び、25 WCU・25 RCU以内に設定してください）。あとは作成ボタンを押すだけで、数十秒でテーブルが使える状態になります。サーバーの準備やインストール作業は一切ありません。
6-2. Step2｜データを読み書きする（Query・Scan・PartiQL）
テーブルができたら、データの読み書きを行います。読み込みには主に2つの方法があり、この使い分けがコストと性能を大きく左右します。
| 操作 | 内容 | 使いどころ |
|---|---|---|
| Query（クエリ） | パーティションキーを指定して、該当する項目だけを効率よく取得する | 基本はこちら。高速かつ低コスト |
| Scan（スキャン） | テーブル全体を先頭から走査して読む | どうしても全件見るとき限定。遅く高コスト |
原則としてQueryを使い、Scanは避けるのが鉄則です。Scanはテーブル全体を読むため、データが増えるほど遅く・高額になります。
なお、SQLに慣れている方向けに、PartiQLというSQLに似た構文でDynamoDBを操作する方法も用意されています。`SELECT * FROM Users WHERE userId = '123'`のような書き方ができるため、SQL経験者は学習コストを下げられます。ただし、内部的にScanが走る書き方をすると結局コストがかかる点は同じなので、キーを意識して使う必要があります。
6-3. Step3｜ローカル環境で開発する（DynamoDB Local）
開発中に毎回AWS上のDynamoDBへアクセスすると、通信の手間や料金が気になります。そこで役立つのがDynamoDB Localです。自分のPC上でDynamoDBと同じように動く環境を無料で立てられるため、オフラインで開発・テストを進められます。Dockerを使って手軽に起動でき、アプリの動作確認を高速に回せます。
プログラムからDynamoDBを操作する際は、PythonならAWSのSDKであるboto3などの各言語向けSDKを使うのが一般的です。まずはローカルで動作を固め、そのままAWS上のDynamoDBへ向き先を変える、という進め方が安全です。
7. DynamoDBを使ううえでの注意点
便利なDynamoDBですが、RDBと同じ感覚で使うと思わぬコストや性能問題に直面します。事前に知っておきたい代表的な落とし穴を3つ挙げます。
7-1. Scanの多用はコストと性能の敵
繰り返しになりますが、Scan（全件走査）の多用は避けるべきです。Scanはテーブル全体を読み込むため、データ量が増えるほど読み込みコストが膨らみ、処理も遅くなります。
「一覧を出したい」という理由で安易にScanを使うと、データが増えた本番環境で急にコストが跳ね上がる、という事故につながります。一覧取得が必要なら、Queryで取れるようキー設計やGSIで対応するのが正攻法です。
7-2. ホットパーティションに注意
ホットパーティションとは、特定のパーティションキーにアクセスが集中し、その裏側のサーバーだけ負荷が偏る状態です。たとえばパーティションキーに「今日の日付」を使うと、その日のアクセスが1か所に集中してしまいます。
対策は、5章で触れたとおり値がまんべんなくばらけるパーティションキーを選ぶこと。ユーザーIDや注文IDなど、分散しやすい属性を鍵に選ぶのが基本です。
なお、1つのパーティションが処理できるスループットは3,000 RCU／1,000 WCUが上限です。単一の項目へのアクセスもこの上限の範囲に収まるため、極端にアクセスが集中するデータを1項目や1パーティションに集約する設計は避けてください。
7-3. 1項目あたりのサイズ上限
DynamoDBでは、1つの項目（アイテム）に保存できるデータサイズは最大400KBです。画像や動画そのものといった大きなデータは、DynamoDBに直接入れず、Amazon S3に本体を置き、DynamoDBにはそのS3の場所（URLやキー）だけを保存するのが定石です。DynamoDBは「小さなデータを大量に、速く」扱うのが得意なサービスだと意識すると、設計を誤りにくくなります。
▼Amazon S3についてはこちら
8. よくある質問（FAQ）
Q1. DynamoDBは無料で使えますか？
A. AWS無料利用枠がありますが、内容はキャパシティモードによって異なります。データストレージ25GB（Standardテーブルクラス）とDynamoDB Streamsの読み込み250万件/月はモードを問わず適用されます。一方、書き込み・読み込みキャパシティユニット各25の無料枠はプロビジョンドモード専用で、オンデマンドモードのテーブルは最初のリクエストから課金されます。読み書きも含めて完全に無料枠で試したい場合は、プロビジョンドモードを選んでください（最新の無料枠はAWS公式の料金ページで確認できます）。
Q2. DynamoDBとRDS（リレーショナルDB）はどちらを使うべきですか？
A. 決まったキーで大量に高速アクセスするならDynamoDB、複雑な検索・集計やテーブル結合（JOIN）が中心ならRDSやAuroraが向いています。「データの取り出し方がもう明確に決まっているか」を判断の目安にしてください。
Q3. DynamoDBはSQLで操作できますか？
A. PartiQLというSQLに似た構文が用意されており、SQLに近い書き方で操作できます。ただしDynamoDBの得意・不得意はRDBと異なるため、キーを意識した書き方をしないと性能やコストのメリットを活かせません。
Q4. オンデマンドとプロビジョンド、どちらのモードを選べばいいですか？
A. アクセス量が読めない・変動が激しいならオンデマンド、安定して予測できるならプロビジョンドが基本です。判断に迷う場合は、設定不要でゼロまでスケールするオンデマンドで始め、実測が取れてからプロビジョンドを検討するとよいでしょう。
Q5. テーブル設計で最初に気をつけることは何ですか？
A. 「どうデータを取り出すか（アクセスパターン）」を先にすべて洗い出すことです。DynamoDBは、そのアクセスパターンに合わせてパーティションキー・ソートキー・セカンダリインデックスを設計します。RDBのように「とりあえず保存して検索は後で」という進め方は避けてください。
まとめ：DynamoDBは「決まった使い方を、速く・大量に」さばくデータベース
「アクセスが読めないサービスのDBを、運用の手間をかけずにスケールさせたい」時に、DynamoDBは有効です！
最後に、この記事の要点を振り返ってみましょう。
| 項目 | ポイント |
|---|---|
| DynamoDBとは | AWSのフルマネージド・サーバーレスNoSQL。一桁ミリ秒の応答と自動スケールが強み |
| RDSとの使い分け | キー指定の高速アクセスならDynamoDB、複雑な検索・JOINならRDS・Aurora |
| 主要機能 | オンデマンド／プロビジョンド、Streams、TTL、グローバルテーブル、DAX、PITR |
| 料金 | キャパシティ・ストレージ・オプションの従量制。無料枠あり。Scan多用に注意 |
| テーブル設計 | 「どう取り出すか」から逆算。アクセスパターンを先に洗い出すのが鉄則 |
| 注意点 | Scanの多用・ホットパーティション・項目サイズ上限に気をつける |
DynamoDBは、RDBと同じ感覚で使うと戸惑うサービスです。しかし「決まった使い方を、速く・大量にさばく」という土俵で圧倒的な強さを発揮します。まずは無料枠でテーブルを1つ作り、Queryでデータを取り出すところから触ってみてください。その一歩が、スケーラブルなシステム設計の感覚をつかむ近道になります。
ALH株式会社はAWSパートナーネットワーク（APN）において、AWS 1000 APN Certification Distinction（AWS認定資格の取得数が1,000件を超えたパートナーに与えられる認定）をはじめとする複数の認定を取得しています。AWSの設計・運用に関する知見を、こうした記事を通じて発信しています。
▼AWS資格について
参考リンク
いずれも2026年7月時点の情報です。改定される場合があります。
- Amazon DynamoDBの特徴（AWS公式） … フルマネージド・サーバーレス、パフォーマンス、Streams、TTL、グローバルテーブル、PITR、暗号化などの機能仕様
- Amazon DynamoDBの料金（AWS公式） … キャパシティモード・ストレージ・オプションの料金体系（リージョンごとに単価が異なる）
- Amazon DynamoDBオンデマンドキャパシティモードの料金（AWS公式） … WRU／RRU・ストレージ単価・無料利用枠の記載
- AWS Pricing Calculator（DynamoDB） … 東京リージョンを含む実際の見積もりツール
- Amazon DynamoDBのサービスクォータ（AWS公式ドキュメント） … GSI・LSIの数、スループットなどの上限値
関連記事
この記事を書いた人
