目次

Amazon Aurora 完全ガイド 2026

初心者から実務者向けの包括的解説

Amazon Aurora は、AWS が開発した高性能な マネージドリレーショナルデータベース で、MySQL および PostgreSQL との互換性を保ちながら、独自のクラウドネイティブアーキテクチャで従来の RDS を大幅に上回るパフォーマンスを実現します。2014 年の公開以降、グローバルなミッションクリティカルワークロードの標準選択肢となっています。本ドキュメントは、Aurora の概念・アーキテクチャ・ユースケース・実装・運用・最新動向を体系的に解説する包括的ガイドです。

ドキュメントの目的

本ガイドは以下を対象としています。

  • 初心者向け： Aurora とは何か、RDS との違いを学びたい方
  • 開発者向け： マイグレーション・アプリ統合・クエリ最適化を実装したい方
  • DBA/インフラ向け： クラスター構成・バックアップ・フェイルオーバーを運用したい方
  • 意思決定者向け： コスト・パフォーマンス・可用性の投資判断

2026 年の Aurora エコシステム

  • Aurora MySQL 8.0 / 8.4 & PostgreSQL 16 / 17: 最新エンジン対応
  • Aurora DSQL: 2024 年 re:Invent で発表、分散 SQL エンジン（GA 予定）
  • Aurora Serverless v3: v2 からのさらなる自動スケーリング強化
  • Optimized Reads / Writes: I/O コスト最適化の新機能群
  • Amazon Bedrock 統合: Aurora から生成 AI モデルへの直接呼び出し
  • ベクトル検索対応: pgvector 拡張による semantic search
  • Enhanced Monitoring / Performance Insights: より詳細な可視化

目次

  1. 概要
  2. Aurora が解決する課題
  3. 主な特徴
  4. アーキテクチャ
  5. Aurora MySQL vs PostgreSQL vs DSQL
  6. Aurora Serverless v1 / v2 / v3
  7. Aurora DSQL（分散 SQL）
  8. 主要ユースケース
  9. クラスタ構成
  10. Auto Scaling
  11. Aurora Global Database
  12. バックアップ・PITR・スナップショット
  13. Blue/Green Deployment
  14. Babelfish for PostgreSQL
  15. Aurora Optimized Reads / Writes
  16. ML 統合（Aurora ML・Bedrock）
  17. ベクトル検索（pgvector）
  18. セキュリティ
  19. モニタリング
  20. RDS vs Aurora の違い
  21. 他の類似ツールとの比較
  22. クライアントとエコシステム
  23. ベストプラクティス
  24. トラブルシューティング
  25. 2025-2026 最新動向
  26. 学習リソース
  27. 実装例・活用シーン
  28. 導入ロードマップ
  29. 実装チェックリスト
  30. まとめ
  31. 参考文献

概要

初心者向けメモ： Aurora は「データベースを一から作り直した」ものです。従来の RDS は商用データベースエンジン（MySQL・PostgreSQL）をそのまま AWS クラウドにのせているだけですが、Aurora は AWS が独自にストレージ・ネットワーク・キャッシュを最適化し、同じ SQL 構文を保ちながら 5 倍高速にしました。RDS を「マネージド版 MySQL」と考えるなら、Aurora は「クラウド専用の最高性能データベース」です。

定義

Amazon 公式による定義：

“Amazon Aurora is a MySQL and PostgreSQL-compatible relational database built for the cloud, that combines the performance and availability of traditional enterprise databases with the simplicity and cost-effectiveness of open source databases.”

Aurora の本質は以下 3 つの約束：

  • 互換性: MySQL / PostgreSQL と完全互換（既存アプリそのまま動作）
  • 性能: ストレージとコンピュートを分離した独自アーキテクチャで MySQL 比 5 倍・PostgreSQL 比 3 倍のスループット
  • 高可用性: 3 AZ × 2 コピーの 6 方向レプリケーション、30 秒未満フェイルオーバー

エディション・バリエーション

Aurora エディション

  • Aurora Standard: 標準マネージド版（最も一般的）
  • Aurora Serverless v2: 自動スケーリング版（可変負荷推奨）
  • Aurora Serverless v1: 旧バージョン（新規は v2 推奨）
  • Aurora DSQL: 分散 SQL（2024 年新発表、複数リージョン対応）

互換エンジン

  • Aurora MySQL: MySQL 5.7 / 8.0 / 8.4 互換
  • Aurora PostgreSQL: PostgreSQL 12 / 13 / 14 / 15 / 16 / 17 互換

Aurora が解決する課題

課題 1: RDS の性能限界

状況： RDS MySQL でトラフィック 10 倍に増加、CPU 100%、レイテンシ増加

RDS の根本的制限：

  • ストレージ I/O がシングルインスタンスに集中（分散不可）
  • ログ書き込みが同期的でネットワークレイテンシに左右される
  • リードレプリカは非同期複製（レプリカラグ数秒）

Aurora の解決：

  • ✅ 6 方向ストレージレプリケーション（Quorum ベース）で書き込み確認時間短縮
  • ✅ Redo Log を分散ストレージに並列書き込み（2 コピー確認で十分）
  • ✅ リードレプリカはストレージ共有（ラグ < 100 ms）

課題 2: フェイルオーバーのダウンタイム

状況： プライマリ DB が故障、自動フェイルオーバー待機中に顧客からのアクセス失敗

RDS（Multi-AZ）の課題：

  • フェイルオーバー 60～120 秒かかる
  • ホストレベルの再起動のため接続リセット必須
  • DNS TTL 60 秒で反映遅延の可能性

Aurora の解決：

  • ✅ フェイルオーバー < 30 秒（リードレプリカあり）
  • ✅ DNS 自動切り替え（クラスターエンドポイント）
  • ✅ Aurora Serverless v2 は数秒レベル

課題 3: ストレージスケーリングの手作業

状況： ディスク容量 95% に達した、ダウンタイムなしで拡張したい

RDS の課題：

  • ストレージサイズは固定（事前に決定・拡張も手動）
  • 最大 65 TiB（拡張に待機時間）

Aurora の解決：

  • ✅ 自動拡張（10 GB 単位）
  • ✅ 最大 128 TiB
  • ✅ 使用量に応じた従量課金

課題 4: グローバル読み取りの遅延

状況： 東京リージョンのデータを米国から参照、500 ms のレイテンシ

従来の解決策（RDS）：

  • Read Replica を各リージョンに作成（手動・遅延あり）
  • DMS で別 RDS にレプリケーション（運用複雑）

Aurora Global Database の解決：

  • ✅ 5 リージョンまで読み取り専用リージョン自動配置
  • ✅ RPO < 1 秒、RTO < 1 分で自動フェイルオーバー
  • ✅ クエリを各リージョンでローカル実行

主な特徴

特徴 説明
クラウドネイティブアーキテクチャ ストレージ・コンピュート・ネットワークを最適設計、MySQL 比 5 倍・PostgreSQL 比 3 倍
3 AZ × 2 コピー 自動レプリケーション 合計 6 コピー、Quorum ベース（4/6 で書き込み確認、3/6 で読み取り可能）
30 秒未満フェイルオーバー リードレプリカが自動昇格、DNS 自動切り替え
自動ストレージ拡張 10 GB 単位で自動増加、最大 128 TiB
最大 15 リードレプリカ RDS は 5 個、ストレージ共有で低ラグ
Aurora Serverless v2 自動スケーリング 0.5～256 ACU、秒単位で自動調整
Aurora Global Database 最大 5 リージョン、低遅延レプリケーション
バックトラック（MySQL 互換） 最大 72 時間前に巻き戻し、新インスタンス不要
クローン（Copy-on-Write） スナップショット不要、即時コピー（差分課金）
RDS Proxy 統合 接続プール管理、Lambda コールドスタート対策
Aurora ML SageMaker / Bedrock から直接推論呼び出し
ベクトル検索 pgvector による semantic search
Blue/Green Deployment ダウンタイムなしメジャーバージョンアップ

