Amazon SAA-C03: 儲存與資料生命週期 — 學習指南

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

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

S3 儲存類別與成本/延遲光譜

S3 儲存類別存在於一個光譜上，權衡著擷取延遲、最短儲存期間、每 GB 擷取費用與每 GB 儲存成本。正確選擇儲存類別是物件儲存成本優化的最大槓桿。

S3 Standard 是預設選項：跨越三個或更多可用區域 (AZ) 提供 11 個 9 的耐久性、毫秒級延遲、無擷取費用，但每 GB 價格最高。Standard-IA 和 One Zone-IA 將儲存成本降低約 40–50%，但增加了每 GB 的擷取費用、30 天的最短計費期間，以及 128 KB 的最小物件大小（較小的物件會以 128 KB 計費，這會侵蝕節省的成本）。One Zone-IA 透過將資料儲存在單一 AZ 中來進一步降低成本——這僅適用於可重製的次要副本，且單一 AZ 的損失是可接受的情況。

S3 Intelligent-Tiering 是每當存取模式未知、無法預測，或是在大型資料集中變動時的正確選擇。它會根據觀察到的存取行為，在頻繁存取、不頻繁存取、封存即時、封存和深度封存層之間自動遷移物件，並收取小額的每個物件監控費用。由於在頻繁和不頻繁存取層之間沒有擷取費用，也沒有最短儲存期間，因此對於物件大小 ≥128 KB 的資料湖和混合工作負載而言，這是最安全的預設選項。但當您已經知道物件是永久性熱門（會產生額外的監控成本）或將永久性冷門長達十年（Deep Archive 遠比它便宜）時，這就是錯誤的選擇。

Glacier Instant Retrieval 為每季或更少存取一次的資料，以封存價格提供毫秒級的存取——例如醫療影像、被要求時必須立即產出的合規 PDF 文件。Glacier Flexible Retrieval 提供分鐘到小時級的擷取時間。Glacier Deep Archive 是 AWS 中最便宜的層級，大約每月每 TB 1 美元，標準擷取時間為 12 小時（或大量擷取為 48 小時），且有 180 天的最短儲存期間——這是 7-10 年法規保留和磁帶替代方案的正確答案。

兩個主要的成本陷阱是相反的錯誤。為長期很少讀取的資料選擇 Standard 會燒錢，因為 Standard 沒有冷儲存的價格優惠——一個 5 TB 的資料集在 Standard 中存放數年，其成本會是在 Deep Archive 中存放相同資料的好幾倍。相反地，將全新的物件直接移至 Standard-IA 或 Glacier 也是一個陷阱，因為 30/90/180 天的最短費用加上擷取費用，會超過物件仍然是熱門時所能節省的成本。Glacier Flexible 或 Deep Archive 也完全不相容於任何期望同步讀取的工作負載——等待 HTTP GET 回應的使用者無法容忍分鐘到 12 小時的擷取 SLA。Glacier Instant Retrieval 是唯一與即時存取相容的 Glacier 層級。

生命週期政策與版本處理

生命週期組態是附加到儲存貯體的宣告式 JSON/YAML，它根據物件的年齡、標籤或前綴來轉換或過期物件。轉換規則每天評估一次，且只在達到指定年齡後觸發——Days: 30 的轉換意味著前 30 天適用 Standard 的費率。轉換必須移至逐漸變冷的層級，且小於 128 KB 的物件不會從 Standard 轉換到 IA，因為每個物件的額外開銷超過了節省的成本；應先透過 tar/zip 或 S3 Batch Operations 合併小物件。

一個典型的工作負載政策範例，其資料在前 30 天為熱門，之後變冷，但全程需要即時存取，保留四年，並具備良好的清理機制：

Rules:
  - ID: archive-and-clean
    Status: Enabled
    Transitions:
      - Days: 30
        StorageClass: STANDARD_IA
      - Days: 180
        StorageClass: DEEP_ARCHIVE
    NoncurrentVersionTransitions:
      - NoncurrentDays: 30
        StorageClass: GLACIER
    NoncurrentVersionExpiration:
      NoncurrentDays: 365
    Expiration:
      Days: 1460
    AbortIncompleteMultipartUpload:
      DaysAfterInitiation: 7

