Day 10 的 EBS 是「一顆硬碟給一台機器用」，而且一次只能掛給同一個 AZ 的一台 instance。好幾台 EC2 instance 需要同時讀寫同一份資料時，EBS 就不夠用了。EFS（Elastic File System） 是為這種情境設計的服務：一份檔案系統，讓多台 EC2 instance 跨 AZ 同時掛載、並行讀寫，走的是 NFS 協定，用起來就像一般的檔案目錄。
| EBS | EFS | |
|---|---|---|
| 儲存型態 | 區塊儲存 | 檔案系統（NFS） |
| 能掛給誰 | 一台 instance（同 AZ） | 多台 instance，可跨 AZ 同時掛載 |
| 容量 | 建立時指定，要自己調整 | 隨實際用量自動增減 |
| 計費 | 依 provision 的容量 | 依實際用量 |
| 適合情境 | 資料庫、開機碟這種單機獨佔的資料 | 多台機器要共用同一份資料的場景（內容管理、算圖素材） |
判斷依據：這份資料只有一台機器要用，還是好幾台機器要同時讀寫同一份？ 前者 EBS，後者 EFS。就算只有一台機器在用，若是高 IOPS、低延遲的隨機讀寫（例如資料庫），適合的仍是 EBS——EFS 是為多用戶端共享設計的網路檔案系統，單一用戶端的 IOPS 與延遲表現本來就不是它的強項。
開頭那張圖右半邊，EC2 和 EFS 中間都隔著一個 mount target。
目的：EFS 是 VPC 外部的受管服務，本身不具備 VPC 內部的網路位址；EC2 的路由與 Security Group 規則，作用範圍都限定在 VPC 位址空間內的資源上。因此 EFS 需要在 VPC 內建立一個實際的網路介面，EC2 才能透過標準的 VPC 路由連接過去，這個介面就是 mount target。
位置與組成：mount target 是放在 subnet 裡的一個網路介面，有自己的 private IP（例如 10.0.0.50）；進出由 Security Group 控制（Day 6），inbound 要放行 NFS 使用的 TCP 2049，EC2 才連得進去。
每個 AZ 各建一個的原因：mount target 按 AZ 建立，EC2 一律連到自己所在 AZ 的 mount target，路徑不跨 AZ，延遲較低；某個 AZ 的 mount target 若發生問題，也不影響其他 AZ 的 instance 存取。
掛載路徑：
EC2（AZ-a） → AZ-a 的 mount target（10.0.0.50） → EFS 檔案系統
EC2（AZ-b） → AZ-b 的 mount target（10.0.1.50） → 同一個 EFS 檔案系統
EC2 從自己所在 AZ 的 mount target 進去，所以每個有 EC2 要用 EFS 的 AZ 都各建一個。資料不存在 mount target 上，它只是入口；資料由 EFS 自己跨 AZ 存放，兩條路徑最後到的是同一份目錄——AZ-a 寫入的檔案，AZ-b 讀得到。
EFS 走 NFS 協定，只支援 Linux；Windows 的共用檔案系統是 FSx for Windows，後面 FSx 一節會提到。
EFS 有兩種效能模式，只能在建立檔案系統的當下選擇，建好之後無法直接切換：
| 模式 | 特色 | 適合情境 |
|---|---|---|
| General Purpose（預設） | 單次操作延遲最低 | 絕大多數場景，官方建議優先選這個 |
| Max I/O | 犧牲一點單次操作延遲，換取更高的整體並行吞吐與每秒操作數上限 | 幾百台機器同時猛烈平行讀寫，逼近 General Purpose 的每秒操作數上限時 |
要換效能模式，只能建一個新的 EFS 檔案系統、把資料搬過去，再讓 instance 改掛新的——跟 EBS 的 Elastic Volumes「線上直接調」是完全不同的兩種彈性。
效能模式管的是「每秒能處理幾次操作」，吞吐量模式管的是「每秒能搬多少 MB」，兩者是分開的兩件事：
| 模式 | 做法 | 什麼時候用 |
|---|---|---|
| Bursting（預設） | 吞吐量額度跟儲存容量綁在一起，用 burst credit 支撐尖峰 | 容量夠大、流量平穩的檔案系統；小檔案系統容易撞到額度上限 |
| Provisioned | 自己指定一個固定吞吐量，跟容量脫鉤 | 流量穩定、可預測，想要比 Bursting 更高的保底吞吐量 |
| Elastic | 自動依實際流量調整吞吐量，不用預先設定或估算 | 流量忽高忽低、難預測，不想自己算該設多少 |
Bursting 模式如果 burst credit 用完，吞吐量會直接被打回基準值——這是批次工作「跑到一半突然變慢」最常見的原因。吞吐量模式可以事後切換（跟效能模式不一樣），大約每 24 小時能改一次。
EFS 只服務 Linux（NFS），遇到 Windows 或高效能運算，AWS 另外準備了 FSx：
| FSx for Windows File Server | FSx for Lustre | |
|---|---|---|
| 協定 | SMB | Lustre 高效能平行檔案系統 |
| 整合 | 能接 Active Directory，原生支援 Windows 的權限與功能（ACL、陰影複製） | 可以直接連結 S3 bucket 當資料來源，讀寫結果也能寫回 S3 |
| 適合情境 | Windows 應用程式要共用檔案、需要 AD 權限控管 | HPC、機器學習訓練，對存在 S3 的巨量資料集要極高吞吐量、低延遲的平行讀取 |
Linux 共用檔案選 EFS，Windows 選 FSx for Windows，HPC／機器學習訓練選 FSx for Lustre——三者服務的協定和情境完全不重疊，不是同一個東西的三種選項。
| 主題 | 說明 |
|---|---|
| EFS 儲存類別 | 也有 Standard／IA 之分，可以設定生命週期規則把不常存取的檔案自動轉到 EFS-IA 省錢；還有 One Zone／One Zone-IA，只存在一個 AZ，邏輯跟 S3 One Zone-IA 一樣——便宜、但要接受沒有跨 AZ 容錯 |
| EFS 加密 | 靜態加密建立時決定（用 KMS），傳輸加密則是掛載時用 TLS，兩者是分開的設定 |
| Multi-Attach 撞牆時的另一個選擇 | EBS Multi-Attach 只能同一個 AZ、最多 16 台，而且要應用層自己處理寫入衝突；真的需要跨 AZ、多台機器共用同一份資料時，EFS 是更直接的答案 |
| 概念 | 說明 |
|---|---|
| EFS | 檔案系統，多台 Linux instance 跨 AZ 同時掛載，容量隨用量自動調整 |
| Mount target | 每個 AZ 一個，帶 private IP，該 AZ 的 instance 從這裡掛進去 |
| 效能模式 | General Purpose（預設）vs Max I/O，建立時決定、事後不能切換 |
| 吞吐量模式 | Bursting（跟容量綁）／Provisioned（自己指定）／Elastic（自動跟流量走），可以事後切換 |
| FSx for Windows | SMB 協定、能接 Active Directory，給 Windows 用 |
| FSx for Lustre | 高吞吐量低延遲平行存取，能連 S3，給 HPC／機器學習用 |
這天的核心：一台機器獨佔用 EBS，多台機器共用同一份資料用 EFS——Linux 選 EFS，Windows 選 FSx for Windows，HPC／機器學習訓練選 FSx for Lustre，三者互不重疊。
某公司開發一套內容管理系統，前端有多台 EC2 instance 分散在兩個 AZ，這些 instance 都需要能同時讀寫同一份使用者上傳的檔案目錄，且未來機器數量會隨流量彈性增減。工程師原本嘗試把一顆 EBS volume 設定 Multi-Attach 掛給兩個 AZ 的 instance，結果第二個 AZ 的 instance 掛載失敗。
解決方案架構師應該如何修正這個架構？
A. 保留 EBS Multi-Attach，但把所有 instance 都遷移到同一個 AZ，讓 Multi-Attach 的條件成立
B. 改用 io1 volume 並在啟動時指定跨 AZ 的掛載參數，讓 Multi-Attach 支援跨 AZ 掛載
C. 為每個 AZ 各自建立一顆獨立的 EBS volume，並在應用程式層加上一套自訂的雙向同步機制，讓兩顆 volume 保持內容一致
D. 改用 Amazon EFS，在兩個 AZ 各自建立 mount target，讓兩個 AZ 的 instance 都掛載同一個檔案系統
某公司要把一套自行管理的線上交易資料庫遷移到 AWS，這套資料庫只會被一台 EC2 instance 存取，工作負載是大量隨機讀寫、要求極低延遲與高 IOPS。一位工程師建議直接把資料庫的資料目錄放在一個掛載給這台 instance 的 Amazon EFS 檔案系統上，理由是「以後要擴充到多台機器時比較方便」。
解決方案架構師應該如何評估這個建議？
A. 同意這個建議，因為 EFS 支援多台 instance 同時掛載，未來擴充時不需要更改儲存架構
B. 不建議，這種單機、高 IOPS、低延遲隨機讀寫的工作負載更適合用 io2 這類 EBS volume；EFS 是共用檔案系統，延遲與單一用戶端的 IOPS 表現都不是為這種資料庫工作負載設計的，真的要擴充到多機時再評估是否需要改架構
C. 不建議，應該改用 Amazon S3 存放資料庫檔案，S3 的耐用度比 EFS 高，更適合正式環境資料庫
D. 同意這個建議，並額外建議開啟 EFS 的 Max I/O 效能模式，以取得跟 io2 volume 相當的單一操作延遲
某公司在一個既有的 EFS 檔案系統上運行一套影像處理服務，數百個 EC2 instance 會同時對這個檔案系統發出大量平行讀寫請求，目前使用預設的 General Purpose 效能模式。監控顯示，在請求並行量很高的尖峰時段，每秒操作數（Operations per second）逼近該效能模式的上限，開始出現延遲上升與請求被節流的情況。
解決方案架構師應該建議哪一個做法？
A. 直接在這個既有的 EFS 檔案系統上，把效能模式從 General Purpose 改成 Max I/O，讓它能承受更高的整體並行量
B. 建立一個效能模式為 Max I/O 的新 EFS 檔案系統，將既有資料搬移過去，並讓所有 instance 改掛載新的檔案系統
C. 為這個檔案系統啟用 Provisioned Throughput 模式，並調高吞吐量設定，藉此提升每秒可處理的操作數上限
D. 將這個 EFS 檔案系統升級為 Multi-AZ 部署，讓請求可以分散到多個 AZ 的 mount target 處理，藉此提高整體並行量
某公司的 EFS 檔案系統平常吞吐量很低，但每天凌晨會有一個批次工作在很短時間內對這個檔案系統做大量讀寫，吞吐量需求是平常的數十倍，工作結束後又立刻降回平常水準。公司使用預設的 Bursting Throughput 模式，最近開始出現批次工作執行到一半吞吐量驟降、工作時間被拉長的狀況，原因是 burst credit 額度被用完。公司希望在不用自己預估或手動調整吞吐量數字的前提下解決這個問題。
解決方案架構師應該建議哪一個做法？
A. 把吞吐量模式改成 Provisioned Throughput，並自行估算批次工作尖峰所需的吞吐量，手動設定一個固定值
B. 把吞吐量模式改成 Elastic Throughput，讓 EFS 依實際流量自動提供對應的吞吐量，不需要預先設定或手動調整數字
C. 維持 Bursting Throughput 模式，改成在批次工作開始前，先對檔案系統寫入大量暫存資料，藉此換取更多 burst credit
D. 把 EFS 的儲存類別改成 One Zone，藉此提高 burst credit 的累積速度，讓批次工作有更充足的額度可用
某公司有兩個獨立的需求：第一，一套內部行政系統跑在 Windows Server 上，需要一個支援 SMB 協定、能整合現有 Active Directory 網域做權限控管的共用檔案儲存；第二，一組機器學習訓練叢集需要對存放在 S3 的巨量訓練資料集，以極高吞吐量、低延遲的方式重複進行平行讀取。
解決方案架構師應該分別建議哪一種受管檔案系統？（選擇兩項）
A. 行政系統選用 Amazon FSx for Windows File Server，可以整合 Active Directory 並支援 SMB 協定
B. 行政系統選用 Amazon EFS，搭配 Windows 版的 NFS 用戶端存取
C. 機器學習訓練選用 Amazon FSx for Lustre，可以連結 S3 作為資料來源，提供高吞吐量、低延遲的平行存取
D. 機器學習訓練選用 Amazon FSx for Windows File Server 的 Multi-AZ 部署，取得足夠的吞吐量
E. 行政系統與機器學習訓練都選用同一個 Amazon EFS 檔案系統，並開啟 Max I/O 效能模式因應兩種不同的存取模式
EFS 是跨 AZ 的檔案系統，在每個 AZ 各建一個 mount target 後，不同 AZ 的 instance 就能同時掛載並讀寫同一份資料，而且容量會隨用量自動增減，天然符合「多台機器、跨 AZ、彈性增減」的需求。
A 為了遷就 Multi-Attach 的同 AZ 限制，把所有 instance 都塞進同一個 AZ，等於放棄了跨 AZ 的高可用與流量分散能力。B 是誤解：Multi-Attach 就是被設計成只能在同一個 AZ 內運作，沒有能讓它跨 AZ 掛載的參數或設定。C 技術上做得到，但要自己開發並維護一套跨 volume 的雙向同步機制，維運負擔遠高於直接用 EFS 原生就提供的跨 AZ 共用能力。
EFS 是為多用戶端共享檔案存取設計的網路檔案系統，即使只掛給一台 instance，單一用戶端的 IOPS 與延遲表現也比不上專門為單機、高 IOPS、低延遲設計的 io2 volume；「以後可能要擴充」不是現在就該犧牲效能的理由，等真的需要多機共用同一份資料時，再評估是否要換架構會更務實。
A 誤解了需求的優先順序：目前的工作負載明確要求低延遲、高 IOPS，不該為了「未來可能的擴充」犧牲現在的效能。C 是誤解：S3 是物件儲存，物件不支援局部修改，不能像檔案系統一樣被 EC2 掛載後直接當資料庫的資料目錄用。D 也是誤解：Max I/O 犧牲的正是單次操作延遲以換取更高的整體並行量，方向與「低延遲」的需求相反，而且 Max I/O 也不會讓 EFS 的單次操作延遲追上 io2。
EFS 的效能模式（General Purpose／Max I/O）只能在建立檔案系統的當下選擇，建好之後無法直接切換；要換成 Max I/O，必須新建一個指定 Max I/O 的檔案系統，把資料搬過去，再讓 instance 改掛載新的檔案系統。Max I/O 犧牲一點單次操作延遲，換取更高的整體並行吞吐與每秒操作數，適合這種數百台機器同時平行讀寫的情境。
A 是誤解：效能模式是建立時就固定的屬性，沒有「直接在既有檔案系統上切換」這個選項。C 誤解了瓶頸來源：吞吐量模式（Bursting／Provisioned／Elastic）調的是資料搬運的頻寬（MB/s），題目描述的瓶頸是「每秒操作數」逼近上限，這是效能模式在管的事，調高吞吐量設定解決不了操作數的天花板。D 也是誤解：EFS 本來就是跨多個 AZ 存取的服務（在每個 AZ 建 mount target），題目沒有「還沒跨 AZ」這個前提，掛載到多個 AZ 的 mount target 也不會改變單一檔案系統的效能模式上限。
Elastic Throughput 會依實際流量自動提供對應的吞吐量，流量忽高忽低、難以預先估算時最適合，不需要手動設定固定的吞吐量數字，也不會有 burst credit 用完被節流的問題。
A 技術上可行，但要自己估算並手動設定固定吞吐量，不符合「不用自己預估或手動調整」的要求，而且批次尖峰之外的平常時段也會為這個固定值持續付費，不夠有效率。C 是誤解：burst credit 是依檔案系統儲存容量累積的，寫入更多暫存資料只會佔用容量，不會有意義地換到「更多可用的尖峰吞吐量」，而且這種做法本身也違反了題目「不用手動調整」的精神。D 也是誤解：burst credit 的累積速度跟儲存類別（Standard 或 One Zone）無關，One Zone 差的是可用區數量與價格，不影響 Bursting Throughput 的額度機制。
FSx for Windows File Server 原生支援 SMB 協定並能整合 Active Directory 網域，正好對應 Windows 系統的檔案共享與權限需求；FSx for Lustre 是為高效能運算、機器學習這類需要極高吞吐量與低延遲平行存取設計的檔案系統，且能直接連結 S3 bucket 當資料來源，不用先手動搬資料進來。
B 是誤解：EFS 走的是 NFS 協定，不支援 SMB，Windows 也沒有原生的 NFS 用戶端能直接當作正常的共用磁碟機使用，Windows 環境的共用檔案系統應該選 FSx for Windows。D 用錯服務：FSx for Windows File Server 是為 Windows SMB 工作負載設計的，不是為機器學習訓練的高吞吐量平行讀取設計，這種需求要用 FSx for Lustre。E 忽略了兩種需求分別需要不同協定（SMB vs 高效能平行存取）與不同的受管服務，EFS 也不支援 SMB，單一 EFS 檔案系統無法同時滿足這兩種需求。
iThome鐵人賽
看影片追技術