Amazon SAP-C02: 儲存與資料管理 — 學習指南

By Laurynas Brazys · 1 August 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

屬於 AWS Solutions Architect Professional SAP-C02 — 學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.

物件儲存、生命週期與分層 (Amazon S3 及相關服務)

Amazon S3 是耐用、高可用性物件儲存的基礎，應被視為非結構化資料的標準、長期儲存庫。設計決策的核心在於儲存類別的選擇、生命週期規則、一致性語意以及資料治理。對於頻繁存取的物件，選擇 S3 Standard；當存取模式未知時，選擇 Intelligent-Tiering；對於不頻繁存取的物件，選擇 Standard-IA 或 One Zone-IA；對於需要長期保留但可接受較高還原延遲的資料，則選擇 Glacier/Deep Archive。根據標籤或前綴實作生命週期政策，以自動轉換物件並讓舊版本過期；在設定生命週期或複寫規則前啟用版本控制，以免物件被意外清除。使用跨區域複寫 (Cross-Region Replication, CRR) 來達成地理上的耐用性與法規遵循的存放位置，或使用相同區域複寫 (Same-Region Replication, SRR) 來達成合規性與責任分離。使用 S3 Object Lock 的治理模式或合規模式來保護關鍵的封存資料，並在適當情況下啟用 MFA Delete。常見的陷阱包括過於激進的生命週期轉換，這會產生還原費用與數分鐘到數小時的延遲；未考慮到 Glacier 的擷取成本或時間；以及依賴公有端點而非 VPC Gateway/Interface 端點 (這可能會將資料暴露於公用網際網路，或產生 NAT 輸出成本)。在成本、擷取延遲與耐用性之間取得平衡：對於冷資料採取積極的分層策略，但對於熱門的傳入流量和需要低延遲存取的場景，則應配置加速功能 (CloudFront、S3 Transfer Acceleration、分段上傳)。

共用檔案系統與高效能儲存 (EFS, FSx)

當應用程式需要 POSIX 語意、低延遲或 SMB 語意時，應選擇共用檔案系統。Amazon EFS 提供具備多可用區耐用性與 POSIX 一致性的彈性 NFS，適用於網站內容、家目錄以及許多可容忍網路檔案語意的高效能運算 (HPC) 工作負載。EFS 有兩種效能模式 (高載輸送量 vs. 佈建輸送量) 以及可轉換至 EFS Infrequent Access 的生命週期政策。Amazon FSx 提供專為特定目的打造的檔案系統：Windows File Server 用於 SMB/Active Directory 整合，而 FSx for Lustre 則為緊密耦合的 HPC 與媒體工作負載提供亞毫秒級延遲與高輸送量；FSx Lustre 可以透明地連結到 S3，作為一個耐用的資料儲存庫。當您需要 NTFS 語意、AD ACL、DFS 命名空間或僅限 Windows 的工具時，請選擇 FSx for Windows；當彩現農場與機器學習訓練需要高 IOPS 與高輸送量時，請選擇 FSx Lustre。常見的操作錯誤包括假設 EFS 會自動處理中繼資料密集型的工作負載 (您可能需要佈建輸送量)、在安全群組中過於廣泛地開放 NFS/SMB 連接埠，以及忽略掛載選項與用戶端逾時設定。評估權衡：FSx 成本較高，但效能更強且協定功能更豐富；EFS 則擴展簡單且具備多可用區耐用性。將工作負載的 I/O 模式、並行性與輸送量需求與所選的系統進行匹配，並在需要時另外調整輸送量的大小。

混合雲與離線傳輸模式 (Storage Gateway, DataSync, Snow family)

混合雲架構通常需要低延遲的本機快取、無縫的雲端備份或大量資料遷移。AWS Storage Gateway 提供三種模式：File Gateway 將 S3 公開為 NFS/SMB，供本地部署的應用程式寫入 S3；Volume Gateway 公開區塊磁碟區以供災難復原 (DR) 使用；Tape Gateway 取代實體磁帶。AWS DataSync 可自動化本地部署與 AWS (S3、EFS、FSx) 之間的線上、增量與並行資料移動，具備內建的篩選、排程與頻寬控制功能；在設定後，它會保留 POSIX 中繼資料。對於離線與超大規模的傳輸，Snow 系列提供包含運算能力的邊緣與傳輸裝置：Snowcone 適用於小型的遠端站點，Snowball Edge 適用於數十到數百 TB 的資料量，且裝置上可執行 Lambda/EC2，而 Snowmobile 則用於 EB 等級的匯入。使用 DataSync 進行持續、自動化的傳輸；當舊有應用程式必須在本機看到 NFS/SMB 掛載點，同時又將資料儲存在 S3 時，請使用 Storage Gateway File Gateway。常見的陷阱包括使用錯誤的閘道模式 (快取 vs. 預存)、未規劃網路輸送量導致遷移時間過長、忽略用於安全傳輸的 IAM 角色與端點政策，以及低估 Snow 裝置的資料匯入/匯出時間。選擇 DataSync 進行頻繁的增量同步，選擇 Storage Gateway 以達成與本機協定的相容性，並在網路頻寬不足時，選擇 Snow 裝置進行大量或遠端傳輸。

