Aurora か RDS か — マネージドDBの選定

AuroraとRDSは「どちらもマネージドDB」で片付けられがちですが、ストレージの作りから料金モデルまで前提が違います。エンジンの互換性だけでなく、可用性・スケール・コストの三軸で選定するための実務ポイントを整理します。

01「どちらもマネージドDB」で終わらせない

Amazon RDS と Amazon Aurora は、どちらも「フルマネージドのリレーショナルデータベース」です。パッチ適用・バックアップ・フェイルオーバーの自動化といった運用負荷の軽減は共通しています。ですが、この共通点だけを見て「MySQL / PostgreSQL が動くならどっちでもいい」と選ぶと、後々の可用性や料金で悩むことになります。

両者の本質的な違いは、ストレージの作りにあります。RDS はエンジン(MySQL、PostgreSQL、MariaDB、Oracle、SQL Server)を素直にマネージド化し、データは基本的にインスタンスに紐づく EBS ボリュームに書き込まれます。一方 Aurora は MySQL / PostgreSQL 互換のエンジンを AWS が再設計したもので、コンピュートとストレージを分離し、専用の分散ストレージ層に載せています。この一点が、可用性・スケール・料金のすべてに波及します。

現場のコツ：選定の第一問は「動かしたいエンジンは何か」ではなく「Aurora が対応するエンジン(MySQL / PostgreSQL)で要件を満たせるか」です。Oracle や SQL Server が要件なら RDS 一択で、そこで議論は終わります。MySQL / PostgreSQL が使えるなら、初めて Aurora と RDS を比較する土俵に立ちます。

02ストレージ設計の違い — ここが起点

RDS のストレージは、1つのインスタンスに1つ(または Multi-AZ で待機系にもう1つ)の EBS ボリュームが紐づく素直な構成です。書き込みはエンジンレベルの同期レプリケーションで待機系に反映されます。運用者から見て「よく知っている DB がそのままクラウドに載っている」安心感があります。

Aurora は根本的に違います。AWS 公式ドキュメントによれば、プライマリインスタンスへの書き込みは、単一リージョン内の3つのアベイラビリティゾーンにまたがる6つのストレージノードに同期レプリケーションされます。コンピュート(DBインスタンス)とストレージ(クラスターボリューム)が分離されているため、インスタンスが落ちてもデータはストレージ層に残ります。この設計が、後述する高速フェイルオーバーと読み取りスケールの前提になっています。

図：RDSはインスタンスにEBSが紐づく素直な構成、Auroraはコンピュートとストレージを分離し3AZ・6コピーの共有ストレージに載せる。

03可用性とフェイルオーバー

可用性の挙動も、ストレージ設計の違いがそのまま出ます。

RDS の Multi-AZ は、プライマリと待機系(スタンバイ)の2インスタンス構成が基本です。障害時は待機系に切り替わりますが、DNS の切り替えとウォームアップを含めて数十秒〜2分程度を見込むのが実務的です。待機系は通常クエリを受けないため、可用性のためだけのコストになります(RDS には複数の読み取り可能なスタンバイを持つ Multi-AZ DB クラスターもありますが、対応エンジン・リージョンに制約があります。公式で最新を確認してください)。

Aurora のフェイルオーバーは、リーダーインスタンス(Aurora レプリカ)をプライマリに昇格させる方式です。データは共有ストレージにあるため、コピーやログ再生が不要で速い。AWS 公式は「レプリカがある場合、サービスは通常60秒未満、多くは30秒未満で回復する」と明記しています。レプリカが1つもない場合はプライマリの再作成となり、通常10分未満かかるため、可用性を求めるなら異なるAZに最低1つはリーダーを置くのが定石です。

現場のコツ：フェイルオーバーの体感時間はDNSキャッシュに左右されます。RDS Proxy を挟むとアプリの接続を維持したままバックエンドを切り替えられ、AWS 公式は Aurora Multi-AZ でフェイルオーバー時間を最大66%短縮できるとしています。接続プールの枯渇やフェイルオーバーの遅さに悩むなら、まず RDS Proxy による接続管理を検討してください。

