Amazon Aurora、Amazon DocumentDB、Amazon Neptuneの比較表(違い、共通点のまとめ) ～Comparison Table, difference between Amazon Aurora, Amazon DocumentDB, Amazon Neptune～

5月 11, 2021Aurora,AWS,DocumentDB,Neptune

Amazon Web Services（AWS）は、多様なワークロードに対応するため、10種類以上のデータベースサービスを提供しています。その中でもAmazon Aurora、Amazon DocumentDB、Amazon Neptuneは、他のサービスとは一線を画す革新的な技術「クォーラムモデル」を採用した次世代データベースです。

これらのサービスは、それぞれ異なるデータモデル（リレーショナル、ドキュメント、グラフ）をサポートしながらも、ストレージアーキテクチャやクラスター構成に驚くほど多くの共通点を持っています。しかし、AWSはこれらが同一の基盤技術を使用しているとは公式に明言していません。

本記事で分かること

  • クォーラムモデルの仕組みと従来のレプリケーション方式との違い
  • 3つのサービスの詳細な機能比較表（30項目以上を網羅）
  • 運用に必須のモニタリング指標と推奨される対応方法
  • 設定変更時のダウンタイム影響と回避策
  • 適切なサービス選択の指針とユースケース別の推奨事項

こんな方におすすめ

  • AWSでのデータベース選定に悩んでいるアーキテクト、エンジニア
  • 既存のデータベースからAWSへの移行を検討している方
  • Aurora、DocumentDB、Neptuneの違いを体系的に理解したい方
  • AWS認定資格（Solutions Architect、Database Specialty）の学習をしている方
  • 高可用性とパフォーマンスを両立するデータベース設計を目指している方

本記事では、AWS公式ドキュメント、AWS Black Belt Online Seminar資料、そして実際の運用経験とAWSサポートへの問い合わせ内容を基に、実務で即活用できる情報を体系的にまとめています。

AWSのデータベースサービスとクォーラムモデル

Amazon Web Services（AWS）では、多様なワークロードに対応するため、豊富なデータベースサービスを提供しています。主なサービスには以下があります：

  • Amazon Aurora - 高性能なリレーショナルデータベース
  • Amazon RDS - マネージド型リレーショナルデータベース
  • Amazon DynamoDB - NoSQLデータベース
  • Amazon DocumentDB - MongoDB互換ドキュメントデータベース
  • Amazon Neptune - グラフデータベース
  • Amazon ElastiCache - インメモリキャッシュ
  • Amazon Redshift - データウェアハウス
  • Amazon Timestream - 時系列データベース
  • Amazon Keyspaces - Apache Cassandra互換データベース
  • Amazon QLDB - 台帳データベース

クォーラムモデルによる高可用性の実現

これらのサービスの中で、Amazon Aurora、Amazon DocumentDB、Amazon Neptuneは、「クォーラムモデル」という先進的なデータレプリケーション技術を採用しています。

クォーラムモデルとは、複数のデータコピーのうち一定数（過半数）に対して書き込みまたは読み込みが完了した時点でその処理を成功とみなし、残りのデータコピーについては非同期で整合性を保つという仕組みです。

この技術の最大の利点は、従来のレプリケーション方式が抱えていた以下の課題を解決できることです：

  • 同期レプリケーション：すべてのレプリカへの書き込み完了を待つため、レイテンシが増加する問題
  • 非同期レプリケーション：障害発生時にデータ損失のリスクがある問題

クォーラムモデルは、これらの問題点をバランス良く解決し、高いパフォーマンスと耐障害性を両立させています。

クォーラムモデルの理解を深めるための参考資料

クォーラムモデルの詳細な概念や仕組みについて、以下の資料が参考になります：

共通基盤の可能性と本記事の目的

Amazon Aurora、Amazon DocumentDB、Amazon Neptuneについて、AWSドキュメントやAWS Black Belt Online Seminar資料を確認すると、クラスター構成やストレージアーキテクチャに多くの共通点が見られます。

ただし、本記事執筆時点において、AWSからこれら3つのサービスが同一の基盤技術を使用しているという公式アナウンスは確認できていません。

そこで本記事では、これらのデータベースサービスの理解を効率的に深めることを目的として、共通点と相違点を詳細に比較した一覧表を作成しました。

