DynamoDBとは｜AWSのNoSQL DBの特徴・RDSとの違い・案件単価

DynamoDBとは｜AWS製のフルマネージドNoSQL

DynamoDBは、Amazon Web Services（AWS）が提供するフルマネージドのNoSQLデータベースサービスです。サーバーやクラスタの構築は不要で、テーブルを作成するだけですぐにデータを読み書きできます。

サーバーレスアーキテクチャを採用しており、データ量やリクエスト数の増減に応じてバックエンドが自動でスケールします。利用者はキャパシティの計画・パッチ適用・バックアップなどの運用作業から解放され、アプリケーション開発に集中しやすくなります。

基本情報

公式の概要はAmazon DynamoDB（AWS公式）で確認できます。一次情報はAmazon DynamoDB Developer Guideが網羅的です。

ミニFAQ：DynamoDBはRDBMSの代替になる？

一部の用途では代替候補になります。ただしアクセスパターンが固定的でスケール要件が大きい場合に限るのが現実です。複雑な検索や集計が中心の業務システムでは、無理に置き換えずAWS RDSやAuroraと使い分けた方が運用は楽です。NoSQLとRDBMSは「代替」というより適材適所の関係で扱う方が安全です。

DynamoDBの主な特徴

サーバーレス設計と水平スケールが核です。これらが、ゲーム・IoT・SaaSのバックエンドで採用される理由になっています。

サーバーレスでフルマネージド

サーバーやクラスタの構築は不要です。テーブル作成後すぐに利用を開始できますが、本番投入前にはIAM・監視・バックアップ設定の確認が必要です。OS・ミドルウェアのパッチ、レプリケーションの設計、フェイルオーバなどの作業は多くがAWS側に任せられますが、監視・復元方針・コスト管理は利用者側の設計が必要です。

ミリ秒台の応答とほぼ無制限の水平スケール

適切にキー設計されたワークロードでは、規模が大きくなっても応答時間は数ミリ秒台の低レイテンシを維持しやすい設計です。AWSは内部でデータを自動的にパーティショニングし、トラフィックの増加に追随します。1秒あたり数万〜数十万リクエスト級のワークロードも処理できる構成が可能です。

キーバリューとドキュメントの両モデル

キー（プライマリキー）に紐づく値を入れるキーバリュー型に加え、JSONライクなドキュメント型もサポートします。柔軟なスキーマで保存できるので、ユーザー設定・セッション・イベントログのように構造が変わりやすいデータと相性が良い面があります。

グローバルテーブルとマルチAZ可用性

複数AZへの自動レプリケーションでデータの耐久性は高めです。さらにグローバルテーブルを使えば、複数リージョン間で双方向レプリケーションを構成できます。グローバル展開のSaaSでは選択肢の一つになります。

セキュリティ・暗号化

保管時暗号化はデフォルトで有効、通信もTLSで保護されます。IAMで細かいアクセス制御ができ、特定属性のみ参照可能といった条件付きポリシーも組めます。

ミニFAQ：DynamoDBはJOINできない？

公式にはJOIN相当の演算子は用意されていません。設計段階でアクセスパターンを洗い出し、必要に応じてセカンダリインデックス（GSI／LSI）や非正規化で対応するのが基本です。

DynamoDBとRDS／Aurora／MongoDBの違い

ここが多くのエンジニアが迷うところです。「とりあえずDynamoDB」と「とりあえずRDS」のどちらも危ないので、用途別に整理します。

DynamoDBとRDS／Auroraの違い

会員情報・受発注・会計のように複雑なクエリやJOIN、柔軟な集計が必要なシステムは、MySQLやPostgreSQLベースのRDS／Auroraが扱いやすいケースが多い印象です。なお、DynamoDBも強整合読み取りやトランザクションを一部サポートしているため、違いは「整合性の有無」より「クエリ自由度・設計前提・コスト特性」にあります。逆に、ソーシャル投稿・ゲームのスコア・IoTテレメトリのような書き込み量が読みにくくスケール優先の領域はDynamoDBの出番になりやすいです。

DynamoDBとMongoDBの違い

ドキュメント指向という意味ではMongoDBに近い側面もあります。違いは運用モデルにあります。

AWSネイティブな統合と運用簡素化を重視するならDynamoDB、より柔軟なドキュメントクエリやクラウド選択肢を重視するならMongoDB系、という選び方になります（MongoDB Atlasを使えばマネージドで運用負荷を下げられる点も含めて検討します）。

ミニFAQ：迷ったらどちらを選ぶ？

「業務系か否か」で切ると判断が早いです。会計・在庫・受発注のような正確性が問われる業務系はRDS／Auroraから検討。リアルタイム性・スケール・固定アクセスパターンが軸ならDynamoDBが選択肢に入ります。

DynamoDBのデータモデルと設計の勘所

DynamoDBは「使うのは簡単、設計は難しい」と言われます。最初にアクセスパターンを設計し切ることが性能とコストの両方を決めます。

