遷移工具：資料傳輸、應用程式遷移與資料庫遷移

AWS 遷移工具是 Professional 等級的核心學科，要求你能夠挑選、串接並排序正確的服務——AWS Application Migration Service (MGN)、AWS Database Migration Service (DMS)、AWS Schema Conversion Tool (SCT)、DMS Fleet Advisor、AWS Snow Family 艦隊模式、AWS DataSync、AWS Transfer Family、AWS Direct Connect，以及應用層串流複製器（如 Kafka MirrorMaker 和 Amazon MSK Replicator）——讓一個 600 TB 的地端環境遷入 AWS 時，擁有最短的切換窗口、最低的資料遺失風險，以及任何單一元件故障時最小的爆炸半徑。SAP-C02 Domain 4（加速工作負載遷移與現代化，佔 20%）對這個主題的考試比多數考生預期的更重，且考法與 SAA-C03 截然不同：考題預設你已知道「DataSync 是什麼」，問的是你能否在 Direct Connect 管線後面編排 DMS Full Load + CDC，同時平行派出 Snowball Edge 艦隊，用 DMS 驗證任務與 checksum 確認資料正確性，再在 60 分鐘內完成 DNS 切換且不破壞複製延遲 SLO。本筆記以工具鏈而非服務概覽的深度切入 SAP-C02 遷移工具，並以標誌性考題情境作結：600 TB 地端 Oracle 19c → Amazon Aurora PostgreSQL，應用程式停機不超過一小時。

本文假設你已通過 SAA-C03 或同等程度，不需要「DataSync 入門介紹」。如需 Associate 等級的 AWS 資料傳輸決策樹（線上傳輸天數計算、單一服務選擇），請參閱 SAA-C03 data-transfer-solutions 筆記。本文聚焦在 SAP-C02 深度：工具鏈編排、切換工程、複製拓樸，以及企業 AWS 遷移計畫的驗證策略。

Professional 等級框架——遷移工具是系統，不是服務

SAA-C03 問「哪一個 AWS 資料傳輸服務適合這個工作負載？」SAP-C02 問「哪種 AWS 遷移工具服務組合、按什麼順序、走哪條網路、設哪個驗證關卡，才能讓你真正在週六深夜、財務長盯著螢幕的情況下完成切換？」心智模型從「服務選擇器」轉變為「系統設計師」。

Professional 等級的 AWS 遷移工具設計有六個組成部分，在你動手操作主控台之前，全部都要有答案：

• 探索工具 — AWS Migration Hub、Application Discovery Service（無代理程式與代理程式模式）、DMS Fleet Advisor（資料庫）、AWS Migration Evaluator（TCO）。
• 伺服器層複製工具 — AWS Application Migration Service (MGN)，用於區塊層虛擬機複製；歷史上曾有 AWS Server Migration Service (SMS) 和 CloudEndure，現已全數被 MGN 取代。
• 資料庫層複製工具 — AWS Database Migration Service (DMS)，支援 Full Load、CDC 以及 Full Load + CDC 任務模式；AWS Schema Conversion Tool (SCT) 用於異質引擎轉換。
• 檔案與物件層資料傳輸工具 — AWS DataSync（NFS/SMB/HDFS → S3/EFS/FSx）；AWS Transfer Family（合作夥伴 SFTP/FTPS/AS2 接收）；AWS Snow Family（大規模離線批量傳輸）。
• 串流層複製工具 — Kafka MirrorMaker 2 和 Amazon MSK Replicator（事件匯流排同位），以及 Kinesis Data Streams 跨區複製（適用情況下）。
• 網路傳輸 — AWS Direct Connect（專用、私有、可預期頻寬）vs 網際網路加 VPN vs 離線實體運送；這些是所有 AWS 遷移工具選擇背後的「管線」。

白話文解釋 AWS Migration Tooling

讓我用三個類比說明 AWS 遷移工具，因為這條工具鏈在第一次接觸時確實讓人費解。

類比一：海運公司搬家

想像你要把一棟六房大宅的家當搬到另一個城市，而且時程嚴格。你不會在搬家前一晚自己把每件東西塞進紙箱——那是業餘的做法，也是遷移計畫超出切換窗口的根本原因。專業的搬家公司會先派勘查員上門（探索：Application Discovery Service、DMS Fleet Advisor、Migration Evaluator），產出清單與報價（資產評估、7 Rs），再派出專業小隊：鋼琴師傅（MGN 負責關鍵伺服器）、珍貴書籍小隊（DMS 負責資料庫，因為書要按序整齊擺放）、海運倉儲組（Snowball Edge 負責搬運卡車裝不下的大批貨物），以及在目的地逐件對清單驗收的品管員（DMS 驗證任務、DataSync 驗證、Snow 保管鏈）。

搬運卡車就是你的網路——AWS Direct Connect 是租來的 45 噸貨車，公共網際網路是租來的小發財車（慢且不穩定），Snowball Edge 是你在門口裝滿後交給物流公司的密封貨櫃。你不會把鋼琴綁上腳踏車。你也不會把 50 TB 的 Oracle 資料庫透過 100 Mbps VPN 搬走。選對工具搬對貨物。

類比二：機場塔台（切換日）

切換日是空中交通管制，不是賽跑。一次順利執行的 AWS 遷移工具切換就像機場塔台管理二十架飛機：有起降順序（伺服器透過 MGN 先完成，資料庫透過 DMS 讓 CDC 延遲歸零，最後才切 DNS）、有等待航線（應用程式在最後 CDC 清空期間保持唯讀模式）、有重新進場程序（預先撰寫的復原手冊，可從 AWS 反向複製回地端）、也有無線電紀律（一個變更窗口、一個事故頻道、每層一位決策者）。

遷移工具只有在你端對端使用這些服務時才能免費給你這套編排能力。MGN 的測試切換是彩排——從持續複製串流啟動暫存 EC2 執行個體、執行煙霧測試、拆除執行個體、繼續複製。DMS 的 CDC 模式是等待航線——切換窗口內來源資料庫接受的每一筆交易，都會被重播到目標資料庫，直到你關閉來源端的寫入。

類比三：餐廳廚房備料（切換前置作業）

在專業廚房，備料（mise en place）意味著所有食材已切好、每個工作站已補齊、每道醬汁已保溫——在開始出菜前。AWS 遷移工具就是切換的備料：