一個常見的版本控制陷阱：在已啟用版本控制的儲存貯體上，一個讓目前版本物件過期的生命週期規則，只會插入刪除標記；先前的版本會默默地累積並繼續計費。非目前版本需要自己明確的 NoncurrentVersionTransitions 和 NoncurrentVersionExpiration 規則。同樣地，務必包含 AbortIncompleteMultipartUpload——孤立的分段上傳部分在主控台清單中是看不見的，且會無限期地產生儲存費用。

對於混合模式——例如，IoT 遙測資料在第一個月用於機器學習訓練而屬於熱門資料，之後一年內每季查詢一次，然後進行封存——正確的答案是在第一年使用 Intelligent-Tiering（讓該儲存類別在訓練高峰和閒置期間自動優化），然後在第 365 天安排轉換到 Deep Archive。

版本控制、MFA Delete 與物件鎖

版本控制一旦啟用，就只能暫停，無法關閉。每個 PUT 操作都會建立一個新的版本 ID；DELETE 操作會插入一個刪除標記，而不是真正移除資料。版本控制能防止意外覆寫，但它不等於不可變性：任何擁有 s3:DeleteObjectVersion 權限的主體都可以永久移除特定版本。MFA Delete 增加了一項要求，即根帳戶必須提供 MFA 權杖才能永久移除版本或變更版本控制狀態——這彌補了高價值儲存桶意外刪除的漏洞，但仍無法阻止有權限的行為者銷毀資料。

真正的不可變性需要 S3 Object Lock，它要求啟用版本控制，且通常必須在儲存桶建立時就啟用。它有兩種經常被混淆的模式：

保留可以按物件設定 (Retain-Until-Date)，或透過沒有到期日的合法保留 (Legal Hold) 來套用。對於需要將會計紀錄保存一年頻繁存取、九年封存，且十年內不得刪除的情境，正確的模式是在合規模式下使用 Object Lock 並設定十年保留期，再結合生命週期政策在第 365 天將物件轉換至 Deep Archive。治理模式不能作為法律強制規定的可接受替代方案——監管機構不會接受「有權限的人本來可以刪除這個」作為不可變性的說法。

若要透過單一作業將保留設定套用到現有的大量 PDF 檔案，請使用由 S3 Inventory 清單驅動的 S3 Batch Operations。對於跨越數十億個物件金鑰的大規模變動——如設定保留、標記、PUT-copy 重新加密、Lambda 叫用——Batch Operations 是託管的解決方案；手動編寫的迭代腳本並不是正確的模式。

加密：SSE-S3、SSE-KMS 與 Bucket Keys

每個儲存桶都有預設加密。SSE-S3 (AES-256，由 S3 管理的金鑰) 是免費的，且無需金鑰管理。SSE-KMS 使用 KMS 客戶主金鑰 (CMK)，能夠提供每個金鑰的 CloudTrail 稽核軌跡、基於 IAM 的金鑰存取政策，以及金鑰輪替控制——但代價是 KMS API 的費用，以及更關鍵的，可能會成為高吞吐量讀取工作負載瓶頸的 KMS 請求節流。只有當您確實需要這些控制（例如法規證明、職責分離、跨帳戶金鑰共享）時，才選擇 SSE-KMS。為了「安全起見」而預設使用 SSE-KMS，在 SSE-S3 已能滿足要求的情況下，只會增加不必要的成本和複雜性。

S3 Bucket Keys 解決了 SSE-KMS 的請求成本問題。S3 會從 CMK 產生一個短期的儲存桶級金鑰，並在本地端衍生出每個物件的資料金鑰，避免了對每個物件都進行 KMS GenerateDataKey/Decrypt 呼叫，並將 KMS 請求成本降低高達 99%：

"ServerSideEncryptionConfiguration": {
  "Rules": [{
    "ApplyServerSideEncryptionByDefault": {
      "SSEAlgorithm": "aws:kms",
      "KMSMasterKeyID": "arn:aws:kms:..."
    },
    "BucketKeyEnabled": true
  }]
}

當需求強制要求使用 KMS 時，為了「避免 KMS 成本」而切換到 SSE-S3 是錯誤的權宜之計——Bucket Keys 在無需放棄 KMS 的情況下，同時滿足了合規性和成本目標。

