Amazon Auroraとは ― RDSとの違いと仕組み

Amazon RDSでデータベースを作るときに選べるエンジンの1つが、Amazon Auroraです。MySQLやPostgreSQLと互換のあるリレーショナルデータベースです。データを保存するストレージと、処理を行うインスタンスを分けた構成になっています。RDSとの違いは、この構成から生まれます。

Aurora MySQLでもAurora PostgreSQLでも、管理の方法はほかのRDSのエンジンと同じです。作成・パッチ適用・バックアップ・障害の検出などを、同じ画面とコマンドで行います。

互換があるので、MySQLやPostgreSQL用のコード・ツール・アプリケーションをAuroraでも使えます。AWSの説明では、同じようなハードウェアで比べたスループットは、標準のMySQLやPostgreSQLの最大6倍です。SQLの問い合わせを速くするチューニングは、RDSと同じく利用者が担当します。

Auroraでは、データベースをDBクラスターという単位で作ります。DBクラスターは、1台以上のDBインスタンスと、そのデータを保存するクラスターボリュームでできています。クラスターボリュームは、複数のAZにまたがる仮想のストレージです。

インスタンスには2つの役割があります。ライターは読み書きを受け持ち、ボリュームのデータを書き換えます。ライターは1台だけです。リーダーは読み取りだけを受け持ち、ライターのほかに最大15台置けます。リーダーはAuroraレプリカとも呼ばれます。

ライターが書き込んだデータは、3つのAZにある6つのストレージノードへ同期でコピーされます。コピーの数は、インスタンスが何台あっても変わりません。インスタンスが1台だけでも、ストレージは複数のAZに分かれています。そのため、Auroraではこれもクラスターと呼びます。

リーダーは、ライターと同じボリュームを読みます。そのため、リーダーを追加するときに表のデータをコピーする必要がなく、短時間で追加できます。AWSの説明によると、ライターの更新がリーダーから見えるまでの遅れは、通常100ミリ秒を大きく下回ります。

クラスターボリュームは、データが増えると自動で大きくなります。上限はエンジンのバージョンで決まり、新しいバージョンで256TiB、それより前は128TiBです。料金がかかるのは、実際に使っている容量だけです。

RDSのマルチAZ配置では、プライマリとスタンバイがそれぞれ自分のストレージを持ちます。データのコピーは、プライマリからスタンバイへ、インスタンスの間で同期して作ります。Auroraのインスタンスはストレージを持ちません。コピーはクラスターボリュームの中で作られます。

この違いから、AZの障害への対策も変わります。RDSでは、別のAZにデータを置くためにマルチAZ配置を選びます。Auroraでは、データは初めから3つのAZにあります。別のAZにリーダーを置くと、インスタンスの障害にも備えられます。AZの意味は、リージョンとAZの記事で説明しています。

RDSのマルチAZ配置には、スタンバイを2台置いて読み取りにも使う構成もあります。表のRDSの列は、RDSの記事で説明したスタンバイが1台の構成です。RDS for MySQLやRDS for PostgreSQLのデータは、スナップショットや複製でAuroraへ移せます。

ライターが使えなくなると、Auroraは自動でリーダーの1台をライターに昇格させます。この切り替えをフェイルオーバーと呼びます。切り替えの間は読み書きが失敗します。AWSの説明によると、通常60秒未満、多くは30秒未満で復旧します。

リーダーが無いクラスターでは、同じAZにライターを作り直します。こちらは、通常10分未満かかります。どのリーダーを先に昇格させるかは、0から15の優先度で決めておけます。

AZ全体が止まったときに自動で切り替わるのは、別のAZにリーダーがある場合です。インスタンスが1台だけのときや、全部が同じAZにあるときは、利用者が別のAZにインスタンスを作ります。そのためAWSは、2つ以上のAZにリーダーを置く構成を勧めています。

エンドポイントで、接続先を役割ごとに分ける

アプリケーションは、インスタンスを直接指定せず、エンドポイントという接続先に接続します。エンドポイントは、ホスト名とポートの組です。

• クラスターエンドポイント：そのときのライターにつながります。フェイルオーバーのあとも、同じ名前のまま新しいライターを指します。
• リーダーエンドポイント：読み取りの接続を、リーダーに振り分けます。
• カスタムエンドポイント：選んだ一部のインスタンスのグループにつながります。
• インスタンスエンドポイント：特定の1台につながり、診断やチューニングに使います。

書き込みはクラスターエンドポイントに、読み取りはリーダーエンドポイントに送るのが基本の分け方です。インスタンスエンドポイントは、そのインスタンスが止まっても接続先が切り替わりません。