• MGN 是冷藏走入式倉庫 — 它存放每台伺服器不斷更新的備份，隨時可以在幾分鐘內出菜。
• DMS Full Load + CDC 是文火慢燉的高湯 — 目標資料庫已暖身、資料持續流入，主廚在上桌前只需嚐一口確認。
• SCT 是已把 Oracle 預存程序切絲翻譯成 PostgreSQL PL/pgSQL 的備料廚師 — 訂單一來，直接開火烹飪，不用現場翻譯。
• DataSync、Transfer Family、Snow Family 是送食材的物流車道 — 把食材送進廚房；它們不負責烹飪。
• Direct Connect 是餐廳的專用服務通道 — 沒有顧客誤闖，沒有送貨卡車堵住，頻寬可預期，延遲緊實。

白話結論：Professional 等級的 AWS 遷移工具是一支廚房旅（brigade），不是本週服務推薦。像廚房一樣設計它——每種食材提前備妥、每個動作提前排練，出菜（切換）就會是這週最輕鬆的一小時，而不是最讓人膽戰心驚的一小時。

探索——AWS Migration Hub、Application Discovery Service、DMS Fleet Advisor

每一個 AWS 遷移工具專案都從「我們有什麼」開始——在 600 台虛擬機的規模下，憑感覺估算是職業生涯的高風險賭注。

AWS Application Discovery Service

AWS Application Discovery Service 擷取地端伺服器、程序與相依性資料，並推送到 AWS Migration Hub。兩種模式：

• 無代理程式探索 — 透過 Application Discovery Service Agentless Collector OVA，掛接到 VMware vCenter 並讀取清單與效能資料（CPU、RAM、磁碟 I/O、網路），完全不需要觸碰 guest OS。適用於大量 vSphere 環境、無法廣泛安裝代理程式的情況。
• 代理程式式探索 — 在每台伺服器上安裝 Application Discovery Service Agent，擷取更細粒度的資料，包含執行中的程序和 TCP 連線——相依性地圖的原始素材。

資料落地在 Migration Hub，將伺服器分組成應用程式，透過 7 Rs 標籤追蹤遷移狀態，並呈現各遷移波次的準備度儀表板。

DMS Fleet Advisor——無代理程式的資料庫探索

資料庫的 AWS 遷移工具從 DMS Fleet Advisor 開始。它在一台可以網路連到你資料庫伺服器的 Windows 或 Linux 主機上執行輕量資料收集器，使用唯讀憑證連線，並清查：資料庫引擎與版本、Schema 大小、物件數量、功能使用情況（Oracle 分區、SQL Server Always On 等）以及 I/O 特性。它輸出一份引擎相容性報告——「你的 14 個 Oracle Schema 透過 SCT 自動轉換為 Aurora PostgreSQL 的比例為 82%，有 340 個人工處理項目集中在 trigger 和預存程序中。」

DMS Fleet Advisor 專為大規模異質遷移規劃設計。在 DMS Fleet Advisor 出現之前，Pro 架構師要對每個資料庫逐一手動執行 SCT assessment reports，在 500 個資料庫的環境中完全無法擴展。

AWS Migration Evaluator

AWS Migration Evaluator（前身為 TSO Logic）產出商業案例 — 比較地端運作成本與 AWS 目標架構運作成本的 3 年 TCO。它使用 Application Discovery Service 清單加上效能資料，並套用 Savings Plans 和 Reserved Instance 假設產生定價報告。Migration Evaluator 的輸出就是你在 Migration Acceleration Program (MAP) 資金對話前放在財務長面前的那份文件。

AWS Application Migration Service (MGN)——伺服器層主力工具

AWS Application Migration Service (MGN) 是目前 AWS 建議的伺服器遷移工具。它取代了 AWS Server Migration Service (SMS)（2022 年 3 月退役）和 CloudEndure Migration（已合併入 MGN）。若 SAP-C02 題目在 2026 年還提供 SMS 或 CloudEndure 作為選項，那是誤導選項——正確答案是 MGN。

MGN 複製模型

MGN 從來源伺服器（實體、虛擬機或其他雲端 VM）向 AWS VPC 內的暫存區子網路執行持續區塊層複製。流程如下：

1. 安裝代理程式 — 在每台來源伺服器（Windows 或 Linux）上安裝 AWS Replication Agent。代理程式讀取每顆磁碟上的每個區塊，並透過 TLS 的 1500 埠串流到 AWS。
2. 暫存區 — 一個低成本子網路，MGN 在此佈建複製伺服器（預設為 t3.small EC2 執行個體）和接收複製區塊的暫存 EBS 磁碟區。這些刻意壓低成本；你在複製期間付費，而非以目標執行個體規格計費。
3. 持續同步 — 完成初始完整同步後，代理程式只串流變更的區塊。複製延遲通常在秒級。
4. 測試切換 — 從暫存磁碟區非破壞性地啟動目標 EC2 執行個體。來源持續複製。執行煙霧測試後，拆除測試執行個體且不遺失資料。在正式切換前多次執行。
5. 正式切換 — 在來源端停止應用程式，MGN 完成最後的 CDC 清空，正式啟動目標執行個體，最終卸載來源代理程式。

MGN 啟動範本與切換後動作

MGN 允許你為每台來源伺服器預先定義啟動範本：目標執行個體類型、子網路、安全群組、IAM 執行個體設定檔、EBS 磁碟區類型（從 gp2 升級為 gp3，需要 IOPS 時使用 io2），以及切換後動作。切換後動作是切換完成後執行的 SSM Automation 文件——常見範例：卸載 MGN 代理程式、安裝 CloudWatch 代理程式、向 Systems Manager 註冊、加入網域、套用標籤型設定。

MGN 複製設定

• 代理程式頻寬節流 — 避免在上班時間佔滿廣域網路。
• 透過 VPC endpoint 私有連線 — 讓複製流量走 Direct Connect，永不經過公共網際網路。
• 暫存區 EBS 加密 — 使用你的 CMK 進行 SSE-KMS 加密。
• 適當大小的複製伺服器類型 — 針對高變更率工作負載選用較大的複製伺服器（c5.large）。

何時選 MGN（以及何時不選）

• 選 MGN： Rehost / 直接搬移現有伺服器。切換窗口緊迫。大型艦隊（數十到數千台 VM）。跨區域或其他雲端遷移到 AWS。
• 不選 MGN： 來源引擎 ≠ 目標引擎的資料庫伺服器——那是 DMS + SCT 的領域。目標為 S3/EFS/FSx 的檔案伺服器——那是 DataSync 的領域。重構為 serverless 或容器的應用程式——那是現代化，不是遷移工具。

AWS Database Migration Service (DMS)——資料庫層主力工具

AWS Database Migration Service (DMS) 是 AWS 針對即時、低停機資料庫遷移的工具。它支援同質搬遷（Oracle → RDS 上的 Oracle、MySQL → Aurora 上的 MySQL）以及搭配 AWS Schema Conversion Tool 的異質搬遷（Oracle → Aurora PostgreSQL、SQL Server → MySQL）。