啟用儲存桶預設加密可確保所有未來的上傳都經過加密（未加密的 PUT 會被透明地加密）。要直接拒絕未加密的 PUT，請拒絕缺少以下標頭的寫入：

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "StringNotEquals": {
      "s3:x-amz-server-side-encryption": "AES256"
    }
  }
}

預設加密對現有的未加密物件沒有任何作用。請透過 S3 Inventory + Batch Operations 執行一個 Copy 作業來重新加密它們，就地覆寫每個物件——這是標準的大量重新加密模式。

臨時性的用戶端加密不如預設加密加上 KMS：它將金鑰管理分散到各個應用程式團隊，無法透過 CloudTrail KMS 事件進行集中稽核，也無法使用 Bucket Keys。

跨區域複寫與多區域 KMS 金鑰

跨區域複寫 (Cross-Region Replication, CRR) 會非同步地將物件複製到不同區域的儲存桶，用於合規、災難復原 (DR) 或降低延遲。同一區域複寫 (Same-Region Replication, SRR) 用於合規分離、日誌彙總和跨帳戶複製。兩者都需要在來源和目標儲存桶上啟用版本控制，以及一個供來源儲存桶擔任的 IAM 角色。每當儲存桶必須鏡像到另一個區域時，CRR 是低工作量的解決方案——編寫 aws s3 sync 腳本、在 ObjectCreated 事件上連接 Lambda、或執行排程的批次複製，都會引入營運開銷、競爭條件和靜默失敗。預設情況下，CRR 和 SRR 都不會複寫現有的物件；請使用 S3 Batch Replication 進行回填。

加密互動是設計上常見的失敗點：

• SSE-S3 物件會透明地複寫。
• SSE-KMS 物件預設不會被複寫——您必須明確選擇加入，指定一個位於目標區域的目標 KMS 金鑰，並授予複寫角色來源金鑰的 kms:Decrypt 權限和目標金鑰的 kms:Encrypt 權限。單一區域金鑰無法加密另一個區域中的物件。
• 用戶端加密的物件會以不透明的密文形式複寫；除非用戶端的金鑰材料在目標區域可用，否則目標區域無法從中獲益。

管理兩個獨立 CMK 的歷史性摩擦，已由 AWS KMS 多區域金鑰解決，它能在多個區域中呈現相同的金鑰材料和金鑰 ID (帶有區域前綴)。複寫的物件隨後可以在目標區域解密，無需跨區域的 KMS 呼叫，也無需重新包裝資料金鑰。這是加密、複寫的儲存桶在區域性容錯轉移中必須保持可用的標準模式。

在客戶管理的 KMS 金鑰下進行跨帳戶快照和物件共享，需要目標帳戶的主體透過金鑰政策持有來源金鑰的 kms:Decrypt、kms:CreateGrant、kms:DescribeKey 和 kms:ReEncrypt* 權限，再加上相符的 IAM 權限。AWS 管理的金鑰 (例如 aws/ebs、aws/s3) 無法跨帳戶共享，因此客戶管理的金鑰對於跨帳戶工作流程是強制性的。

封鎖公開存取與限制對 CloudFront 的存取

S3 封鎖公開存取 (BPA) 有四個設定 — 封鎖新的公開 ACL、忽略現有的公開 ACL、封鎖新的公開儲存貯體政策、限制公開儲存貯體政策 — 這些設定可在每個儲存貯體上設定，更重要的是，可在帳戶層級設定。帳戶層級的 BPA 會優先於任何授予公開存取的儲存貯體政策，並且是實現「此帳戶中任何物件都不得公開」的正確控制措施。僅靠儲存貯體層級的政策是不可靠的：新建立的儲存貯體可能會在沒有政策的情況下啟動；而帳戶層級的 BPA 則採預設關閉（最安全）模式。

為防止成員帳戶中的管理員停用 BPA，請在 Organizations OU 或根目錄層級加上一個服務控制政策 (Service Control Policy)：

{
  "Effect": "Deny",
  "Action": "s3:PutAccountPublicAccessBlock",
  "Resource": "*",
  "Condition": {
    "Bool": { "aws:PrincipalIsAWSService": "false" }
  }
}

