Amazon DocumentDBとは？MongoDB互換マネージドDBの仕組み・料金・採用判断を実装者目線で解説

Amazon DocumentDB（with MongoDB compatibility）は、MongoDBのドライバーやツールと互換のAPIを備えた、AWSのフルマネージド型ドキュメント指向データベースです。JSON形式のドキュメントを格納・クエリ・インデックスでき、サーバーやレプリケーション、バックアップといった運用をAWS側に委ねられる点が持ち味です。この記事では、ドキュメント指向データベースというDocumentDBの位置づけ、コンピュートとストレージを分離したアーキテクチャ、インスタンスベースクラスターとシャーディング対応のElasticクラスターの違い、3つのアベイラビリティゾーンにデータを分散する冗長化、KMS連携の暗号化とポイントインタイムリカバリ、そしてインスタンス・I/O・ストレージ・バックアップで積み上がる料金モデルを一次情報で整理します。DynamoDBやMongoDB Atlas、RDSとの違い、DocumentDBを採用すべき条件と見送るべき場面の判断基準まで、実装者がデータ基盤の選定で迷う論点を具体的に示します。

まとめ：Amazon DocumentDBの仕組み・料金と採用判断の要点

Amazon DocumentDBは、MongoDB互換のAPIを提供するAWSのマネージド型ドキュメントデータベースで、既存のMongoDBアプリケーションをドライバーやツールをほぼ変えずに載せ替えられる点が核になります。アーキテクチャはコンピュートとストレージを分離し、ストレージは10GB単位で自動的に拡張します。データは3つのアベイラビリティゾーンに6方向でレプリケートされ、プライマリ1台に対して最大15台のリードレプリカを追加して読み取りをスケールできる構成です。パッチ適用やバックアップ、フェイルオーバーといった運用がマネージドに含まれるため、MongoDBの運用負荷をAWSへ移したいワークロードに向きます。

料金は、実際の使用量ではなく起動したインスタンスの時間課金を中心に、I/Oリクエスト、ストレージ、バックアップストレージが積み上がる構造です。柔軟なJSONスキーマでドキュメントを扱いたい、かつMongoDBのAPIをそのまま使いたいならDocumentDB、キーバリュー中心でサーバーレス運用に寄せたいならDynamoDB、結合やトランザクション整合性が要るならRDSやAurora、という切り分けが基本の判断軸になります。迷う実装者は、本記事後半の採用条件と見送り条件を自社のワークロードに当てはめてください。

Amazon DocumentDBの仕組みとドキュメント指向データベースのデータモデル

DocumentDBを設計へ落とし込むには、まず「ドキュメント指向データベースがリレーショナルデータベースやキーバリューストアとどう違うのか」を押さえるのが出発点です。ここを曖昧にすると、結合が前提の業務データを無理にドキュメントへ押し込んだり、逆に単純なキー参照で足りる用途に重い構成を選んだりといった設計のずれにつながります。データベースの種類やRDBとNoSQLの選び方から確認したい場合は、データベースの種類・DBMS・RDBとNoSQLの選び方を実装目線で解説した記事が上位の入り口になります。

MongoDB互換のマネージド型ドキュメントデータベースという位置づけ

Amazon DocumentDBは、JSON形式のドキュメントを1件ずつ格納するドキュメント指向データベースです。各ドキュメントは固定スキーマを持たず、レコードごとに異なる属性を許容するため、仕様変更でフィールドが増えても表定義の変更を伴いません。加えて、MongoDBのドライバー・ツールと互換のAPIを備えており、2026年7月時点ではMongoDB 3.6/4.0/5.0系のドライバーとの互換がうたわれています（対応バージョンは公式で時点確認）。既存のMongoDBアプリケーションを、接続文字列の差し替えを中心とした小さな変更で載せ替えられる点が、DocumentDBを選ぶ大きな動機になります。互換元となるMongoDBそのものの構造は、MongoDBのドキュメント指向データベースとしての構造を解説した記事で整理すると、DocumentDBが何を互換対象にしているかが明確になります。

コンピュートとストレージを分離したアーキテクチャと自動スケール

DocumentDBの内部構造で特徴的なのは、コンピュート層とストレージ層を疎結合に分けている点です。クエリを処理するインスタンスと、実際にデータを保持するストレージが独立しており、それぞれを個別にスケールできます。ストレージは10GB単位で必要に応じて自動的に拡張されるため、あらかじめ大きな容量を確保しておく必要がありません。読み取り負荷が増えたときはリードレプリカを追加してコンピュート側を増強し、データ量が増えたときはストレージが自動で伸びる、という分担で拡張します。この分離により、性能とデータ量の増加を別々の軸で扱える設計になっています。

3つのアベイラビリティゾーンに分散する冗長化とリードレプリカ