アーキテクチャ

初心者向けメモ： Aurora は RDS と違い、「ストレージ層を独立させた」のがポイントです。RDS では DB エンジン（MySQL）がストレージ管理も行いますが、Aurora は DB エンジンは 「計算」だけに専念 し、ストレージは AWS 独自の分散ストレージで管理します。これにより、リードレプリカがすべて同じストレージを共有でき、書き込みが高速になります。

図 1: Aurora のアーキテクチャ（Compute / Storage 分離）

graph TD
    Client[クライアント アプリ]
    
    subgraph Compute[コンピュート層 クラスター]
        PRI[プライマリインスタンス<br/>読み書き]
        REP1[リードレプリカ 1<br/>読み取り]
        REP2[リードレプリカ 2<br/>読み取り]
        REP3[リードレプリカ N<br/>読み取り]
    end
    
    subgraph Storage["ストレージ層 クラスターボリューム"]
        AZ1["AZ1<br/>Segment Segment"]
        AZ2["AZ2<br/>Segment Segment"]
        AZ3["AZ3<br/>Segment Segment"]
    end
    
    Client -->|クラスターエンドポイント| PRI
    Client -->|リーダーエンドポイント| REP1
    Client -->|リーダーエンドポイント| REP2
    
    PRI -.->|Write Quorum<br/>4/6 確認| Storage
    REP1 -.->|Read<br/>3/6 確認| Storage
    REP2 -.->|Read<br/>3/6 確認| Storage
    REP3 -.->|Read<br/>3/6 確認| Storage
    
    style PRI fill:#ff6b6b
    style REP1 fill:#4dabf7
    style REP2 fill:#4dabf7
    style REP3 fill:#4dabf7

図 2: RDS vs Aurora アーキテクチャ比較

graph TD
    subgraph RDS["RDS (従来型)"]
        RDSAPP["App"]
        RDSDB["DB インスタンス<br/>MySQL エンジン<br/>ストレージ管理"]
        RDSREP["Read Replica<br/>非同期複製<br/>遅延あり"]
        RDSSTOR["EBS ストレージ<br/>インスタンス専属"]
        
        RDSAPP --> RDSDB
        RDSDB --> RDSREP
        RDSDB --> RDSSTOR
        RDSREP -.->|遅延| RDSSTOR
    end
    
    subgraph Aurora["Aurora (クラウドネイティブ)"]
        AURAAPP["App"]
        AURADB1["DB インスタンス 1<br/>計算のみ"]
        AURADB2["DB インスタンス 2<br/>計算のみ"]
        AURADB3["DB インスタンス 3<br/>計算のみ"]
        AURASTOR["分散ストレージボリューム<br/>共有 6 方向レプリケーション"]
        
        AURAAPP --> AURADB1
        AURAAPP --> AURADB2
        AURADB1 --> AURASTOR
        AURADB2 --> AURASTOR
        AURADB3 --> AURASTOR
    end
    
    style RDSDB fill:#ffcccc
    style RDSREP fill:#ffeeee
    style AURADB1 fill:#ccddff
    style AURADB2 fill:#ccddff
    style AURASTOR fill:#ddffdd

2.1 クラスター構成

Aurora クラスタの基本要素：

クライアント
    ├── クラスターエンドポイント (Cluster Endpoint)
    │   → 常に現プライマリインスタンスに接続
    │   → フェイルオーバー時は自動切り替え
    │   → 読み書き両対応
    │
    ├── リーダーエンドポイント (Reader Endpoint)
    │   → 利用可能なリードレプリカをラウンドロビン
    │   → 複数リーダーで自動負荷分散
    │   → 読み取り専用
    │
    └── インスタンスエンドポイント (Instance Endpoint)
        → 特定のインスタンスを直接指定
        → デバッグ・パフォーマンス調査用

クラスターエンドポイント

リーダーエンドポイント

2.2 クラスターボリューム（6 方向レプリケーション）

Aurora のストレージ層は** Quorum ベースの分散ストレージ**：

3 AZ × 2 コピー = 合計 6 コピー
    
AZ-1 (東京 a)
    ├── Segment 1 (Copy 1)
    └── Segment 2 (Copy 2)

AZ-2 (東京 c)
    ├── Segment 3 (Copy 3)
    └── Segment 4 (Copy 4)

AZ-3 (東京 d)
    ├── Segment 5 (Copy 5)
    └── Segment 6 (Copy 6)

耐久性・可用性

操作 Quorum 必須 耐可能
書き込み確認 4/6 コピー 最大 2 コピー損失
読み取り 3/6 コピー 最大 3 コピー損失・AZ 丸ごと障害可能

ストレージ課金

使用量に応じた従量課金（プロビジョンド不要）
例）
  1 月: 100 GB 使用 → 100 × $0.1 = $10
  2 月: 150 GB 使用 → 150 × $0.1 = $15
  （費用は月末に精算）

Aurora MySQL vs PostgreSQL vs DSQL

観点 Aurora MySQL Aurora PostgreSQL Aurora DSQL
互換性 MySQL 5.7 / 8.0 / 8.4 PostgreSQL 12-17 新規設計・SQL 標準準拠
成熟度 ★★★★★（最古） ★★★★★ ★★（2024 年発表）
バックトラック ✅ あり ❌ なし 未定
PITR 範囲 35 日 35 日 未定
高度な拡張 JSON, UUID JSON, UUID, pgvector 拡張機能体系準備中
ML 推論 ✅ Aurora ML ✅ Aurora ML ✅ 予定
グローバルDB ✅ ✅ ✅（予定）
推奨ユースケース 既存 MySQL 移行・Web アプリ・EC サイト 既存 PG 移行・複雑 SQL・PostGIS 新規・分散 SQL・複数リージョン

MySQL vs PostgreSQL どちらを選ぶ？

Aurora MySQL を選ぶべき場合 ✅

  • 既存 MySQL アプリケーションからの移行
  • WordPress, Drupal, Joomla など LAMP スタック
  • JSON 型・UUID を多用する
  • シンプルな CRUD アプリケーション

Aurora PostgreSQL を選ぶべき場合 ✅

  • 既存 PostgreSQL アプリケーションからの移行
  • 複雑な JOIN・ウィンドウ関数が必要
  • pgvector（ベクトル検索）を使いたい
  • PostGIS（地理情報）を使いたい
  • JSONB で複雑な構造を扱う
  • 型安全性・トランザクション複雑度を重視

Aurora DSQL を選ぶべき場合 ✅（2024 年新）

  • 複数 AWS リージョンに自動分散したい
  • グローバルな ACID トランザクション（強一貫性）が必要
  • MySQL / PostgreSQL ベースの制限を超えたい
  • 新規アプリケーション（既存互換性不要）

Aurora Serverless v1 / v2 / v3

初心者向けメモ： Serverless は「インスタンスサイズを事前に決めず、負荷に応じて自動スケール」する仕組みです。従来の Aurora は db.r6g.xlarge のように固定サイズを事前に購入しますが、Serverless は「必要な時に必要な分だけ」払う、従量課金型です。

3 世代の比較

観点 v1 v2 v3（予定）
リリース年 2018 年 2021 年 2025+
スケール範囲 2～16 ACU 0.5～256 ACU 0.5～1000 ACU 予定
スケール粒度 1 ACU 単位 0.5 ACU 単位 0.5 ACU 単位予定
アイドル時課金 ❌（0 ACU） ✅（0.5 ACU 最小） ✅
スケール速度 数十秒 秒単位 秒単位
マルチ AZ ❌ ✅ ✅
リードレプリカ ❌（読み書き兼用） ✅（別リードレプリカ可） ✅
新規推奨 ❌ 非推奨 ✅ 推奨 ✅ 今後推奨

