Amazon DocumentDB 完全ガイド 2026

初心者から実務者向けの包括的解説

Amazon DocumentDB は、MongoDB API との互換性を保ちながら AWS クラウドで独自の最適化を施した フルマネージド・ドキュメントデータベース です。JSON ドキュメント、スキーマレス設計、複雑なネストされたデータ構造を得意とし、商品カタログ・CMS・ユーザープロファイル・IoT データなど「スキーマが動的に変化する」ワークロードに最適。MongoDB 3.6 / 4.0 / 5.0 API 互換で既存 MongoDB ドライバーをそのまま使用可能。最新の版 8.0 では最大 7 倍のクエリレイテンシ改善と圧縮率 5 倍向上を実現。

ドキュメントの目的

本ガイドは以下を対象としています。

• 初心者向け： DocumentDB とは何か、MongoDB との違いを学びたい方
• 開発者向け： ドキュメント設計・クエリ最適化・インデックス戦略を実装したい方
• データアーキテクト向け： スキーマレス設計・ネストされた構造の最適化
• DBA/インフラ向け： クラスター構成・バックアップ・レプリケーション・性能チューニング
• 意思決定者向け： MongoDB vs DocumentDB、DynamoDB との比較・投資判断

2025-2026 年の DocumentDB エコシステム

• DocumentDB 8.0（2025 年 11 月）： Planner Version 3 による最大 7 倍のクエリ改善、辞書ベース圧縮（Zstandard）で圧縮率 5 倍向上、6 新集計ステージ、並列ベクトルインデックス構築で 30% 高速化、MongoDB 6.0/7.0/8.0 ドライバーサポート
• DocumentDB 5.0 Long-Term Support（2026 年 2 月）： セキュリティ・安定性パッチのみ、新機能不含
• DocumentDB 3.6 Extended Support（2025 年 8 月）： 標準サポート終了（2026 年 3 月 30 日）から最大 3 年間の延長サポート
• Elastic Clusters GA： 動的スケーリングと自動シャーディング
• Global Cluster 拡張： マルチリージョン読み取り複製
• ベクトル検索対応： AI/ML 統合強化

目次

1. 概要
2. DocumentDB が解決する課題
3. 主な特徴
4. アーキテクチャ
5. DocumentDB vs MongoDB
6. コアコンポーネント
7. インスタンスタイプと構成
8. Elastic Clusters
9. ドキュメントモデル
10. インデックス戦略
11. クエリ最適化
12. 変更ストリーム（Change Streams）
13. Global Database
14. バックアップ・復元・PITR
15. セキュリティ
16. 性能チューニング
17. コスト最適化
18. 主要ユースケース
19. 設定・操作の具体例
20. 類似サービス比較
21. ベストプラクティス
22. トラブルシューティング
23. 2025-2026 最新動向
24. 学習リソース
25. 実装チェックリスト
26. まとめ

概要

初心者向けメモ： DocumentDB は「MongoDB を AWS で動かしたい」という需要から生まれたサービス。MongoDB Atlas（オンライン MongoDB ホスティング）との大きな違いは AWS ネイティブな統合：IAM 認証・KMS 暗号化・VPC セキュリティ・CloudWatch モニタリング・CloudTrail 監査が深く統合されており、エンタープライズなセキュリティ・コンプライアンス要件がある組織向け。一方、MongoDB の最新機能（5.0 以降の全機能）が必要な場合や、マルチリージョン自動同期が不可欠な場合は MongoDB Atlas も比較検討する。

DocumentDB は以下を実現します：

• MongoDB 互換 API： MongoDB 3.6 / 4.0 / 5.0 ドライバー・クエリ・ツールがそのまま使用可能
• スキーマレス柔軟性： JSON ドキュメントの属性を動的に追加・変更可能
• 自動スケーリング： Elastic Clusters で自動シャーディング
• マルチ AZ 耐久性： 3 AZ × 2 コピー = 6 コピーで 99.99% SLA
• AWS 統合： IAM・KMS・VPC・CloudWatch・CloudTrail が統合

DocumentDB が解決する課題

課題 1: MongoDB 管理の運用コスト

状況： オンプレミス MongoDB クラスターをメンテナンス・パッチ・バックアップ管理に週 20 時間消費

DocumentDB の解決：

• ノード追加・削除・パッチが自動
• バックアップ・復元が自動
• レプリケーション・フェイルオーバーが自動（< 30 秒）
• インフラ管理ゼロ

課題 2: JSON スキーマの柔軟性が必要