プライマリキーの種類

• パーティションキーのみ：1つのキーでアイテムを一意に特定する最小構成

• 複合キー（パーティションキー＋ソートキー）：同じパーティションキーの中でソート可能。範囲検索もできる

パーティションキーの選び方は重要です。偏った値（ホットパーティション）が発生するとスループットが詰まり、結果として遅延やスロットリングの原因になります。

セカンダリインデックス

• GSI（グローバルセカンダリインデックス）：別のパーティションキーで横断的に検索したいときに使う

• LSI（ローカルセカンダリインデックス）：同じパーティションキーの中で別のソートキーが必要なときに使う

GSIは追加コストが発生します。必要なクエリだけに絞って作成するのが運用ベースのコスト管理として現実的です。

設計の流れ

1. アプリのアクセスパターンを一覧化する

2. 各パターンに必要なキー・インデックスを設計する

3. 1テーブル設計（Single Table Design）か複数テーブルかを判断する

4. キャパシティモードを決める

5. プロトタイプでスループット・遅延を実測する

公式のDynamoDB ベストプラクティスに詳しいガイドがあります。

ミニFAQ：1テーブル設計って何？

DynamoDBで複数のエンティティ（ユーザー・注文・商品など）を1つのテーブルにキー設計で同居させる手法です。クエリ効率は上がる反面、設計の難度は上がります。中規模以上の案件で採用例があります。

DynamoDBの料金体系

料金は大きく分けて2モードです。アクセスパターンの読みやすさで選びます。

オンデマンドモード

リクエスト単位の課金です。事前に容量を見積もる必要はなく、アクセス量に応じて自動でスケールします。スタートアップやアクセスが読みにくいサービス、ピークが鋭いゲーム系に向いています。

2024年11月にAWSはオンデマンドの読み書きスループット料金を半額化しました。プロビジョンドとの差が縮まっており、選択肢として取りやすくなっています。料金は改定されることがあるため、最新価格は必ず公式料金ページで確認してください。

プロビジョンドモード

事前にRCU／WCU（読み書きの性能課金単位）を確保するモードです。安定したトラフィックが見込めるサービスで単価を抑えやすい構成です。長期利用向けの割引オプション（リザーブドキャパシティ等）が使える場合がありますが、適用条件は公式料金ページで確認してください。

料金構成の主な要素

数値は変動するため、設計時には必ずAWS Pricing Calculatorで試算する流れが現実的です。

ミニFAQ：思ったより高くなるのは？

書き込みが多いワークロードでGSIを多数作る／プロビジョンドの容量を過大に取るといった構成だと費用が膨らみます。GSIは必要分に絞り、プロビジョンドはAuto Scalingで上限を抑えるのが基本線です。

DynamoDBが向いているケース・向かないケース

万能なデータベースは存在しません。DynamoDBは強みがはっきりしている分、向かない領域もはっきりしています。

向いているユースケース

• ゲーム（ランキング・スコア・プレイヤーステート）

• IoT・テレメトリ（書き込み中心、時系列データ）

• ECサイトのカート・セッション

• SaaSのユーザープロファイル・通知履歴

• サーバーレスアーキテクチャのバックエンド（Lambda連携）

向かないユースケース

• 複雑なJOIN・集計・OLAP分析（DWH系を検討）

• アドホックな検索（全文検索はOpenSearch等）

• 複雑なトランザクションを高頻度で扱い、かつ柔軟なSQLやJOINも必要な業務システム

• レポート系で柔軟なSQLを多用する基幹業務

特に「業務システムを全部DynamoDBで作ろう」とすると、運用面で苦しくなるケースが目立ちます。複数DBの併用が現実解です。

ミニFAQ：分析用途には使える？

少量のレポート程度なら使えますが、本格的な分析にはAthena・BigQueryなどのDWH／クエリエンジンを併用するのが定石です。ETLでS3に出してからBigQueryやSnowflakeに取り込むパイプラインも一般的です。

フリーランスエンジニアの案件単価と求められるスキル

DynamoDB単独で募集される案件は多くはなく、AWS全般のスキルセットの一部として求められる形が中心です。

単価の目安

2026年6月時点で、主要フリーランスエージェントの公開案件のうち、週5日・業務委託・AWSサーバーレス関連のバックエンド案件を確認した範囲では、AWSサーバーレス構成の経験を含むバックエンドエンジニアで月単価60〜90万円前後、リード級で90〜120万円超のレンジに位置する募集が見られます。後者は、AWS設計・IaC・Lambda連携・要件定義まで担えるリード経験者が中心です。これは公開案件ベースの目安で、業界・期間・契約条件で変動します。

単価レンジの考え方はフリーランスエンジニアの単価相場でも整理しています。

よくある案件タイプ

求められるスキルセット

• DynamoDBのデータモデリング（パーティションキー設計・GSI／LSI）

• AWS基礎（IAM・CloudFormation／CDK・CloudWatch）

