AWS

RDSとAuroraの違いを実測で比べる：東京の月額・フェイルオーバー時間と選び分け

RDSとAuroraの違いを実測で比べる：東京の月額・フェイルオーバー時間と選び分け

Amazon RDSとAmazon Auroraは、同じRDSのコンソールから作れるマネージドDBですが、データの置き場所と課金の単位が違います。この記事では、RDS for MySQLのMulti-AZ構成とAurora MySQLのライター＋リーダー構成を同じdb.r8g.largeで並べ、東京リージョンの月額、フェイルオーバーで書き込みが止まる時間、容量とレプリカの上限を比べます。単価はAWS Price List APIの2026年10月1日版から取りました。月額を出すPythonコードと、停止時間を測るAWS CLIの手順も載せています。

まとめ：RDSとAuroraの違いを月額・停止時間・容量の上限で決める要点

RDSとAuroraの違いは、ストレージがインスタンスごとのEBSか、3つのアベイラビリティーゾーンにまたがる共有ボリュームかという1点から生まれています。Auroraはリーダーを足してもデータを複製し直さず、障害時の切り替えも公式の目安で60秒未満、多くは30秒未満です。RDSのMulti-AZ DBインスタンスは60〜120秒が目安なので、停止時間は半分以下になります。

料金は、東京のdb.r8g.large・200GBで比べると、RDSのMulti-AZが月474.22USD、Aurora Standardの2台構成がI/O料金を除いて月510.18USDでした。待機系を読み取りに使わないならRDSが安く、読み取り用のレプリカを足す構成ならAuroraがI/O月8.38億回まで安く収まります。Aurora内部では、I/Oが月7.33億回を超えるとI/O-Optimizedのほうが得です。

選び方は単純で、読み取りの分散、30秒前後での復旧、64TiBを超える容量のどれかが要件にあればAuroraにします。どれも無い小規模なDBと、SQL Server・Oracleで動くDBはRDSのままで構いません。

RDSとAuroraの構成の違いをストレージ・レプリカ・上限の数値で比べる

料金や停止時間の差は、2つのサービスがデータをどこに書いているかでほぼ説明できます。Aurora単体の仕組みはAmazon Auroraの仕組みとRDSとの違いで詳しく扱っているので、この章は両者を並べたときに差が出る箇所に絞ります。

EBSに書くRDSと共有クラスターボリュームに書くAuroraの書き込み経路の差

RDS for MySQL・PostgreSQLのデータは、インスタンスに接続されたEBSボリュームに置かれます。Multi-AZ DBインスタンスの説明によると、別のアベイラビリティーゾーンの待機系へは同期で複製されますが、待機系は読み取りに使えません。読み取りを分散するには、非同期で複製されるリードレプリカを別に作り、そのストレージ料金も別に払います。

Auroraは、データをクラスターボリュームという1つの仮想ボリュームに置きます。Auroraの高可用性の説明では、プライマリへの書き込みは3つのアベイラビリティーゾーンにある6つのストレージノードへ同期で複製されます。リーダーは同じボリュームを読むため、追加してもテーブルのコピーは起きません。Auroraのレプリケーションの説明では、リーダーの遅延は通常100ミリ秒を大きく下回るとされています。

レプリカ15台・容量64TiBと256TiBなど上限値と仕様の比較表

公式ドキュメントの値を2026年10月4日時点で並べました。RDSの列はMySQL・PostgreSQLの値です。

項目 RDS（Multi-AZ） Aurora
最大ストレージ 64TiB 256TiB（版により128TiB）
ストレージ課金 割り当てた容量 使った容量
読める複製 リードレプリカ最大15台 リーダー最大15台
待機系の読み取り 不可 リーダーが兼ねる
切り替えの目安 60〜120秒 60秒未満
対応エンジン MySQL・PostgreSQLなど6種 MySQL互換・PostgreSQL互換

容量の上限はRDSのストレージの説明とAuroraのクォータ表によります。Auroraの256TiBはAurora PostgreSQL 17.5以上・16.9以上・15.13以上と、Aurora MySQL 3.10以上に限られ、それより前の版は128TiBです。リードレプリカの15台は、同じクォータ表にある「プライマリあたりのリードレプリカ数」の既定値です。

見落とされやすいのはエンジンの行です。RDSはMariaDB・Oracle・SQL Server・Db2にも対応しますが、Auroraは2種類だけです。Oracle・SQL Server・Db2の案件では、Auroraはそもそも選択肢に入りません。

東京リージョンのRDSとAuroraの月額をPrice List APIで計算する手順