以下の比較表は、次の情報源を基に作成しています：

※ 本記事の情報は個人の調査に基づくものです。最新情報や詳細については、必ずAWS公式ドキュメントをご確認ください。

Amazon Aurora、Amazon DocumentDB、Amazon Neptuneの機能比較表

以下の表では、3つのデータベースサービスの主要な機能について、共通点と相違点を詳しく比較しています。

基本仕様・データベースエンジン

比較項目 Amazon Aurora Amazon DocumentDB Amazon Neptune
概要 リレーショナルデータベース MongoDB互換ドキュメントデータベース グラフデータベース
サポートデータベース MySQL、PostgreSQL MongoDB 3.6、4.0、5.0互換 Apache TinkerPop Gremlin、W3C SPARQL
ユースケース エンタープライズアプリケーション、
SaaS、Webアプリケーション		 コンテンツ管理、カタログ、
ユーザープロファイル管理		 ソーシャルネットワーク、
レコメンデーション、不正検知、
知識グラフ
デフォルトDBポート 3306（MySQL）
5432（PostgreSQL）		 27017 8182

ストレージとデータ可用性

比較項目 Amazon Aurora Amazon DocumentDB Amazon Neptune
ストレージ自動拡張 10GB単位で最大128TiBまで自動拡張
（使用量に応じて自動的に増減）		 10GB単位で最大64TiBまで自動拡張
（使用量に応じて自動的に増減）		 10GB単位で最大64TiBまで自動拡張
（使用量に応じて自動的に増減）
ストレージ可用性
（クォーラムモデル）		 3つのアベイラビリティーゾーン（AZ）に6個のデータコピーを自動作成。

書き込みクォーラム：6個中4個
読み込みクォーラム：6個中3個

・最大3個のコピー損失でも読み込み可能
・最大2個のコピー損失でも書き込み可能
・データ損失なしで高可用性を維持		 3つのアベイラビリティーゾーン（AZ）に6個のデータコピーを自動作成。

書き込みクォーラム：6個中4個
読み込みクォーラム：6個中3個

・最大3個のコピー損失でも読み込み可能
・最大2個のコピー損失でも書き込み可能
・データ損失なしで高可用性を維持		 3つのアベイラビリティーゾーン（AZ）に6個のデータコピーを自動作成。

書き込みクォーラム：6個中4個
読み込みクォーラム：6個中3個

・最大3個のコピー損失でも読み込み可能
・最大2個のコピー損失でも書き込み可能
・データ損失なしで高可用性を維持
ストレージタイプ クラスター共有ストレージ
（SSDベース、自動レプリケーション）		 クラスター共有ストレージ
（SSDベース、自動レプリケーション）		 クラスター共有ストレージ
（SSDベース、自動レプリケーション）

クラスター構成とフェイルオーバー

比較項目 Amazon Aurora Amazon DocumentDB Amazon Neptune
クラスター構成 ・1つのプライマリDBインスタンス（読み書き）
・0～15個のリードレプリカDBインスタンス（読み取り専用）
・最大16インスタンス		 ・1つのプライマリDBインスタンス（読み書き）
・0～15個のリードレプリカDBインスタンス（読み取り専用）
・最大16インスタンス		 ・1つのプライマリDBインスタンス（読み書き）
・0～15個のリードレプリカDBインスタンス（読み取り専用）
・最大16インスタンス
フェイルオーバー
優先順位		 レプリカの昇格階層（Tier）を0（最優先）～15（最低優先）で指定可能。

昇格順序：
1. 優先度が高い（0に近い）リードレプリカ
2. 優先度が同じ場合はインスタンスサイズが大きいレプリカ
3. 優先度とサイズが同じ場合はランダムに選択		 レプリカの昇格階層（Tier）を0（最優先）～15（最低優先）で指定可能。

昇格順序：
1. 優先度が高い（0に近い）リードレプリカ
2. 優先度が同じ場合はインスタンスサイズが大きいレプリカ
3. 優先度とサイズが同じ場合はランダムに選択		 レプリカの昇格階層（Tier）を0（最優先）～15（最低優先）で指定可能。

