系列專欄：從 AWS 視角征服 Azure：AZ-900 30 天通關實戰
難度指數：★★★★☆
今日任務：用 Storage Explorer 與 AzCopy 搬移 Blob/File，並判斷何時改用 Azure Migrate、Database Migration Service 或 Data Box。
本文使用copilot cli 初稿，antigravity gemini 3.6 以上校稿，Day 16 我們替 VM 準備了共享檔案與區塊磁碟；今天，CTO 把一支真正的
遷徙隊伍交給 Titan 科技的 Chief Cloud Architect：把地端檔案、舊雲端
物件與資料庫搬進 Azure，而且要可追蹤、可重試、可控風險。
資料遷移不是「找一個上傳按鈕」而已。若用人工拖曳 50 TB 檔案，可能因
網路中斷而從頭開始；若用資料庫工具搬影像，會把服務邊界搞錯；若未先
盤點來源、權限與校驗策略，搬完才發現檔案遺失，爆炸半徑已經擴散到
整個備份與合規流程。今天要建立的判斷鏈是：先辨識資料型態與距離，
再選工具，最後用權限、日誌與校驗收斂風險。
┌────────────────────────────────────────────────────────────┐
│ Titan 資料遷徙架構與工具分流 │
├─────────────────┬────────────────────────┬─────────────────┤
│ 評估與依賴分析 │ 網路連線傳輸 │ 離線實體運送 │
│ Azure Migrate │ AzCopy / Storage Expl. │ Azure Data Box │
├─────────────────┴───────────┬────────────┴─────────────────┤
│ ▼ │
│ Azure Blob / Files 儲存體服務 │
│ (驗證機制、日誌稽核、最小 RBAC 授權) │
└────────────────────────────────────────────────────────────┘
💡 架構師重點筆記：Azure Migrate 是「發現、評估與特定工作負載遷移」
的雷達與控制中心，不等於任意檔案複製器；Storage Explorer 是圖形化操作介面；AzCopy
是適合腳本與批次作業的資料傳輸引擎；Data Box 則把網路瓶頸改成實體
裝置物流。資料庫另有 Database Migration Service，不能用檔案工具代替。
AWS 使用者常把 aws s3 cp、aws s3 sync、AWS Snowball Edge 與 Database
Migration Service 都稱為「搬資料」，但它們處理的抽象層不同。S3 CLI
與 Azure AzCopy 都是物件/檔案資料平面工具；sync 會依來源與目的地
狀態差異同步，適合重跑的批次流程。AWS DMS 與 Azure Database
Migration Service 則依支援的資料庫引擎提供遷移或複寫流程；Snowball Edge 與
Azure Data Box 處理的是大容量離線傳輸。
Azure Storage Explorer 位於「操作介面」層：可以瀏覽容器、檔案共用、
上傳下載與管理 SAS，但它不是遷移評估平台，也不是資料庫複寫服務。
AzCopy 位於「傳輸引擎」層，支援 Blob、Files 與 ADLS Gen2 的高效能
複製；可用登入身分、SAS 或服務主體等方式授權，實際可用功能取決於
目的服務與權限。
頻寬風險：網路傳輸的上限受頻寬、延遲、封包遺失與同時使用者影響。
AzCopy 能平行化與重試，卻不能魔法突破一條飽和的 WAN。TB 級資料若
計算後的上傳時間超過切換窗口，應評估 Data Box，而不是盲目增加
並行度。
一致性風險：來源仍在寫入時，單次複製可能得到不完整檔案。應先定義
凍結窗口、增量同步、檔案雜湊與抽樣驗證；sync 或 AzCopy 的重試不等於
交易一致性。資料庫則必須用具備複寫與切換語意的 DMS 類服務。
權限風險：把儲存體帳戶金鑰貼進 shell history，或發出過度寬廣、
永不過期的 SAS，會讓一次搬運變成長期入侵入口。優先使用 Microsoft
Entra ID 登入與最小 RBAC；若必須用 SAS，限制資源、權限、IP、協定與
有效期限，並在作業後撤銷或輪替。
遷移工作應使用專用身分、專用容器與明確的來源/目的地路徑，不要給整個
Storage Account 的永久寫入權。先以小批次 dry run，再擴大到正式資料；
保留來源唯讀、傳輸日誌與校驗清單，讓錯誤只影響本批次，而不是覆蓋整個
資料湖。目的地也要用軟刪除、版本控制或不可變保留等資料保護能力，
但要注意這些設定不是備份的替代品，且可能帶來額外成本。
| 遷移問題 | AWS 選擇 | Azure 選擇 | 架構判斷 |
|---|---|---|---|
| 盤點伺服器與成本 | Application Discovery / Migration Hub | Azure Migrate | 先評估依賴、大小與可行性 |
| 物件/檔案批次搬運 | AWS CLI s3 cp/sync |
AzCopy | 網路資料平面，支援重試與批次 |
| 圖形化少量操作 | S3 Console / CLI 輔助 | Storage Explorer | 適合探索、抽查與人工管理 |
| 資料庫線上遷移 | AWS DMS | Azure Database Migration Service | 支援範圍依引擎與 online/offline 模式而異 |
| 大量離線資料 | AWS Snowball Edge | Azure Data Box | 頻寬不足時以實體裝置運送 |
在 AWS，CLI 命令最後呼叫 S3 API；在 Azure，Storage Explorer 與
AzCopy 也都透過儲存體端點與授權機制完成資料平面操作。上層工具可以
簡化工作，卻不會替架構師決定資料分類、RPO/RTO、保留政策或切換窗口。
這就是從「能不能上傳」演進到「能否可重複、可審計地遷移」的抽象提升。
cxcxc-io 的 AWS 架構參考把 IAM Role → VPC Endpoint → S3 串成
一條私有資料存取路徑：工作負載先透過角色取得臨時權限，再由 VPC Endpoint
前往 S3，而不是把長期 Access Key 放在主機或遷移腳本中。套用到本日的
雙雲對照，AWS 的這個設計觀點可對應 Azure 的 Microsoft Entra ID 工作負載
身分、受限的 Storage RBAC 與 Private Endpoint；但兩者的網路元件和授權
語法並不相同，這段是 AWS 側架構觀點，不是 Azure 原生拓撲的一對一翻譯。
┌────────────────────────────────────────────────────────────┐
│ 雙雲私有資料平面存取路徑對照 (cxcxc-io) │
├────────────────────────────────────────────────────────────┤
│ AWS 路徑: │
│ 工作負載 ──> IAM Role (臨時憑證) ──> VPC Endpoint ──> S3 │
│ │
│ Azure 路徑: │
│ 工作負載 ──> 受控身分 / Entra ID ──> Private EP ──> Blob │
├────────────────────────────────────────────────────────────┤
│ 核心觀點: 拒絕寫死金鑰，強制走私有端點與最小權限資料平面 │
└────────────────────────────────────────────────────────────┘
💡 來源：改編自
cxcxc-io/README.md圖 1（AWS 側對照圖），已對照 Azure 服務調整。
Azure Storage Explorer
AzCopy
s3 cp / s3 sync；兩者皆是資料平面Azure Migrate
Azure Data Box
Azure Database Migration Service
Titan 科技要把地端 50 TB 的歷史影像搬進 Azure Blob Storage。既有
專線只有 200 Mbps，估算完整上傳超過一個月；同時，訂單資料庫必須
在週末切換，要求盡量縮短停機。CTO 指著兩條路線問 Chief Cloud
Architect：「我們是否只要裝好 AzCopy，就能解決全部問題？」
✅ 正解：B。 影像是大量非結構化資料，頻寬不足時 Data Box 能把
網路傳輸改為受控的實體搬運；資料庫需要 schema、複寫、驗證與切換，
應在其支援的資料庫引擎與模式中使用 Database Migration Service；Azure Migrate
則可負責盤點依賴、評估並執行特定工作負載遷移，三者分工清楚。
❌ A 的陷阱：AzCopy 適合高效能網路搬運，但平行化不會消除 200 Mbps
的物理上限；資料庫也不能只靠檔案複製維持交易一致性。可將 AzCopy
留給小批次、增量或頻寬足夠的檔案資料。
❌ C 的陷阱：Storage Explorer 適合瀏覽與少量管理，不是 50 TB 長期
批次遷移的最佳控制面；共用帳戶金鑰更違反最小權限，無法精準限制單一
容器與期限。應改用 Entra ID 或受限 SAS，並留下可稽核的操作紀錄。
❌ D 的陷阱：Azure Migrate 是探索與評估中心，不是「任何資料自動
搬完」的萬用引擎。把評估、檔案傳輸與資料庫切換混為一談，會造成責任
邊界不清與錯誤的停機預估。
Titan 有 20 TB 的冷資料，地端出口頻寬很低，且沒有嚴格的即時切換
窗口。哪個選項最合理？
答案：B。 題幹關鍵是「大量資料＋網路瓶頸」；Data Box 的服務邊界
就是離線大量傳輸。A 沒處理頻寬，C 是資料庫工具，D 是評估/規劃工具。
examtopics-az900-search skill 覆核，本文不杜撰部署管線每晚要把指定目錄的新增與變更檔案同步到 Azure Blob，要求可
腳本化、可重試且不依賴桌面操作。應優先選哪個工具？
答案：A。 這是資料平面批次傳輸與自動化需求，AzCopy 比圖形化
Storage Explorer 更適合納入排程；C 與 D 的服務邊界不同。
examtopics-az900-search skill管理員只需檢查幾個 Blob、建立 File Share，並在畫面上確認上傳結果；
另一個小組要搬遷關聯式資料庫。哪個配對正確？
答案：A。 Storage Explorer 適合互動式儲存體管理，資料庫遷移則需
專用的 schema、複寫與切換能力。其他選項都把工具層級或服務邊界混淆。
examtopics-az900-search skill⚠️ 來源說明：本題改寫自 2020 年 gratisexam AZ-900 題庫（歷史題型改編），屬歷史題庫層；
已依現行 Microsoft Learn 交叉驗證，不沿用可能過期的舊服務名稱或答案敘述。
公司要把檔案從地端複製到 Azure Blob，要求使用命令列而非入口網站。
哪個選項最符合需求？
答案：A。 AzCopy 是資料傳輸工具；其餘是治理、建議與監控服務，
不能直接取代檔案複製引擎。
⚠️ 來源說明：本題改寫自 2020 年 gratisexam AZ-900 題庫（歷史題型改編），屬歷史題庫層；
服務名稱與判斷已按現行文件修正。
一家公司要將既有資料庫遷移到 Azure，並盡量降低停機時間。哪個服務
方向最合理？
答案：B。 在 Azure DMS 支援的 SQL 目標與 online/offline 模式中，
資料庫遷移可處理相容性、複寫與切換規劃；檔案工具只能搬位元組，不能保證
交易語意。Azure Migrate 可協助評估與特定工作負載遷移，但不是資料庫複寫的替代品。
看到「檔案」先不要立刻選工具，可以用三個問題收斂：
這三題比背服務名稱更接近架構師實務：同一份資料可能先用 Data Box
做初始種子，再用 AzCopy 做增量同步，最後以應用程式切換完成遷移。
AWS 的 Snowball Edge + s3 sync 也可以採相同的「離線初始種子＋網路增量」
抽象，但實際命令、權限模型與服務限制仍須查該雲官方文件。
┌────────────────────────────────────────────────────────────┐
│ AZ-900 資料遷移工具快速判斷鏈 │
├──────────────────────┬─────────────────────────────────────┤
│ 情境條件 │ 優先選用工具與服務 │
├──────────────────────┼─────────────────────────────────────┤
│ 大容量 + 頻寬嚴重不足│ 實體裝置搬運 ──> Azure Data Box │
│ 命令列 / 自動化腳本 │ 高效網路引擎 ──> AzCopy (CLI) │
│ 視覺化 GUI / 少量管理│ 跨平台桌面端 ──> Storage Explorer │
│ 關聯式資料庫切換 │ 專用遷移服務 ──> Azure DMS │
│ 伺服器盤點與整機遷移 │ 評估規劃中心 ──> Azure Migrate │
└──────────────────────┴─────────────────────────────────────┘
💡 架構師決策速查：先辨別「資料庫 vs 檔案」，再辨別「頻寬足夠 (網路) vs 頻寬不足 (實體裝置)」，最後依「自動化需求」決定 AzCopy 或 Storage Explorer。
情境題目： Titan 科技需將地端機房中 70 TB 的非結構化歷史歸檔影像遷移至雲端物件儲存。地端對外網路頻寬僅 100 Mbps，且白天需保留給核心業務連線，要求以最短總耗時且對日常網路頻寬衝擊最小的方式完成遷移。架構師應採取哪項方案？
┌────────────────────────────────────────────────────────────┐
│ 決策分歧：70 TB 檔案 + 頻寬受限 │
│ 網路連線 (CLI / AzCopy) ──> 耗時數月擠爆頻寬 ──> 判定失敗 │
│ 實體裝置 (Snowball / Data Box) ──> 物流寄送 ──> 最佳方案 │
└────────────────────────────────────────────────────────────┘
答案：B。 70 TB 在 100 Mbps 頻寬下全速上傳需耗時數十天，嚴重排擠業務頻寬；Snowball Edge 能將傳輸瓶頸轉為實體硬體物流，是最快且不消耗對外頻寬的標準解法。A 忽略頻寬限制；C 是混合雲快取並非大量遷移首選；D 是資料庫遷移工具，不適用於非結構化影像檔。
Azure 知識映射與連動解析：
對應至 Azure AZ-900 考點，即為 Azure Data Box。當資料量達到數十 TB 且網路頻寬有限（或傳輸估算超過可接受的遷移窗口）時，AZ-900 官方題庫必定考核「Azure Data Box 實體裝置」。架構師心法在兩朵雲完全相通：「頻寬有極限，物流無瓶頸」。
情境題目： Titan 系統工程師每天需將地端備份伺服器產生的新日誌與報表檔案，自動上傳至雲端儲存進行長期保存。要求傳輸過程能腳本自動化執行、僅上傳新增或修改過的檔案（Delta Sync），且具備中斷後自動重試機制，不需人工作業。應選擇哪種傳輸工具？
aws s3 sync 命令排程批次作業┌────────────────────────────────────────────────────────────┐
│ 差異同步比對機制 (aws s3 sync ↔ azcopy sync) │
│ 來源目錄 (地端) ──> 比對「檔名、大小與時間戳」 ──> 目的端 │
│ 僅傳輸增量差異 (Delta) + 支援斷點續傳 ──> 兼顧頻寬與可靠性 │
└────────────────────────────────────────────────────────────┘
答案：B。 aws s3 sync 能自動比對來源與目的地的檔名、大小與最後修改時間，僅傳輸差異檔案（增量同步），且命令列格式能輕易納入 Linux Cron 或 Windows Task Scheduler 排程中。A 需人工介入無法自動化；C 每天快遞實體裝置成本過高且延遲巨大；D 是伺服器資產探索工具而非檔案搬運工具。
Azure 知識映射與連動解析：
對應至 Azure AZ-900 考點，此需求首選為 AzCopy（搭配 azcopy sync 命令或 azcopy copy 搭配指令碼排程）。AZ-900 經常出現「圖形介面 (Storage Explorer / Portal) vs 命令列工具 (AzCopy / CLI)」的選型陷阱題：只要題幹出現「腳本化 (scriptable)」、「批次自動化 (batch)」、「排程執行 (scheduled)」，正解一律鎖定命令列引擎 AzCopy；若為「互動式檢視、少量手動上傳、設定 Access Tier 或產生 SAS」，才選 Storage Explorer。
雙雲考場口訣：大量離線走硬體物流：Snowball Edge ↔ Azure Data Box命令列批次與增量同步：aws s3 sync ↔ azcopy sync圖形化互動管理：S3 Console ↔ Azure Storage Explorer資料庫交易複寫：AWS DMS ↔ Azure Database Migration Service (DMS)
| 項目 | 內容 |
|---|---|
| 對應課程章節 | 課程未涵蓋 |
| 官方考綱領域 | Describe Azure Architecture & Services（占比 35–40%） |
| 課程涵蓋範圍 | 本主題課程未收錄 |
| 本文補充範圍 | Microsoft Learn：Storage Explorer、AzCopy、Azure Data Box、Azure Migrate、Azure Database Migration Service；並取用 RPG 素材庫「遷徙行軍」的 DMS / Data Box / AzCopy 遷移策略與 AWS Snowball Edge、S3 CLI 對照。 |
⚠️ 本日是課程對照表列出的課程空白日；本文以 Microsoft Learn
現行文件與 RPG 遷徙行軍素材補足工具邊界，不把補充工具誤寫成課程
已涵蓋的高權重考點。
資料已經抵達 Azure，下一個問題是：Titan 的關聯式資料庫要選
Azure SQL Database 還是 Managed Instance？明天我們進入關聯神殿，對照
AWS RDS 的受控資料庫邊界、相容性與遷移決策。
iThome鐵人賽
看影片追技術