【Day 16】Azure Files & Managed Disks：共享檔案與高效能磁碟的資料堡壘 feat. AWS 雙強對照

系列專欄：從 AWS 視角征服 Azure：AZ-900 30 天通關實戰
難度指數：★★★★☆
核心考點：Azure Storage account、Azure Files SMB/NFS、File share、Managed Disks、OS disk/Data disk、Standard HDD、Standard SSD、Premium SSD、Ultra Disk、Disk bursting、快照、可用性與資料保護、AWS EFS/EBS 對照。

🎯 前言與今日目標

Day 15 我們把 Blob Storage 的物件分成 Hot、Cool、Cold 與 Archive，學會依存取頻率換取成本效率。但物件儲存不是所有應用程式的答案：傳統 ERP 可能期待一個可掛載的檔案系統，資料庫則需要低延遲、可預期 IOPS 的區塊裝置。若把兩者混用，最壞情況不是「效能差一點」，而是應用程式直接無法啟動、資料庫交易逾時，甚至在災難復原時才發現資料沒有被保護。

今天 Titan 科技要替舊式訂單系統搬家。Windows 應用程式的多台 VM 必須共同讀寫報表檔案；SQL Server 則要自己的高效能磁碟。Chief Cloud Architect 的任務不是背服務名稱，而是回答三個問題：資料要以檔案共享還是區塊磁碟呈現？工作負載需要什麼效能？故障或誤刪時如何縮小爆炸半徑？

對 AWS 架構師而言，最常見的誤植是把 Azure Files 當成 EBS，或把 Managed Disk 當成跨主機共享的 EFS。今天會用同一套抽象模型重新對齊：Azure Files ↔ Amazon EFS（檔案介面），Managed Disks ↔ Amazon EBS（區塊介面）；兩者都由雲端平台管理底層儲存，但連接模型、共享限制、效能與備份策略完全不同。

📚 Part 1：0.5 小時觀念裝備（AWS ↔ Azure 深度對照）

📐 從應用程式到儲存體的請求路徑

┌──────────────────────────────────────────────────────────────┐
│ Titan 應用程式與資料層                                       │
├──────────────────────────────────────────────────────────────┤
│ 多台 VM 共同讀寫檔案  →  Azure Files (SMB / NFS)             │
│ AWS 對照：Amazon EFS；抽象是 Storage account / file share    │
├──────────────────────────────────────────────────────────────┤
│ VM 的 OS / DB 區塊 I/O  →  Azure Managed Disk                │
│ AWS 對照：Amazon EBS；抽象是 Disk SKU / snapshot / backup    │
└──────────────────────────────────────────────────────────────┘

💡 架構師重點筆記：左側是「檔案系統」抽象，應用程式看到目錄、檔名與檔案鎖，適合多台 VM 掛載同一份資料；右側是「區塊裝置」抽象，VM 看到的是磁碟，作業系統和資料庫自行管理檔案系統。先看 I/O 介面，再看 SKU，不要因為兩者都叫 Storage 就直接互換。

1. Azure Files：受控的雲端檔案共享

Azure Files 建立在 Storage account 中，以 file share 提供可掛載的檔案系統。Windows 常用 SMB 3.x，Linux 可以使用 SMB；在傳統 Storage account 部署 NFS 4.1 時，必須使用 Premium FileStorage（SSD）帳戶，Standard GPv2 不支援 NFS。用戶端可以是 Azure VM、容器或地端伺服器；透過 Azure File Sync，還能把地端 Windows 檔案伺服器的常用資料快取到 Azure。

SMB 不只是「Windows 專用的網路磁碟」：它支援身分驗證、檔案鎖與企業常見的檔案語意；NFS 則常見於 Linux/Unix 工作負載。選擇通訊協定時，必須同時檢查作業系統、驗證方式、網路連接埠和應用程式對鎖定語意的要求。把需要 POSIX 行為的 Linux 應用程式硬接到不相容的共享上，會造成難以重現的權限與鎖定錯誤。

Azure Files 的效能層級包含 Standard 與 Premium。Standard 以 HDD 為基礎，適合一般檔案共享；Premium 以 SSD 為基礎，提供較低延遲與較高、較一致的效能，適合高 I/O 檔案服務。實際可用的備援、協定與功能取決於帳戶類型與區域，不能只看「Premium」三個字就假設所有選項都存在。