昇格順序：
1. 優先度が高い（0に近い）リードレプリカ
2. 優先度が同じ場合はインスタンスサイズが大きいレプリカ
3. 優先度とサイズが同じ場合はランダムに選択
フェイルオーバー時間 通常30秒以内
（リードレプリカが存在する場合）		 通常30秒以内
（リードレプリカが存在する場合）		 通常30秒以内
（リードレプリカが存在する場合）

エンドポイントと接続

比較項目 Amazon Aurora Amazon DocumentDB Amazon Neptune
エンドポイントタイプ 1. クラスターエンドポイント（プライマリへの読み書き）
2. リーダーエンドポイント（リードレプリカへの読み取り負荷分散）
3. インスタンスエンドポイント（特定インスタンスへの直接接続）
4. カスタムエンドポイント（任意のインスタンスグループへの接続）		 1. クラスターエンドポイント（プライマリへの読み書き）
2. リーダーエンドポイント（リードレプリカへの読み取り負荷分散）
3. インスタンスエンドポイント（特定インスタンスへの直接接続）		 1. クラスターエンドポイント（プライマリへの読み書き）
2. リーダーエンドポイント（リードレプリカへの読み取り負荷分散）
3. インスタンスエンドポイント（特定インスタンスへの直接接続）
4. カスタムエンドポイント（任意のインスタンスグループへの接続）
VPC必須設定 enableDnsHostnames：true
enableDnsSupport：true
（DNSホスト名解決のため必須）		 enableDnsHostnames：true
enableDnsSupport：true
（DNSホスト名解決のため必須）		 enableDnsHostnames：true
enableDnsSupport：true
（DNSホスト名解決のため必須）

セキュリティと暗号化

比較項目 Amazon Aurora Amazon DocumentDB Amazon Neptune
保管データの暗号化 AWS KMSを使用した暗号化
（クラスター作成時に設定、後から変更不可）		 AWS KMSを使用した暗号化
（クラスター作成時に設定、後から変更不可）		 AWS KMSを使用した暗号化
（クラスター作成時に設定、後から変更不可）
転送データの暗号化 TLS/SSL暗号化をサポート
パラメータグループで設定可能
（デフォルトで有効）		 TLS/SSL暗号化をサポート
パラメータグループで設定可能
（デフォルトで有効）		 TLS/SSL暗号化
（エンジンバージョン1.0.4.0以降は強制有効）
リソース管理の
アクセス制御		 AWS IAM（Identity and Access Management）
・IAMロール
・IAMユーザー
・IAMポリシー		 AWS IAM（Identity and Access Management）
・IAMロール
・IAMユーザー
・IAMポリシー		 AWS IAM（Identity and Access Management）
・IAMロール
・IAMユーザー
・IAMポリシー
ネットワークレベルの
アクセス制御		 ・VPCセキュリティグループ
・ネットワークACL（NACL）
・プライベートサブネット配置推奨		 ・VPCセキュリティグループ
・ネットワークACL（NACL）
・プライベートサブネット配置推奨		 ・VPCセキュリティグループ
・ネットワークACL（NACL）
・プライベートサブネット配置推奨
DB接続認証方式 1. ユーザー名とパスワード認証
2. IAMデータベース認証
（一時的な認証トークンを使用）		 ユーザー名とパスワード認証のみ
（MongoDB互換の認証機構）		 IAMデータベース認証
（一時的な認証トークンを使用、
パスワード認証は非サポート）
監査ログ機能 Amazon CloudWatch Logsへのエクスポート対応
パラメータグループで「server_audit_logging」を有効化
（接続、クエリ、テーブルアクセスなどを記録）		 Amazon CloudWatch Logsへのエクスポート対応
パラメータグループで「audit_logs」を有効化
（認証、承認、DDL、ユーザー管理などを記録）		 Amazon CloudWatch Logsへのエクスポート対応
パラメータグループで「neptune_enable_audit_log」を有効化
（すべてのデータベースリクエストを記録）

バックアップとリカバリ

