【Day 15】Azure Blob Storage & Tiers：資料金庫的分層經濟學 feat. AWS 雙強對照

系列專欄：從 AWS 視角征服 Azure：AZ-900 30 天通關實戰
難度指數：★★★★☆
今日任務：Storage Account → Container → Blob 三層、Hot/Cool/Cold/Archive、Archive rehydration、早期刪除費用、LRS/ZRS/GRS/GZRS 與 AWS S3 對照。

🎯 前言與今日目標

Day 14 我們在網路要塞部署了流量調度器；今天，CTO 把一座更大的寶庫交給 Titan 科技的 Chief Cloud Architect：每天產生的圖片、影片、稽核日誌與備份，如何既可靠又不讓帳單失控？

把所有資料放在 Hot，就像把五年份的稽核錄影全部放在辦公桌上：拿取很快，卻浪費昂貴的空間。反過來，所有資料都丟進 Archive，遇到即時事故時又可能因為取回要等數小時而延誤決策。更危險的是，若直接用單一 Storage Account 承載不同合規需求，備援設定是帳戶層級共用，錯誤的設定會擴大故障的 Blast Radius（爆炸半徑）。

今天要建立一個可落地的判斷鏈：先辨認物件的存取頻率與可接受延遲，再選 Access Tier；接著依故障邊界選備援；最後用生命週期管理自動搬移，並以 Microsoft Learn 現行內容校準新考綱新增的 Cold tier。

📚 Part 1：0.5 小時觀念裝備（AWS ↔ Azure 深度對照）

📐 Blob Storage 三層與資料流架構圖

┌────────────────────────────────────────────────────────────┐
│ Storage Account / namespace / LRS ZRS GRS GZRS             │
└────────────────────────────────────────────────────────────┘
                              |
                              v
┌────────────────────────────────────────────────────────────┐
│ Container / logical group / access boundary                │
└────────────────────────────────────────────────────────────┘
                              |
                              v
┌────────────────────────────────────────────────────────────┐
│ Block Blob / access tier: Hot Cool Cold Archive            │
│ image / video / log / backup objects                       │
└────────────────────────────────────────────────────────────┘

💡 架構師重點筆記：Container 不是檔案系統磁碟區，Blob 也不是可直接掛載的檔案。Access tier 可由帳戶設定預設值，也可在 Block Blob 層級覆寫；redundancy 則是 Storage Account 邊界。若兩批資料需要不同備援策略，應拆到不同 Account，避免一次變更影響所有服務。

🧱 Azure Blob 的三層心智模型

1. Storage Account（儲存體帳戶）：管理端點、命名空間、網路與資料備援。一般用途 v2 帳戶可承載 Blob、Files、Queue、Table；帳戶的 redundancy 設定會套用到帳戶內的儲存服務。
2. Container（容器）：Blob 的邏輯群組與授權範圍。可用 Microsoft Entra ID、RBAC、SAS 與儲存體防火牆控制存取；不要把 Account Key 寫進原始碼或映像檔。
3. Blob（Blob 物件）：實際的非結構化資料。Block Blob 適合文件、圖片、影片；本日的 Access Tier 主要討論 Block Blob。Append Blob 與 Page Blob 不支援這組分層。

🧭 Hot、Cool、Cold、Archive 怎麼選？

Cool、Cold 是 online tier，可以立即讀寫；Archive 是 offline tier，只能讀取中繼資料與標籤，資料本體必須先用 Set Blob Tier 或 Copy Blob 取回到 Hot、Cool 或 Cold。對 10 GB 以下物件，標準優先級的取回可能最多 15 小時；高優先級通常可少於一小時，但更貴且受帳戶容量與需求影響，不能把「高優先級」當成即時 SLA。

最低保存期不是保留政策。若一個 Blob 在 Cool 存 21 天便刪除，可能按剩餘 9 天計算早期刪除費；Archive 存 45 天就移出，可能按剩餘 135 天計費。覆寫、整個物件重寫或換層也可能觸發費用。設計生命週期規則時，必須把「資料真的會留多久」和「多久會被讀」一起估算，否則儲存費省下來，存取與提早刪除費反而超支。

