AWSではどのデータベースを利用するべき？DynamoDBやRDSを比較して紹介

最終更新日：2026年8月5日

はじめに

データベースはオンラインショッピングや宿泊サイト、WordPressのようなCMSといった多くのWebサービス、あるいは業務システム、ゲーム等と分野を問わず利用されている仕組みです。簡単に表すと「データを格納する箱」ではあるものの、その格納の仕方はいくつかの異なった手段が採られ、さらにただ格納しているだけではなく、データの参照、追加・更新・削除といった処理も発生するため、データベースごとに仕様や管理方法を覚えなければなりません。そのためデータベースに特化した「データベースエンジニア」という専門職を設けている企業も少なくありません。

以上のことはオンプレミスのサーバー環境だけではなくクラウドサービスにも言えることです。この記事では、Amazonのクラウドサービスである「AWS」で特に利用されることの多いデータベース「RDS(Relational Database Service)」と「DynamoDB」それぞれの特徴や、選定基準、その他にAWSで利用できるデータベースについても紹介していきます。これからAWSを利用しようと思っている方、データベースの選定に迷っている方、データベースエンジニアやクラウドエンジニアを目指している方はぜひご覧ください。

データベースの種類について

まずは、AWSに限らず一般的に出回っているデータベースの種類について紹介します。データベースの種類は大きく階層型、ネットワーク型、リレーショナル型、NoSQLの4つに分けられ、現在も多くのシステムで利用されているのは、このうちリレーショナル型、NoSQLとなっています。なお、今回紹介するAWSのRDSがリレーショナル型に当たり、DynamoDBがNoSQLに当たります。

階層型のデータベースは、親ノード、子ノードをツリー構造で繋げてデータを管理する方法です。基本的に子ノードに対して親ノードは1:1の関係となるため検索に時間がかかることがなく、結果として速度が早くなります。その一方で、親ノード間で同データを参照することができないため親ノードごとに同じデータを保持することとなり、その分容量が多く使われ、冗長化の原因にもなります。

ネットワーク型は、子ノードが複数の親ノードを持つことが可能なモデルのデータベースであるため、階層型より柔軟で複雑な管理が可能となります。なお、階層型にも言えることですが、データ構造の理解が前提となるモデルであるため仕組みを深く理解しているエンジニアでないと取り扱うことが困難というデメリットがあり、近年では利用されているシステムが少なくなってきています。

リレーショナル型を簡単に表すのであれば、Excel等の表計算ソフトで作成する表のような形でデータを管理するデータベースと思っていただいて問題ありません。例えば全生徒のテストの点数表を記録する表を作成しようとした場合、学年・クラス・氏名・教科・点数等の属性(列)を用意し、その下の行に実際の生徒の情報を入力していくことになると思いますが、この形がまさにリレーショナル型のデータベースとなっています。表のように管理できることによって、階層型やネットワーク型のように親ノード・子ノードの関係性、階層構造を理解せずにデータの管理が可能となることがわかっていただけることでしょう。そのため複数の表を関連付けて複雑なデータ管理ができるようになる一方で、データ量の増加やプログラムの負荷が発生しやすくなるというデメリットもあります。

リレーショナル型データベースを管理するシステムはRDBMS(Relational DataBase Management System)と呼ばれ、該当する製品として代表的なものはAWSのRDSの他、Oracle Database、MySQL、PostgreSQL、SQLite、Microsoft SQL Server等があります。

最後のNoSQLは、SQLを使わなくても管理できるデータベースのことを表します。近年利用されているデータベースのほとんどは前述したリレーショナル型であるため、リレーショナル型以外のデータベースをNoSQLと言ったとしても認識が大きく誤っているということはありません。実際に「非リレーショナル」と言い表されることもあります。あまりデータベースに触れたことがない方には馴染みがないかもしれませんが、SQLとは「Structured Query Language」の略で、リレーショナル型のデータベースに対して何らかの操作を行う場合に必須の言語です。プログラミング言語と違って仕組みはシンプルですが、使いこなすには多少の学習が必要です。しかし、このSQLを使わずにAPI等で管理できるデータベースがNoSQLです。処理速度が速い、扱えるデータの種類が多いというメリットがある一方、データの更新・削除が頻繁に発生するシステムでは、データの整合性が取れなくなる可能性があるというデメリットもあります。

