examhub .cc 用最有效率的方法,考取最有價值的認證
Vol. I
本篇導覽 約 31 分鐘

高效能與可擴展儲存解決方案

6,100 字 · 約 31 分鐘閱讀

選擇高效能可擴展儲存解決方案,是 SAA-C03 第三領域中配分最重的單一任務陳述,也是大多數考生最容易失分的地方。考題不會問「什麼是 S3」,而是問諸如「哪種可擴展儲存解決方案組合能在基因組學 pipeline 中達成 200 GB/s 的吞吐量,同時將工作集從 S3 暫存」,或是「挑選一個可擴展儲存解決方案架構,讓 5,000 台 EC2 執行個體跨三個 AZ、以毫秒以下的延遲共用同一個 POSIX 檔案系統」。你必須對可擴展儲存解決方案的全局矩陣瞭若指掌:Amazon S3、Amazon EBS、Amazon EFS、四種 Amazon FSx 版本,以及 AWS Storage Gateway,再加上能把正確答案從好答案中篩出的效能調節器(IOPS、吞吐量、延遲、通訊協定、並行存取)。

本學習筆記帶你走過完整的可擴展儲存解決方案產品組合,並刻意重複核心關鍵字(可擴展儲存解決方案、S3 storage classes、S3 Intelligent-Tiering、EBS volume types、EFS performance modes、FSx for Lustre),讓你在讀完任何一道 SAA-C03 情境題的題幹後,能在二十秒內找出正確答案。讀完本篇,你將建立一套在真實考試壓力下都能穩定運作的心智模型。

AWS 可擴展儲存解決方案是什麼?

AWS 上的可擴展儲存解決方案,是指容量、吞吐量、IOPS 與並行用戶端數量可以獨立於底層運算資源擴展的受管儲存服務——你不需要碰任何磁碟或檔案伺服器。可擴展儲存解決方案的產品組合涵蓋五大類:

  • EB 級物件儲存 — Amazon S3,具備七種 S3 storage classes、multipart upload、Transfer Acceleration 與 versioning。
  • 每台 EC2 執行個體的區塊儲存 — Amazon EBS,提供六種 volume types,涵蓋 SSD(gp3、gp2、io2 Block Express、io1)與 HDD(st1、sc1)。
  • 多用戶端共享檔案儲存 — Amazon EFS,供 NFSv4.1 Linux 工作負載使用,具備 Bursting/Provisioned/Elastic 吞吐量模式與 General Purpose/Max I/O 效能模式。
  • 受管專用檔案系統 — Amazon FSx for Windows File Server(SMB/NTFS/AD)、Amazon FSx for Lustre(HPC)、Amazon FSx for NetApp ONTAP,以及 Amazon FSx for OpenZFS。
  • 混合儲存橋接 — AWS Storage Gateway,提供 File、Volume 與 Tape 三種模式。

所有可擴展儲存解決方案共享五項特質,你應將其視為公理:AWS 管理硬體、耐久性內建、範圍依服務分為 AZ 層級或 Region 層級、按用量計費,且靜態加密可透過 AWS KMS 啟用。SAA-C03 相較於 CLF-C02 的關鍵差異在於:架構取捨(IOPS 與吞吐量、AZ 範圍與 Region 範圍、通訊協定、並行性)才是重點,而非單純識別服務。

AWS 上的可擴展儲存解決方案是指物件(S3)、區塊(EBS)與檔案(EFS、FSx)服務,其容量與效能無需操作者介入即可擴展。物件 = HTTPS API,無需掛載。區塊 = 單一 AZ,單一 EC2 連接。檔案 = 多用戶端,每個 AZ 一個掛載目標。把這個分類燒進記憶中——每一道 SAA-C03 可擴展儲存解決方案題都圍繞著它轉。

可擴展儲存解決方案分類概覽

範式 AWS 服務 存取單位 通訊協定 並行性 SAA-C03 典型考點
物件 Amazon S3 物件(key + body + metadata) HTTPS REST 數千 資料湖、靜態資產、歸檔
區塊 Amazon EBS 512B–4 KiB 區塊 區塊裝置至 EC2 1 台 EC2(或 Multi-Attach 叢集) 資料庫、開機磁碟區
檔案(Linux) Amazon EFS 檔案與資料夾 NFSv4.1 數千台 EC2/地端主機 共享 POSIX、網站層內容
檔案(Windows) Amazon FSx for Windows File Server 檔案與資料夾 SMB 2/3、NTFS 數千 AD 整合 SMB 共享
檔案(HPC) Amazon FSx for Lustre 檔案與資料夾 Lustre/POSIX 數千 ML 訓練、基因組學、CFD
檔案(NetApp) Amazon FSx for NetApp ONTAP 檔案與區塊 NFS、SMB、iSCSI 數千 企業 NetApp 直接遷移
檔案(ZFS) Amazon FSx for OpenZFS 檔案與資料夾 NFSv3/v4.1 數千 Linux ZFS 快照/複製
混合 AWS Storage Gateway 檔案、區塊、虛擬磁帶 NFS、SMB、iSCSI、iSCSI-VTL 多台地端主機 磁帶替換、地端快取

白話文解釋可擴展儲存解決方案

類比一:圖書館(物件儲存 = Amazon S3)

