AWS認定資格 WEB問題集＆徹底解説

会員登録/ログイン

1. サービス概要

Amazon Auroraは、AWSが独自設計したクラウドネイティブなリレーショナルデータベースサービスです。 MySQL互換とPostgreSQL互換の2エンジンを提供し、商用データベース並みのパフォーマンスをオープンソースのコストで実現します。 AWSのフルマネージドサービスであり、パッチ適用・バックアップ・フェイルオーバーが自動化されています。

Auroraの最大の特徴は、コンピュートとストレージを分離した独自アーキテクチャにあります。 ストレージ層はデータを3つのアベイラビリティゾーン（AZ）に6コピー分散し、99.999999999%（イレブンナイン）の耐久性を実現します。 標準のMySQLと比べ最大5倍、PostgreSQLと比べ最大3倍のスループットを発揮します。

主なユースケースは、大規模OLTPアプリケーション（ECサイト・金融・SaaS）、ミッションクリティカルな基幹システム、 読み取り負荷の高いWebアプリケーション、そして負荷変動が激しいサーバーレスアプリケーションです。

2. 主な特徴と機能

2.1 MySQL / PostgreSQL 互換エンジン

Aurora MySQL（MySQL 8.0互換）とAurora PostgreSQL（PostgreSQL 16互換、2026年6月時点）を提供します。 既存のMySQL/PostgreSQLアプリケーションのドライバ・ツール・SQLをほぼそのまま利用でき、移行コストを最小化できます。 Aurora固有の拡張機能（並列クエリ、Aurora機械学習統合など）も利用可能です。

2.2 Aurora Serverless v2

Aurora Serverless v2は、負荷に応じて0.5 ACU（Aurora Capacity Unit）単位で即座にスケールアップ・ダウンするオートスケーリング機能です（v1の段階的スケールとは異なり、継続的かつ即時）。

• 最小0.5 ACU〜最大128 ACUの範囲でシームレスにスケール（1 ACU = 約2GBメモリ）
• マルチAZ・レプリカ・グローバルデータベースとの組み合わせが可能
• アイドル時はコストが最小化され、急激なスパイクにも瞬時に対応
• 予測困難なワークロード・開発/ステージング環境に特に有効

2.3 クラスターエンドポイントと Aurora レプリカ

Auroraはクラスター構成で動作し、以下のエンドポイントを提供します:

• クラスターエンドポイント（Writer）: 書き込み・読み取り可能なプライマリインスタンスへ常に接続。フェイルオーバー時も自動で新プライマリを指す。
• リーダーエンドポイント: すべてのAuroraレプリカに負荷分散して接続。読み取りスケールアウトに使用。
• カスタムエンドポイント: 特定インスタンスのグループにのみ接続するエンドポイント。ワークロード分離に活用。
• インスタンスエンドポイント: 特定のインスタンスに直接接続（診断・デバッグ用途）。

Aurora Replicaは最大15台まで作成でき、プライマリと同じストレージを共有するため、レプリケーションラグが非常に小さい（通常数十ミリ秒以内）のが特徴です。

2.4 自動フェイルオーバー

プライマリインスタンスに障害が発生した場合、Auroraは自動的にAuroraレプリカをプライマリに昇格します。 通常のフェイルオーバー所要時間は約30秒以内（多くは10〜20秒程度）です。 フェイルオーバー優先度はレプリカごとに設定でき、最も優先度の高いレプリカが昇格します（同優先度の場合は最大サイズのインスタンスが選ばれます）。

2.5 Aurora Global Database

Aurora Global Databaseは、プライマリリージョンから最大5つのセカンダリリージョンにレプリケーションする機能です。

• レプリケーション遅延は通常1秒未満（専用インフラによる非同期レプリケーション）
• セカンダリリージョンは読み取り専用として機能（低レイテンシでの読み取りアクセス）
• フェイルオーバー: プライマリリージョン障害時にセカンダリをプライマリに昇格可能（RTO: 通常1分以内）
• グローバルなDR（災害復旧）と地理的分散読み取りに有効

2.6 Aurora I/O-Optimized

Aurora I/O-Optimized（2023年5月GA）は、I/Oリクエスト料金がかからない新しい設定です。 I/O料金がストレージ料金の約25%超を占める場合にコスト削減効果があります。 I/O集約型ワークロード（書き込みが多いOLTP、分析クエリ）に適しています。

2.7 Aurora Parallel Query

Aurora Parallel Queryは、SQLクエリの処理をAuroraのストレージ層のノードに分散して実行する機能です。 OLTP処理を妨げずに分析クエリを高速実行でき、レプリカに負荷を分散する必要がなくなります（Aurora MySQL専用）。

2.8 ゼロETL統合

Aurora MySQL → Amazon Redshift ゼロETL統合（2024年GA）により、データウェアハウスへのETL処理なしでほぼリアルタイムにデータを同期できます。 分析・BI基盤との連携がシンプルになります。

2.9 バックアップと復旧

• 自動バックアップ: 1〜35日間保持のポイントインタイムリカバリ（PITR）に対応。
• スナップショット: 手動スナップショットは無期限保持（アカウント間・リージョン間コピー可）。
• Backtrack: Aurora MySQL専用。DBをロールバックすることなく、指定した過去の時点に巻き戻す機能（最大72時間前まで、スナップショット不要）。
• クローン: 既存クラスターから高速にクローンを作成（コピーオンライト方式でストレージを共有するため即時・低コスト）。

3. アーキテクチャおよび技術要素