Aurora Serverless v2

ACU（Aurora Capacity Unit）とは

1 ACU = 2 GB RAM + 対応 CPU・ネットワーク
例）
  0.5 ACU = 1 GB RAM（最小）
  1 ACU = 2 GB RAM
  2 ACU = 4 GB RAM
  16 ACU = 32 GB RAM
  256 ACU = 512 GB RAM（最大）

スケーリング動作

時系列：
  00:00 トラフィック低 → 0.5 ACU（最小）
  06:00 朝のピーク → 自動検出 → 4 ACU に拡張（秒単位）
  09:00 安定 → 2 ACU に縮小
  12:00 昼のピーク → 8 ACU
  18:00 夜間低 → 0.5 ACU に縮小

課金

例：v2 ダブルリーダー + 東京リージョン
  - ライター: 平均 2 ACU = 2 × 1.036 円/秒 × 2,592,000 秒 = ¥5,367/月
  - リーダー 1: 平均 1 ACU = 1 × 1.036 円/秒 × 2,592,000 秒 = ¥2,683/月
  - リーダー 2: 平均 1 ACU = ¥2,683/月
  月額: ¥10,733

プロビジョンド db.r6g.xlarge との比較:
  - 1 × db.r6g.xlarge = ¥17,000/月 × 1 台
  月額: ¥17,000（スケーリング不可）

v2 を選ぶべき場合

✅ 開発・テスト環境（スパイク→アイドル繰り返し） ✅ SaaS・マルチテナント（テナント数変動） ✅ イベント駆動（キャンペーン時ピーク） ❌ 24/7 定負荷（プロビジョンド推奨） ❌ 予測不能スパイク回避（リザーブド推奨）

Aurora DSQL（分散 SQL）

初心者向けメモ： DSQL は「複数 AWS リージョンに自動分散したグローバルデータベース」です。従来の Global Database は「プライマリリージョン + セカンダリ読取」ですが、DSQL は「複数リージョンで読み書き同時実行」でき、強い一貫性を保証します。2024 年 re:Invent で発表、2025 年 GA 予定。

DSQL の特徴

特徴 説明
グローバルマルチリージョン 複数 AWS リージョンに自動分散、全リージョンで読み書き可能
強い一貫性（Strong Consistency） 分散トランザクションで ACID 保証
No シャーディング アプリが分散を意識不要
自動フェイルオーバー リージョン障害時の自動切り替え
JSON + リレーショナル 構造化 + 非構造化データを同時対応

DSQL と Global Database の比較

観点 Global Database DSQL
書き込み プライマリのみ 複数リージョン同時
一貫性 結果整合（Eventually Consistent） 強一貫性（Strong）
遅延 RPO < 1 秒 < 数百 ms 予定
API MySQL / PostgreSQL 新規 SQL エンジン
用途 読み取りローカライズ グローバル読み書き

主要ユースケース

初心者向けメモ： Aurora は「監視用途」のイメージが強いですが、実は **オンラインビジネスの「心臓」**として使われます。ここでは実務でよくある 10 以上のユースケースを整理します。

1. SaaS マルチテナント DB

状況： 複数顧客のデータを 1 つの DB で管理、テナント数が月 10% 増加

Aurora の価値：

  • ✅ Serverless v2 で自動スケール
  • ✅ テナント数増 → 自動リード増設で読み取り分散
  • ✅ 月額コスト最適化

典型構成：

複数テナント
    ├── ライター 1 × db.r6g.2xlarge
    └── リーダー 3 × Serverless v2 自動スケール
        （テナント数増で自動 replicas 追加）

2. グローバル EC サイト

状況： 東京・シンガポール・ロンドンから同時アクセス、低レイテンシ必須

Aurora Global Database の価値：

  • ✅ 各リージョンで読み取りローカル（< 100 ms）
  • ✅ 在庫更新は東京リージョンで一元化（< 1 秒レプリケーション）
  • ✅ リージョン障害時の自動フェイルオーバー

構成：

東京リージョン（Primary）
    ├── Writer
    └── Reader × 3

シンガポール（Secondary）
    └── Reader × 3（東京から自動複製）

ロンドン（Secondary）
    └── Reader × 3（東京から自動複製）

3. レポーティング・分析 DB

状況： 毎晩 0 時から大量レポート生成、昼間はほぼアイドル

Aurora の価値：

  • ✅ リードレプリカで重い集計を分離（プライマリ負荷低減）
  • ✅ Serverless v2 で夜間ピーク時 8 ACU → 昼間 0.5 ACU に自動縮小
  • ✅ Custom Endpoint で特定リーダーに集計専用割り当て可能

4. リアルタイムビッグデータ

状況： IoT センサー 100 万台、秒 10 万件のイベント記録

Aurora の価値：

  • ✅ 6 方向ストレージレプリケーション + Quorum ベースで高スループット
  • ✅ MySQL 比 5 倍性能（MySQL では 5 万イベント/秒が限界）
  • ✅ オートスケーリング Serverless v2 でピーク対応

5. 医療・コンプライアンスシステム

状況： HIPAA・GDPR 対応が必須、データ誤削除リスク

Aurora の価値：

  • ✅ KMS 暗号化（保存時）+ TLS（転送時）
  • ✅ バックトラック機能で誤削除を数秒で復旧
  • ✅ CloudTrail・Enhanced Audit Logging で監査ログ完全記録
  • ✅ IAM 認証で UUID ベース認証

6. CI/CD パイプライン DB

状況： テスト・ステージング・本番で複数 DB 必要、構築・破棄が頻繁

Aurora の価値：

  • ✅ クローン機能（Copy-on-Write）で本番スナップショット即座複製
  • ✅ スナップショットより高速・コスト低（差分課金）

例：

  • 本番 DB: 500 GB
  • ↓ クローン生成（5 秒、差分のみ課金）
  • テスト DB: 内容は同じ、書き込みで差分記録

7. オンラインゲーム / ゲームランキング

状況： ランキング更新 / ユーザー数急変時ピーク、60 fps 以下の遅延禁止

Aurora の価値：

  • ✅ MySQL 比 5 倍スループット（ランキング更新の高速化）
  • ✅ リードレプリカ最大 15 個で読み取り分散
  • ✅ < 100 ms レプリカラグ（強い最終一貫性を実装可能）

8. 金融・PCI DSS DB

状況： クレジットカード番号・決済情報の最高セキュリティ保護必須

Aurora の価値：

  • ✅ KMS (Hardware Security Module) による暗号化
  • ✅ VPC 内完全隔離
  • ✅ IAM 認証 + TLS
  • ✅ Enhanced Audit Logging で全 SQL を CloudWatch に記録

9. ML パイプライン統合

状況： アプリから直接 SageMaker の推論モデル呼び出し

Aurora ML の価値：

  • ✅ SQL クエリから直接推論（SELECT aws_ml.invoke_endpoint(...) ）
  • ✅ Python コード不要、DB 内で完結
  • ✅ Amazon Bedrock 統合で生成 AI 連携

例：

-- 顧客チャーン率を ML モデルで予測
SELECT customer_id, 
       aws_ml.invoke_endpoint(
           'churn-predictor',
           customer_id, 
           total_spent, 
           days_inactive
       ) AS churn_probability
FROM customers
WHERE churn_probability > 0.7;

10. ベクトルレコメンデーション

状況： 「この商品を見た人はこれも見ています」のレコメンデーション

