1. 意思決定の背景と実務上の重要課題
Webアプリケーションの可用性を設計する際、最大のボトルネックとなるのは常にステートフルな永続層、すなわちリレーショナルデータベース（RDB）である。ステートレスなWebサーバーやコンテナはAuto Scalingとロードバランサーにより数分で自己修復・増減が可能だが、データベースの停止はトランザクションの即時破綻、決済失敗、顧客離脱、そして重大な機会損失に直結する。
多くのエンジニアリングマネージャーやインフラ責任者が直面する選択肢は、以下の3系統に集約される。
- Amazon Aurora（Multi-AZ クラスタ構成）
- Amazon RDS for PostgreSQL / MySQL（Multi-AZ インスタンス構成、およびRead Replica追加）
- EC2上の自前レプリケーション（Patroni, Orchestrator, Pacemaker/Corosync等を用いたOSSセルフホスト）
ここで頻発する議論が「AuroraはRDSに比べて約20〜30%高い。このコスト差はダウンタイム削減に見合っているのか」という疑問である。多くのプロジェクトで、単に「マネージドだから安心」「予算がないから標準RDSで」といった定性的な判断が下され、障害発生時に想定外のダウンタイム（60秒〜数分）が発生して経営層から追及される事態が発生している。
この意思決定を合理化するためには、各アーキテクチャの根本的な違いを理解する必要がある。
- フェイルオーバーメカニズムの差異（DNSレコード切り替え vs クラスタエンドポイントと共有ストレージ）
- クラッシュリカバリに伴うディスク走査時間の有無
- レプリケーション遅延（レプリカラグ）の発生確率とRPO（目標復旧時点）
- 単純なコンピュート・ストレージ料金のみならず、I/O課金および運用保守人件費を含めた真のTCO（総保有コスト）
RDS Multi-AZの公称フェイルオーバー時間は通常60〜120秒（1〜2分）である。一方、Auroraは通常30秒未満（最短十数秒）で完了し、ストレージ層は3つのアベイラビリティゾーン（AZ）にわたって6重化されているため、ディスク障害時の再構築処理（リビルド）によるコンピュート負荷変動が存在しない。
停止時間1分あたりのビジネス損失額が、月額のAWSインフラ差額（数万円〜数十万円）を上回るか否か。この損得分岐点を特定することが、本稿の目的である。
2. 【条件別】損得分岐マトリクス（早見表）
ビジネス要件（許容停止時間、許容データ損失、トラフィック特性）およびインフラ予算に基づいて導き出される最適解のマトリクスを以下に示す。
| ビジネス要件・トラフィック特性 | 許容ダウンタイム (RTO) | 許容データ損失 (RPO) | 推奨アーキテクチャ | コスト水準（月額目安） | 採択の論理的根拠 |
|---|---|---|---|---|---|
| BtoC大規模EC・決済・SaaS基幹 数分の停止で分単位数百万円の損失、書き込み・読み込みが高頻度 | 30秒未満 (自動修復) | 0秒 (完全同期・ストレージ6重化) | Amazon Aurora (Multi-AZ, 2インスタンス以上) | 基準額の120%〜140% (I/O課金またはIOPS最適化) | ストレージ共有型アーキテクチャによりクラッシュリカバリ不要。30秒以内の高速昇格とリードレプリカの自動昇格で即時復旧。 |
| BtoB業務SaaS・社内システム 夜間・休日の数分停止は許容、平日の月間稼働率99.95%を要求 | 1分〜2分 (DNS切り替え待機) | 0秒 (ブロックレベル同期) | Amazon RDS (Multi-AZ構成) | 基準額の100% (シングルAZの約2倍) | 物理スタンバイが別AZで常時待機。DNS伝播とクラッシュリカバリに1〜2分要するが、月額固定費をAuroraより抑制可能。 |
| 情報配信メディア・参照偏重型Web 更新頻度は低く、大量の参照要求がありコストを極小化したい | 数分〜数十分 (手動/スクリプト昇格) | 数秒〜数分の遅延 (非同期レプリカ) | Amazon RDS (Single-AZ + Read Replica) | 基準額の70%〜90% (インスタンス仕様による) | Multi-AZスタンバイを持たず、非同期リードレプリカを昇格させる運用。レプリカラグによるデータ消失リスクと昇格工数を許容してコスト優先。 |
| 超特殊要件・クラウド脱却方針 AWS利用料削減至上主義、専属SREチームが24時間常駐 | 30秒〜数分 (設定・自動化依存) | 0秒〜数秒 (半同期/非同期設定依存) | EC2自前レプリケーション (Patroni + PostgreSQL等) | インフラ費: 基準の50% ※ただし人件費で逆転 | インフラ利用料単体は最小化できるが、運用パッチ・HAスクリプト保守・DR体制に多大な人件費を要し、TCOでは多くの場合で敗北。 |
3. 【徹底対比】主要選択肢の構造・スペック・料金比較
3大選択肢のアーキテクチャ、フェイルオーバー挙動、データ保護構造、および料金モデルの詳細対比は下表の通りである。
| 比較項目 | Amazon Aurora (MySQL/PostgreSQL) | Amazon RDS Multi-AZ (db.r6g) | 自前EC2レプリケーション (Patroni/MySQL MHA等) |
|---|---|---|---|
| ストレージアーキテクチャ | 分散ストレージ（3 AZにわたり6コピー） コンピュートとストレージが完全分離 | 共有なし（EBSボリューム同期レプリケーション） ブロックレベル同期 | 各EC2に個別EBS/ローカルNVMeをアタッチ エンジンネイティブのレプリケーション |
| 障害検知・切り替え方式 | クラスタマネージャーによるクォーラム監視 CNAME切り替えまたはAurora接続ドライバ | 監視プロセスによるDNS切り替え（CNAME） スタンバイノードへのルーティング更新 | 分散合意（Consul / etcd等）によるVIP切り替え またはRoute 53動的更新 |
| 平均フェイルオーバー時間 (RTO) | 通常10〜30秒以内 (接続ドライバ利用時は10秒未満) | 60〜120秒（1〜2分） (DNS伝播時間＋REDOログ適用時間) | 30〜180秒 (検知設定・フェンシング処理に依存) |
| レプリケーション遅延 (Lag) | ミリ秒未満（通常10ms以下） ストレージ層で直接読み取り | 非同期（Read Replica時）: 数十ms〜数秒 Multi-AZスタンバイは同期（参照不可） | 数ミリ秒〜数分 (ネットワーク帯域・書き込み負荷依存) |
| クラッシュリカバリの要否 | 不要 (ログ構造化ストレージがバックグラウンド修復) | 必要 (スタンバイ機が未適用のREDOログを再生) | 必要 (未コミットトランザクションのロールバック等) |
| 最大リードレプリカ数 | 最大15台（単一共有ストレージ参照） | 最大15台（各レプリカが個別EBSを保持） | 物理リソースが許す限り（通常3〜5台が限界） |
| ストレージの自動拡張 | 最大128 TiBまで自動拡張（10 GiB単位） 縮小時も自動解放 | 最大64 TiBまで自動拡張可能 ※ストレージ容量の自動縮小は不可 | 運用者が手動または自作スクリプトでLVM/EBS拡張 縮小は再構築が必要 |
| SLA（月間稼働率） | 99.99%（クラスタ構成時） | 99.95%（Multi-AZ配置時） | なし（EC2単体SLA 99.99%の複合計算） |
| 料金構造 | コンピュート料金＋ストレージ容量＋I/O課金 （Aurora I/O-Optimized選択時はI/O課金なし） | コンピュート料金（シングルAZの約2倍）＋プロビジョンドEBS容量＋EBS IOPS/スループット | EC2インスタンス料金＋EBS料金 ＋運用監視ツールコスト＋保守人件費 |
| 東京リージョン単価感 (db.r6g.xlarge 基準) | インスタンス: 約$0.58/時間 ストレージ: $0.12/GB-月 I/O: $0.24/100万リクエスト | Multi-AZインスタンス: 約$1.012/時間 gp3ストレージ: $0.138/GB-月 （ベースラインIOPS/帯域は込み） | EC2 (r6g.xlarge × 2台): 約$0.504/時間 gp3ストレージ × 2台分 ＋監視用クォーラムノード（t4g等） |
技術的深層：なぜAuroraとRDS Multi-AZで復旧時間に大差が出るのか
RDS Multi-AZは、プライマリインスタンスのブロックデバイス（EBS）の更新を同期的にセカンダリAZのEBSへミラーリングする。耐障害性は極めて高いが、障害発生時の切り替えプロセスは以下のステップを踏む。
- プライマリインスタンスのハートビート途絶を検出（約30秒〜40秒）。
- セカンダリ機をアクティブ化し、DNSのCNAMEレコードを書き換える。
- セカンダリ機内部のDBエンジンが起動またはアクティブ状態へ遷移し、直前に書き込まれたトランザクションログ（REDOログ/WAL）を再生してメモリとディスクの整合性を復元する（クラッシュリカバリ）。
- クライアント側のDNSキャッシュがTTL経過後に切れ、新しいIPへ再接続する。
このうち「クラッシュリカバリ」にかかる時間は、障害直前の書き込み負荷（ダーティページの量）に完全に依存する。大量のバッチ処理や高負荷トランザクションの最中にプライマリが落ちた場合、復旧完了までに3分〜5分以上を要するケースが存在する。
対照的に、Auroraは「ログがデータベースそのものである」という思想に基づき設計されている。データベースエンジンは更新されたデータブロックそのものではなく「REDOログレコード」のみを分散ストレージフリートに書き込む。6つのストレージノードのうち4つがACKを返せばコミットが成立する（クォーラム方式）。
フェイルオーバー時には、スタンバイとなっているリードレプリカが即座にプライマリへ昇格するが、ストレージ層はすでに更新ログを継続的に適用済みであるため、従来のクラッシュリカバリ処理（大規模なREDOログのシーケンシャル再生）が一切発生しない。結果として、障害発生から一貫して10〜30秒以内でフェイルオーバーが完了する。
4. 【規模別・年数別】3年間の実額TCO（総保有コスト）シミュレーション
インフラコストの比較において、AWSの請求書金額のみを比較することは致命的なミスを招く。自前運用の場合はパッチ適用、DR訓練、監視障害対応に割かれるエンジニアの人件費を計上しなければならない。
以下の条件で3年間のTCOを試算する。
- リージョン: 東京リージョン（ap-northeast-1）
- 為替レート: 1 USD = 150 JPY
- 構成規模: 中規模Webシステム（トランザクション頻度: 月間1億回のI/Oリクエスト、データ容量: 1TB、年次成長率20%）
- コンピュート規模: 4 vCPU / 32 GiB RAMクラス（r6g.xlarge相当）
- Aurora構成: Multi-AZ（Writer 1台 + Reader 1台、計2ノード）、Standardストレージプラン
- RDS構成: Multi-AZ（Active-Standby 1セット）、EBS gp3（1TBプロビジョンド）
- EC2自前構成: r6g.xlarge × 2台（Active/Standby） + クォーラム用t4g.small × 1台、EBS gp3（1TB × 2台分）
- SRE/DBA人件費: 1人月 = 120万円（1時間あたり7,500円換算）
| コスト内訳（3年間累計） | Amazon Aurora (Multi-AZ) | Amazon RDS (Multi-AZ) | EC2自前レプリケーション (Patroni構成) |
|---|---|---|---|
| コンピュート利用料 | 約4,633,200円 ($0.587/h × 2台 × 26,280h) | 約3,989,000円 ($1.012/h × 26,280h) | 約2,096,000円 (EC2 2台 + t4g 1台 × 26,280h) |
| ストレージ利用料 (初年度1TB〜3年目1.44TB) | 約972,000円 (平均1.2TB × $0.12/GB-月) | 約1,117,800円 (gp3 1.2TB × $0.138/GB-月) | 約2,235,600円 (2台分保持: 2.4TB × $0.138) |
| I/O・データ転送課金 | 約1,296,000円 (1億回/月 × $0.24/100万回 × 36ヶ月) | 0円 (gp3基本性能内は追加なし) | 0円 (EBS gp3基本性能内) |
| バックアップストレージ費用 | 約243,000円 (スナップショット超過分) | 約280,000円 (スナップショット保持分) | 約560,000円 (EBSスナップショット2台分運用) |
| インフラ直接費 小計 (A) | 約7,144,200円 | 約5,386,800円 | 約4,891,600円 |
| 初期構築・HA検証工数 | 180,000円 (24時間) | 180,000円 (24時間) | 1,800,000円 (240時間: 検証・自動化) |
| OS/DBパッチ適用・保守工数 | 540,000円 (月2時間 × 36ヶ月) | 540,000円 (月2時間 × 36ヶ月) | 3,240,000円 (月12時間 × 36ヶ月) |
| 障害訓練・リカバリ手順維持 | 270,000円 (半期6時間 × 6回) | 270,000円 (半期6時間 × 6回) | 1,080,000円 (半期24時間 × 6回) |
| 運用人件費 小計 (B) | 約990,000円 | 約990,000円 | 約6,120,000円 |
| 3年間 TCO 総額 (A + B) | 約8,134,200円 | 約6,376,800円 | 約11,011,600円 |
財務的示唆と損得分岐
-
AuroraとRDSの差額評価: 3年間の直接AWS利用料において、AuroraはRDS Multi-AZに対して約175万円（年間約58万円、月額換算で約4.8万円）高い。この月額4.8万円の差額は、障害発生時のダウンタイム差（RDSの1〜2分 vs Auroraの20秒前後）に対する保険料といえる。 サービスの月間売上が3,000万円を超え、停止1分あたり数万円の機会損失および顧客対応コストが発生する環境であれば、Auroraの選択が経済合理性を持つ。
-
自前レプリケーションの経済的破綻: インフラ費用単体では自前EC2構成が最安（3年で約489万円）に見えるが、HAクラスタの維持、パッチ当て、スプリットブレイン対策のテストに伴うエンジニアリング工数が重くのしかかる。運用人件費を加味したTCOでは、自前構成が約1,101万円と最も高額になる。特定業界の閉域網要件やAWS外へのマルチクラウド要件がない限り、セルフホスト構成を採択する経済的理由は存在しない。
🧭 【この分岐とあわせて検討したい意思決定バイブル】
関連する周辺領域の損得分岐点もあわせて確認し、全体の費用対効果を最大化してください。
- 🔗 【中小企業のBCP対策・データバックアップ】AWS S3 Glacier vs Wasabi Hot Cloud Storageの容量単価・復元費用マトリクス
【損得分岐】データ保管容量単価、データ取り出し（Egress）料金、緊急リストア時に発生する想定外の従量課金リスクを精査- 🔗 【条件別】バックアップアプライアンス（Arcserve vs Veeam vs クラウド直結バックアップ）のランサムウェア復旧時間と年間保守費分岐マトリクス
【損得分岐】目標復旧時間（RTO：即時復旧 vs 24時間以内）とイミュータブル（書き換え不能）ストレージの導入コスト検証
5. 実務で直面する「3大失敗パターン」と生々しい回避策
データベース冗長化の設計において、教科書通りの導入を行ったにもかかわらず本番環境で大規模障害を引き起こす典型パターンが3つ存在する。
失敗パターン1: DNSキャッシュによるフェイルオーバーの「見かけ上の長期化」
- 現象: AuroraやRDSが正常に30秒〜1分でフェイルオーバーを完了し、AWSマネジメントコンソール上は健全ステータスに戻っているにもかかわらず、アプリケーション側で「Connection refused」や「Read-only」エラーが10分以上継続する。
- 原因: アプリケーション実行基盤（JVM、Node.js、PHP-FPM、Go等のHTTPデーモン）またはコンテナ内のOSが、データベースのエンドポイントDNS解決結果を無期限または長期間キャッシュしている。DB側のCNAMEが新プライマリのIPアドレスに更新されても、アプリは旧プライマリ（障害機または降格してリードレプリカになった機体）へ接続を試み続ける。
- 泥臭い回避策:
- JVMの場合、
networkaddress.cache.ttlをデフォルトの-1（恒久キャッシュ）から1または5（秒）へ強制上書きする。 - アプリケーション側のコネクションプール（HikariCP、Prisma、TypeORM等）で、接続の最大生存期間（
maxLifetime）を30秒〜60秒程度に短く制限し、定期的に名前解決をやり直させる。 - Auroraの場合は「AWS JDBC Driver」や「AWS SDK for Python (Boto3) DB Cluster Client」を導入する。これらはDNSを介さず、クラスタトポロジー変更を直接APIおよび内部プロトコルで購読するため、DNS伝播遅延を完全に迂回して10秒未満で新Writerへ切り替わる。
- JVMの場合、
失敗パターン2: RDS Single-AZ + Read Replica構成における「非同期レプリカラグによるデータ蒸発」
- 現象: コスト削減のため「RDS Multi-AZ」を避け、「RDS Single-AZ ＋ 非同期Read Replica 1台」で構成。プライマリがハードウェア障害で突然死した際、レプリカを手動でプライマリへ昇格させたところ、直前数分間の注文データ・決済ログが消失。結果として二重引き落としや注文不整合が多発し、データ復旧に数日間のメンテナンス停止を要した。
- 原因:
Read Replicaへの複製は「非同期（Asynchronous）」で行われる。書き込み負荷が高い時間帯には、プライマリのbinlog/WAL生成速度にレプリカのI/Oスレッド・SQLスレッドが追いつかず、レプリケーション遅延（
ReplicaLag）が数秒〜数分単位で発生する。非同期レプリカを昇格（Promote）させた場合、未転送のデータは完全に消失する。 - 泥臭い回避策:
- ゼロデータロス（RPO=0）が要件であるなら、Read Replica単独での冗長化は禁止し、必ずストレージ同期ミラーリングを行う「RDS Multi-AZ」または「Aurora」を採用する。
- やむを得ずリードレプリカ昇格をDR戦略とする場合は、CloudWatchアラームで
ReplicaLagを監視し、1秒を超えた時点でアプリケーション側で書き込み流量制限（Throttling）をかけるサーキットブレーカーを実装する。
失敗パターン3: Aurora Standardプランにおける「バッチ処理・フルスキャンによるI/O課金爆発」
- 現象: RDSからAurora Standardへ移行後、月額のAWS請求額が想定の3倍に跳ね上がった。コンピュート料金は想定通りだったが、「I/Oリクエスト費用」が単月で数十万円請求されていた。
- 原因: Aurora Standardは、ストレージに対する読み書きリクエスト（100万リクエストあたり$0.24）に対して従量課金される。インデックスが適切に効いていない大規模テーブルのフルスキャン、頻繁なテーブルスキャンを伴う夜間バッチ、あるいは非効率なページネーションクエリが実行されると、1回のクエリで数万〜数十万のI/Oが消費される。
- 泥臭い回避策:
- 移行前にワークロードの総I/O数をCloudWatchメトリクス（
VolumeReadIOPs+VolumeWriteIOPs）で精査する。 - 毎月のI/Oコストがストレージ＋コンピュート合計費用の25%〜30%を超える場合は、即座に料金体系を「Aurora I/O-Optimized」へ切り替える。I/O-Optimizedはインスタンス料金が約30%、ストレージ料金が約2.25倍になるが、I/Oリクエスト課金が完全ゼロになるため、読み書きが激しいシステムでは確実にコスト上限を固定できる。
- 移行前にワークロードの総I/O数をCloudWatchメトリクス（
6. あなたの最適解を導く「意思決定フローチャート」
自社システムにとって最も費用対効果の高い冗長化構成を判定するための4分岐ロジックである。
[Q1: 1回のDB障害で「1分以上のサービス全停止」が発生した場合、
許容限度を超える金銭的損失や社会的信用の失墜があるか？]
│
├─ YES ───► [判定: 即時切り替えが必須]
│ │
│ ▼
│ [Q2: DBの読み書き頻度において、月間数億回規模のI/Oが発生するか、
│ あるいはリードトラフィックが膨大で参照分散が必要か？]
│ │
│ ├─ YES ──► 【推奨解 A】
│ │ Amazon Aurora (Multi-AZ)
│ │ ※高I/O特性なら「I/O-Optimized」、
│ │ 通常特性なら「Standard」を選択
│ │ ※AWS公式ドライバによる10秒級フェイルオーバーを実装
│ │
│ └─ NO ───► 【推奨解 B】
│ Amazon Aurora (Multi-AZ) の最小構成
│ または Amazon RDS Multi-AZ + Proxy
│ ※短時間復旧を維持しつつインスタンスサイズを適正化
│
└─ NO ────► [判定: 数分の計画外停止・瞬断を許容可能]
│
▼
[Q3: 障害復旧時に「直前数秒〜数分のデータ消失（RPO>0）」は
ビジネス上絶対に許容できないか？]
│
├─ YES ──► 【推奨解 C】
│ Amazon RDS for PostgreSQL/MySQL (Multi-AZ)
│ ※EBSブロック同期によりデータ欠損はゼロ。
│ ※DNS切り替えに伴う1〜2分の停止を受け入れることで
│ Aurora比20〜30%の月額コストを削減。
│
└─ NO ───► [Q4: インフラ運用に専任SREを割く工数リソースが存在し、
かつAWS外での動作保証が必須要件か？]
│
├─ YES ──► 【推奨解 D】
│ EC2上での自前レプリケーション (Patroni等)
│ ※運用保守のTCO増大を許容した特殊設計。
│
└─ NO ───► 【推奨解 E】
Amazon RDS (Single-AZ) ＋ 自動スナップショット
＋ コールドスタンバイ / Read Replica
※低予算システム・ステージング向けの最小コスト構成。
7. 現場で迷ったときのFAQ（よくある質問5選とズバリ回答）
Q1. RDS Multi-AZに「Amazon RDS Proxy」を挟めば、Aurora並みのフェイルオーバー速度（30秒以内）になりますか？
A. 一部改善するが、Auroraと同等にはならない。 RDS Proxyを導入することで、クライアント側の接続プーリングが集約され、DNSキャッシュの伝播遅延をバイパスできるため、フェイルオーバー時間は約30%〜50%短縮される（通常1分半かかるところが30〜60秒程度になる）。
しかし、バックエンドのRDSインスタンス自体が未適用のトランザクションログを再生する「クラッシュリカバリ時間」そのものは消滅しない。高負荷時にプライマリが落ちた場合、エンジン側の起動処理で数分待たされるボトルネックは解消できない点に留意が必要である。
Q2. Auroraのリードレプリカを置かず「Writer 1台のみ」のMulti-AZ構成は可能ですか？
A. 技術的には可能だが、フェイルオーバー時間が長期化するため推奨しない。 Auroraはストレージ層が最初から3AZに6重化されているため、インスタンスが1台のみでも「ストレージのMulti-AZ耐障害性」は担保される。
ただし、Writerインスタンスがクラッシュした場合、新しいコンピュートノードのプロビジョニングと起動が完了するまで待つ必要があり、復旧に約5分〜10分を要する。30秒以内の高速フェイルオーバーを実現するには、フェイルオーバー先として常に待機しているReaderインスタンス（最低1台）がクラスタ内に存在することが必須条件である。
Q3. RDS Multi-AZの「スタンバイ機」からデータを読み取ることはできますか？
A. 従来のRDS Multi-AZでは不可能。「RDS Multi-AZ クラスター」構成であれば可能。 長年提供されている標準のRDS Multi-AZ（2ノード構成）のスタンバイ機は完全なパッシブ待機であり、SQLを受け付けることはできない。
参照負荷を分散したい場合は、追加でRead Replicaを建てるか、あるいは2022年に投入された「Amazon RDS Multi-AZ DB クラスター構成（Writer 1台＋読み取り可能なStandby 2台、ローカルNVMe SSD搭載）」を採用する必要がある。ただし、この構成はAuroraとほぼ同等かそれ以上の費用が発生するため、多くの場合Auroraを採用した方がコスト効率と実績の面で優位である。
Q4. Aurora MySQLとAurora PostgreSQLで、冗長化の挙動や停止時間に差はありますか？
A. 基本的なフェイルオーバー機構に差はないが、コネクション切断後の再接続挙動に差異がある。 両者ともストレージのクォーラム同期アーキテクチャは同一であり、クラスタとしての切り替え時間は30秒以内である。
実務上の差はクライアントドライバのエコシステムにある。PostgreSQLはプロセスモデルを採用しているため大量の新規同時再接続（フェイルオーバー直後のストーム）でCPUスパイクを起こしやすい。これを緩和するため、Aurora PostgreSQLではRDS Proxyの併用が強く推奨される。
Q5. メンテナンスウィンドウ（パッチ適用）時の停止時間は冗長化によってゼロにできますか？
A. 完全なゼロ（0秒）にはならないが、Auroraの「ゼロダウンタイムパッチ（ZDP）」により数秒の瞬断に抑えられる。 RDS Multi-AZの場合、パッチはまずスタンバイ機に適用され、フェイルオーバーが発生し、旧プライマリに適用されるため、切り替え時に必ず1〜2分の停止を伴う。
Auroraの場合、OSやDBエンジンのパッチ適用時に「Zero-Downtime Patching (ZDP)」が試みられる。これはクライアント接続を維持したままバックグラウンドでエンジンバイナリを置き換える技術であり、成功すれば停止時間はトランザクションの一時的なブロック（数秒以内）で完了する。ただし、実行中のトランザクション状態によってはZDPがスキップされ、通常のフェイルオーバー処理にフォールバックすることがある。
8. 結論と今すぐできるアクションプラン
データベース冗長化の選定において、感情論や机上の理想論を排した冷徹な結論は以下の3点に集約される。
- 停止1分あたりの売上毀損が5万円を超えるサービスは、迷わずAmazon Auroraを採用せよ。 月額数万円のインフラ差額は、年間で数回発生し得るハードウェア不調やメンテナンス瞬断時の復旧速度（10〜30秒以内）で完全に元が取れる。
- 夜間メンテナンスや数分の瞬断が許容される業務SaaS・社内基幹は、Amazon RDS Multi-AZが最もTCOバランスに優れる。 ブロックレベルの完全同期によりRPO=0を担保しつつ、Auroraより安価かつ予測可能な固定コストでインフラを維持できる。
- EC2自前レプリケーションは、クラウド運用において「最も高くつく貧困策」である。 インフラ利用料のわずかな削減分は、SREのパッチ適用・監視・障害復旧訓練に伴う莫大な人件費によって瞬時に相殺される。
今週着手すべきアクションプラン
- ステップ1: 自社DBのCloudWatchメトリクス監査（即日）
ReplicaLag（レプリカ遅延）の推移、および過去30日間のI/Oリクエスト総量（VolumeReadIOPs/WriteIOPs）を確認し、現在支払っている隠れコストを可視化する。 - ステップ2: アプリケーション側のDNSキャッシュTTL値の総点検（2日以内） DBクライアント、コンテナOS、言語ランタイム（JVM、Node等）のTTLが5秒以下に設定されているかをコード・設定ファイルレベルで確認する。これが長大であれば、いかなるマネージドHA構成も無力化される。
- ステップ3: カオステスト（フェイルオーバー強制試験）の実施（次期スプリント）
ステージング環境において、マネジメントコンソールまたはAWS CLIから
aws rds reboot-db-instance --force-failoverを実行し、クライアント側から見た「真の復旧秒数」をストップウォッチで計測する。理論値と実測値の乖離を把握することが、耐障害性担保の唯一の現実解である。