状況： 新しい属性を追加するたびに既存レコードの移行が必要な RDS が不適切

DocumentDB の解決：

• 新しい属性を追加してもスキーマ変更不要
• 既存レコードはそのまま、新規レコードから新属性を追加
• 柔軟な $lookup（JOIN）でネストされたデータを抽出

課題 3: AWS との セキュリティ統合が必須

状況： IAM・KMS・VPC・CloudTrail の深い統合が必要だが MongoDB Atlas では外部統合が必要

DocumentDB の解決：

• IAM ロール認証が標準
• KMS で保存時暗号化が自動
• VPC プライベートサブネット配置が推奨
• CloudTrail で全 API 呼び出しをログ記録

主な特徴

graph TD
    A["DocumentDB クラスター"] --> B["プライマリインスタンス<br/>読み書き"]
    A --> C["リーダーインスタンス<br/>読み取りのみ<br/>最大 15 個"]
    
    B --> D["共有クラスターボリューム<br/>3 AZ × 2 コピー<br/>最大 64 TiB"]
    C --> D
    
    D --> E["自動 Failover<br/>< 30 秒"]
    D --> F["PITR バックアップ<br/>35 日"]
    D --> G["スナップショット<br/>手動・自動"]
    
    H["Change Streams"] --> I["Lambda"]
    H --> J["Kinesis"]
    H --> K["Kafka"]

主な特徴の詳細

1. MongoDB API 互換性

   • MongoDB 3.6 / 4.0 / 5.0 ドライバーをサポート
   • BSON データ形式対応
   • aggregation framework 対応
   • $lookup（SQL JOIN 相当）対応

2. クラスターアーキテクチャ

   • プライマリ + リードレプリカ（最大 15 個）
   • 共有クラスターボリューム（3 AZ × 2 コピー）
   • < 30 秒 Failover
   • 自動フェイルオーバー

3. パフォーマンス

   • DocumentDB 8.0: 最大 7 倍クエリレイテンシ改善
   • 辞書ベース圧縮（Zstandard）で圧縮率 5 倍向上
   • 並列ベクトルインデックス構築で 30% 高速化

4. スキーマレス設計

   • JSON ドキュメント
   • ネストされた構造
   • 配列フィールド
   • 動的属性追加

アーキテクチャ

flowchart TB
    app["アプリケーション<br/>MongoDB ドライバー"]
    endpoint["DocumentDB エンドポイント（DNS）<br/>クラスターエンドポイント（読み書き）<br/>リーダーエンドポイント（読み取り）"]
    primary["プライマリインスタンス<br/>読み書き"]
    replicas["リーダーレプリカ<br/>最大 15 個 / 読み取り"]
    storage["共有クラスターボリューム<br/>3 AZ × 2 コピー<br/>最大 64 TiB 自動拡張<br/>PITR 35日 / スナップショット"]

    app --> endpoint
    endpoint --> primary
    endpoint --> replicas
    primary --> storage
    replicas --> storage
    replicas -.フェイルオーバー時に昇格.-> primary

キーポイント

• クラスターボリューム分離： ストレージをインスタンスから分離することで、インスタンス障害時のリカバリが高速化
• 自動複製： 3 AZ に 2 コピー = 6 データコピーで高可用性確保
• リードスケーリング： リーダーレプリカを追加することで読み取りスケーリング
• ホットスタンバイ： すべてのレプリカがアクティブで、常にデータ同期状態

DocumentDB vs MongoDB

コアコンポーネント

1. インスタンスタイプ

db.r6g.xlarge     (8 vCPU, 64 GB)
db.r6g.2xlarge    (16 vCPU, 128 GB)
db.r6g.4xlarge    (32 vCPU, 256 GB)
↑ 最新世代（Graviton 2 ベース）

db.r5.large       (2 vCPU, 16 GB)   ← 小規模用
db.r5.xlarge      (4 vCPU, 32 GB)
db.r5.2xlarge     (8 vCPU, 64 GB)
↑ 前世代（Intel ベース）

2. クラスター構成

1 プライマリ + N リーダーレプリカ
最小: 1 プライマリ
最大: 1 プライマリ + 15 リーダー = 16 インスタンス

3. Elastic Clusters（GA）

• 自動スケーリング

• 自動シャーディング

• ノード追加時の再バランシング自動化

• Shard 1: Primary + Replicas

• Shard 2: Primary + Replicas

• …

• Shard N: Primary + Replicas

インスタンスタイプと構成

標準インスタンス（Instance-based）

