導入
ここまでいくつものデータベースサービスが出てきました。「結局どれをいつ使うのか」を一枚の地図として整理しておきましょう。
説明
AWSの主なデータベースサービスと、その用途を対応させると次のようになります。
| 用途 | サービス | ひとこと |
|---|---|---|
| リレーショナル（表・SQL） | RDS / Aurora | 複雑な関係性を扱う業務データの基本形 |
| キーバリュー・NoSQL | DynamoDB | 超高速・大量アクセス・柔軟なスキーマ |
| インメモリキャッシュ | ElastiCache | データベース手前で応答を高速化（Redis/Memcached） |
| 分析・データウェアハウス | Redshift | 大量データの集計・BI分析（OLAP） |
| グラフ | Neptune | 「誰が誰とつながっているか」のような関係性データ（SNS・レコメンド） |
| データベース移行 | AWS DMS（Database Migration Service） | オンプレミスのDBをAWSへ、ダウンタイムを抑えて移行する |
flowchart TD
Q["どんなデータを扱いたいか"] --> Q1{"複雑な関係を\nSQLで扱いたい？"}
Q1 -->|はい| RDS["RDS / Aurora"]
Q1 -->|いいえ| Q2{"超高速・大量・\n柔軟な形式？"}
Q2 -->|はい| DDB["DynamoDB"]
Q2 -->|いいえ| Q3{"つながり・関係性が主役？"}
Q3 -->|はい| Nep["Neptune"]
Q3 -->|いいえ| Q4{"集計・分析が主目的？"}
Q4 -->|はい| Red["Redshift"]
CLF試験では、シナリオ文（「◯◯なアプリを作りたい、どのデータベースが適切か」）から、この対応表を逆引きして答える形式の問題がよく出ます。サービス名を単独で覚えるより、「用途→サービス」の対応で覚えるほうが実戦的です。
具体例
驚くことに、1つの通販アプリの中で、これらのデータベースが役割分担して共存します。
| アプリの機能 | 選ぶデータベース | 理由 |
|---|---|---|
| 注文・在庫・会計 | RDS / Aurora | 複数の表をJOINする複雑な関係。SQLの整合性が要る |
| ショッピングカート | DynamoDB | 一人ひとりのカートを超高速・大量に読み書き |
| 人気商品ランキングの表示 | ElastiCache | 同じ結果を何度も返すのでキャッシュで高速化 |
| 3年分の売上を分析 | Redshift | 大量データの集計・BI分析（OLAP） |
| 「この商品を買った人はこれも」 | Neptune | 商品と購入者の“つながり”をたどるレコメンド |
| 旧オンプレDBからの移行 | AWS DMS | ダウンタイムを抑えてクラウドへ移す |
「万能な1つ」を探すのではなく、機能ごとに一番得意なDBへ振り分けるのが現代的な設計です。試験のシナリオ問題も、まさにこの「用途→サービス」の逆引きを問うています。
読んでみよう
迷ったら「関係性が複雑ならRDS/Aurora、速さと規模ならDynamoDB、分析ならRedshift」という3択にまず絞り込むと、試験本番でも判断しやすくなります。