クラウド

AWSデータベースの選び方：RDSとAuroraとDynamoDBの使い分け

2026/10/17 シリーズ「AWS 入門」 第8回 / 全8回

🤖 AIを使用して執筆

SELECT members.member_id, plans.monthly_fee
FROM members
  JOIN plans ON members.plan = plans.plan
WHERE members.member_id = 'M-301';

SELECT count(*)
FROM members
WHERE plan = '平日会員';

{
  "member_id": "M-301",
  "entered_at": "2026-10-17T07:02:15",
  "store": "駅前店"
}

自分で動かすか、RDS に任せるか

データベースは、EC2 のインスタンス（AWS で借りる仮想のサーバー）に自分で入れて動かすこともできる。その場合、AWS が管理するのは機械と電源とネットワークまでで、OS とデータベースのソフトの導入とパッチ、バックアップ、予備を持つ構成、規模の変更は、利用者が受け持つ。RDS では、それらを AWS が受け持つ⁹。どちらでも、問い合わせを速くする調整のように、アプリに合わせる作業は利用者が行う⁹。

AWS は、リレーショナルデータベースを動かす多くの場合に、RDS を既定の選択として勧めている。EC2 で自分で動かす短所として、利用者の誤りが入りやすいことを挙げている⁹。

Amazon RDS：リレーショナルデータベースを任せて動かす

RDS は、AWS の上でリレーショナルデータベースを用意し、運用し、規模を変えやすくするサービスである。エンジン（データベースのソフト）は、MySQL、PostgreSQL、MariaDB、Oracle、SQL Server、Db2 から選べる⁹。RDS は、バックアップ、ソフトのパッチ、故障の検出と復旧を管理する⁹。

• バックアップ： 自動のバックアップを残す日数は、0〜35 日で決められ、コンソールで作ると既定は 7 日である¹⁰。その期間の中なら、どの時点の状態にでも、新しいインスタンスとして戻せる¹¹。
• マルチ AZ： 別のアベイラビリティーゾーン（リージョンの中で離れたデータセンターの群）に、同じ内容を同期して書く予備を置く¹²。元のゾーンで障害が起きると、RDS は自動で予備に切り替える。切り替えには、ふつう 60〜120 秒かかる¹³。予備は、ふだんの読み出しには使えない¹²。
• リードレプリカ： 読み出し専用の写しで、元のデータベースへの書き込みは、少し遅れて（非同期で）写される¹⁴。読む負荷を分けるのに使う。

料金は、主にデータベースのインスタンスを動かした時間、確保したストレージと I/O（読み書き）の性能、データ転送で数える¹⁵。インスタンスの料金は、起動してから、停止するか削除するまでかかる¹⁶。停止しているあいだも、確保したストレージとバックアップの料金はかかる。停止は最長 7 日で、過ぎると自動で起動する¹⁷。バックアップの保存は、そのリージョンのデータベースのストレージの合計と同じ量までは、追加の料金がかからない¹⁶。

Amazon Aurora：AWS が作り直したリレーショナルデータベース

Aurora は、MySQL と PostgreSQL に互換の、AWS が管理するリレーショナルデータベースである¹⁸。Aurora は RDS の一部として提供され、アプリからは MySQL や PostgreSQL と同じように使える¹⁸。違いは、データを保存する部分にある。

Aurora のデータは、一つのリージョンの三つのアベイラビリティーゾーンにまたがって写しを持つ。書き込むと、Aurora は六つのストレージの機械（ノード）へ同期して写す¹⁹²⁰。ストレージは、必要に応じて自動で大きくなる¹⁸。AWS は、同じような機械で、標準の PostgreSQL や MySQL の最大 6 倍の処理量が出るとしている¹⁸。

2017 年の論文で AWS の Alexandre Verbitski らは、大量の処理での制約がネットワークに移ったとして、データベースの変更の記録（ログ）を Aurora 専用のストレージに送り、ストレージの側でデータを作る作りにしたと説明している²¹。

負荷が読めないときは、負荷に合わせて容量が自動で増減する形（Aurora serverless）で動かせる。負荷の山に合わせて容量を増やし、落ち着けば減らす²²。料金の方式も二つある。標準の方式では、インスタンスとストレージに加えて、I/O の回数に応じて払う。I/O-Optimized の方式では、読み書きの I/O に料金がかからず、インスタンスとストレージの分だけ払う。AWS は、I/O の支出が全体の 25% を超えるなら、費用が最大 40% 下がるとしている²³。

Amazon DynamoDB：キーで読み書きするサーバーレスのデータベース

DynamoDB は、サーバーを用意しなくてよい、AWS が管理する分散型の NoSQL データベースで、どんな規模でも数ミリ秒で応えるよう作られている²⁴。キーバリューとドキュメントの二つのデータの形を扱う²⁴。

項目は、主キーで一つに決まる⁴。主キーは、パーティションキーだけか、パーティションキーとソートキーの組である。リレーショナルデータベースと違い、DynamoDB は表をつなぐ JOIN ができない²⁴。一つの項目の大きさは 400 KB までである²⁵。

• 読み方の整合性： 読みは、既定では結果整合（書いた直後には古い値が返ることがある）で、書いた結果が必ず返る強い整合の読みも選べる²⁶。
• グローバルテーブル： テーブルのデータを、複数のリージョンへ自動で写す²⁷。