Aurora PostgreSQL + pgvector の価値：

  • ✅ ベクトル（embedding）を DB に保存・検索
  • ✅ SQL で semantic search（意味で検索）
  • ✅ OpenAI API / Bedrock で embedding 生成

例：

-- コサイン類似度で最も近い商品 5 件を取得
SELECT product_id, product_name,
       1 - (embedding <=> query_embedding) AS similarity
FROM products
WHERE 1 - (embedding <=> query_embedding) > 0.8
ORDER BY similarity DESC
LIMIT 5;

11. マイグレーション基点

状況： オンプレミス Oracle → クラウド移行、既存アプリ最小変更で実現したい

Aurora の価値：

  • ✅ Babelfish for PostgreSQL で SQL Server 互換性
  • ✅ AWS DMS で異なる DB エンジンから自動マイグレーション
  • ✅ Zero-downtime migration（カットオーバー中も稼働）

12. 小規模開発スタートアップ

状況： 初期段階で DBA いない、でも本番ユーザー 100k に成長見込み

Aurora Serverless v2 の価値：

  • ✅ インスタンスサイズ選定不要（自動スケール）
  • ✅ 初期コスト低（0.5 ACU 最小）
  • ✅ トラフィック成長に自動対応

クラスタ構成

図 3: エンドポイント構成図

graph TD
    App["アプリケーション"]
    
    App -->|Write| ClusterEndpoint["クラスターエンドポイント<br/>mydb.cluster.example.com<br/>常に現プライマリ"]
    App -->|Read| ReaderEndpoint["リーダーエンドポイント<br/>mydb.cluster-ro.example.com<br/>全リードレプリカ分散"]
    
    ClusterEndpoint --> Primary["プライマリインスタンス<br/>db.r6g.2xlarge<br/>読み書き"]
    
    ReaderEndpoint --> Reader1["リードレプリカ 1<br/>db.r6g.xlarge<br/>読み取り"]
    ReaderEndpoint --> Reader2["リードレプリカ 2<br/>db.r6g.xlarge<br/>読み取り"]
    ReaderEndpoint --> Reader3["Serverless v2<br/>Auto scaling<br/>読み取り"]
    
    Primary -.->|同一ストレージ| Storage["クラスターボリューム<br/>3 AZ × 2 copy<br/>自動管理"]
    Reader1 -.-> Storage
    Reader2 -.-> Storage
    Reader3 -.-> Storage
    
    style ClusterEndpoint fill:#ff9999
    style ReaderEndpoint fill:#99ccff
    style Primary fill:#ffcccc
    style Reader1 fill:#ccddff
    style Reader2 fill:#ccddff
    style Reader3 fill:#ccffcc

エンドポイント種別

1. クラスターエンドポイント（Cluster Endpoint）

接続先の DNS：

特性：

  • フェイルオーバー時に自動切替（DNS ポイント変更）
  • プライマリが新しいインスタンスに昇格 → エンドポイント自動更新
  • 読み書き両対応
  • 通常、アプリは常にこのエンドポイントを使用

2. リーダーエンドポイント（Reader Endpoint）

接続先の DNS：

特性：

  • ラウンドロビンで複数リーダーに分散
  • 新規リーダー追加時は自動的にエンドポイントに含まれる
  • 読み取り専用
  • バッチ処理・レポート生成に最適

3. インスタンスエンドポイント（Instance Endpoint）

特性：

  • 特定インスタンスを直接指定
  • パフォーマンス調査・デバッグ用
  • 通常は使用しない

4. カスタムエンドポイント（Custom Endpoint）

用途例：

  • 特定リーダー（高スペック）に集計クエリのみ送信
  • 別の Serverless v2 リーダーにアナリティクス用途を分離
  • 機械学習推論用リーダーを専用化

構成例：

Custom Endpoint: analytics-reader
  構成: リーダー 1 (db.r6g.4xlarge) + Serverless v2
  用途: 毎日 0 時から重い集計クエリ実行

Auto Scaling

Read Replica Auto Scaling

Aurora の新機能（2023 年以降）：

トラフィック検出
    ↓
CloudWatch メトリクス（CPU, Connections）
    ↓
自動判定: リーダー追加必要？
    ↓
リーダー自動追加（最大 15 個まで）

設定例

AutoScaling Configuration:
  Metric: CPU > 70%（プライマリ）
  Action: リーダー追加（最小 3、最大 7）
  Cooldown: 300 秒（スケール後、次スケール待機）

Aurora Serverless v2 Auto Scaling

負荷検出（秒単位）
    ↓
自動 ACU 調整（0.5～256 範囲）
    ↓
秒単位でスケール（RDS の数分待ちより高速）

CPU リソース活用

時系列：
  00:00-06:00: 0.5 ACU（最小：月額 ¥1,200）
  06:00-09:00: 4 ACU（朝ピーク：月額 ¥9,600）
  09:00-18:00: 2 ACU（昼間：月額 ¥4,800）
  18:00-22:00: 6 ACU（夜のピーク：月額 ¥14,400）
  22:00-00:00: 1 ACU（夜間：月額 ¥2,400）
  
月額推定: ¥32,400（プロビジョンド db.r6g.2xlarge の ¥30,000 と同等）
+ 柔軟性で急増対応可能

Aurora Global Database

初心者向けメモ： Global Database は「複数リージョンで自動読み取りレプリカを保有」する仕組みです。通常の RDS Read Replica は同リージョン内ですが、Global DB はリージョンをまたぎ、各リージョンでローカル読み取り可能にします。

アーキテクチャ

graph TD
    App1["東京<br/>読み書き"]
    App2["シンガポール<br/>読み取り"]
    App3["ロンドン<br/>読み取り"]
    
    App1 --> PrimaryDB["プライマリ DB<br/>us-east-1"]
    App2 --> SecondaryDB1["セカンダリ DB<br/>ap-southeast-1<br/>自動レプリケーション"]
    App3 --> SecondaryDB2["セカンダリ DB<br/>eu-west-1<br/>自動レプリケーション"]
    
    PrimaryDB -->|Redo Log Stream<br/>RPO < 1 秒| SecondaryDB1
    PrimaryDB -->|Redo Log Stream<br/>RPO < 1 秒| SecondaryDB2
    
    style PrimaryDB fill:#ff9999
    style SecondaryDB1 fill:#99ccff
    style SecondaryDB2 fill:#99ccff

特性

特性 値
RPO（Recovery Point Objective） < 1 秒
RTO（Recovery Time Objective） < 1 分（自動フェイルオーバー）
セカンダリリージョン数 最大 5 個
レプリケーション方式 Redo Log Stream（物理レプリケーション）
セカンダリ特性 デフォルト読み取り専用（ただし全リージョンで読み取り可）

フェイルオーバー

計画的フェイルオーバー（Managed Planned Failover）

メンテナンス・テスト用：

  1. 東京（Primary）→ シンガポール（New Primary）へ切替
  2. ダウンタイム: 数秒（DNS 更新 + バッファフラッシュ）
  3. 東京は自動的に Secondary に変更
  4. アプリ接続文字列は変わらず（DNS ベース）

非計画的フェイルオーバー（Unplanned Failover）

プライマリリージョン障害時：

  1. プライマリリージョン（東京）が完全停止
  2. AWS が自動検出（数秒）
  3. 最も進んだセカンダリ（シンガポール）を New Primary に昇格
  4. RTO < 1 分（通常 30 秒以内）

Cost

Global Database 固有の課金：

ライター DB: 東京 db.r6g.2xlarge = ¥30,000/月
リーダー DB: シンガポール db.r6g.large = ¥15,000/月
リーダー DB: ロンドン db.r6g.large = ¥15,000/月
グローバル DB レプリケーション: ¥5,000/月（例）