DMS 架構元件

• 複製執行個體 — 在你 VPC 中的受管 EC2 執行個體，執行 DMS 引擎。依吞吐量需求調整大小：dev 用 dms.t3.medium，生產等級 Pro 工作負載用 dms.c5.4xlarge 到 dms.r5.8xlarge。生產遷移一律部署 Multi-AZ 複製執行個體，確保 AZ 故障不中斷遷移。
• 來源端點與目標端點 — 包含憑證（透過 Secrets Manager 整合）、TLS 設定，以及依引擎調整的額外連線屬性。
• 複製任務 — 遷移的執行單元。繫結來源端點、目標端點、遷移類型、資料表對應，以及任務設定（錯誤處理、LOB 模式、驗證）。

DMS 任務類型

• Full Load — 一次性複製現有資料。快照式。無持續同步。
• Full Load + CDC — 完整載入後接 Change Data Capture 串流。這是低停機切換的 Pro 預設模式。DMS 讀取來源的 redo log（Oracle）、binlog（MySQL/MariaDB）、WAL（PostgreSQL）或 transaction log（SQL Server），並對目標重播每個 DML 操作，直到你下令停止。
• CDC Only — 只套用持續變更。當你已透過其他方式（例如 Snowball 運送的初始載入）預先填充目標，且只需要追上差異時使用。
• Replication Ongoing — 持續複製，無明確結束點。用於讀取擴展模式或跨區域即時複製，而非純粹的遷移。

DMS 遷移類型選擇規則

Pro 等級的選擇規則：每次生產切換都使用 Full Load + CDC。單純 Full Load 保證停機時間等於完整載入時間（600 TB 來說完全無法接受）。CDC Only 需要你事先正確預填。Full Load + CDC 是唯一既能填充目標又能在你規劃切換窗口時持續同步的選項。

DMS 驗證

DMS 包含驗證模式，可在遷移任務進行中同步執行或作為獨立任務執行。針對每一筆遷移的資料列，DMS 重新從來源和目標讀取並以逐欄 checksum 比較，並將不符之處回報為驗證失敗。這是 SAP-C02 等級回答「如何證明目標與來源一致」的標準答案。不要只信賴資料列數——驗證任務能捕捉到 null 值、編碼飄移、trigger 引發的修改，以及精度遺失。

DMS Fleet Advisor（遷移規劃）

已在探索段落說明——DMS 的規劃階段夥伴。為每個來源資料庫產出引擎相容性報告，讓你能正確規劃異質遷移的波次。

DMS Serverless（較新選項）

DMS Serverless 省去複製執行個體大小選擇的煩惱——你只需提供來源、目標和任務設定；DMS 自動擴展容量。適合吞吐量不均勻的遷移；成本較難預測。考試上需要知道它的存在，以及它簡化了「複製執行個體該選哪種大小」的頭痛問題。

AWS Schema Conversion Tool (SCT)——異質引擎轉換

AWS Schema Conversion Tool (SCT) 是離線桌面應用程式（Windows、macOS、Linux），將 Schema 物件從一個引擎轉換到另一個引擎：資料表、索引、約束、檢視表、預存程序、函式、trigger、package、序列。

SCT 轉換模型

SCT 連接到來源資料庫（唯讀）和目標資料庫（可寫入）並執行：

1. 評估報告 — 逐物件產生轉換率。範例輸出：「82% 的 Oracle Schema 可自動轉換為 Aurora PostgreSQL；18%（342 個物件）需要人工處理，主要集中在 PL/SQL package 和 trigger 主體。」
2. 自動轉換 — 轉換機械化可翻譯的 DDL（資料表、大多數約束、簡單檢視表）。
3. 行動項目清單 — 產出需要人工翻譯物件的可開票清單（複雜 PL/SQL → PL/pgSQL、Oracle DBMS_* package、跨 Schema 參照、資料類型缺口）。
4. 套用至目標 — 將轉換後的 DDL 寫入目標資料庫。

SCT 引擎配對與轉換率

典型自動轉換成功率（僅供參考——實際結果因案例而異）：

• Oracle → Aurora PostgreSQL：70–90% 自動（最常見的考題情境）。
• Oracle → Aurora MySQL：60–85% 自動。
• SQL Server → Aurora PostgreSQL：75–90%。
• SQL Server → Aurora MySQL：70–85%。
• MySQL → PostgreSQL：85–95%。
• MongoDB → DocumentDB：大多為機械式轉換，因為 DocumentDB 支援 wire-protocol 相容。
• Cassandra → Amazon Keyspaces：CQL Schema 的機械式對應。

SCT 擴充套件與應用程式轉換

SCT 附帶擴充套件，在目標上模擬來源引擎功能——例如針對 PostgreSQL 的 Oracle DBMS_OUTPUT 或 UTL_FILE 等效實作。對於最小化應用程式程式碼變更至關重要。

SCT 也執行應用程式 SQL 轉換 — 指向你的應用程式原始碼樹，它會將嵌入式 SQL 從 Oracle 方言改寫為 PostgreSQL 方言。覆蓋率因案例而異；將其輸出視為草稿，而非最終版本。

SCT 後接 DMS 的順序

使用 AWS 遷移工具進行異質遷移的正確順序：

1. SCT 評估報告 — 預先量化轉換工作量。
2. SCT 自動轉換 — 產生目標 Schema DDL。
3. 人工修復 — 開發人員修正行動項目。
4. 套用 Schema 至目標 — 在目標 Aurora 叢集建立物件。
5. DMS 複製任務（Full Load + CDC） — DMS 現在有相容的目標可寫入資料。
6. DMS 驗證任務 — 證明資料正確移動。
7. 切換 — 清空 CDC、停止來源寫入、重新導向應用程式。

在異質配對上先執行 DMS 再執行 SCT 會失敗，因為 DMS 只搬移資料，不搬移 Schema。這是 SAP-C02 上最常考的 DMS 架構問題。

AWS Snow Family 艦隊模式

SAA-C03 把 Snowball Edge 視為單裝置離線傳輸的選項。SAP-C02 把它視為艦隊 — 數十到數百台裝置平行出動，在數週而非數月內完成資料中心撤離。

現行 Snow Family 產品線（2026）