昇格の順序は制御できます。各リーダーに昇格ティア(優先度0〜15、0が最優先)を割り当てられ、同ティアなら大きいインスタンスが優先されます。本番系と分析系を混在させているクラスターでは、分析用の小さいリーダーが昇格しないようティアを設計しておくと安全です。

04読み取りスケールとレプリカ

読み取りのスケールアウトも両者で性質が異なります。

RDS のリードレプリカ：エンジンレベルの非同期レプリケーションで、レプリカごとに独立したストレージを持ちます。レプリカは独自のエンドポイントを持ち、レプリケーション遅延はワークロードやインスタンスサイズに依存します。エンジンにより最大レプリカ数に上限があります。
Aurora のリーダー：ライターと同じ共有ストレージを参照します。ストレージのコピーが不要なため追加が速く、遅延は一般に非常に小さい。最大15のリーダーを持て、リーダーエンドポイントが読み取りトラフィックを自動で分散します。

読み取り負荷が高く、レプリカを機動的に増減させたいワークロードでは、Aurora の共有ストレージ + リーダーエンドポイントの組み合わせが効いてきます。逆に、レプリカを1〜2台しか使わない小規模系では、この差はコストほど体感できないこともあります。

05Aurora Serverless v2 の使いどころ

Aurora には、キャパシティを需要に応じて自動で増減させる Aurora Serverless v2 があります。容量の単位は ACU(Aurora Capacity Unit)で、1 ACU はおよそ2 GiB のメモリと対応するCPU・ネットワークに相当します。

AWS 公式ドキュメントによれば、容量は0.5 ACU 刻みで最大256 ACU まで、需要に応じて細かくスケールします。さらに、最小 ACU を 0 に設定すると、一定時間接続がなければ自動的に一時停止(オートポーズ)し、次の接続で再開できます。開発・検証環境や、アクセスが夜間ゼロになるような業務系で効果が大きい機能です(数値・上限はバージョンやリージョンで変わるため、公式で最新を確認してください)。

現場のコツ：Serverless v2 は「常時高負荷なら割高、変動が激しい・アイドルが長いなら割安」になりやすい構成です。最小 ACU を極端に小さくすると、急な負荷スパイクでスケールアップが追いつかず遅延が出ることがあります。予測できるベースライン負荷がある本番系では、最小 ACU をベースライン相当に設定するか、プロビジョンド(固定インスタンス)と比較して決めるのが安全です。

06料金モデルの違い — I/O課金という落とし穴

料金は「インスタンス単価が高いか安いか」だけで比べると足をすくわれます。特に Aurora にはストレージI/Oの課金体系という論点があります。

Aurora には2つの構成があります。Aurora Standard はインスタンス・ストレージに加えてI/Oリクエストごとの従量課金が乗ります。Aurora I/O-Optimized は I/O を課金せず、コンピュートとストレージを高めの固定単価にした構成です。AWS 公式ブログは、I/OコストがAuroraの総額の約25%を超えるようなI/O集約ワークロードでは、I/O-Optimized で最大40%のコスト削減が見込めるとしています。切り替えは30日に1回まで、Standard への戻しは随時可能です。

RDS はエンジンのライセンスモデル(特に Oracle / SQL Server)、ストレージタイプ(gp3 / io2)、Multi-AZ の有無で構成がシンプルに決まります。I/O課金という独自の変数がない分、見積もりは素直です。

現場のコツ：Aurora Standard で運用中なら、CloudWatch の VolumeReadIOPs / VolumeWriteIOPs と請求内訳を突き合わせ、I/O料金が総額の何%かを必ず確認してください。25%を超えているなら I/O-Optimized への切り替えが有力です。逆にI/Oが軽いワークロードで I/O-Optimized を選ぶと、割高な固定単価だけを払うことになります。

07選定の判断軸 — 決定表

ここまでを踏まえ、実務で使える判断軸を整理します。まずエンジン、次に可用性・スケール要件、最後にコストの順で絞り込むのが定石です。

