RDS Multi-AZ フェイルオーバー原因の確認手順

Multi-AZ 構成の RDS で、深夜や日中の何もしていない時間帯に突然接続断が起き、あとからイベント履歴を見たらフェイルオーバーが記録されていた。運用でよく聞くパターンです。この状況で運用担当者は、たいてい次の3点をその日のうちに答えるよう求められます😇

• 自分たちの操作ミスなのか、AWS 基盤側の問題なのか
• データは失われていないのか
• 同じことが起きないようにできるのか

この記事では、Multi-AZ のフェイルオーバー原因を確認する順番と、それぞれの確認で「何が言えるようになるか」を整理します。あわせて、同期レプリケーションとリカバリの仕組みから「なぜコミット済みデータは残り、未コミットはロールバックされるのか」を押さえ、報告書に書ける形の説明と恒久対策までをまとめます。

RDS / Aurora の運用でつまずきやすいポイントの全体像は RDS・Aurora 運用・トラブル解決ガイド｜仕組み・障害切り分け・性能監視の全体像 にまとめているので、他の症状と並べて確認したい場合はあわせて読んでください。

🔍 結論：まず RDS のイベント履歴を見る。ここで原因の大半は切り分けられる

最初に開くべきは、RDS コンソールの対象 DB インスタンスの「ログとイベント」、またはマネジメントイベントとしての RDS イベント履歴です。CLI なら次のように取得します。

aws rds describe-events \
  --source-identifier <インスタンス名> \
  --source-type db-instance \
  --duration 1440 \
  --region <リージョン>

--duration は「何分前までのイベントを取るか」です。障害の発生時刻が前日なら 1440（24時間）、もっと前なら --start-time / --end-time で範囲指定します。RDS のイベントは保持期間に限りがあるため、調査を始めた時点でまず JSON として手元に落としておくのが安全です。CloudWatch Logs に転送していないエンジンログも同様で、ローテーションで消える前に取得します。

このイベント一覧で見るのは、次の2点です。

1. フェイルオーバー関連のイベントが出ているか（カテゴリは failover）
2. その前後に、利用者の操作やメンテナンスに起因するイベントが「ない」こと

💡 2つ目が意外と重要です。「基盤起因である」という主張は、「こちら側の操作起因ではない」ことを示せてはじめて説明として成立します。

「The primary host of the RDS Multi-AZ instance is unhealthy.」が意味すること

Multi-AZ の自動フェイルオーバーが起きたとき、イベントにこのメッセージが記録されることがあります。

The primary host of the RDS Multi-AZ instance is unhealthy.

意味はそのままで、「プライマリ DB インスタンスを動かしていた基盤ホストが健全でないと判定された」ということです。RDS の内部監視機構はプライマリの生存を継続的に確認しており、ホストが応答しない状態になったことを検知すると、Multi-AZ のフェイルオーバーメカニズムによってスタンバイレプリカへの切り替えを自動実行します。

つまりこのメッセージが指しているのは、DB エンジン内部のエラー（SQL の失敗、デッドロック、ディスクフル等）ではなく、DB インスタンスが載っていた実行基盤側の問題です。ハードウェアに起因してホストが応答しなくなったケースがこれに該当します。エンジンのログを何時間眺めても「原因」が書かれていないのは、原因がエンジンの外側にあるためです😅

この時点で言えること・まだ言えないこと

イベントを見た時点で言えることは次のとおりです。

• 自動フェイルオーバーが発生した（手動操作でもメンテナンスでもない可能性が高い）
• 原因はプライマリの基盤ホストの健全性低下である
• Multi-AZ 構成だったため、スタンバイへ切り替わって復旧した

一方、まだ言えないこと・分からないこともはっきりさせておきます。

• ホストのハードウェアがどうなっていたか。RDS のイベントで確認できるのはフェイルオーバーの理由までで、基盤のハードウェアに関する詳細な情報は開示されません。「どの部品がどう壊れたのか」は追えない前提で報告を組み立てます
• API 呼び出しがなかったことの確証。イベントに操作起因の記録がないのは強い材料ですが、次節の CloudTrail で裏を取ります
• アプリ側に何秒間のエラーが出たか。これは自分たちのアプリケーションログや ALB のログ、CloudWatch メトリクスから測るしかありません