NoSQLの代表的な製品としては、AWSのDynamoDBの他、GoogleのCloud DatastoreやCloud Firestore、Cloud Bigtable、そしてMongoDB、Redis、Cassandra等があります。

近年利用されることが多いデータベースはリレーショナル型とNoSQLということを紹介しましたが、この2つはそれぞれの特徴を十分に活かせるシステム開発において使い分けられている状況です。

RDS(Relational Database Service)について

RDBMSの一つであり、MySQL、PostgreSQL、MariaDB、SQL Server、Oracle、Auroraといったデータベースエンジン(データベースを操作するソフトウェアのこと)の中から任意のものを利用できます。もちろん操作にはSQL言語が使われます。そのため、正規化の工程を踏む等、何かとリレーショナル型データベースの扱いに慣れている方にはおすすめです。特に、検索における自由度が高い点はRDSのメリットですが、一方で構造化されていないデータの管理ができないという面もあります。

複雑なクエリの処理(データの検索・更新・削除・抽出等を行う要求)が可能であるため、業務システムでの利用に適していると言えます。その他の特徴としては、参照専用のデータベース「リードレプリカ」を必要に応じて複数利用することで、大量なリクエストがあったとしても速度を落とさずに処理が可能という点があります。また、通常利用しているデータベースとバックアップ用のデータベースをそれぞれ別の場所に設置(ストレージとインスタンスの分離)し、通常利用している方が障害等で停止したとしてもバックアップ用の自動的に切り替えて運用を継続することが可能となっています。ただし、切り替えは瞬時に行われるわけではなく数十秒という単位で時間がかかり、その間はデータベースへのアクセスが不可となるため、一時的とはなりますが可用性が失われるということは覚えておきましょう。その他、メンテナンス等でセキュリティパッチを当てて再起動が必要となる場合も、一時的に可用性が失われることになるでしょう。

クラウドサービスならではのスケーラビリティ(拡張性)の高さ、管理や構築の簡略化、コストの削減が可能という部分も、AWSにおけるRDSの特徴と言っていいでしょう。それらに加え、KMS、AWS CloudHSMといったセキュリティサービスを利用することで暗号化し、その際のキーの保管も安全に行えるようになります。仕様はリレーショナル型とほぼ同様であるため今回は省略します。

なお、RDSで利用できるデータベースエンジンとして紹介した「Aurora」ですが、こちらはAWSが提供するオリジナルなものであるもののMySQLやPostgreSQLとの互換性があります。そのため、オンプレミス環境からクラウドに移行する際も元々MySQL、PostgreSQLを利用していれば移行がスムーズに行える可能性が高いです。RDSでMySQL、PostgreSQLを引き継いで利用することも可能ですが、処理能力はAuroraの方が優れていると言われているので、クラウド化をきっかけに切り替えるのも一つの手になるでしょう。またAuroraの場合、前述したリードレプリカは最大で15個まで設置が可能です。注意点として、利用可能なMySQL、PostgreSQLのバージョンは限られているため、もしオンプレミスから移行をする際はあらかじめAWSの公式サイトで対応バージョンを確認してから進めることをおすすめします。

DynamoDBについて

RDSとは対照的に、シンプルな処理を高速に実施する点で優れているデータベースです。そのため、システム使用の行動履歴、位置情報、ゲーム、IoTでのデータ管理というような複雑なクエリが発生しづらく、データの更新等の操作を前提としないシステムでの利用に向いています。なお、大量データの処理時は規模に応じてデータをパーティションニングやスケーリングすることで分散処理を行い、高速化を実現しています。