備份、複寫、存取控制與維運治理

備份與複寫的選擇應根據 RTO/RPO 目標、法規控制與成本來決定。使用 AWS Backup 來集中管理 EBS、RDS、DynamoDB、EFS 和 FSx 的備份政策，並設定從暖封存庫到冷儲存的生命週期轉換以節省成本。對於資料庫，建議優先使用原生機制（RDS 快照、唯讀複本，或用於異質遷移的 DMS），並搭配跨區域快照複製以及 KMS 金鑰複寫或獨立的金鑰政策。對於 S3，啟用版本控制、CRR/SRR，並在需要近乎即時複寫 SLA 時，考慮使用複寫時間控制 (RTC)。安全的存取模式依賴於最低權限 IAM、儲存貯體政策、S3 封鎖公開存取、帶有端點政策的 VPC Gateway/Interface 端點，以及用於跨帳戶存取和快照複製、具備細緻授權的 KMS。使用 CloudTrail、S3 存取日誌、CloudWatch 指標、AWS Config 規則進行監控，並利用 GuardDuty 和 Access Analyzer 進行威脅偵測和 IAM 設定錯誤的檢查。常見的陷阱包括：未跨帳戶複寫 KMS CMK 或授予其存取權限、讓快照保持未加密或可公開存取狀態，以及未能使用 SCP 和標籤政策來強制執行標籤或資源放置，這些都會使成本分配和復原變得複雜。根據彈性需求來決定：多區域 active-active 模式可獲得最低的 RTO，pilot-light/warm standby 模式適用於具成本效益的災難復原，而當 RTO 必須最小化時，則採用完整容錯移轉。

實務問題：使用案例情境

情境：Atlas Media 營運一個多帳戶的 AWS Organization，其生產環境位於 us‑east‑1，備援區域則在 eu‑west‑1。他們有一個 150 TB 的本地影片資產封存，而遍布北美和歐洲的藝術家需要高效能的共享儲存，以及對當前專案的安全、低延遲存取。

挑戰：將封存遷移至 AWS，為藝術家提供高吞吐量的渲染儲存，最小化冷資產的持續儲存成本，並確保具備強大備份的安全跨區域存取。

建議方法：

在 us‑east‑1 中佈建一個 S3 儲存貯體作為標準封存，啟用版本控制、使用 AWS KMS 的伺服器端加密 (SSE‑KMS)，並設定跨區域複寫 (Cross‑Region Replication) 到 eu‑west‑1，同時開啟刪除標記的複寫。
使用 AWS Snowball Edge 裝置將最初的 150 TB 匯入 S3 (選用儲存優化型 Snowball Edge)，然後執行 AWS DataSync 進行任何差異變更的增量同步，並驗證其完整性。
對於活躍的工作集，在每個區域部署 Amazon FSx for Lustre，並將檔案系統連結到 S3 儲存貯體（資料儲存庫整合），這樣藝術家就能獲得高吞吐量和低延遲，同時寫入的資料會同步回 S3；可考慮為專案的爆量需求使用生命週期較短的 FSx 執行個體。
透過適用於 S3 和 FSx 的 VPC Interface Endpoints 強制安全存取，使用與 Organization 主體綁定的 IAM 角色和儲存貯體政策來限制儲存貯體存取，利用 CloudFront 和簽署的 URL 為遠端審閱者提供公開分發的前端，並為 FSx 啟用 AWS Backup，加上 S3 跨區域複寫和生命週期規則，將冷資產轉換至 Glacier Deep Archive。

理由：此方法將耐用、低成本的封存儲存 (S3 + Glacier) 與高效能的專案儲存 (連結到 S3 的 FSx Lustre) 分開，使用 Snowball 和 DataSync 來優化初始的大量匯入和差異同步，並在平衡成本、效能和復原目標的同時，強制執行強大的安全性和跨區域彈性。

← 運算與 Auto Scaling · 所有領域 · 資料庫與分析 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →