Amazon RDS vs Aurora 徹底比較｜料金・性能・ユースケース別の選び方ガイド

「RDSとAuroraって何が違うの？」「Auroraのほうが高性能って聞くけど、コストに見合うの？」——AWSでデータベースを選ぶとき、この疑問にぶつかるインフラエンジニアは多いはずです。

オンプレミス環境では、MySQLやPostgreSQLをサーバーにインストールして、バックアップやフェイルオーバーの仕組みを自前で構築するのが当たり前でした。AWSに移行すると、マネージドDBサービスとしてAmazon RDSとAmazon Auroraの2つが選択肢に入りますが、どちらを選ぶかで運用負荷もコストも大きく変わります。

この記事では、RDSとAuroraの違いを「アーキテクチャ」「性能」「料金」「運用」「ユースケース」の5軸で徹底比較します。オンプレからの移行シナリオも交えて解説しますので、自社の要件に合った選定の判断材料にしてください。

RDSとAuroraの基本的な違い

まず押さえておきたいのは、AuroraはRDSの「上位互換」ではなく「別アーキテクチャの別サービス」だという点です。

Amazon RDSは、MySQL・PostgreSQL・MariaDB・Oracle・SQL Serverなど複数のエンジンに対応したマネージドDBサービスです。オンプレで使い慣れたエンジンをそのままクラウドに持ち込めるのが最大の利点で、既存のSQLやツールがほぼそのまま動きます。

Amazon Auroraは、AWSがクラウド向けにゼロから設計したリレーショナルDBエンジンです。MySQL互換とPostgreSQL互換の2種類があり、APIレベルでは既存のMySQL/PostgreSQLアプリケーションと互換性がありますが、内部のストレージやレプリケーションの仕組みはまったく異なります。

オンプレでMySQLのマスター・スレーブ構成を組んだ経験があるなら、RDSはその延長線上にあるサービスです。一方Auroraは、ストレージ層を分離して分散化した「クラウドネイティブな設計」で、同じMySQLの顔をしていても中身は別物と考えてください。

アーキテクチャの違いを深掘りする

RDSのアーキテクチャ

RDSのストレージはAmazon EBSボリュームに直接紐づいています。マルチAZ構成を有効にすると、別AZにスタンバイインスタンスが作られ、EBSレベルの同期レプリケーションが行われます。

この構造はオンプレのActive/Standby構成と似ているため理解しやすい反面、フェイルオーバー時にはスタンバイ側のEBSをマウントし直す処理が入るため、切り替えに60〜120秒かかります。

Auroraのアーキテクチャ

Auroraはコンピュート層とストレージ層が完全に分離されています。ストレージは3つのAZにまたがって6つのコピーを自動的に保持し、書き込みは6つのうち4つに成功すればコミット完了とする「4/6クォーラム方式」を採用しています。

この分散ストレージのおかげで、フェイルオーバー時にスタンバイ側がストレージを「マウントし直す」必要がありません。既存のリードレプリカがそのまま昇格するだけなので、切り替えは通常30秒以内で完了します。

# Auroraクラスターのエンドポイント確認
aws rds describe-db-cluster-endpoints \
  --db-cluster-identifier my-aurora-cluster \
  --region ap-northeast-1

# 出力例:
# "EndpointType": "WRITER"  → 書き込み用エンドポイント
# "EndpointType": "READER"  → 読み取り用エンドポイント（負荷分散）

Auroraではクラスターエンドポイントが書き込み用と読み取り用に分かれているため、アプリケーション側で接続先を切り替えるだけで読み取り負荷を分散できます。オンプレでProxySQLやHAProxyを使って手動で読み書き分離していた仕組みが、エンドポイントレベルで標準提供されているわけです。

性能比較

AWSの公式ベンチマークでは「AuroraはMySQLの最大5倍、PostgreSQLの最大3倍の性能」と謳われています。ただし、この数字はすべてのワークロードに当てはまるわけではありません。

現場の実感としては、1日数万トランザクション程度の小〜中規模ワークロードでは、RDSとAuroraの性能差は体感しにくいことがほとんどです。差が顕著に出るのは、書き込みが集中するピーク時や、リードレプリカを多数展開して読み取りを分散させるケースです。

レプリケーション遅延の違い

レプリケーション遅延もアーキテクチャの違いが効いてきます。

・RDS: バイナリログベースの非同期レプリケーション。書き込み量が多いと数秒〜数十秒の遅延が発生することがある
・Aurora: ストレージ層で共有しているため、レプリケーション遅延は通常20ミリ秒以下

オンプレでMySQLレプリケーションの遅延に苦労した経験があるなら、Auroraのこの特性は大きなメリットです。リードレプリカでほぼリアルタイムのデータを読めるため、レポート系クエリの分離がやりやすくなります。

料金比較