NoSQLのデータベースであるため、API経由にてデータ操作を行う仕組みとなっています。キーとバリューでデータを管理するタイプとなっており、高度なパーティション化、負荷状況に合わせてサーバー数を増減する「水平スケーリング」が可能となっている他、ドキュメント型であるため、JSONやXMLといったフォーマットで記述されているデータも扱えるという特徴もあります。特にJSONは複数のプログラミング言語を跨いで利用できるフォーマットであるため、データベースにDynamoDBを採用することでさらに柔軟なシステムの構築が可能になると言えます。

さらにDynamoDBはインメモリキャッシュが利用できるため、レイテンシー(通信の遅延)をマイクロ秒程度に抑えることが可能となっています。可用性については、テーブルを自動バックアップするポイントインタイムリカバリ(PITR)を利用することで誤って削除や上書き処理が行われないような仕組みを採っています。クラウドサービスならではのメリットがあるのはRDSと同様です。

DynamoDBは利用者側で冗長化を行う必要がなく、自動で3箇所にバックアップが取られる他、容量が無制限(RDSの場合はエンジンによって最大64TiB程度)でインスタンスのサイジングやネットワーク設計・構築(Amazon VPC)が不要である、RDSにはない高い拡張性を持っているという特徴があるため、よりクラウドサービスのメリットを生かしたいのであればこちらがおすすめです。RDSの場合は、事前にインスタンスのサイジング、ネットワーク設定・構築のいずれも必要になります。

また、DynamoDBでは基本的に正規化が不要で、アクセスパターンをベースにモデリングを行います。パフォーマンスを優先した構造となっているため細かい検索機能を省いており、検索はDynamoDBが苦手な分野の一つと言えます。パーティションを跨いだインデックスの構成ができないため、もし検索をする場合は毎回対象のパーティションを指定したうえで実施することになります。データ量が少ないのであれば、もちろんフルスキャンを行うという手段をとっても問題ありません。

最初にも述べましたが、以上の特徴により、DynamoDBは遅延を許容しづらいWebサービスやアプリ、ゲーム、IoTといった分野で利用される傾向が見られる状況です。DynamoDBの代表的な事例としてはQRコード決済サービス「PayPay」が挙げられます。

なお、特徴的であるDynamoDBの料金体系についても紹介しておきます。DynamoDBにはテーブルに対する読み込み/書き込み容量モードが「オンデマンド」「プロビジョニング済み」の2つ用意されていて、それぞれ課金方法が異なります。

オンデマンドでは、システムにおいてテーブルに対して読み取り/書き込みが行われた際に課金が発生します。柔軟に拡張可能であるため、新規にデータベースのテーブル作成をする必要が予測される場合、トラフィックの予測ができない場合、その他、予算の都合等で、従量課金制である方が何かと便利という場合に適したモードです。

一方の「プロビジョニング済み」は、システムにおける1秒あたりの読み込み/書き込みの回数をあらかじめ指定しておき、その指定値に対する利用率によってテーブルのキャパシティが自動調整され、システムの安定稼働を維持することが可能なモードです。事前にトラフィック予想ができている場合や、トラフィックに大きな上下がない、キャパシティを予測してコスト削減をしたいという場合におすすめです。

その他AWSで提供されているデータベースについて

今回はRDSとDynamoDBについて紹介してきましたが、AWSでは他にもデータベースが提供されているため簡単に触れておきます。

一つ目は「Redshift」です。BIデータの分析を得意とするデータベースで、ペタバイトに達する大容量のデータも扱える列指向型のデータベースです。なお「列指向」というのは、リレーショナルデータベースが行を対象とする「行指向」であるのに対して、列を対象とするデータベースということになります。リレーショナルデータベースでも列を対象にすることはできますが、基本的には行指向であるため、列を対象にしようとした場合に負荷がかかります。その点、初めから列指向であるRedshiftは、その特徴を生かして分析がスムーズに行えるようになっています。

