某公司正在將兩個簡單的 Node.js 應用程式從地端環境遷移到 AWS。其中一個應用程式收集感測器資料並寫入 MySQL 資料庫；另一個應用程式將資料彙總成報告。當彙總工作執行時，某些載入工作會失敗。遷移必須解決載入失敗問題，並且在不中斷或客戶看不到任何變更的情況下進行。解決方案架構師應提出什麼建議？

正確選項提供了一個零停機時間的遷移策略，並解決了負載失敗問題。AWS DMS 實現了從本地到 Aurora 的持續數據複製，確保數據同步。在 Aurora Replica 上執行彙總工作，將讀取負載從主資料庫分離，避免了彙總期間的寫入中斷。將收集端點託管在 ALB 後方的 Lambda 函數上，並使用 RDS Proxy 寫入 Aurora，提供了高可用性、可擴展性和連接管理。遷移完成後，只需更新 DNS 指向 ALB，即可無縫切換到 AWS 環境，且客戶無感知。 其他選項的不足之處： 選項一：在遷移完成前，將收集端點直接指向 NLB 後方的 Lambda 函數，但資料庫尚未完全同步，可能導致資料不一致或寫入失敗。 選項二：沒有使用 Aurora Replica 來分離讀寫負載，彙總工作仍可能影響寫入操作。 選項四：使用 Kinesis Data Stream 和 Firehose 雖然是數據攝取的好方法，但對於現有應用程式的遷移，直接使用 DMS 複製現有資料庫更為直接和低風險。此外，將收集器 DNS 指向 Kinesis stream 不符合將應用程式遷移到 Aurora 的目標。