⚠️ Health Dashboard に該当イベントが出ていないこともあります。単一インスタンスの基盤ホスト異常はリージョン全体に影響する事象ではないため、パーソナルヘルスとして通知されるかどうかはケースによります。「Health Dashboard に何も出ていないから障害ではない」とは判断できません。

⚙️ なぜ勝手に切り替わるのか：Multi-AZ フェイルオーバーの仕組み

「自動で切り替わる」という挙動を仕様として知っていても、内部で何が起きているかを押さえておかないと、データ整合性の質問に答えられません。

同期レプリケーションとコミット済みデータの扱い

Multi-AZ（1インスタンス＋同期スタンバイの構成）では、プライマリへの更新が別 AZ のスタンバイへ同期的に複製されます。同期という言葉の中身は、更新の記録（Oracle なら REDO、PostgreSQL や MySQL なら WAL / binlog に相当するもの）がスタンバイ側で永続化されたことを確認してから、プライマリがクライアントへコミット完了を返す、というプロトコルです。

ここから2つの帰結が出ます。

ひとつは、コミット済みのデータがフェイルオーバーで失われないこと。クライアントが「コミット成功」を受け取れているなら、その時点でスタンバイ側にも更新記録が届いて永続化されています。だからスタンバイを昇格させても、その更新は残ります。

💡 もうひとつは、コミットが完了していなかった変更がロールバックされること。昇格したスタンバイは、クラッシュリカバリと同じ経路をたどります。永続化された更新記録を適用して最新状態まで進め、その時点で未コミットだったトランザクションを取り消します。Oracle であれば UNDO セグメントの情報を使って巻き戻し、PostgreSQL であればコミットログ（pg_xact）にコミットが記録されていないトランザクションの変更が、MVCC の可視性判定によって「誰にも見えない行」として扱われます。PostgreSQL 系では、この巻き戻された行が物理的にはデッドタプルとして残り、後続の VACUUM で回収されます。フェイルオーバー直後に長大なトランザクションが巻き戻された場合、しばらくして VACUUM の I/O が増えることがあるので、頭に入れておくと慌てずに済みます。

性能面の帰結もあります。昇格したインスタンスのバッファキャッシュ（PostgreSQL の shared_buffers、Oracle のバッファキャッシュ）と共有メモリ上のキャッシュは、切り替え直後はほぼ空です。Oracle なら共有プールの実行計画キャッシュも空になります。したがってフェイルオーバー後しばらくは物理 I/O が増え、同じクエリでもレスポンスが悪化します。「切り替わった直後だけ遅い」という報告は多くの場合これで説明でき、時間とともに解消します。逆に何時間経っても戻らないなら、キャッシュではなく統計情報やパラメータなど別の要因を疑います。

DNS の付け替えで起きる「既存接続が切れる」現象

フェイルオーバーでは、DB インスタンスのエンドポイント名に紐づく DNS レコードが、旧プライマリから昇格したスタンバイ側のアドレスへ自動的に書き換えられます。エンドポイント名（<インスタンス名>.xxxxxxxx.<リージョン>.rds.amazonaws.com）は変わらないため、接続文字列の修正は不要です。

ただし既存の接続はそのままでは使えません。TCP 接続は名前解決の結果として得た IP に対して張られているので、切り替え前に確立していたコネクションは切断されるか、無効な相手に向いたまま残ります。アプリケーションからは次のような形で観測されます。

• 「接続がリセットされた」「サーバーが予期せず接続を閉じた」系のドライバ例外
• コネクションプールが保持していた接続を使った瞬間のエラー
• ALB 配下の Web アプリなら、上位レイヤでは 5xx として現れる（ALB のエラーとして見えたときの切り分けは ALB で 502 Bad Gateway が出たときの原因と切り分け手順【AWS】 を参照）

だからこそ、後述する「接続のリトライ」と「DNS キャッシュ TTL」が恒久対策の中心になります。アプリ側が接続を作り直せる設計になっていれば、ユーザー影響は切り替え時間の範囲にとどまります✨

リードレプリカや単一 AZ 構成との違い

混同されやすいので整理します。