料金はRDS選定で最も悩むポイントの一つです。以下は東京リージョン（ap-northeast-1）のオンデマンド料金の比較です（2026年4月時点）。

インスタンス料金の比較

Auroraのインスタンス料金はRDSの約20%増です。ただし、これだけで「Auroraは高い」と判断するのは早計です。

ストレージ料金の比較

RDSではストレージを事前に確保する必要があるため、「念のため多めに確保しておこう」と余分なコストが発生しがちです。Auroraは使った分だけ課金されるので、容量の読みが難しいケースではAuroraのほうが無駄が出にくくなります。

マルチAZ構成のコスト比較

可用性を確保するためにマルチAZ構成を組む場合、コスト構造が変わります。

・RDS マルチAZ: スタンバイインスタンスのぶん、インスタンス料金が約2倍になる
・Aurora: ストレージは最初から3AZに分散しているため追加料金なし。リードレプリカを別AZに配置すればフェイルオーバー先も兼ねられる

つまり、マルチAZ＋リードレプリカを組む構成では、RDSは「スタンバイ＋リードレプリカ」で3台分の料金がかかるのに対し、Auroraは「ライター＋リーダー」の2台分で済みます。この差額でインスタンス単価の20%増を十分吸収できるケースは少なくありません。

# RDS マルチAZ構成の月額目安（db.r6g.large）
# ライター: $0.290 × 730h = $211.70
# スタンバイ: $0.290 × 730h = $211.70（マルチAZ追加分）
# 合計: 約$423/月（リードレプリカ別途）

# Aurora 構成の月額目安（db.r6g.large）
# ライター: $0.350 × 730h = $255.50
# リーダー（フェイルオーバー兼用）: $0.350 × 730h = $255.50
# 合計: 約$511/月（ストレージ3AZ分散込み）

# ※RDSにリードレプリカ1台追加すると +$211.70 → 合計$635/月
# ※Auroraの2台構成のほうが安くなる

Aurora Serverless v2という選択肢

Aurora Serverless v2は、ワークロードに応じてコンピュートキャパシティが自動的にスケールするオプションです。ACU（Aurora Capacity Unit）という単位で課金され、最小0.5ACUから最大256ACUまで設定できます。

・東京リージョン料金: $0.20/ACU/時間（2026年4月時点）
・最小ACU: 0.5ACU（約1GBメモリ相当）

トラフィックが不規則な開発環境や、夜間・休日にアクセスが激減するWebサービスでは、プロビジョンド型（固定インスタンス）より大幅にコストを下げられる可能性があります。

ただし注意点もあります。ピーク時のACU消費量が大きいと、プロビジョンドインスタンスのほうが安くなることがあります。まずは開発環境やステージング環境で試してから、本番への適用を検討するのが現実的です。

# Aurora Serverless v2の設定例
aws rds create-db-cluster \
  --db-cluster-identifier my-serverless-cluster \
  --engine aurora-mysql \
  --engine-version 8.0.mysql_aurora.3.04.0 \
  --serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=16 \
  --master-username admin \
  --master-user-password "YourStrongPassword" \
  --region ap-northeast-1

# Serverless v2インスタンスの追加
aws rds create-db-instance \
  --db-instance-identifier my-serverless-instance \
  --db-cluster-identifier my-serverless-cluster \
  --db-instance-class db.serverless \
  --engine aurora-mysql \
  --region ap-northeast-1

運用面の比較

バックアップとリストア

Auroraのバックアップは継続的に行われるため、RDSのように「バックアップウィンドウ中にI/Oが遅くなった」という問題が起きません。また、Auroraのクローン機能は大規模DBでも数分でコピーを作成できるため、本番データを使ったテスト環境の構築が格段に楽になります。

メンテナンスウィンドウ

エンジンのマイナーバージョンアップやパッチ適用の頻度は、RDSもAuroraもほぼ同等です。ただしAuroraのパッチ適用はゼロダウンタイム（ZDP）に対応しているケースがあり、アクティブなコネクションを維持したままパッチを適用できます。

RDSの場合はマルチAZ構成であればフェイルオーバーを伴うパッチ適用が可能ですが、数十秒〜数分のダウンタイムが発生します。

ユースケース別の選び方

RDSを選ぶべきケース

・Oracle・SQL Serverからの移行: Auroraは非対応。RDSならライセンス込み（License Included）で使える
・小規模ワークロード: 月額数万円以下の規模なら、RDSのほうがシンプルでコスト効率が良い
・既存アプリのリフト&シフト: オンプレのMySQL/PostgreSQLをそのまま移行する場合、RDSが最も変更点が少ない
・MariaDB固有機能の利用: MariaDBのGalera Clusterなど固有機能が必要な場合はRDS一択

Auroraを選ぶべきケース