🛡️ 備援：先定義故障邊界，再談 11 個 9

GRS/GZRS 的跨 Region 複寫是非同步的，所以它不是零資料遺失保證，也不是備份的替代品；誤刪除與覆寫通常會被複寫到副本。對需要跨區讀取的災備讀取路徑，才考慮 RA-GRS 或 RA-GZRS，並在應用層處理讀取延遲與資料新鮮度。

☁️ AWS S3 ↔ Azure Blob：相似抽象，不是名稱一對一

雙雲的演進哲學相同：應用程式不應把儲存位置、密鑰與 tier 規則硬編碼；AWS 以 IAM、S3 Bucket Policy、Lifecycle 與 CloudFormation/CDK 管理，Azure 以 RBAC、SAS、Lifecycle 與 ARM/Bicep 管理。部署前先做 CloudFormation Change Set 或 ARM What-If，讓「把整個帳戶改成 Archive」這類高爆炸半徑變更先被審查。

📖 AZ-900 核心名詞解釋與速查

1. Access Tier（存取層）：依存取頻率與延遲選擇 Hot、Cool、Cold 或 Archive 的 Blob 成本層。
2. Cold tier（冷存取層）：新考綱納入的 online tier；資料至少建議保存 90 天，仍可快速取回，但存取費高於 Cool。
3. Archive tier（封存層）：offline tier；資料至少保存 180 天，讀取前要 rehydrate 到線上層。
4. Rehydration（重新水合／取回）：用 Set Blob Tier 或 Copy Blob 把 Archive Blob 帶回 Hot、Cool 或 Cold。
5. Early deletion charge（早期刪除費）：在最低保存期前刪除、覆寫或換層，按剩餘期間比例收費。
6. RA-GRS / RA-GZRS：在異地複本上提供唯讀端點；讀到的資料可能尚未追上主要端。

🎮 Part 2：1 小時實戰情境 Role-Play

🏛️ 情境背景：Titan 科技的合規影像金庫

Titan 科技的醫療影像平台每天上傳兩類 Blob：最近 30 天的診斷影像要供醫師立即查詢；五年份的稽核原檔依法保存，平常幾乎不讀，但稽核事件發生時必須取回。CTO 同時要求主要 Region 的 Zone 故障不能中斷寫入，Region 災難時還要有異地副本。為避免把不同 redundancy 硬塞進同一帳戶，我們允許建立兩個 Storage Account：影像帳戶負責線上查詢，歸檔帳戶負責長期保存。

🧩 決策任務

你會提出哪個方案？

• A. 所有 Blob 放 Hot + LRS，因為單一設定最容易維護。
• B. 建立影像用 ZRS 帳戶與歸檔用 GRS 帳戶；前者的 Blob 維持 Hot，後者由應用程式或資料管線搬移至 Archive。
• C. 所有 Blob 放 Archive + GZRS，最省儲存費且同時防 Zone 與 Region 故障。
• D. 最近影像用 Cold + LRS；稽核檔用 Cool + ZRS，因為所有 online tier 都可立即讀。

🎯 解題拆解與解析

✅ 正解：B

最近影像是高頻、低延遲讀取，Hot 合理；影像帳戶的 ZRS 以主要 Region 內跨 Zone 的同步複寫降低單一 Zone 故障風險。稽核檔能接受數小時取回，歸檔帳戶的 Archive + GRS 適合長期保存。兩個帳戶之間不能靠單一 Lifecycle rule 跨帳戶搬移，應由應用程式、Event Grid 或資料管線執行搬移，並先檢查最低保存期與取回費。

❌ 逐一陷阱分析

• A 錯在只看維運簡單：LRS 無法抵禦整個資料中心災害；全部 Hot 也讓五年份冷資料持續支付最高容量成本。故障時的 Blast Radius 是整個帳戶。
• C 錯在把 Archive 與 GZRS 混用：Archive 目前只支援 LRS、GRS、RA-GRS 帳戶，不能直接放在 GZRS 帳戶；而且 Archive 不是立即可讀。
• D 錯在反轉成本與韌性判斷：Cold 適合仍需快速取回的低頻資料，長期稽核資料若能等待應優先評估 Archive；LRS 也不符合 Zone 故障需求，ZRS 本身又不是跨 Region 災備。