若要僅透過 CloudFront 提供 S3 內容，請將 來源存取控制 (Origin Access Control, OAC) — 這是取代舊版 OAI 的現代化方案 — 附加到分發上，並在儲存貯體政策中以該分發的 ARN 作為條件閘控：

{
  "Effect": "Allow",
  "Principal": { "Service": "cloudfront.amazonaws.com" },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "StringEquals": {
      "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E123"
    }
  }
}

儲存貯體上的 BPA 保持啟用。對於特定使用者對私有物件的限時存取（上傳/下載到期），可產生一個 預先簽章 URL，其內嵌的簽章會繼承簽署主體的權限。

私有網路路徑：閘道端點

在 VPC 內的 EC2 到 S3 流量不會自動使用 AWS 私有骨幹網路。若未經設定，S3 API 呼叫會解析到公有端點，並通過網際網路閘道或 NAT 閘道，這會產生 NAT 資料處理費用，並將流量暴露於網際網路上。S3 的閘道 VPC 端點 (以及 DynamoDB 的) 是免費的，它會作為一個字首清單路由新增到指定的路由表中，並將流量保留在 AWS 網路內。S3 也存在介面端點 (PrivateLink)，但需要付費，適用於從地端透過 Direct Connect 發起的存取。將端點與儲存貯體政策中的 aws:SourceVpce 條件配對，以強制儲存貯體只能從經核准的 VPC 端點連線 — 這是受監管工作負載的標準模式。

Object Lambda 用於即時轉換

S3 Object Lambda 會在 GET/HEAD/LIST 的路徑中插入一個 Lambda 函數，以便在讀取時轉換回傳給呼叫者的物件。這避免了為每種變體（如修訂、調整大小、重訂格式）複製資料，並在底層儲存貯體中保持單一事實來源。典型用途包括：為分析師提供 PII 修訂後的資料，同時為稽核人員提供完整資料、為每個使用者加上圖片浮水印、為舊版用戶端將 XML 轉換為 JSON。IAM 和儲存貯體政策仍然對底層物件進行閘控；Lambda 函數只能看到其執行角色所允許的內容。

事件通知

S3 會將事件（如 s3:ObjectCreated:*、s3:ObjectRemoved:*、複寫與生命週期事件）發送到 Lambda、SQS、SNS 或 EventBridge。當您需要多個目標、根據物件中繼資料進行篩選或進行跨帳戶路由時，建議優先使用 EventBridge；對於像上傳時生成縮圖這樣的單一目標管線，直接通知則更簡單且成本更低。通知是「至少一次」(at-least-once) 的傳遞，因此消費者必須具備冪等性。

輸送量優化：分段上傳與傳輸加速

對於超過 100 MB 的物件，分段上傳是最佳實務；超過 5 GB 則是強制性的。各個部分會平行上傳，失敗的部分會獨立重試，輸送量會隨著並行性擴展。在下載方面，位元組範圍 GET (Byte-range GETs) 提供了同等的平行處理能力。如前所述，務必附加一個 AbortIncompleteMultipartUpload 生命週期規則，以避免為孤立的組件支付費用。

S3 Transfer Acceleration 會透過 AWS 骨幹網路，將上傳流量路由到最近的 CloudFront 邊緣節點 — 這適用於全球分佈的用戶端上傳到單一儲存貯體的情況。對於下載，則在 S3 前端加上 CloudFront 以在邊緣進行快取。Transfer Acceleration 是以上傳為導向；CloudFront 則是以載為導向；它們解決了相關但不同的問題。

EBS：磁碟區類型、加密與快照

EBS 磁碟區是限定在單一 AZ、掛載到單一 EC2 執行個體的區塊裝置。gp3 是預設的通用型 SSD；它相較於 gp2 的關鍵優勢在於 IOPS (最高 16,000) 和吞吐量 (最高 1,000 MiB/s) 是與容量獨立佈建的，這消除了 gp2 那種為了達到效能目標而過度佈建儲存空間的反模式。io2 Block Express 為對延遲敏感的資料庫提供高達 256,000 的 IOPS 和次毫秒級的延遲。st1 和 sc1 是以 HDD 為基礎，適用於吞吐量導向的循序與冷工作負載。io1/io2 上的 Multi-Attach 功能雖然存在，但僅限於在同一個 AZ 中，最多 16 個執行叢集感知檔案系統的執行個體使用——這是一個狹窄的特例，並非通用的「共享 EBS」模式。試圖將 EBS 廣泛地掛載到多個執行個體（例如，負載平衡器後方的執行個體）是個概念上的根本錯誤，因為每個磁碟區都是私有的區塊裝置，這會確切地產生「重新整理後有些文件可見，有些卻不行」的症狀。

