RDS vs Aurora vs DynamoDB vs ElastiCache: AWSデータベースサービス選定ガイド

はじめに

データベースの選定は、アプリケーションのパフォーマンス、スケーラビリティ、コストに大きな影響を与えます。AWSは多様なデータベースサービスを提供していますが、それぞれに適した用途があります。

身近な例えで理解するデータベースサービス

• RDS = 普通のノート。整理して書けば検索しやすい。使い慣れた方法で管理できる（MySQL、PostgreSQL等）
• Aurora = 高性能な電子ノート。RDSと同じ使い方だが、速度と信頼性が段違い
• DynamoDB = 付箋紙の山。キーワードで一瞬で見つけられるが、複雑な検索には向かない
• ElastiCache = メモ帳。よく使う情報を手元に置いておくことで、ノートを開く手間を省く

各サービスの概要

RDS（Relational Database Service）

AWSのマネージドリレーショナルデータベースサービス。MySQL、PostgreSQL、MariaDB、Oracle、SQL Serverに対応。

特徴:

• 馴染みのあるRDBMSをそのまま使える
• バックアップ、パッチ適用、レプリカ作成が自動化
• Multi-AZ配置で高可用性を実現
• Read Replicaで読み取り性能を向上

Aurora

AWS独自のリレーショナルデータベースエンジン。MySQL/PostgreSQL互換。

特徴:

• 標準MySQLの最大5倍、PostgreSQLの最大3倍のスループット
• ストレージが自動で最大128TBまで拡張
• 6つのコピーを3つのAZに自動分散
• Aurora Serverless v2で自動スケーリング対応
• Global Databaseでクロスリージョンレプリケーション

DynamoDB

フルマネージドのNoSQLデータベースサービス。キーバリュー型/ドキュメント型。

特徴:

• ミリ秒以下のレスポンス（一桁ミリ秒）
• 事実上無制限のスケーラビリティ
• サーバーレス（テーブル作成のみでインフラ管理不要）
• オンデマンドキャパシティモードとプロビジョニングモードを選択可能
• DynamoDB Streams でリアルタイムのデータ変更を検知

ElastiCache

インメモリデータストアのマネージドサービス。RedisとMemcachedに対応。

特徴:

• マイクロ秒レベルのレスポンス
• セッション管理、キャッシュ、リアルタイムランキングに最適
• Redis: データ永続化、Pub/Sub、クラスター対応
• Memcached: シンプルなキャッシュに特化

比較表

基本機能

料金比較

月額概算（東京リージョン、小規模構成）:

料金の仕組み

データモデルの違い

リレーショナル（RDS/Aurora）

テーブル間のリレーションシップを定義し、SQLでJOINして複雑なクエリを実行できる。

[ユーザーテーブル]          [注文テーブル]           [商品テーブル]
| id | name   |          | id | user_id | product_id |    | id | name  | price |
|----|--------|          |----|---------|------------|    |----|-------|-------|
| 1  | 田中   |          | 1  | 1       | 2          |    | 1  | 商品A | 1000  |
| 2  | 鈴木   |          | 2  | 1       | 1          |    | 2  | 商品B | 2000  |
                          | 3  | 2       | 1          |

-- 田中さんの注文一覧を取得
SELECT u.name, p.name, p.price
FROM users u
JOIN orders o ON u.id = o.user_id
JOIN products p ON o.product_id = p.id
WHERE u.name = '田中';

NoSQL（DynamoDB）

1つのテーブルにデータを非正規化して格納し、パーティションキーとソートキーで高速にアクセス。

[注文テーブル（単一テーブル設計）]
| PK      | SK            | name | product | price |
|---------|---------------|------|---------|-------|
| USER#1  | PROFILE       | 田中  |         |       |
| USER#1  | ORDER#1       |      | 商品B   | 2000  |
| USER#1  | ORDER#2       |      | 商品A   | 1000  |
| USER#2  | PROFILE       | 鈴木  |         |       |
| USER#2  | ORDER#3       |      | 商品A   | 1000  |

-- 田中さんの注文一覧を取得（PK=USER#1, SKが"ORDER#"で始まるもの）

判断フローチャート

[データベースサービス選定]
    |
    v