• 単一 AZ 構成では、基盤ホストに問題が起きると、RDS が別ホストで同じストレージを使って復旧させるまで DB は使えません。自動で待機系に切り替わる仕組みがそもそもありません
• リードレプリカのレプリケーションは非同期なので、昇格させると未反映分の更新が失われる可能性があります。また昇格は自動ではなく、こちらから実行する操作です。可用性のための仕組みではなく、読み取りのスケールアウトやリージョン間コピーのための仕組みと考えます
• Multi-AZ の同期スタンバイには、読み取りクエリを投げられません。「スタンバイが遊んでいるのでは」という指摘を受けることがありますが、用途が可用性であることを説明しておきます
• ⚠️ Multi-AZ DB クラスターは、2つの読み取り可能なスタンバイを持つ別方式の構成で、レプリケーションや切り替えの特性も異なります。自分の環境がどちらの Multi-AZ なのかは、コンソールの構成表示で必ず確認してください

🧩 原因を切り分ける5つの確認手順

ここからは、報告に使える形で原因を確定させる手順です。順番に意味があります。

1. RDS イベントで基盤起因かどうかを判定する

前述の describe-events で、発生時刻付近のイベントを時系列に並べます。見るポイントは以下です。

• failover カテゴリのイベントがあるか（「Multi-AZ instance failover started / completed」など）
• 「The primary host of the RDS Multi-AZ instance is unhealthy.」のように、基盤ホストの健全性に言及したメッセージがあるか
• 同時刻に、パラメータ変更・インスタンスクラス変更・ストレージ変更・手動再起動などのイベントがないか

✅ 基盤ホストの健全性低下を示すイベントがあり、かつ利用者操作やメンテナンス由来のイベントがなければ、この時点で「基盤起因の自動フェイルオーバー」という筋が立ちます。

2. CloudTrail で再起動・フェイルオーバー API が呼ばれていないか確認する

「本当に誰も触っていないのか」を示すのが CloudTrail です。特に見るべきイベント名は RebootDBInstance（ForceFailover が true なら意図的なフェイルオーバー）、ModifyDBInstance、FailoverDBCluster（Aurora の場合）です。

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=RebootDBInstance \
  --start-time <開始時刻> \
  --end-time <終了時刻> \
  --region <リージョン>

該当するイベントが0件であれば、「再起動やフェイルオーバーを行う API コールは記録されていない＝利用者操作が原因ではない」と言えます。逆に誰かが実行していた場合は userIdentity から実行者が分かるので、そこで調査は終わりです。運用担当が触っていなくても、CI/CD や IaC のパイプライン、あるいは自動起動停止のスクリプトが叩いていることもあるので、人間の記憶ではなく CloudTrail で確認してください。

⚠️ なお CloudTrail のコンソール検索で遡れる期間には限りがあります。それより古い事象を追う場合は、S3 に出力しているログを Athena で検索する形になります。

3. 発生時刻がメンテナンスウィンドウ内かどうかを確認する

計画メンテナンスによる切り替えを除外します。

aws rds describe-db-instances \
  --db-instance-identifier <インスタンス名> \
  --query 'DBInstances[].{MaintWindow:PreferredMaintenanceWindow,AutoMinor:AutoMinorVersionUpgrade}'

PreferredMaintenanceWindow は UTC 表記なので、JST に直してから発生時刻と比較します。ここを間違えて「ウィンドウ外だ」と結論づけるミスが起こりがちです。あわせて保留中の作業も確認します😇

aws rds describe-pending-maintenance-actions \
  --region <リージョン>

「操作していないのに RDS が再起動された」ケースには、サーバー証明書の自動ローテーションのような、メンテナンス起因のものもあります。イベントとメンテナンスウィンドウの読み方は RDS 証明書ローテーションで再起動される原因と対処 でも扱っているので、今回のフェイルオーバーと切り分けたいときに参照してください。

4. OOM やエンジン側のプロセス再起動が記録されていないか確認する

次に、「アプリ側の過負荷でメモリを食い潰した結果ではないか」を除外します。確認するのは以下です。

• RDS イベントに、メモリ不足によるプロセス再起動を示すイベントが記録されていないか
• CloudWatch の FreeableMemory が発生時刻に向かって枯渇していないか、SwapUsage が増えていないか
• エンジンログに、バックエンドプロセスが強制終了されて自動リカバリに入った痕跡がないか