月額: ¥65,000

バックアップ・PITR・スナップショット

初心者向けメモ： Aurora には 3 つの復旧方法があります：PITR（時点復旧・秒単位）・スナップショット（手動・削除まで保持）・バックトラック（MySQL のみ・タイムマシン）。用途で使い分けます。

3 つの復旧方式

方式 PITR スナップショット バックトラック
保持期間 35 日（自動） 削除まで無制限 72 時間
復旧時間 数分 数分 数秒
新インスタンス必要？ ✅ 必須 ✅ 必須 ❌ 不要
対応エンジン MySQL / PG MySQL / PG MySQL のみ
コスト バックアップストレージ スナップショット容量 バックトラック容量
用途 予測不能な障害 本番スナップショット 誤削除の即座復旧

PITR（Point-in-Time Recovery）

メカニズム

連続バックアップ（Continuous Backup）
    ↓
毎日（自動スナップショット）+ Redo Log
    ↓
35 日間保持
    ↓
任意時刻に復旧

復旧プロセス

例：2024-04-20 14:30:00 時点に復旧したい
    ↓
AWS RDS コンソール → Recover to point in time
    ↓
新規クラスター作成（旧データは保持）
    ↓
復旧クラスター起動（5-10 分）

課金

PITR バックアップストレージ = DB ストレージサイズ × 日数
例）
  DB サイズ: 500 GB
  35 日保持
  = 500 × 35 × $0.023/GB/月
  = 月額 ¥4,000（概算）

スナップショット（Manual Snapshot）

用途

1. ビジネスクリティカルなポイント記録
   例）月末決算、四半期終了データ
   
2. データ分析環境への複製
   例）本番 → テスト DB
   
3. アカウント間コピー
   例）本番アカウント → DR アカウント

作成・管理

# CLI で手動スナップショット作成
aws rds create-db-cluster-snapshot \
  --db-cluster-identifier mydb-cluster \
  --db-cluster-snapshot-identifier mydb-20240420-snapshot

# スナップショットから復旧
aws rds restore-db-cluster-from-snapshot \
  --db-cluster-identifier mydb-restored \
  --snapshot-identifier mydb-20240420-snapshot

コスト

スナップショット = クラスター全体のデータサイズ
例）
  クラスター 500 GB のスナップショット 3 個保有
  = 500 × 3 × $0.1/GB/月
  = 月額 ¥1,500

バックトラック（MySQL 互換のみ）

初心者向けメモ： バックトラックは Aurora の最高の機能です。誤削除・誤更新をした時に「新しい DB インスタンスを起動することなく」、元の時点に巻き戻すことができます。

メカニズム

Backtrack Buffer（メモリ内）に変更を記録
    ↓
任意時刻への巻き戻し（物理的に Block を戻す）
    ↓
数秒で完了（新インスタンス起動不要）

例：誤削除の復旧

-- 04-20 14:30 で全顧客削除されてしまった
DELETE FROM customers;  -- 誤操作
COMMIT;

-- 解決方法（バックトラック）
1. AWS RDS コンソール → Backtrack
2. 時刻: 2024-04-20 14:29:00 に指定
3. 「Backtrack」をクリック
4. 15 秒後 → データ復旧完了（アプリは継続稼働）

設定

Backtrack 有効化:
  - DB クラスター作成時に指定
  - 保持期間: 24 時間～72 時間の範囲で設定
  - コスト: バックトラック容量 × 日数
  
例）
  72 時間バックトラック有効化
  月額コスト: バックトラックストレージ容量 × $0.15/GB/月

Blue/Green Deployment

初心者向けメモ： Blue/Green は「本番 DB をアップグレードする時、ダウンタイムなし」で実現する仕組みです。Blue（現在）と Green（新規）を用意して、瞬間的に切り替えます。

フロー

現状（Blue）
    ├── MySQL 8.0
    ├── db.r6g.2xlarge × 3
    └── 稼働中

準備（Green 環境生成）
    ├── MySQL 8.4（最新）にアップグレード
    ├── db.r6g.2xlarge × 3（同スペック）
    ├── Blue のクローンから生成（数秒）
    └── テスト・検証（数時間可能）

切り替え（Switchover）
    ├── Blue → Green に DNS 切替（秒単位）
    ├── トラフィック自動転送
    └── ロールバック可能（Green → Blue に戻す）

廃止
    └── Blue は削除またはスタンバイ保持

メリット

✅ ゼロダウンタイム（DNS 切替のみ、秒単位） ✅ メジャーバージョンアップグレード（MySQL 8.0 → 8.4 など） ✅ パラメータグループ変更（innodb_buffer_pool など） ✅ ロールバック可能（何か問題があれば 1 分で戻す） ✅ テスト期間を確保（Green 環境で数時間テスト可能）

実装

# Blue/Green デプロイ作成
aws rds create-blue-green-deployment \
  --blue-green-deployment-name mydb-upgrade-20240420 \
  --source mydb-cluster-arn

# 検証期間（Green で十分テスト）

# Switchover（本番切替）
aws rds switchover-blue-green-deployment \
  --blue-green-deployment-identifier bgd-xxxxx
  
# ロールバック（必要な場合）
aws rds switchover-blue-green-deployment \
  --blue-green-deployment-identifier bgd-xxxxx

Babelfish for PostgreSQL

初心者向けメモ： Babelfish は「SQL Server のコードが PostgreSQL で動く」実現する互換レイヤーです。SQL Server から移行する時に、アプリコード修正をほぼゼロで実現できます。

用途

SQL Server → Aurora PostgreSQL のマイグレーション

従来（コード書き換え必須）：
  SQL Server 専用 SQL
      ↓ コード全削除
  PostgreSQL に書き直し
  
Babelfish使用:
  SQL Server 専用 SQL（そのまま）
      ↓
  Aurora PostgreSQL + Babelfish（互換性）

Babelfish 対応機能

機能 対応
T-SQL（SQL Server SQL） ✅ 対応
sp_executesql ✅
動的 SQL ✅
IDENTITY（自動採番） ✅
XML 型 ✅
バッチ処理 ✅

制限

❌ SQL Server 固有機能（Replication、Agent） ❌ SSIS（Integration Services） ❌ Analysis Services（OLAP）

Aurora Optimized Reads / Writes

初心者向けメモ： これは「I/O 課金の構造を変える」新しい課金オプションです。I/O が多いワークロードで、従来課金の 40% 削減を実現します。

従来課金（標準）

インスタンス料金: db.r6g.2xlarge = ¥30,000/月
ストレージ料金: 500 GB = ¥5,000/月
I/O 料金: 100 万イクエスト × ¥0.2 = ¥20,000/月

月額合計: ¥55,000

Optimized Reads 課金

インスタンス料金: db.r6g.2xlarge + Optimized = ¥40,000/月
ストレージ料金: 500 GB = ¥5,000/月
I/O 料金: 0（定額化）

月額合計: ¥45,000（20% 削減！）

Optimized Writes 課金

  • ライト I/O を定額化（特に変更多いワークロード向け）
  • 従来: ¥20,000/月
  • 最適化: ¥8,000/月（60% 削減！）

選択基準

ワークロード 推奨オプション
OLTP（トランザクション多） Optimized Writes
分析・集計（読み込み多） Optimized Reads
混合 Optimized Reads + Writes
シンプル CRUD 標準課金（I/O 料金少）

ML 統合（Aurora ML・Bedrock）

Aurora ML（SageMaker 統合）

SQL から直接機械学習推論を呼び出し：

-- 顧客チャーン予測
SELECT customer_id,
       aws_ml.invoke_endpoint(
           'churn-model',
           customer_age,
           customer_value,
           days_inactive
       ) AS churn_probability