Amazon RDSの料金ページとAmazon Auroraの料金ページは別々で、課金項目の構成も違います。同じ条件で比べるため、認証なしで使えるPrice List Bulk APIから東京の単価を取り出しました。

PythonでMulti-AZのRDSとAurora 2台構成の月額を比べるコード

条件は、db.r8g.large（2vCPU・16GiB）を2台、データ量200GB、1か月730時間です。RDSはMulti-AZ DBインスタンスとgp3ストレージ、Auroraはライター1台とリーダー1台の構成にしました。Python 3の標準ライブラリだけで動き、東京のRDSのオファーファイルは約25MBあるため、取得に1分ほどかかることがあります。

# 東京リージョンで「RDS for MySQL Multi-AZ」と「Aurora MySQL（ライター＋リーダー）」の月額を比べる
import json, urllib.request

BASE = "https://pricing.us-east-1.amazonaws.com"
CLS = "db.r8g.large"     # 比較するインスタンスクラス
GB = 200                 # データ量（GB）
HOURS = 730              # 1か月の時間

def get(path):
    with urllib.request.urlopen(BASE + path, timeout=300) as r:
        return json.load(r)

idx = get("/offers/v1.0/aws/AmazonRDS/current/region_index.json")
offer = get(idx["regions"]["ap-northeast-1"]["currentVersionUrl"])
print("version", offer["version"])

def price(usagetype, engine=None):
    for sku, p in offer["products"].items():
        a = p["attributes"]
        if a.get("usagetype") != usagetype:
            continue
        if engine and a.get("databaseEngine") not in (engine, "Any"):
            continue
        for term in offer["terms"]["OnDemand"].get(sku, {}).values():
            for dim in term["priceDimensions"].values():
                return float(dim["pricePerUnit"]["USD"])

rds_maz = price("APN1-Multi-AZUsage:" + CLS, "MySQL")
rds_gp3 = price("APN1-RDS:Multi-AZ-GP3-Storage", "MySQL")
au_std = price("APN1-InstanceUsage:" + CLS, "Aurora MySQL")
au_iop = price("APN1-InstanceUsageIOOptimized:" + CLS, "Aurora MySQL")
au_sto = price("APN1-Aurora:StorageUsage", "Aurora MySQL")
au_sto_iop = price("APN1-Aurora:IO-OptimizedStorageUsage", "Aurora MySQL")
au_io = price("APN1-Aurora:StorageIOUsage", "Aurora MySQL")

rds = rds_maz * HOURS + rds_gp3 * GB
std_base = au_std * 2 * HOURS + au_sto * GB
iopt = au_iop * 2 * HOURS + au_sto_iop * GB

print(f"RDS Multi-AZ（待機系は読めない） {rds:8.2f} USD/月")
for io_m in (50, 200, 500, 1000):           # 月間I/O（100万回単位）
    std = std_base + au_io * io_m * 1_000_000
    print(f"Aurora Standard I/O {io_m:>4}百万回   {std:8.2f} USD/月")
print(f"Aurora I/O-Optimized            {iopt:8.2f} USD/月")
print(f"StandardとI/O-Optimizedの分岐点   {(iopt - std_base) / au_io / 1e6:.0f} 百万回/月")
rr = price("APN1-InstanceUsage:" + CLS, "MySQL") * HOURS + price("APN1-RDS:GP3-Storage", "MySQL") * GB
print(f"RDS Multi-AZ＋リードレプリカ1台  {rds + rr:8.2f} USD/月")
print(f"上記とAurora Standardの分岐点     {(rds + rr - std_base) / au_io / 1e6:.0f} 百万回/月")

# 出力（version 20261001060230）
# RDS Multi-AZ（待機系は読めない）   474.22 USD/月
# Aurora Standard I/O   50百万回     522.18 USD/月
# Aurora Standard I/O  200百万回     558.18 USD/月
# Aurora Standard I/O  500百万回     630.18 USD/月
# Aurora Standard I/O 1000百万回     750.18 USD/月
# Aurora I/O-Optimized              686.18 USD/月
# StandardとI/O-Optimizedの分岐点   733 百万回/月
# RDS Multi-AZ＋リードレプリカ1台    711.33 USD/月
# 上記とAurora Standardの分岐点     838 百万回/月

Auroraのストレージ単価は料金データ上でエンジンが「Any」として登録されているため、絞り込みで両方を許しています。取り出した単価は、RDSのdb.r8g.largeがMulti-AZで毎時0.574USD、Auroraの同じクラスがStandardで0.333USD、I/O-Optimizedで0.433USDでした。ストレージは1GBあたり月額で、RDSのMulti-AZ用gp3が0.276USD、AuroraのStandardが0.12USD、I/O-Optimizedが0.27USDです。Standardだけ、I/O 100万回ごとに0.24USDが加わります。