二つ目は「ElastiCache」です。DynamoDBのようにインメモリキャッシュへのデータ保管を可能とすることで、高速な処理が行えるデータベースとなっています。コストも削減しやすいというメリットがありますが、一方で基本的にメモリ上にデータを保存するという仕組みであることから、障害が発生した際にデータが消失してしまう可能性もあります。そのため、一時的なデータの保存に利用することが推奨されます。なお、ElastiCacheは、memcached、Valkey/Redisといったエンジンから選択して利用することが可能です。

最後は「Neptune」です。「オブジェクト」「関係性」という2つの属性を基本とするデータ構造で管理を行う「グラフ型データベース」で、リレーショナル型では処理が複雑になってしまうことを高速で処理できるというメリットがあり、アプリ等の開発を簡略化できるようになります。グラフ型と呼ばれるだけあってデータはグラフの形式で格納されているという特徴があり、高速な検索も得意としています。

ここで紹介した3つ以外にも、AWSでは目的別に特化したデータベースサービスが提供されています。あわせて押さえておくと、システムの要件に合わせた選定の幅が広がります。

DocumentDB（ドキュメント型・MongoDB互換）

JSONのような形式の「ドキュメント」単位でデータを管理する、MongoDB互換のマネージドデータベースです。ネストした構造のデータをそのまま柔軟に保存・検索できるため、商品カタログやユーザープロフィールのように項目数や構造が案件ごとに変わりやすいデータの管理に向いています。

Keyspaces（ワイドカラム型・Cassandra互換）

Apache Cassandra互換のワイドカラム型データベースです。行ごとに異なる数・種類の列を持たせられる柔軟なテーブル構造と、大規模書き込みに強いスケーラビリティが特徴で、IoTのセンサーデータや大量アクセスログのように書き込み頻度が非常に高いユースケースに適しています。

Timestream（時系列データベース）

IoTセンサーの計測値やシステムの監視メトリクスのように、時刻とともに大量に発生するデータ(時系列データ)の保存・分析に特化したデータベースです。時系列データ特有の圧縮・集計処理に最適化されており、汎用的なリレーショナルデータベースで同じことを行うよりも効率的に扱えます。

MemoryDB（インメモリ・Redis/Valkey互換）

Redis/Valkey互換のインメモリデータベースで、ElastiCacheと同様に高速な処理を得意としますが、複数のAZにまたがるトランザクションログによってデータの永続性・高可用性を確保している点が異なります。キャッシュ用途だけでなく、インメモリの速度をそのままプライマリデータベースとして利用したいシステムに向いています。

用途別 AWSデータベースの選び方一覧表

ここまで紹介してきたAWSの主なデータベースサービスを、種類と主な用途で一覧にまとめました。選定の参考にしてください。

よくある質問（FAQ）

Q. RDSとDynamoDB、まず何を基準に選べばいいですか？

複数テーブルの結合や複雑な検索条件など「データ同士の関係性を扱う処理」が多いシステムはRDSが向いています。一方、単純なキー検索を大量・高速に処理したい、トラフィックの増減が大きい、将来的なデータ量の見通しが立てにくいといった場合はDynamoDBが向いています。どちらか一方に絞らず、要件定義の段階で処理内容ごとに使い分けを検討するのがおすすめです。

Q. RDSとAuroraはどちらを選ぶべきですか？

Auroraは技術的にはRDSのデータベースエンジンの一つという位置づけで、MySQL・PostgreSQLと互換性がありながら処理性能や可用性がRDSの標準エンジンより高く設計されています。オンプレミスからMySQL/PostgreSQLをそのまま持ち込みたい場合はRDS、性能や拡張性、リードレプリカ数の多さ(Auroraは最大15個)を重視する場合はAuroraが選ばれる傾向にあります。

Q. DynamoDBとMemoryDB、ElastiCacheの違いは何ですか？

DynamoDBはディスクベースで永続性を前提としたNoSQLデータベースです。ElastiCacheはインメモリのキャッシュ用途に特化しており、障害時にデータが消える可能性があります。MemoryDBはRedis/Valkey互換のインメモリ速度を持ちながら、トランザクションログによってデータの永続性・高可用性を確保している点でElastiCacheと異なり、プライマリデータベースとしての利用も想定されています。