Azure Files 與 Amazon EFS 的對照

這個表不是「一對一產品翻譯」。AWS EFS 的 mount target 與 VPC 子網路設計，不能直接套到 Azure；Azure Files 的 storage account 網路端點、金鑰或身分授權，也不是 Amazon EFS 的設定方式。跨雲遷移時應先重畫網路與身分邊界，再搬移資料。

若 AWS 工作負載需要 Windows 原生 SMB 與 Active Directory 整合，應另外比較 Amazon FSx for Windows File Server；EFS 是 NFS 檔案系統，不能把它當成 Azure Files SMB 的一對一產品對應。

☁️ AWS EFS / EBS ↔ Azure Files / Managed Disks：服務邊界與遷移陷阱

雙雲遷移最危險的做法，是把 AWS 的資源名稱逐字替換成 Azure 名稱，卻沒有重新確認「用戶端看到的是什麼介面」。EFS 與 Azure Files 都是檔案服務；EBS 與 Managed Disks 都是區塊服務，但這不代表掛載命令、網路端點、身分模型或共享限制相同。

Azure Files 與 EFS：SMB 不是 NFS 的別名

EFS 的核心介面是 NFS，通常由 Linux 用戶端透過 VPC 內的 mount target 連線；權限常以 POSIX UID/GID、NFS client 與 security group 的組合表達。Azure Files 則以 SMB 3.x 支援 Windows 常見的網路磁碟與檔案鎖；傳統 Storage account 的 NFS 4.1 需使用 Premium FileStorage。SMB 分享可整合 Active Directory／Microsoft Entra Domain Services 相關身分；NFS 則通常採用 Unix 身分與網路邊界，不會自動變成 Kerberos 網域驗證。

因此，mount -t nfs 並不是把 EFS 連線字串換成 Azure host name 就能完成的遷移。若來源是 Windows SMB 應用，應確認 Azure Files SMB、DNS、TCP 445、AD 身分與 share-level/file-level 權限；若來源是 Linux EFS，則要確認 Azure Files NFS 4.1 的支援條件、網路路由、export 行為與 POSIX 權限。兩者都叫「共享檔案」，但應用程式依賴的鎖定、大小寫、ACL 與驗證語意可能完全不同。

Managed Disks 與 EBS：磁碟類型只能做方向性對照

這裡的「對照」不是價格或 SLA 的承諾。gp3 可以獨立調整 IOPS 與吞吐量，Azure Premium SSD v2 也有相似的獨立效能思維，但兩邊的容量單位、最大值、區域可用性與 attached VM 上限不同。遷移評估應以實測 I/O profile 為中心，而不是看到 gp3 就機械式換成 Premium SSD。

三個常見遷移陷阱

1. 把 EFS mount target 套到 Azure Files：EFS mount target 是每個 VPC subnet 的區域性網路入口；Azure Files 以 storage account endpoint、private endpoint 或 service endpoint 暴露 file share，資源拓撲不同。
2. 把 NFS no-auth 當成 SMB/Kerberos：Azure Files SMB 的網域式驗證、share ACL 與 NTFS ACL 需要重新規劃；不能把來源的 UID/GID 或匿名 NFS 行為直接當成 AD 使用者。
3. 把 EBS 附掛模型當成共享檔案系統：EBS 與 Managed Disk 預設是 VM 的區塊裝置。即使某些平台提供受限的 shared-disk 能力，也不會自動提供一般檔案系統的鎖定與一致性語意。

遷移 runbook 應先列出「協定、驗證、網路、鎖定、效能、復原」六欄，再建立小型驗證環境。先讓一個真實應用完成讀、寫、鎖定、斷線重連與還原測試，才把容量與正式資料搬過去。

2. Managed Disks：VM 的區塊儲存

Managed Disk 是 Azure 管理的虛擬硬碟。平台處理底層儲存帳戶、配置與可用性，架構師仍要決定磁碟類型、大小、加密、快取、備份與附掛位置。每台 VM 至少有一個 OS disk，也可以附加多個 data disks；官方最佳實務通常是把應用程式資料與 OS 分離，避免 OS 磁碟滿載或重建時牽動資料。