バックアップも差があります。保持期間の無料枠を超えた分は、RDSが1GBあたり月0.095USD、Auroraが0.023USDでした。スナップショットを長く残す運用では、この差が月額に効いてきます。

月間I/O 7.33億回でI/O-Optimizedが逆転する損益分岐の読み方

I/O料金を除いた時点で、Aurora Standardの2台構成はRDSのMulti-AZより月35.96USD高くなります。ただしRDSの待機系は読めないので、読み取りを分散するならリードレプリカを1台足した月711.33USDと比べるのが公平です。この比較では、AuroraはI/Oが月8.38億回に達するまで安く収まります。

Aurora内部の選択では、月7.33億回が分岐点です。この点でのI/O料金は月176USDで、総額686.18USDの約26%にあたります。Auroraのストレージ構成の説明にある「I/Oの支出が総額の25%以上ならI/O-Optimized」という目安と、東京の実額でもほぼ一致しました。

切り替えには回数の制約があります。StandardからI/O-Optimizedへの変更は30日に1回までで、逆方向はいつでも戻せます。NVMeを持たないクラスなら切り替えに停止は伴いません。迷うときはStandardで始め、次の手順でI/O量を1か月測ってから決める順番にします。

CloudWatchのVolumeReadIOPsを使うAuroraのI/O料金試算手順

Auroraで課金されるI/O回数は、AuroraのCloudWatchメトリクスのVolumeReadIOPsとVolumeWriteIOPsで確かめられます。どちらもクラスター単位の5分ごとの回数で、読み取りはバッファキャッシュに無いページをストレージから読んだときに数えられます。

# 9月の1か月間に課金対象になった読み取りI/Oと書き込みI/Oの合計回数を出す
for M in VolumeReadIOPs VolumeWriteIOPs; do
  aws cloudwatch get-metric-statistics \
    --namespace AWS/RDS --metric-name "$M" \
    --dimensions Name=DBClusterIdentifier,Value=app-db-aurora \
    --start-time 2026-09-01T00:00:00Z --end-time 2026-10-01T00:00:00Z \
    --period 86400 --statistics Sum \
    --query "sum(Datapoints[].Sum)" --output text --region ap-northeast-1
done

2つの合計に0.24を掛け、100万で割った値が月のI/O料金です。この金額がAuroraの月額全体の25%を超えていれば、I/O-Optimizedへ切り替える候補になります。

RDSで稼働中のDBの見積もりには注意が要ります。同じページで、AuroraのWriteIOPSは8KBのページ書き込みではなくストレージへのログレコードの数と説明されており、EBSのIOPSとは数え方が違います。RDSのReadIOPSとWriteIOPSをそのまま当てはめず、スナップショットから検証用のAuroraを作って本番に近い負荷を流し、上のコマンドで測ってください。

フェイルオーバーの停止時間をCLIでRDSとAuroraそれぞれ確かめる手順

書き込みが止まる時間は、構成ごとに公式の目安が分かれています。いずれもトランザクションの大きさや負荷によって延びる値です。

公式の目安で比べるRDS Multi-AZの60〜120秒とAuroraの30秒未満

構成 停止時間の公式の目安
RDS Multi-AZ DBインスタンス 通常60〜120秒
RDS Multi-AZ DBクラスター 通常35秒未満
Aurora（リーダーあり） 60秒未満・多くは30秒未満
Aurora（リーダーなし） 作り直しで通常10分未満

RDSの2行はMulti-AZ DBインスタンスのフェイルオーバーとMulti-AZ DBクラスターのフェイルオーバー、Auroraの2行は前章で触れた高可用性の説明によります。注意したいのは最終行です。リーダーを持たないAuroraは障害時にライターを作り直すため、RDSのMulti-AZより長く止まります。Auroraを選ぶなら、別のアベイラビリティーゾーンにリーダーを最低1台置く構成が前提になります。

表の2行目のMulti-AZ DBクラスターは、RDSの中で読み取り可能な待機系を2台持つ構成です。使えるクラスはdb.r8gdやdb.m8gdなどローカルNVMe付きに限られ、東京のgp3ストレージ単価は1GBあたり月0.414USDでした。Multi-AZ DBインスタンスの1.5倍にあたります。

強制フェイルオーバーを実行して書き込みの停止秒数を測るスクリプト