• AWS Snowcone — 8 TB HDD 或 14 TB SSD；2 vCPU、4 GB RAM；以標準快遞信封寄送。適合邊緣 / 戰術 / 個位數 TB 的一次性任務。
• AWS Snowball Edge Storage Optimized — 約 80 TB 可用 HDD 或 210 TB 可用 SSD（物件儲存變體）。40 vCPU、80 GB RAM。
• AWS Snowball Edge Compute Optimized — 約 42 TB 可用；52 vCPU、208 GB RAM；選配 NVIDIA V100 GPU。適合離線現場的邊緣運算需求。
• AWS Snowmobile — 已停止接受新訂單。 歷史上是搭載高達 100 PB 的 45 英尺貨櫃車。對於任何 2026 年以後的 EB 規模情境，AWS 建議答案是平行部署多台 Snowball Edge Storage Optimized 裝置艦隊，而非 Snowmobile。

600 TB 的 Snow Family 艦隊拓樸

針對標誌性的 600 TB 情境，Pro 等級設計如下：

• 訂購 8 台 × Snowball Edge Storage Optimized（每台約 80 TB 可用）。總容量約 640 TB。分兩批出貨，確保現場始終有裝置可用，同時其他裝置在運送中。
• 平行載入 — 啟動 8 個載入工作階段，每台裝置一個，使用 AWS OpsHub for Snow Family 應用程式或 snowball CLI。每台裝置在本地載入網路的目標吞吐量約 1 Gbps。
• 保管鏈 — 每台裝置透過 AWS 防竄改封條和 KMS 包裝加密金鑰（金鑰永不存放在裝置上）追蹤。
• 回寄 — AWS 提供回寄標籤；收到後裝置資料自動匯入目標 AWS 區域的 S3。
• 匯入後驗證 — 在標記任務完成前，比對 S3 etag 和物件數量與來源清單。

Snow Edge Compute 的前置處理

Snowball Edge Compute Optimized 可在裝置上執行 EC2 執行個體和 Lambda。對於媒體轉碼、PII 去識別化或出貨前壓縮，你可以在 Snow 裝置上直接轉換資料，讓落地 S3 的位元組已是目標格式。Pro 等級的成本槓桿；很少被考到，但偶爾作為誤導選項出現。

AWS DataSync 檔案伺服器遷移

AWS DataSync 是 AWS 針對檔案到雲端搬遷的線上遷移工具：NFS、SMB、HDFS 以及物件儲存來源，遷移到 S3、Amazon EFS、Amazon FSx for Windows File Server、FSx for Lustre、FSx for OpenZFS，或 FSx for NetApp ONTAP。

DataSync NFS/SMB 遷移——Pro 模式

• 代理程式部署位置 — 一台 DataSync 代理程式 VM（VMware、Hyper-V、KVM 或 EC2）在來源網路內部。對於非常大型的檔案伺服器，平行部署多個代理程式，每個指向不同前綴，以匯聚吞吐量。
• 排程增量傳輸 — cron 式排程只複製差異。用這個方式讓最後切換同步壓縮到幾分鐘。
• 頻寬節流 — 在上班時間限制代理程式吞吐量；夜間移除限制。
• 驗證模式 — POINT_IN_TIME_CONSISTENT（預設）在任務結束時重新掃描並驗證整個資料集。ONLY_FILES_TRANSFERRED 對增量傳輸較快。合規要求高的遷移使用較嚴格的模式。
• VPC endpoint 路由 — DataSync 流量透過 PrivateLink + Direct Connect，讓資料位元組遠離公共網際網路。

DataSync for HDFS

DataSync 支援 HDFS 作為來源——直接從 Hadoop 叢集遷移到 S3，無需中介暫存。代理程式透過 Kerberos 認證讀取 HDFS 並保留 metadata 寫入 S3。這是「將地端 Hadoop 資料湖遷移到 S3-on-Athena」的 Pro 答案。

DataSync Discovery

DataSync Discovery（較新功能）掃描地端儲存陣列並分析容量、存取模式與成長趨勢——然後建議 AWS 儲存目標。在評估階段有用，很少被考到但值得知道它的存在。

DataSync vs Snow Family vs Direct Connect——Pro 決策

在 SAA 等級，決策是「線上傳輸天數 > 7 → Snow」。在 Pro 等級你需要加上：

• 混合使用 — DataSync 透過 Direct Connect 用於持續增量傳輸，Snow 用於初始批量。你兩個都用，不是二選一。Snow 處理會使廣域網路飽和的 95% 批量；DataSync 透過 Direct Connect 處理切換窗口期間 5% 的每日變更。
• 成本最佳化 — Snow 按裝置固定費用 vs DataSync 按 GB 計費。在 500 TB 以上且連線速度低於 1 Gbps 的情況下，Snow 佔優勢。在超過 1 Gbps 專用頻寬時，DataSync 的競爭力提升。

AWS Transfer Family 合作夥伴檔案接收

AWS Transfer Family 提供由 S3 或 EFS 支撐的受管 SFTP、FTPS、FTP 和 AS2 端點。在 Pro 範疇，它以兩種形式進入 AWS 遷移工具討論：

• 將現有地端 SFTP/FTPS/AS2 閘道遷移到 AWS，而不中斷合作夥伴整合。合作夥伴保留相同的憑證和目錄結構（透過邏輯目錄）。你獲得受管端點，不再需要自行管理 SFTP 伺服器並打修補程式。
• 遷移後穩定狀態，用於合作夥伴發起的檔案投遞到 AWS 著陸區。

Transfer Family 部署模式

• 服務管理使用者 — 適合小型合作夥伴清單。
• AWS Managed Microsoft AD / AD Connector — 適合企業身份識別聯盟。
• 自訂 Lambda 身份識別提供者 — 適合 Okta、Azure AD 或自製使用者存儲。
• 受管工作流程 — 檔案到達時觸發的事件驅動管線（解密、驗證、路由至下游）。

何時選 Transfer Family

Transfer Family 不是用於搬移你自己資料的 AWS 遷移工具——那要用 MGN、DMS、DataSync 或 Snow。Transfer Family 是將面向合作夥伴的檔案交換介面從地端遷移到 AWS 而不中斷外部整合的工具。觸發關鍵字：「300 個外部合作夥伴」、「SFTP」、「EDI」、「AS2」、「客戶每天推送檔案給我們」。

Direct Connect vs 網際網路的切換頻寬

網路傳輸在 Pro 等級佔 AWS 遷移工具決策的一半。

遷移用 Direct Connect

• 專用埠： 1 Gbps、10 Gbps、100 Gbps。Direct Connect 合作夥伴提供的託管連線涵蓋低於 1 Gbps 的情況。
• 私有、可預期延遲 — 有緊迫 CDC 延遲 SLO（DMS 需要亞秒級）的遷移需要 Direct Connect。公共網際網路 VPN 的延遲抖動會中斷 CDC 複製。
• 較低的輸出成本 — 對於需要反向複製（AWS → 地端復原）的遷移，每 GB 的 Direct Connect 輸出費用明顯低於網際網路輸出。
• Virtual Interfaces (VIFs)： Private VIF 接 VPC、Public VIF 接 AWS 公共服務（包含 S3）、Transit VIF 接 Transit Gateway。

