AWS は締め切りプレッシャー下の戦略的ワークロードに対して2フェーズの移行を明示的に推奨している：まず即時の締め切りに対応するために Rehost（MGN を使用、コード変更なし、高速）し、次にデータセンターが退出された後、エンジニアリングの帯域幅が解放された後のウェーブで選択されたワークロードを Refactor する。この「Rehost-then-Refactor」シーケンスはスピードと長期的なクラウドネイティブ恩恵のバランスを取るものであり、AWS の移行ガイダンスで繰り返し言及されるパターンである。

やさしい解説:

まず引っ越してから改造する。90日以内に必ず出なければならない → Rehost でそのままリフトアンドシフト；後でリソースができたら Refactor してクラウドネイティブ化する。これが AWS が推奨する「2フェーズ移行」モデルだ — スピードとクラウドネイティブの恩恵は二択ではない。

選択肢の分析:419

A：不正解 — Retain は90日間の退出義務に矛盾する。アプリケーションは移行しなければならない。
B：不正解 — 90日間のデータセンター退出と凍結されたエンジニアリング予算の組み合わせでは、初日から Refactor することは不可能であり、書き直しには数か月かかる。
C：不正解 — 主力アプリケーションは顧客向けでビジネスクリティカルであり、廃止できない。完全に使用可能な状態を維持しなければならない。
D：正解 — 2フェーズの Rehost-then-Refactor は、データセンターの締め切りが初期のリフトアンドシフトを強いるが、クラウドネイティブ恩恵を最大化するという長期的な戦略的目標が存在する場合の AWS の推奨アプローチである。