比較項目 Amazon Aurora Amazon DocumentDB Amazon Neptune
自動バックアップ
保持期間		 1～35日間
（デフォルト：1日）
0日に設定すると自動バックアップ無効		 1～35日間
（デフォルト：1日）
0日に設定すると自動バックアップ無効		 1～35日間
（デフォルト：1日）
0日に設定すると自動バックアップ無効
バックアップ方式 1. 自動バックアップ
・スナップショット（日次）
・トランザクションログ（継続的）
2. 手動スナップショット
・任意のタイミングで作成可能
・保持期限なし		 1. 自動バックアップ
・スナップショット（日次）
・トランザクションログ（継続的）
2. 手動スナップショット
・任意のタイミングで作成可能
・保持期限なし		 1. 自動バックアップ
・スナップショット（日次）
・トランザクションログ（継続的）
2. 手動スナップショット
・任意のタイミングで作成可能
・保持期限なし
ポイントインタイム
リカバリ（PITR）		 自動バックアップ保持期間内の
任意の時点（秒単位）に復元可能
※最新の復元可能時刻から5分前まで		 自動バックアップ保持期間内の
任意の時点（秒単位）に復元可能
※最新の復元可能時刻から5分前まで		 自動バックアップ保持期間内の
任意の時点（秒単位）に復元可能
※最新の復元可能時刻から5分前まで
バックアップウィンドウ リージョンごとの8時間ブロック内でランダムな30分間が自動割り当て
任意の時間帯に変更可能

影響：
・シングルAZ：数秒間のI/O中断
・マルチAZ：数分間のレイテンシー上昇		 リージョンごとの8時間ブロック内でランダムな30分間が自動割り当て
任意の時間帯に変更可能

影響：
・シングルAZ：数秒間のI/O中断
・マルチAZ：数分間のレイテンシー上昇		 リージョンごとの8時間ブロック内でランダムな30分間が自動割り当て
任意の時間帯に変更可能

影響：
・シングルAZ：数秒間のI/O中断
・マルチAZ：数分間のレイテンシー上昇
スナップショットの
共有とコピー		 手動スナップショット：
・リージョン間コピー可能
・AWSアカウント間共有可能

自動スナップショット：
・手動スナップショットにコピー後に共有可能

暗号化スナップショット：
・カスタムKMSキー使用時は共有先に権限付与が必要
・デフォルトKMSキー使用時はカスタムKMSキーで再暗号化が必要		 手動スナップショット：
・リージョン間コピー可能
・AWSアカウント間共有可能

自動スナップショット：
・手動スナップショットにコピー後に共有可能

暗号化スナップショット：
・カスタムKMSキー使用時は共有先に権限付与が必要
・デフォルトKMSキー使用時はカスタムKMSキーで再暗号化が必要		 手動スナップショット：
・リージョン間コピー可能
・AWSアカウント間共有可能

自動スナップショット：
・手動スナップショットにコピー後に共有可能

暗号化スナップショット：
・カスタムKMSキー使用時は共有先に権限付与が必要
・デフォルトKMSキー使用時はカスタムKMSキーで再暗号化が必要

運用とメンテナンス

比較項目 Amazon Aurora Amazon DocumentDB Amazon Neptune
メンテナンス
ウィンドウ		 リージョンごとの8時間ブロック内でランダムな30分間が自動割り当て
曜日・時間帯を任意に変更可能
この時間帯に必要なパッチやアップグレードが自動適用される		 リージョンごとの8時間ブロック内でランダムな30分間が自動割り当て
曜日・時間帯を任意に変更可能
この時間帯に必要なパッチやアップグレードが自動適用される		 リージョンごとの8時間ブロック内でランダムな30分間が自動割り当て
曜日・時間帯を任意に変更可能
この時間帯に必要なパッチやアップグレードが自動適用される
課金体系 1. DBインスタンス時間（インスタンスクラスごと）
2. ストレージ容量（GB/月）
3. バックアップストレージ（DB容量超過分）
4. データ転送（リージョン間・インターネット）
5. I/O操作（Auroraのみ、I/O最適化を選択しない場合）		 1. DBインスタンス時間（インスタンスクラスごと）
2. ストレージ容量（GB/月）
3. バックアップストレージ（DB容量超過分）
4. データ転送（リージョン間・インターネット）		 1. DBインスタンス時間（インスタンスクラスごと）
2. ストレージ容量（GB/月）
3. バックアップストレージ（DB容量超過分）
4. データ転送（リージョン間・インターネット）