遷移切換的 Direct Connect 冗餘

在實際切換週末，你需要兩條位於不同位置的 Direct Connect 電路，或 Direct Connect + Site-to-Site VPN 備援。最後 CDC 清空期間電路中斷是職業生涯的高風險事件。主動/主動透過 LAG 或主動/被動透過兩條電路；VPN 作為第三層後備。

遷移用網際網路加 VPN

適用於：

• 小型遷移（< 10 TB）。
• 切換時程寬鬆的 Dev / 暫存遷移。
• Direct Connect 尚未佈建的環境（佈建可能需要數週）。

不適用於：

• 切換窗口緊迫的大型（> 50 TB）遷移。
• 延遲抖動會破壞複製 SLO 的 DMS CDC 重度切換。
• 合規要求私有傳輸的受管工作負載。

應用層串流複製

企業遷移幾乎都帶有串流系統——Kafka 叢集、Kinesis 串流——必須與資料庫和檔案一起達到同位。

自管理 Kafka 的 Kafka MirrorMaker 2

Kafka MirrorMaker 2 (MM2) 是開源的 Kafka 對 Kafka 複製器。以 Kafka Connect 叢集執行。從來源到目標複製 topic、消費者群組 offset 和 ACL。用於將地端自管理 Kafka 遷移 → EC2 上的自管理 Kafka → 最終遷移到 Amazon MSK。

Amazon MSK Replicator

Amazon MSK Replicator 是 MSK 對 MSK 複製的 AWS 受管等效工具。適用場景：

• 用於 DR 或讀本地/寫中央拓樸的跨區 MSK 複製。
• 叢集之間的同區 MSK 遷移（例如零停機版本升級）。
• 具備無衝突 offset 保留的主動/主動多區 MSK。

MSK Replicator 比自己架設 MM2 簡單，因為不需要操作 Kafka Connect 叢集。對於從自管理 Kafka 遷移到 MSK，MSK Connect（將 Kafka Connect 作為受管服務執行）加上 MM2 仍是標準模式。

Kinesis 跨區考量

Kinesis Data Streams 沒有原生跨區複製；你透過Kinesis Client Library (KCL) 消費者複製（讀取區域 A 並寫入區域 B），或透過 Amazon Data Firehose 輸出到 S3 再配合跨區複製。很少是主要遷移答案，但在多區 DR 模式中會出現。

資料一致性驗證——證明搬移安全無虞再切換

在 Pro 等級，「我們已複製資料」是不夠的；「我們已證明資料完全相同，且應用程式可以在目標上正常運作」才是。AWS 遷移工具每個層次都有驗證原語。

DMS 驗證

DMS 驗證任務重新從來源和目標讀取每筆遷移資料列，並以逐欄 checksum 比較。不符之處以驗證失敗的形式呈現在任務的驗證指標中。在 Full Load + CDC 任務進行中同步執行驗證（併行驗證），而非事後執行；在複製仍在進行時就能發現問題。

DataSync 驗證

DataSync 驗證模式（前面已說明）比較物件 metadata 並可選擇比較內容 checksum。對於合規要求高的檔案伺服器遷移，在切換前最後一次執行 POINT_IN_TIME_CONSISTENT 模式。

Snow Family 保管鏈

Snow 裝置在載入時計算每個物件的 SHA-256 checksum。匯入 S3 時，AWS 重新計算並比較。任何不符都會阻擋匯入並記錄到 CloudTrail。你透過 Snow 任務的匯入日誌進行稽核。

MGN 演練切換作為驗證

MGN 的測試切換是功能性驗證——非破壞性地啟動目標執行個體、在應用程式層執行煙霧測試、拆除、繼續複製。正式切換前至少執行兩次測試切換。

應用程式層煙霧測試

除了 AWS 原生驗證，Pro 手冊還要求應用程式層驗證：

• 唯讀流量重播 — 將生產流量日誌以唯讀模式對目標資料庫重播；比較回應數量和延遲分布。
• 逐表差異資料列數 — 每張資料表執行 SELECT COUNT(*)，對差異逐一調查漂移 > 0 的情況。
• 基於 checksum 的對帳 — 應用程式對關鍵商業彙總（總未結餘額、總庫存數量）計算的雜湊值。

標誌性情境——600 TB 地端 Oracle → Aurora PostgreSQL，切換不超過一小時

這是 SAP-C02 AWS 遷移工具的經典問題。從頭到尾完整走一遍。

需求摘要

• 來源： Oracle 19c、單一資料中心、600 TB 總資料庫大小（冷熱分區混合）。
• 目標： Amazon Aurora PostgreSQL 相容、Multi-AZ，位於 ap-northeast-1。
• 切換預算： 應用程式讀寫停機不超過一小時。
• 網路： 現有 10 Gbps Direct Connect；可選擇佈建第二條 10 Gbps 電路作為冗餘。
• 合規： 資料不得經過公共網際網路；強制要求傳輸加密和靜態加密。

第一步——探索與規劃

• 執行 DMS Fleet Advisor 清查 Oracle Schema（資料表、索引、PL/SQL package、trigger）。產出每個 Schema 的轉換率估計。
• 針對範圍內的特定資料庫執行 AWS SCT 評估報告。輸出：78% 自動轉換；22% 人工處理項目，主要是 PL/SQL 和 Oracle 特有的 DBMS_* 用法。
• 決策：透過 SCT + DMS 進行異質遷移。 保留 4 週工程時間用於人工將 PL/SQL 轉換為 PL/pgSQL。

第二步——網路準備

• 在不同位置佈建第二條 10 Gbps Direct Connect 電路作為冗餘。
• 設定主動/主動透過 LAG，讓兩條電路在遷移期間同時運作。
• 新增 Site-to-Site VPN 作為第三層後備。
• 為 DMS 和 S3 設定 VPC endpoint，讓所有遷移流量保持在私有傳輸上。

第三步——Schema 轉換

• 使用 AWS SCT 為所有 Schema 產生目標 Aurora PostgreSQL DDL。
• 將自動轉換的 DDL 套用到暫存 Aurora 叢集。
• 開發人員手動修復行動項目（PL/SQL → PL/pgSQL、package 到 Schema 的重新對應、資料類型調整）。
• 對使用 DMS Full Load 載入到暫存叢集的樣本資料集單元測試轉換後的程序。

第四步——初始資料種子（選項 A：透過 Direct Connect 完整載入）