把 Amazon S3 想像成一座龐大的公共圖書館。每本書就是一個物件,書背上的條碼就是 S3 key(s3://bucket/2026/report.pdf)。你永遠不會自己走進書庫——你透過服務台(S3 HTTPS API)請館員幫你取書或幫你收書。這座圖書館設有不同溫度的區域,從明亮的閱覽室(S3 Standard)到冷凍地下室(Glacier Deep Archive);館員可以按照排程自動把書搬到不同區域(lifecycle rules),也可以根據讀者借閱頻率持續調整書的擺放位置(S3 Intelligent-Tiering)。一本重達五 TB 的百科全書無法一次搬過來,所以你把它拆成章節一章一章地遞給館員(multipart upload)。若讀者在遠方,有一個離他更近的衛星收件站(Transfer Acceleration,透過 CloudFront 邊緣節點)。重點是:你只能透過服務台與這種可擴展儲存解決方案互動,你無法把 USB 線插進圖書館。

類比二:工作台抽屜(區塊儲存 = Amazon EBS)

Amazon EBS 就像是鎖在某個特定工作台下方的抽屜(單一 AZ 中的某台 EC2 執行個體)。只有那台工作台的主人可以使用那個抽屜。你根據工作性質選擇抽屜材質:塑膠適合冷冰冰的低頻存取(sc1),鋼材適合日常工作(gp3),要應付最嚴苛精密任務就選航太級鈦合金超大容量(io2 Block Express)。你可以隨時對抽屜內容拍一張快照(EBS snapshot),把快照存進圖書館(背後的 S3),然後把快照寄到另一棟大樓並在那裡重建抽屜(跨 Region 快照複製)。但你無法把抽屜本身搬到另一棟大樓的另一台工作台——它是鎖死在一個 AZ 的。若兩個人需要同時存取相同的檔案,抽屜就是錯誤答案。這時應該改用共享的檔案儲存櫃。

類比三:辦公室共享文件櫃(檔案儲存 = Amazon EFS 與 Amazon FSx)

共享文件櫃放在走廊上,所有人都可以同時打開它。Amazon EFS 是 Linux 樓層的文件櫃——大家用 NFS 鑰匙。Amazon FSx for Windows File Server 是 Windows 樓層的文件櫃——SMB 鑰匙、Active Directory 身份登入。Amazon FSx for Lustre 是 HPC 實驗室裡的高速文件櫃——專業人員每秒存取數百萬個檔案;文件櫃直接從圖書館(S3 連結)拉取目錄,處理完再把結果還回去。Amazon FSx for NetApp ONTAP 是財務部從舊 NetApp 辦公室搬來的文件櫃——SnapMirror、SnapVault、FlexClone 全部照用。Amazon FSx for OpenZFS 是 Linux 文件櫃,配備 ZFS 工程師最愛的即時複製功能。所有文件櫃的共同原則:根據誰需要讀取(通訊協定 + 作業系統)以及需要多快(吞吐量 + 延遲)來選擇正確的文件櫃。

類比四:物流中轉站(混合儲存 = AWS Storage Gateway)

如果你的辦公室還在地端,但想遠端使用圖書館,你就在地下室設一個本地收件站(Storage Gateway 設備)。同仁把文件交給收件站,就跟以前的收發室一樣(NFS/SMB/iSCSI/磁帶),一輛卡車每晚悄悄地把所有東西送到雲端圖書館。收件站也會在本地快取最常用的東西,讓大家不必等卡車回程。共有四種收件站模式:File Gateway(最終成為 S3 物件的文件)、FSx File Gateway(FSx for Windows 的快取)、Volume Gateway(iSCSI 虛擬硬碟,由 S3 備份並快照為 EBS snapshots),以及 Tape Gateway(虛擬磁帶機器人,讓舊備份軟體完全不知道自己在與雲端溝通)。

可擴展儲存解決方案的核心法則:依序回答三個問題——(1)存取單位是什麼(物件/區塊/檔案/虛擬磁帶)?(2)哪些主體需要同時讀寫(單一 EC2、多台 EC2、地端、全球)?(3)你需要什麼效能範圍(延遲、IOPS、吞吐量、通訊協定)?正確的可擴展儲存解決方案服務自然就會浮出來。

AWS 可擴展儲存解決方案的核心運作原則

每項 AWS 可擴展儲存解決方案服務都共享相同的運作基因:

  1. 受管生命週期 — AWS 負責佈建、複寫、修補與容量擴展。你管理資料、IAM 政策、加密金鑰與 lifecycle rules。
  2. 耐久性優先 — S3 提供 99.999999999%(11 個九)的物件耐久性;EBS 在一個 AZ 內複寫;EFS 跨 AZ 複寫(Standard)或在單一 AZ 內複寫(One Zone);FSx 根據你選擇的部署類型複寫。
  3. 範圍明確 — S3 = Region。EBS = 單一 AZ。EFS = Region(每個 AZ 設掛載目標)或單一 AZ(EFS One Zone)。FSx = 單一 AZ 或 Multi-AZ,取決於部署方式。Storage Gateway = 地端搭配雲端後端。
  4. 按用量計費 — 依儲存容量、請求次數、資料傳輸量計費,有時還有取回費用(Glacier)或已佈建吞吐量費用(EFS、FSx)。
  5. 加密與存取控制 — SSE-S3、SSE-KMS、SSE-C、用戶端加密、EBS KMS 加密、EFS 加密(靜態與傳輸中,透過 TLS/stunnel)、FSx KMS 加密。
範圍是第一個效能調節器,不只是安全考量。EBS 的範圍是單一 AZ,因此不同 AZ 的兩台 EC2 執行個體無法共用同一個 EBS volume——單憑這一點,EBS 就在所有「共享資料」情境中被排除在外。EFS 每個 AZ 都有掛載目標,因此可以橫向跨 AZ 擴展;FSx Multi-AZ 同樣能在一個 AZ 故障後繼續運作,而 FSx Single-AZ 則不行。永遠先閱讀 AZ 與 Region 的限制條件。

Amazon S3 — 網際網路規模的物件儲存

Amazon S3 是 SAA-C03 中任何提到「物件」、「資料湖」、「靜態網站」、「備份」或「歸檔」的可擴展儲存解決方案問題的預設答案。你把物件(每個最大 5 TB)放進全球唯一命名的儲存貯體;S3 資料平面每個前綴每秒可處理 3,500 次 PUT/COPY/POST/DELETE 與 5,500 次 GET/HEAD 請求,無需任何佈建。S3 耐久性為 11 個九;S3 Standard 可用性為 99.99%。

SAA-C03 必知的 Amazon S3 關鍵事實

  • 物件大小:最大 5 TB。單次 PUT:最大 5 GB。超過約 100 MB 的物件應使用 multipart upload。
  • 請求擴展:每個前綴每秒可處理數千次請求,透過使用多個前綴水平擴展。
  • 耐久性:跨至少 3 個 AZ 達到 11 個九(One Zone 類別除外)。
  • 儲存貯體名稱全球唯一;物件屬於 Region 層級。
  • 存取方式:HTTPS API、主控台、CLI、SDK——永遠無法掛載為區塊裝置。
  • 所有操作皆具備強一致的寫後讀一致性(自 2020 年 12 月起)。

S3 Multipart Upload — 考試最愛的效能調節器

Multipart upload 將單一大型物件拆分為多個分段(每段 5 MB 至 5 GB,最多 10,000 段)並行上傳。優點:

  • 吞吐量隨並行上傳的分段數量線性提升——單台 EC2 執行個體就能輕易達到 10+ Gbps。
  • 可恢復性 — 若某段失敗,只需重試該段,而非重新上傳整個 2 TB 物件。
  • 超過 5 GB 的物件必須使用此方式。

操作建議:

  • 使用 lifecycle rules 在 N 天後中止未完成的 multipart upload,避免為孤立的分段付費。
  • 當上傳者距離儲存貯體所在 Region 較遠時,搭配 Transfer Acceleration 使用 multipart upload。

S3 Transfer Acceleration

S3 Transfer Acceleration 透過最近的 CloudFront 邊緣節點,經由 AWS 最佳化骨幹網路將上傳路由至目標儲存貯體。使用場景:

  • 從遠端辦公室上傳資料至另一個遙遠 Region 的儲存貯體。
  • 多地區的使用者上傳至同一個集中儲存貯體。
  • 最後一哩網際網路是瓶頸的大型物件上傳。

此功能按儲存貯體啟用,每 GB 額外收費,當上傳者與儲存貯體位於同一 Region 時沒有效果。若 S3 Transfer Acceleration 速度比較工具顯示無效益,AWS 不會收取附加費用。

S3 Byte-Range Fetch

對稱的下載最佳化:使用 Range 標頭並行 GET 物件的特定位元組範圍。FSx for Lustre、Athena 以及許多 SDK 內部都使用此方式。考試考點:「如何從 S3 更快地下載單一大型物件?」→ 並行 byte-range fetch。

Multipart upload、byte-range fetch、Transfer Acceleration 與多前綴,是四個 S3 效能調節器。對於 Amazon S3 上的寫入密集可擴展儲存解決方案,結合 multipart upload 與分片 key 前綴。對於大型物件的讀取密集工作負載,使用 byte-range fetch。對於全球分散的上傳者,加入 Transfer Acceleration。在考試情境中提到這些,正確的 S3 調節器通常就在這四者之中。

S3 Versioning

Versioning 保留儲存貯體中每個物件的每一個版本。一旦啟用,你只能暫停它——無法完全停用。使用 versioning 的場景:

  • 防止意外覆寫與刪除。
  • 啟用 Cross-Region Replication 與 Same-Region Replication(兩者皆需要 versioning)。
  • 驅動 S3 Object Lock 合規工作流程(WORM + versioning)。

費用注意:每個版本都會儲存完整的物件副本並計入帳單。搭配 lifecycle rule,將非當前版本轉移至較冷的儲存類別,並在 N 天後到期刪除。

S3 Storage Classes 與 S3 Intelligent-Tiering

共有七種 S3 storage classes。將它們記成效能與成本的階梯,每種附上一句話描述:

  1. S3 Standard — 頻繁存取,毫秒延遲,99.99% 可用性,無最短儲存期限。
  2. S3 Intelligent-Tiering — 根據存取模式自動在 Frequent/Infrequent/Archive Instant/Archive Access/Deep Archive Access 等層級間移動物件。即時層無取回費用。每個物件每月收取少量監控費用。
  3. S3 Standard-IA — 每月存取一次的資料,99.9% 可用性,每 GB 取回費用,30 天最短儲存期,128 KB 最低計費大小。
  4. S3 One Zone-IA — 與 Standard-IA 相同,但為單一 AZ 儲存。便宜 20%,99.5% 可用性。僅適用於可重新產生的資料。
  5. S3 Glacier Instant Retrieval — 每季存取一次的歸檔類別,毫秒級取回;90 天最短儲存期。
  6. S3 Glacier Flexible Retrieval — 分鐘至小時級取回(Expedited 1–5 分鐘、Standard 3–5 小時、Bulk 5–12 小時);90 天最短儲存期。
  7. S3 Glacier Deep Archive — 12–48 小時取回,最低成本類別,180 天最短儲存期。適用於 7–10 年合規歸檔。

S3 Storage Classes 效能速查表

S3 Storage Class 首位元組延遲 最短儲存期 SAA-C03 典型選擇
S3 Standard 毫秒 預設熱資料、資料湖基礎層
S3 Intelligent-Tiering 毫秒至小時(最低層) 未知或變動的存取模式
S3 Standard-IA 毫秒 30 天 每月備份取回、DR 資料
S3 One Zone-IA 毫秒 30 天 次要副本、易於重建的資料
S3 Glacier Instant 毫秒 90 天 每季合規查詢
S3 Glacier Flexible 分鐘至小時 90 天 長尾備份
S3 Glacier Deep Archive 12–48 小時 180 天 七年財務或醫療歸檔

S3 Intelligent-Tiering 深度解析

S3 Intelligent-Tiering 是 SAA-C03 中在情境包含「未知存取模式」、「變動的存取模式」或「不想維護 lifecycle rules」時,被問到最多次的 S3 storage classes 答案。此服務根據實際存取情況,將每個物件跨五個存取層移動:

  • Frequent Access 層(預設,類似 Standard)
  • Infrequent Access 層(30 天未存取)
  • Archive Instant Access 層(90 天未存取)
  • Archive Access 層(選擇性啟用;90 天以上未存取,分鐘至小時取回)
  • Deep Archive Access 層(選擇性啟用;180 天以上未存取,12 小時取回)

自動管理的層級無取回費用;每個物件每月收取少量監控費用(僅限超過 128 KB 的物件)。當存取行為無法預測、人工無法撰寫可靠的 lifecycle rule 時,使用 Intelligent-Tiering。

S3 Intelligent-Tiering 與 S3 Standard-IA 都帶有「IA」字樣,但解決的是不同問題。Standard-IA 要求你了解存取模式(每季取回,30 天最短期限,每 GB 取回費用)——如果你猜對了,它比較便宜。Intelligent-Tiering 消除了預測問題,收取少量監控費用,且自動管理層級無取回費用。如果題目說「未知存取模式」,答案是 Intelligent-Tiering。如果題目說「每月存取,30 天最短期限沒問題」,答案是 Standard-IA。

用於成本與效能的 Lifecycle Policies

Lifecycle policies 每日執行,將物件跨 S3 storage classes 移動或到期刪除。僅附加記錄資料的典型資料分層鏈:

Day 0    → S3 Standard
Day 30   → S3 Standard-IA
Day 90   → S3 Glacier Flexible Retrieval
Day 365  → S3 Glacier Deep Archive
Day 2555 → Expire(七年後刪除)

存取模式無法預測時:略過 lifecycle,將所有資料放入 S3 Intelligent-Tiering。

Amazon EBS — 區塊儲存效能層級

Amazon EBS 是任何時候單台 EC2 執行個體需要持久性本地磁碟的可擴展儲存解決方案答案——開機磁碟區、交易型資料庫、對延遲敏感的應用程式、記錄暫存區。EBS volumes 存在於單一 AZ;snapshots 存在於 S3(受管、對你不可見),可跨 Region 複製以作為 DR 的種子。

EBS Volume Types — 核心效能矩陣

類型 媒介 最大容量 每個 volume 最大 IOPS 最大吞吐量 主要使用場景
gp3 SSD 16 TiB 16,000 1,000 MiB/s 預設通用用途;IOPS 與吞吐量獨立於大小佈建
gp2 SSD 16 TiB 16,000 250 MiB/s 舊版通用用途;IOPS 隨大小增長(3 IOPS/GB,可突增至 3,000)
io2 Block Express SSD 64 TiB 256,000 4,000 MiB/s 關鍵任務:SAP HANA、Oracle、SQL Server AlwaysOn
io1 SSD 16 TiB 64,000 1,000 MiB/s 舊版 provisioned IOPS;建議改用 io2 Block Express
st1 HDD 16 TiB 500 500 MiB/s 吞吐量最佳化:巨量資料、記錄處理、資料倉儲掃描工作負載
sc1 HDD 16 TiB 250 250 MiB/s 冷 HDD:不常存取的大型資料集,最低 EBS 成本

gp3 vs gp2 — 免費的效能升級

gp3 是目前預設的通用 SSD。與 gp2 相比:

  • gp3 可獨立於 volume 大小佈建 IOPS(最高 16,000)與吞吐量(最高 1,000 MiB/s),而 gp2 的 IOPS 隨大小增長,吞吐量上限為 250 MiB/s。
  • gp3 的基準容量費用比 gp2 便宜約 20%。
  • 對大多數工作負載而言,從 gp2 遷移至 gp3 可同時提升效能並降低成本。

io2 Block Express — 256k IOPS 的效能怪獸

io2 Block Express 是 Amazon EBS 可擴展儲存解決方案的效能巔峰:最高 64 TiB、256,000 IOPS、4,000 MiB/s 吞吐量,以及 99.999% volume 耐久性。這也是 SAP HANA 以及那種能讓人接受頂級每 IOPS 定價的一線 OLTP 工作負載所要選擇的 volume 類型。

Throughput-Optimized HDD(st1)vs Cold HDD(sc1)

  • st1 — 串流吞吐量工作負載:Hadoop、Kafka、資料倉儲掃描、影片處理。不可用作開機磁碟區。不適用於需要高 IOPS 小型隨機讀取的工作負載。
  • sc1 — HDD 上的冷儲存;最便宜的 EBS 層級。適用於不常存取的大型檔案,且因需要區塊裝置而不能使用 Amazon S3 的場景。

EBS Snapshots — 時間點備份

Snapshots 為增量式——第一次快照後只複製變更的區塊——並在背後儲存於 S3。你可以:

  • 將 snapshots 複製到另一個 Region(DR 種子)。
  • 透過 KMS grants 跨 AWS 帳戶共享加密 snapshots。
  • 使用 EBS Fast Snapshot Restore(FSR)預熱 snapshots,讓新建立的 volume 從第一次區塊讀取起就有正常的延遲表現。
  • 使用 Amazon Data Lifecycle Manager(DLM)或 AWS Backup 按排程協調 snapshots。
考試必背的 EBS 效能上限:gp3 最高 16,000 IOPS 與 1,000 MiB/s;io2 Block Express 最高 256,000 IOPS 與 4,000 MiB/s 及 64 TiB;st1 最高 500 MiB/s 吞吐量但僅 500 IOPS;sc1 最高 250 MiB/s 與 250 IOPS。這些數字是「選哪種 EBS volume type」情境題的決定因素。

EBS Multi-Attach

io1 與 io2 volumes 支援 Multi-Attach,可同時連接至同一 AZ 內最多 16 台 Nitro EC2 執行個體,用於叢集應用程式(Oracle RAC 風格)。應用程式必須自行協調寫入——EBS 不提供檔案系統層級的鎖定。Multi-Attach 不是 EFS 或 FSx 的替代品;它是叢集資料庫的利基功能。

Amazon EFS — 具備 Region 覆蓋範圍的共享 NFS 檔案儲存

Amazon EFS 是當多台 EC2 執行個體(或透過 VPN/Direct Connect 的地端主機)需要掛載共享 POSIX 檔案系統(NFSv4.1)時的可擴展儲存解決方案選擇。EFS 從數 MB 擴展至 PB 級無需佈建,吞吐量隨工作負載自動調整。

EFS Performance Modes — General Purpose vs Max I/O

效能模式在建立檔案系統時選擇,之後無法更改:

  • General Purpose(預設)— 最低的每次操作延遲。支援最高 35,000 個全檔案系統 IOPS。適用於網站層內容、CMS、開發者家目錄、容器持久儲存——幾乎涵蓋所有場景。
  • Max I/O — 更高的聚合吞吐量與更高的 IOPS 上限,代價是每次操作延遲略高。適用於極度並行且能容忍毫秒級額外延遲、但受益於高聚合吞吐量的工作負載。AWS 自 2023 年起建議預設使用 General Purpose;Max I/O 現在很少是最佳答案,因為 Elastic throughput 涵蓋了大多數過去需要 Max I/O 的場景。

EFS Throughput Modes — Bursting、Provisioned、Elastic

吞吐量模式決定檔案系統每秒能移動多少資料:

  • Bursting Throughput(預設)— 吞吐量隨已儲存的資料量增長;小型檔案系統累積突增積分以應對短暫的高吞吐量需求。適用於吞吐量大致與容量成比例的穩態工作負載。
  • Provisioned Throughput — 你獨立於檔案系統大小佈建的固定吞吐量。當工作負載吞吐量超過 Bursting 所能提供,且檔案系統容量較小時使用。
  • Elastic Throughput — 從零到數十 GB/s 自動擴展,按用量計費,無需佈建。AWS 目前推薦大多數無法預測工作負載的 Amazon EFS 預設選項。

EFS Storage Classes 與 Lifecycle Management

EFS 支援四種儲存類別:

  • EFS Standard — Multi-AZ,頻繁存取的檔案。
  • EFS Standard-Infrequent Access(Standard-IA) — Multi-AZ,不常存取;每 GB 費用低得多,但有每次存取的取回費用。
  • EFS One Zone — 單一 AZ,頻繁存取的檔案,比 Standard 便宜。
  • EFS One Zone-Infrequent Access(One Zone-IA) — 單一 AZ,不常存取;最便宜的 EFS 層級。

EFS Lifecycle Management 自動將 N 天(7、14、30、60、90 天)未存取的檔案移至對應的 IA 類別,並(選擇性地)在存取時將其移回 Standard。對於具有長尾存取模式的工作負載,搭配 IA + Lifecycle 可降低 EFS 成本 70–90%。

EFS 存取範圍與擴展

  • Region 範圍 — EFS Standard 與 Standard-IA 在 Region 內的多個 AZ 間複寫。在 VPC 每個 AZ 中建立一個掛載目標;該 AZ 中的 EC2 執行個體掛載本地掛載目標。
  • EFS One Zone — 存在於單一 AZ。更便宜;若該 AZ 被摧毀則資料遺失(建議搭配 snapshots/AWS Backup 至其他 AZ)。
  • EFS Replication — 跨 Region 複寫功能,用於 DR;RPO 通常為分鐘級。
  • POSIX 權限與 EFS Access Points — 應用程式層級的掛載限制與 UID/GID 強制執行。
Amazon EFS 僅支援 Linux NFS。任何 SAA-C03 情境提及「Windows」、「SMB 共享」、「Active Directory 身份驗證」或「NTFS ACLs」,都會立即排除 EFS。這些情況下正確的可擴展儲存解決方案選擇是 Amazon FSx for Windows File Server(若同時需要 SMB + NFS + iSCSI,則選 Amazon FSx for NetApp ONTAP)。

Amazon FSx — 專用受管檔案系統

Amazon FSx 是四種受管檔案系統的可擴展儲存解決方案傘,每一種都解決 EFS 無法處理的特定工作負載模式。

Amazon FSx for Windows File Server

  • 通訊協定:SMB 2.0/3.0,具備 NTFS 語義。
  • 身份識別:整合 AWS Managed Microsoft AD 或自管 AD。
  • 功能:NTFS ACLs、DFS Namespaces、陰影複製、資料重複資料刪除、備份。
  • 部署:Single-AZ 或 Multi-AZ(同步複寫 + 自動容錯移轉)。
  • 使用場景:Windows 家目錄、SharePoint 後端、SQL Server 檔案共享、Windows 應用程式直接遷移。

考試考點:「Windows 應用程式需要搭配 AD 與 SMB 的共享檔案儲存」→ FSx for Windows File Server。絕不選 EFS。

Amazon FSx for Lustre

  • 通訊協定:Lustre(POSIX)。
  • 效能:毫秒以下延遲,聚合吞吐量可達數百 GB/s,IOPS 達數百萬。
  • S3 整合:FSx for Lustre 檔案系統可連結至 S3 儲存貯體;首次存取時懶惰載入物件為檔案,並可將修改後的檔案匯出回 S3。
  • 部署:Scratch 檔案系統(暫時性,無複寫)適用於短期工作負載;Persistent 檔案系統(在 AZ 內複寫)適用於長期執行且資料重要的工作負載。
  • 使用場景:機器學習訓練、基因組學、金融 Monte Carlo 模擬、CFD、媒體渲染,以及任何共享檔案吞吐量為瓶頸的工作負載。

考試考點:「ML 訓練從 S3 串流資料,需要以 200 GB/s 的低延遲 POSIX 檔案存取」→ FSx for Lustre 連結至 S3 儲存貯體。

Amazon FSx for NetApp ONTAP

  • 通訊協定:NFS v3/v4、SMB 2/3、iSCSI——全在一個檔案系統中。
  • 功能:SnapMirror、SnapVault、FlexClone、ONTAP 快照、重複資料刪除、壓縮、壓實、精簡佈建、分層至容量集區(S3 支援的 ONTAP 後端冷儲存)。
  • 部署:Single-AZ 或 Multi-AZ。
  • 使用場景:企業 NetApp 客戶將現有工作負載遷移至 AWS;NFS + SMB + iSCSI 混合環境;依賴 NetApp 特定功能(如 SnapMirror 或 FlexClone)的工作負載。

考試考點:「企業需要從單一受管檔案系統同時使用 SMB、NFS 與 iSCSI,並搭配 SnapMirror 複寫」→ FSx for NetApp ONTAP

Amazon FSx for OpenZFS

  • 通訊協定:NFSv3 與 NFSv4.1。
  • 功能:ZFS 快照、複製(即時可寫複本)、壓縮、copy-on-write。
  • 部署:Single-AZ(較新的檔案系統類型提供 Multi-AZ HA)。
  • 使用場景:需要 ZFS 風格即時複製的 Linux 工作負載(開發/測試資料複本)、低延遲 NFS、從地端 ZFS 系統進行較簡單的遷移。

考試考點:「需要對數 TB 檔案系統建立即時可寫時間點複本供開發/測試使用,且不複製資料」→ FSx for OpenZFS

FSx 決策表 — 何時選擇哪一種

需求 答案
Windows SMB + Active Directory FSx for Windows File Server
HPC/ML/毫秒以下延遲/數百 GB/s 吞吐量/S3 連結 FSx for Lustre
從單一檔案系統使用 SMB + NFS + iSCSI,NetApp 功能 FSx for NetApp ONTAP
Linux NFS 搭配 ZFS 快照與即時複製 FSx for OpenZFS
通用 Linux NFS 共享,最低操作負擔 Amazon EFS(非 FSx)
Amazon FSx for Lustre 有兩種部署類型,考題經常針對此點出題。Scratch 檔案系統是最便宜的,但沒有資料複寫——硬體故障時可能遺失資料,這對短期 HPC 任務是可接受的。Persistent 檔案系統在 AZ 內複寫,防止硬體故障,適用於長期執行或關鍵 HPC 資料。如果題幹強調耐久性與長期執行的工作負載,選 Persistent。如果強調成本與暫時性工作集,選 Scratch。

AWS Storage Gateway — 混合可擴展儲存解決方案

AWS Storage Gateway 是虛擬或硬體設備,可在不強迫應用程式改寫的情況下,將地端工作負載橋接至 AWS 儲存服務。共有四種模式,全在 SAA-C03 考試範圍內。

S3 File Gateway

  • 通訊協定:NFS v3/v4.1 與 SMB。
  • 後端:每個檔案成為目標儲存貯體中帶有 S3 metadata 的 S3 物件。
  • 本地快取:常用檔案快取於地端,提供低延遲讀取。
  • 使用場景:需要寫入檔案並讓這些檔案自動成為雲端原生 S3 物件的地端應用程式(記錄擷取、媒體擷取、備份目標、混合資料湖)。

FSx File Gateway

  • 通訊協定:SMB。
  • 後端:AWS 中的 Amazon FSx for Windows File Server,地端提供低延遲本地快取。
  • 使用場景:分支辦公室讀寫託管於 FSx 的中央 Windows 檔案共享。

Volume Gateway

  • 通訊協定:呈現給地端伺服器的 iSCSI 區塊 volumes。
  • 模式
    • Cached volumes — 主要資料存於 AWS;常用子集快取於本地。可在不購買地端磁碟的情況下擴展儲存容量。
    • Stored volumes — 主要資料在地端;完整非同步複寫至 AWS 用於備份與 DR。本地讀寫延遲低。
  • 快照:時間點 EBS snapshots 儲存於 S3;可用作直接遷移或 DR 的 AWS 原生 EBS volumes 種子。

Tape Gateway

  • 通訊協定:iSCSI Virtual Tape Library(VTL),相容於 NetBackup、Veeam、Backup Exec、Dell EMC NetWorker、CommVault 等。
  • 後端:虛擬磁帶存於 S3,可封存至 S3 Glacier 與 S3 Glacier Deep Archive。
  • 使用場景:在不更換備份軟體的情況下取代實體磁帶庫。

考試考點:「使用現有磁帶備份軟體的公司想淘汰實體磁帶」→ Tape Gateway。「地端應用程式需要寫入檔案並讓它們成為 S3 物件」→ S3 File Gateway。「地端區塊儲存容量需求持續增長,但不想購買更多 SAN」→ Volume Gateway Cached 模式

以效能為驅動的可擴展儲存解決方案選擇

SAA-C03 可擴展儲存解決方案題目中最危險的習慣,是根據服務熟悉度而非所需效能範圍來選擇。對每個情境使用這四維度的審視框架。

維度一:延遲

  • 毫秒以下/微秒級每次操作 → FSx for Lustre、EBS io2 Block Express、EC2 Instance Store、FSx for OpenZFS。
  • 個位數毫秒 → EBS gp3、EFS General Purpose、FSx for Windows、FSx for NetApp ONTAP。
  • 數十毫秒(網路 + 檔案系統額外負擔) → EFS Max I/O、S3 Standard 首位元組。
  • 分鐘至小時 → S3 Glacier Flexible 取回、Glacier Deep Archive 取回。

維度二:吞吐量

  • 數百 GB/s 聚合 → FSx for Lustre Persistent。
  • 每用戶端數十 GB/s → EFS Elastic throughput、EBS io2 Block Express、FSx for NetApp ONTAP。
  • 每用戶端 GB/s 級 → EBS gp3(1 GiB/s)、st1(500 MiB/s)、S3 搭配 multipart upload + 多連線。
  • 單一連線未最佳化的吞吐量通常是瓶頸——並行化才能解鎖真正的上限。

維度三:通訊協定

  • HTTPS REST/AWS SDK → S3。
  • 區塊裝置(原始磁碟) → EBS、Instance Store、Volume Gateway。
  • NFSv4.1(Linux) → EFS、FSx for Lustre、FSx for OpenZFS、FSx for NetApp ONTAP。
  • SMB(Windows) → FSx for Windows、FSx for NetApp ONTAP、S3 File Gateway、FSx File Gateway。
  • iSCSI → Volume Gateway、FSx for NetApp ONTAP、EBS Multi-Attach(AZ 內)。
  • Virtual Tape Library → Tape Gateway。

維度四:並行存取模式

  • 單一 EC2,獨佔存取 → EBS 或 Instance Store。
  • 單一 AZ 內叢集,共享區塊 → EBS Multi-Attach(io1/io2)或 FSx NetApp ONTAP iSCSI。
  • 多台 EC2,共享檔案,單一 AZ → EFS One Zone、FSx Single-AZ。
  • 多台 EC2,共享檔案,Multi-AZ → EFS Standard、FSx Multi-AZ。
  • 全球數千用戶端,物件存取 → S3 + CloudFront 或 S3 Transfer Acceleration。
  • 地端 + 雲端混合存取 → 對應模式的 Storage Gateway。
不確定時,在草稿紙上建立一個四欄表格:延遲 | 吞吐量 | 通訊協定 | 並行性。用題目要求填滿每一格。正確的可擴展儲存解決方案服務通常是唯一一個四格都符合的選項。這個習慣能消除 SAA-C03 大多數可擴展儲存解決方案的誘答選項。

確定能擴展至未來需求的儲存方案

可擴展儲存解決方案不只關乎今日的工作負載——SAA-C03 反覆詢問十倍成長的情境。經驗法則:

  • 優先選擇沒有硬性容量上限的服務(S3、EFS、FSx NetApp ONTAP 搭配容量集區、Storage Gateway),而非固定容量的選項(EBS volumes 大多數類型上限 16 TiB;io2 Block Express 上限 64 TiB)。
  • 優先選擇 Region 範圍的服務(S3、EFS Standard),適用於將來需要跨 AZ 容錯移轉的工作負載。
  • 優先選擇 IOPS/吞吐量與大小解耦的服務(gp3、Provisioned/Elastic EFS、Provisioned IOPS io2),當容量成長不會與效能需求同步時。
  • 使用 lifecycle rules(S3、EFS)讓成本與實際熱資料大小成比例,而非與總儲存資料量掛鉤。
  • 當你無法預測多年後的存取模式時,對 S3 使用 Intelligent-Tiering

可擴展儲存解決方案必背關鍵數字

  • S3 最大物件大小:5 TB。單次 PUT:5 GB。Multipart 分段大小:5 MB–5 GB,最多 10,000 段。
  • S3 請求擴展:每個前綴每秒 3,500 次寫入與 5,500 次讀取請求。
  • S3 耐久性:跨 ≥ 3 個 AZ 達 11 個九(One Zone 類別除外)。
  • S3 Standard 可用性 99.99%;Standard-IA 99.9%;One Zone-IA 99.5%;Glacier 類別 99.99% 搭配取回 SLA。
  • EBS gp3:獨立於大小,最高 16,000 IOPS 與 1,000 MiB/s,最大 16 TiB。
  • EBS io2 Block Express:最高 256,000 IOPS、4,000 MiB/s、64 TiB,99.999% 耐久性。
  • EBS st1:500 MiB/s 吞吐量,最高 500 IOPS;sc1:250 MiB/s,250 IOPS。
  • EFS General Purpose 效能模式:最高 35,000 IOPS。
  • EFS Elastic throughput:自動擴展至數十 GB/s 範圍。
  • FSx for Lustre Persistent:聚合吞吐量數百 GB/s,毫秒以下延遲。
  • FSx for Windows 部署:Single-AZ 與 Multi-AZ。
  • AWS Storage Gateway 模式:S3 File Gateway、FSx File Gateway、Volume Gateway(Cached/Stored)、Tape Gateway。
二十個必背的可擴展儲存解決方案數字:S3 11 個九耐久性;S3 最大物件 5 TB;S3 每前綴 3,500 次寫入/5,500 次讀取;S3 classes = 7 種;gp3 16,000 IOPS/1,000 MiB/s;io2 Block Express 256,000 IOPS/4,000 MiB/s;io2 64 TiB;st1 500 MiB/s;sc1 250 MiB/s;EFS GP 模式 35,000 IOPS;EFS One Zone 存在;FSx 版本 = 4 種(Windows、Lustre、ONTAP、OpenZFS);FSx for Lustre scratch vs persistent;Storage Gateway 模式 = 4 種;S3 Glacier Deep Archive 12–48 小時;Standard-IA 30 天最短期限;Glacier 90 天最短期限;Deep Archive 180 天最短期限;S3 Transfer Acceleration 使用 CloudFront 邊緣節點;EBS 範圍為單一 AZ。

SAA-C03 可擴展儲存解決方案的常見考試陷阱

  1. EBS vs EFS「跨 EC2 執行個體共享」 — EBS 範圍為單一 AZ,且(Multi-Attach 以外)為單一執行個體。一旦看到「多台 EC2 執行個體共享相同檔案」,答案是 EFS 或 FSx,不是 EBS。
  2. EFS vs FSx for Windows — EFS 只支援 Linux NFS。「Windows SMB 共享」永遠指向 FSx for Windows,不是 EFS。
  3. FSx for Lustre Scratch vs Persistent — Scratch 最便宜,但沒有複寫。Persistent 是長期執行或關鍵 HPC 資料集的正確選擇。
  4. S3 Intelligent-Tiering vs Standard-IA — 未知存取 → Intelligent-Tiering。已知且可預測的不頻繁存取 → Standard-IA。
  5. S3 One Zone-IA 在 AZ 故障時會遺失資料 — 僅用於可重新產生的資料。
  6. Transfer Acceleration 對 Region 內上傳無效 — 它只在長距離傳輸時有幫助。
  7. Glacier Instant Retrieval vs Glacier Flexible Retrieval — Instant 是每季存取一次的毫秒級取回;Flexible 是 DR 歸檔的分鐘至小時取回。
  8. EBS Multi-Attach 不是 EFS 的替代品 — 它是讓叢集資料庫自行協調寫入的利基功能,且範圍限於單一 AZ。
  9. Storage Gateway Tape Gateway 取代實體磁帶 — 「現有備份軟體寫入磁帶」→ Tape Gateway。
  10. FSx for NetApp ONTAP 是多通訊協定單一檔案系統的答案 — 若情境要求從同一個檔案系統使用 NFS、SMB 與 iSCSI,ONTAP 是唯一選擇。
  11. FSx for Lustre 連結至 S3 — 「ML 訓練以 POSIX 語義從 S3 讀取 GB/s 級資料」→ FSx for Lustre 連結至儲存貯體。
  12. EBS snapshots 為增量式並存於 S3 — 第一次快照後只複製變更的區塊;可跨 Region 複製用於 DR。
某道 SAA-C03 可擴展儲存解決方案題描述「3,000 台 EC2 Linux 執行個體跨 3 個 AZ,每台都讀寫一個聚合吞吐量 5 GB/s 的共享內容目錄」。預設選 EBS Multi-Attach 的考生會因兩個原因失分:Multi-Attach 最多只能連接 16 台 EC2 執行個體,且範圍限於單一 AZ。選 FSx for Lustre 的考生可能過度花費,並且錯過更簡單的 Linux POSIX 答案。正確的可擴展儲存解決方案選擇是 Amazon EFS 搭配 Elastic throughput(若吞吐量為主要瓶頸則選 Max I/O)。先閱讀三個 AZ 與數千用戶端的限制條件。

可擴展儲存解決方案情境模式

  • 模式一 — 靜態網站與行動應用程式資產分發,11 個九耐久性 → S3 Standard + CloudFront(上傳時可選用 Transfer Acceleration)。
  • 模式二 — 合規歸檔,極少讀取,7 年保留 → S3 Glacier Deep Archive 搭配 lifecycle expiration。
  • 模式三 — 新資料湖上的未知存取模式 → S3 Intelligent-Tiering
  • 模式四 — EC2 MySQL OLTP 需要在 2 TiB volume 上維持 20,000 穩態 IOPS → EBS gp3 佈建 20,000 IOPSio2 Block Express
  • 模式五 — EC2 上的 SAP HANA → EBS io2 Block Express
  • 模式六 — 500 台 Linux EC2 執行個體提供 CMS 服務,所有執行個體跨 3 個 AZ 掛載同一個內容目錄 → Amazon EFS,Elastic throughput。
  • 模式七 — Windows SharePoint 農場需要整合 AD 的 SMB 共享,具備 Multi-AZ 容錯移轉 → FSx for Windows File Server Multi-AZ
  • 模式八 — ML 訓練從 S3 讀取數 TB 資料,需要以 200 GB/s 的毫秒以下 POSIX 存取 → FSx for Lustre Persistent 連結至 S3 儲存貯體。
  • 模式九 — NetApp 客戶遷移,搭配 SnapMirror、SMB + NFS + iSCSI → FSx for NetApp ONTAP
  • 模式十 — 開發/測試團隊需要 5 TiB Linux NFS 資料集的即時可寫複本 → FSx for OpenZFS
  • 模式十一 — 地端應用程式寫入需成為 S3 物件的檔案,且需要低延遲本地讀取 → S3 File Gateway
  • 模式十二 — 取代 Veeam 使用的實體磁帶庫 → AWS Storage Gateway Tape Gateway
  • 模式十三 — 從新加坡快速上傳 2 TB 物件至 us-east-1 儲存貯體 → Multipart upload + S3 Transfer Acceleration
  • 模式十四 — EBS 支援資料庫的跨 Region DR → 快照 + 複製至目標 Region(或 AWS Backup 跨 Region 複製)。
  • 模式十五 — 地端區塊容量需求持續增長,不想購買更多 SAN → Storage Gateway Volume Gateway Cached 模式

可擴展儲存解決方案與其他 SAA-C03 主題的關聯

  • 資料加密與金鑰管理(1.3) — 每項可擴展儲存解決方案服務都整合 AWS KMS:S3 的 SSE-KMS、EBS volumes 與 snapshots 的 KMS 金鑰、EFS 的 KMS、FSx 的 KMS。
  • 資料治理與合規(1.3) — S3 Object Lock WORM 模式、versioning 與 AWS Backup 橫跨可擴展儲存解決方案產品組合。
  • 災難復原策略(2.2) — S3 CRR、EBS snapshot 複製、EFS replication、FSx 備份與 AWS Elastic Disaster Recovery 都依賴可擴展儲存解決方案。
  • 成本最佳化儲存(4.1) — Lifecycle rules、S3 Intelligent-Tiering、EFS Lifecycle Management、gp3 優於 gp2,以及 One Zone 類別是成本調節器。
  • 資料傳輸與遷移(3.5) — DataSync、Snowball、Storage Gateway 與 Transfer Family 都為可擴展儲存解決方案提供資料來源。

FAQ — 可擴展儲存解決方案熱門問題

Q1:需要 50,000 穩態 IOPS 的關鍵任務 OLTP 資料庫,應選擇哪種 EBS volume type?

正確的可擴展儲存解決方案選擇是 Amazon EBS io2 Block Express,可提供最高 256,000 provisioned IOPS、最高 4,000 MiB/s 吞吐量、99.999% 耐久性,以及每個 volume 最大 64 TiB。io1 也能達到 50,000 IOPS,但 io2 Block Express 更新、每 IOPS 更便宜,且是 SAP HANA、Oracle 或 SQL Server 等一線資料庫的推薦選擇。gp3 最高 16,000 IOPS,不足以應付此需求。

Q2:何時應選 Amazon FSx for Lustre 而非直接使用 Amazon S3?

當工作負載需要具備毫秒以下延遲與數百 GB/s 聚合吞吐量的 POSIX 檔案系統語義時,選擇 Amazon FSx for Lustre——典型場景包括 HPC、機器學習訓練、基因組學 pipeline、金融模擬或媒體渲染。FSx for Lustre 可直接連結至 S3 儲存貯體,首次存取時懶惰載入物件為檔案,再將修改後的檔案匯出回 S3。若應用程式能使用 HTTPS 或不需要 POSIX 語義的延遲與吞吐量,則直接使用 S3 即可。

Q3:我的 EC2 執行個體跨三個 AZ,所有執行個體都需要讀寫一個共享檔案系統。正確的可擴展儲存解決方案選擇是什麼?

Amazon EFS 是 Linux 工作負載的正確答案——它的範圍是 Region,每個 AZ 有掛載目標,支援數千台並行 NFS 用戶端。針對無法預測的工作負載選擇 Elastic throughput。Windows 則選 Amazon FSx for Windows File Server Multi-AZ。HPC 規模的吞吐量需求則選 Amazon FSx for Lustre Persistent 部署。EBS 是錯誤答案,因為它的範圍是單一 AZ。

Q4:如何加速從歐洲上傳 2 TB 檔案至 us-east-1 的 S3 儲存貯體?

使用 S3 multipart upload 並行多個分段,並在儲存貯體上啟用 S3 Transfer Acceleration。Multipart 讓你並行上傳分段(每段 5 MB–5 GB,最多 10,000 段)——吞吐量上限變成所有並行 TCP 串流的總和,而非單一串流。Transfer Acceleration 透過最近的 CloudFront 邊緣節點,經由 AWS 最佳化骨幹網路路由上傳。兩者結合,通常可將實際上傳時間縮短一半甚至四分之一。

Q5:EFS Bursting、Provisioned 與 Elastic throughput 有什麼差異,我應該選哪個?

Bursting 吞吐量隨已儲存的資料量增長,適用於吞吐量隨容量成比例增長的工作負載。Provisioned 吞吐量是你獨立於大小佈建的固定速率——當你需要的吞吐量超過 Bursting 所能提供,且檔案系統容量較小時使用。Elastic 吞吐量無需任何佈建即可自動上下調整,並按每 GB 傳輸量計費——AWS 目前推薦它作為大多數無法預測的 Amazon EFS 可擴展儲存解決方案工作負載的預設選項,因為它同時消除了佈建不足與過度佈建的風險。

Q6:S3 One Zone-IA 與 S3 Standard-IA,何時各自是正確答案?

S3 One Zone-IA 每 GB 比 Standard-IA 便宜 20%,但資料儲存於單一 AZ——若該 AZ 被摧毀,資料即遺失。只有在資料可以重新產生的情況下才選它:次要副本、渲染過的縮圖、已處理的分析輸出。對於耐久性至關重要的主要不常存取副本,選 S3 Standard-IA(Multi-AZ)。兩者都有 30 天最短儲存期限與每 GB 取回費用。

Q7:取代實體磁帶備份的公司應選哪種 AWS Storage Gateway 模式?

Tape Gateway。它透過 iSCSI 呈現一個虛擬磁帶庫(VTL),現有備份軟體(Veeam、NetBackup、Backup Exec、CommVault 等)將其視為實體磁帶庫。虛擬磁帶落於 S3,並可歸檔至 S3 Glacier 或 S3 Glacier Deep Archive 以長期保留。這是重複出現的情境——「淘汰實體磁帶機器人」永遠對應 Tape Gateway,而非 EBS snapshots 或 AWS Backup。

Q8:存取模式完全無法預測,且不想維護 lifecycle rules,應選哪種 S3 storage class?

S3 Intelligent-Tiering。它收取少量的每物件每月監控費用,然後根據實際存取自動在 Frequent、Infrequent、Archive Instant,以及選擇性的 Archive 與 Deep Archive 層之間移動每個物件。自動管理層級無取回費用(選擇性啟用的 Archive 與 Deep Archive 層除外)。這是 SAA-C03 可擴展儲存解決方案題目中「未知存取模式、最小化成本、零操作負擔」的唯一正確答案。

Q9:從快照還原 EBS volume 並讓第一次區塊讀取就有完整效能,最快的方法是什麼?

使用 EBS Fast Snapshot Restore(FSR)。若不使用 FSR,從快照建立的 volume 會在首次存取時懶惰地從 S3 載入區塊,導致首次存取延遲。FSR 預先暖機 volume,讓每個區塊從 volume 建立的那一刻起就能以完整 provisioned IOPS 即時存取。在你計畫建立 volumes 的每個 AZ 中對快照啟用 FSR。這對 DR 與大規模複製情境至關重要。

Q10:工作負載需要從單一檔案系統同時使用 SMB、NFS 與 iSCSI,應選哪種可擴展儲存解決方案服務?

Amazon FSx for NetApp ONTAP。它是唯一一個從同一個檔案系統同時提供 NFS、SMB 與 iSCSI 的受管 AWS 可擴展儲存解決方案服務,並具備 NetApp 原生功能(SnapMirror 複寫、SnapVault 備份、FlexClone 即時複製、重複資料刪除、壓縮、分層至 S3 支援的容量集區)。正在將現有儲存基礎架構遷移至 AWS 的企業 NetApp 客戶,應預設選擇 FSx for NetApp ONTAP。

延伸閱讀

可擴展儲存解決方案最終學習建議

  1. 反覆練習物件/區塊/檔案/混合分類法,直到它變成直覺反應——可擴展儲存解決方案題目永遠以此為第一個轉折點。
  2. 將 EBS volume type 矩陣(gp3、gp2、io2 Block Express、io1、st1、sc1)連同最大 IOPS 與最大吞吐量一起背下來。
  3. 依通訊協定與考點記住四種 FSx 版本:Windows + AD → FSx Windows;HPC + Lustre → FSx Lustre;多通訊協定 + NetApp → FSx ONTAP;Linux ZFS 複製 → FSx OpenZFS。
  4. 徹底搞清楚 S3 Intelligent-Tiering 與 Standard-IA 的區別——它出現在大多數成本相關的可擴展儲存解決方案題目中。
  5. 對每個可擴展儲存解決方案情境練習套用四維度框架(延遲、吞吐量、通訊協定、並行性)。
  6. 了解混合情境的重點:S3 File Gateway(檔案 → S3 物件)、Volume Gateway(iSCSI 區塊)、Tape Gateway(虛擬磁帶庫)。
  7. 記住可擴展儲存解決方案的選擇與加密、DR 和成本最佳化主題相互交織——考試會將它們混合在一起。

掌握這些可擴展儲存解決方案模式,SAA-C03 任務陳述 3.1「確定高效能且/或可擴展的儲存解決方案」在考試當天就會成為穩定的得分來源。祝你考試順利。

官方資料來源