---
title: "AWSのDBサービス11種の選び方：用途別の比較表とCLIで作成して確かめる手順"
url: "https://www.issoh.co.jp/tech/details/17879/"
published: 2026-09-27
updated: 2026-09-27
categories: ["AWS"]
publisher: "株式会社一創"
---

# AWSのDBサービス11種の選び方：用途別の比較表とCLIで作成して確かめる手順

AWSのDB（データベース）サービスは、公式の選定ガイドが「15以上」と数えるほど種類があり、名前だけ見ても違いがつかみにくい状態です。この記事では、業務システムやWebサービスで候補に挙がる11サービスを、データモデルと用途で一枚の表に整理します。そのうえで、JOINとトランザクションの要否から始める選ぶ順番、AWS CLIで対応バージョンを確かめてRDSとDynamoDBを実際に作る手順、2025年7月に改定された無料枠での試し方までを順に解説します。

## まとめ：AWSのDBはJOINの要否で絞りRDSかDynamoDBから検証

業務データを表で持ち、JOINやトランザクションで整合性を守るなら、候補はRDSとAuroraの2つです。PostgreSQLかMySQLで足り、可用性の要求が「数分の停止なら許容」ならRDSから始めます。読み取りレプリカを複数台並べる、フェイルオーバーを数十秒に抑える、といった要件が出た時点でAuroraに移ります。

キーを指定した読み書きが大半で、アクセスパターンを事前に列挙できるならDynamoDBです。キャッシュはElastiCache、グラフや時系列などの特殊なデータモデルはNeptuneやTimestreamを追加で組み合わせます。どれを選ぶにしても、AWS CLIで対応版を確かめ、小さなインスタンスで作って壊す検証を先に済ませてください。Timestream for LiveAnalyticsとQLDBは新規案件の候補から外します。

## AWSのDBサービス11種をデータモデルと用途で整理した全体像