1. コンピュートとストレージの分離: DBインスタンス（プライマリ＋レプリカ）はコンピュートのみを担当し、ストレージ層は完全に独立。
2. 分散共有ストレージ: データを3 AZにわたる6か所のストレージノードに書き込む。4/6以上への書き込み成功でコミット確認（クォーラム書き込み）。読み取りは3/6クォーラム。
3. 自動修復: ストレージノードは障害を検知すると、残りのコピーから自動修復（ピアツーピア通信）。DBインスタンス側への影響を最小化。
4. レプリカのストレージ共有: AuroraレプリカはプライマリとストレージVolumeを共有するためレプリケーションラグが小さく、レプリカ追加でもストレージコストは増加しない。
5. フェイルオーバー: プライマリ障害時、最高優先度のレプリカが自動昇格。クラスターエンドポイントが新プライマリを指すよう自動更新。
6. Aurora Serverless v2: ACU単位でコンピュート容量を動的スケール。内部でウォームプールからキャパシティを即時割り当て。

Auroraはストレージを10GBごとのセグメント（Protection Group）に分割し、それぞれを6コピー管理します。 Auroraストレージは自動で最大128TiBまで拡張します（従来の64TBから拡大）。

4. セキュリティと認証・認可

• VPC内配置: AuroraクラスターはVPC内のサブネットグループにプロビジョニング。セキュリティグループでポート・IPレベルの通信を制御。パブリックアクセスは原則無効化。
• 保存時暗号化: AWS KMSによるAES-256暗号化。有効化はクラスター作成時のみ（後から変更不可）。暗号化を変更するにはスナップショットから新クラスターを作成。スナップショット・レプリカ・バックアップもすべて暗号化される。
• 転送時暗号化: SSL/TLS接続を強制可能。
• IAM Database Authentication: パスワードの代わりにIAMロール/ユーザーの認証トークンでDBに接続。認証情報の管理をシンプルにし、IAM監査証跡も残る。
• Secrets Manager統合: マスターパスワードをSecrets Managerで自動ローテーション。ハードコードを排除。
• 監査ログ: クエリログ・スロークエリログ・エラーログをCloudWatch Logsに転送可能。CloudTrailでAPIコールも監査。
• セキュリティグループ: DBポート（MySQL: 3306、PostgreSQL: 5432）へのアクセスをアプリサーバーのSGのみに制限するのがベストプラクティス。

5. 料金形態

Auroraはプロビジョンドとサーバーレスで料金体系が異なります：

• DBインスタンス時間（プロビジョンド）: インスタンスクラス（db.r7g.large等）と稼働時間による従量課金。
• Aurora Capacity Unit（サーバーレスv2）: ACU・秒単位の従量課金。アイドル時（最小0.5 ACU）も最低限の課金あり。
• ストレージ: 実際に使用した分のみGB・月課金（自動拡張、未使用領域への課金なし）。
• I/Oリクエスト（Standard設定）: 100万リクエストあたりの課金。I/O-Optimized設定ではI/O料金は不要だがストレージ単価が上がる。
• バックアップストレージ: DBクラスターのストレージ量を超えた分のバックアップに課金。保持期間を短くするとコスト削減可能。
• データ転送: 同一AZ内は無料。AZ間・リージョン間は課金（Global Databaseのリージョン間レプリケーションも課金）。

6. よくあるアーキテクチャ・設計パターン

• 高スループットOLTP（プロビジョンド）: プライマリ1台＋Aurora Replica複数台。リーダーエンドポイントで読み取りをスケールアウト。カスタムエンドポイントで重要クエリと分析クエリを分離。
• サーバーレスワークロード（Serverless v2）: Lambda等と組み合わせ、APIバックエンドのDB。トラフィックスパイクに自動スケール。夜間アイドル時のコストを最小化。
• グローバル展開・DR（Global Database）: 本番リージョンのプライマリからセカンダリリージョンへ1秒未満でレプリケーション。障害時にセカンダリをプライマリ昇格（RPO: 約1秒、RTO: 約1分）。
• ゼロETLデータ分析: Aurora MySQL → Redshift ゼロETL統合でほぼリアルタイムのデータウェアハウス連携。データパイプライン構築不要。
• クローンによるテスト環境: 本番クラスターをコピーオンライト方式で即時クローン。本番データを使った検証を低コスト・低リスクで実施。
• Backtrackによる誤操作対応（Aurora MySQL）: 誤ったDELETE/UPDATEを実行した場合、スナップショット復元なしで数分以内に指定時刻に巻き戻し。

7. 設定・デプロイ手順（ハンズオン例）

1. RDSコンソールを開き、「データベースの作成」→「Amazon Aurora」を選択し、エンジン（MySQL/PostgreSQL互換）とバージョンを指定。
2. 「プロビジョンド」または「Aurora Serverless v2」を選択。Serverless v2の場合は最小・最大ACU範囲を設定。
3. DBクラスター識別子・マスターユーザー名・パスワード（またはSecrets Manager管理）を設定。
4. VPC・サブネットグループ（少なくとも2 AZに跨るサブネット）・セキュリティグループを設定。パブリックアクセスは原則「なし」。
5. 「マルチAZ」でAuroraレプリカの追加有無を設定。本番環境では最低1台のレプリカ推奨。
6. 暗号化（KMSキー）・バックアップ保持期間・CloudWatch Logsへのログエクスポートを設定。
7. 「作成」後、クラスターエンドポイントとリーダーエンドポイントをアプリケーションに設定して接続テスト。

8. 試験で問われやすいポイント