FROM customers
WHERE aws_ml.invoke_endpoint(...) > 0.7;

セットアップ

# SageMaker endpoint 作成
aws sagemaker create-endpoint \
  --endpoint-name churn-predictor \
  --endpoint-config-name churn-config

# Aurora から endpoint を関連付け
aws rds modify-db-cluster \
  --db-cluster-identifier mydb-cluster \
  --enable-aurora-ml \
  --associated-roles arn:aws:iam::xxxx:role/service-role

Amazon Bedrock 統合

生成 AI モデル（Claude、Llama）を SQL から呼び出し：

-- 商品説明を自動生成
SELECT product_id,
       bedrock.invoke_model(
           'anthropic.claude-instant',
           CONCAT('商品名:', product_name, 
                  '、特徴:', product_features,
                  '。説明文を生成してください。')
       ) AS generated_description
FROM products;

ベクトル検索（pgvector）

初心者向けメモ： ベクトル検索は「意味で検索する」機能です。「赤い靴」を検索しても、「赤いスニーカー」も引き出せます（意味が近いから）。PostgreSQL のpgvector拡張を使用します。

セットアップ

-- pgvector 拡張を有効化
CREATE EXTENSION IF NOT EXISTS vector;

-- ベクトル列を追加
ALTER TABLE products ADD COLUMN embedding vector(1536);

-- インデックス作成（高速化）
CREATE INDEX ON products USING ivfflat (embedding vector_cosine_ops)
  WITH (lists = 100);

実装例

-- 商品レコメンデーション
WITH query_embedding AS (
  SELECT bedrock.generate_embedding('靴') AS vec
)
SELECT product_id, product_name,
       1 - (p.embedding <=> q.vec) AS similarity
FROM products p, query_embedding q
WHERE 1 - (p.embedding <=> q.vec) > 0.8
ORDER BY similarity DESC
LIMIT 10;

セキュリティ

初心者向けメモ： Aurora は「多層防御」でデータを守ります。DB レベル・ネットワークレベル・暗号化レベルで段階的に保護します。

図 4: Aurora セキュリティレイヤー

graph TD
    App["アプリケーション"]
    
    subgraph Security["セキュリティレイヤー"]
        IAM["レイヤー 1: IAM 認証<br/>UUID ベース認証<br/>一時トークン（15 分有効）"]
        TLS["レイヤー 2: TLS 暗号化<br/>転送中の通信保護"]
        VPC["レイヤー 3: VPC 隔離<br/>プライベートサブネット<br/>SG で接続元制限"]
        KMS["レイヤー 4: KMS 暗号化<br/>保存時の暗号化<br/>キー管理"]
        Audit["レイヤー 5: 監査ログ<br/>全 SQL を CloudWatch 記録"]
    end
    
    App --> IAM --> TLS --> VPC --> KMS --> Audit

1. ネットワークセキュリティ

VPC 配置

VPC: vpc-12345678
├── プライベートサブネット（DB 配置）
│   └── 10.0.1.0/24（AZ1）
│   └── 10.0.2.0/24（AZ2）
│   └── 10.0.3.0/24（AZ3）
│
├── パブリックサブネット（踏台）
│   └── ALB で外部アクセス
│
└── セキュリティグループ
    └── インバウンド: ポート 3306（MySQL）
        送信元: app-sg（アプリケーション SG）のみ

実装

# SG で接続元制限
aws ec2 authorize-security-group-ingress \
  --group-id sg-12345678 \
  --protocol tcp --port 3306 \
  --source-group sg-app-xxxxxxx

# 結果: app-sg のアプリからのみ接続可能

2. IAM 認証（パスワード不要）

初心者向けメモ： 従来：パスワード → DB に保存（盗聴・漏洩リスク） IAM 認証：UUID トークン → AWS STS で検証（盗聴しても無効）

セットアップ

# IAM ロール作成
aws iam create-role --role-name rds-iam-auth-role \
  --assume-role-policy-document file://trust-policy.json

# ポリシー追加
aws iam put-role-policy --role-name rds-iam-auth-role \
  --policy-name rds-iam-policy \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Action": "rds-db:connect",
      "Resource": "arn:aws:rds:ap-northeast-1:123456789:db:mydb/*"
    }]
  }'

# DB クラスター有効化
aws rds modify-db-cluster \
  --db-cluster-identifier mydb-cluster \
  --enable-iam-database-authentication

クライアント接続

# トークン生成（15 分有効）
TOKEN=$(aws rds generate-db-auth-token \
  --hostname mydb.c123456789.ap-northeast-1.rds.amazonaws.com \
  --port 3306 \
  --region ap-northeast-1 \
  --username iamuser)

# MySQL 接続（パスワード = トークン）
mysql -h mydb.c123456789.ap-northeast-1.rds.amazonaws.com \
  -P 3306 \
  -u iamuser \
  --password=$TOKEN \
  --enable-cleartext-plugin

3. KMS 暗号化（保存時）

# KMS キー作成
KEY_ID=$(aws kms create-key --description "Aurora DB key" \
  --query 'KeyMetadata.KeyId' --output text)

# DB クラスター作成（暗号化有効）
aws rds create-db-cluster \
  --db-cluster-identifier mydb-cluster \
  --engine aurora-mysql \
  --kms-key-id arn:aws:kms:ap-northeast-1:123456789:key/$KEY_ID

注意

⚠️ KMS キーは作成後変更不可 （変更は：スナップショット → 新キーで復旧 → 手動）

4. TLS/SSL 暗号化（転送時）

デフォルトで有効：

# MySQL クライアント（TLS 強制）
mysql -h mydb-cluster.xxx.rds.amazonaws.com \
  --ssl-mode=REQUIRED \
  -u admin -p

5. Enhanced Audit Logging

# クエリログを CloudWatch に送信
aws rds modify-db-cluster \
  --db-cluster-identifier mydb-cluster \
  --enable-audit-logs \
  --log-types audit \
  --apply-immediately

CloudWatch に記録される情報：

{
  "timestamp": "2024-04-20T14:30:00Z",
  "username": "appuser",
  "query": "SELECT * FROM customers WHERE id = 123",
  "status": "OK",
  "rows_affected": 1
}

モニタリング

Performance Insights

CPU / DB Load / アクティブセッション を可視化
    ↓
どのクエリがボトルネック？
    ↓
最適化ポイントを特定

コンソール表示

時系列グラフ:
  ├── DB Load（DB に対する負荷）
  │   └── 通常 1-2、ピーク時 5-10
  │
  ├── アクティブセッション
  │   └── 同時実行クエリ数
  │
  └── Top SQL
      ├── SELECT ... FROM customers（45%）
      ├── UPDATE orders SET ...（30%）
      └── DELETE FROM logs ...（25%）

Enhanced Monitoring

OS レベルのメトリクス：

  • CPU / メモリ / ディスク I/O / ネットワーク

CloudWatch に送信（1 秒粒度）：

aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name CPUUtilization \
  --start-time 2024-04-20T00:00:00Z \
  --end-time 2024-04-20T01:00:00Z \
  --period 300 \
  --statistics Average

RDS vs Aurora の違い

観点 RDS Aurora
アーキテクチャ エンジン + ストレージ統合 分離設計（Compute / Storage）
性能 MySQL 比 1x MySQL 比 5x・PG 比 3x
フェイルオーバー 60～120 秒 < 30 秒
リードレプリカ 最大 5 最大 15
ストレージ拡張 手動（マニュアル） 自動（10 GB 単位）
ストレージ上限 65 TiB 128 TiB
バックトラック ❌ ✅（MySQL のみ）
Serverless ❌ ✅（v2）
Global Database ❌（読み取り専用リードレプリカ） ✅
互換エンジン MySQL / PostgreSQL / Oracle / SQL Server / Db2 / MariaDB MySQL / PostgreSQL のみ
コスト感 低い やや高い（パフォーマンス分）
運用負荷 中程度 低い（自動化多）