目安の秒数は、アプリ側のDNSキャッシュやコネクションプールの設定で変わります。検証環境で次の2つを同時に動かすと、自分の構成での停止時間を秒単位で記録できます。1つ目は、MySQL互換のDBへ1秒ごとに接続し、書き込みできるライターにつながったかを @@innodb_read_only の値で判定するループです。

# 1秒ごとに接続し、ライターなら OK、接続失敗か読み取り専用なら NG を表示する
# RDSはインスタンスのエンドポイント、Auroraはクラスターエンドポイントを指定する
ENDPOINT=app-db-aurora.cluster-xxxxxxxx.ap-northeast-1.rds.amazonaws.com
export MYSQL_PWD='検証用のパスワード'
while true; do
  RO=$(mysql -h "$ENDPOINT" -u admin --connect-timeout=2 -N -e "SELECT @@innodb_read_only" 2>/dev/null)
  if [ "$RO" = "0" ]; then echo "$(date +%T) OK"; else echo "$(date +%T) NG"; fi
  sleep 1
done

別の端末から、RDSはreboot-db-instanceの --force-failover、Auroraはfailover-db-clusterでフェイルオーバーを起こします。

# RDS（Multi-AZ DBインスタンス）：再起動と同時に待機系へ切り替える
aws rds reboot-db-instance --db-instance-identifier app-db-rds \
  --force-failover --region ap-northeast-1

# Aurora：指定したリーダーを新しいライターに昇格させる
aws rds failover-db-cluster --db-cluster-identifier app-db-aurora \
  --target-db-instance-identifier app-db-aurora-2 --region ap-northeast-1

NGが続いた行数が、書き込みの停止秒数です。Auroraでは切り替え後に元のライターがリーダーとして戻るため、古いDNSの値をつかんだ接続は読み取り専用のノードにつながり、値1が返ってNGになります。この時間が長い場合の対処は、アプリのDNSキャッシュを60秒以下にするか、RDS Proxyによる接続プールを挟む方法です。Auroraの高可用性の説明では、RDS ProxyでAuroraのフェイルオーバー時間を最大66%短縮できるとしています。クラスターの作成から検証用の削除までの手順はAurora（AWS）の構築手順にまとめました。

RDSからAuroraへ移るときに変わる接続先と移行方式の選び方

Auroraへ移ると決めた後に作業が発生するのは、アプリの接続先と移行中の停止時間の2つです。SQLの書き換えはほとんど発生しません。

インスタンス単位からクラスター単位へ変わるエンドポイントの書き換え

RDSのアプリは、DBインスタンスのエンドポイント1つに接続しています。Auroraでは、クラスターエンドポイントが常に現在のライターを指し、読み取り用のリーダーエンドポイントが別にあります。書き込みの接続先をクラスターエンドポイントへ、読み取り専用のクエリをリーダーエンドポイントへ向ける2か所が書き換えの対象です。

パラメータの置き場所も、移行に伴って変わる箇所です。Auroraにはクラスター全体に効くDBクラスターパラメータグループと、インスタンスごとのDBパラメータグループの2層があり、RDSで変えていた値をどちらに移すかを1つずつ確かめます。読み書きを分ける実装例はリードレプリカの作成手順と読み書き分離の実装で扱っています。

Auroraリードレプリカで移す方式とスナップショット復元の停止時間の差

RDS for MySQL・PostgreSQLからは、前出のレプリケーションの説明にあるとおり、RDSインスタンスを元にAuroraのリードレプリカを作って移すのが基本です。複製が追いついてから昇格させれば、書き込みを止めるのは昇格と接続先の切り替えにかかる時間だけで済みます。スナップショットから復元する方式は手順が単純な代わりに、取得から切り替えまでの書き込みを止めるか、差分を別の手段で移す必要があります。

エンジン別の具体的なコマンドは、MySQLならAurora MySQLの実装ガイド、PostgreSQLならAurora PostgreSQLの対応バージョンと移行判断に載せています。

受託開発でRDSとAuroraを選び分ける採用条件と見送るべき場面

ここまでの数値をもとに、新規構築と既存DBの見直しで使う判断基準を示します。

Auroraを選ぶのは読み取り分散・30秒前後の復旧・64TiB超のとき

次のどれか1つに当てはまれば、Auroraに決めて構いません。

  • 読み取りの負荷を分散したい。リードレプリカを足す構成なら、I/Oが月8億回前後まではAuroraのほうが安い
  • 障害時の書き込み停止を30秒前後に抑えたい。決済や予約のように、1〜2分の停止が売上に直結するシステムが該当する
  • データが64TiBを超える見込みがある。RDS for MySQL・PostgreSQLの上限を超える