EBS 磁碟區使用由 KMS 包裝的資料金鑰，以 AES-256 進行靜態加密。加密過程是透明的——沒有效能損失，也無需變更應用程式。一旦磁碟區被加密，其衍生的快照和磁碟區也都會被加密；您無法就地解密。在每個 Region 預設啟用 EBS 加密，如此一來，無論開發人員是否記得，每個新建立的磁碟區和快照都會被加密：

aws ec2 enable-ebs-encryption-by-default --region us-east-1
aws ec2 modify-ebs-default-kms-key-id \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...

現有的未加密磁碟區不會被回溯加密——修復程序需要先建立快照、複製並加密快照，然後再從加密後的快照建立新的磁碟區。

快照是儲存在 S3 管理的基礎設施上的增量區塊級備份——但它們並非免費（您需要為保留的已變更區塊付費）、在來源磁碟區被刪除時它們不會消失，且當參考它們的 AMI 被取消註冊時，它們也不會被移除。透過 aws ec2 modify-snapshot-tier、Amazon Data Lifecycle Manager (DLM) 或 AWS Backup，將它們轉移至 EBS Snapshots Archive 層（便宜 75%，還原時間 24-72 小時）。Fast Snapshot Restore (FSR) 會在特定的 AZ 中預熱快照，以便從它啟動的執行個體能立即提供完整效能——對於需要處理快速向外擴展的自動擴展群組後方的 AMI，應啟用此功能。

資源回收桶 會將刪除的 EBS 快照和 AMI 保留在一個還原視窗（1 天到 1 年）內。若沒有它，快照的刪除是立即且永久的：

aws rbin create-rule \
  --retention-period RetentionPeriodValue=30,RetentionPeriodUnit=DAYS \
  --resource-type EBS_SNAPSHOT \
  --description "30-day snapshot recovery"

僅僅依賴每日的 EBS 快照來進行長期合規性資料保留是一個常見的架構錯誤——快照的定價較接近暖儲存，且需要明確的封存轉換操作。

Amazon EFS：適用於 Linux 叢集的共享 POSIX 檔案系統

EFS 是一個全託管、彈性、符合 POSIX 規範的 NFSv4.1 檔案系統，可從一個 Region 內跨多個 AZ 的數千個 EC2、ECS、EKS 或 Lambda 用戶端同時掛載，也可透過 Direct Connect 或 VPN 從地端主機掛載。其決定性的特性是，所有用戶端能同時看到完全相同的檔案系統，具有相同的檔案控制代碼和位元組級語意。因此，當負載平衡器後方的 Linux 叢集必須共享一組通用檔案時——例如使用者上傳的檔案、設定檔、共享的家目錄——EFS 就是正確的解決方案。

掛載目標存在於您設定的每個 AZ 子網路中。amazon-efs-utils 輔助工具可啟用傳輸中 TLS 加密和 IAM 掛載授權：

sudo mount -t efs -o tls,iam fs-0123456789abcdef0:/ /mnt/shared

EFS 儲存類別橫跨兩個維度。生命週期管理 會將 7-90 天未存取的檔案從 Standard 分層到 Infrequent Access，並可選擇性地再分層到 Archive，最高可節省 92% 的儲存成本；Intelligent-Tiering 會在檔案被存取時將其移回。One Zone 類別將資料儲存在單一 AZ 中，成本降低約 47%——這適用於開發/測試或可重製的資料，但絕不適用於在 AZ 故障期間無法接受資料遺失的場景。對於一個已經在使用 EFS Standard-IA 的工作負載，一個成本優化的作法是切換到 EFS One Zone-IA，而無需任何應用程式變更。