高度な機能とデータ連携

比較項目 Amazon Aurora Amazon DocumentDB Amazon Neptune
データ変更ストリーム データベースアクティビティストリーム
・データベース変更イベントをAmazon Kinesis Data Streamsにリアルタイムプッシュ
・重複なし、順序保証
・監査、分析、アプリケーション連携に利用可能		 変更ストリーム（Change Streams）
・データベース変更イベントをクラスター内に7日間保持
・重複なし、順序保証
・プライマリインスタンスからのみ取得可能
・MongoDB Change Streams APIで利用		 Neptuneストリーム
・グラフ変更イベントをクラスター内に7日間保持
・重複なし、順序保証
・プライマリおよびリードレプリカから取得可能
・HTTP APIで利用
イベント通知 Amazon SNS連携
・クラスターイベント
・インスタンスイベント
・パラメータグループイベント
・セキュリティグループイベント
をリアルタイムに通知		 機能なし
（CloudWatch Eventsを
利用した代替手段が必要）		 Amazon SNS連携
・クラスターイベント
・インスタンスイベント
・パラメータグループイベント
・セキュリティグループイベント
をリアルタイムに通知
Performance Insights 対応
・データベース負荷を視覚化
・待機イベント別の分析
・SQLクエリ、ホスト、ユーザー別の詳細分析
・最大2年間のパフォーマンス履歴保持		 非対応
（CloudWatch メトリクスと
プロファイラーで代替）		 非対応
（CloudWatch メトリクスで代替）
プロファイラー Performance Insightsに統合 対応
・遅いクエリの実行時間と詳細ログをCloudWatch Logsに記録
・しきい値を超えたクエリを自動記録
・パフォーマンスチューニングに活用		 非対応
（監査ログとCloudWatch
メトリクスで代替）

Aurora専用の高度な機能

機能 説明 DocumentDB/Neptune
バックトラック 同じDBクラスター内のデータを指定時間まで数分で巻き戻す機能
・新しいクラスター作成不要
・最大72時間前まで巻き戻し可能
・論理エラーからの迅速な復旧に有効		 非対応
クローン機能 DBクラスターをダウンタイムなしで高速クローン作成
・コピーオンライト技術を使用
・初期ストレージコストがほぼゼロ
・開発・テスト環境の構築に最適		 非対応
Serverless オンデマンド自動スケーリング構成
・使用量に応じて自動的にキャパシティ調整
・ACU（Aurora Capacity Unit）単位の課金
・間欠的なワークロードに最適		 非対応
Global Database クロスリージョン配置のシングルマスター構成
・複数リージョンに読み取り専用レプリカを配置
・リージョン間レプリケーション遅延1秒未満
・災害復旧とグローバル読み取りパフォーマンス向上に活用
・RPO（目標復旧時点）：1秒
・RTO（目標復旧時間）：1分未満		 非対応
Multi-Master 1つのリージョン内でマルチマスターデータベースを作成
・複数のインスタンスで読み書き可能
・高可用性とスケーラビリティを実現
・書き込み競合は自動解決
※MySQL互換のみサポート		 非対応
カスタムエンドポイント 任意のインスタンスグループへのカスタムエンドポイント作成
・特定のワークロード用インスタンスグループを定義
・分析クエリと運用クエリを分離
・きめ細かい負荷分散が可能		 Neptune：対応
DocumentDB：非対応

モニタリングメトリクス比較表

適切なインスタンスクラスを選択し、パフォーマンスを最適化するために、以下のメトリクスを定期的に監視することが重要です。特にBufferCacheHitRatio、CPUUtilization、FreeableMemoryは、インスタンスクラスのスケーリング判断に使用される主要な指標です。

パフォーマンス関連メトリクス

メトリクス名 説明と推奨される対応
BufferCacheHitRatio
（Aurora / DocumentDB / Neptune）		 バッファキャッシュヒット率（％）
・バッファキャッシュで処理されたリクエストの割合を示す
・理想値：99.9％以上