反対に、待機系を読み取りに使わずI/Oも少ないDBをAuroraにしても、同じ2台構成で月36USDほど高くなるだけです。Auroraの機能を使う予定が無いなら選ぶ理由はありません。

RDSのままにする小規模DBとSQL Server・Oracle案件の判断基準

社内向けの業務システムで、データが数十GB、同時接続が数十程度に収まるDBはRDSのままにします。1〜2分のフェイルオーバーを夜間のメンテナンスウィンドウで受け止められるなら、Auroraの短い停止時間に追加の費用を払う必要はありません。クラスの決め方はRDSのインスタンスタイプの選び方、総額の試算はAWS RDSの料金を東京リージョンの実額で計算した記事を参照してください。

SQL Server・Oracle・Db2の案件は、Auroraに対応エンジンが無いためRDSで決まりです。PostgreSQL互換へ書き換えてまでAuroraへ寄せると、移行工数がDB費用の差を大きく上回ります。既存DBをどちらに寄せるか、移すならどの方式で止めずに移すかの判断は、データベース設計・移行支援で現状の構成とメトリクスの確認から請け負っています。

よくある質問

RDSとAuroraの比較で、選定と移行の段階によく出る質問に答えます。

RDSとAuroraはどちらが安いですか？

同じクラスの2台構成なら、I/Oが少ないうちはRDSのMulti-AZが安くなります。東京のdb.r8g.large・200GBでは、RDSのMulti-AZが月474.22USD、Aurora StandardがI/O料金を除いて月510.18USDでした（2026年10月1日版の単価）。読み取り用のレプリカを足す構成ではRDSが月711.33USDに上がり、AuroraがI/O月8.38億回まで安く収まります。バックアップ超過分の単価はAuroraのほうが安い点も含めて比べてください。

RDSのMulti-AZ DBクラスターとAuroraは何が違いますか？

どちらも読み取り可能な待機系を持ちますが、Multi-AZ DBクラスターはRDSの機能で、ライター1台とリーダー2台の固定構成です。データは各インスタンスのEBSへ半同期で複製され、フェイルオーバーは通常35秒未満とされています。使えるクラスはdb.r8gdなど、ローカルNVMe付きのクラスに限定される仕様です。Auroraはリーダーを0〜15台の範囲で増減でき、ストレージは全インスタンスで共有します。

Aurora Serverless v2にすればRDSより安くなりますか？

負荷が一日中ほぼ一定のDBでは高くなります。東京のServerless v2は1ACUあたり毎時0.15USDで、db.r8g.largeと同じ16GiB相当の8ACUで動かし続けると毎時1.20USDです。プロビジョンドのAurora Standardの0.333USDの3倍を超えます。夜間はほぼ使われない開発環境や、アクセスの山が短いシステムで効く選択肢です。仕組みはAurora Serverless v2の料金とスケーリングで解説しています。

RDSからAuroraへ移るとアプリの修正は必要ですか？

SQLの書き換えはほとんど要りません。Aurora MySQLはMySQL互換、Aurora PostgreSQLはPostgreSQL互換で、ドライバーもそのまま使えます。修正が必要になるのは接続先で、書き込みはクラスターエンドポイント、読み取りはリーダーエンドポイントへ向けます。MySQLのバージョンごとの細かな差分は、Aurora MySQLの実装ガイドで確認してください。

AuroraからRDSへ戻すことはできますか？

戻せますが、AuroraのスナップショットをそのままRDSへ復元する方法はありません。Aurora MySQLからはバイナリログレプリケーションでRDS for MySQLへ複製するか、mysqldumpなどの論理バックアップで移します。Aurora PostgreSQLから戻す際に使うのは、論理レプリケーションかpg_dumpです。戻る可能性がある案件では、バックトラックのようなAurora固有の機能に頼らない作りにしておくと移行が楽になります。

関連記事

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

この記事は以下の記事からリンクされています

この記事に関連するサービス

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.09.05　コラム eKYCとは？方式の違いと2027年4月の犯収法改正で変わる本人確認要件
  2. 2026.10.03　テックブログ AWS Snowconeとは：サービス終了後の現状とDataSync・Greengrassへの移行手順【2026年版】
  3. 2026.10.03　テックブログ foliumとは：Pythonで地図を作る使い方・タイルの注意点・1.0候補版の変更点【2026年版】
  4. 2026.01.22　テックブログ Xアルゴリズム最新（2026年9月）｜おすすめの仕組みと公開コードの重み一覧
  5. 2026.10.03　コラム ワークフローシステムの通知機能の設計：承認を止めないリマインド・催促と宛先の絞り方

RELATED POSTS 関連記事

一覧へ戻る

目次