「MySQL 互換って、乗り換えは大変?」
「高性能・高可用って、具体的に何が起きてるの?」
Aurora の説明でいちばん多い引っかかりが、「RDS と何が違うのか」です。ここを対比で片づけると、残りは一気にほどけます。
Amazon Aurora とは、MySQL・PostgreSQL と互換を保ちながら、クラウド向けに性能と可用性を作り込んだ AWS 製のリレーショナルデータベースです。
使い勝手は身近な DB のまま、中身のストレージの作りが違う。この一点が、速さと止まりにくさ、そして SAA での問われ方を決めています。以下では RDS と並べて立ち位置を掴み、なぜ止まりにくいのかを図で開き、互換の効く場面と選び方まで順に見ていきます。
1. まず RDS と並べる — Aurora の立ち位置
混乱の元は、Aurora と RDS を「別々のサービス」だと思ってしまうことです。実際は違います。Aurora は RDS の中で選べるエンジンの一つで、RDS の運用の枠組み（バックアップや監視の自動化）をそのまま受け継ぎます。
RDS では MySQL・PostgreSQL・Oracle など複数のエンジンを運用付きで動かせます。あなたがその一覧から Aurora を選ぶと、標準の MySQL/PostgreSQL とはストレージの作りが違う高性能版が手に入る、という関係です。だから「RDS か Aurora か」ではなく、「RDS の中で標準エンジンを取るか Aurora を取るか」が正しい問いになります。
RDS そのものの基本やマルチAZの考え方は AWS RDSとは で押さえると、この上位版の意味がはっきりします。
2. 止まりにくさの正体 — データを6つの写しに分ける
Aurora が「高可用」と呼ばれる理由は、ストレージの持ち方にあります。Aurora はデータを6つの写しとして、離れた3つのアベイラビリティゾーン（AZ）に分けて保管します。1か所のAZで障害が起きても、別のAZに写しが残るため、サービスを続けられます。図で見てください。
速さの方も、この作りが効きます。読み取りの負荷は、リードレプリカという読み取り専用の控えを足して分散できます。書き込みを受ける本体はそのままに、参照だけをレプリカへ逃がすことで、アクセスが多くても詰まりにくくなります。止まりにくさと速さは、別々の工夫ではなく「ストレージを分けて持つ」という同じ設計から生まれています。
3. MySQL・PostgreSQL 互換が効く場面
Aurora は MySQL 互換と PostgreSQL 互換の2系統から選べます。互換とは「同じように扱える」性質のことで、これがあると既存の SQL や接続の仕組み、使い慣れたツールをそのまま活かせます。あなたが一から覚え直す必要はありません。
互換がうれしいのは、次のような場面です。
- 今使っている MySQL/PostgreSQL の DB を、アプリを大きく書き換えずに移せる
- チームが慣れた操作やツールを、そのまま引き継げる
- 学習コストを抑えたまま、性能と可用性だけを引き上げられる
あなたが移行を考えるときは、もとの DB が MySQL 系か PostgreSQL 系かで、選ぶ Aurora の系統が決まります。ここを取り違えると互換の恩恵が薄れるため、先に元の DB のエンジンを確認しておくのが実務の順序です。表形式が向かないデータには別系統もあり、AWS DynamoDBとは と対比すると、DB の選び分けが立体的になります。
4. 標準RDSと Aurora、どちらを選ぶか
では、標準の RDS エンジンと Aurora、どちらを取るか。判断材料を表にしました。
| 観点 | 標準RDS（MySQL/PostgreSQL） | Aurora |
|---|---|---|
| ストレージ | 一般的な構成 | 6写し・3AZに分散 |
| 可用性 | マルチAZ等で高められる | もとから高い設計 |
| 読み取り拡張 | リードレプリカ対応 | 低遅延なレプリカを足しやすい |
| コスト感 | 小規模なら抑えやすい | 性能・可用性に見合う分の費用 |
| 向く場面 | 標準構成で足りるとき | 止められない・アクセスが多いとき |
当社のエンジニアが実務で見る軸は、シンプルに2つです。「止まると業務が止まる度合い」と「読み取りの多さ」。この2つが高いシステムなら、レプリカを足しやすく障害に強い Aurora が候補に上がります。逆に、たまに使う小さな社内ツールなら標準エンジンで足ります。あなたが機能から逆算して、過剰にも過小にもしないのが選び方の勘所です。
5. SAA での問われ方
SAA（ソリューションアーキテクト アソシエイト）では、Aurora は用語の暗記でなく要件マッチングの設計問題で登場します。問題文の要件を、Aurora の性質にひもづけられるかが得点の分かれ目です。あなたが押さえておきたい対応は、次のとおりです。
- 「単一AZの障害でもサービスを継続したい」→ 複数AZに分散する Aurora が候補
- 「読み取りが集中して遅い。書き込みは変えたくない」→ リードレプリカで参照を逃がす
- 「既存の MySQL を大きく作り替えずに性能を上げたい」→ Aurora MySQL 互換
要件文の中の「止めたくない」「読み取りが多い」「既存互換」というキーワードに反応できると、選択肢が絞れます。DB を置くネットワークやAZの土台は リージョンとアベイラビリティゾーンとは で押さえると、可用性設計の問題がさらに読みやすくなります。
次のステップ
Aurora が SAA のどのあたりで効くのかは、AWS SAAの試験範囲と勉強法ガイド で全体像を見ておくと、可用性設計の位置づけが掴めます。
問題で手応えを確かめるなら、AWS SAA 弾力性・回復性設計の問題集 で、Aurora を含む可用性設計の設問に当たっておくのがおすすめです。