🎯 Part 3：AZ-900 精選高頻真題解析

以下題目均以 Titan 情境重新撰寫，不複製題庫原文。ExamTopics 是社群回報來源，不是 Microsoft 官方題目；本文不把社群票數當成技術證據，答案以 Microsoft Learn 交叉驗證為準。

📝 真題 1：低頻但立即可取的 Blob 層級（ExamTopics 社群考點改寫）

Titan 將一批仍可能被查詢、但平常很少讀取的備份放入 Blob Storage。CTO 要求資料仍能立即取回，並接受比 Hot 高的讀取費。應選哪一層？

• A. Hot　B. Cool　C. Archive　D. Page Blob

┌──────────────────────────────────────────────┐
│ Access frequency: low                        │
│ Online + immediate read -> COOL              │
└──────────────────────────────────────────────┘
                       |
                       v
┌──────────────────────────────────────────────┐
│ Archive requires rehydration; Cool does not  │
└──────────────────────────────────────────────┘

💡 架構師重點筆記：先把「低頻」與「立即取回」兩個條件疊合；仍屬 online tier 就選 Cool，而不是只因為低頻便直接選 Archive。

答案：B。 關鍵字是「低頻、立即取回」：Cool 是 online tier；Archive 是 offline，必須先取回。A 的容量成本較高；C 有數小時延遲；D 是 Blob 類型，不是 Access Tier。

• 來源與驗證：改寫自 ExamTopics 社群回報的 Blob tier 高頻考點（本文不引用社群票數）；並經 Microsoft Learn：Blob access tiers 交叉驗證。

📝 真題 2：最低保存期與 Cold tier（ExamTopics Q465 考點改寫）

Titan 想把很少存取、但仍需快速取回的資料放在 Cold，並在 60 天後刪除。架構師應如何評估？

• A. 沒有額外影響，Cold 沒有最低保存期
• B. 60 天後刪除會觸發剩餘 30 天的按比例早期刪除費
• C. Cold 必須先 rehydrate 才能讀
• D. Cold 只能搭配 GZRS

┌──────────────────────────────────────────────┐
│ Cold tier: minimum retention = 90 days       │
│ Delete at day 60 -> charge for 30 days       │
└──────────────────────────────────────────────┘
                       |
                       v
┌──────────────────────────────────────────────┐
│ Online read: no rehydrate; fee still applies │
└──────────────────────────────────────────────┘

💡 架構師重點筆記：Cold 的「可立即讀取」與「90 天最低保存期」同時成立；線上可讀不代表提前刪除免費。

答案：B。 Cold 的最低保存期是 90 天；60 天刪除或換層可能按剩餘 30 天收費。A 忽略新 tier 的成本規則；C 把 Archive 的 offline 特性套錯；D 混淆 tier 與 redundancy。ExamTopics Q465 是 HOTSPOT；本題保留其考點並改寫為選擇題，答案以官方文件驗證。

• 來源與驗證：改寫自 ExamTopics Q465（Cold/Cool/Archive 最低保存期考點）；並經 Microsoft Learn：Early deletion charges 交叉驗證。

📝 真題 3：Archive 不是立即讀取（ExamTopics Q471 考點改寫）

Titan 將舊稽核資料放入 Archive。事故發生時，工程師直接執行下載，卻無法取得 Blob 內容。正確的下一步是什麼？

• A. 直接讀取 Archive，因為它只是容量較便宜的 Hot
• B. 用 Set Blob Tier 或 Copy Blob 取回到 Hot、Cool 或 Cold
• C. 將 Storage Account 改成 ZRS，資料就會自動可讀
• D. 只要讀取 metadata 就能取得完整內容

┌──────────────────────────────────────────────┐
│ Archive blob = offline content               │
└──────────────────────────────────────────────┘
                       |
                       v
┌──────────────────────────────────────────────┐
│ Set Blob Tier / Copy Blob -> online tier     │
└──────────────────────────────────────────────┘