效能有兩個獨立的控制選項。效能模式（於建立時設定）：通用模式 (General Purpose) 延遲最低，適用於元資料密集的網站服務；最大 I/O (Max I/O) 是一個已被彈性模式取代的舊選項。吞吐量模式：突發模式 (Bursting) 隨容量大小擴展（基準線為每 GB 50 KB/s，低於基準線時可累積突發額度）、已佈建模式 (Provisioned) 支付固定的 MB/s，與容量大小無關，而 彈性模式 (Elastic)——目前的預設選項——會自動擴展至 10+ GB/s，無需進行容量規劃。一個小型檔案系統在持續負載下可能會耗盡突發額度，並被節流至很低的基準線，因此，佔用空間小但 I/O 繁重的工作負載必須使用彈性模式或已佈建模式。

EFS 不能替代高 IOPS 的區塊儲存。每一次 EFS 的 I/O 都是一次透過網路的 NFS RPC 呼叫，因此，單一寫入者、次毫秒級、交易日誌型的工作負載應使用 EBS io2 Block Express——單一磁碟區即可提供 256,000 IOPS 和次毫秒級延遲，這是 EFS 在單次操作基礎上無法比擬的。與 Deep Archive 相比，EFS 用於儲存冷資料的價格也過於昂貴；僅僅「因為方便」而將合規性資料保留在 EFS 上是站不住腳的。

FSx: Windows、Lustre、ONTAP、OpenZFS

FSx 是一系列的受管檔案系統，可根據協定與工作負載來選擇：

FSx for Windows File Server 提供原生的 SMB 2.0/3.1.1，並支援 NTFS ACLs、DFS Namespaces、陰影複製 (shadow copies)，以及透過 Active Directory 的 Kerberos 驗證。Multi-AZ 部署會在一個 AZ 中部署一台作用中的檔案伺服器，並在另一個 AZ 中部署一台同步複製的備援伺服器，透過單一的容錯移轉 DNS 名稱存取。AD 整合是必要選項：FSx 必須加入 AWS Managed Microsoft AD 或一個可連線的自管理 AD，且用戶端必須以網域使用者的身分，根據網域 SID 進行驗證。若略過 AD，或讓用戶端指向一個位於不受信任樹系且未建立跨樹系信任的檔案系統，會產生典型的「看得到分享卻存取被拒」的症狀。對於 Windows 檔案分享的直接遷移 (lift-and-shift) 來說，FSx for Windows 是個可以直接對應的目標。

FSx for Lustre 是一個為 HPC、ML 訓練、EDA 和基因組學設計的平行 POSIX 檔案系統——支援數千個用戶端、數百 GB/s 的吞吐量，以及毫秒以下的元資料延遲。其關鍵的 AWS 功能是與 S3 的資料儲存庫關聯：物件金鑰會以檔案的形式出現在 Lustre 命名空間中，並在首次存取時延遲載入 (或透過 hsm_restore 預先載入)；新增/修改的檔案會依排程或隨需匯出回 S3。典型的高效能運算模式如下：

1. 將本地資料集複製到 S3 (透過 DataSync 或 Storage Gateway)。
2. 建立連結到該儲存貯體的 Lustre。
3. 掛載到所有 Spot 背景工作角色上；以線速讀取輸入、寫入輸出。
4. 將結果匯出到 S3，S3 作為持久的長期儲存庫。
5. 工作結束時刪除 Lustre 檔案系統。

Lustre 的 Scratch 部署類型沒有複寫，硬體故障時會遺失資料——這是最便宜且最快的選項，適用於暫時性的工作資料。Persistent 部署類型則會在單一 AZ 內進行複寫，以獲得更高的持久性。吞吐量以每 TiB 多少 MB/s (50/125/250/500/1000) 來佈建，將容量與效能脫鉤。

FSx for NetApp ONTAP 是多重協定的解決方案：可在相同的資料上同時提供 NFS、SMB 和 iSCSI 存取，並具備快照、SnapMirror 複寫、FlexClones 和重複資料刪除等功能。當您需要整合混合的 Linux NFS 和 Windows SMB 分享，且需要跨協定存取與 Multi-AZ 備援時，或當您要從本地 NetApp 遷移時，請選擇 ONTAP。FSx for OpenZFS 則填補了 Linux 工作負載的一個特定需求，即透過 NFS 使用 ZFS 的功能 (如快照、複本)。不要將 ONTAP 的多重協定強項與其他類型混淆。