主要磁碟層級如下：

⚠️ 考點防坑：OS Disk 可使用 Standard HDD、Standard SSD 與 Premium SSD；Premium SSD v2 與 Ultra Disk 僅能作為 Data Disk，不能用來開機。表中的 AWS 欄是架構思維對照，不代表 SKU、SLA 或價格相同。題目若只說「需要共享檔案」，優先想到 Files/EFS；若說「VM 的 OS 磁碟、資料庫區塊 I/O、IOPS」，才進入 Managed Disks/EBS 的選型。

3. 效能、快取與資料保護：不要把可用性當成備份

磁碟效能至少有三個維度：IOPS（每秒 I/O 次數）、吞吐量（每秒傳輸資料量）與延遲。小型隨機讀寫的資料庫可能受 IOPS 限制；大型循序掃描則可能先撞到吞吐量。VM 大小也有磁碟頻寬與附掛數量上限，升級磁碟而不檢查 VM 上限，效能不會憑空出現。

Azure VM 的 disk caching（ReadOnly、ReadWrite 或 None）會影響讀寫路徑。資料庫工作負載不應憑經驗套用快取；例如 SQL Server 資料檔通常評估 ReadOnly，而交易記錄檔通常使用 None，以免寫入快取干擾持久性；仍須依資料庫引擎、磁碟建議與實際基準測試決定。Premium SSD v2 與 Ultra Disk 不支援 Host Caching。

Premium SSD 與 Standard SSD 在符合大小與平台條件時可使用 Disk Bursting：信用額度模式適合短暫尖峰，隨選模式則可能產生額外費用；這是短期效能緩衝，不應當成長期基線效能。

Managed Disk snapshot 是某一時間點的磁碟複本，可作為測試、複製或還原材料；它不是自動的跨區災難復原方案。要處理長期保留、排程、應用程式一致性與跨區還原，應使用 Azure Backup 或適合的災難復原設計。磁碟加密保護靜態資料，但不會自動修補錯誤的 RBAC、公開端點或過寬的網路規則。

🛡️ 防禦性設計：共享儲存體的安全邊界

共享檔案與區塊磁碟都要同時保護「資料面」和「控制面」。資料面是檔案內容與磁碟區塊；控制面則是誰能建立、掛載、刪除、變更網路或取得快照。只加密資料而讓任何人能刪除 share，仍然是高風險設計。

• Azure Files 的傳輸與身分：SMB 連線應使用 SMB 3.x 加密能力與安全通道，透過 private endpoint、網路規則與 NSG 限制來源。若採 AD 身分，必須同時設計 share-level permission 與目錄／檔案 ACL；不要把 storage account key 散落在 VM 環境變數或 Git。
• Managed Disks 的靜態加密：Azure Storage Service Encryption（SSE）保護磁碟資料；若法規要求客戶管理金鑰，再以 Key Vault 管理 CMK 的生命週期與輪替。加密不等於授權，仍需限制誰可讀取磁碟、建立快照或變更 encryption set。
• 快照策略：快照適合部署前複製、短期測試與指定時間點還原；要有排程、保留期、應用程式一致性、跨區副本與稽核紀錄，應使用 Azure Backup 或經驗證的備份方案。快照與來源磁碟位於同一故障邊界時，不能把它宣稱成完整 DR。
• 最小權限與刪除防護：將儲存體管理者、掛載者、備份操作者分離；對關鍵資源加 Resource Lock，並以 Azure Policy／RBAC 限制公開端點、未加密磁碟與過寬網路規則。

可用下列防禦順序做設計審查：先封網路，再驗身分；先加密，再分權限；先定義 RPO/RTO，再選快照或備份。若只問「資料有沒有複本」，卻沒有問「誰能刪除複本、複本在哪個 Region、能否在隔離帳戶還原」，復原方案仍是不完整的。

從「能不能跑」到「能不能停、會不會太貴」

借鏡 cxcxc-io/cloud-arch-notes-felo-key1.md 的實務筆記，儲存體設計不能只驗證功能成功，還要同時回答三個問題：能不能跑、能不能停、會不會太貴？ Azure Files 與 Managed Disks 可依下列方式落實這個檢查：