ここで押さえておきたいのは、OOM によるプロセス再起動と Multi-AZ フェイルオーバーが別の事象だということです。メモリ不足でエンジンのプロセスが落ちた場合、多くはそのインスタンス上で自動リカバリが走り、接続断は起きるがフェイルオーバーのイベントは出ません。「短時間の接続断」という症状が同じでも、イベント上の記録がまったく違います。OOM の記録がなく、代わりにフェイルオーバーのイベントが出ているなら、アプリケーション側の負荷が原因という線は薄くなります。

5. 切り替えに要した時間が想定範囲に収まっているか確認する

最後に、切り替えそのものが異常に長引いていないかを見ます。材料は3つです。

• RDS イベントの「failover started」と「failover completed」相当のタイムスタンプ差
• CloudWatch の DatabaseConnections が0に落ちてから戻るまでの時間
• アプリケーションログでエラーが出続けた時間

公式ドキュメントには通常のフェイルオーバー所要時間の目安が示されているので、観測値がその範囲に収まっているかを確認します。範囲内であれば「想定どおりに切り替わった」と報告できます。目安を大きく超えていた場合は、次のような要因を疑います。

• 巻き戻すべき未コミットトランザクションが大量にあり、リカバリに時間がかかった（長時間走る一括更新バッチが動いていた時間帯と重なっていないか）
• アプリケーション側の DNS キャッシュが古いアドレスを保持し続け、接続先が切り替わらなかった
• コネクションプールが死んだ接続を破棄せず使い回し、エラーが長引いた

💡 「切り替え自体は速く終わっているのに、アプリのエラーが長く続いた」のであれば、それは AWS 側ではなくアプリ側の設定の問題です。この区別ができると、対策の打ち先を間違えません。

🛡️ 「フェイルオーバーでロールバック＝データ不整合」は誤解

報告の場で必ず出るのが「データは壊れていないのか」という質問です。ここを誤解したまま説明すると、不要な全件チェックや復旧作業に人員を割くことになります。

ロールバックはデータベースを一貫性のある状態に保つ正常動作

前述のとおり、Multi-AZ ではスタンバイへの複製が同期的に行われるため、コミット済みのデータがフェイルオーバーによって失われることはありません。一方、コミットが完了していなかった変更はロールバックされます。

このロールバックは、障害の副作用ではなくトランザクションの原子性（All or Nothing）を守るための正常動作です。昇格側で行われているのは、永続化済みの更新記録を適用して「コミットされたものを確実に反映する」処理と、コミット記録のないトランザクションの変更を「なかったことにする」処理の組み合わせであり、単一インスタンスがクラッシュから復帰するときとまったく同じリカバリ経路です。データベース内部のブロックやインデックスが中途半端な状態で残る、といったことは起きません。

アプリケーションから見れば、実行中だったトランザクションはエラーになります。エラーになったのだから反映されていない、というだけの話です。

それでも注意が必要なのは「複数トランザクションに分割した業務処理」

データベース単位での整合性が守られていても、業務単位での中途半端さは生じ得ます。よくある構成では、1つの業務処理を複数のトランザクションに分けて実行します。

たとえば「ヘッダを登録してコミット → 明細を登録してコミット → ステータスを確定してコミット」という作りになっているバッチで、2つ目のコミット前に切断された場合、ヘッダだけが残った状態になります。データベースとしては整合が取れていますが、業務データとしては未完成です。

したがって確認すべきは、テーブルの物理的な破損ではなく次の点です。

• 発生時刻に実行中だったバッチ・ジョブの一覧と、その進捗をどこで記録しているか
• 中断された業務処理を検出するクエリ（明細のないヘッダ、ステータスが中間値のまま残っているレコードなど）を持っているか
• 再実行が冪等か。二重登録を防ぐ一意制約や処理済みフラグがあるか

この観点を持っておくと、フェイルオーバーのたびに「とりあえず全件照合」をする運用から抜け出せます✨

AWS から開示される情報の範囲を理解しておく

イベントとして確認できるのはフェイルオーバーの理由までで、基盤のハードウェアに関する詳細な情報は開示されません。これは仕様として受け入れて、報告書は事実ベースで書きます。

• 起きたこと：プライマリの基盤ホストが健全でないと判定され、Multi-AZ の仕組みにより自動フェイルオーバーが実行された
• 影響：切り替えに伴い既存接続が切断され、○○時○○分から○分間、△△機能でエラーが発生した（時間は自分のログから記載）
• データ：同期レプリケーションのため、コミット済みデータの喪失はない。未コミット分はロールバックされ、これは正常動作
• 利用者操作の有無：CloudTrail に再起動・フェイルオーバーの API 呼び出しは記録されていない
• 計画メンテナンスの有無：発生時刻はメンテナンスウィンドウ外

