AWS Service Comparison Matrix (Database)¶
データベースサービスの選定判断材料。RDS、DynamoDB、ElastiCache、DWH/分析基盤等を比較する。
History¶
| 日付 | 内容 |
|---|---|
| 2026-05-28 | 初版作成 |
| 2026-10-10 | 初版から更新なし。AWS公式ドキュメント・サービス仕様との整合を再確認する必要あり（要レビュー、#911） |
RDB: RDS vs Aurora vs Aurora Serverless v2¶
| 比較項目 | RDS | Aurora | Aurora Serverless v2 |
|---|---|---|---|
| ドキュメント | RDS | Aurora | Aurora Serverless v2 |
| 課金モデル | インスタンス時間 + ストレージ (料金) | インスタンス時間 + I/O + ストレージ (料金) | ACU 秒 + I/O + ストレージ (料金) |
| 主用途 | 標準的な RDB ワークロード | 高性能・高可用性が必要な RDB | 可変負荷の RDB ワークロード |
| SLA | 99.95% (Multi-AZ) | 99.99% | 99.99% |
| 学習コスト | 低い | 低い (RDS 互換) | 低い (Aurora 互換) |
| スケーリング | 手動インスタンス変更 | リードレプリカ Auto Scaling | ACU 自動スケール (0.5〜128) |
| 主要サービス制限 | ストレージ 64TB、インスタンス 40/リージョン (Quotas) | ストレージ 128TB、レプリカ 15、接続数はインスタンスクラス依存 (Quotas) | ストレージ 128TB、ACU 0.5-128、接続数は ACU 依存 (Quotas) |
| コスト (常時高負荷) | 安い (RI 適用) | 中程度 (RI 適用) | 高い |
| コスト (バースト) | 高い (ピークに合わせたサイジング) | 高い | 安い (使った分だけ) |
| 対応エンジン | MySQL, PostgreSQL, MariaDB, Oracle, SQL Server | MySQL 互換, PostgreSQL 互換 | MySQL 互換, PostgreSQL 互換 |
| ストレージ上限 | 64 TB (gp3) | 128 TB (自動拡張) | 128 TB (自動拡張) |
| レプリカ | 最大 15 (リードレプリカ) | 最大 15 (同一ストレージ共有) | 最大 15 (同一ストレージ共有) |
| フェイルオーバー時間 | 60-120 秒 | 30 秒以下 | 30 秒以下 |
| マルチ AZ | ✅ (スタンバイレプリカ) | ✅ (3 AZ に 6 コピー自動) | ✅ (3 AZ に 6 コピー自動) |
| ゼロスケール | ❌ | ❌ | ✅ (最小 0.5 ACU) |
| Global Database | ❌ | ✅ | ✅ |
| Terraform 対応 | ✅ | ✅ | ✅ |
Guidelines¶
→ Aurora を標準採用する。 ストレージの自動拡張、高速フェイルオーバー、リードレプリカの容易な追加で運用負荷が低い。
- 開発環境や負荷が不定期なワークロードは Aurora Serverless v2 を検討 (コスト最適化)
- Oracle / SQL Server が必須の場合は RDS を採用
- 小規模で Aurora のコストが過剰な場合は RDS (db.t4g クラス) を検討
- I/O 課金が高額になるワークロード (大量書き込み) は Aurora I/O-Optimized を検討
NoSQL: DynamoDB vs DocumentDB vs ElastiCache¶
| 比較項目 | DynamoDB | DocumentDB | ElastiCache (Redis) |
|---|---|---|---|
| ドキュメント | DynamoDB | DocumentDB | ElastiCache |
| 課金モデル | RCU/WCU or リクエスト従量 (料金) | インスタンス時間 + I/O (料金) | ノード時間 (料金) |
| 主用途 | 高スループット KV アクセス、シンプルなクエリ | MongoDB 互換が必要なドキュメント DB | キャッシュ、セッション、リアルタイム処理 |
| SLA | 99.999% (Global Tables) / 99.99% (Standard) | 99.99% | 99.99% |
| 学習コスト | 中程度 (データモデリング独特) | 低い (MongoDB 経験者) | 低い (Redis 経験者) |
| スケーリング | 自動 (オンデマンド) / 手動 (プロビジョン) | インスタンス追加 | ノード追加 / シャーディング |
| 主要サービス制限 | アイテム 400KB、トランザクション 25 アイテム/100 アイテム、パーティション 3000 RCU/1000 WCU (Quotas) | ドキュメント 16MB、インスタンス数 16/クラスター (Quotas) | ノードメモリ依存、シャード数 500 (Quotas) |
| コスト (常時高負荷) | 中程度 (プロビジョンモード) | 中程度 | 中程度 |
| コスト (バースト) | 安い (オンデマンドモード) | 高い (インスタンス常時課金) | 高い (ノード常時課金) |
| データモデル | Key-Value + ドキュメント | JSON ドキュメント | Key-Value + データ構造 |
| クエリ柔軟性 | 低い (PK/SK + GSI/LSI) | 高い (MongoDB クエリ構文) | 低い (キーベース) |
| レイテンシ | 1 桁 ms | 1 桁 ms | サブ ms |
| ストレージ上限 | 実質無制限 | 128 TB | ノードメモリ依存 |
| トランザクション | ✅ (25 アイテムまで) | ✅ | ✅ (Redis 7.0+) |
| TTL | ✅ | ✅ | ✅ |
| Global 展開 | ✅ Global Tables | ✅ Global Clusters | ✅ Global Datastore |
| VPC 内配置 | ⚠️ (VPC Endpoint 経由) | ✅ (VPC 内のみ) | ✅ (VPC 内のみ) |
| Terraform 対応 | ✅ | ✅ | ✅ |
Guidelines¶
→ DynamoDB をデフォルト NoSQL として採用する。 サーバーレス運用でスケーリング管理が不要、オンデマンドモードで小規模から大規模まで対応できる。
- MongoDB 互換 API が必須 (既存アプリ移行) の場合は DocumentDB を検討
- サブ ms レイテンシが必要なキャッシュ・セッション管理は ElastiCache を採用
- DynamoDB のクエリ制約 (複雑な検索、集計) が問題になる場合は Aurora を検討
- DynamoDB + ElastiCache の併用パターン: 読み取り頻度が極めて高いホットキーがある場合
Cache: ElastiCache Redis vs ElastiCache Memcached vs DAX¶
| 比較項目 | ElastiCache Redis | ElastiCache Memcached | DAX |
|---|---|---|---|
| ドキュメント | Redis | Memcached | DAX |
| 課金モデル | ノード時間 (料金) | ノード時間 (料金) | ノード時間 (料金) |
| 主用途 | 汎用キャッシュ、セッション、Pub/Sub、ランキング | シンプルなキャッシュ | DynamoDB 読み取りキャッシュ |
| SLA | 99.99% | 99.99% | 99.99% |
| 学習コスト | 低い (Redis 経験者) | 非常に低い | 非常に低い (SDK 差し替えのみ) |
| スケーリング | シャーディング + レプリカ追加 | ノード追加 | ノード追加 (最大 10) |
| 主要サービス制限 | シャード 500、レプリカ 5/シャード、接続数ノードタイプ依存 (Quotas) | ノード 300/クラスター (Quotas) | ノード 10、アイテムキャッシュ 10 分 TTL (Quotas) |
| コスト (常時高負荷) | 中程度 | 安い | 中程度 |
| コスト (バースト) | 高い (ノード常時課金) | 高い (ノード常時課金) | 高い (ノード常時課金) |
| データ構造 | String, Hash, List, Set, Sorted Set, Stream | String のみ | DynamoDB 互換 |
| 永続化 | ✅ (RDB/AOF) | ❌ | ❌ (キャッシュのみ) |
| レプリケーション | ✅ (最大 5 レプリカ/シャード) | ❌ | ✅ (最大 10 レプリカ) |
| フェイルオーバー | ✅ 自動 | ❌ (クライアント側で対応) | ✅ 自動 |
| マルチ AZ | ✅ | ⚠️ (AZ 分散配置のみ) | ✅ |
| Pub/Sub | ✅ | ❌ | ❌ |
| Lua スクリプト | ✅ | ❌ | ❌ |
| API 互換性 | Redis API | Memcached API | DynamoDB API (透過的) |
Guidelines¶
→ ElastiCache Redis を汎用キャッシュとして採用する。 データ構造の豊富さ、永続化、レプリケーション、Pub/Sub を備え、キャッシュ以外の用途にも対応できる。
- DynamoDB の読み取りレイテンシ改善が目的で、アプリケーション変更を最小化したい場合は DAX を検討
- 単純な KV キャッシュのみで永続化・レプリケーション不要な場合は Memcached を検討 (コスト面で有利な場合がある)
- Redis のメモリコストが問題になる場合は ElastiCache Serverless (Redis) を検討
DWH / Analytics: Redshift vs Athena vs S3 + Glue¶
| 比較項目 | Redshift | Athena | S3 + Glue (データレイク) |
|---|---|---|---|
| ドキュメント | Redshift | Athena | Glue |
| 課金モデル | ノード時間 or RPU 秒 (Serverless) (料金) | スキャンデータ量 \$5/TB (料金) | Glue ETL: DPU 時間 + S3 ストレージ (料金) |
| 主用途 | 大規模 DWH、複雑な分析クエリ、BI 連携 | アドホッククエリ、ログ分析、S3 データ探索 | ETL パイプライン、データカタログ、データレイク構築 |
| SLA | 99.99% | 99.99% | 99.99% (S3) / 99.9% (Glue) |
| 学習コスト | 中程度 (PostgreSQL 互換 SQL) | 低い (標準 SQL / Presto) | 高い (Spark/Python + カタログ設計) |
| スケーリング | ノード追加 or Serverless 自動スケール | 自動 (クエリ単位) | DPU 自動スケール (Glue 4.0+) |
| 主要サービス制限 | ノード 128/クラスター、同時クエリ 50 (WLM 依存) (Quotas) | クエリ結果 2GB、同時クエリ 25-150 (DML)、スキャンデータ無制限 (Quotas) | DPU 最大 100 (デフォルト)、ジョブ同時実行数制限あり (Quotas) |
| コスト (常時高負荷) | 安い (RI 適用、大量データ常時クエリ) | 高い (スキャン量課金) | 中程度 (DPU 時間) |
| コスト (バースト) | 高い (クラスター常時課金) ※Serverless なら中程度 | 安い (使った分だけ) | 安い (ジョブ実行時のみ) |
| クエリエンジン | 独自 (PostgreSQL 互換、列指向) | Trino (Presto 後継) | Apache Spark |
| データ格納先 | 独自マネージドストレージ + S3 (Spectrum) | S3 (直接クエリ) | S3 |
| データ形式 | 独自形式 (COPY でロード) | Parquet, ORC, CSV, JSON, Avro 等 | 任意 (ETL で変換) |
| 同時実行性 | 高い (WLM / Concurrency Scaling) | 中程度 (アカウント上限あり) | ジョブ単位 (並列実行可) |
| レイテンシ | 秒〜分 (事前ロード済みデータ) | 秒〜分 (スキャン量依存) | 分〜時間 (バッチ ETL) |
| リアルタイム取り込み | ✅ (Streaming Ingestion from Kinesis/MSK) | ❌ (S3 に書き込み後クエリ) | ⚠️ (Glue Streaming ETL) |
| BI ツール連携 | ✅ (QuickSight, Tableau, JDBC/ODBC) | ✅ (QuickSight, JDBC/ODBC) | ❌ (ETL 専用、クエリは Athena/Redshift 経由) |
| データカタログ | ⚠️ (Glue Data Catalog 連携) | ✅ (Glue Data Catalog 必須) | ✅ (Glue Data Catalog 中心) |
| ML 統合 | ✅ (Redshift ML → SageMaker) | ⚠️ (結果を S3 経由で SageMaker へ) | ✅ (Glue + SageMaker パイプライン) |
| Terraform 対応 | ✅ | ✅ | ✅ |
Guidelines¶
→ データ量・クエリ頻度・レイテンシ要件に応じて使い分ける。
- アドホッククエリ、ログ分析、低頻度の S3 データ探索 → Athena (初期コストゼロ、スキャン従量)
- 大量データの定常的な分析、BI ダッシュボード、複雑な JOIN → Redshift (Provisioned or Serverless)
- ETL パイプライン構築、データカタログ管理、データレイク基盤 → S3 + Glue
- Redshift Serverless は小〜中規模で RI コミットなしに始められるため、Provisioned の前に検討する
- Athena + Parquet (列指向) + パーティション設計でスキャン量を削減すれば、月数百 TB 規模でもコスト効率が高い
- 典型的な構成: S3 (データレイク) + Glue (ETL/カタログ) + Athena (アドホック) + Redshift (定常 BI) の併用