• 以 Multi-AZ 模式佈建 DMS 複製執行個體，大小選 dms.r5.8xlarge 以確保吞吐量。
• 部署生產 Aurora PostgreSQL 叢集（Multi-AZ、適當執行個體大小、加密啟用、備份保留期設定好）。
• 啟動 Full Load + CDC 任務，從 Oracle 來源到 Aurora PostgreSQL 目標。
• 透過 10 Gbps Direct Connect，約 5 Gbps 有效吞吐量意味著 600 TB 完整載入大約需要 10–14 天。
• 完整載入期間，DMS 對已載入資料表尚未複製 CDC；每張資料表完整載入完成後才開始 CDC 追補。

第四步——初始資料種子（選項 B：Snowball Edge 艦隊 + CDC）

對於不想讓 Direct Connect 連續兩週飽和的更快速初始種子：

• 將 Oracle 快照（RMAN / Data Pump）匯出到本地暫存儲存。
• 載入到 8 台裝置的 Snowball Edge Storage Optimized 艦隊（總容量約 640 TB）。
• 運送到 AWS；資料約 7 個日曆天完成匯入 S3。
• 使用以 S3 為來源端點的 DMS 任務將快照載入 Aurora。
• 同時執行DMS CDC Only 任務，從即時 Oracle 對 Aurora 複製，以快照時的 SCN 作為起點。

選項 B 是 600 TB 搬遷的 Pro 首選答案：離線批量處理熱門主體，線上 CDC 處理涓流差異。Direct Connect 不被完整載入佔滿，可以留給 CDC 流量使用。

第五步——CDC 穩定狀態

• 初始種子完成後，CDC 以亞秒級延遲將每筆 Oracle 交易複製到 Aurora。
• 監控 CloudWatch 的 CDCLatencySource 和 CDCLatencyTarget 指標。延遲超過 30 秒時觸發警報。
• 執行DMS 併行驗證任務 — DMS 持續重新讀取來源和目標的每筆遷移資料列並回報不符之處。
• 在排程切換之前解決所有驗證失敗。

第六步——測試切換

• 啟動應用層的測試切換（若應用伺服器也在遷移中則透過 MGN，若應用伺服器已在 AWS 則透過藍綠部署）。
• 將測試應用層指向 Aurora 目標。
• 執行唯讀煙霧測試、對帳查詢和應用程式整合測試。
• 拆除測試環境。繼續執行 DMS CDC。
• 至少重複兩次測試切換，每次精進執行手冊。

第七步——正式切換（一小時預算內）

切換執行手冊（含時間預算）：

• T+00:00 — 變更窗口開啟。預先將 Route 53 TTL 降至 60 秒（提前 24 小時執行，讓 DNS 快取清空）。
• T+00:05 — 在來源 Oracle 上將應用程式設為唯讀模式；在應用層封鎖寫入。
• T+00:10 — 等待 DMS CDC 延遲清空到零。監控 CDCLatencyTarget = 0。
• T+00:20 — 乾淨地停止 DMS 任務。在 DMS 任務日誌中擷取最終 SCN。
• T+00:22 — 對 Oracle 和 Aurora 都執行最終對帳查詢（每張資料表的資料列數、關鍵商業彙總 checksum）。確認一致。
• T+00:30 — 切換應用程式資料庫連線字串（透過 Secrets Manager 輪換或設定旗標）從 Oracle 到 Aurora PostgreSQL。
• T+00:40 — 在應用層啟用寫入。監控應用程式錯誤率和 Aurora WriteThroughput 指標。
• T+00:50 — 執行切換後應用程式煙霧測試套件。
• T+00:55 — 宣告切換完成。保持 Oracle 來源以唯讀模式執行 72 小時作為復原安全網。
• T+72:00 小時 — 停用 Oracle 來源。

應用程式總停機時間： 約 30 分鐘（T+00:10 唯讀窗口開始到 T+00:40 寫入啟用）。遠在 1 小時預算之內。

第八步——復原安全網

預先撰寫的復原執行手冊：

• 如果切換在任何步驟失敗，重新在 Oracle 來源啟用寫入。
• 停止應用程式。
• 將連線字串重新切回 Oracle。
• 進行事後調查。
• 對於切換前復原之前已寫入 Aurora 的任何資料，在切換準備週期間設定反向 DMS 任務（Aurora PostgreSQL → Oracle）。這是幾乎所有 SAP-C02 Pro 答案都包含的「破玻璃」選項。

透過 Migration Hub 編排 AWS 遷移工具鏈

AWS Migration Hub 是 MGN、DMS、DataSync 和 Snow 任務的遷移工具狀態單一窗格。在 Pro 等級它有三個目的：

• 資產組合追蹤 — 將伺服器和資料庫分組成應用程式，透過 7 Rs 狀態追蹤每個（Retire、Retain、Rehost、Relocate、Replatform、Repurchase、Refactor）。
• 波次可見度 — 每個遷移波次的準備度儀表板。
• 跨服務事件整合 — MGN 啟動事件、DMS 任務狀態、DataSync 任務完成都串流到 Migration Hub。

Migration Hub Refactor Spaces

AWS Migration Hub Refactor Spaces 提供受管基礎架構用於**絞喉器（strangler-fig）**應用程式現代化遷移——逐步將服務從單體架構剝離到新的微服務。嚴格來說不屬於「資料傳輸」範疇，但在鄰近遷移工具的 SAP-C02 現代化問題中出現。

整個鏈的安全考量

每項 AWS 遷移工具服務都有必須針對生產環境強化的安全態勢：

• MGN — 複製流量透過 VPC endpoint + Direct Connect；暫存 EBS 磁碟區以 KMS CMK 加密；代理程式流量一律 TLS 1.2+。
• DMS — 複製執行個體在私有子網路中；端點憑證存放在 Secrets Manager；來源和目標使用 SSL；複製執行個體儲存加密。
• SCT — 在工作站上執行——絕對不要將包含來源憑證的 SCT 專案提交到版本控制；使用 SCT 憑證保管庫。
• DataSync — 代理程式透過啟用金鑰 + IAM 角色向 AWS 認證；流量 TLS 透過 VPC endpoint；目標加密（SSE-KMS）為強制。
• Snow Family — 256 位元加密、金鑰在 AWS KMS 中永不在裝置上、防竄改封條、回收時 TPM 驗證。
• Transfer Family — SFTP（SSH）、FTPS（TLS）、AS2（S/MIME）；僅限內部合作夥伴網路的 VPC endpoint。
• Direct Connect — 電路是私有的但預設不加密；對於合規要求端對端加密的情況，在 Public VIF 上加一層 IPsec VPN。