💡 架構師重點筆記：Archive 的資料本體先停在離線層；rehydration 是狀態轉換，完成前不能把它當成一般線上 Blob 下載。

答案：B。 Archive 是 offline tier，資料本體不可直接讀寫；要先 rehydrate。A 把容量價格誤當存取狀態；C 是備援設定且 Archive 不支援 ZRS；D 只能讀中繼資料與標籤，不能得到物件內容。Q471 的社群討論與答案訊號仍應以指定讀取流程即時覆核，本文不引用未驗證票數。

• 來源與驗證：改寫自 ExamTopics Q471（Archive rehydration 考點）；並經 Microsoft Learn：Blob rehydration 交叉驗證。

📝 真題 4：網路磁碟與 Blob 的邊界（gratisexam Q36 歷史題庫改寫）

⚠️ 來源說明：本題改寫自 2020 年 gratisexam AZ-900 題庫 Q36，屬歷史題庫層；原題考點是 Windows 網路磁碟應使用 Azure Files，已以現行 Microsoft Learn 交叉驗證，本文只延伸辨識 Blob 與檔案共享的邊界。

Titan 要讓多台 Windows 工作站掛載共享路徑來讀取影像檔。哪一項 Azure 資源最符合需求？

• A. Azure SQL Database　B. Virtual machine data disk　C. Files service in a Storage Account　D. Blobs service in a Storage Account

┌──────────────────────────────────────────────┐
│ Many Windows clients need SMB mount          │
└──────────────────────────────────────────────┘
                       |
                       v
┌──────────────────────────────────────────────┐
│ Azure Files = file share; Blob = object API  │
└──────────────────────────────────────────────┘

💡 架構師重點筆記：題目問「掛載共享路徑」時先辨識檔案協定與共享語意；Blob 適合物件 API，不是 SMB 網路磁碟。

答案：C。 Azure Files 提供可由 Windows 掛載的雲端檔案共用；D 的 Blob 是物件儲存，不能直接當成 SMB 網路磁碟掛載。這題提醒我們不要把「檔案共享」與本日的 Blob tier 混為一談。

• 來源與驗證：改寫自 2020 年 gratisexam Q36；並經 Microsoft Learn：Azure Files planning 交叉驗證。

📝 真題 5：Availability Zone 的故障邊界（gratisexam Q27 歷史題庫改寫）

⚠️ 來源說明：本題改寫自 2020 年 gratisexam AZ-900 題庫 Q27，屬歷史題庫層；原題考察 Availability Zone 的故障邊界，本文依現行 Microsoft Learn 用語改寫，並不把舊題當成 Cold tier 題。

CTO 啟用跨 Availability Zone 的資料複本，想知道它主要防禦哪一種故障？哪一項最符合？

• A. 單一實體伺服器故障　*B. 整個 Azure Region 故障　*C. 儲存體服務故障　*D. 單一資料中心故障

┌──────────────────────────────────────────────┐
│ Region: Zone A | Zone B | Zone C             │
└──────────────────────────────────────────────┘
                       |
                       v
┌──────────────────────────────────────────────┐
│ One zone/DC fails -> others stay online      │
└──────────────────────────────────────────────┘

💡 架構師重點筆記：Availability Zone 把複本分散到同一 Region 的獨立故障邊界；它縮小單一 Zone／資料中心故障的 Blast Radius，但不等於跨 Region 災備。

答案：D。 Availability Zone 是 Region 內彼此隔離的資料中心群，具備獨立電力、冷卻與網路；跨 Zone 複寫主要降低單一資料中心失效的影響，並不等於跨 Region 災備。

• 來源與驗證：改寫自 2020 年 gratisexam Q27；並經 Microsoft Learn：Azure Availability Zones 交叉驗證。

💡 AWS SAA-C03 / CLF-C02 概念補充與雙雲考點連動演練