# AWS CLI でクラスター作成（標準）
aws docdb create-db-cluster \
  --db-cluster-identifier my-cluster \
  --engine docdb \
  --engine-version 8.0 \
  --master-username admin \
  --master-user-password 'Pass@123!' \
  --db-subnet-group-name my-subnet-group \
  --vpc-security-group-ids sg-12345678 \
  --backup-retention-period 35 \
  --preferred-backup-window "03:00-04:00" \
  --preferred-maintenance-window "sun:04:00-sun:05:00"

# インスタンス追加（プライマリ）
aws docdb create-db-instance \
  --db-instance-identifier my-instance-primary \
  --db-instance-class db.r6g.xlarge \
  --engine docdb \
  --db-cluster-identifier my-cluster \
  --publicly-accessible false

# インスタンス追加（リーダーレプリカ）
aws docdb create-db-instance \
  --db-instance-identifier my-instance-replica-1 \
  --db-instance-class db.r6g.xlarge \
  --engine docdb \
  --db-cluster-identifier my-cluster

Elastic Clusters

# AWS CLI で Elastic Cluster 作成
aws docdb-elastic create-cluster \
  --cluster-name my-elastic-cluster \
  --shard-capacity 4 \
  --shard-count 3 \
  --auth-type SECRET_ARN \
  --admin-user-name admin \
  --subnet-ids subnet-12345678 subnet-87654321 \
  --security-group-ids sg-12345678

Elastic Clusters

Elastic Clusters は DocumentDB の新しいクラスター構成で、以下の特徴がある：

従来（Instance-based）:
  └─ 手動でインスタンスを追加・削除
  └─ キャパシティプランニング必要
  └─ シャーディング手動管理

Elastic Clusters:
  └─ 自動スケーリング
  └─ 自動シャーディング
  └─ キャパシティプランニング不要

利点

• 自動スケーリング：トラフィックに応じてシャード数自動調整
• 簡潔な API：インスタンス管理不要
• コスト効率：使用した容量のみ課金

ドキュメントモデル

基本的なドキュメント構造

{
  "_id": ObjectId("507f1f77bcf86cd799439011"),
  "userId": "user_12345",
  "email": "user@example.com",
  "profile": {
    "firstName": "John",
    "lastName": "Doe",
    "birthDate": ISODate("1990-01-15"),
    "address": {
      "street": "123 Main St",
      "city": "Springfield",
      "zipCode": "12345"
    }
  },
  "tags": ["premium", "verified", "early_adopter"],
  "orders": [
    {
      "orderId": "ORD001",
      "date": ISODate("2024-01-15"),
      "amount": 299.99,
      "items": [
        { "sku": "SKU123", "quantity": 2, "price": 149.99 }
      ]
    }
  ],
  "preferences": {
    "newsletter": true,
    "notifications": {
      "email": true,
      "sms": false
    }
  },
  "createdAt": ISODate("2024-01-01"),
  "updatedAt": ISODate("2024-04-26")
}

基本的な CRUD 操作

// コレクション内にドキュメント挿入
db.users.insertOne({
  userId: "user_99999",
  email: "newuser@example.com",
  tags: ["new"]
})

// 複数ドキュメント挿入
db.users.insertMany([
  { userId: "user_77777", email: "user77@example.com" },
  { userId: "user_88888", email: "user88@example.com" }
])

// クエリ（条件指定）
db.users.findOne({ userId: "user_12345" })

// 複数条件クエリ
db.users.find({
  "profile.address.city": "Springfield",
  tags: "premium"
})

// インデックス使用したソート
db.users.find(
  { "profile.address.city": "Springfield" }
).sort({ createdAt: -1 }).limit(10)

// ドキュメント更新
db.users.updateOne(
  { userId: "user_12345" },
  {
    $set: {
      "profile.firstName": "Jane",
      updatedAt: new Date()
    }
  }
)

// 配列要素の追加
db.users.updateOne(
  { userId: "user_12345" },
  { $push: { tags: "gold_member" } }
)

// ドキュメント削除
db.users.deleteOne({ userId: "user_12345" })

集計パイプライン

// ユーザーの注文額合計を集計
db.users.aggregate([
  {
    $match: {
      "profile.address.city": "Springfield"
    }
  },
  {
    $unwind: "$orders"
  },
  {
    $group: {
      _id: "$userId",
      totalSpent: { $sum: "$orders.amount" },
      orderCount: { $sum: 1 }
    }
  },
  {
    $sort: { totalSpent: -1 }
  },
  {
    $limit: 10
  }
])