SAP-C02 AWS 遷移工具常見陷阱

陷阱一：將 MGN 和 DMS 視為可互換

MGN 遷移伺服器（區塊層 VM 複製）。DMS 遷移資料庫（資料列層複製）。如果情境說「遷移 Oracle 資料庫」，MGN 在技術上確實會複製伺服器，但你失去了所有資料庫層的優勢（異質轉換、CDC、驗證）。正確答案是 DMS + SCT。如果情境說「直接搬移這台 Linux 網頁伺服器」，正確答案是 MGN，DMS 是錯的。

陷阱二：異質遷移不執行 SCT 直接跑 DMS

DMS 搬移資料；SCT 轉換 Schema。異質引擎（Oracle → Aurora PostgreSQL）需要先 SCT 來建立目標 Schema 並翻譯預存程序。跳過 SCT 意味著 DMS 在 CREATE 陳述式就會出錯，你的「遷移」在第一步就死掉了。

陷阱三：在 2026 年選擇 Snowmobile

Snowmobile 已停止接受新訂單。對於 EB 規模遷移，當代答案是平行部署多台 Snowball Edge Storage Optimized 裝置艦隊。在 2026 年的題目中，Snowmobile 出現為選項通常是誤導選項。

陷阱四：以為 Direct Connect 是資料傳輸服務

Direct Connect 是管線。DMS、DataSync、MGN 和 Storage Gateway 跑在上面。任何說「使用 Direct Connect 遷移 600 TB」卻不點名傳輸服務的答案都是不完整的。Pro 答案永遠指定整個堆疊：「DataSync 透過 Direct Connect」或「DMS Full Load + CDC 透過 Direct Connect」。

陷阱五：跳過驗證關卡

任何說「複製，切換，完成」的 Pro 答案，如果正確選項包含驗證階段，那就是錯的。DMS 驗證任務、DataSync 驗證模式、Snow checksum 以及應用程式層煙霧測試，在 Pro 等級遷移中是不可省略的。SAP-C02 明確考驗你是否包含驗證關卡。

陷阱六：多層工作負載使用單一服務答案

600 台 VM + 50 個資料庫 + 400 TB 檔案伺服器的遷移需要MGN + DMS/SCT + DataSync/Snow 平行執行，而非單一服務。多層工作負載的單一服務答案是誤導選項。

陷阱七：低估切換網路冗餘的重要性

切換時只有一條 Direct Connect 電路是單點故障。Pro 答案永遠包含冗餘 Direct Connect（LAG 或雙位置），通常還有 VPN 備援。「最小化切換風險」的情境是在暗示這個預期。

陷阱八：混淆 DMS Fleet Advisor 和 SCT

DMS Fleet Advisor 是艦隊規模的探索與規劃（數百個資料庫）。SCT 是每個資料庫的 Schema 轉換。你先執行 DMS Fleet Advisor 對艦隊進行分類，然後對每個波次中的每個資料庫執行 SCT 進行實際轉換。單獨用 SCT 在艦隊規模下操作上不可行；用 DMS Fleet Advisor 而不執行 SCT 則跳過了實際轉換。

陷阱九：在公共網際網路上執行 CDC

DMS CDC 有嚴格的延遲 SLO。公共網際網路抖動會中斷 CDC 並產生不斷增長的複製延遲。每個 Pro 等級的 CDC 切換都在 Direct Connect 上執行。

陷阱十：忽略 Kafka 和 Kinesis

帶有串流層（Kafka、Kinesis）的遷移計畫中需要 MSK Replicator 或 Kafka MirrorMaker 2。只遷移資料庫而忘記事件匯流排的答案是不完整的。

SAP-C02 AWS 遷移工具需要背熟的關鍵數字與模式

• MGN 複製 — 持續區塊層、TLS 1500 埠、預備就緒後切換 RTO 在分鐘以內、測試切換不具破壞性。
• DMS 任務類型 — Full Load、Full Load + CDC、CDC Only、Replication Ongoing。
• DMS 生產最佳實踐 — Multi-AZ 複製執行個體、併行驗證任務、憑證透過 Secrets Manager。
• SCT — 異質遷移時在 DMS 前執行；產出評估報告；轉換 Schema 和用於功能同位的擴充套件。
• DMS Fleet Advisor — 艦隊規模資料庫探索；引擎相容性報告輸出。
• Snow Family 2026 — Snowcone 8/14 TB、Snowball Edge Storage Optimized 約 80 TB HDD 或約 210 TB SSD、Snowball Edge Compute Optimized 約 42 TB + 選配 V100 GPU、Snowmobile 已退役。
• DataSync 吞吐量 — 每個代理程式最高約 10 Gbps；支援 NFS、SMB、HDFS、S3 相容；預設 POINT_IN_TIME_CONSISTENT 驗證。
• Transfer Family — SFTP / FTPS / FTP / AS2；S3 或 EFS 後端；邏輯目錄隱藏儲存貯體路徑；受管工作流程用於到達時處理。
• MSK Replicator — AWS 受管 Kafka 對 Kafka 複製；跨區、同區、主動/主動拓樸。
• Direct Connect 用於遷移 — 1/10/100 Gbps 埠；切換時永遠冗餘；預設不加密（合規需求需加 VPN）。
• 切換計算 — 600 TB 透過 10 Gbps 在約 60% 效率下，完整載入需 10–14 天；Snowball Edge 艦隊將此縮短為端對端約 7 個日曆天。
• 驗證 — DMS 驗證任務、DataSync 驗證、Snow SHA-256 checksum、應用程式層煙霧測試——Pro 答案包含四個層次。

FAQ——SAP-C02 深度的 AWS 遷移工具問題

1. 資料庫伺服器遷移時，何時該用 AWS Application Migration Service (MGN) 而非 DMS？

只有在來源和目標資料庫引擎相同，且你想要直接搬移整台伺服器（OS、資料庫二進位、資料檔案）而非在資料庫層進行遷移時，才使用 MGN。例如，Linux VM 上的 Oracle 19c 遷移到具相同設定的 EC2 上的 Oracle 19c——MGN 可以使用。一旦目標引擎不同（Oracle → Aurora PostgreSQL）或目標是受管資料庫（RDS、Aurora），你就需要 DMS + SCT，因為 MGN 無法轉換 Schema 或翻譯預存程序。SAP-C02 的誤導模式是在應該用 DMS + SCT 的異質資料庫遷移中提供 MGN 作為選項。

2. DMS Fleet Advisor 和 AWS Schema Conversion Tool 有何不同？

