AWS

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

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(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の対応エンジンと料金モデルを解説した記事とAuroraの仕組みとRDSとの違いを解説した記事で扱っています。

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

非リレーショナル系は、データの形ごとに専用のサービスが用意されています。AWS公式ホワイトペーパーのデータベース章の対応表を、実務でよく出る用途に置き換えると次のとおりです。

データモデル サービス 典型的な用途
キーバリュー 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選定を比較した記事で詳しく整理しています。

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

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

  1. Aurora DSQLは2025年5月27日に一般提供を開始しました。サーバーレスの分散SQLで、公式ではマルチリージョン構成の可用性を99.999%としています。
  2. Timestream for LiveAnalyticsは、公式の告知で2025年6月20日から新規顧客を受け付けていません。新規はTimestream for InfluxDBが代替です。
  3. 台帳データベースのQLDBは、AWSの日本語ブログが示すとおり2025年7月31日にサポートを終えました。移行先はAurora PostgreSQLなどです。

Timestreamの2つのエンジンの違いはAmazon Timestreamのエンジンと料金モデルを解説した記事、QLDBからの移行はQLDBのサービス終了と移行先を解説した記事を参照してください。

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つの選択肢を解説した記事にまとめています。

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

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

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

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

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

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

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

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

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

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

RDSで選べるエンジンの版はリージョンと時期で変わるため、記事や社内資料の版番号をそのまま信じず、その場で取得します。describe-db-engine-versionsのリファレンスにある--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のリファレンスには、--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によるパスワード管理の公式ページのとおり自動でローテーションされます。インスタンスクラスのdb.t4g.microは、後述する無料プランの対象です。

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

DynamoDBはサーバーを持たないため、テーブルを作るだけで読み書きを始められます。create-tableのリファレンスに従い、パーティションキーとソートキーを文字列で定義し、課金をオンデマンド(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のスループット容量の公式ページで確認できます。

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

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のリファレンスのとおり、--skip-final-snapshotを付けない場合は最終スナップショットの名前が必須です。手動で取ったスナップショットはインスタンスを消しても残り、ストレージ料金がかかり続けます。削除の翌日に請求画面でRDSの項目が止まっているかを見て、残骸が無いことを確かめてください。

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

AWSの無料利用枠は、2025年7月16日に発表された改定で仕組みが変わりました。「12か月無料」を前提にした古い解説のまま検証を始めると、アカウントが途中で閉じる、使えるはずの枠が無い、といった事態になります。

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

AWSのデータベース無料枠の公式ページによると、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の料金を東京リージョンの実額で試算した記事で確認できます。

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の同種・異種移行の使い分けを解説した記事で確認できます。設計から移行までをまとめて任せたい場合は、データベース設計・移行支援のサービスに、移行元の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を外すと選べる版が一覧で返ります。版の提供状況はリージョンと時期で変わるため、資料の記載ではなく、作成直前にコマンドで確かめてください。

関連記事

お気に入りに入れた記事の一覧

資料請求

RELATED POSTS 関連記事

目次