// JOIN 相当（$lookup）
db.users.aggregate([
  {
    $lookup: {
      from: "orders",
      localField: "userId",
      foreignField: "userId",
      as: "orderHistory"
    }
  },
  {
    $match: {
      "orderHistory": { $not: { $size: 0 } }
    }
  }
])

インデックス戦略

インデックスタイプ

インデックス作成例

// シングルフィールドインデックス
db.users.createIndex({ email: 1 })

// 複合インデックス（複数フィールド）
db.users.createIndex({
  "profile.address.city": 1,
  status: 1
})

// マルチキーインデックス（自動: 配列フィールド）
db.users.createIndex({ tags: 1 })

// テキストインデックス
db.articles.createIndex({ title: "text", content: "text" })

// TTL インデックス（自動削除）
db.sessions.createIndex(
  { createdAt: 1 },
  { expireAfterSeconds: 3600 }  // 1 時間後に自動削除
)

// 部分インデックス
db.users.createIndex(
  { email: 1 },
  { partialFilterExpression: { status: "active" } }
)

// ベクトルインデックス（新機能）
db.products.createIndex({
  embedding: "vector"
}, {
  dimension: 1536,
  similarity: "cosine"
})

インデックス最適化のベストプラクティス

// インデックス使用状況の確認
db.users.aggregate([
  { $indexStats: {} }
])

// クエリプラン確認
db.users.find({
  email: "user@example.com"
}).explain("executionStats")

// 不要なインデックス削除
db.users.dropIndex({ email: 1 })

// すべてのインデックス表示
db.users.getIndexes()

クエリ最適化

クエリプランの分析

// Explain で実行計画を確認
const plan = db.users.find({
  "profile.address.city": "Springfield",
  status: "active"
}).explain("executionStats")

console.log("executionStats:", plan.executionStats)
// docsExamined: 検査したドキュメント数
// nReturned: 返却したドキュメント数
// executionTimeMillis: 実行時間

// 最適：docsExamined === nReturned（インデックス完全使用）
// 悪い：docsExamined >> nReturned（不要なドキュメント検査）

スキャン最適化パターン

// ❌ 悪い例：インデックス未使用（全テーブルスキャン）
db.users.find({
  $or: [
    { firstName: "John" },
    { email: { $regex: "example.com" } }
  ]
})

// ✅ 良い例：複合インデックス利用
db.users.createIndex({ email: 1, status: 1 })
db.users.find({
  email: "user@example.com",
  status: "active"
})

// ❌ 悪い例：集計時に大量フィルタリング
db.orders.aggregate([
  { $match: { status: "pending" } },
  { $lookup: { from: "products", ... } },
  { $unwind: "$items" },
  { $match: { "items.price": { $gt: 100 } } }  // ← 遅い
])

// ✅ 良い例：早期に絞り込み
db.orders.aggregate([
  { $match: { status: "pending" } },
  { $match: { "items.price": { $gt: 100 } } },  // ← 先にフィルタリング
  { $lookup: { from: "products", ... } }
])

変更ストリーム（Change Streams）

Change Streams は、ドキュメントの挿入・更新・削除をリアルタイムでキャプチャする CDC 機能。

// Change Streams 監視開始
const changeStream = db.users.watch()

changeStream.on('change', (change) => {
  console.log('Change detected:', change.operationType)
  // operationType: "insert", "update", "delete", "replace"
  
  if (change.operationType === 'insert') {
    console.log('New document:', change.fullDocument)
  }
  
  if (change.operationType === 'update') {
    console.log('Updated fields:', change.updateDescription)
  }
})

// 特定の操作のみを監視（フィルタリング）
const changeStream = db.users.watch([
  {
    $match: {
      operationType: { $in: ['insert', 'update'] },
      'fullDocument.status': 'active'
    }
  }
])

Lambda との連携

DocumentDB Change Streams
    ↓ (Kinesis Data Streams へ送信)
Kinesis
    ↓ (トリガー)
Lambda Function
    ├─→ SNS (通知)
    ├─→ SQS (キューイング)
    ├─→ S3 (ログ保存)
    └─→ OpenSearch (検索インデックス)

Global Database

Global Database は、複数リージョン間でのレプリケーション。

プライマリリージョン（AWS Tokyo）
    └─ DocumentDB Cluster（読み書き）
       ↓
       └─→ セカンダリリージョン（AWS Singapore）
           └─ DocumentDB Cluster（読み取り）
       └─→ セカンダリリージョン（AWS Sydney）
           └─ DocumentDB Cluster（読み取り）