這種「成本防護與故障止血一起做」的思維，不代表把正式資料庫任意關機；而是讓每個非生產資源都有明確的到期時間、責任人與刪除前備份。公開端點也不應成為預設值：能放在私有網路的 file share、磁碟管理與備份控制面，就不要讓它們直接暴露到公網。

雙雲底層抽象：從宣告到實際儲存

┌──────────────────────────────────────────────────────────────┐
│ Azure Bicep / ARM：disk、file share、RBAC                    │
├──────────────────────────────────────────────────────────────┤
│ ARM API：資源、網路與政策評估                                │
├──────────────────────────────────────────────────────────────┤
│ Azure Files / Managed Disk：平台管理實體儲存                 │
└──────────────────────────────────────────────────────────────┘
                              ↕
┌──────────────────────────────────────────────────────────────┐
│ AWS CloudFormation / CDK：EBS、EFS、IAM                      │
├──────────────────────────────────────────────────────────────┤
│ CloudFormation API：資源、網路與政策評估                     │
├──────────────────────────────────────────────────────────────┤
│ EFS / EBS：平台管理實體儲存                                  │
└──────────────────────────────────────────────────────────────┘

IaC 的價值不只是少點幾次 Portal。把檔案共享的網路限制、磁碟加密、診斷設定與標籤寫成可審查的宣告，能避免 Dev、Test、Prod 的 ClickOps 漂移。部署前使用 az deployment group what-if 預覽變更，對照 AWS Change Sets 或 Terraform plan；尤其要留意替換磁碟、變更網路端點與刪除 file share 這類高爆炸半徑操作。帳戶金鑰、密碼與連線字串不可硬編碼，應由 Microsoft Entra ID、Key Vault 或工作負載身分取得。

📖 AZ-900 核心名詞解釋與速查

1. Azure Files（Azure 檔案）
   • 定義：在 Azure Storage account 中提供受控檔案共享的服務，可透過 SMB 或支援的 NFS 版本掛載。
   • AWS 對照：Amazon EFS；兩者都是檔案介面，但協定與網路整合不同。
   • 考點：多台 VM 需要共同讀寫檔案時，優先考慮 Azure Files，而不是 Managed Disk。
2. File share（檔案共用）
   • 定義：Azure Files 中承載目錄與檔案的邏輯共享單位，可設定配額、層級與存取控制。
   • 考點：Storage account 是管理邊界，file share 是應用程式實際掛載與資料組織的單位。
3. Managed Disk（受控磁碟）
   • 定義：由 Azure 管理底層配置的 VM 區塊儲存，供 OS disk 與 data disk 使用。
   • AWS 對照：Amazon EBS。
   • 考點：它通常由一台 VM 使用，不能當成一般多主機檔案共享。
4. IOPS 與吞吐量（Throughput）
   • 定義：IOPS 是每秒 I/O 操作次數；吞吐量是每秒傳輸的資料量，兩者共同描述儲存效能。
   • 考點：小型隨機 I/O 偏向 IOPS；大型循序傳輸偏向吞吐量。
5. Disk snapshot（磁碟快照）
   • 定義：磁碟在某一時間點的複本，可用於複製或還原。
   • 考點：快照不是完整的排程備份與跨區 DR 設計，需搭配 Azure Backup 等方案。

🎮 Part 2：1 小時實戰情境 Role-Play

🏛️ 情境背景：Titan 科技的共享檔案與訂單資料庫

Titan 科技的訂單平台有六台 Windows Web/Report VM。報表產生器會把 PDF 寫入共享目錄，客服人員與批次工作都要讀取同一份檔案；後端 SQL VM 則需要低延遲、可預期的隨機 I/O。實習架構師提出：「所有資料都放進一顆 Premium Managed Disk，再把這顆磁碟掛到六台 VM；為了方便，把 storage account 的金鑰放在 Git repository；備份只在部署時手動做一次快照。」

CTO 問：「這套方案看起來很快，為什麼不能直接上線？請提出既能共享檔案、又能保護資料庫的設計。」

🧩 決策任務