・高可用性が最優先: フェイルオーバー30秒以内、3AZ×6コピーのストレージが標準で付いてくる
・書き込み負荷が高い: 分散ストレージによる書き込み性能の向上が直接効いてくる
・リードレプリカを多数展開: 最大15台、かつレプリケーション遅延がほぼゼロ
・トラフィック変動が大きい: Aurora Serverless v2で自動スケールに対応
・大容量DB（数十TB以上）: 128TBまで自動拡張、ストレージ管理が不要

判断フローチャート

・MySQL/PostgreSQL以外のエンジンが必要 → RDS
・月間コスト$100以下の小規模環境 → RDS
・フェイルオーバー時間60秒以上許容できない → Aurora
・リードレプリカ6台以上必要 → Aurora
・ストレージ容量の事前見積もりが困難 → Aurora
・開発/テスト環境で本番DBのクローンを頻繁に作る → Aurora

オンプレからの移行パス

オンプレのMySQL/PostgreSQLからAWSに移行する場合、段階的なアプローチがおすすめです。

1. まずRDSに移行する

AWS Database Migration Service（DMS）を使って、オンプレのDBをRDSに移行します。MySQLからRDS MySQLへの移行は互換性が最も高く、アプリケーション側の変更が最小限で済みます。

# DMSレプリケーションインスタンスの作成
aws dms create-replication-instance \
  --replication-instance-identifier my-dms-instance \
  --replication-instance-class dms.r5.large \
  --region ap-northeast-1

# ソース（オンプレMySQL）エンドポイントの作成
aws dms create-endpoint \
  --endpoint-identifier source-onprem-mysql \
  --endpoint-type source \
  --engine-name mysql \
  --server-name 192.168.1.100 \
  --port 3306 \
  --username repl_user \
  --password "ReplicationPassword"

2. 必要に応じてAuroraに移行する

RDSで本番運用を始めた後、性能やコストの観点でAuroraに移行したくなった場合は、RDSスナップショットからAuroraクラスターを作成するだけで移行できます。

# RDSのスナップショットからAuroraクラスターを作成
aws rds restore-db-cluster-from-snapshot \
  --db-cluster-identifier my-aurora-from-rds \
  --snapshot-identifier rds-mysql-snapshot-20260410 \
  --engine aurora-mysql \
  --region ap-northeast-1

# Auroraインスタンスの作成
aws rds create-db-instance \
  --db-instance-identifier my-aurora-writer \
  --db-cluster-identifier my-aurora-from-rds \
  --db-instance-class db.r6g.large \
  --engine aurora-mysql \
  --region ap-northeast-1

この2段階アプローチなら、最初から「RDSかAuroraか」を決め打ちしなくても、実際のワークロードを見てから判断できます。

よくあるトラブルと対処法

Aurora移行後にI/O料金が想定以上になった

Auroraのストレージ単価はRDSより安いものの、I/O料金が別途かかります。書き込みが非常に多いワークロードでは、I/O料金がインスタンス料金を上回ることがあります。Aurora I/O-Optimizedという選択肢もあり、I/O料金が無料になる代わりにインスタンス料金が約30%増になります。ワークロードのI/O特性に応じて切り替えを検討してください。

RDSのフェイルオーバーが遅い

RDSマルチAZのフェイルオーバーが60秒以上かかる場合、アプリケーション側のDNSキャッシュが原因であることが多いです。RDSエンドポイントのTTLは短く設定されていますが、アプリケーションやOSレベルでDNSキャッシュが長いと切り替えが遅れます。JDBCの場合はconnectTimeoutとsocketTimeoutを適切に設定し、コネクションプールの再接続ロジックを確認してください。

Auroraのリーダーエンドポイントで負荷が偏る

Auroraのリーダーエンドポイントはラウンドロビンで接続を分散しますが、コネクションプールを使っているとプール作成時に接続が固定され、特定のリーダーに偏ることがあります。接続プールのTTLを短く設定するか、アプリケーション側で定期的にコネクションをリフレッシュする仕組みを入れてください。

本記事のまとめ

RDSとAuroraは「どちらが優れている」という関係ではなく、ワークロードと要件に応じて使い分けるものです。小規模な環境やOracle/SQL Serverが必要な場面ではRDSが最適解ですし、高可用性・高性能・スケーラビリティが求められる場面ではAuroraの分散アーキテクチャが真価を発揮します。迷ったときは「まずRDSで始めて、必要に応じてAuroraに移行する」という段階的アプローチが最もリスクが低い選択です。

RDSの基本的な使い方についてはAmazon RDS入門 クラウドDB移行の基礎知識で詳しく解説しています。また、Azure環境のマネージドDBについてはAzure SQL Database入門 オンプレSQLサーバーからの移行手順と料金・設計の基礎知識もあわせてご覧ください。

Linuxサーバー上のデータベース運用については、姉妹サイトLinuxMaster.JPで詳しく解説しています。