Q. AWSのデータベースはどれも料金体系が同じですか？

いいえ、サービスごとに異なります。RDSやAuroraはインスタンスタイプ・稼働時間に応じた課金が基本ですが、DynamoDBは記事内で紹介した「オンデマンド」「プロビジョニング済み」の2モードから選択でき、Redshiftはクラスターのノード数・稼働時間に応じた課金が基本です。最新の料金体系は必ずAWSの公式サイトで確認してください。

Q. 一度RDSまたはDynamoDBで構築したシステムを、後から切り替えることは可能ですか？

技術的には移行ツールを使ったデータ移行は可能ですが、データモデルの設計思想(正規化されたリレーショナル型か、アクセスパターン中心のNoSQLか)が根本的に異なるため、アプリケーション側の作り直しが必要になるケースがほとんどです。記事内でも触れている通り、システム稼働後の切り替えは現実的ではなく、要件定義の段階でどちらを使うか決めておくことが重要です。

まとめ

この記事のポイント：

• データベースは大きく階層型・ネットワーク型・リレーショナル型・NoSQLの4種類に分類され、AWSのRDSはリレーショナル型、DynamoDBはNoSQLに該当する
• RDSは複雑な検索・結合処理を伴う業務システム向き、DynamoDBは低レイテンシーで大量アクセスを高速処理したいシステム向き
• AuroraはRDSのエンジンの一つでMySQL/PostgreSQL互換ながら高い処理性能を持ち、「Aurora Serverless v2」によるキャパシティの自動調整にも対応している
• RDS・DynamoDB以外にも、分析用のRedshift、インメモリのElastiCache/MemoryDB、グラフ型のNeptune、ドキュメント型のDocumentDB、ワイドカラム型のKeyspaces、時系列型のTimestreamなど目的特化型のデータベースが揃っている
• システム稼働後のデータベース切り替えは現実的ではないため、要件定義の段階で用途に合ったデータベースを選定しておくことが重要

今回紹介しきれていないさらに細かい特徴はそれぞれにありますが、DynamoDB、RDSの概要は掴んでいただけたのではないでしょうか。今後どちらか一方のデータベースだけが飛躍的に様々なシステムで利用されるようになるという傾向は特に見られず、どちらもメリットが活かせる分野のシステムで利用され続けることが考えられます。そのため、改めてこの2つの間の選定基準をまとめます。

これまで利用していたMySQLやPostgreSQL等のリレーショナル型データベースの知識・スキルを持ってデータベースを管理したい、検索やテーブルの結合含め、データに対する複雑かつ頻繁な処理が必要となるといった場合はRDSがおすすめです。

データに対する処理や検索は重要ではないものの、高トラフィックに対応し、速い処理速度が求められる場合、JSON、XMLのデータも扱いたい場合、将来的な拡張性が見込める場合はDynamoDBがおすすめです。

いずれにしても、システム稼働後にデータベースを切り替えるということは現実的ではないため、どちらを利用するかはシステム開発の初期となる要件定義の段階で決めておく必要があります。また、DynamoDB、RDS両方のメリットを生かして併用するというハイブリッドな利用も可能なので、今後AWSでデータベースを利用する場合は、ぜひこの記事をきっかけに複数のデータベースの特徴を共に正しく、かつ深く理解しておくことをおすすめします。

関連記事

• Amazon RDSで選択できるリレーショナルデータベースエンジン（Amazon Aurora・PostgreSQL・MySQL・MariaDB・Oracle データベース・SQL Server）について — RDSで選べる各データベースエンジンをさらに詳しく知りたい方向け
• 「Aurora」と「Oracle」のそれぞれの強みと戦略性 — Auroraの強みをOracleと比較して掘り下げた記事
• Amazon DocumentDBとは？MongoDBとは？ — 本記事で紹介したDocumentDBをさらに詳しく解説
• Redshiftについて概要を説明 — 分析用データベースRedshiftの詳細解説