料金の数え方は二つの方式から選ぶ²⁸。オンデマンドの方式は、リクエストの回数に応じて払い、容量の計画が要らない²⁹。読みは、4 KB までの項目を強い整合で 1 回読むと 1 単位で、結果整合なら 2 回で 1 単位である。書きは、1 KB までの項目を 1 回書くと 1 単位である³⁰。保存しているデータの量にも料金がかかる²⁹。プロビジョニングの方式は、秒あたりの読み書きの容量を、前もって決めて払う³¹。

DynamoDB は Amazon 自身の大きな負荷も支えており、2021 年のプライムデーには毎秒最大 8,920 万回呼ばれたと、AWS の論文は報告している³²。

DynamoDB は、読み方を先に決めてからキーを作る

リレーショナルデータベースでは、データの形を先に整え、問い合わせは後から書ける。AWS は、DynamoDB では反対に、答えるべき問いが分かるまで、データの形を設計し始めるべきではないとしている。最初にすることは、システムが満たすべき問い合わせの型を特定することである³³。そのうえで、テーブルの数はなるべく少なくするよう勧めている³³。

ここから生まれた考え方が、単一テーブル設計である。種類の違うデータ（顧客、注文、支払いなど）を一つのテーブルにまとめ、キーの付け方で一度に読めるようにする。AWS の文書は、いくつもの種類のデータを一緒に読む場合や、データどうしの関係を保つ場合に向くとしている³⁴。

単一テーブル設計には賛否がある。

• 勧める側： 当時 AWS にいた Rick Houlihan は 2020 年のポッドキャストで、NoSQL ではすべての問い合わせを一つのテーブルの絞り込みにするので速くなると話し、単一テーブル設計なら、コードが少なく、単純で、効率もよいとした³⁵。
• 条件を付ける側： DynamoDB の本を書いた Alex DeBrie は、2020 年に、単一テーブル設計を基本としつつ、開発の速さが性能より大事な新しいアプリや、GraphQL を使うアプリでは、複数のテーブルにしてもよいと書いた³⁶。AWS のブログに寄せた 2022 年の記事でも、一つか複数かの選択は単純でなく、複数のテーブルが向く場合もあるとしている³⁷。
• 複数のテーブルに分があるとする側： Paul Swail は 2019 年に、リレーショナルデータベースに慣れた多くの開発者には複数のテーブルのほうが入りやすいと書いた。索引の作り込みの硬さや、データの移行の手間も考えると、多くのチームは複数のテーブルのほうが早くアプリを出せるという³⁸。

つなぎ方と、作るときに決めること

アプリからの使い方も、二つでは大きく違う。

• RDS と Aurora： データベースは VPC（AWS の中に作る自分のネットワーク）の中に置く。ふつうはインターネットから入れないプライベートサブネットに置き、セキュリティグループ（通してよい通信を決める規則）で、アプリのサーバーからの通信だけを許す³⁹。アプリは、データベースの接続先（エンドポイント）のアドレスとポートに、データベースへの接続を張る³。
• DynamoDB： データベースへの接続を張る代わりに、アプリは GetItem や Query などの API（操作の窓口）を呼んで読み書きする⁴⁰。誰が何を読み書きできるかは、IAM（AWS の権限の仕組み）で決める⁴¹。DynamoDB のテーブルは、自分の VPC の中には置けない。テーブルはリージョンごとに作り、アプリは API で呼ぶ。VPC の中のサーバーからは、ゲートウェイエンドポイント（VPC から S3 や DynamoDB へ直接つなぐ出口）を通せば、インターネットゲートウェイや NAT デバイスを通さずに呼べる⁴²。

RDS では、二つ以上のゾーンのサブネットをまとめた DB サブネットグループを用意する³⁹。マルチ AZ にすると、RDS が本体と予備を別々のゾーンのサブネットに置く¹²。

作るときに決めることも違う。RDS では、エンジン、インスタンスの大きさ、ストレージ、マルチ AZ にするか、置くサブネット、外から入れるようにするか、暗号化するかを決める。保存したデータとバックアップは暗号化でき、暗号化は作るときにしか選べない⁴³。ストレージは、空きが少なくなったときに自動で増やす設定もある⁴⁴。DynamoDB では、パーティションキーとソートキー、料金の方式を決める。索引は、テーブルを作った後からも足せる⁴⁰。

選び方の目安

AWS の Well-Architected フレームワークのパフォーマンス効率の柱は、データの大きさ、読み方、遅延、処理量などの特性を理解して、目的に合うデータの保存先（ストレージやデータベース）を選ぶよう求めている。社内に経験があるからという理由で、一つの種類のデータベースにこだわることは、避けるべき型として挙げている⁴⁵。

AWS の選び方の案内も、DynamoDB を、セッションの保存や買い物かごのような用途に挙げている¹。一つのアプリで、データごとに RDS と DynamoDB を使い分けることもできる。ただし、使うデータベースが増えれば、学び、運用し、データの食い違いを防ぐ手間も増える。

試すときは、無料プランのアカウントなら、Aurora と RDS を最大 6 か月、費用なしで使える⁴⁶。

データベースは、読み方に合わせて選ぶ

AWS は、一つのデータベースですべてを満たそうとせず、データの読み方に合う目的別のデータベースを選ぶよう勧めている。表をつないで自由に問い合わせるデータは RDS か Aurora に置き、バックアップや予備への切り替えは AWS に任せる。決まったキーで大量に読み書きするデータは DynamoDB に置く。

DynamoDB では、答えるべき問いを先に決め、それに合わせてパーティションキーとソートキーを設計する。一つのテーブルにまとめるか、複数に分けるかには、実務者のあいだで賛否がある。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。