はじめに
AWS Solutions Architect Associate (SAA) の学習中に整理した Amazon Aurora 関連の知識をまとめました。
Aurora は RDS と似ているようで異なる点が多く、特に「Aurora にスタンバイは存在しない」という最大の違いは試験で頻出です。
本記事は個人の学習ノートをベースにしています。誤りがあればコメントでご指摘いただけると助かります。
サービス概要
Aurora の特徴
- MySQL / PostgreSQL 互換
- 最大 15台 の Aurora Replicas
- 共有ストレージ（6コピー、3AZ）
- Aurora Replica のレプリケーションラグ: 10ミリ秒台
- Aurora にスタンバイは存在しない（RDS Multi-AZ との最大の違い）
Aurora vs RDS Multi-AZ の違い
この違いは試験で非常によく問われます。
| Aurora Multi-AZ | RDS Multi-AZ | |
|---|---|---|
| 読み取り用インスタンス | Aurora Replica（最大15台、読み取り可能） | なし（standby は読み取り不可） |
| エンドポイント | Writer + Reader Endpoint | 単一エンドポイント |
| フェイルオーバー先 | Aurora Replica | Standby インスタンス |
| 「standby インスタンス」 | 存在しない | 存在する |
| フェイルオーバー時間 | 通常30秒以内 | 60〜120秒 |
「Aurora に standby を作成する」という選択肢が出たら、それは不正解です。
Aurora のエンドポイント
| エンドポイント | 用途 | 接続先 |
|---|---|---|
| Cluster Endpoint（Writer） | 読み書き | Writer Instance |
| Reader Endpoint | 読み取り専用 | Aurora Replica（負荷分散） |
| Custom Endpoint | カスタム用途 | 指定したインスタンス群 |
| Instance Endpoint | 特定インスタンス | 個別インスタンス |
Reader Endpoint は複数の Replica へのロードバランシングを自動的に行います。
Aurora デプロイオプション
| オプション | スコープ | 用途 |
|---|---|---|
| Aurora Global Database | マルチリージョン | グローバルアプリ、DR |
| Aurora Provisioned | 単一リージョン | 一般的なワークロード |
| Aurora Serverless v1/v2 | 単一リージョン | 可変・予測不能なワークロード |
| Aurora Multi-Master | 存在しない | ダミー選択肢 |
「Aurora Multi-Master」が選択肢に出たら不正解です。
Aurora Global Database
- 複数リージョンにまたがる Aurora クラスタ
- RPO = 1秒、RTO = 1分未満
- 書き込みはプライマリリージョンのみ（DynamoDB Global Tables との違い）
- 各リージョンで低レイテンシーのローカル読み取りが可能
Aurora I/O-Optimized
- I/O 課金なし（定額ストレージ料金のみ）
- I/O 負荷の高いワークロードで最大40%のコスト削減
- Aurora Standard との切り替えが可能
Aurora Serverless v2
- ACU（Aurora Capacity Unit）単位で自動スケール
- MySQL / PostgreSQL 互換
- Multi-AZ HA 内蔵
- 可変・予測不能なワークロード向け
Aurora の重要な機能
- Database Cloning: Aurora のみ（RDS では不可）
- Aurora のバックアップは継続的・増分的（DB パフォーマンスへの影響なし）
試験で問われる設計パターン
グローバル展開系
グローバル展開 + 最小リファクタリング → Aurora Global Database
シナリオ: Aurora で運用しているゲームアプリをグローバル展開します。games テーブルはグローバルに共有し、users / games_played はリージョナルに管理したいです。アプリ変更は最小限にしたい場合、どの構成が最適でしょうか？
正解: Aurora Global Database（games）+ 各リージョンに Aurora（users / games_played）
- 既存が Aurora → Aurora のまま構成すれば API 変更不要
- DynamoDB は NoSQL → 大規模リファクタリングが必要
グローバル低レイテンシー + RPO 秒単位 + RTO 1分以内 → Aurora Global Database
シナリオ: グローバルに展開するアプリケーションで、RPO を秒単位、RTO を1分以内に抑えたいです。どのデータベース構成が最適でしょうか？
正解: Aurora Global Database
- RPO = 1秒、RTO = 1分未満
- Aurora Multi-Master は存在しない
- Aurora Serverless / Provisioned は単一リージョン
RDS MySQL パフォーマンス問題 + グローバル + リレーショナル維持 → Aurora Global Database
シナリオ: RDS MySQL でパフォーマンスの問題が発生しています。グローバルに展開しつつリレーショナル DB を維持したい場合、どのサービスに移行すべきでしょうか？
正解: Aurora Global Database
- MySQL 互換 → RDS MySQL からの移行が容易
- DynamoDB は NoSQL でリレーショナル要件に不適
- Redshift は分析用（OLAP）
スケーリング・パフォーマンス系
MySQL 互換 + 自動スケール + HA + コスト効率 → Aurora Serverless v2
シナリオ: MySQL 互換のデータベースが必要で、ワークロードに応じた自動スケールと高可用性を両立させたいです。コスト効率も重視する場合、どの構成が最適でしょうか？
正解: EC2（ASG + ALB）+ Aurora Serverless v2 for MySQL
- Aurora Serverless v2 = ACU 単位で自動スケール + Multi-AZ HA
- RDS Multi-AZ は HA のみ（自動スケールなし）
OLTP + リレーショナル + 予測不能なスパイク → Aurora Serverless
シナリオ: OLTP ワークロードでリレーショナルクエリを使用しています。トラフィックのスパイクが予測不能な場合、どのデータベースが最適でしょうか？
正解: Aurora Serverless
- OLTP + リレーショナル → DynamoDB / ElastiCache は除外
- 予測不能なスパイク → Serverless
Aurora 高 I/O ワークロード + コスト効率 → Aurora I/O-Optimized
シナリオ: Aurora で I/O 負荷の高いワークロードを実行しています。I/O コストが増大している場合、最もコスト効率の良い設定はどれでしょうか？
正解: Aurora I/O-Optimized ストレージ設定
- I/O 課金なし（定額）
- Aurora は EBS ボリュームタイプを直接選択しない（独自ストレージ）
読み取り負荷系
Aurora 読み取り負荷（繰り返し同じクエリ）→ ElastiCache Redis
シナリオ: Aurora に対して同じクエリが繰り返し実行され、読み取り負荷が高くなっています。最もコスト効率の良い対策はどれでしょうか？
正解: ElastiCache for Redis（アプリ → Aurora 間にキャッシュ）
- 同じクエリの繰り返し → キャッシュが最適
- Read Replica を追加しても毎回 DB にクエリが飛ぶ（根本解決にならない）
Aurora 読み取り負荷分散 → Aurora Replica + Reader Endpoint
シナリオ: Aurora の読み取り負荷を分散したいです。どの構成が適切でしょうか？
正解: Aurora Replica を作成 + Reader Endpoint に読み取り操作を接続
- Aurora に「standby インスタンス」は存在しない
- Reader Endpoint が複数 Replica への LB を自動化
- Aurora にはビルトインの read-through キャッシュはない
Aurora 高負荷 + 書き込み欠落 + 可用性向上
シナリオ: 単一の Aurora DB インスタンスで書き込み欠落が発生しています。CPU / メモリが高負荷です。可用性を向上させつつ問題を解決するにはどうすべきでしょうか？（2つ選択）
正解:
- 別 AZ に Aurora Replica を作成
- Reader Endpoint に読み取り操作を接続
- Aurora に Standby は存在しない（超重要）
- Writer から読み取り負荷を分離して Writer の負荷を軽減
- Lambda の同時実行数増加は逆効果（ボトルネックは DB 側）
インメモリ系
インメモリ + リアルタイムリーダーボード → ElastiCache Redis / DynamoDB + DAX
シナリオ: リアルタイムのリーダーボード機能を実装したいです。インメモリのデータストアが必要な場合、どのサービスが適切でしょうか？（2つ選択）
正解:
- ElastiCache for Redis
- DynamoDB + DAX
- Aurora は RDBMS でありインメモリ DB ではない
- DynamoDB 単体はインメモリではない（DAX が必要）
おわりに
Aurora は RDS と似ているようで、「スタンバイが存在しない」「レプリケーションラグが10ミリ秒台」「Reader Endpoint による自動 LB」など、重要な違いがあります。特に「Aurora に standby を作成する」「Aurora Multi-Master」は試験の引っかけ選択肢なので、見た瞬間に不正解と判断できるようにしておきましょう。
間違いや補足があればぜひコメントで教えてください。