• A. 建立 Azure Files file share 給報表使用；SQL VM 使用獨立 Premium SSD 或 Ultra Disk，資料與 OS 分離；以 Entra ID/Key Vault 管理存取，並用 Azure Backup 設計排程保護。
• B. 把同一顆 Managed Disk 同時附掛到六台 VM，並用 OS 的本機帳號控制檔案權限。
• C. 把全部資料放到 Standard HDD，靠增加 VM CPU 解決儲存延遲；將 storage account 金鑰寫入應用程式設定檔。
• D. 使用 Azure Files，但讓所有用戶端直接透過公用端點與共享金鑰存取，並把單一快照視為跨區災難復原。

🎯 解題拆解與解析

✅ 正解：方案 A

方案 A 先用存取介面分流，再依工作負載選效能。多台 VM 共享目錄需要檔案協定與檔案鎖，因此使用 Azure Files；SQL 的區塊 I/O 則使用獨立 Managed Disk。OS 與資料分離可降低 OS 更新、磁碟滿載或重建對資料的牽連。最後用身分式授權、私有網路、Key Vault 與排程備份收斂資料面和控制面的風險。

❌ 陷阱選項深度剖析

• B 錯在把區塊儲存當檔案共享：Managed Disk 的主要模型是 VM 的區塊裝置，不等於具備分散式檔案鎖與多主機共享語意。即使某些進階功能有特定共享情境，也不能由題目直接推定一般 Windows 檔案共享可用。
• C 錯在效能與機密管理都失守：增加 CPU 不會提高磁碟 IOPS 或吞吐量；把金鑰寫入設定檔則可能透過原始碼、日誌或備份外洩，造成整個 storage account 的資料面淪陷。
• D 錯在網路與復原邊界：Azure Files 不代表必須公開；可用私有端點、網路規則與身分授權縮小攻擊面。單一快照只代表一個時間點，不能取代排程備份、保留策略或跨區復原。

🎯 Part 3：AZ-900 精選高頻真題解析

本節將題目改寫為 Titan 情境；ExamTopics 題號與票數須以 examtopics-az900-search skill 定向覆核，本文不重製原題文字。

📝 AZ-900 高頻真題 1：多台 VM 共享檔案（ExamTopics 題型改編）

題目情境

Titan 需要讓多台 Azure VM 同時存取同一組檔案，並希望使用受控服務而不管理檔案伺服器。應選哪項服務？

• A. Azure Managed Disk
• B. Azure Files
• C. Azure Queue Storage
• D. Azure Table Storage

考點拆解與解析（架構師推理鏈）

1. 關鍵字識別：題幹同時給出「多台 VM」「同一組檔案」與「受控服務」；這是在問共享檔案介面，不是在問容量。
2. 核心考點定位：Azure Files 提供 file share 與 SMB／支援的 NFS 介面；Managed Disk 是 VM 的 block device。
3. 陷阱識破：Queue 是訊息佇列、Table 是 NoSQL 儲存，兩者沒有目錄、檔案鎖或掛載語意。
4. 最佳實踐連結：正式環境仍須補上私有網路、身分式授權、ACL、備份與監控；「服務選對」不代表安全設計自動完成。

• 來源與驗證：改寫自 ExamTopics AZ-900 檔案儲存高頻題型（票數待以 examtopics-az900-search skill 定向覆核）；並經 Microsoft Learn：Azure Files 總覽 交叉驗證。

📝 AZ-900 高頻真題 2：VM 的高 I/O 磁碟（ExamTopics 題型改編）

題目情境

Titan 的資料庫執行個體需要高 IOPS、低延遲的區塊儲存，且不需要多台 VM 共同掛載。哪項設計最符合需求？

• A. Azure Files Standard
• B. Azure Queue Storage
• C. Premium SSD 或符合需求的 Ultra Disk
• D. Azure Blob Archive

考點拆解與解析（架構師推理鏈）

1. 關鍵字識別：資料庫、低延遲、高 IOPS、區塊儲存，而且沒有共享掛載需求。
2. 核心考點定位：Managed Disk 的效能層級要依 IOPS、吞吐量、延遲與 VM 限制選擇。
3. 陷阱識破：Azure Files 是檔案介面；Queue 沒有磁碟語意；Blob Archive 追求低成本封存，不能承載線上交易。
4. 最佳實踐連結：Premium 或 Ultra 只是候選，仍要用基準測試驗證資料庫日誌、資料檔、快取與 VM 磁碟頻寬。