推奨対応：
キャッシュヒット率が99.9％未満で、かつクエリのレイテンシーが高い場合：
→ より大きいインスタンスクラスへのスケールアップを検討
→ メモリキャッシュの増加によりディスクI/O削減が期待できる
CPUUtilization
（Aurora / DocumentDB / Neptune）		 CPU使用率（％）
・DBインスタンスのCPU使用状況を示す
・警戒値：80％以上
・危険値：90％以上

推奨対応：
CPU使用率が継続的に80％を超える、または瞬間的に100％に達する場合：
→ より大きいインスタンスクラスへのスケールアップを検討
→ 読み取り負荷が高い場合はリードレプリカの追加も検討
→ クエリの最適化（インデックス追加など）も並行して実施
FreeableMemory
（Aurora / DocumentDB / Neptune）		 利用可能なメモリ容量（Bytes）
・DBインスタンスで使用可能な空きRAM容量

推奨対応：
利用可能なメモリが常に少ない（総メモリの10％未満など）場合：
→ より大きいインスタンスクラスへのスケールアップを検討
→ メモリ不足はバッファキャッシュヒット率の低下やスワップの原因となる
DatabaseConnections
（Aurora / DocumentDB / Neptune）		 データベース接続数
・現在のデータベース接続数を示す
・各インスタンスクラスには最大接続数の制限がある

推奨対応：
最大接続数に近づいている場合：
→ 接続プーリングの実装を検討
→ より大きいインスタンスクラスへのスケールアップ（最大接続数が増加）
→ リードレプリカの追加による負荷分散

可用性・レプリケーション関連メトリクス

メトリクス名 説明と推奨される対応
AuroraReplicaLag（Aurora）
DBInstanceReplicaLag（DocumentDB）
ClusterReplicaLag（Neptune）		 リードレプリカのレプリケーション遅延（ミリ秒）
・プライマリインスタンスと特定のリードレプリカ間の遅延時間
・理想値：100ミリ秒未満
・警戒値：1000ミリ秒（1秒）以上

推奨対応：
レプリケーション遅延が大きい場合：
→ プライマリの負荷が高い可能性を調査
→ より大きいインスタンスクラスへのスケールアップを検討
→ 大量の書き込みトランザクションの最適化
AuroraReplicaLagMaximum（Aurora）
DBClusterReplicaLagMaximum（DocumentDB）
ClusterReplicaLagMaximum（Neptune）		 最大レプリケーション遅延（ミリ秒）
・プライマリと全リードレプリカ間の最大遅延時間
・クラスター全体のレプリケーション健全性を示す指標

推奨対応：
特定のレプリカの遅延が他より大きい場合：
→ 当該レプリカのリソース使用状況を確認
→ 必要に応じて再作成を検討
AuroraReplicaLagMinimum（Aurora）
DBClusterReplicaLagMinimum（DocumentDB）
ClusterReplicaLagMinimum（Neptune）		 最小レプリケーション遅延（ミリ秒）
・プライマリと全リードレプリカ間の最小遅延時間
・最良のレプリカのパフォーマンスを示す

活用方法：
最小値と最大値の差が大きい場合、レプリカ間のパフォーマンスにばらつきがあることを示す
EngineUptime
（Aurora / DocumentDB / Neptune）		 エンジン稼働時間（秒）
・インスタンスが起動してからの経過時間
・値がリセットされた場合は再起動が発生したことを示す

活用方法：
予期しない再起動の検知に使用
計画的なメンテナンスとの区別が重要

ストレージ関連メトリクス

メトリクス名 説明と推奨される対応
VolumeBytesUsed
（Aurora / DocumentDB / Neptune）		 使用中のストレージ容量（Bytes）
・DBクラスターに割り当てられている実際のストレージ使用量
・自動的に拡張されるが上限に注意が必要

上限値：
・Aurora：128TiB
・DocumentDB / Neptune：64TiB

推奨対応：
・容量増加トレンドを定期的に確認
・上限の80％に達する前にデータアーカイブやパーティショニング戦略を検討
VolumeReadIOPs
（Aurora / DocumentDB / Neptune）		 ストレージ読み取りI/O操作数（回/秒）
・ストレージレイヤーでの読み取りI/O操作数
・キャッシュミスが多いと値が増加