RPO（Recovery Point Objective）: < 1 秒
RTO（Recovery Time Objective）: < 1 分

Global Database の設定

# グローバルデータベース作成
aws docdb create-global-cluster \
  --global-cluster-identifier my-global-cluster \
  --engine docdb \
  --engine-version 5.0

# プライマリリージョンのクラスターを作成
aws docdb create-db-cluster \
  --db-cluster-identifier primary-cluster \
  --engine docdb \
  --global-cluster-identifier my-global-cluster

# セカンダリリージョンのクラスターを作成
aws docdb create-db-instance-in-db-cluster \
  --db-cluster-identifier primary-cluster \
  --db-instance-identifier primary-instance \
  --db-instance-class db.r5.large \
  --region us-east-1

# セカンダリリージョンのクラスター追加
aws docdb add-members-to-global-cluster \
  --global-cluster-identifier my-global-cluster \
  --db-cluster-identifier secondary-cluster \
  --region eu-west-1

バックアップ・復元・PITR

バックアップタイプ

自動バックアップ（PITR: Point-in-Time Recovery）
    ├─ 最大 35 日まで任意の秒単位で復元可能
    ├─ 継続的にトランザクションログをキャプチャ
    └─ コスト：クラスターストレージ × 1 倍まで無料

スナップショット（手動）
    ├─ オンデマンド作成
    ├─ 削除まで保持（容量課金）
    └─ 別アカウント・別リージョンに共有可能

バックアップ・復元の操作

# 自動バックアップの設定
aws docdb modify-db-cluster \
  --db-cluster-identifier my-cluster \
  --backup-retention-period 35 \
  --preferred-backup-window "03:00-04:00"

# PITR から復元
aws docdb restore-db-cluster-to-point-in-time \
  --db-cluster-identifier my-cluster-restored \
  --source-db-cluster-identifier my-cluster \
  --restore-type "copy-on-write" \
  --restore-to-time 2024-04-26T12:30:00Z

# スナップショット作成
aws docdb create-db-cluster-snapshot \
  --db-cluster-snapshot-identifier my-snapshot \
  --db-cluster-identifier my-cluster

# スナップショットから復元
aws docdb restore-db-cluster-from-snapshot \
  --db-cluster-identifier my-cluster-from-snapshot \
  --snapshot-identifier my-snapshot \
  --engine docdb

セキュリティ

ネットワークセキュリティ

┌──────────────────────────────────────┐
│         VPC（プライベート）           │
│  ┌────────────────────────────────┐  │
│  │  プライベートサブネット         │  │
│  │  ┌──────────────────────────┐  │  │
│  │  │ DocumentDB クラスター    │  │  │
│  │  │ (ポート 27017)           │  │  │
│  │  └──────────────────────────┘  │  │
│  └────────────────────────────────┘  │
│           ↑                           │
│           │ Security Group            │
│           │ 許可: EC2, Lambda         │
│           │ 拒否: Public Access       │
└──────────────────────────────────────┘

IAM 認証

# IAM 認証を有効化
aws docdb modify-db-cluster \
  --db-cluster-identifier my-cluster \
  --enable-iam-database-authentication

# IAM ポリシー例
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "docdb:DescribeDBClusters",
        "docdb:DescribeDBInstances",
        "docdb:ListTagsForResource"
      ],
      "Resource": "arn:aws:docdb:*:*:cluster:my-cluster"
    },
    {
      "Effect": "Allow",
      "Action": "docdb-aws:connect",
      "Resource": "arn:aws:docdb:*:*:db:mydb/*"
    }
  ]
}

# MongoDB ドライバーで IAM 認証を使用
const { MongoClient } = require('mongodb');

const client = new MongoClient(
  'mongodb+srv://cluster.docdb.amazonaws.com/?retryWrites=false',
  {
    authMechanism: 'MONGODB-AWS',
    authMechanismProperties: {
      AWS_ACCESS_KEY_ID: process.env.AWS_ACCESS_KEY_ID,
      AWS_SECRET_ACCESS_KEY: process.env.AWS_SECRET_ACCESS_KEY,
      AWS_SESSION_TOKEN: process.env.AWS_SESSION_TOKEN
    }
  }
);

暗号化

# KMS 暗号化を有効化
aws docdb create-db-cluster \
  --db-cluster-identifier my-cluster \
  --storage-encrypted true \
  --kms-key-id "arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012"