他の類似ツールとの比較

製品 タイプ 強み 弱み コスト
Aurora マネージド RDS（AWS） パフォーマンス・可用性・自動化 MySQL/PG のみ 中程度
Google AlloyDB マネージド RDS（GCP） PostgreSQL 特化・高性能 GCP 依存 やや高
Cloud Spanner グローバル分散 DB（GCP） グローバル ACID・スケーラビリティ 高コスト・SQL 方言 高い
CockroachDB 分散 SQL（OSS） グローバル・自動分散 運用複雑・学習曲線急 中程度
YugabyteDB 分散 SQL（OSS） PostgreSQL 互換・分散 コミュニティ規模小 低
PlanetScale MySQL サーバーレス シンプル・安価・スケーラブル MySQL のみ・GitOps 重視 安い
Neon PostgreSQL サーバーレス 開発者向け・自動スケール ベータ・機能制限 格安
Supabase PostgreSQL + Auth オールインワン・開発向け 小規模向け 格安

選択フロー

既存 MySQL / PostgreSQL アプリ？
    ├─ YES：Aurora
    │
    └─ NO：新規構築？
        ├─ YES：分散必須？
        │   ├─ YES：Spanner / DSQL
        │   └─ NO：開発者向け？
        │       ├─ YES：Neon / Supabase
        │       └─ NO：Aurora（最高性能）
        │
        └─ NO：クラウド移行？
            ├─ GCP：AlloyDB
            └─ AWS：Aurora

クライアントとエコシステム

CLI・SDK

ツール 対応
AWS CLI ✅ aws rds
boto3（Python） ✅
AWS SDK（他言語） ✅
Terraform ✅ aws_rds_cluster
CloudFormation ✅

マイグレーション

DMS（Database Migration Service）
    ├── 異なる DB エンジン間の移行
    │   例）Oracle → Aurora
    │
    └── Schema Conversion Tool
        └── スキーマを自動変換

RDS Proxy（接続管理）

Lambda・ECS での接続枯渇対策：

Lambda（短命接続）
    ↓（大量）
RDS Proxy（接続プール管理）
    ↓
Aurora（長時間接続維持）

ベストプラクティス

1. インスタンスサイズ選定

  • 初期段階: db.t3.medium（テスト用）
  • 成長期: db.r6g.2xlarge（メモリ最適化）
  • 規模時: Serverless v2 + Auto Scaling（柔軟対応）

2. リードレプリカ配置

  • 標準: ライター 1 + リーダー 2-3
  • 高負荷: ライター 1 + リーダー 5-7 + Serverless v2
  • 分析: 専用リーダー（Custom Endpoint）

3. バックアップ戦略

  • 毎日: 自動 PITR（35 日保持）
  • 週 1 回: 手動スナップショット
  • 重要タイミング: バックトラック設定（MySQL）

4. セキュリティ

✅ KMS 暗号化（作成時に設定）
✅ IAM 認証（パスワード廃止）
✅ VPC 隔離（プライベートサブネット）
✅ TLS/SSL（デフォルト有効）
✅ Enhanced Audit Log（CloudWatch 送信）

5. モニタリング・アラート

Performance Insights で定期監視
    ↓
CloudWatch アラーム設定
    ├── CPU > 70%
    ├── Connection Pool 枯渇
    └── レプリケーション遅延 > 1 秒
    
結果 → Slack / PagerDuty に通知

トラブルシューティング

症状 1: 接続タイムアウト

原因： セキュリティグループで接続元が制限されている

# 確認
aws ec2 describe-security-groups \
  --group-ids sg-12345678 \
  --query 'SecurityGroups[0].IpPermissions'

# 修正：アプリケーション SG を追加
aws ec2 authorize-security-group-ingress \
  --group-id sg-12345678 \
  --protocol tcp --port 3306 \
  --source-group sg-app-xxxxxx

症状 2: CPU 100% 使用率

原因： リードレプリカ不足

-- 実行中のクエリ確認
SHOW PROCESSLIST;

-- 解決：
-- 1. リードレプリカ追加（リーダーエンドポイント用）
-- 2. Serverless v2 リーダー追加（自動スケール）
-- 3. インデックス追加（クエリ最適化）

症状 3: レプリケーション遅延（リーダー遅延）

原因： リーダーが書き込み処理に追い付かない

# 遅延確認
aws rds describe-db-clusters \
  --db-cluster-identifier mydb-cluster \
  --query 'DBClusters[0].ReplicationLag'

# 対策：
# 1. リーダー数を増やす
# 2. Serverless v2 リーダー追加
# 3. ライターの書き込み最適化

症状 4: スロークエリ

原因： インデックス不足

-- スロークエリログ確認
SELECT query, latency FROM slow_log LIMIT 10;

-- インデックス追加
CREATE INDEX idx_customer_id ON orders(customer_id);

-- EXPLAIN で実行計画確認
EXPLAIN SELECT * FROM orders WHERE customer_id = 123;

症状 5: ストレージ満杯（128 TB 近い）

原因： 古いデータ削除していない

-- パーティショニングで古いデータ削除
ALTER TABLE logs DROP PARTITION p_2024_01;

-- または、古いレコード削除
DELETE FROM logs WHERE created_at < DATE_SUB(NOW(), INTERVAL 90 DAY);

2025-2026 最新動向

Aurora DSQL エコシステム急速拡大（2026 年 2-4 月）

2026 年 2 月～4 月での言語コネクタ・ツール統合の爆発的拡張。

言語サポート拡張:
├── Go（pgx）・Python（asyncpg）・Node.js（Postgres.js）2026 年 2 月
├── Ruby（pg gem）・.NET（Npgsql）・Rust（SQLx）2026 年 3 月
└── PHP（PDO_PGSQL）2026 年 4 月

開発ツール統合:
├── Visual Studio Code SQLTools（2026 年 2 月）
├── DBeaver Community Edition（2026 年 2 月）
└── ブラウザベース Playground（スキーマ作成・SQL 実行）

AI 開発統合:
├── Kiro powers・AI エージェントスキル
└── Model Context Protocol（MCP）によるベストプラクティス共有

リージョン拡張:
├── Asia Pacific (Melbourne), (Sydney)
├── Canada (Central), (Calgary)
└── 計 31+ リージョンで利用可能

コア機能:
├── NUMERIC データ型のインデックス対応（2026 年 2 月）
├── マルチリージョン読み書き（強一貫性 ACID）
└── IAM トークン自動生成・SSL 設定・接続プーリング

Aurora MySQL 8.4・PostgreSQL 17/18 対応

MySQL 8.4 LTS（2025 年）
    ├── レプリケーション改善
    ├── JSON ハンドリング強化
    └── Aurora に統合予定

PostgreSQL 17（2024年10月）・18（2025年）
    ├── JSON テーブル関数
    ├── 並列クエリ 35% 高速化
    ├── メモリ管理（真空）最適化
    ├── pgvector 拡張統合
    └── Aurora に 2026 年対応

Aurora Serverless v3 拡張

スケール範囲拡大: 0.5～1000 ACU
    ├── より大規模な変動に対応
    └── エンタープライズワークロード対応

AI・ML 統合強化

Amazon Bedrock との統合
    ├── 生成 AI（Claude、Llama）直接呼び出し
    ├── テキスト生成
    └── RAG（Retrieval-Augmented Generation）

学習リソース

公式ドキュメント