推奨対応：
値が高い場合はBufferCacheHitRatioを確認し、
メモリ増強（インスタンスクラスのスケールアップ）を検討
VolumeWriteIOPs
（Aurora / DocumentDB / Neptune）		 ストレージ書き込みI/O操作数（回/秒）
・ストレージレイヤーでの書き込みI/O操作数
・書き込み負荷の指標

推奨対応：
値が高い場合は書き込みパターンの最適化やバッチ処理の検討

ネットワーク関連メトリクス

メトリクス名 説明
NetworkReceiveThroughput
（Aurora / DocumentDB / Neptune）		 ネットワーク受信スループット（Bytes/秒）
・DBインスタンスが受信しているネットワークトラフィック量
・クライアントからの受信データ量を示す
・インスタンスクラスごとにネットワーク帯域幅の上限がある
NetworkTransmitThroughput
（Aurora / DocumentDB / Neptune）		 ネットワーク送信スループット（Bytes/秒）
・DBインスタンスが送信しているネットワークトラフィック量
・クライアントへのデータ送信量を示す
・大量のデータ取得クエリで値が増加

モニタリングのベストプラクティス：
・CloudWatch Alarmsを設定して閾値超過時に自動通知
・Performance Insights（Aurora）を活用した詳細分析
・複数のメトリクスを組み合わせた総合的な判断が重要
・本番環境では少なくとも14日間のメトリクス履歴を保持することを推奨

設定変更の影響とタイミング

Amazon Aurora、Amazon DocumentDB、Amazon Neptuneでは、多くの設定変更が共通の挙動を示します。
変更を実行する際に「Apply Immediately（すぐに適用）」オプションを選択しない場合、一部の変更は次回のメンテナンスウィンドウまで保留されます。

メンテナンスウィンドウで適用される変更項目

以下の設定変更は、「Apply Immediately」を選択しない限り、メンテナンスウィンドウで適用されます：

  • クラスター識別子
  • マスターパスワード
  • IAM DB認証の有効化/無効化（DocumentDBは対象外）
  • インスタンス識別子
  • インスタンスクラス

上記以外の設定は、「Apply Immediately」の指定に関係なく即時適用されます。

クラスターレベルの変更

変更対象 ダウンタイム 影響と注意事項
クラスター識別子 なし ・エンドポイントURLが変更されるため、アプリケーションの接続文字列を更新する必要がある
・DNSの伝播に数分かかる場合がある
マスターパスワード なし ・既存の接続は維持される
・新しい接続には新しいパスワードが必要
・アプリケーションの接続情報を更新するまで接続エラーが発生する可能性
IAM DB認証
（DocumentDBは非対応）		 なし ・有効化/無効化が即座に反映される
・既存の接続には影響しない
・新しい接続から新しい認証方式が適用される
VPCセキュリティグループ なし ・即時適用（メンテナンスウィンドウ不要）
・変更後すぐにネットワークアクセス制御が更新される
・誤った設定は即座に接続不能を引き起こす可能性があるため注意
パラメータグループ パラメータによる ・パラメータグループの割り当て変更自体はダウンタイム不要
・ただし、パラメータ値の変更は手動再起動時にのみ反映される（フェイルオーバーでは反映されない）
・一部のパラメータは動的変更可能（パラメータごとに異なる）
・変更前にAWSドキュメントで再起動の必要性を確認すること
メンテナンスウィンドウ 条件付きであり ・メンテナンスウィンドウ時間帯の変更自体はダウンタイム不要
・重要：変更後の時間帯が現在時刻を含み、かつ保留中の変更アクション（インスタンスクラス変更など）がある場合、それらの変更が即座に適用され、ダウンタイムが発生する
・計画的なメンテナンス時間の変更には細心の注意が必要
バックアップ保持期間 なし ・即時適用（メンテナンスウィンドウ不要）
・保持期間を短縮すると古いバックアップが削除される
・0日に設定すると自動バックアップが無効化される（非推奨）
バックアップウィンドウ なし ・即時適用（メンテナンスウィンドウ不要）
・バックアップ実行中の変更は次回のバックアップから反映
・業務時間外に設定することを推奨
削除保護 なし ・即時適用（メンテナンスウィンドウ不要）
・有効化することで誤削除を防止できる
・本番環境では必ず有効化することを推奨

インスタンスレベルの変更

