- AZレベルの冗長性だけでなく、リージョン単位の分離を設計に組み込む： us-east-1での障害がグローバルに波及しないようワークロードを設計する。Route 53のレイテンシベースルーティングやマルチリージョンでのアクティブ/アクティブ構成を活用する。さらに良いのは、ネットワーク設定を完全に維持したままワークロード全体を別のクラウドにフェイルオーバーできるN2W（ネットワーク間移行）を利用することだ。
- クロスクラウドDNSフェイルオーバーの実装： Route 53障害（実際に発生した事例あり）はフェイルオーバー戦略全体を阻害する。サードパーティDNSプロバイダー（CloudflareやNS1など）を活用し、ヘルスチェック機能でトラフィックを別のクラウド環境やオンプレミス環境へルーティング可能に。
- 代替環境でのコールドワークロード事前準備： 別のクラウド（例：AzureやGCP）に「ウォームスタンバイ」または「コールドスタンバイ」インフラを事前構成し、必要時に自動スケーリングを実行します。
- 重要サービスをAWSネイティブAPIから分離： コアビジネスロジックにおけるAWS API（STS、KMS、IAMなど）へのハード依存を最小化します。これらのAPIはボトルネックとなる可能性があります。N2WSはデータと設定を完全に別のクラウドにバックアップし、依存関係を完全に回避します。
- 全ての統合に冪等性のある再試行ロジックを実装する： AWSサービスが劣化（例：S3のレイテンシ急増）した場合、単純な再試行ループはAPIへの過剰なリクエストで障害を悪化させます。失敗を増幅させないよう、指数関数的バックオフとサーキットブレーカーを備えた再試行メカニズムを設計してください。
Posted in: AWS, クラウド・バックアップ