• 來源與驗證：改寫自 ExamTopics AZ-900 Managed Disk 效能選型高頻題型（票數待以 examtopics-az900-search skill 定向覆核）；並經 Microsoft Learn：Azure Managed Disks 交叉驗證。

📝 AZ-900 高頻真題 3：檔案共享與磁碟的服務辨識（ExamTopics 題型改編）

題目情境

請將下列需求配對至 Azure 服務：

1. 多台 VM 透過 SMB 掛載共同目錄。
2. VM 的作業系統需要可開機的區塊磁碟。
3. 長期保存大量非結構化物件。

• A. 1-Azure Files；2-Managed Disk；3-Blob Storage
• B. 1-Managed Disk；2-Azure Files；3-Queue Storage
• C. 1-Blob Storage；2-Queue Storage；3-Managed Disk
• D. 1-Azure SQL；2-Blob Storage；3-Azure Files

考點拆解與解析（架構師推理鏈）

1. 關鍵字識別：SMB 掛載指向檔案；可開機指向 OS disk；非結構化物件指向 Blob。
2. 核心考點定位：AZ-900 常用「同一個 Storage 關鍵字」混淆檔案、區塊與物件三種介面。
3. 陷阱識破：Managed Disk 不能被當成一般共享目錄；Queue 不能承載 Blob；SQL 不是通用檔案服務。
4. 最佳實踐連結：先問應用程式需要哪種 API／協定，再問效能層級；這個順序也適用 AWS EFS、EBS 與 S3 的選型。

• 來源與驗證：改寫自 ExamTopics AZ-900 Azure Storage 服務配對高頻題型（票數待以 examtopics-az900-search skill 定向覆核）；並經 Microsoft Learn：Azure 儲存體服務比較 交叉驗證。

📝 AZ-900 真題 4：磁碟快照與備份邊界（2020 gratisexam 題庫改編）

⚠️ 來源說明：本題改寫自 2020 年 gratisexam AZ-900 題庫（歷史題型改編），屬歷史題庫層，已與 Microsoft Learn 交叉驗證；不把過期服務名稱當成現行答案。

題目情境

Titan 希望在部署前保留 Managed Disk 的某一時間點複本，日後用來建立測試磁碟。應使用哪項功能？

• A. Disk snapshot
• B. Network Security Group
• C. Virtual Network peering
• D. Azure DNS

考點拆解與解析（架構師推理鏈）

1. 關鍵字識別：「部署前」「某一時間點複本」「建立測試磁碟」明確描述 snapshot，而不是網路控制元件。
2. 核心考點定位：Managed Disk snapshot 是時間點複本，可用來建立磁碟或短期還原。
3. 陷阱識破：NSG、Peering、DNS 分別處理流量、網路互連與名稱解析，不能複製區塊資料。
4. 最佳實踐連結：若題目改成排程保留、跨區、應用程式一致性或長期 RPO，答案就不能停在 snapshot，必須評估 Azure Backup。

• 來源與驗證：改寫自 2020 年 gratisexam 題庫磁碟快照題型；並經 Microsoft Learn：Azure Managed Disks 快照 交叉驗證。

📝 AZ-900 真題 5：Windows 檔案共享協定（2020 gratisexam 題庫改編）

⚠️ 來源說明：本題改寫自 2020 年 gratisexam AZ-900 題庫（歷史題型改編），屬歷史題庫層，已與 Microsoft Learn 交叉驗證；題目只保留檔案協定的現行概念。

題目情境

Titan 的 Windows Server 應用程式要把 Azure 上的 file share 掛載為網路磁碟。哪項協定最符合一般 Windows 檔案共享需求？

• A. SMB
• B. SMTP
• C. ICMP
• D. BGP

考點拆解與解析（架構師推理鏈）

1. 關鍵字識別：Windows Server、file share、網路磁碟，直接指向 SMB。
2. 核心考點定位：SMB 提供 Windows 常見的檔案共享語意；NFS 是另一套協定，不能以名稱混用。
3. 陷阱識破：SMTP 是郵件、ICMP 是診斷封包、BGP 是路由交換，均不提供檔案系統介面。
4. 最佳實踐連結：正式掛載還要驗證 TCP 445、DNS、AD／Kerberos、ACL 與私有端點；協定答對只是第一層。