変更対象 ダウンタイム 影響と注意事項
インスタンス識別子 あり ・DBインスタンスの再起動が発生
・再起動中（通常数分間）はそのインスタンスが利用不可
・プライマリインスタンスの場合、書き込みが一時的に不可
・リードレプリカの場合、そのレプリカへの読み取りが一時的に不可
・インスタンスエンドポイントURLが変更されるため、アプリケーションの更新が必要
インスタンスクラス あり ・変更中はインスタンスが利用不可（通常数分～十数分）
・プライマリインスタンスの場合、書き込みが一時的に不可
・推奨手順（ダウンタイム最小化）：
　1. リードレプリカのインスタンスクラスを先に変更
　2. 新しいサイズのレプリカへフェイルオーバー
　3. 元のプライマリ（現レプリカ）のサイズを変更
・この手順により書き込み停止時間を30秒程度に短縮可能
昇格階層（Tier） なし ・即時適用（メンテナンスウィンドウ不要）
・フェイルオーバー時の昇格優先順位を制御
・本番用とレポート用でレプリカを分ける場合に有用
・値が小さいほど優先度が高い（0が最優先）

変更実行時のベストプラクティス

  • 本番環境での変更は必ず低トラフィック時間帯に実施
  • 「Apply Immediately」の使用は緊急時のみに限定し、通常はメンテナンスウィンドウで計画的に適用
  • 変更前にスナップショットを取得して、ロールバック手段を確保
  • 複数の変更は個別に実施し、問題発生時の原因特定を容易にする
  • ダウンタイムが発生する変更では、事前にアプリケーションの再接続ロジックをテスト
  • インスタンスクラス変更時は、リードレプリカ経由のフェイルオーバー戦略を活用してダウンタイムを最小化

重要：メンテナンスウィンドウの時間変更時は特に注意が必要です。現在時刻を含む新しい時間帯に変更し、かつ保留中のアクション（インスタンスクラス変更など）がある場合、それらが即座に適用され、予期しないダウンタイムが発生する可能性があります。

まとめ

本記事では、Amazon Aurora、Amazon DocumentDB、Amazon Neptuneの3つのデータベースサービスについて、クォーラムモデルを基盤とした共通点と各サービス固有の相違点を詳しく比較しました。

共通する主要な特徴

  • クォーラムベースのストレージレプリケーション：3つのAZに6コピー、書き込みクォーラム4/6、読み取りクォーラム3/6
  • クラスター構成：1つのプライマリと最大15個のリードレプリカ
  • 自動ストレージ拡張：10GB単位での自動拡張（AuroraのみPOG128TiB、他は64TiBまで）
  • 自動バックアップとポイントインタイムリカバリ：最大35日間の保持期間
  • 高度なセキュリティ機能：KMS暗号化、TLS/SSL通信、IAM統合

サービス選択の指針

Amazon Auroraを選択すべき場合：

  • MySQLまたはPostgreSQL互換のリレーショナルデータベースが必要
  • Global Database、Serverless、Multi-Master、バックトラックなどの高度な機能が必要
  • Performance Insightsによる詳細なパフォーマンス分析が必要
  • 最大128TiBのストレージ容量が必要

Amazon DocumentDBを選択すべき場合：

  • MongoDB互換のドキュメントデータベースが必要
  • JSONドキュメントの柔軟なスキーマ管理が必要
  • 既存のMongoDBアプリケーションをAWSに移行したい
  • 変更ストリーム機能とプロファイラーによるクエリ分析が必要

Amazon Neptuneを選択すべき場合：

  • グラフデータベースが必要（ソーシャルネットワーク、レコメンデーション、不正検知など）
  • Apache TinkerPop GremlinまたはW3C SPARQLクエリ言語のサポートが必要
  • 複雑な関係性データの高速トラバーサルが必要
  • IAMデータベース認証による強固なセキュリティが必要

注意事項：
記載されている情報は本記事執筆時点のものです。AWSは継続的にサービスを更新しているため、最新の機能や仕様については必ずAWS公式ドキュメントをご確認ください。また、本番環境への適用前には必ず十分なテストを実施することを推奨します。

Reference: Tech Blog citing related sources

Aurora,AWS,DocumentDB,Neptune

Posted by magtranetwork