次の図で要件を選ぶと、向いているサービスと、その理由・注意点が表示されます。RDSとAuroraのほかに、Aurora Serverless v2とGlobal Databaseも選べます。この2つは後の節で説明します。リレーショナルデータベースが合わない要件では、DynamoDBが表示されます。

使うエンジンが決まっていれば、RDSの中から選びます。MySQLかPostgreSQLで十分なら、Auroraが候補になります。キーで読み書きするNoSQLの使い方は、DynamoDBの記事で説明しています。何年分もの行を集計する分析には、Redshiftのようなデータウェアハウスが向きます。

Aurora Serverless v2は、負荷に合わせて、Auroraがインスタンスの容量を自動で増減する構成です。利用者は、インスタンスクラスの代わりに、容量の下限と上限を決めます。料金は、使った容量の分だけかかります。

容量の単位はACUです。1 ACUは、およそ2GiBのメモリと、それに見合うCPUとネットワークの組です。容量は最小0.5 ACUの刻みで変わり、容量が大きいほど刻みも大きくなります。増減の間も、処理は止まりません。設定できる範囲はエンジンなどのバージョンで変わり、新しいバージョンでは0〜256 ACUです。

下限を0 ACUにすると、処理が無いときにインスタンスが一時停止します。0 ACUを選べるのは、この機能に対応したバージョンだけです。Aurora PostgreSQLの一部の新しいバージョンでは、上限を384 ACUまで上げられます。

AWSは、アクセスの変動が大きく予測しにくい用途や、開発・テストの環境に向くとしています。一方、負荷が一定なら、インスタンスクラスを選ぶプロビジョンドのクラスターが向きます。料金も見積もりやすくなります。1つのクラスターの中で、プロビジョンドのインスタンスとServerless v2のインスタンスを混ぜることもできます。

ストレージは、プロビジョンドと同じクラスターボリュームです。今のユーザーガイドと料金ページは、この構成をAurora serverlessの名前で説明しています。構成の違う古いAurora Serverless v1は、非推奨の製品です。サーバの管理を利用者が行わない仕組み全般は、サーバーレスの記事で説明しています。

Aurora Global Databaseは、1つのデータベースを複数のリージョンにまたがって配置する機能です。書き込みを受けるプライマリのリージョンが1つあり、読み取り専用のセカンダリのリージョンを最大10個置けます。書き込みは、ストレージの層でセカンダリへ複製されます。反映までの遅れは通常1秒未満です。

リージョン全体が止まったときは、セカンダリのクラスターをプライマリに切り替えます。計画的な切り替えをスイッチオーバー、障害時の切り替えをフェイルオーバーと呼びます。スイッチオーバーでは、データを失いません。Global Databaseを使ってリージョンの障害に備える戦略は、AWSのDR戦略の記事で説明しています。どこまでデータを戻し、何時間で復旧させるかの目標は、BCPとDRの記事で説明しています。

2026年10月29日に料金ページで確認した、料金の決まり方は次のとおりです。

• インスタンス：プロビジョンドは動かした時間で、1秒単位、最低10分です。Serverless v2は、使ったACUの時間で数えます。
• ストレージ：使ったデータの量と月数で決まります。事前に容量を決める必要はありません。
• I/O：Aurora Standardは、読み書きの要求100万件ごとにかかります。Aurora I/O-Optimizedは、読み書きのI/Oにはかかりません。
• バックアップ：クラスターの大きさまでの分は、料金がかかりません。
• Global Database：セカンダリのリージョンへ複製した書き込みのI/Oにもかかります。

I/O-Optimizedは、I/Oが多い使い方のための設定です。ユーザーガイドは、I/Oの費用がAuroraの費用全体の25%以上なら、I/O-Optimizedを選ぶよう勧めています。プロビジョンドのインスタンスは、1年か3年のリザーブドインスタンスで割り引けます。

• AWS「What is Amazon Aurora?」と「Amazon Aurora DB clusters」
• AWS「Amazon Aurora storage」と「Quotas and constraints for Amazon Aurora」（ストレージの上限）
• AWS「High availability for Amazon Aurora」（6つのストレージノード、フェイルオーバー）
• AWS「Replication with Amazon Aurora」と「Amazon Aurora endpoint connections」
• AWS「Using Aurora serverless」と「How Aurora serverless works」
• AWS「Using Amazon Aurora Global Database」
• AWS「Configuring and managing a Multi-AZ deployment for Amazon RDS」（RDSのマルチAZ配置）
• Amazon Auroraの料金（2026年10月29日に確認）