クラウド全盛の現場において、最も身近なフェイルオーバーの代表例がAmazon Web Servicesの「AWS RDS（Relational Database Service）Multi-AZ構成」です。公式ドキュメントやAWS障害報告資料によれば、プライマリインスタンスに障害が発生した場合、別のアベイラビリティゾーン（AZ）にあるスタンバイインスタンスへ自動フェイルオーバーが行われます。
しかし、IT現場のエンジニアコミュニティやSNS上でのリアルな障害報告を検証すると、カタログスペックと実運用には無視できないギャップが存在します。
「AWS RDSのフェイルオーバーは通常60秒から120秒程度で完了すると案内されているが、アプリケーション側がエラーを吐き続けて復旧に10分以上かかった」というトラブルの告白が後を絶ちません。このタイムラグが生じる最大の原因は、DNS伝播とクライアント側のコネクションプール問題です。
AWS RDSのフェイルオーバーでは、エンドポイント（ドメイン名）が指し示すIPアドレスがスタンバイ側のIPへと書き換わります。しかし、JavaやPHPなどのバックエンドアプリケーション側で「DNSの名前解決結果をキャッシュする設定（TTL）」が長く設定されていると、アプリは障害で死んだ旧サーバーのIPへ接続を試み続けます。結果として、クラウド側のデータベース切り替え自体は1分で完了していても、サービス全体は接続エラーを垂れ流し続ける事態に陥るのです。
インフラの現場検証から導き出される教訓は明快です。「クラウド事業者が提供する自動フェイルオーバー機能を有効化しただけで安心し、アプリ側の再試行ロジック（リトライ処理）やキャッシュ設定を放置すれば、高可用性の恩恵は半分も得られない」というのが、現場が直面するシビアな現実です。