# 転送中の暗号化（TLS）
# MongoDB URI で TLS を有効化
mongodb://admin:password@cluster.docdb.amazonaws.com:27017/?ssl=true&retryWrites=false&replicaSet=rs0

性能チューニング

Performance Insights

# Performance Insights 有効化
aws docdb modify-db-instance \
  --db-instance-identifier my-instance \
  --enable-performance-insights true \
  --performance-insights-retention-period 7

# 遅いクエリを確認
# CloudWatch の Performance Insights ダッシュボード
# → データベース負荷を視覚化
# → CPU・ロック・ディスク I/O を分析

クエリパフォーマンス分析

// シンプルなベンチマーク
const start = Date.now()

const results = db.users.find({
  "profile.address.city": "Springfield"
}).toArray()

const duration = Date.now() - start
console.log(`Query took ${duration}ms, returned ${results.length} docs`)

// Explain で実行計画を確認
db.users.find({
  "profile.address.city": "Springfield"
}).explain("executionStats")

インスタンス負荷の監視

# CloudWatch メトリクス確認
aws cloudwatch get-metric-statistics \
  --namespace AWS/DocDB \
  --metric-name CPUUtilization \
  --dimensions Name=DBInstanceIdentifier,Value=my-instance \
  --start-time 2024-04-25T00:00:00Z \
  --end-time 2024-04-26T00:00:00Z \
  --period 300 \
  --statistics Average,Maximum

# ディスク I/O の確認
aws cloudwatch get-metric-statistics \
  --namespace AWS/DocDB \
  --metric-name ReadLatency \
  --dimensions Name=DBInstanceIdentifier,Value=my-instance \
  --start-time 2024-04-25T00:00:00Z \
  --end-time 2024-04-26T00:00:00Z \
  --period 300 \
  --statistics Average,Maximum

コスト最適化

コスト構造

月額費用 = インスタンス料金 + ストレージ料金 + I/O 料金 + バックアップ超過分

インスタンス料金: db.r5.large で $0.52/時間（月 $375）
ストレージ: $0.17/GB/月
I/O: $0.20/100 万リクエスト
バックアップ: GB/月（クラスターストレージ × 1 倍まで無料）

コスト削減パターン

# ✅ リードレプリカの共有
# 不要：読み取り用に専用インスタンス
# 推奨：複数アプリが共有リーダーエンドポイントを使用

# ✅ バックアップ期間の最適化
# デフォルト 35 日を見直し
aws docdb modify-db-cluster \
  --db-cluster-identifier my-cluster \
  --backup-retention-period 7  # 7 日に短縮

# ✅ Elastic Clusters の活用
# 不要：固定容量のインスタンス
# 推奨：自動スケーリングで使用量に応じて課金

# ✅ オンプレミスからの移行時のハイブリッド運用
# 段階的移行で旧システムとの並行運用コスト削減

主要ユースケース

設定・操作の具体例

CLI 例

# クラスター作成
aws docdb create-db-cluster \
  --db-cluster-identifier production-cluster \
  --engine docdb \
  --engine-version 8.0 \
  --master-username admin \
  --master-user-password 'MySecurePass123!' \
  --db-subnet-group-name default \
  --vpc-security-group-ids sg-12345678 \
  --backup-retention-period 35 \
  --storage-encrypted true \
  --kms-key-id "arn:aws:kms:us-east-1:123456789012:key/abcd1234" \
  --enable-cloudwatch-logs-exports '["audit","error","general","slowlog"]'

# インスタンス追加
aws docdb create-db-instance \
  --db-instance-identifier production-instance-1 \
  --db-instance-class db.r6g.xlarge \
  --engine docdb \
  --db-cluster-identifier production-cluster \
  --auto-minor-version-upgrade true

# クラスター確認
aws docdb describe-db-clusters \
  --db-cluster-identifier production-cluster

# インスタンス確認
aws docdb describe-db-instances \
  --db-instance-identifier production-instance-1

SDK 例（Node.js）

const { MongoClient } = require('mongodb');

// 接続
const client = new MongoClient(
  'mongodb://admin:password@cluster.docdb.amazonaws.com:27017/?ssl=true&retryWrites=false',
  {
    useNewUrlParser: true,
    useUnifiedTopology: true,
  }
);