[複雑なクエリやJOINが必要?]
    |
    +-- はい --> [高いパフォーマンス/可用性が必要?]
    |               |
    |               +-- はい --> Aurora
    |               |           （MySQL/PostgreSQL互換で高性能）
    |               |
    |               +-- いいえ --> RDS
    |                              （コスト重視の場合）
    |
    +-- いいえ
         |
         v
    [ミリ秒以下のレスポンスが必要?]
         |
         +-- はい --> [データの永続化が必要?]
         |               |
         |               +-- はい --> DynamoDB + DAX
         |               |           （DAX: DynamoDB用インメモリキャッシュ）
         |               |
         |               +-- いいえ --> ElastiCache
         |                              （セッション、キャッシュ、リアルタイム処理）
         |
         +-- いいえ
              |
              v
         [アクセスパターンが予測可能?]
              |
              +-- はい --> DynamoDB
              |           （Key-Valueアクセスで十分な場合）
              |
              +-- いいえ --> Aurora or RDS
                            （柔軟なクエリが必要な場合）

ユースケース別の推奨

Webアプリケーション（一般的なCRUD）

IoTデータ収集

推奨: DynamoDB

• 大量の書き込みに強い
• スキーマレスでデバイスごとに異なるデータ構造に対応
• 自動スケーリングで突発的な負荷に対応

リアルタイムランキング

推奨: ElastiCache（Redis）

• Sorted Setを使ったランキング機能
• マイクロ秒レベルのレスポンス
• リアルタイム更新

ECサイト

推奨: Aurora + ElastiCache + DynamoDB

• Aurora: 商品カタログ、注文管理（複雑なクエリ対応）
• ElastiCache: セッション管理、商品情報キャッシュ
• DynamoDB: カート情報、ユーザーアクティビティログ

RDS vs Aurora の詳細比較

Aurora を選ぶべきケース:

結論: 本番環境で可用性とパフォーマンスを重視するならAurora、開発環境やコスト重視ならRDS。

DynamoDB設計のポイント

DynamoDBは設計思想がRDBとは大きく異なる。

単一テーブル設計（Single Table Design）

DynamoDBでは、複数のエンティティを1つのテーブルに格納する「単一テーブル設計」が推奨される。

利点:

• JOINの代わりに1回のクエリで関連データを取得
• テーブル管理が簡単
• コスト効率が良い

欠点:

• 設計が複雑
• アクセスパターンを事前に確定する必要がある
• 後からアクセスパターンを追加するのが難しい

アクセスパターンの重要性

DynamoDBでは、テーブル設計の前にアクセスパターン（どんなクエリを実行するか）を全て洗い出す必要がある。

ElastiCacheの使いどころ

Redis vs Memcached

ほとんどのケースでRedisが推奨される。Memcachedは純粋なキャッシュ用途でマルチスレッドの性能が必要な場合にのみ選択する。

キャッシュ戦略

実際の構成例

スタートアップ（コスト最小化）

[Web App] --> [RDS db.t3.micro (PostgreSQL)]
              ストレージ: 20GB
              月額: 約$15

成長期（パフォーマンス重視）

[Web App] --> [ElastiCache (Redis)]
              （キャッシュヒット時はここで返す）
                   |
                   | キャッシュミス
                   v
              [Aurora PostgreSQL]
              （Read Replica x 2）
              月額: 約$300-500

大規模サービス

[Web App] --> [ElastiCache Cluster (Redis)]
                   |
          +--------+--------+
          |                 |
    [Aurora Global]   [DynamoDB]
    （商品/注文管理）  （セッション/ログ）
          |
    [Read Replica x 5]
    月額: $1,000+

まとめ

データベース選定で最も重要なのは、「データの特性」と「アクセスパターン」を正確に理解すること。RDBで始めて、ボトルネックが見えてからNoSQLやキャッシュを追加するのが、多くのプロジェクトにとって現実的なアプローチである。

参考リンク

• AWS RDS公式ドキュメント
• Amazon Aurora公式ドキュメント
• Amazon DynamoDB公式ドキュメント
• Amazon ElastiCache公式ドキュメント
• DynamoDB単一テーブル設計ガイド