💡 先搞懂問題
虛構的「北辰醫院」把檢查報告與影像放在 Azure 的儲存體帳戶裡。建立帳戶時，入口網站要求選「備援」，下拉選單裡有 LRS、ZRS、GRS、GZRS，旁邊還有一個「讀取存取」的勾選框。很多人直接接受預設值，直到某天一個資料中心停電、或整個區域出了大事，才發現資料讀得到卻寫不進去、要先做一個叫「容錯移轉」的動作，而且最後幾分鐘寫入的資料可能不見了。另一個困擾在帳單：五年前的影像幾乎沒人調閱，卻和每天要看的資料放在同一個存取層，每個月付一樣的儲存費。
這兩件事分別由兩個設定決定。備援（redundancy）決定資料複製幾份、放在哪裡：同一個資料中心、同一個區域的不同可用性區域（availability zone），或另外再複製一份到遠方的次要區域（secondary region）。存取層（access tier）則決定 Blob 資料放得多「冷」：越冷的層儲存費越便宜，但讀取費越貴，有最短保存天數，最冷的 Archive 甚至要先花數小時解除凍結（rehydrate，也常稱為解除封存）才讀得到。
生活比喻：重要文件要怎麼備份
想像你要保管一份很重要的合約。最簡單的做法，是印三份影本鎖在家裡的保險箱：其中一份被咖啡潑到沒關係，還有另外兩份；可是房子一旦失火，三份一起燒掉。謹慎一點的人，會在同一個城市的三間銀行分行各放一份，而且每次修改都三間同時更新：一家分行淹水，另外兩家照常營業，你走到隔壁那家就能繼續辦事。
再更謹慎，就會另外把文件寄一套到外縣市的分行。郵寄需要時間，所以你剛改完的那一版可能還在路上；而且外縣市分行平常只負責保管，你要正式宣告「本地分行都不能用了」、把外縣市改成主要往來的分行，才能在那裡繼續修改文件。如果你和外縣市分行另外約定「平常就讓我調閱」，那麼本地出事時至少馬上看得到內容，只是不能改，而且看到的可能是幾分鐘前的版本。
這個比喻有幾個地方和實際不同。第一，外縣市要寄去哪裡不是你選的：次要區域由 Microsoft 的區域配對（region pair）決定，你不能自己指定；官方也說明很多較新的區域沒有配對、改以可用性區域為主要備援，在這類區域規劃異地備援前，要先查該區域支援哪些選項。第二，影本是「同一份文件的複製品」，你把文件撕掉，所有影本也會跟著被撕掉：刪除與覆寫會同步到每一份副本，所以備援防的是硬體與機房故障，不是誤刪或勒索軟體，那要靠虛刪除、版本設定或備份。第三，容錯移轉不是按下去就完事：未同步的寫入會遺失，而且官方文件說明，非計畫的容錯移轉之後，帳戶會在新的主要區域變成 LRS，要自己再把異地備援設回來。
再看存取層：同一個帳戶裡，資料的「溫度」不一樣
北辰醫院的資料大致分成三種：當天門診要看的影像，幾乎每分鐘都有人讀；半年前的影像偶爾回診時調閱；七年前、依法規要保存的舊病歷影像，一年可能不到一次。如果全部放在 Hot 層，最冷的那一批每個月照樣付最高的儲存費；如果全部丟進 Archive，門診醫師點開影像要等好幾個小時。存取層讓你依讀取頻率替每個 blob 選擇擺放方式，再用生命週期管理（lifecycle management）規則，讓資料隨著時間自動往冷的層移動。實驗室二就是用這個情境，算給你看每一層在不同讀取次數與保存天數下的總成本。
🎮 互動實驗室一：備援故障模擬器
先選一種備援，下方的地圖會畫出副本放在哪裡（深青色是主要區域的副本，深藍綠色是次要區域的副本）。接著按一種故障：磁碟或節點、整個資料中心（可用性區域）、整個主要區域。預設會先請你猜「還能讀嗎」「還能寫嗎」，兩題都選完才公布答案與原因；需要容錯移轉的情況，可以再按「執行容錯移轉」看看之後變成什麼樣子。
主要區域 East Asia（示意）
次要區域 配對區域（示意）
行為依 Microsoft Learn「Azure Storage 備援」與「災害復原與儲存體帳戶容錯移轉」文件（查證時間 2026 年 10 月）。耐久性為官方「每年至少」的數字；副本數依 AZ-900 學習模組；區域名稱為示意。
🎮 互動實驗室二：存取層成本試算
選一個情境或自己拉滑桿：資料量、每月讀取次數、平均每次讀多大、資料保存幾天後刪除。右邊會用示意單價算出 Hot、Cool、Cold、Archive 四層在整段保存期間的儲存費、提前刪除費與存取費。示意單價的單位是「點」，只保留各層之間大致的高低關係，不是實際價格；真正的價格依區域、備援與時間而不同，請以 Azure 定價頁與定價計算機為準。每個情境下方有小挑戰：先猜哪一層總成本最低。
一、輸入
| 示意單價（點） | Hot | Cool | Cold | Archive |
|---|
二、整段保存期間的總成本（示意）
提前刪除費 ＝ 資料量 × 每 GB 每月單價 × max(0, 最短天數 − 保存天數) ÷ 30
存取費 ＝ 保存月數 × ［每月讀取次數 ÷ 1 萬 × 讀取單價 ＋ 每月讀取 GB × 擷取單價］
最短保存天數（Cool 30 天、Cold 90 天、Archive 180 天）與提前刪除的計算方式，依 Microsoft Learn「Blob 資料的存取層」文件，查證時間 2026 年 10 月。示意單價為本頁自訂的比例，不代表任何區域的實際價格。
🛠️ 操作教學：建立儲存體帳戶並設定生命週期規則
不用登入 Azure，也能先把流程走一遍。左邊是簡化的入口網站，照步驟填表、按按鈕；右邊同步顯示等效的 Azure CLI 與 Bicep，黃色底的那幾行就是目前這一步對應的指令。你可以故意填錯看看驗證訊息，也可以改帳戶名稱、區域或備援，看指令怎麼跟著變；生命週期規則的 JSON 在「policy.json」分頁。
managementPolicies 資源的屬性，內容結構相同。
自己動手時要注意
權限方面，建立帳戶與設定生命週期原則屬於管理平面的操作，在資源群組上需要「參與者」（Contributor）或「儲存體帳戶參與者」（Storage Account Contributor）這類角色；要讀寫 blob 資料本身，則另外需要「儲存體 Blob 資料參與者」這類資料平面角色。費用方面，儲存體依資料量、交易次數與備援方式計費，異地備援還有複寫流量；生命週期規則變更層級會產生交易費，搬到 Cool、Cold、Archive 的資料若在最短天數內被刪除或移走，會收提前刪除費。另外，CLI 沒有指定 --sku 時預設是 Standard_RAGRS，練習時記得明確指定。練習完把整個資源群組刪掉：
# 練習完刪除整個資源群組，帳戶與裡面的資料會一起刪除
az group delete --name rg-storage-lab --yes --no-wait範例裡的名稱都是示意。不要把儲存體帳戶金鑰、SAS 權杖、連接字串或訂用帳戶 ID 寫進腳本或截圖；需要時用 <your-subscription-id> 這類佔位字。應用程式存取 blob 時，優先用 Microsoft Entra ID 搭配受控識別，並考慮關閉帳戶金鑰存取。
📘 原理補完
六種備援的正式定義
備援設定在儲存體帳戶（storage account）層級，帳戶裡的 Blob、Azure Files、Queue、Table 都套用同一種。判斷時問兩個問題：主要區域內怎麼複製？要不要再複製到次要區域？主要區域內的複寫一律是同步的，寫入要在副本都完成才回報成功；複製到次要區域則是非同步的，所以會有一段延遲。下表依 Microsoft Learn 整理（查證時間 2026 年 10 月）：
| 選項 | 主要區域 | 次要區域 | 次要區域平常可讀 | 耐久性（每年至少） | 適合 |
|---|---|---|---|---|---|
| LRS 本地備援 | 單一資料中心內 3 份 | 無 | — | 11 個 9 | 成本優先、資料可重建，或法規要求資料不得離開單一區域 |
| ZRS 區域備援 | 3 個以上可用性區域同步複寫 | 無 | — | 12 個 9 | 要扛資料中心故障、又要資料留在同一區域 |
| GRS 異地備援 | LRS | 非同步複寫，次要區域內 LRS | 否，要容錯移轉 | 16 個 9 | 要防整個區域災難，平常不需要讀次要區域 |
| RA-GRS | LRS | 同 GRS | 是（-secondary 端點） | 16 個 9 | 主要區域出事時，應用程式要能先改讀次要區域 |
| GZRS 異地區域備援 | ZRS | 非同步複寫，次要區域內 LRS | 否，要容錯移轉 | 16 個 9 | 同時要扛資料中心故障與區域災難 |
| RA-GZRS | ZRS | 同 GZRS | 是 | 16 個 9 | 可用性需求最高、要在區域故障時仍可讀 |
限制：Premium 帳戶類型（Premium 區塊 Blob、Premium 檔案共用、Premium 分頁 Blob）只支援 LRS 與 ZRS；Archive 存取層只支援 LRS、GRS、RA-GRS；Azure Files 不支援 RA-GRS 與 RA-GZRS。
非同步複寫、上次同步時間與容錯移轉
因為主要區域到次要區域是非同步複寫，兩邊之間永遠有一段延遲。儲存體帳戶有一個上次同步時間（Last Sync Time）屬性：在這個時間點之前寫入的資料，保證已經到了次要區域；之後寫入的，可能還沒到。官方文件明確寫出，容錯移轉時已經複製到次要區域的資料會保留，還沒複製過去的寫入會永久遺失，而且一般的異地複寫沒有針對 RPO（復原點目標）提供 SLA。
容錯移轉（failover）是把次要區域升格為新的主要區域，讓帳戶重新可以寫入。官方文件把它分成三種：客戶管理的計畫性容錯移轉（用來演練災難復原）、客戶管理的非計畫性容錯移轉（主要區域真的出事時由你發動），以及 Microsoft 管理的容錯移轉（嚴重災難時由 Microsoft 發動）。非計畫性容錯移轉之後，帳戶在新的主要區域會變成 LRS，原本主要區域的資料會被刪除，要恢復異地備援得自己重新設定 GRS 或 RA-GRS，重新複寫也會產生費用。
存取層：儲存費與存取費的翹翹板
存取層主要用在標準一般用途 v2 帳戶裡的區塊 blob（Premium 帳戶沒有存取層）。Hot、Cool、Cold 是線上層，讀取延遲都是毫秒等級，差在費用結構；Archive 是離線層，資料在裡面不能直接讀取或修改，要先解除凍結（rehydrate）到線上層。帳戶的預設存取層只能設 Hot、Cool 或 Cold（新的一般用途 v2 帳戶預設是 Hot），Archive 只能設在個別 blob 上，或由生命週期規則搬過去。另外還有 smart 層，由平台依存取情況在 Hot、Cool、Cold 之間自動移動，不含 Archive。
| 存取層 | Learn 繁中名稱 | 線上／離線 | 最短保存天數 | 第一個位元組延遲 | 儲存費 | 存取費 | 典型資料 |
|---|---|---|---|---|---|---|---|
| Hot | 經常性存取層 | 線上 | 無 | 毫秒 | 最高 | 最低 | 網站圖片、正在使用的檔案 |
| Cool | 非經常性存取層 | 線上 | 30 天 | 毫秒 | 較低 | 較高 | 不常讀的報表、短期備份 |
| Cold | 極非經常性存取層 | 線上 | 90 天 | 毫秒 | 更低 | 更高 | 很少讀但要能立即取用的舊資料 |
| Archive | 封存層 | 離線 | 180 天 | 小時（要先解除凍結） | 最低 | 最高 | 法規保存、長期封存 |
最短保存天數不是「放進去之後不能動」，而是提早刪除、移到別的層或覆寫時，要補收剩餘天數的費用。官方範例：放在 Cool 第 21 天就刪除，要補收 9 天（30 − 21）的 Cool 儲存費；放進 Archive 後第 120 天刪除，要補收 60 天的 Archive 儲存費。
Archive 的解除凍結
Archive 的 blob 要讀，先得解除凍結到 Hot、Cool 或 Cold。方法有兩種：用複製 Blob 把它複製成一個新的線上層 blob，原本的 Archive blob 不動，因此不會觸發提前刪除費；或用設定 Blob 層直接改原 blob 的層級，開始後不能取消，若還沒在 Archive 放滿 180 天，會收提前刪除費。優先順序也有兩種：標準依收到的順序處理，10 GB 以下的物件最長可能要 15 小時；高優先順序費用較高，10 GB 以下的物件可能在 1 小時內完成，適合緊急復原。生命週期管理不能用來把 Archive 解除凍結回線上層。
生命週期管理：讓資料自己變冷
手動替每個 blob 改層級不切實際。生命週期管理原則設在儲存體帳戶上，由一條或多條規則組成；每條規則用篩選條件（前置詞要從容器名稱開始，例如 applogs/，以及 blob 類型）挑出 blob，再依「上次修改後幾天」「建立後幾天」「上次存取後幾天」等條件執行移到 Cool、Cold、Archive 或刪除。原則每天執行，變更後最多可能要 24 小時才生效；規則名稱最多 256 個英數字、區分大小寫。Archive 動作不支援設定為 ZRS、GZRS、RA-GZRS 的帳戶，這一點在操作教學第 8 步會碰到。下面是操作教學預設的原則，也就是 CLI 用 --policy @policy.json 讀取的檔案內容：
{
"rules": [
{
"enabled": true,
"name": "moveOldLogs",
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": [ "blockBlob" ],
"prefixMatch": [ "applogs/" ]
},
"actions": {
"baseBlob": {
"tierToCool": { "daysAfterModificationGreaterThan": 30 },
"tierToArchive": { "daysAfterModificationGreaterThan": 180 }
}
}
}
}
]
}判斷步驟
- 先確認帳戶類型：多數情境用標準一般用途 v2；需要低延遲的 Premium 帳戶只能選 LRS 或 ZRS，也沒有存取層。
- 資料能重建、或法規要求資料不得離開單一區域，LRS 或 ZRS；要扛資料中心故障，至少 ZRS。
- 要防整個區域災難，選 GRS 或 GZRS；兩種故障都要扛，選 GZRS。
- 主要區域出事時應用程式要能先讀，加上 RA-（RA-GRS、RA-GZRS），並讓程式知道怎麼改讀
-secondary端點。 - 存取層依讀取頻率與保存天數選：常讀選 Hot；少讀但保存超過 30 天選 Cool；很少讀、保存超過 90 天、需要時要立即讀選 Cold；幾乎不讀、保存超過 180 天、可以等數小時選 Archive。
- 用生命週期管理自動降層；如果要用 Archive，帳戶備援不能是 ZRS、GZRS、RA-GZRS。
- 備援不是備份：另外開啟虛刪除、版本設定，或用 Azure Backup 防誤刪與勒索軟體。
容易考錯的地方
GRS 平常就能讀次要區域：不能。GRS 與 GZRS 的次要區域資料平常不開放讀取，要容錯移轉後才能用；題目寫「主要區域故障時仍需讀取」就要選 RA-GRS 或 RA-GZRS。
ZRS 能防區域災難：ZRS 的三份都在同一個區域裡，扛得住單一資料中心或可用性區域故障，扛不住整個區域的災難。反過來，GRS 能防區域災難，但它在主要區域內只是 LRS，單一資料中心故障就要靠容錯移轉才能寫入。
次要區域可以自己選：不行，次要區域由區域配對決定。需要自己選兩個區域的跨區域架構，要在應用程式層自己設計，例如物件複寫或在兩個區域各建帳戶。
備援等於備份：刪除與覆寫會同步到所有副本。防誤刪看虛刪除、版本設定、時間點還原；防竄改看不可變儲存；跨帳戶的備份看 Azure Backup。
Archive 可以當預設存取層、可以立即讀：都不行。帳戶預設層只能是 Hot、Cool、Cold；Archive 是離線層，要先解除凍結，標準優先順序最長可能 15 小時。
最短保存天數的意思：不是「鎖住不能刪」，而是提早刪除或移走要補收剩餘天數的費用。題目若是「資料只保存 7 天」，放 Cool 反而不划算。
生命週期管理會自動把資料拉回來：它只能往冷的層移動或刪除（Cool 層另有被存取時自動移回 Hot 的選項），不能把 Archive 解除凍結。
相關考試：AZ-900 大綱點名 Azure Storage 的層級、備援與帳戶類型；AZ-104 大綱點名備援、存取層、虛刪除、生命週期管理與版本控制。
✅ 自我檢測
6 題原創題，選完立即顯示對錯與解析，全部作答後會出現總分。目前得分：0 / 6