要件・状況	RDS が向く	Aurora が向く
エンジン	Oracle / SQL Server / MariaDB が必須	MySQL / PostgreSQL 互換で足りる
可用性	数十秒〜数分の切替を許容できる	30〜60秒未満の高速フェイルオーバーが欲しい
読み取りスケール	レプリカは1〜2台で足りる	多数のリーダーを機動的に増減したい
負荷の変動	負荷が安定・予測可能	変動が激しい/アイドルが長い(Serverless v2)
コスト志向	見積もりの単純さ・小規模で最小コスト	I/O集約でI/O-Optimizedの恩恵が大きい
運用の親しみ	既存の標準エンジンをそのまま載せたい	AWS再設計エンジンの特性を活かせる

図：エンジン→可用性・スケール→負荷変動の順に絞り込む選定フロー。最後にI/O課金を含めたコスト比較で確定する。

08移行の実務 — RDSからAuroraへ

既存 RDS(MySQL / PostgreSQL)から Aurora への移行は、いくつか定番のパターンがあります。要件(許容ダウンタイム、データ量)で使い分けます。

スナップショットからの移行：RDS のスナップショットを Aurora クラスターとして復元。手順は単純ですが、データ量に応じたダウンタイムが発生します。検証環境や許容停止時間が長い系に向きます。
Aurora リードレプリカ経由：RDS のリードレプリカとして Aurora を作成し、追いついたところで昇格・切り替え。ダウンタイムを短くできる定番手です(エンジン・バージョンの対応条件は公式で確認してください)。
AWS DMS：異種エンジン間や、より柔軟な移行が必要な場合。継続的レプリケーションでカットオーバーを最小化できます。

いずれの方式でも、移行後にアプリの接続先をクラスターエンドポイント(常に現在のプライマリを指す)とリーダーエンドポイント(読み取り分散)に正しく振り分けることが肝心です。読み取りをリーダーエンドポイントに寄せずライターに集中させたままだと、Aurora の読み取りスケールの利点を活かせません。移行はここで終わりではなく、パラメータグループやスロークエリの棚卸しまで含めて設計してください。オンプレDBの移行を含む案件では、Oracle TDEとPCI DSS対応の移行事例のような段取りの型も参考になります。

現場のコツ：移行の成否は「切り戻し(ロールバック)手順を先に決めておけるか」で決まります。カットオーバー当日に問題が出たとき、旧RDSに即戻せる状態を保ち、DNS・接続文字列の切替を一箇所に集約しておく。この段取りがあるだけで、移行のリスクは大きく下がります。実際の設計は導入事例のような伴走の中で詰めていくのが確実です。

—まとめ

Aurora と RDS の選定は、次の順で絞り込むと迷いません。

エンジンで足切り：Oracle / SQL Server が必須なら RDS。MySQL / PostgreSQL で足りるなら比較の土俵に立つ。
可用性・スケールで判断：30〜60秒未満の高速フェイルオーバーや多数リーダーが要るなら Aurora。数分の切替を許容でき、レプリカも少数なら RDS の素直さが効く。
負荷変動で構成を選ぶ：変動が激しい・アイドルが長いなら Aurora Serverless v2。安定負荷ならプロビジョンド。
最後にコストで確定：Aurora は I/O課金が総額の25%を超えるなら I/O-Optimized を検討。RDS は見積もりが素直。数値・上限はバージョン依存のため、必ず公式で最新を確認する。

「どちらもマネージドDB」ではなく、ストレージ設計の違いを起点に可用性・スケール・コストの三軸で見れば、選定は再現性のある判断になります。DBまわりの統制設計を含む全体像は、マルチアカウント統制の観点と合わせて整理すると、組織横断でも一貫した基準を持てます。

—参考(一次情報)

DBの選定・移行方式の設計でお悩みでしたら、お問い合わせください。現行構成と要件を踏まえて、Aurora / RDS の選定から移行手順まで一緒に設計します。

相談する

← ブログ一覧へ戻る