最初に地図を持っておくと、あとの選定が速くなります。AWSの公式ドキュメント[Choosing an AWS database service](https://docs.aws.amazon.com/decision-guides/latest/decision-guides/databases-on-aws-how-to-choose.html)（2026年6月2日更新）は、OLTP向けのデータベースを「リレーショナル」と「非リレーショナル」の2系統に分けています。

### リレーショナル系4サービスの用途・課金の違いと対応エンジンの一覧比較

選定ガイドによると、AWSのリレーショナル系は9つのエンジンを持ちます。Auroraの3種（PostgreSQL互換・MySQL互換・Aurora DSQL）と、RDSの6種（PostgreSQL・MySQL・MariaDB・SQL Server・Oracle・Db2）です。これに、月額固定のLightsailマネージドDBを加えた4つが業務DBの受け皿になります。

| サービス              | エンジン                 | 向く場面               | 課金の単位              |
| ----------------- | -------------------- | ------------------ | ------------------ |
| Amazon RDS        | 上記のRDS対応6エンジン        | 既存DBの移設、標準的な業務システム | インスタンス時間＋ストレージ     |
| Amazon Aurora     | PostgreSQL互換・MySQL互換 | 高い可用性と読み取り性能が要る本番  | インスタンス時間またはACU＋I/O |
| Aurora DSQL       | PostgreSQL互換（分散SQL）  | マルチリージョンで同時書き込み    | DPU（処理量）＋ストレージ     |
| Lightsail マネージドDB | MySQL・PostgreSQL     | 小規模サイトを月額固定で運用     | 月額の定額プラン           |

RDSとAuroraの違いは、ストレージの作りにあります。Auroraは3つのAZに複製する分散ストレージを持ち、その上にインスタンスを載せる構造です。詳しい仕組みは[Amazon RDSの対応エンジンと料金モデルを解説した記事](https://www.issoh.co.jp/tech/details/15426/)と[Auroraの仕組みとRDSとの違いを解説した記事](https://www.issoh.co.jp/tech/details/15447/)で扱っています。

### NoSQL系6サービスとデータモデルの対応を一覧表で確認する

非リレーショナル系は、データの形ごとに専用のサービスが用意されています。[AWS公式ホワイトペーパーのデータベース章](https://docs.aws.amazon.com/whitepapers/latest/aws-overview/database.html)の対応表を、実務でよく出る用途に置き換えると次のとおりです。

| データモデル       | サービス               | 典型的な用途                  |
| ------------ | ------------------ | ----------------------- |
| キーバリュー       | Amazon DynamoDB    | セッション、カート、IoTの受信データ     |
| インメモリ（キャッシュ） | Amazon ElastiCache | RDBの読み取り負荷の肩代わり         |
| インメモリ（永続）    | Amazon MemoryDB    | ランキングなどを主DBとして保持        |
| ドキュメント       | Amazon DocumentDB  | MongoDB互換のJSON格納、商品カタログ |
| グラフ          | Amazon Neptune     | 不正検知、レコメンド、ナレッジグラフ      |
| ワイドカラム       | Amazon Keyspaces   | Cassandraからの移行          |
| 時系列          | Amazon Timestream  | センサー値やアプリの計測値           |

新規案件で候補に挙がる頻度はDynamoDBとElastiCacheが突出して高く、残りの4つは特定のデータモデルが要件に出たときに初めて検討します。

### 分析用のRedshiftを業務DBと分けるOLTPとOLAPの線引き

11番目のRedshiftは、ほかの10種と役割が違います。選定ガイドは自らの対象をOLTP（日々の登録・更新処理）に限定し、大量データの集計・分析（OLAP）にはAmazon Redshiftを案内しています。

注文テーブルに月次集計を直接投げ続けると、業務の更新処理とI/Oを奪い合います。業務DBはRDSかAurora、集計はRedshiftに複製して行う分担が基本形です。両者の違いは[OLTPとOLAP・DWHの違いとAWSでのDB選定を比較した記事](https://www.issoh.co.jp/tech/details/9237/)で詳しく整理しています。

### 2025年以降に変わった3点：DSQLのGAと2サービスの受付終了

一覧記事の多くは次の3つの変化を反映しておらず、見落とすと候補の段階で手戻りが出ます。

1. Aurora DSQLは[2025年5月27日に一般提供](https://aws.amazon.com/about-aws/whats-new/2025/05/amazon-aurora-dsql-generally-available/)を開始しました。サーバーレスの分散SQLで、公式ではマルチリージョン構成の可用性を99.999%としています。
2. Timestream for LiveAnalyticsは、[公式の告知](https://docs.aws.amazon.com/timestream/latest/developerguide/AmazonTimestreamForLiveAnalytics-availability-change.html)で2025年6月20日から新規顧客を受け付けていません。新規はTimestream for InfluxDBが代替です。
3. 台帳データベースのQLDBは、[AWSの日本語ブログ](https://aws.amazon.com/jp/blogs/news/migration-from-amazon-qldb/)が示すとおり2025年7月31日にサポートを終えました。移行先はAurora PostgreSQLなどです。

Timestreamの2つのエンジンの違いは[Amazon Timestreamのエンジンと料金モデルを解説した記事](https://www.issoh.co.jp/tech/details/15453/)、QLDBからの移行は[QLDBのサービス終了と移行先を解説した記事](https://www.issoh.co.jp/tech/details/15451/)を参照してください。

## AWSでDBを選ぶ順番：JOINの要否・可用性・アクセスパターン

11種を横に並べて比べるより、質問を1つずつ当てて候補を減らすほうが早く決まります。重みの大きい順に4つの分岐を示します。

### 最初の分岐はJOINとトランザクションが必要かどうかで決める

受注と在庫、請求と入金のように、複数の表をまたいで同時に更新し、途中で失敗したら全部取り消したいデータがあるか。これが最初の質問です。答えが「ある」なら、リレーショナル系（RDS・Aurora・Aurora DSQL）から選びます。

DynamoDBにもトランザクションAPIはありますが、表の結合（JOIN）はできません。検索条件の多い管理画面や帳票の多い業務システムは、リレーショナル系のほうが実装も保守も素直です。

### RDSとAuroraの分かれ目は可用性の要件とレプリカの台数

リレーショナル系に決まったら、次は停止をどこまで許せるかです。RDSのMulti-AZ（インスタンスの配置）は待機系への切り替えで可用性を上げますが、この待機系は読み取りに使えません。Auroraは公式ホワイトペーパーの記載で読み取りレプリカを最大15台まで持て、障害時はレプリカを昇格させてフェイルオーバーします。

Oracle・SQL Server・Db2・MariaDBを使い続けるならRDS一択です。PostgreSQLかMySQLで、読み取りの多いWebサービスや停止の許容が短い本番ならAuroraを選びます。Oracleをそのまま持ち込む場合の選択肢とライセンスの数え方は、[AWSでOracle Databaseを動かす3つの選択肢を解説した記事](https://www.issoh.co.jp/tech/details/10885/)にまとめています。

複数リージョンで同時に書き込みたい、という要件が出たときだけAurora DSQLを検討します。PostgreSQLのすべての機能には対応していないため、採用前に[Aurora DSQLの非対応機能と採用可否の判断基準をまとめた記事](https://www.issoh.co.jp/tech/details/4487/)で確認してください。

### DynamoDBを選ぶ前にアクセスパターンを列挙できるか確かめる

DynamoDBは、パーティションキー（とソートキー）で引ける読み書きを高速にこなす代わりに、キー以外の条件での検索が苦手です。テーブルを作る前に「ユーザーIDで注文一覧を新しい順に取る」「注文IDで1件取る」のように、アプリが発行する問い合わせをすべて書き出せるかどうかが判断の分かれ目になります。

書き出せるならDynamoDBは有力で、オンデマンドモードならリクエスト数に応じた課金になります。キー設計の考え方とローカルでの試し方は[DynamoDBのキー設計と容量モード選定を解説した記事](https://www.issoh.co.jp/tech/details/17453/)で詳しく扱っています。

### キャッシュのElastiCacheと永続化のMemoryDBの使い分け

応答をマイクロ秒単位に縮めたいときに出てくるのがインメモリの2サービスです。選定ガイドは、ElastiCacheを「頻繁に読むデータの一時的なキャッシュ」、MemoryDBを「Multi-AZで永続化するインメモリの主DB」と位置づけています。

元データがRDSやDynamoDBにあり、消えても作り直せるならElastiCacheで足ります。ランキングやリアルタイムの在庫数のように、インメモリ上のデータそのものが正本になるならMemoryDBです。両者の料金差と選び方は[MemoryDBとElastiCacheの違いと選び方を解説した記事](https://www.issoh.co.jp/tech/details/3216/)で比較しています。

## AWS CLIでDBの対応版を調べてRDSとDynamoDBを作成する手順

候補が絞れたら、CLIで作って消すのが条件を正確に把握する近道です。手順はAWS CLI v2（2026年9月時点のリファレンスは2.37系）と東京リージョン（ap-northeast-1）を前提にしています。CLIの導入と認証がまだなら、[AWS CLI v2の設定とSSO認証の手順](https://www.issoh.co.jp/tech/details/17403/)を先に済ませてください。

### describe-db-engine-versionsで東京の既定版と対応版を確認

RDSで選べるエンジンの版はリージョンと時期で変わるため、記事や社内資料の版番号をそのまま信じず、その場で取得します。[describe-db-engine-versionsのリファレンス](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html)にある`--default-only`を付けると、新規作成時の既定版だけが返ります。

```
# RDS for PostgreSQL の既定版を取得する
aws rds describe-db-engine-versions --engine postgres \
  --default-only --region ap-northeast-1 \
  --query 'DBEngineVersions[0].[EngineVersion,DBParameterGroupFamily]' \
  --output text

# 選べる版をすべて並べる（MySQL の例）
aws rds describe-db-engine-versions --engine mysql \
  --region ap-northeast-1 \
  --query 'DBEngineVersions[].EngineVersion' --output text
```

1つ目の結果に出るパラメータグループのファミリー名は、パラメータグループを作るときに使います。移行の検証なら、既定版ではなく移行元に近い版を2つ目の一覧から選んでください。

### create-db-instanceでRDS for PostgreSQLを非公開で作成

次の手順は、検証用のRDSを1台作る作業です。[create-db-instanceのリファレンス](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)には、`--manage-master-user-password`を付けるとマスターパスワードをSecrets Managerで管理すると記載されています。パスワードをシェルの履歴に残さずに済むので、検証でもこの指定を使います。

```
aws rds create-db-instance \
  --db-instance-identifier lab-pg \
  --engine postgres \
  --db-instance-class db.t4g.micro \
  --allocated-storage 20 --storage-type gp3 \
  --master-username labadmin --manage-master-user-password \
  --no-publicly-accessible --backup-retention-period 1 \
  --region ap-northeast-1

# 作成完了まで待ち、接続先のエンドポイントを取得する
aws rds wait db-instance-available --db-instance-identifier lab-pg
aws rds describe-db-instances --db-instance-identifier lab-pg \
  --query 'DBInstances[0].[Endpoint.Address,MasterUserSecret.SecretArn]' \
  --output text
```

`--no-publicly-accessible`を指定しているため、接続は同じVPC内のEC2などから行います。パスワードは2行目に出るシークレットのARNから取り出し、[RDSとSecrets Managerによるパスワード管理の公式ページ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-secrets-manager.html)のとおり自動でローテーションされます。インスタンスクラスのdb.t4g.microは、後述する無料プランの対象です。

### DynamoDBのテーブルをオンデマンドで作成し読み書きを試す

DynamoDBはサーバーを持たないため、テーブルを作るだけで読み書きを始められます。[create-tableのリファレンス](https://docs.aws.amazon.com/cli/latest/reference/dynamodb/create-table.html)に従い、パーティションキーとソートキーを文字列で定義し、課金をオンデマンド（`PAY_PER_REQUEST`）にします。

```
aws dynamodb create-table --table-name LabOrders \
  --attribute-definitions AttributeName=pk,AttributeType=S \
                          AttributeName=sk,AttributeType=S \
  --key-schema AttributeName=pk,KeyType=HASH AttributeName=sk,KeyType=RANGE \
  --billing-mode PAY_PER_REQUEST --region ap-northeast-1

aws dynamodb wait table-exists --table-name LabOrders

# 1件書き込み、同じユーザーの注文をソートキーの降順で取得する
aws dynamodb put-item --table-name LabOrders \
  --item '{"pk":{"S":"USER#1001"},"sk":{"S":"ORDER#2026-09-27"},"total":{"N":"4800"}}'
aws dynamodb query --table-name LabOrders \
  --key-condition-expression "pk = :u" \
  --expression-attribute-values '{":u":{"S":"USER#1001"}}' \
  --no-scan-index-forward
```

続けて、`total`が4,000円以上の注文を全ユーザーから探す検索を試してください。キーに無い条件は`query`では書けず、テーブル全体を読む`scan`になります。オンデマンドとプロビジョンドの課金の違いは[DynamoDBのスループット容量の公式ページ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/capacity-mode.html)で確認できます。

### 検証後に削除して課金を止めるコマンドと削除後も残りやすいリソース

RDSはインスタンスが起動している限り時間課金が続きます。検証が終わったら、その日のうちに次のコマンドで消します。

```
aws rds delete-db-instance --db-instance-identifier lab-pg \
  --skip-final-snapshot --delete-automated-backups
aws dynamodb delete-table --table-name LabOrders

# 消し忘れの確認：手動スナップショットと残っているインスタンス
aws rds describe-db-snapshots --snapshot-type manual \
  --query 'DBSnapshots[].DBSnapshotIdentifier' --output text
aws rds describe-db-instances --query 'DBInstances[].DBInstanceIdentifier' \
  --output text
```

[delete-db-instanceのリファレンス](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-instance.html)のとおり、`--skip-final-snapshot`を付けない場合は最終スナップショットの名前が必須です。手動で取ったスナップショットはインスタンスを消しても残り、ストレージ料金がかかり続けます。削除の翌日に請求画面でRDSの項目が止まっているかを見て、残骸が無いことを確かめてください。

## AWSのDB費用と無料枠：2025年7月の改定後に小規模で試す方法

AWSの無料利用枠は、[2025年7月16日に発表された改定](https://aws.amazon.com/about-aws/whats-new/2025/07/aws-free-tier-credits-month-free-plan/)で仕組みが変わりました。「12か月無料」を前提にした古い解説のまま検証を始めると、アカウントが途中で閉じる、使えるはずの枠が無い、といった事態になります。

### 無料プランで使えるDBと30日・2か月・3か月の試用枠の違い

[AWSのデータベース無料枠の公式ページ](https://aws.amazon.com/free/database/)によると、DBごとに無料の形が異なります。2026年9月時点の記載を整理すると次のとおりです。

| サービス               | 無料の内容                    | 期間の扱い     |
| ------------------ | ------------------------ | --------- |
| Amazon RDS         | db.t3.micro・db.t4g.micro | Free plan |
| Amazon Aurora      | 最大4ACU・1GiB（詳細は表の下）      | Free plan |
| Amazon DynamoDB    | ストレージ25GB・25WCU・25RCU    | 常時無料      |
| DocumentDB・Neptune | t3.medium 750時間など        | 30日間      |
| Amazon MemoryDB    | t4g.small 750時間／月など      | 2か月間      |
| Amazon Keyspaces   | 読み書き各3,000万回／月・1GB       | 3か月間      |

表のRDS無料プランで対象となるエンジンは、MySQL・PostgreSQL・MariaDB・SQL Serverです。Auroraの欄は、PostgreSQLサーバーレスの最大4ACU・1GiBを指しています。

新規アカウントは最大200ドルのクレジットが付く無料プランと有料プランを選ぶ形式で、無料プランは6か月かクレジットを使い切った時点で終わります。社内のAWS Organizationsに参加させたアカウントは有料プラン扱いになるため、会社の検証環境で無料枠を当てにした見積もりはしないでください。

### 本番運用でDBの料金が跳ねる3要因：常時稼働・I/O・データ転送量

本番でDBの請求が想定を超えるときの原因は、ほぼ次の3つに集約されます。影響の大きい順に挙げます。

- 常時稼働：RDSとAuroraのプロビジョンド型はアクセスが無い夜間も時間課金されます。開発環境は夜間停止か従量型にします。
- I/O課金：Aurora Standardは100万リクエスト単位でI/O料金がかかり、I/Oが多いならI/O-Optimizedで総額が下がる場合があります。
- データ転送：別のAZやリージョン、インターネットへの転送はDB本体とは別に請求されます。

DynamoDBの請求はリクエスト数と項目サイズで決まるため、スキャンの多用が最大の落とし穴です。東京リージョンの実額での試算は[DynamoDBの料金を東京リージョンの実額で試算した記事](https://www.issoh.co.jp/tech/details/17798/)で確認できます。

## AWSのDB選定で起きる失敗パターンと業務要件から採用を見送る判断基準

選定の失敗は、サービスの性能ではなく、要件とデータモデルのずれから起きます。ここでは採用を見送るべき条件を言い切ります。

### DynamoDBをRDBの代わりに選び集計と検索条件の追加で詰まる

もっとも多いのは、「サーバーレスで安い」という理由だけで業務システムの主DBにDynamoDBを選び、運用開始後に検索条件や帳票が増えて行き詰まるケースです。キー以外の条件が増えるたびにグローバルセカンダリインデックスを足すか全件スキャンするしかありません。

管理画面の検索条件が5つ以上ある、月次の集計帳票がある、項目の追加が頻繁に見込まれる。このどれかに当てはまる業務システムでは、DynamoDBを主DBに採用しません。RDSかAuroraを主DBにし、アクセスが集中するセッションやログの受信部分だけDynamoDBに分けます。

### マネージドDBを見送りEC2に自前で構築すべき条件は限られる

選定ガイドはEC2にDBソフトウェアを入れて自分で運用する方法も挙げていますが、パッチ適用、バックアップ、容量計画、フェイルオーバーをすべて自前で持つことになります。EC2を選んでよいのは、ほぼ次の条件に限った場合です。RDSが対応していないエンジンや拡張機能が必須であるか、OSレベルの設定変更が要件に含まれることが、その条件に当たります。「マネージドより安そう」という理由だけで選ぶと、運用担当者の工数で差額が消えます。

### 複数DBの組み合わせと移行の設計を外部に任せる際の要件と判断の目安

選定ガイドは、ECサイトの例として、商品カタログをDocumentDB、閲覧時の低遅延をDynamoDB、在庫と注文をAuroraで持つ組み合わせを紹介しています。DBを増やすほど、データの同期、障害時の整合性、監視の手間が増えるため、2種類を超える構成は設計段階での検討が要ります。

オンプレミスのOracleやSQL ServerからAuroraへ乗り換える、複数DBにデータを分ける、といった案件は、スキーマ変換と差分同期、切り替え当日の停止時間の見積もりまで含めて計画が必要です。移行ツールの仕組みは[AWS DMSの同種・異種移行の使い分けを解説した記事](https://www.issoh.co.jp/tech/details/15785/)で確認できます。設計から移行までをまとめて任せたい場合は、[データベース設計・移行支援のサービス](https://www.issoh.co.jp/service/system/database/)に、移行元のDB製品と版、許容できる停止時間を伝えて相談すると、見積もりの前提がそろいます。

## よくある質問

AWSのDBを選ぶときに検索されることの多い疑問に、公式ドキュメントの記載をもとに答えます。

### AWSのDBサービスは全部でいくつありますか？

AWSの公式選定ガイドは「15以上」としています。業務システムやWebサービスで候補になるのは、RDS・Aurora・Aurora DSQL・DynamoDB・ElastiCache・MemoryDB・DocumentDB・Neptune・Keyspaces・Timestream・Redshiftの11種が中心です。QLDBは2025年7月31日に終了しており、Timestream for LiveAnalyticsは2025年6月20日以降の新規顧客は使えません。

### RDSとDynamoDBはどちらを選べばよいですか？

複数の表をJOINで結合したり、画面ごとに検索条件を変えたりするならRDSです。キーを指定した読み書きが大半で、アプリの問い合わせパターンを事前にすべて書き出せるならDynamoDBが向きます。迷う場合はRDSを主DBにし、アクセスが集中する一部の処理だけをDynamoDBに切り出す構成が安全です。

### AWSのDBは無料で使えますか？

DynamoDBはストレージ25GBと25WCU・25RCUが常時無料です。RDSはdb.t3.microとdb.t4g.micro、Auroraはサーバーレスで最大4ACUが無料プランの対象です。2025年7月16日の発表以降、新規アカウントは最大200ドルのクレジット制で、無料プランは6か月で終了します。

### AuroraはRDSと何が違うのですか？

AuroraはRDSの管理機能の上で動く、AWS独自のPostgreSQL・MySQL互換エンジンです。3つのAZに複製する分散ストレージを持ち、読み取りレプリカを最大15台まで追加できます。Oracle・SQL Server・Db2・MariaDBを使うならRDSを選びます。

### AWSのDBの対応バージョンはどこで確認できますか？

AWS CLIの`aws rds describe-db-engine-versions --engine postgres --default-only`で、リージョンごとの既定版を取得できます。`--default-only`を外すと選べる版が一覧で返ります。版の提供状況はリージョンと時期で変わるため、資料の記載ではなく、作成直前にコマンドで確かめてください。

## 関連記事

- [データベースとは？種類・DBMS・RDBとNoSQLの選び方を実装目線で解説](https://www.issoh.co.jp/tech/details/13012/)：AWSに限らないRDBとNoSQLの基礎と選び方を確認できる記事
- [Amazon RDSとは？仕組み・対応エンジンと料金モデル・採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15426/)：本記事で候補に挙げたRDSの仕組みと料金を深掘りした記事
- [Aurora（AWS）の構築手順：CLIでクラスター作成・接続・フェイルオーバー検証まで](https://www.issoh.co.jp/tech/details/17844/)：Auroraに決めたあとCLIで構築・検証する手順をまとめた記事
- [Amazon DynamoDBとは：機能の全体像からローカル起動・キー設計・容量モード選定まで](https://www.issoh.co.jp/tech/details/17453/)：DynamoDBのキー設計と容量モードを実装目線で扱った記事
- [AWS Database Migration Service（DMS）とは？サーバーレスと同種・異種移行の使い分け・料金を実装者目線で解説](https://www.issoh.co.jp/tech/details/15785/)：既存DBをAWSのDBへ移すときの移行ツールを解説した記事

---

出典: [AWSのDBサービス11種の選び方：用途別の比較表とCLIで作成して確かめる手順](<https://www.issoh.co.jp/tech/details/17879/>)（株式会社一創）