可用性の面では、ストレージが3つのアベイラビリティゾーン（AZ）にまたがって6方向にレプリケートされます。一部のAZやディスクに障害が起きても、残りのコピーから読み書きを継続できる耐障害性を備えた構成です。クラスターはプライマリインスタンス1台と、最大15台までのリードレプリカで構成でき、リードレプリカは読み取りクエリを引き受けて負荷を分散します。プライマリに障害が起きた場合は、リードレプリカのいずれかが昇格してフェイルオーバーする仕組みで、レプリカラグは通常10ミリ秒未満に収まる水準です。読み取りが多いワークロードでは、レプリカを足すだけで水平にスケールできる点が運用しやすさにつながります。

Amazon DocumentDBのクラスター形態と料金モデルの設計前提

DocumentDBで次に押さえるのが、クラスターの形態選択と料金の積み上がり方です。インスタンスを自分で選ぶ形態と、シャーディングをマネージドに任せる形態があり、規模と運用スタイルによって置き場所が変わります。

インスタンスベースクラスターとElasticクラスター（シャーディング）の選び分け

DocumentDBのクラスターには、大きく2つの形態があります。インスタンスベースクラスターは、VPC内にプライマリとリードレプリカのインスタンスを配置し、インスタンスサイズを自分で選んで性能を決める形態で、ストレージは概ね128TiB前後まで拡張します。もう一方のElasticクラスターは、MongoDB互換のシャーディングAPIをサポートし、データを複数のシャードへ自動的に分散してペタバイト規模（約4PiBまで）へ伸ばせる形態で、インスタンスの管理が不要です。単一の大きなインスタンスで収まる規模ならインスタンスベース、書き込みスループットや容量を水平分割で伸ばしたいならElasticクラスター、という規模と分散要件が選び分けの起点になります。

ポイントインタイムリカバリとKMS暗号化によるバックアップ・保護の前提

バックアップと保護は、マネージドサービスとして標準的な仕組みがそろっています。自動バックアップは1〜35日の範囲で保持期間を設定でき、ポイントインタイムリカバリにより、直近5分前まで、かつ保持期間中の任意の時点へ秒単位で復元できます。ストレージの耐久性は99.999999999%とされ、複数AZへの分散と合わせてデータ損失のリスクを抑える設計です。保存データと転送中のデータは、KMS（Key Management Service）と連携した暗号化で保護でき、VPC内配置やセキュリティグループによるアクセス制御も前提になります。HIPAAやPCI DSS、ISO 27001などのコンプライアンス認証にも対応しており、規制のあるデータを扱う要件にも当てはめやすいサービスです。

インスタンス・I/O・ストレージ・バックアップで積み上がる料金モデル

インスタンスベースクラスターの料金は、大きく4つの要素で積み上がります。中心となるのは起動したインスタンスの時間課金（オンデマンドインスタンス）で、これに読み書きのI/O（100万リクエストあたり約0.24USD）、格納しているストレージ（GB/月あたり約0.12〜0.36USD）、バックアップストレージ（GB/月あたり約0.023USD）が加わる構造です。使用したぶんだけ支払う従量制で、前払いの初期費用はかかりません。ただしI/Oが多いワークロードでは、インスタンス代よりI/O料金が支配的になる場面もあるため、読み書きの回数を見積もって試算します。Elasticクラスターは課金体系が異なるので、規模の大きい構成を検討する際は、下表の目安をもとにAWS公式で対象リージョンと時点を確認してください。

Amazon DocumentDBを採用すべき条件と各データベースとの使い分け

ここでは判断を言い切ります。DocumentDBはMongoDB互換のマネージドDBとして強い反面、新規で単純なNoSQLを選ぶだけの用途や、結合とトランザクション整合性が中心の業務データには過剰、あるいは用途違いになります。自社のデータをどこに置くかを、条件付きで見極めてください。

Amazon DocumentDBの採用が効くワークロードと要件の条件の見極め

採用が効くのは、既存のMongoDBワークロードをAWS上へ移したい、かつMongoDBのAPIやドライバをそのまま使い続けたい、という条件が重なるときです。具体例としては、オンプレミスや他クラウドで動くMongoDBアプリの移行、ユーザープロファイルやカタログ・在庫のように属性が可変なドキュメントを扱うサービス、ゲームやSNSのように読み取りが多くレプリカでスケールしたいリアルタイムアプリが当てはまります。パッチ適用・バックアップ・レプリケーション・フェイルオーバーといった運用をマネージドに委ね、自前でMongoDBクラスターを組む手間を省きたい場面で効きます。こうしたAWS上のデータベース基盤や既存ワークロードの移行を自社で進めるなら、AWSを含むクラウドインフラ構築の相談窓口で、クラスター形態の選定やインスタンスサイズ、I/Oを含めたコストの妥当性を相談するとよいでしょう。

DynamoDB・MongoDB Atlasとの違いと選び分けの判断軸