• 來源與驗證：改寫自 2020 年 gratisexam 題庫 Azure Files 協定題型；並經 Microsoft Learn：Azure 檔案共用 SMB 存取 交叉驗證。

💡 AWS SAA-C03 / CLF-C02 概念補充與雙雲考點連動演練

AWS 考題常把「共享檔案」與「單機區塊磁碟」放在同一個情境，再用效能或可用性關鍵字改變答案。Azure 的映射應記住：EFS → Azure Files，EBS → Managed Disks；但驗證協定、網路與 SKU 時，必須回到各平台原生規則。

🎲 AWS 經典情境一：多個可用區的共享內容

題目： 一組 Linux EC2 應用程式分散在多個 Availability Zone，需要同時讀寫同一份 POSIX 風格的共享檔案，且不想維護 NFS server。應選哪項？

• A. 每台 EC2 各自建立 EBS，再用 rsync 維持一致
• B. Amazon EFS，並讓用戶端透過適當的 mount target 存取
• C. S3 Glacier Deep Archive
• D. 每台 EC2 使用 instance store

答案：B。 關鍵字是跨主機共享、檔案語意與受控 NFS；EBS 是附掛到主機的區塊裝置，rsync 會引入衝突與延遲；S3 Glacier 是物件封存；instance store 是主機生命週期綁定的暫存區。

Azure 知識映射： Azure 對應是 Azure Files，但不是把 EFS mount target 原樣搬過去。Linux 來源若依賴 NFS 4.1，需確認 Azure Files NFS 支援條件；若是 Windows SMB 工作負載，應改以 SMB、AD／Kerberos、TCP 445 與 file share ACL 重新設計。

🎲 AWS 經典情境二：資料庫的高 IOPS 區塊儲存

題目： 一台 EC2 上的交易資料庫需要穩定低延遲、可調整 IOPS 的區塊磁碟，資料不需要由多台主機同時掛載。應選哪項？

• A. Amazon EFS
• B. Amazon EBS gp3 或符合需求的 io2
• C. S3 Standard-IA
• D. EFS One Zone

答案：B。 這是區塊 I/O 與 IOPS 選型；EFS 是檔案介面，S3 是物件介面，EFS One Zone 仍然不是資料庫的 block device。最後要以資料庫基準測試、EC2 EBS 頻寬與 RPO/RTO 需求確認 gp3 或 io2。

Azure 知識映射： Azure 對應是 Managed Disks，通常從 Premium SSD、Premium SSD v2 或 Ultra Disk 評估。不要把 Premium SSD 的名稱當成 io2 的保證；需檢查區域、VM 大小、IOPS、吞吐量、快取與加密設定，並以 Azure Backup／快照策略處理復原。

雙雲考場口訣： EFS / Files = 檔案協定與共享目錄；EBS / Managed Disks = VM 可見的區塊裝置。題幹出現 mount target、NFS、跨主機共享，先走檔案路徑；出現 OS disk、database、IOPS、throughput，先走區塊路徑。

📐 Part 4：以戰代訓課程對照

🚀 今日總結與明日預告

🏆 今日 3 點速記

1. 先判斷介面：多台 VM 共同讀寫目錄選 Azure Files；VM 的 OS、資料庫與區塊 I/O 選 Managed Disks；物件資料則回到 Day 15 的 Blob Storage。
2. 再判斷效能：HDD/Standard SSD/Premium SSD/Ultra Disk 不是單純的快慢排名，要依 IOPS、吞吐量、延遲、VM 上限與區域支援共同選擇。
3. 最後收斂風險：OS 與資料分離、私有端點與身分授權、Key Vault、快照加上排程備份，才能同時降低組態漂移、機密外洩與資料遺失的爆炸半徑。

🔮 明日預告：Day 17 Azure Storage Explorer & AzCopy

儲存體建好了，資料如何安全且有效率地搬進去？明天 Titan 科技將進入資料遷移戰：比較 Azure Storage Explorer 的圖形化操作與 AzCopy 的命令列批次傳輸，並延伸 Azure Migrate、Data Box 與混合雲搬遷策略。