💡 先搞懂問題
虛構的「青松物流」把三種資料都丟進 Amazon S3：每天要給客服查的出貨單據、只在稽核時才翻的系統日誌，以及法規要求保存七年的合約掃描檔。剛開始一切都放在預設的 S3 Standard，帳單每個月照資料量線性往上爬。後來有人為了省錢，把整個儲存貯體的物件都改成最便宜的 S3 Glacier Deep Archive，結果客服第二天要調一張上個月的單據，發現要先發「還原」請求、最久得等 12 小時才拿得到。又有一次，批次程式把同名的合約檔覆寫成空白檔，因為沒開版本控制，原本的內容就此消失。
這三次事故分別對應 S3 的三組設定。儲存類別（storage class）決定每個物件放在哪一種計費與取用方式：越冷的類別儲存費越低，但讀取時要多付擷取費（retrieval fee），有最短儲存期間（minimum storage duration），最冷的兩種還要先還原（restore）才能讀。生命週期規則（lifecycle rule）讓物件依建立後的天數自動轉換到較冷的類別或到期刪除，不必靠人記得去搬。版本控制（versioning）讓覆寫與刪除都留下舊版本，Object Lock 則讓指定的版本在一段期間內任何人都刪不掉、改不了。
生活比喻：一間分區計租的倉庫
想像青松物流在郊區租了一間大型倉庫。門口的常用區租金最高，但貨拿了就走、不另收費；後排貨架租金便宜將近一半，可是每次從後排調貨，倉庫都要收一筆搬運費，而且合約寫明每批貨最少計 30 天租金，放三天就搬走也照收 30 天。同一園區還有一棟只靠單一建築的特價貨架，再便宜一點，但那棟樓如果淹水，裡面的貨就沒了。地下保管區更便宜，隨叫隨到，只是每次搬出來的費用最高。最便宜的是幾十公里外的遠端倉庫：平常幾乎不用付什麼租金，但要拿貨得先打電話預約，幾分鐘到半天以上才送到，最遠的那間甚至要等到隔天。
倉庫還提供兩種服務。一種是倉管員：他會看每箱貨的進出紀錄，一個月沒人碰的自動移到後排，三個月沒人碰的再移進地下保管區，有人來拿又搬回門口，每箱收一點管理費。另一種是牆上的搬移排程表：入庫 30 天後移到後排、120 天後送遠端倉庫、一年後銷毀，照表自動執行。至於防止貨被誤丟，倉庫的做法是「每次換貨都保留舊箱並編上版本號」，有人說要丟掉，倉管只會在最上面貼一張「已出庫」的標籤；真正重要的箱子再貼上封條，寫明保全到哪一天，期限沒到誰都不能拆。
再看版本控制：覆寫和刪除，到底留下了什麼
S3 的物件用鍵（key）識別，例如 contracts/2026/A-1024.pdf。沒有開版本控制時，對同一個鍵再上傳一次就是直接取代，舊內容不會留下；刪除也是真的刪除。開了版本控制以後，每次上傳都產生一個新的版本 ID（version ID），舊的變成非目前版本（noncurrent version）；不指定版本的刪除不會刪掉任何資料，只是在最上面疊一個刪除標記，讓這個鍵「看起來不存在」。只有指定版本 ID 的刪除，才會真正把那個版本永久移除，這也正是 Object Lock 要擋住的動作。
這個比喻有幾個地方和實際不同。第一，「遠端倉庫」不是另一個區域：所有儲存類別都在你建立儲存貯體的那個區域（Region）裡，One Zone-IA 以外的類別都把資料放在至少 3 個可用區域；要把資料放到另一個區域，得另外設定 S3 複寫。第二，最短儲存期間不是「鎖住不能動」，而是提早刪除、覆寫或轉出時要補收剩餘天數的費用；真正能鎖住物件的只有 Object Lock。第三，倉庫可以把遠端的貨搬回門口，但生命週期規則只能把物件往冷的類別轉，要把封存的資料變回常用，得先還原再複製成新物件。第四，版本控制保留的舊版本仍在同一個儲存貯體裡，有權限的人照樣可以指定版本永久刪除，所以它防的是誤刪與誤覆寫，不是取代異地備份。
🎮 互動實驗室一：七種儲存類別成本試算
先選一個情境，或自己拉滑桿：資料量、每月讀取量、保存天數（之後刪除）與物件平均大小。右邊會用示意單價算出七種儲存類別在整段保存期間的儲存費、提早刪除費與取用費（擷取費、請求費，Intelligent-Tiering 另含監控費）。示意單價的單位是「點」，只保留各類別之間大致的高低關係，不是實際價格；實際價格依區域與時間而不同，請以 Amazon S3 定價頁與 AWS Pricing Calculator 為準。下方的兩個勾選框代表兩個硬條件：讀取時必須毫秒回應、資料不能只放在一個可用區域。
一、輸入
| 示意單價（點） | 儲存 GB・月 | 擷取 GB | 請求千次 | 最短天數 | 最小計費 |
|---|
二、整段保存期間的總成本（示意）
儲存費 ＝ 計費量 × 儲存單價 × 保存天數 ÷ 30
提早刪除費 ＝ 計費量 × 儲存單價 × max(0, 最短天數 − 保存天數) ÷ 30
取用費 ＝ 保存月數 × ［每月讀取 GB × 擷取單價 ＋ 每月讀取物件數 ÷ 1000 × 請求單價］
最短儲存期間（Standard-IA、One Zone-IA 30 天；Glacier Instant Retrieval、Glacier Flexible Retrieval 90 天；Deep Archive 180 天）、最小計費物件大小 128 KB、Glacier Flexible 與 Deep Archive 每個物件 40 KB 中繼資料、Intelligent-Tiering 不監控小於 128 KB 的物件，依 Amazon S3 使用者指南「比較 S3 儲存類別」與「Intelligent-Tiering 的運作方式」，查證時間 2026 年 10 月。Intelligent-Tiering 的示意模型假設每月被讀取的是同一批熱門物件、其餘物件 30 天後進入不頻繁存取層、90 天後進入封存即時存取層（未啟用選用的封存層）。示意單價為本頁自訂的比例，不代表任何區域的實際價格。
🎮 互動實驗室二：版本控制與 Object Lock 時間軸
這個儲存貯體裡只有一個鍵 contracts/A-1024.pdf。左上切換版本控制狀態，右上決定要不要啟用 Object Lock 與預設保留設定，接著用下方按鈕上傳、覆寫、刪除，或在清單裡點選某個版本後還原、永久刪除、切換法務保留。每個版本旁邊會即時標出「現在能不能永久刪除」與原因；「時間快轉」可以讓保留期間過去。右下角的六個任務會在你做到時自動打勾。
儲存貯體版本控制（Bucket Versioning）
Object Lock（需要版本控制）
行為依 Amazon S3 使用者指南「使用版本控制」「使用刪除標記」「Object Lock」各章，查證時間 2026 年 10 月：保留期間與法務保留套用在個別物件版本上，不會阻止上傳新版本或加上刪除標記；治理模式要有 s3:BypassGovernanceRetention 權限並帶 x-amz-bypass-governance-retention:true 標頭才能略過；啟用 Object Lock 後無法停用，也不能暫停版本控制。版本 ID 為示意。
🛠️ 操作教學：建立儲存貯體並設定生命週期規則
不用登入 AWS，也能先把流程走一遍。左邊是簡化的管理主控台，照步驟填表、按按鈕；右邊同步顯示等效的 AWS CLI 與 CloudFormation，黃色底的那幾行就是目前這一步對應的指令。可以故意把儲存貯體名稱打錯，或把生命週期的天數排得太近，看驗證訊息怎麼說明；也可以改名稱、區域或加密方式，看指令怎麼跟著變。生命週期規則的 JSON 在「lifecycle.json」分頁。
AWS::S3::Bucket 資源把版本控制、加密、公開存取封鎖與生命週期都寫成屬性。用 CloudFormation 建立的資源，刪除堆疊就會一起刪除；但 S3 儲存貯體裡還有物件（含非目前版本）時刪不掉，堆疊會刪除失敗，要先清空。
自己動手時要注意
權限方面，建立與設定儲存貯體需要 s3:CreateBucket、s3:PutBucketOwnershipControls、s3:PutBucketPublicAccessBlock、s3:PutBucketVersioning、s3:PutEncryptionConfiguration、s3:PutLifecycleConfiguration，上傳要 s3:PutObject；啟用 Object Lock 另需 s3:PutBucketObjectLockConfiguration。選 SSE-KMS 時，上傳與下載的人還需要對那把 KMS 金鑰的 kms:GenerateDataKey 與 kms:Decrypt。用 CloudFormation 部署，執行者另外要有建立堆疊的權限。
費用方面，S3 依儲存量、請求次數、擷取量與資料傳出計費；生命週期每轉換一個物件都算一次轉換請求，所以大量小檔案轉換前要先算過；版本控制保留的每個舊版本都照樣計費；SSE-KMS 會產生 KMS 請求費，S3 Bucket Key 可以減少呼叫次數。2025-07-15 以後建立的帳戶採抵用金制度的 Free Tier，選「免費方案」的帳戶在 6 個月到期或抵用金用完時會自動關閉，練習前先確認自己的帳戶方案。練習完記得清理：開了版本控制的儲存貯體，要先在主控台用「清空」把所有版本與刪除標記刪掉，再刪除儲存貯體；用 CloudFormation 建立的，清空後刪除堆疊。
# 先在主控台對儲存貯體按「清空」（會刪除所有版本與刪除標記），再刪除儲存貯體
aws s3api delete-bucket --bucket qingsong-logs-2026 --region ap-northeast-1
# 用 CloudFormation 建立的：清空儲存貯體後刪除堆疊
aws cloudformation delete-stack --stack-name s3-lifecycle-lab --region ap-northeast-1範例裡的名稱都是示意。不要把存取金鑰寫進腳本或截圖；需要帳戶 ID 時用 111122223333 或 <your-account-id> 這類佔位字。日常操作用 IAM Identity Center 或 IAM 角色取得的短期憑證，而不是根使用者或長期存取金鑰。
📘 原理補完
七種儲存類別的正式定義
儲存類別設在每一個物件上，同一個儲存貯體裡可以混放；上傳時沒指定就是 S3 Standard。判斷時問三個問題：多久讀一次？讀的時候能不能等？要保存多久？下表依 Amazon S3 使用者指南整理（查證時間 2026 年 10 月）。所有類別的設計耐久度都是 99.999999999%（11 個 9），差別在可用性、存放的可用區域數與費用結構。
| 儲存類別 | 可用區域 | 設計可用性 | 最短儲存期間 | 最小計費 | 擷取費 | 取用時間 | 適合 |
|---|---|---|---|---|---|---|---|
| S3 Standard | ≥ 3 | 99.99% | 無 | 無 | 無 | 毫秒 | 經常讀取的資料、網站與應用程式內容 |
| S3 Intelligent-Tiering | ≥ 3 | 99.9% | 無 | 無（< 128 KB 不監控） | 無，另收監控費 | 毫秒（選用封存層除外） | 存取模式不明或會變動的資料 |
| S3 Standard-IA | ≥ 3 | 99.9% | 30 天 | 128 KB | 有 | 毫秒 | 約一個月讀一次、讀時要立即拿到 |
| S3 One Zone-IA | 1 | 99.5% | 30 天 | 128 KB | 有 | 毫秒 | 可重建的次要副本、縮圖 |
| S3 Glacier Instant Retrieval | ≥ 3 | 99.9% | 90 天 | 128 KB | 有（較高） | 毫秒 | 約一季讀一次的封存資料 |
| S3 Glacier Flexible Retrieval | ≥ 3 | 99.99%（還原後） | 90 天 | 每物件另加 40 KB | 有（Bulk 免費） | 分鐘～12 小時（先還原） | 一年讀一兩次、可以等的備份 |
| S3 Glacier Deep Archive | ≥ 3 | 99.99%（還原後） | 180 天 | 每物件另加 40 KB | 有 | 12～48 小時內（先還原） | 法規長期保存、幾乎不讀 |
另有兩個不在比較範圍的類別：S3 Express One Zone 是單一可用區域、個位數毫秒延遲的高效能類別，要放在目錄儲存貯體（directory bucket）裡；Reduced Redundancy Storage 是舊類別，官方不建議使用。名稱上要分清楚：S3 的三種 Glacier 儲存類別是現行的封存選項，而舊的 vault 型獨立服務 Amazon Glacier 已在 2025-11-07 起不收新客戶（maintenance），S3 Glacier Select 也在 2024-07-25 起不收新客戶。
Intelligent-Tiering：讓 S3 依實際存取自動搬
S3 Intelligent-Tiering 依每個物件實際被存取的情況自動移動：連續 30 天沒被存取的進入不頻繁存取層，連續 90 天沒被存取的進入封存即時存取層，一被存取就回到頻繁存取層，這三層都是毫秒取用。你還可以另外啟用兩個選用的封存層（至少 90 天未存取進封存存取層、至少 180 天未存取進深度封存存取層），這兩層就和 Glacier Flexible Retrieval、Deep Archive 一樣要先還原。它沒有擷取費、沒有最短儲存期間，代價是每個物件每月收監控與自動化費；小於 128 KB 的物件不會被監控，永遠放在頻繁存取層，也不收監控費。所以它最適合「物件夠大、存取模式說不準」的資料；如果你很確定資料 30 天後就沒人看，用生命週期規則直接轉 Standard-IA 或更冷的類別，省下監控費。
Glacier Flexible Retrieval 與 Deep Archive 的還原
這兩個類別的物件不能直接讀，要先發出還原（restore）請求，S3 會建立一份暫時副本，在你指定的天數內可以讀；原本的封存物件不動。還原速度分三種：Glacier Flexible Retrieval 的 Expedited 對 250 MB 以下的物件通常 1～5 分鐘、Standard 3～5 小時、Bulk 5～12 小時（Bulk 免擷取費）；Deep Archive 沒有 Expedited，Standard 在 12 小時內、Bulk 在 48 小時內。需要「隨時毫秒讀取」的封存資料，就不該放這兩類，而是放 Glacier Instant Retrieval。
生命週期規則：轉換、到期與清理
S3 生命週期組態（Lifecycle configuration）掛在儲存貯體上，最多可以有很多條規則。每條規則先用篩選條件挑物件（前綴、物件標籤、物件大小，或整個儲存貯體），再設定動作：轉換（Transition）把目前版本在建立後第 N 天轉到另一個類別；到期（Expiration）讓目前版本在第 N 天到期，在開了版本控制的儲存貯體裡，到期只會加上刪除標記；非目前版本轉換與到期依「變成非目前版本後幾天」處理舊版本；另外還能清除未完成的 multipart upload 與只剩自己的過期刪除標記。規則是非同步執行的，但只要條件一滿足，就開始以目標類別計費。
轉換只能往冷的方向走，形成一道「瀑布」：Standard 可以轉到任何較冷的類別；Standard-IA 可以轉到 Intelligent-Tiering、One Zone-IA 與三種 Glacier；One Zone-IA 與 Glacier Instant Retrieval 只能再往 Glacier Flexible Retrieval 或 Deep Archive；Glacier Flexible Retrieval 只能轉到 Deep Archive；Deep Archive 是終點。要把封存資料變回常用，得先還原，再把它複製成一個新的物件。
天數的限制有三個要分清楚。第一，轉到 Standard-IA 或 One Zone-IA 不再需要先在 Standard 放滿 30 天：AWS 在 2026-07-16 宣布取消這個限制，現在可以在物件建立當天（0 天）就轉換；很多舊教材與題目仍寫「至少 30 天」，看到時要知道那是 2026 年 7 月以前的規則。第二，同一條規則裡的連續轉換，要讓物件在中間那個類別待滿它的最短儲存期間：官方的例子是第 4 天轉 Glacier Instant Retrieval，那麼轉 Deep Archive 至少要在第 94 天（4 ＋ 90）；同理，第 30 天轉 Standard-IA 的話，下一次轉換至少要在第 60 天。拆成兩條規則可以繞過這個檢查，但提早轉出的費用照收。第三，小於 128 KB 的物件預設不會被轉換（2024 年 9 月起的預設行為），因為每個物件都要付一次轉換請求費，小檔案搬了反而虧；確實需要時，可以在規則裡加物件大小篩選條件覆寫。
版本控制的三種狀態
儲存貯體的版本控制只有三種狀態：未啟用（unversioned，預設）、啟用（Enabled）、暫停（Suspended）。一旦啟用過，就永遠回不到未啟用，只能暫停。暫停時，既有的版本都保留，但之後上傳的物件版本 ID 一律是 null，同一個鍵再上傳會取代那個 null 版本；不指定版本的刪除會放一個版本 ID 為 null 的刪除標記，並把原本的 null 版本刪掉。要真正清掉舊版本，就要指定版本 ID 刪除，或用生命週期的非目前版本到期規則。另一個常用的保護是 MFA Delete：啟用後，永久刪除版本或變更版本控制狀態都要提供 MFA 驗證碼，只能由根使用者透過 API 或 CLI 設定。
Object Lock：保留期間與法務保留
S3 Object Lock 提供 WORM（write once, read many，一次寫入、多次讀取）保護，前提是儲存貯體已啟用版本控制；可以在建立時啟用，也可以對既有的儲存貯體啟用，但啟用後就無法停用。保護作用在個別物件版本上，同一個鍵的不同版本可以有不同的保留設定；它擋的是「改寫或永久刪除這個版本」，不擋上傳新版本、也不擋加上刪除標記。
| 保護方式 | 期限 | 誰能提前解除 | 適合 |
|---|---|---|---|
| 治理模式（Governance） | 保留到指定日期 | 有 s3:BypassGovernanceRetention 權限、且請求帶 x-amz-bypass-governance-retention:true 標頭的人 | 內部政策、先測試保留設定 |
| 合規模式（Compliance） | 保留到指定日期，不能縮短、不能改模式 | 沒有人，包括根使用者；唯一方法是關閉整個 AWS 帳戶 | 法規要求的不可竄改保存 |
| 法務保留（Legal hold） | 沒有到期日，直到被移除 | 有 s3:PutObjectLegalHold 權限的人可以設定或移除 | 訴訟、調查期間凍結資料 |
判斷步驟
- 先看讀取頻率與能不能等：常讀選 Standard；不常讀但要毫秒取得選 Standard-IA 或 Glacier Instant Retrieval；可以等數小時選 Glacier Flexible Retrieval 或 Deep Archive。
- 說不準存取模式、物件又大於 128 KB，選 Intelligent-Tiering，省去猜天數。
- 檢查保存天數：比最短儲存期間短，就留在 Standard。
- 檢查物件大小：大量小於 128 KB 的物件，IA 類別會被最小計費拖累，封存類別會被每物件 40 KB 中繼資料拖累，先打包再封存。
- 資料可以重建、又在意成本，才考慮 One Zone-IA；它不耐可用區域損毀。
- 用生命週期規則把「幾天後轉、幾天後刪」寫下來；連續轉換之間要讓物件在中間類別待滿最短儲存期間，開了版本控制要記得清理非目前版本與未完成的 multipart upload。
- 防誤刪開版本控制；法規要求不可竄改用 Object Lock 合規模式；要跨區域保存一份用 S3 複寫或 AWS Backup。
容易考錯的地方
最短儲存期間等於鎖定期：不是。物件隨時能刪，只是提早刪除或轉出要補收剩餘天數；真正鎖住物件的是 Object Lock。題目寫「資料只保存 7 天」，放 Standard-IA 反而更貴。
Glacier 類別都要等：Glacier Instant Retrieval 是毫秒取用，只是擷取費較高；要先還原、等分鐘到小時的是 Glacier Flexible Retrieval 與 Deep Archive。題目寫「一季讀一次、讀時要立即拿到」選 Instant Retrieval。
One Zone-IA 和 Standard-IA 一樣可靠：耐久度設計同樣是 11 個 9，但資料只放在一個可用區域，可用區域損毀時資料會遺失，可用性也較低（99.5%）。干擾選項常把它包裝成「最便宜的不常用類別」。
Intelligent-Tiering 一定最划算：它要收每物件監控費，小於 128 KB 不監控也不會降層；存取模式已知且穩定時，生命週期規則往往更便宜。
生命週期能把資料搬回 Standard：不行，只能往冷的方向；要回來得還原後複製。另外，「轉 Standard-IA 前要先放 30 天」的限制已在 2026-07-16 取消。
刪除就是刪除：開了版本控制，不指定版本的刪除只加刪除標記，移除那個標記就能救回；Object Lock 也擋不住刪除標記，只擋指定版本的永久刪除。
Object Lock 可以後來關掉、合規模式可以縮短：都不行。啟用 Object Lock 後不能停用、不能暫停版本控制；合規模式的保留期只能延長。
相關考試：CLF-C02、SAA-C03、SOA-C03、DEA-C01 的 in-scope 服務清單都列出 Amazon S3 與 Amazon S3 Glacier（SOA-C03 只列 Amazon S3）；DEA-C01 另在資料生命週期任務點名 S3 Lifecycle 與版本。
✅ 自我檢測
6 題原創題，選完立即顯示對錯與解析，全部作答後會出現總分。目前得分：0 / 6