async function main() {
  try {
    await client.connect();
    const db = client.db('myapp');
    const users = db.collection('users');

    // ドキュメント挿入
    const result = await users.insertOne({
      userId: 'user_12345',
      email: 'user@example.com',
      profile: {
        name: 'John Doe',
        address: {
          city: 'Springfield'
        }
      },
      tags: ['premium', 'verified'],
      createdAt: new Date()
    });

    console.log('Inserted:', result.insertedId);

    // クエリ
    const user = await users.findOne({ userId: 'user_12345' });
    console.log('Found:', user);

    // インデックス作成
    await users.createIndex({ email: 1 });
    await users.createIndex({
      'profile.address.city': 1,
      tags: 1
    });

    // 集計
    const results = await users.aggregate([
      { $match: { tags: 'premium' } },
      { $group: { _id: '$profile.address.city', count: { $sum: 1 } } },
      { $sort: { count: -1 } }
    ]).toArray();

    console.log('Aggregation:', results);

  } finally {
    await client.close();
  }
}

main().catch(console.error);

Terraform 例

# DocumentDB クラスター
resource "aws_docdb_cluster" "example" {
  cluster_identifier      = "my-docdb-cluster"
  engine                  = "docdb"
  engine_version          = "8.0"
  master_username         = "admin"
  master_password         = "MySecurePass123!"
  backup_retention_period = 35
  skip_final_snapshot     = false
  final_snapshot_identifier = "my-docdb-final-snapshot"
  
  db_subnet_group_name            = aws_docdb_subnet_group.default.name
  db_cluster_parameter_group_name = aws_docdb_cluster_parameter_group.default.name
  
  storage_encrypted = true
  kms_key_id        = aws_kms_key.docdb.arn
  
  enabled_cloudwatch_logs_exports = ["audit", "error", "general", "slowlog"]
  
  tags = {
    Name = "MyDocDBCluster"
  }
}

# DocumentDB インスタンス
resource "aws_docdb_cluster_instance" "example" {
  count              = 2
  identifier         = "my-docdb-instance-${count.index}"
  cluster_identifier = aws_docdb_cluster.example.id
  instance_class     = "db.r6g.xlarge"
  engine             = aws_docdb_cluster.example.engine
  auto_minor_version_upgrade = true
}