「ハードウェアの具体的な故障箇所」は書けません。それを求められた場合は、開示範囲の話として説明します。

🔧 アプリケーション側でやっておく対処と再発時のダメージ低減

フェイルオーバー後の DB インスタンスに問題がなければ、そのまま利用を継続できます。即時対応としてはそれで十分で、力を入れるべきは「次に起きたときの影響を小さくする」側です。Multi-AZ は基盤側の問題が発生した際の影響を抑えるための仕組みであり、基盤側の問題そのものの発生を防ぐことはできない、というのが出発点になります。

接続リトライとコネクションプールの再接続設定

最優先はこれです。実装・設定の観点は次のとおりです。

• コネクションプールが接続を貸し出す前に生存を確認する設定（検証クエリや接続テスト）を有効にする。無効のままだと、死んだ接続をアプリに渡してエラーになります
• プール内の接続に最大生存時間を設け、古い接続が滞留しないようにする
• 接続エラーは即座に失敗させず、指数バックオフで数回リトライする。無限リトライは DB 復帰時にコネクション要求が殺到するので、回数上限を必ず置く
• 参照系は素直にリトライできますが、更新系は「コミットされたか不明」な状態が起こり得ます。一意キーや処理済み判定で二重実行を防げる設計になっているかを確認してから、書き込みリトライを入れます
• 接続タイムアウトとクエリタイムアウトを明示的に設定し、切り替え中のスレッド枯渇を防ぐ

JVM の DNS キャッシュ TTL を見直す

フェイルオーバーはエンドポイント名に対する DNS レコードの付け替えで実現されるため、アプリ側が古い解決結果をキャッシュし続けると、切り替えが終わっているのに接続できない状態が続きます。RDS のエンドポイントの DNS TTL は短く設定されていますが、それを尊重するかどうかはクライアント側の実装次第です。

⚠️ 特に JVM 環境は注意が必要です。JVM は名前解決の結果を自前でキャッシュし、その保持時間は networkaddress.cache.ttl（成功時）と networkaddress.cache.negative.ttl（失敗時）で制御されます。既定値は JVM のバージョンやセキュリティマネージャーの有無によって異なり、環境によっては「起動中ずっとキャッシュし続ける」設定になり得ます。対応は以下のいずれかです。

• $JAVA_HOME/conf/security/java.security（または jre/lib/security/java.security）で上記プロパティを短い値に設定する
• 起動オプションでシステムプロパティとして指定する
• アプリケーション初期化時に java.security.Security.setProperty で設定する

💡 Java 以外でも、コンテナ内の DNS キャッシュ、OS レベルのキャッシュ（nscd / systemd-resolved）、接続プールが IP を保持し続ける実装などが同じ問題を起こします。フェイルオーバーテストのときに「何秒で再接続できたか」を実測するのが確実です。

イベントサブスクリプションで failover 通知を受け取る

「翌朝に気づいた」を避けるため、RDS イベントサブスクリプションを設定して SNS 経由で通知を受け取ります。

aws rds create-event-subscription \
  --subscription-name <サブスクリプション名> \
  --sns-topic-arn <SNSトピックARN> \
  --source-type db-instance \
  --source-ids <インスタンス名> \
  --event-categories failover availability maintenance \
  --region <リージョン>

failover カテゴリを含めておけば、切り替えの開始・完了が通知されます。availability や maintenance も併せて購読しておくと、再起動やメンテナンス起因の事象も取りこぼしません。CloudWatch 側では DatabaseConnections の急減や FreeableMemory にもアラームを置き、フェイルオーバー前後の接続状況を後から追えるようにしておきます。

手動フェイルオーバーで事前に挙動を確認する

対策を入れたら、実際に切り替えてテストします。Multi-AZ の DB インスタンスは、フェイルオーバーを伴う再起動によって手動でフェイルオーバーを強制実行できます。

aws rds reboot-db-instance \
  --db-instance-identifier <インスタンス名> \
  --force-failover \
  --region <リージョン>

本番でいきなり実行するのではなく、まず検証・ステージング環境で実施し、以下を測ります。