DMS Fleet Advisor 是艦隊規模的探索與規劃工具——它清查地端環境中數百個資料庫，分析引擎版本和功能使用情況，並產出估計每個 Schema 自動轉換率的引擎相容性報告。它回答「在我 200 個資料庫中，哪些容易遷移，哪些困難？」AWS SCT 是每個資料庫的 Schema 轉換工具——它連接到特定來源資料庫，產生目標 Schema DDL，轉換預存程序，並產出行動項目清單。你先執行 DMS Fleet Advisor 將艦隊分類成波次，再對每個波次中的每個資料庫執行 SCT 進行實際轉換。把它們視為可互換是一個陷阱。

3. 在 1 小時切換的生產環境 Oracle 到 Aurora PostgreSQL 遷移中，正確的任務類型選擇是什麼？

Full Load + CDC。 單純 Full Load 意味著停機時間等於完整載入時間（數百 TB 需要數天到數週）。CDC Only 需要透過其他方式（例如 Snowball 匯入的 Oracle Data Pump 轉存）預先填充。Full Load + CDC 兩者都做——填充目標並保持同步——因此在切換時，CDC 延遲接近零，你只需凍結寫入、清空最後 CDC 差異，並在幾分鐘停機內切換應用程式。搭配 Multi-AZ 複製執行個體和DMS 併行驗證任務以確保生產安全。

4. 對於具有現有 10 Gbps Direct Connect 的 600 TB 地端遷移，該使用 DataSync、Snowball Edge 艦隊，還是兩者都用？

兩者都用。Pro 首選模式是：Snowball Edge Storage Optimized 艦隊負責初始 600 TB 批量（通常 8 台裝置平行執行，約 640 TB 總容量，端對端約 7 個日曆天），加上 DMS CDC Only（資料庫）或 DataSync 透過 Direct Connect 排程增量（檔案）來追上快照到 Snow 載入與切換時刻之間的差異。Snow 處理主體；Direct Connect 處理涓流。用 600 TB 完整載入佔滿 10 Gbps Direct Connect 需要 10–14 天的專用頻寬，並剝奪其他組織成員的網路資源。Snow + CDC 更快也更友善。

5. 如何保證 Oracle 到 Aurora 切換期間接近零的資料遺失？

四層堆疊保證：(1) DMS Full Load + CDC 搭配併行驗證任務，持續重新讀取來源和目標的每筆遷移資料列並回報不符之處；(2) 在切換開始時對來源應用程式執行唯讀凍結，讓沒有新寫入能造成差異；(3) 在切換連線字串前清空 CDC 到零延遲（CloudWatch CDCLatencyTarget = 0）；(4) 作為最後切換前關卡的最終對帳查詢（每張資料表的資料列數、關鍵商業彙總 checksum）。綜合起來，這些產生幾分鐘唯讀停機且目標零資料遺失。

6. MSK Replicator 是什麼，我在遷移時何時需要它？

Amazon MSK Replicator 是 AWS 受管的 Kafka 對 Kafka 複製器，用於跨區、跨叢集和主動/主動 MSK 拓樸。每當你正在遷移的工作負載有Kafka 事件匯流排必須在目標 AWS 環境中達到同位時，你都需要它——單純切換無狀態消費者是不夠的，因為消費者群組 offset 也必須複製。對於從地端自管理 Kafka 遷移到 MSK，使用在 MSK Connect 上執行的 Kafka MirrorMaker 2（受管 Kafka Connect）。對於 MSK 叢集之間的遷移（叢集升級、跨區 DR），使用 MSK Replicator。忽略串流層是 Pro 考試中常見的錯誤；光有伺服器和資料庫並不構成完整的遷移。

7. Direct Connect 預設是否加密遷移流量？

不加密。 Direct Connect 電路是私有的（不走公共網際網路），但在連結層沒有加密。對於要求傳輸加密的合規需求（HIPAA、PCI-DSS、GDPR），在 Direct Connect 電路的 Public VIF 上加一層 Site-to-Site IPsec VPN — 這同時給你私有傳輸和端對端加密。或者，依賴應用程式層加密（TLS 到每個 AWS 服務端點，所有 AWS 遷移工具服務預設都強制執行）。SAP-C02 直接考這個：需要在 Direct Connect 上進行加密傳輸的合規驅動遷移意味著「Direct Connect + VPN」或「每個服務 TLS」，而非單純 Direct Connect。

8. 如果切換在執行中途失敗，如何處理復原？

在切換準備期間預先撰寫反向複製路徑。對於資料庫遷移：在切換前，設定一個反向 DMS 任務（Aurora PostgreSQL → Oracle）作為「破玻璃」復原路徑。在正常切換期間不啟動它；只在宣告復原時才啟動。切換後保持來源 Oracle 資料庫以唯讀備援模式執行 72 小時；這是最簡單的復原方式（把連線字串切回去）。對於使用 MGN 的伺服器層復原，至少保留來源 VM 到切換後 72 小時——MGN 的測試切換模式意味著即使你已執行「正式切換」，仍然可以從暫存磁碟區重新啟動。每個 Pro 遷移計畫都有復原演練，不只有正向演練。

總結——SAP-C02 深度的 AWS 遷移工具

在 Pro 等級，AWS 遷移工具是一套設計並排序成系統的服務鏈，而非單一服務選擇。核心鏈是：探索（Migration Hub + Application Discovery Service + DMS Fleet Advisor + Migration Evaluator） → 異質遷移時進行 Schema 轉換（SCT） → 每層各自的複製（MGN 負責伺服器、DMS 負責資料庫、DataSync 負責檔案、Snow 負責離線批量、Transfer Family 負責合作夥伴投遞、MSK Replicator 負責串流） → 傳輸（含冗餘的 Direct Connect） → 每層各自的驗證（DMS 驗證任務、DataSync 驗證、Snow checksum、應用程式煙霧測試） → 預先演練的切換與預先撰寫的復原計畫。標誌性 SAP-C02 情境——600 TB 地端 Oracle → Aurora PostgreSQL 且切換不超過一小時——的解決方案是：SCT 進行 Schema 轉換、Snowball Edge 艦隊負責初始 600 TB 種子、從 SCN 檢查點執行 DMS CDC Only、DMS 驗證任務與 CDC 併行執行、冗餘 Direct Connect 負責 CDC 流量、兩次演練測試切換、約 30 分鐘唯讀凍結-清空-切換窗口，以及 72 小時反向 DMS 復原路徑。只有在情境確實只有單一層時才選單一服務答案；每當工作負載跨越伺服器、資料庫、檔案和串流時——也就是每次真實的遷移——就選鏈答案。掌握這條鏈，而不只是各個服務，遷移工具題型就會收斂成一套可重複執行的七步驟操作手冊。