コース・チュートリアル

  • AWS Training（公式）
  • A Cloud Guru - Aurora Deep Dive
  • Linux Academy - RDS / Aurora Essentials

コミュニティ

  • AWS RDS フォーラム
  • Stack Overflow（タグ：amazon-rds）
  • AWS Japan User Group

実装例・活用シーン

例 1: WordPress 高可用性構成

構成:
  DB クラスター:
    エンジン: Aurora MySQL 8.0
    ライター: db.r6g.2xlarge
    リーダー: db.r6g.xlarge × 2 + Serverless v2 × 1
  
  セキュリティ:
    - VPC プライベートサブネット配置
    - IAM 認証有効化
    - KMS 暗号化
  
  バックアップ:
    - PITR: 35 日
    - スナップショット: 週 1 回
  
  モニタリング:
    - Performance Insights
    - CloudWatch アラーム

メリット:
  ✅ プラグイン（WooCommerce 等）の高速化
  ✅ トラフィックピーク時の自動スケール
  ✅ 複数アベイラビリティゾーン高可用性

例 2: SaaS マルチテナント

構成:
  DB クラスター:
    エンジン: Aurora PostgreSQL 16
    ライター: Serverless v2（0.5～64 ACU）
    リーダー: Serverless v2 × 2（自動スケール）
  
  テーブル設計:
    - tenant_id カラムで多テナント管理
    - パーティショニング（テナント単位）
  
  Custom Endpoint:
    - 分析用リーダー（高スペック）
    - レポート生成専用
  
  セキュリティ:
    - Row Level Security（RLS）で各テナント隔離

スケーリング:
  テナント 100 → 1000: Serverless v2 自動対応
  開発段階: 0.5 ACU 最小で低コスト

例 3: 金融決済 API

構成:
  DB クラスター:
    エンジン: Aurora MySQL 8.4
    ライター: db.r6i.4xlarge（高 IOPS）
    リーダー: db.r6i.2xlarge × 5（決済クエリ分散）
    RDS Proxy: Lambda 接続プール管理
  
  セキュリティ:
    - KMS（PCI DSS Level 3 対応）
    - IAM 認証（パスワード廃止）
    - Enhanced Audit Logging（全 SQL 記録）
    - VPC 内隔離
  
  バックアップ:
    - PITR（毎秒）
    - スナップショット（毎時間）
    - 別 AWS アカウントに DR

パフォーマンス:
  同時トランザクション: 1 万 TPS
  レイテンシ: p99 < 50 ms

導入ロードマップ

フェーズ 1: 準備期（1-2 週間）

チェックリスト:
  ☑ 現状 RDS / MySQL 調査
  ☑ マイグレーション対象テーブル特定
  ☑ パフォーマンス目標定義
  ☑ セキュリティ要件確認
  ☑ コスト試算

フェーズ 2: 環境構築（2-4 週間）

手順:
  1. テスト環境 Aurora クラスタ構築
     aws rds create-db-cluster \
       --db-cluster-identifier test-aurora-mysql \
       --engine aurora-mysql8.0 \
       ...
  
  2. ストレージ・バックアップ設定
  3. セキュリティ設定（VPC / KMS / IAM）
  4. Performance Insights 有効化

フェーズ 3: マイグレーション・検証（4-8 週間）

方法:
  Option 1: AWS DMS（オンプレミス → Aurora）
  Option 2: mysqldump → restore
  Option 3: RDS MySQL → Aurora（スナップショット復旧）
  
検証:
  ☑ データ完全性確認
  ☑ パフォーマンステスト
  ☑ アプリ互換性テスト
  ☑ セキュリティテスト

フェーズ 4: 本番切替（1-2 日）

カットオーバー:
  1. Blue/Green デプロイメント作成
  2. Green 環境で最終テスト
  3. Switchover（DNS 切替）
  4. ロールバック手順確認
  5. 本番稼働開始
  
ロールバック:
  問題あれば 1 分で旧 Blue に戻す

フェーズ 5: 運用・最適化（継続）

継続活動:
  ☑ Performance Insights 定期確認
  ☑ CloudWatch アラーム監視
  ☑ バックアップ検証（月 1 回）
  ☑ セキュリティパッチ適用
  ☑ コスト最適化（Serverless v2 活用等）

実装チェックリスト

インスタンス・ネットワーク

  • [ ] クラスタ作成（db クラスター名・エンジン・バージョン指定）
  • [ ] ライターインスタンス作成（インスタンスクラス選定）
  • [ ] リーダーインスタンス作成（最低 2 個推奨）
  • [ ] VPC・サブネット配置
  • [ ] セキュリティグループ設定
  • [ ] パラメータグループ設定

バックアップ・HA

  • [ ] 自動バックアップ有効化（PITR）
  • [ ] スナップショット保持ポリシー
  • [ ] バックトラック有効化（MySQL 互換のみ）
  • [ ] マルチ AZ 有効化（デフォルト推奨）
  • [ ] リードレプリカ優先度設定

セキュリティ

  • [ ] KMS 暗号化（作成時指定）
  • [ ] IAM 認証有効化
  • [ ] VPC エンドポイント設定（オプション）
  • [ ] Enhanced Audit Logging 有効化
  • [ ] CloudTrail で API コール記録

モニタリング・アラート

  • [ ] CloudWatch アラーム（CPU / Connection / Replication Lag）
  • [ ] Performance Insights 有効化
  • [ ] Enhanced Monitoring 有効化
  • [ ] Slack / PagerDuty 通知統合

アプリケーション

  • [ ] アプリから接続テスト
  • [ ] クエリ最適化（インデックス追加）
  • [ ] コネクションプール設定（RDS Proxy オプション）
  • [ ] キャッシング戦略（Redis / ElastiCache）

ドキュメント・運用

  • [ ] フェイルオーバー手順書作成
  • [ ] リカバリ手順書作成
  • [ ] 利用者教育・トレーニング
  • [ ] 定期バックアップ検証スケジュール

まとめ

**Aurora は「AWS が ゼロから設計した最高性能マネージドデータベース」**です。

最重要ポイント

  1. 性能: ストレージ・コンピュート分離で MySQL 比 5 倍・PostgreSQL 比 3 倍のスループット
  2. 高可用性: 3 AZ × 2 コピー 6 方向レプリケーション、30 秒未満フェイルオーバー
  3. スケーラビリティ: Serverless v2 で秒単位自動スケール、リーダー最大 15 個
  4. グローバル: Aurora Global Database で 5 リージョンへの低遅延レプリケーション
  5. セキュリティ: KMS・IAM・VPC・監査ログで多層防御
  6. 運用負荷低減: 自動バックアップ・自動パッチ・自動フェイルオーバー

こういう場合は Aurora を選ぶ

✅ MySQL / PostgreSQL ベースの高可用性・高パフォーマンスが必須 ✅ トラフィック変動が大きく自動スケーリング必要 ✅ グローバルサービスで低遅延読み取り必要 ✅ 本番ワークロード・ミッションクリティカル

こういう場合は他を検討

❌ Oracle / SQL Server 必須 → RDS ❌ 開発・テスト環境で低コスト重視 → RDS MySQL / PostgreSQL ❌ 複数リージョン読み書き必須 → DSQL / Spanner ❌ 単純 CRUD で無サーバー・最小コスト → PlanetScale / Neon

参考文献

AWS 公式

解析・最適化

コミュニティ・学習

  • AWS Training and Certification
  • A Cloud Guru
  • Linux Academy
  • AWS Japan ブログ

ドキュメント最終更新: 2026 年 4 月 Aurora バージョン: Aurora MySQL 8.4、Aurora PostgreSQL 17 DSQL 状況: GA 予定（2025-2026）