【脱・手動フェイルオーバー】AWS ARCがAurora/Neptuneの自動スケール＆切り替えを実現！「待機コスト削減」と「爆速RTO」を両立する最強のDR構成へ

Amazon Application Recovery Controller (ARC) Region Switchに、Amazon Aurora (Provisioned/Serverless) および Amazon Neptune Global Database のフェイルオーバーとスケーリングを自動化する3つの新しい「実行ブロック (Execution Blocks)」が追加されました。これにより、マルチリージョン構成において、有事の際にセカンダリリージョンのデータベース容量を自動で本番規模へスケールアップ、またはNeptuneの切り替えを自動実行することが可能になります。

🚨 マルチリージョン運用で「あの数分間」の恐怖をゼロにする

マルチリージョン構成を組んでいるエンジニアなら、「フェイルオーバー後にセカンダリのインスタンスサイズを上げ忘れて、トラフィックに耐えられず二次災害が起きる」、あるいは**「Neptuneの切り替え手順が複雑で、いざという時にスクリプトが走らない」**という、あの胃が痛くなる瞬間を経験したことがあるはずです。

今回のアップデートは、まさにその**「人的ミスによるRTOの遅延」**という痛みを解決する神アップデートです。

🛠️ 何が凄すぎるのか？

1. Auroraの自動リサイズ: 平時は低コストな最小構成（低ACUや小規模インスタンス）で運用し、ARCがRegion Switchを実行する瞬間に、自動で本番同等のスペックへスケールアップしてくれます。これで「コスト削減」と「爆速復旧」が究極のバランスで両立できます。
2. Neptuneの自動切り替え: 計画的なSwitchoverから、緊急時の非計画Failoverまで、単一のプランで自動化。カスタムスクリプトのメンテナンスから解放されます。
3. クロスアカウント対応: 複数のアカウントにまたがるデータベース操作も一つのプランでオーケストレーション可能。大規模なエンタープライズ環境でも強力です。

🇯🇵 日本国内の可用性について

リサーチの結果、東京 (ap-northeast-1) および 大阪 (ap-northeast-3) の両リージョンにおいて、ARC Region Switch、Aurora Global Database、Neptune Global Database すべてが利用可能であることが確認されています。国内のマルチリージョンDR構成を構築する際、迷わず採用できるレベルの技術成熟度です。

💡 実務でのアドバイスと次の一手

• コスト戦略: 「セカンダリは常に本番と同じサイズ」というこれまでの常識を捨てましょう。ARCの実行ブロックを活用して、**「有事の際のみスケールアップ」**というアーキテクチャへシフトすることで、DRコストを劇的に下げられます。
• 権限の管理: rds:ModifyDBInstance や neptune:FailoverGlobalCluster などのIAM権限をARC実行ロールに正しく付与しておかないと、いざという時に動きません。ここが最大の落とし穴です。
• まずはこれを確認: 非本番環境で実際にARCの実行ブロックを含めたRegion Switchプランを作成し、**「自動スケーリングが意図したスペックまで到達するか」**を検証することから始めてください。

【参照したAWS公式ドキュメント】

• Amazon Application Recovery Controller documentation: https://docs.aws.amazon.com/r53recovery/latest/dg/aurora-provisioned-scaling-block.html