• アプリケーションがエラーを返した時間と、自動的に回復したかどうか
• リトライログが想定どおり出ているか、リトライ回数が上限内で収まったか
• バッチ実行中に切り替えた場合、中断されたジョブを検出・再実行できるか
• 切り替え後にレスポンスが悪化し、どのくらいで戻るか（キャッシュのウォームアップ）

この結果があれば、次に本番で同じことが起きたときに「想定どおりの挙動でした」と言えます。テストせずに対策を入れただけだと、本番で初めて不備が分かることになります🎉

❓ よくある質問

フェイルオーバーでコミット済みのデータは失われる？

Multi-AZ 構成ではスタンバイへの複製が同期的に行われるため、コミット済みのデータがフェイルオーバーによって失われることはありません。クライアントがコミット成功を受け取った時点で、更新記録はスタンバイ側にも永続化されています。一方、コミットが完了していなかった変更はロールバックされますが、これはデータベースを一貫性のある状態にするための正常な動作です。なお、非同期のリードレプリカを昇格させる場合は話が別で、こちらは遅延分の更新が失われる可能性があります。

フェイルオーバーにかかる時間はどのくらい？

公式ドキュメントに通常の所要時間の目安が示されているので、そこと観測値を比較してください。目安より長くかかったように見える場合、DB 側の切り替えではなくクライアント側の DNS キャッシュやコネクションプールが原因で「アプリのエラーが長引いた」だけ、というケースが少なくありません。イベントのタイムスタンプ差（DB 側の切り替え時間）と、アプリのエラー継続時間を分けて測るのが切り分けの要点です。

基盤ホスト障害によるフェイルオーバーは事前に防げる？

Multi-AZ 構成は、基盤側の問題が発生した際の影響を抑えるための仕組みであり、基盤側の問題そのものの発生を防ぐことは困難です。したがって目標は「起きない状態」ではなく「起きても短時間で自動復旧し、ユーザー影響とデータの中途半端さを最小化する状態」に置きます。具体的には、接続リトライ、DNS キャッシュ TTL、ジョブの再実行設計、通知設定、そして定期的なフェイルオーバーテストの5点です。

フェイルオーバーが起きた正確な理由を AWS に問い合わせできる？

サポート契約があれば問い合わせは可能ですが、RDS のイベントで確認できるのはフェイルオーバーの理由までで、基盤のハードウェアに関する詳細な情報は開示されません。「基盤ホストが健全でないと判定されたため自動フェイルオーバーが実行された」という粒度が、得られる情報の実質的な上限だと考えて報告を組み立てるのが現実的です。問い合わせる価値があるのは、むしろ「切り替え時間が目安を大きく超えていた」「短期間に同じインスタンスで繰り返し発生している」といった、想定と異なる挙動が見えているケースです。

📝 まとめ：切り分けの型を持っておくと報告が早くなる

Multi-AZ のフェイルオーバー原因の確認は、次の順番で固定できます。

1. RDS イベントで failover カテゴリと「primary host is unhealthy」等のメッセージを確認する。同時に、操作起因・メンテナンス起因のイベントが「ない」ことも見る
2. CloudTrail で RebootDBInstance などの API 呼び出しが記録されていないことを確認し、利用者操作を除外する
3. 発生時刻がメンテナンスウィンドウ外であることを、UTC / JST を揃えて確認する
4. メモリ枯渇によるプロセス再起動の記録がないことを確認し、アプリ負荷起因を除外する
5. 切り替え時間を公式の目安と比較し、長引いていた場合はクライアント側の DNS キャッシュやプール設定を疑う

説明の軸は「同期レプリケーションなのでコミット済みは失われない。未コミットのロールバックは一貫性を保つための正常動作。ただし業務処理を複数トランザクションに分けている箇所は、中断された業務単位の洗い出しが必要」の3点です。

対策側は、接続リトライ、DNS キャッシュ TTL、failover カテゴリのイベントサブスクリプション、そしてフェイルオーバーを伴う再起動による事前テスト。この4つを一度整えておけば、次に同じイベントが出たときの作業は「通知を受ける → イベントと CloudTrail を確認 → 中断ジョブを再実行 → 報告」で完結します。

RDS の仕様やイベントメッセージの文言、フェイルオーバー所要時間の目安、イベントの保持期間などは変更されることがあります。実際の調査や報告の前に、必ず AWS の公式ドキュメントで最新の仕様を確認してください。