NotebookLM 取用狀態：本次嘗試開啟 Notebook 1 與 Notebook 2，兩者都導向 Google 登入頁，無法驗證筆記內容。因此本節不捏造或宣稱引用其中的未公開內容；「NotebookLM 雙雲筆記」僅作補充來源，技術事實以 AWS 與 Microsoft 官方文件為準。本次改採本地 cxcxc-io AWS 架構筆記 與官方文件整理。

具備 AWS 背景的架構師，最容易把「S3 Storage Class」和「Azure Blob Access Tier」當成同一個維度，再把「冗餘」也塞進同一張服務對照表。正確的抽象方式是：tier 回答資料多久被讀、要付多少儲存與取回成本；redundancy 回答複本跨越哪個故障邊界；versioning 回答能否追回誤刪或覆寫；replication 回答是否要把資料複製到另一個儲存位置。

🧭 多維度決策矩陣：不要做錯一對一映射

AWS 官方的 S3 storage classes、S3 Lifecycle、S3 Versioning 與 S3 replication，以及 Azure 的 Blob access tiers、lifecycle management、Blob versioning 與 data redundancy 都支持這個拆分。cxcxc-io 的圖 7 也把 CloudFront／S3 與應用、快取、資料庫層分開；遷移到 Azure 時，應保留「內容儲存、邊緣快取、應用入口、資料保護」的分層思考，而不是硬找一個完全相同的服務名稱。

🎲 連動演練一：生命週期、版本與成本一起設計

Titan 情境：CTO 要求產品圖片上線後先維持低延遲讀取；30 天後大多數圖片只偶爾被查詢，但不能因一次誤覆寫就失去舊版本。對 AWS 圖片 bucket，希望降低長期儲存成本；對 Azure Blob，要求同樣能以規則管理目前版本與舊版本。

題目： 哪個方案最完整？

• A. AWS 直接把新物件放 Glacier Deep Archive；Azure 直接放 Archive，兩邊都不開 Versioning。
• B. AWS 開啟 S3 Versioning，使用 Lifecycle 將目前物件在 30 天後轉到較冷的 class，另為非目前版本設定保留／清理規則；Azure 開啟 Blob versioning，再以 lifecycle 規則分別管理 current 與 previous versions 的 tier 或到期。
• C. AWS 只設定 CRR 到另一個 Region；Azure 只設定 GZRS，因為跨位置複寫就能追回誤覆寫。
• D. AWS 使用 One Zone-IA；Azure 使用 LRS，兩者都不設 lifecycle，避免轉換請求費。

ASCII 解題圖：

┌──────────────────────────────────────────────┐
│ Current data -> colder tier (30d)            │
│ lower cost; keep old version                 │
└──────────────────────────────────────────────┘
                       | overwrite
                       ▼
┌──────────────────────────────────────────────┐
│ Old version -> lifecycle -> retain or expire │
└──────────────────────────────────────────────┘

💡 架構師重點筆記：上方兩條路徑要同時存在：Lifecycle 管理成本，Versioning 保留歷史。只設定其中一條，另一個需求就會留下風險。

答案：B。

推理與雙雲對照： 題幹同時出現「30 天後低頻」與「誤覆寫可復原」兩個需求，前者需要 lifecycle／tier，後者需要 versioning。AWS 的 Lifecycle 必須另外處理 noncurrent versions，否則只刪 current object 的規則可能讓舊版本無限累積；Azure lifecycle 也能針對目前版本、舊版本或 snapshot 設定動作。這是兩組互補的控制，不是用其中一組取代另一組。

陷阱拆解：

• A 錯在把封存當成低頻線上層：Glacier Deep Archive 與 Azure Archive 都不適合需要立即取回的圖片，還可能產生取回延遲與最低保存期成本。
• C 錯在混淆複寫與版本保護：CRR／GZRS 是讓另一個位置有副本，誤刪或誤覆寫若被同步到副本，仍可能一起消失；versioning 才提供回到舊版本的路徑。
• D 錯在只看單價：One Zone-IA 與 LRS 的故障邊界較小，且完全沒有自動分層與版本清理，長期成本與復原風險都未被管理。

🎲 連動演練二：區域內冗餘不等於跨區災備