同じNoSQL寄りの選択肢と比べると、判断軸がはっきりします。新規にAWSでNoSQLを選ぶだけで、MongoDBのAPI互換が必須でないなら、サーバーレスで運用がさらに軽いDynamoDBが候補になります。DynamoDBはインスタンスを持たず、リクエストと容量で課金されるため、トラフィックの波が大きい用途で無駄が出にくい設計です。両者の特徴は、AWS DynamoDBの特徴・料金・RDSとの違いを実装目線で解説した記事と読み比べると切り分けやすくなります。一方、MongoDBの最新バージョン固有の機能や特定のインデックス・集計機能が必須なら、本家のMongoDB Atlasを検討します。DocumentDBは互換対象のバージョン範囲が定められているため、要件がその範囲に収まるかを事前に確認するのが安全です。

DocumentDBが過剰・不要な場面とRDS・Auroraへ寄せる切り分け

複数テーブルの結合や、金額を扱うような厳密なトランザクション整合性が中心の業務データなら、ドキュメント指向のDocumentDBは用途違いです。こうしたデータは、MySQLやPostgreSQLといったリレーショナルエンジンをマネージドで動かすRDSや、負荷に応じて自動でスケールするAuroraへ寄せます。とくに需要の増減が読みにくいワークロードでは、コンピュートを自動で伸縮させるAurora Serverless v2のACUスケーリングと料金を解説した記事が選択肢になります。DocumentDBはインスタンスを起動している時間で課金が積み上がるため、アクセスがまばらな小規模用途に常時インスタンスを立てるのは割高です。スキーマが柔軟で結合が少ないならDocumentDB、正規化された関係データと整合性が要るならRDS/Aurora、という軸で選定してください。

よくある質問

Amazon DocumentDBの導入検討で実装者から多く挙がる質問を、一次情報に基づいて簡潔に整理します。

Amazon DocumentDBはMongoDBとどう違うのですか？

DocumentDBはMongoDB互換のAPIを提供するAWSのマネージドサービスで、MongoDB本体そのものではありません。MongoDBのドライバーやツールをほぼそのまま使える一方、互換対象は特定のバージョン範囲に定められ、内部エンジンはAWSが独自に実装しています。運用をAWSに委ねられる代わりに、MongoDBの最新版固有の機能がすべて使えるわけではないため、必要な機能が互換範囲に収まるかを事前に確認します。

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

既存のMongoDBワークロードを移行したい、あるいはMongoDBのAPI互換が要るならDocumentDB、新規にAWSでNoSQLを選ぶだけならサーバーレスのDynamoDBが起点になります。DynamoDBはインスタンスを持たずリクエストと容量で課金されるため、トラフィックの波が大きい用途で無駄が出にくい設計です。ドキュメントの柔軟なクエリやMongoDB互換が判断の分かれ目になります。

Amazon DocumentDBのバックアップと復元はどうなっていますか？

自動バックアップを1〜35日の範囲で保持でき、ポイントインタイムリカバリにより直近5分前まで、かつ保持期間中の任意の時点へ秒単位で復元できます。ストレージは3つのアベイラビリティゾーンに6方向でレプリケートされ、耐久性は99.999999999%という水準です。手動スナップショットの取得や、別リージョンへの展開と組み合わせて、復旧点とディザスタリカバリを設計します。

Amazon DocumentDBの料金はどう決まりますか？

インスタンスベースクラスターでは、起動したインスタンスの時間課金を中心に、I/Oリクエスト、格納ストレージ、バックアップストレージの4要素で積み上がります。前払いの初期費用はなく、使用したぶんだけの従量制です。I/Oが多いワークロードではI/O料金が支配的になる場面もあるため、読み書きの回数を見積もって試算し、Elasticクラスターは課金体系が異なる点に注意して公式で確認してください。

既存のMongoDBアプリはそのままAmazon DocumentDBへ移行できますか？

MongoDBのドライバー・ツールと互換のAPIを備えるため、接続文字列の差し替えを中心とした小さな変更で載せ替えられる場合が多いです。ただし互換対象のバージョン範囲を外れる機能や、一部のインデックス・集計機能は挙動が異なることがあります。移行前に、使用しているクエリや機能が互換範囲に収まるかを検証環境で確認し、必要ならAWS DMSなどの移行ツールを併用すると安全です。

関連記事

• データベースとは？種類・DBMS・RDBとNoSQLの選び方を実装目線で解説：DocumentDBの前提となるデータベースの分類とRDB・NoSQLの選び方を整理した上位概念の記事
• MongoDBとは？ドキュメント指向データベースの構造・使い方入門：DocumentDBが互換対象とするMongoDBの構造と使い方を整理した記事
• AWS DynamoDBとは？特徴・使い方・料金・RDSとの違いを実装目線で解説：DocumentDBと選び分けるAWSのサーバーレスNoSQLを整理した記事
• Aurora Serverless v2とは？料金・ACUスケーリング・v1移行を解説：結合や整合性が要る場合に寄せるRDB側のマネージドDBを整理した記事