• Lambda＋API Gatewayでのサーバーレス開発

• 言語：公開案件ではPython・TypeScript・Goとの組み合わせを比較的よく見かけます

• 設計力：アクセスパターン主導の設計、コスト試算

AWS認定資格（特にDeveloper Associate、Solutions Architect Associate）は実務経験の代替にはなりませんが、案件応募時のスキル説明の補助にはなります。

ミニFAQ：未経験者でも案件は取れる？

DynamoDB単独での未経験OK案件は少ないです。AWSサーバーレスの開発経験が1年程度あれば、要件次第で参画できる募集が見られます。実務経験が浅い段階なら、AWS RDSやクラウドエンジニアの基礎案件から積み上げる方が現実的です。

DynamoDBの学習ロードマップ

「使う」だけなら数時間で動きます。難しいのは設計です。順序立てて学ぶと遠回りを避けやすくなります。

ステップ1：基礎（1〜2週間）

• 公式チュートリアル（テーブル作成・読み書き）

• AWS Management Consoleでの操作

• AWS CLI・SDK（Python boto3、JavaScript SDK）での基本操作

• IAMロール・ポリシーの基本

ステップ2：データモデリング（2〜4週間）

• パーティションキー・ソートキーの設計

• GSI／LSIの使い分け

• 1テーブル設計の基本パターン

• ベストプラクティスの読み込み

ステップ3：サーバーレス統合（2〜4週間）

• Lambdaとの連携

• API Gateway経由のREST／HTTP API

• DynamoDB Streamsによる非同期処理

• IaC（CloudFormation／CDK／Terraform）

ステップ4：本番運用（並行）

• メトリクス（CloudWatch）の理解

• スロットリング対策・キャパシティモード変更

• バックアップ・ポイントインタイムリカバリ

• コスト分析と最適化

ある程度動くようになったら、ポートフォリオ用に小規模なサーバーレスアプリを公開しておくと、案件提案時に話が早くなります。

ミニFAQ：書籍と公式ドキュメント、どちらが先？

設計の勘所を掴むなら公式ドキュメントのベストプラクティスを先に読むのが効率的です。書籍は周辺知識を補完する目的で並行して使うと無駄が出ません。

DynamoDB導入でよくある失敗と対策

実務で繰り返し見られるパターンです。設計段階で対策しておくと、運用フェーズの炎上を回避できます。

失敗1：ホットパーティションの放置

特定のパーティションキーにアクセスが集中し、スロットリングや遅延が発生するパターンです。キー設計時にハッシュ的にばらける値（ユーザーID＋日付など）を組み合わせることで分散を狙えます。ただしキー設計はアクセスパターン依存のため、取得要件を満たす形で設計する必要があります。安易な複合化はクエリ要件を壊す恐れがあります。

失敗2：JOIN前提のデータモデルを持ち込む

RDB感覚で複数テーブルを作りすぎると、アプリケーション側で結合処理が増え、レイテンシもコストも悪化します。アクセスパターンから逆算した1テーブル設計を検討する場面です。

失敗3：GSIの作りすぎ

検索の自由度を上げたくてGSIを増やすと、書き込みコストが膨らみます。実際に使われるパターンに絞ってGSIを設計するのが鉄則です。

失敗4：オンデマンドモードのまま放置でコスト超過

スタートアップ初期はオンデマンドが楽ですが、アクセスが安定してきたらプロビジョンド＋Auto Scalingに切り替えるだけで月額が大きく変わるケースがあります。定期的な見直しが必要です。

失敗5：バックアップ・PITR未設定で本番に出す

ポイントインタイムリカバリ（PITR：任意時点へ復元できるバックアップ機能）はデフォルトでは無効です。本番では有効化を強く検討し、保持要件とコストを踏まえて判断するのが安全側です。

まとめ

DynamoDBは、サーバーレスで運用負荷を最小化したい場面と、固定アクセスパターンで大規模スケールを取りたい場面に強いNoSQLです。RDS／Auroraと役割が分かれるため、どちらか一方ではなく適材適所で使い分けることが現場の正解になりやすいです。

ポイントを整理します。

• DynamoDBはサーバーレスNoSQL、運用負荷が低くスケール耐性が高い

• 業務系・複雑なクエリはRDS／Aurora、固定アクセス・スケール優先はDynamoDB

• 料金はオンデマンドとプロビジョンド。アクセス予測の読みやすさで選ぶ

• 案件はAWSサーバーレス文脈で募集が見られ、月単価60〜120万円超のレンジに位置する募集も

• 設計（パーティションキー・GSI）に学習時間を割くのが近道

DynamoDBを軸にキャリアを考えるなら、AWSサーバーレス・データベースエンジニア・データエンジニアの隣接領域もあわせて棚卸ししておくと、案件選択の幅が広がります。

参照元・一次情報

• Amazon DynamoDB（AWS公式）

• Amazon DynamoDB Developer Guide

• Amazon DynamoDB 料金

• DynamoDB ベストプラクティス