選擇錯誤會導致明確的失敗：將 EBS 用於共享工作負載、將 EFS 用於 Windows SMB 分享，或將 Lustre 用於需要 AD 整合的 Windows 分享，這些都是不合適的選擇——應優先匹配協定與存取模式。

Storage Gateway: 混合雲存取

Storage Gateway 呈現雲端儲存，使其看起來像在本地。這與移動資料的 DataSync 不同。

對於一個已將其媒體庫移至 S3，但仍需要在本地進行低延遲讀取的渲染應用程式來說，S3 File Gateway 是合適的選擇——它提供 NFS/SMB 存取、本地快取，並隨需從 S3 擷取冷門物件。FSx File Gateway 則是分公司的解決方案：它是中央雲端 FSx 分享的 LAN 速度 SMB 快取，而不是為了解決 EC2 執行個體之間 的共享存取問題 (EC2 執行個體應該直接掛載 FSx)。當工作負載使用區塊 iSCSI 而非檔案語意時，應採用 Volume Gateway。Tape Gateway 則是在現有的備份軟體下取代實體磁帶櫃。

資料傳輸與遷移

AWS DataSync 是一種基於代理程式的線上遷移服務，可將 NFS、SMB、HDFS 和物件儲存的資料遷移至 S3、EFS 或 FSx——速度比開源工具快上 10 倍，並提供加密、完整性驗證、排程，以及保留 POSIX 元資料和 NTFS ACLs。對於具有數百萬個小檔案和深層階層的大規模 SMB 遷移，開銷最小的解決方案是使用 DataSync 遷移至 FSx for Windows：SMB 得以保留、ACLs/時間戳記保持不變、透過平行傳輸處理小檔案的吞吐量，且無需更改應用程式。將這樣的資料集直接遷移到 S3 是一個陷阱——物件儲存處理深層前綴中的小檔案列表效能不佳，且 SMB 用戶端無法掛載儲存貯體。

AWS Snow Family 為離線傳輸提供實體設備：Snowcone (最高 8 TB，邊緣運算強化型)、Snowball Edge (最高約 80 TB 可用空間，附帶運算選項)，以及 Snowmobile (EB 等級規模)。經驗法則是：如果網路傳輸需要超過一週，Snowball 會更便宜也更快。

AWS Transfer Family 提供由 S3 或 EFS 支援的 SFTP、FTPS、FTP 和 AS2 服務——當外部合作夥伴必須繼續使用標準檔案傳輸協定時，這是正確的解決方案。

AWS Backup、跨區域複寫與 Vault Lock

AWS Backup 集中管理 EBS、EFS、FSx、RDS、DynamoDB、S3 等服務的政策。備份計畫定義了排程、暖儲存保留期、轉換至冷儲存的時間，以及跨區域/跨帳戶的複寫動作：

BackupPlan:
  Rules:
    - RuleName: DailyWithDRCopy
      TargetBackupVault: prod-vault
      ScheduleExpression: "cron(0 5 * * ? *)"
      Lifecycle:
        MoveToColdStorageAfterDays: 30
        DeleteAfterDays: 2555        # 7 years
      CopyActions:
        - DestinationBackupVaultArn: arn:aws:backup:eu-west-1:...:backup-vault:dr-vault
          Lifecycle:
            MoveToColdStorageAfterDays: 30
            DeleteAfterDays: 2555

轉換至冷儲存至少需要 90 天的暖儲存保留期，再加上至少 90 天的冷儲存期；設定錯誤的生命週期將會被拒絕。若要實現真正的多年法規遵循保留，請搭配使用 AWS Backup Vault Lock (WORM)，它能防止連管理員都縮短保留期——從而滿足 SEC 17a-4 及類似法規的要求。跨區域複寫可應對區域性的災難復原 (DR)；跨帳戶複寫則透過將備份與生產帳戶的爆炸半徑隔離，來應對勒索軟體和內部威脅的情境。

選擇速查表

← 無伺服器與事件驅動架構 · 所有領域 · 資料傳輸與遷移 →

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

瀏覽 Amazon →