Amazon Auroraは、AWSのマネージドデータベースであるAmazon RDSのエンジン選択肢の1つです。ただし中身は通常のRDSと別物で、データを3つのアベイラビリティゾーン（AZ）へ6重に複製する分散ストレージ層と、SQLを処理するDBインスタンスを切り離した構造を持ちます。本記事では、Auroraの仕組みと標準RDSとの違い、Standard／I/O-Optimizedの料金構成を整理したうえで、AWS CLIでクラスターを作って接続し、I/O比率を実測して料金構成を決めるまでのコマンドも載せました。最後に、採用すべき条件と見送るべき場面を言い切ります。
まとめ：Amazon Auroraの仕組み・料金構成と採用判断の要点
Amazon Auroraは、Amazon RDSのエンジン選択肢の1つでありながら、内部構造が通常のRDSと大きく異なるデータベースです。データの保存先はインスタンスに紐づくストレージではなく、3つのAZへ6重で複製する分散ストレージ層で、コンピュート（DBインスタンス）とストレージを分離しています。この設計により、Multi-AZのスタンバイを別途立てなくても高い耐久性を確保でき、最大15台までのリードレプリカ追加やフェイルオーバーも通常のRDSより速く済みます。互換エンジンはMySQL互換とPostgreSQL互換の2系統です。
料金はStandardとI/O-Optimizedの2構成から選び、I/O支出が総額の25%を超えるかどうかで有利な側が入れ替わります。単価は同等の標準RDSエンジンよりやや高い傾向がある一方、可用性や書き込みスループットの要求が高いほど総額で見合いやすくなります。深いOS制御や特殊な拡張が要る要件はEC2自前構築、標準的で運用を軽くしたい要件は標準RDS、という順で候補を絞り、可用性と書き込みスケールが足りない場合にAuroraへ寄せる判断が実務的です。
手を動かして確かめたい実装者向けに、本記事の中盤ではAWS CLIでの最小構成の作成、ライター／リーダーのエンドポイントへの接続確認、CloudWatchメトリクスからI/O比率を出す集計コマンドを載せました。料金構成は感覚で決めず、この集計結果で決めてください。
Amazon Auroraの仕組みと3AZ6重複製の分散ストレージ・2系統エンジン
Auroraを設計へ落とし込むには、通常のリレーショナルデータベースと何が違うのかを先に押さえます。ここを曖昧にすると、Auroraの利点である可用性と読み取り拡張を活かせないまま単価だけ高い構成を組みかねません。リレーショナルデータベースそのものの前提は、データベースの種類と選び方を整理した記事で確認できます。
3AZ6重複製の分散ストレージ層とコンピュート/ストレージ分離
Auroraの最大の特徴は、DBインスタンスとストレージを切り離し、ストレージを独立した分散層として持つ点です。書き込まれたデータは「クラスターボリューム」と呼ばれる1つの仮想ボリュームに入り、3つのAZに合計6つのコピーとして分散保存されます。一部のディスクやAZに障害が起きても、残りのコピーから読み書きを続けられる仕組みです。AWSのAurora storageのドキュメントには、複製の量はクラスター内のインスタンス数と無関係であり、インスタンスを足してもテーブルデータは再コピーされないと明記されています。
ボリュームは使った分だけ自動で広がり、テーブルを削除すれば確保量も縮みます。上限はエンジンの版で決まり、2026年9月時点のAurora size limitsでは、Aurora MySQL 3.10系以降とAurora PostgreSQL 17.5系・16.9系・15.13系以降が256TiB、それより前の版が128TiBです。1テーブルの上限は別にあり、Aurora MySQLで64TiB、Aurora PostgreSQLで32TiB。容量を事前に見積もって確保する運用は要りませんが、大きなテーブルはパーティション分割を前提に設計してください。
MySQL互換・PostgreSQL互換という2系統とバージョン選定の考え方
Auroraは独自エンジンでありながら、MySQL互換とPostgreSQL互換の2系統を提供し、既存アプリのドライバやSQLをほぼそのまま使えるよう設計されています。新規構築でどちらを選ぶかは、既存資産の互換性と必要な拡張機能で決めるのが起点です。MySQL互換版の具体的なバージョンや移行時の前提は、Aurora MySQLの全体像と移行の前提を整理した記事で確認できます。互換とはいえ完全に同一ではないため、依存する関数や拡張が対応済みかを移行前に検証する手順を挟むと安全です。MySQL 8.0との具体的な差分と、RDS for MySQLからAuroraリードレプリカで移行するCLI手順は、Aurora MySQLの実装ガイドにまとめています。PostgreSQL互換版の対応バージョンと拡張機能の可否は、Aurora PostgreSQLとは？対応バージョン・拡張機能とRDSからの移行判断で整理しています。
版の選び方には、前述のボリューム上限も絡みます。256TiBまで伸ばしたいなら、Aurora MySQLは3.10系（MySQL 8.0.42互換）以降が条件です。利用できる版の一覧はリージョンごとに異なるため、後述のCLI章にある describe-db-engine-versions で実際の候補を取ってから決めます。
リードレプリカ・フェイルオーバー・グローバルデータベースの可用性
Auroraはストレージ層を共有する仕組みのため、リードレプリカ（Aurora Replica）を最大15台まで追加してもデータの再コピーが不要で、レプリカ遅延を小さく保てます。プライマリに障害が起きた際は、レプリカの1台が数十秒程度で昇格してフェイルオーバーが自動的に完了する仕組みです。さらに複数リージョンをまたいで読み取りと災害対策を強化したい場合は、Aurora Global Databaseで別リージョンに複製し、リージョン障害時の切り替え先を持てます。読み取り負荷の分散はレプリカ、書き込みの継続性はフェイルオーバー、地理的な冗長はGlobal Databaseと、役割の違うレイヤーを目的別に使い分けてください。CLIで実際にクラスターを作り、フェイルオーバーで接続が何秒途切れるかを測る手順は、Aurora（AWS）の構築手順とフェイルオーバー検証を解説した記事で扱っています。レプリカでも足りないほど同じ参照が集中する場合は、Amazon ElastiCacheのインメモリキャッシュを前段に置く構成も検討できます。
Amazon Auroraと標準RDSエンジン・関連サービスの違いと使い分け
Auroraで次に迷うのが、通常のRDSやAurora系の派生サービスとの線引きです。名前が似た選択肢が複数あるため、構造の違いから候補を絞ります。東京リージョンの実額で月額を並べた試算とフェイルオーバーの停止時間の比較は、RDSとAuroraの違いを実測で比べた記事にまとめています。なお、提供が終了したAmazon QLDBからの移行先としてもAurora PostgreSQLが案内されており、台帳データベースの仕組みと移行の判断はAmazon QLDBとは何かと移行先を解説した記事で確認できます。
標準RDS（MySQL/PostgreSQL）とAuroraのアーキテクチャの違い
通常のRDSがインスタンスに紐づくブロックストレージへ書き込み、可用性は別AZのスタンバイへ同期レプリケーションして担保するのに対し、Auroraは分散ストレージ層そのものが冗長化されています。このため、標準RDSがMulti-AZスタンバイのインスタンス料金を二重に負担するのに対し、Auroraはスタンバイの二重課金なしに高い耐久性を確保できる点が構造的な差です。製品ファミリーとしての位置づけや対応エンジン全体像は、Amazon RDSの仕組みと対応エンジンを解説した記事で整理できます。まず標準RDS、可用性と書き込みスループットが足りなければAurora、という順で検討するのが定石です。
| 比較観点 | 標準RDS | Aurora |
|---|---|---|
| データの置き場所 | インスタンス付属の領域 | 3AZ共有のボリューム |
| 容量の確保 | 事前に割り当てて拡張 | 使用量に応じて自動増減 |
| 高可用性の担保 | Multi-AZスタンバイ | ストレージ自体が冗長 |
| 読み取り拡張 | レプリカへ非同期複製 | 共有ボリュームを参照 |
Aurora ServerlessとプロビジョンドのキャパシティモデルとACU
Auroraにはインスタンスクラスを固定するプロビジョンド構成と、負荷に応じて自動でスケールするサーバーレス構成があります。Aurora Serverless v2はACU（Aurora Capacity Unit）という単位で容量を増減し、1ACUはメモリ約2GiBと対応するCPU・ネットワークの組み合わせです。How Aurora serverless worksによれば、容量範囲は0〜256ACUで、最小0ACUの自動一時停止はAurora MySQL 3.08系以降、Aurora PostgreSQL 16.3系・15.7系・14.12系・13.15系以降が対象です（2026年9月時点）。アクセスの波が読みにくい開発環境や、間欠的にしか動かないワークロードでコストを抑えやすい構成といえます。
逆に定常的に高い負荷がかかる本番ではプロビジョンドのほうが単価を読みやすくなります。同じクラスター内にプロビジョンドのライターとサーバーレスのリーダーを混在させる構成も取れるため、書き込みは固定、参照は波に合わせる、といった組み方も可能です。ACUのスケーリングやv1からの移行の具体は、Aurora Serverless v2の料金とスケーリングを解説した記事で確認できます。
Amazon Aurora DSQLとの違いと混同を避ける区別
名前が近いために混同しやすいのがAmazon Aurora DSQLです。DSQLはサーバーレスの分散SQLデータベースで、複数リージョンでの読み書きを前提としたアクティブ／アクティブ構成など、本体のAuroraとはアーキテクチャも用途も異なる別製品です。両者を取り違えると設計の前提を誤るため、区別して押さえておく必要があります。DSQLの概要と適する場面は、Amazon Aurora DSQLの基本概念を解説した記事で確認できます。本記事が扱うのはMySQL/PostgreSQL互換の本体Auroraです。
Amazon AuroraをAWS CLIで試す手順と接続エンドポイントの確認方法
ここからは、仕組みの理解を手元で確かめる最小構成の手順です。AWS CLI v2が設定済みで、VPC内にDBサブネットグループとセキュリティグループがある前提で進めます。CLI自体の導入と認証設定は、AWS CLIの導入と運用をまとめた記事を参照してください。
CLIでAuroraクラスターとライターインスタンスを作る最小構成の手順
注意点が1つあります。create-db-clusterのCLIリファレンスにあるとおり、CLIでクラスターを作っても、コンソールと違ってDBインスタンスは自動で作られません。クラスター（ストレージと設定の器）を作ってから、create-db-instance でライターを足す2段構えになります。これは先に述べた「コンピュートとストレージの分離」がそのままAPIに表れた形です。
# 1. 利用できるAurora MySQLの版をリージョンで確認する
aws rds describe-db-engine-versions --engine aurora-mysql \
--query "DBEngineVersions[].EngineVersion" --output text
# 2. クラスター（ストレージと設定）を作る。パスワードはSecrets Managerに管理させる
aws rds create-db-cluster \
--db-cluster-identifier demo-aurora \
--engine aurora-mysql \
--master-username admin \
--manage-master-user-password \
--storage-type aurora \
--db-subnet-group-name demo-db-subnets \
--vpc-security-group-ids sg-0123456789abcdef0
# 3. ライターのDBインスタンスを足す（CLIではここまでやって初めて接続できる）
aws rds create-db-instance \
--db-instance-identifier demo-aurora-writer \
--db-cluster-identifier demo-aurora \
--db-instance-class db.t4g.medium \
--engine aurora-mysql
aws rds wait db-instance-available --db-instance-identifier demo-aurora-writer--storage-type は aurora がStandard、aurora-iopt1 がI/O-Optimizedです。--manage-master-user-password を付けるとマスターパスワードがSecrets Managerに保存され、ローテーションもAWS側に任せられます。シークレットの料金とローテーション設計はAWS Secrets Managerの解説記事で扱っています。検証が終わったら delete-db-instance と delete-db-cluster --skip-final-snapshot の順で消し、課金を止めてください。
クラスターエンドポイントとリーダーエンドポイントの使い分けと接続確認
Auroraでは、アプリはインスタンスのホスト名ではなく「エンドポイント」に接続します。Aurora endpoint connectionsが定める種類は、書き込み用のクラスターエンドポイント、レプリカ間で接続を振り分けるリーダーエンドポイント、任意のインスタンス群を束ねるカスタムエンドポイント、個別のインスタンスエンドポイントの4つ。フェイルオーバー後も接続先を自動で付け替えるのは前の2つなので、アプリの設定はこの2つだけを使います。
# ライター／リーダーのエンドポイントとストレージ構成を一覧する
aws rds describe-db-clusters --db-cluster-identifier demo-aurora \
--query "DBClusters[0].{Writer:Endpoint,Reader:ReaderEndpoint,Port:Port,Storage:StorageType}" \
--output table
# Secrets Managerに入ったマスターパスワードを取り出す
SECRET_ARN=$(aws rds describe-db-clusters --db-cluster-identifier demo-aurora \
--query "DBClusters[0].MasterUserSecret.SecretArn" --output text)
aws secretsmanager get-secret-value --secret-id "$SECRET_ARN" \
--query SecretString --output text
# 接続先がライターかリーダーかを確かめる（innodb_read_only が 0 ならライター）
mysql -h demo-aurora.cluster-xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com -u admin -p \
-e "SELECT @@aurora_version, @@innodb_read_only;"リーダーエンドポイントは、ホスト名に入る cluster-ro- が目印です。レプリカを1台足してからリーダー側で同じSELECTを実行し、innodb_read_only が1になれば読み書き分離の経路は正しく通っています。アプリ側での読み書きの振り分け方はRDS・Auroraのリードレプリカと読み書き分離の実装を解説した記事に、フェイルオーバー時の接続の張り直しを和らげる接続プールはRDS Proxyの仕組みと導入手順の記事にまとめています。
Amazon Auroraの料金とStandard／I/O-Optimizedの選び分け
Auroraのコストは、同じエンジンでも料金構成の選び方で大きく変わります。I/Oの多寡を読み、可用性要件から逆算して構成を決めるのがコスト設計の起点です。
Auroraの課金要素とDBインスタンス・ストレージ・I/Oの内訳
Auroraの料金は、DBインスタンスの稼働時間に、分散ストレージの使用量、そしてデータベースへのI/Oリクエストが積み上がる構造です。加えて、バックアップの保持超過分やデータ転送、Global Databaseのリージョン間レプリケーションなどが要件に応じて上乗せされます。標準RDSと同様、定常稼働が読める本番ではリザーブド相当のコミットで単価を下げられます。まずどの要素が支出の大半を占めるかをCloudWatchのメトリクスで実測し、削減の打ち手を要素ごとに選ぶ順序が有効です。
| コスト要素 | 課金の考え方 | 抑える打ち手 |
|---|---|---|
| DBインスタンス | クラス×稼働時間 | コミットで単価削減 |
| ストレージ | 使用量に応じ自動拡張 | 不要データの整理 |
| I/Oリクエスト | 読み書き回数（Standard） | I/O-Optimizedへ切替 |
| リードレプリカ | 追加インスタンス分 | 参照負荷に応じ増減 |
StandardとI/O-Optimizedの分岐とI/O集約型ワークロードの判断
Auroraの料金構成にはStandardとI/O-Optimizedの2択があります。Standardはインスタンスとストレージに加えてI/Oリクエスト100万件ごとに課金する従量型で、I/Oが少ないワークロードに向きます。I/O-Optimizedはインスタンスとストレージの単価が上がるかわりに、読み書きI/Oの課金がなくなる構成です。Aurora料金ページの米国東部（バージニア北部）の単価で比べると、2026年9月時点でストレージはStandardが0.10 USD／GB月、I/O-Optimizedが0.225 USD／GB月（約2.25倍）、I/OはStandardで100万リクエストあたり0.20 USDです。東京リージョンの単価は同じページでリージョンを切り替えて確認してください。
分岐点は明示されています。AWSのストレージ解説では、I/O支出がAuroraの総支出の25%以上ならI/O-Optimized、25%未満ならStandardが適するとされ、料金ページはI/O集約型での削減幅を最大40%としています。まずStandardで運用してI/O比率を実測し、しきい値を超えたらI/O-Optimizedへ移す判断が堅実です。
CloudWatchのVolumeReadIOPsでI/O比率を実測する計算手順
25%の判定に要るのは、課金対象のI/O件数です。Auroraのメトリクス一覧では、クラスター単位の VolumeReadIOPs と VolumeWriteIOPs が「5分間ごとの課金対象の読み取り／書き込みI/O件数」と定義されています。インスタンス単位の ReadIOPS は毎秒平均で、課金とは対応しません。取り違えやすいので注意してください。
# 直近30日の課金対象I/O件数を合計する（読み取り）
aws cloudwatch get-metric-statistics \
--namespace AWS/RDS --metric-name VolumeReadIOPs \
--dimensions Name=DBClusterIdentifier,Value=demo-aurora \
--start-time 2026-08-31T00:00:00Z --end-time 2026-09-30T00:00:00Z \
--period 86400 --statistics Sum \
--query "sum(Datapoints[].Sum)"
# 書き込みも同じ形で合計する
aws cloudwatch get-metric-statistics \
--namespace AWS/RDS --metric-name VolumeWriteIOPs \
--dimensions Name=DBClusterIdentifier,Value=demo-aurora \
--start-time 2026-08-31T00:00:00Z --end-time 2026-09-30T00:00:00Z \
--period 86400 --statistics Sum \
--query "sum(Datapoints[].Sum)"2つの合計を足して100万で割り、リージョンのI/O単価を掛けたものが月のI/O料金です。これを同じ期間のAurora請求額（Cost Explorerでサービスと使用タイプを絞った値）で割れば、I/O比率が出ます。たとえばI/O料金が月300 USDで総額が1,000 USDなら30%で、I/O-Optimizedへの切り替え候補です。パラレルクエリを使うAurora MySQLはバッファプールを通らないため VolumeReadIOPs が増えやすく、集計期間にその処理が含まれているかも確かめます。
I/O-Optimizedへの切り替えコマンドと30日制限・再起動の注意点
切り替えは既存クラスターの設定変更で済み、データの移し替えは要りません。
# Standard から I/O-Optimized へ切り替える
aws rds modify-db-cluster --db-cluster-identifier demo-aurora \
--storage-type aurora-iopt1 --apply-immediately
# 反映を確認する（aurora-iopt1 と出れば完了）
aws rds describe-db-clusters --db-cluster-identifier demo-aurora \
--query "DBClusters[0].StorageType" --output text制約は2つです。1つ目は頻度で、StandardからI/O-Optimizedへの切り替えは30日に1回まで。逆方向はいつでも戻せます。2つ目は停止時間で、NVMe搭載でないインスタンスとサーバーレスは停止なしで切り替わりますが、NVMe搭載インスタンスではエンジンの再起動が入り、短時間の停止が起きます。月末のバッチなどI/Oが一時的に跳ねる時期だけを見て切り替えると、30日間は戻せても再び切り替えられない期間ができるため、少なくとも1か月分の集計で判断してください。
Amazon Auroraを採用すべき条件と標準RDS・EC2自前構築との切り分け
ここでは判断を言い切ります。Auroraは可用性と読み取り拡張に強い反面、単価は標準RDSよりやや高く、用途を選びます。自社システムのDB基盤をどこに置くかを、条件付きで見極めてください。
Amazon Auroraの採用が効くワークロードと要件の条件の見極め
採用が効くのは、可用性を仕組みで担保したい、読み取りトラフィックが多くレプリカで捌きたい、書き込みスループットや将来のデータ増加に余裕を持たせたい、という条件が重なるときです。具体例は、アクセスの多いWebサービスの本番DB、参照系の負荷が高いSaaSのバックエンド、複数リージョンで可用性を確保したい基幹システムが当てはまります。データが数十TiBを超える見込みなら、ボリューム上限が256TiBになる版を選べることも判断材料に加わります。こうしたAWS上のデータベース基盤を自社に取り入れるなら、AWSを含むクラウドインフラ構築の相談窓口で、Auroraと標準RDSの選定や可用性構成、料金構成の妥当性を相談するとよいでしょう。AWSやクラウドの全体像から検討したい場合は、クラウドとは何か・AWSの仕組みを事業者向けに解説した記事が上位の入り口になります。
標準RDSやEC2への自前構築へ寄せるべき場面と切り分けの判断
標準的なリレーショナルデータベースを、可用性はMulti-AZで足り、コストを優先したいという要件なら、Auroraではなく標準のRDS（MySQL/PostgreSQL）が向きます。単価が読みやすく、小〜中規模では総額を抑えられるためです。一方、RDSがサポートしないバージョンや拡張機能を使いたい、OSレベルで深くチューニングしたいといった要件では、EC2上に自前でDBを立てる構築が候補になります。EC2そのものの仕組みや料金は、Amazon EC2の構成要素と料金モデルを解説した記事で確認できます。サーバー費用だけならEC2自前が安く見えても、パッチやバックアップの運用が利用者に戻る点を織り込んで比較してください。
Amazon Auroraを見送るべき場面とはまりやすい失敗パターン
見送るべきなのは、I/Oも接続も少ない小規模なデータベースで、標準RDSやEC2自前のほうが総額を抑えられるケース、そしてAuroraがサポートしない特殊なストレージエンジンやバージョンに依存するシステムです。これらをAuroraで無理に組むと、分散ストレージの利点を活かせないまま単価だけ高い構成になりかねません。
もう1つの失敗パターンは、Standard構成のままI/O料金が支出の大半を占めているのに放置し、I/O-Optimizedへの切り替えを検討しないケースです。逆に、I/Oが少ないのにI/O-Optimizedを選ぶとストレージ割増分だけ損をします。アプリの接続先をインスタンスエンドポイントに直書きし、フェイルオーバー後に書き込みが失敗し続ける事故も典型です。料金構成はI/O比率の実測で選び、接続先はクラスター／リーダーの2エンドポイントに寄せる。この2点を守れば、Auroraの分散アーキテクチャの利点を無駄なく引き出せます。
よくある質問
Amazon Auroraの導入検討で実装者から多く挙がる質問を、一次情報に基づいて簡潔に整理します。
Amazon AuroraとAmazon RDSの違いは何ですか？
AuroraはRDSのエンジン選択肢の1つですが、内部構造が異なります。通常のRDSがインスタンスに紐づくストレージへ書き込むのに対し、Auroraは3つのAZに6重で複製する分散ストレージ層を持ち、コンピュートとストレージを分離した設計です。Multi-AZスタンバイを別途立てなくても高い耐久性を確保でき、リードレプリカやフェイルオーバーも速くなります。単価はやや高い傾向ですが、可用性や読み取り拡張の要求が高いほど総額で見合いやすくなります。
AuroraはMySQLやPostgreSQLとどこまで互換がありますか？
AuroraはMySQL互換とPostgreSQL互換の2系統を提供し、既存アプリのドライバやSQLをほぼそのまま使えるよう設計されています。ただし完全に同一ではないため、依存する関数や拡張機能、特定バージョン固有の挙動が対応済みかを移行前に検証する必要があります。たとえばAurora MySQL 3.10系はMySQL 8.0.42互換です。利用できる版はリージョンごとに異なるので、describe-db-engine-versions で候補を取得してから選んでください。
Aurora StandardとI/O-Optimizedはどちらを選ぶべきですか？
判断の軸はI/O支出の比率です。Standardはインスタンスとストレージに加えてI/Oごとに課金する従量型で、I/Oが少ない用途に向きます。I/O-Optimizedはストレージ単価が約2.25倍になるかわりにI/O課金がなく、AWSはI/O支出が総額の25%以上ならI/O-Optimizedを推奨しています。まずStandardで運用し、VolumeReadIOPs と VolumeWriteIOPs の月合計からI/O比率を出して判断してください。StandardからI/O-Optimizedへの切り替えは30日に1回までです。
Aurora Serverlessは通常のAuroraと何が違いますか？
Aurora Serverless v2は、インスタンスクラスを固定せずACU（1ACU≒メモリ2GiB）単位で負荷に応じて自動スケールする構成です。容量範囲は0〜256ACUで、対応する版では負荷がないときに0ACUまで下がる自動一時停止も使えます。アクセスの波が読みにくい開発環境や間欠的なワークロードでコストを抑えやすい一方、定常的に高負荷がかかる本番ではプロビジョンドのほうが単価を読みやすくなります。
Amazon Aurora DSQLとAmazon Auroraは同じものですか？
別の製品です。Aurora DSQLはサーバーレスの分散SQLデータベースで、複数リージョンでのアクティブ／アクティブな読み書きを前提とした構成など、本体のAurora（MySQL/PostgreSQL互換）とはアーキテクチャも用途も異なります。名前が近いため混同しやすいものの、設計の前提が変わります。検討の場では、どちらを指しているかを最初に明確にしてください。
関連記事
- Amazon RDSとは？仕組み・対応エンジンと料金モデル・採用判断を解説：Auroraを含むRDS製品ファミリー全体と標準エンジンとの位置づけを整理した記事
- Aurora（AWS）の構築手順：CLIでクラスター作成・接続・フェイルオーバー検証まで：本記事のCLI章の続きとして、フェイルオーバー時間の計測まで扱う手順記事
- Aurora MySQL 8.4の全体像と移行を検討する読者が押さえる前提：AuroraのMySQL互換版のバージョンと移行前提を具体的に確認できる記事
- Aurora Serverless v2とは？料金・ACUスケーリング・v1移行を解説：Auroraのサーバーレス構成の料金とスケーリングを深掘りした記事
- Amazon Aurora DSQLの概要と基本概念についての説明：混同しやすい別製品・分散SQLとの違いを確認するための記事
- クラウドとは？AWSとは何かを仕組み・料金・移行の判断まで解説：Auroraの前提となるクラウド・AWS全体像を事業者向けに整理した上位概念の記事