# セキュリティグループ
resource "aws_security_group" "docdb" {
  name = "docdb-sg"
  
  ingress {
    from_port       = 27017
    to_port         = 27017
    protocol        = "tcp"
    security_groups = [aws_security_group.app.id]
  }
  
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

類似サービス比較

ベストプラクティス

インデックス設計

✅ 推奨パターン

• db.users.createIndex({ email: 1 }, { unique: true }) // 一意性を強制
• db.orders.createIndex({ customerId: 1, createdAt: -1 }) // 複合インデックス
• db.products.createIndex({ tags: 1 }) // 配列フィールド（自動マルチキー）
• db.events.createIndex({ createdAt: 1 }, { expireAfterSeconds: 2592000 }) // TTL

❌ アンチパターン

• インデックスなしの大規模フィルタリング（全テーブルスキャン）
• 不要な複合インデックスの作成（メモリ消費・書き込み遅延）
• すべてのフィールドにインデックス（インデックスメンテナンスコスト）

設計パターン

✅ 推奨パターン

• 埋め込みドキュメント：関連データを 1 ドキュメントに
• 配列フィールド：メッセージ・アイテム・タグを配列で管理
• 共有リーダーエンドポイント：複数アプリが同じリーダーを使用
• Change Streams で CDC：リアルタイム同期

❌ アンチパターン

• 正規化しすぎ：MongoDB の強みであるドキュメント指向を活かしていない
• 大量の $lookup：RDS の JOIN が必要な場合は RDS を検討
• 複雑な集計パイプライン：分析は Redshift/Athena へ

オペレーション

✅ 推奨パターン

• バックアップ保持期間を定期的に見直し（コスト最適化）
• Performance Insights で定期的に遅いクエリを確認
• CloudWatch Logs で監査ログ・エラーログを監視
• IAM 認証・KMS 暗号化・VPC 配置を標準化

❌ アンチパターン

• パスワード認証のみ（IAM 認証を無効）
• KMS 暗号化なし（セキュリティリスク）
• パブリックサブネット配置（外部アクセス許可）
• バックアップなし（PITR 機能を活用せず）

トラブルシューティング

2025-2026 最新動向

DocumentDB 8.0 リリース（2025 年 11 月）

主要な改善：

• Planner Version 3：クエリプランナーが集計ステージ演算子に対応、パフォーマンス向上
• 新集計ステージ：6 つの新ステージ（documents、group など）
• 辞書ベース圧縮（Zstandard）：圧縮率が最大 5 倍向上、ストレージコスト削減
• 並列ベクトルインデックス構築：インデックス構築が最大 30% 高速化
• MongoDB 6.0/7.0/8.0 ドライバーサポート：最新ドライバーとの互換性向上

DocumentDB 5.0 Long-Term Support（2026 年 2 月）

• 標準サポート機能のセキュリティ・安定性パッチのみ
• 新機能は含まない
• 3 年間の安定性保証
• 本番環境で長期安定性が必要な場合に推奨

DocumentDB 3.6 Extended Support（2025 年 8 月）

• 標準サポート終了予定（2026 年 3 月 30 日）から 3 年間の延長サポート
• 既存レガシーワークロードの段階的移行をサポート

今後の展開

• ベクトル検索の強化：生成 AI との統合拡大
• Elastic Clusters GA：自動スケーリングの標準化
• Global Cluster 拡張：マルチリージョン機能強化
• Analytics Engine 統合：Redshift Zero-ETL との統合

学習リソース

公式ドキュメント

• Amazon DocumentDB Developer Guide
• Amazon DocumentDB API Reference
• DocumentDB Release Notes
• DocumentDB Best Practices

関連プロジェクト・ツール

• MongoDB Node.js Driver
• MongoDB Python Driver (PyMongo)
• MongoDB Compass - GUI クライアント
• mongosh

AWS リソース

• AWS Database Blog - DocumentDB
• AWS Samples - DocumentDB
• AWS Ramp-Up Guides

外部リソース

• MongoDB Official Docs
• MongoDB Aggregation Pipeline
• MongoDB Indexing

実装チェックリスト

導入前の検討事項

• [ ] スキーマレス・ネストされたドキュメント構造が要件か確認
• [ ] MongoDB API 互換性で十分か確認（最新機能の必要性）
• [ ] AWS ネイティブ統合（IAM・KMS・VPC）が必須か確認
• [ ] グローバル展開の必要性を検討
• [ ] RDS・DynamoDB との比較検討

クラスター構築

• [ ] VPC・プライベートサブネット設計
• [ ] セキュリティグループで EC2・Lambda のアクセス許可
• [ ] KMS キー設定・IAM 認証有効化
• [ ] バックアップ保持期間設定（35 日 推奨）
• [ ] CloudWatch Logs 出力有効化（audit・error・general・slowlog）

開発フェーズ

• [ ] ドキュメント設計・アクセスパターン定義
• [ ] 主要クエリのインデックス戦略設計
• [ ] SDK・ドライバーのセットアップ
• [ ] Connection pooling の設定（推奨: 最小 10・最大 100）
• [ ] エラーハンドリング・リトライロジック実装

本番運用

• [ ] Performance Insights による遅いクエリの監視
• [ ] CloudWatch アラーム設定（CPU・ストレージ・IOPS）
• [ ] バックアップ・復旧テストの定期実施
• [ ] リーダーレプリカへの読み取り分散
• [ ] 定期的なインデックス最適化・不要インデックス削除

セキュリティ

• [ ] IAM 認証有効化・パスワード認証の廃止検討
• [ ] KMS 暗号化・CMK 使用
• [ ] VPC エンドポイント設定（PrivateLink）
• [ ] CloudTrail で API 呼び出し監査
• [ ] 定期的なセキュリティグループ見直し

まとめ

Amazon DocumentDB は 「AWS ネイティブな MongoDB 互換ドキュメントデータベース」 です。JSON ドキュメント・スキーマレス設計・ネストされた複雑なデータ構造が必要なワークロード（商品カタログ・CMS・ユーザープロファイル）に最適。

選ぶべき場合：

• AWS IAM・KMS・VPC などのエンタープライズセキュリティ統合が必須
• MongoDB 互換 API でコード変更最小化を希望
• スキーマレスの柔軟性が必要
• AWS マネージドサービスでの運用コスト削減

避けるべき場合：

• MongoDB の最新機能（5.0 以降の全機能）が必須 → MongoDB Atlas
• 複雑な SQL JOIN が必要 → RDS / Aurora
• キーバリュー・シンプルなアクセス → DynamoDB

DocumentDB 8.0 による最大 7 倍のクエリ改善と圧縮率 5 倍向上により、本番環境での採用メリットが一層高まっています。AWS ネイティブな統合とドキュメント指向の柔軟性を最大限に活かすことで、スケーラブルで保守性の高いアプリケーション基盤を構築できます。

最終更新：2026-04-26 バージョン：v2.0