Titan 情境：稽核原檔平常很少讀取，但主要 Region 發生災難時，CTO 要能在另一個 Region 啟動讀取流程；同時，單一 Zone 故障不能讓主要寫入路徑立刻中斷。架構師要向 AWS 與 Azure 團隊各提出一個可行方案。

題目： 下列哪個跨雲設計最符合需求？

• A. AWS 只用 S3 Standard；Azure 只用 ZRS。兩者都已經有區域內複本，因此自然具備跨 Region 災備。
• B. AWS 以具版本控制的來源 bucket 設定 CRR 到另一 Region 的目的 bucket，明確設計權限與切換；Azure 以 GZRS 保護主要 Region 的 Zone 與異地副本，若災備期間需要讀次要端，再評估 RA-GZRS。
• C. AWS 把所有物件直接放 Deep Archive；Azure 把所有 Blob 放 Archive，封存層會自動提供可讀的熱備援端點。
• D. AWS 用 S3 Versioning 取代 CRR；Azure 用 Blob versioning 取代 GRS，因為舊版本就是另一個 Region 的副本。

ASCII 解題圖：

┌──────────────────────────────────────────────┐
│ Primary Region: write and read path          │
└──────────────────────┬───────────────────────┘
                       |
┌──────────────────────────────────────────────┐
│ AWS CRR -> secondary bucket                  │
│ Azure GZRS -> asynchronous geo copy          │
└──────────────────────────────────────────────┘
                       |
                       ▼
┌──────────────────────────────────────────────┐
│ Failover needs permissions and health checks |
└──────────────────────────────────────────────┘

💡 架構師重點筆記：區域內 redundancy 先縮小 Zone 故障的爆炸半徑；跨 Region replication 才提供災備副本。兩者都還需要權限、健康檢查與切換流程。

答案：B。

推理與雙雲對照： S3 Standard 的區域內設計不能代替跨 Region 的 CRR；S3 Versioning 也不會自行複製到別的 bucket。Azure ZRS 只處理主要 Region 內的 Zone 故障，GZRS 才把主要 Region 的 ZRS 與次要 Region 的 geo-replication 結合；若要求直接讀次要端，才選擇 RA-GZRS 類型並接受非同步複寫延遲。這裡的「版本」「主要位置複本」「異地複本」是三個不同控制面。

陷阱拆解：

• A 錯在故障邊界不足：S3 Standard 與 ZRS 都主要解決區域內可用性；Region 整體失效時仍需要跨 Region 複寫。
• C 錯在把 storage class 當成 failover endpoint：Glacier／Archive 的低儲存成本不會自動替應用程式完成 DNS、權限、讀取端點與切換。
• D 錯在把復原歷史當成地理副本：Versioning 能追回同一儲存位置中的舊版本，無法承受整個 Region 消失。

考場口訣： Tier 問「多久讀、多少錢」；Versioning 問「能否追回上一版」；Redundancy 問「同一 Region 的哪個故障邊界」；Replication 問「要不要把資料送到另一個 bucket 或 Region」。先把四個問題分開，才不會在 S3 與 Blob 之間做出錯誤的一對一映射。

📐 Part 4：以戰代訓課程對照

🚀 今日總結與明日預告

🏆 今日 3 點速記

1. 三層先分清：Storage Account 是帳戶與備援邊界，Container 是邏輯群組，Blob 才是物件本體。
2. 四層按存取選：Hot 頻繁、Cool 低頻立即取回、Cold 更低頻但仍 online、Archive 最省容量卻要 rehydrate；Cool/Cold/Archive 最低保存期分別是 30/90/180 天。
3. 備援按故障選：LRS 守單一資料中心、ZRS 守 Zone、GRS/GZRS 守 Region；RA- 前綴代表可讀次要端，但資料可能尚未同步。

🔮 明日預告：Day 16 Azure Files & Managed Disks

Blob 是物件，不是可掛載的網路磁碟。明天我們將進入 Azure Files 與 Managed Disks，對照 AWS EFS 與 EBS，拆解 SMB/NFS 檔案共享、磁碟效能層級、掛載邊界與「物件、檔案、區塊」三種儲存模型的選型陷阱。