備份、還原與災難復原程序

備份與災難復原是每位 SysOps 工程師神經最緊繃的實戰測試：這個主題的核心問題不是「備份有在跑嗎？」，而是「三十秒前，有人不小心在生產資料庫執行了 DROP TABLE，資料已毀損——你接下來要輸入什麼指令？」SOA-C02 考試指南 v2.3 在 Domain 2（Reliability and Business Continuity，佔 16%）下的 Task Statement 2.3 明確劃出「實作備份與還原策略」——不同於 SAA-C03 要求你從 RTO 和 RPO 目標設計 DR 架構，SOA-C02 要求你執行還原。你要選哪個 AWS Backup recovery point？要設定哪些還原參數？RDS point-in-time restore 後的新端點是什麼？哪條 S3 lifecycle transition 是合法的、哪條會拋出 InvalidRequest？你剛複製到目的地 Region 的 cross-region snapshot copy，為什麼在那邊讀不到？

本指南專為 AWS 上備份與災難復原的操作流程所打造。我們會走過 AWS Backup plans、vaults、Vault Lock（governance 對比 compliance 模式，包含不可逆的 72 小時寬限期）、RDS 自動備份與 point-in-time restore、在 Region 故障時提升 read replica、S3 versioning 搭配 MFA Delete、S3 lifecycle rules 與 30 天 transition 最短限制、S3 Cross-Region Replication（CRR）含 Replication Time Control（RTC）、Data Lifecycle Manager（DLM）管理 EBS 與 AMI snapshots、cross-region snapshot copy 及那個讓每位考生掉分的加密陷阱、S3 Glacier 各取回層級的實際時間，以及四種標準 DR 策略（backup/restore、pilot light、warm standby、multi-site active/active）搭配其操作 RTO 和 RPO。因此，備份與災難復原是個讀懂 SysOps 操作手冊遠比死背架構圖更有用的主題。

為什麼備份與災難復原是 SOA-C02 Domain 2 的核心

SOA-C02 考試指南在 TS 2.3 下列出五項技能：自動化 snapshots 與備份（RDS snapshots、AWS Backup、RTO/RPO、Data Lifecycle Manager、保留策略）、還原資料庫（point-in-time restore、提升 read replica）、實作 versioning 與 lifecycle rules、設定 S3 Cross-Region Replication，以及執行災難復原程序。每一項技能都是操作性的——不是「決定哪種備份策略合適」，而是「設定 backup plan、執行還原、驗證復原後的資源」。因此，備份與災難復原是 SOA-C02 視角相對於 SAA-C03 視角最純粹的體現。

在 SysOps 的層級，問題框架是程序性而非架構性的。SAA-C03 問「工作負載的 RPO 是 5 分鐘、RTO 是 1 小時——選哪種 DR 模式？」SOA-C02 問「團隊選了 pilot light——主要 Region 剛剛失效——列出你要在次要 Region 依序執行的步驟」。備份與災難復原也是所有其他 SOA-C02 主題的匯聚點：CloudWatch alarms（Domain 1）監控備份任務成功率和 CRR 複寫延遲、EventBridge rules（Domain 1.2）將 Backup job 失敗事件路由至補救動作、Auto Scaling（Domain 2.1/2.2）啟動 warm standby 機群、CloudFormation（Domain 3）在次要 Region 部署 stack、KMS keys（Domain 4）對跨 Region snapshot copy 重新加密、VPC（Domain 5）提供備援 Region 的網路，以及 EBS 效能（Domain 6）決定還原後的 volume 在第一次 I/O 時是否符合 SLA。因此，備份與災難復原是所有後續 SOA-C02 技能都必須組合成「真正讓生產環境恢復上線的單一程序」的主題。

白話文解釋 Backup and Disaster Recovery on AWS

備份的術語很容易混亂。三個類比能讓這些概念更好記。

類比一：銀行保險庫與保管箱

AWS Backup 是一座銀行保險庫。Backup vault 是那個加了螺栓、裝了警報器、以 KMS 加密的實體保險庫間。Recovery points 是裡面一格一格的保管箱，每格存放某位客戶的資產在某個時間點的快照。Backup plan 是在服務台留的常設指示：「每個工作日晚上 23:00，對所有標記 tier=prod 的帳戶取一份新快照，把上個月的保管箱移到地下三層的冷儲存庫，超過七年的保管箱予以銷毀」。Vault Lock 是監管機關在一次詐欺稽核後要求安裝的時間鎖保險門——一旦以 compliance mode 上鎖，72 小時寬限期到期後，就連銀行總裁都無法縮短保留期或取出任何保管箱，因為法規要求監管機關必須能夠查閱七年內的每一筆交易。Vault Lock governance mode 是比較溫和的表親：保險門是鎖上的，但擁有特殊鑰匙（backup:DeleteRecoveryPoint 加上 backup:DisassociateRecoveryPoint）的資安長在有正當理由時仍可開啟。Cross-region copy 是設在另一座城市的異地備份庫——必須這樣做，因為總部大樓如果失火，裡面的保險庫也會付之一炬。

類比二：圖書館預約服務台

S3 versioning 是圖書館預約服務台。每次借閱者歸還一本寫滿眉批的書，館員不會覆蓋原本的版本——她把兩個版本都放上書架，各附一個版本 ID（v1: 原版、v2: 附 2024 年讀者眉批、v3: 附 2025 年讀者修正）。當有人「刪除」一本書，她不會把它丟掉；她只在書堆前放一個刪除標記書籤，讓一般搜尋顯示「找不到」，但館員可以移除書籤並取回任何舊版本。MFA Delete 是館長——僅限館長、且必須攜帶實體令牌——才能打開的珍本書鐵籠鑰匙，只有這樣才能永久銷毀任何版本。S3 lifecycle rules 是館員的常設輪換政策：「30 天後移至異地倉庫（Glacier Instant Retrieval）、90 天後移至深層典藏（Glacier Deep Archive）、七年後銷毀——在啟用 versioning 的書架上，非最新版本在 90 天後到期，避免眉批副本無限累積」。Object Lock compliance mode 是地下室任何館員——包括館長——都無法開鎖的政府文件保管庫，必須等到法定保留期到期才能觸碰。

類比三：保險產品等級（DR 策略）

四種 AWS DR 策略完美對應保險產品的等級。Backup/restore 是基本住宅火險——每月保費便宜，但房子燒掉後要在旅館住好幾週等待重建（高 RTO、高 RPO）。Pilot light 是有緊急備用公寓待命的責任險——那間公寓空著，但已接水接電、油漆也粉刷好了；房子失火後當晚就能入住，只需要帶換洗衣物（中等 RTO、低 RPO，因為資料庫一直在持續複寫）。Warm standby 是有最低限度員工、隨時待命的全套布置備用宅——小廚房維持運作，燈火通明，能在一小時內以完整容量迎接全家入住（低 RTO、低 RPO）。Multi-site active/active 是兩棟完全相同、同時都有人居住的房子——每頓飯煮兩份、每張床都整理好；成本高昂，但其中一棟失火也不影響晚餐（近乎零 RTO、近乎零 RPO）。在 SOA-C02 上，考題很少問你選哪種（那是 SAA 的工作）；考題問的是你在切換故障時要執行哪些程序，前提是你的團隊已選好了那個等級。

TS 2.3 閱讀重點：SOA 考的是執行備份，而非設計 DR

SOA-C02 考試指南將 TS 2.3 定義為**「實作備份與還原策略」**——注意動詞是實作，而非設計。這個措辭是預測題型最準的單一指標。SOA 不考「給定 5 分鐘 RPO，選哪個 AWS 服務？」——那是 SAA-C03 的領域。SOA 考「backup plan 已設定好，recovery point 存在，生產資源已損毀——你要依序做什麼才能還原？」考試指南明確列出的五項技能，直接對應到 SysOps 工程師必須在鍵盤前展示的五項操作能力。

這些措辭——實作、還原、設定、執行——在 TS 2.3 中無處不在。把它們記成 SOA 的語氣。

AWS Backup：Plans、Vaults 與 Recovery Points

AWS Backup 是集中式、以策略驅動的備份服務，SOA-C02 考試將它視為任何「跨多個資源類型自動化備份」情境的標準答案。它透過統一的策略集與稽核介面，取代了各服務各自為政的備份設定（RDS 自動備份、EBS snapshot lifecycle、DynamoDB on-demand backup、EFS backups）。

Backup plan 結構

一個 backup plan 有三個組成部分：

1. Rules——一條或多條規則，每條規則指定：
   • Schedule（cron 運算式或速率，例如每天 UTC 05:00）。
   • Backup window——AWS Backup 可執行該任務的起始窗口與完成窗口。
   • Lifecycle——何時轉移至冷儲存（建立後最少 90 天）以及何時刪除（冷儲存最少停留 90 天，因此任何冷層 recovery point 的最短冷儲存保留期合計為 90 + 90 = 180 天）。
   • Destination vault——recovery points 存放的目標。
   • Copy actions——可選的跨 Region 或跨帳號複製，含各自的 lifecycle 設定。
2. Resource assignments——plan 涵蓋哪些資源，可透過 tag（Backup=daily、Environment=prod）或 ARN 清單選取。SOA 偏好以 tag 為基礎的選取方式，因為新增的已標記資源會自動納入。
3. IAM service role——AWS Backup 用來讀取來源資源並寫入 recovery points 的角色（AWSBackupServiceRolePolicyForBackup 與 ...ForRestores）。

Backup vault 結構

Backup vault 是存放 recovery points 的儲存容器。每個 vault 包含：

• KMS 加密金鑰——AWS 管理的 aws/backup，或客戶自管的 CMK（CMK 讓你擁有金鑰策略層級的控制權，包含跨帳號存取）。
• Vault access policy——控制哪些主體可執行 vault 層級操作的資源策略。
• 可選的 Vault Lock 策略（下一節說明）。
• 可選的 vault 通知 SNS topic，用於備份/還原任務狀態異動通知。

Vault 是 Regional 的。若要防範 Regional 停機，需在 backup plan 中設定 copy action，將 recovery point 複製到第二個 Region 的 vault。

從 recovery point 還原

首要原則：AWS Backup 還原會建立新的資源。它不會覆蓋原始資源。還原 EBS snapshot 會建立新的 volume（你再掛載）。還原 RDS recovery point 會建立新的 DB instance（你再更新應用程式的連線字串或做 CNAME 切換）。還原 EFS recovery point 會建立新的檔案系統，或將項目還原至現有檔案系統的新路徑。執行還原的 SysOps 工程師必須在還原之後規劃切換步驟——單純執行還原並不會讓工作負載恢復上線。

AWS Backup Vault Lock：Governance 對比 Compliance Mode

Vault Lock 是 WORM（一次寫入多次讀取）功能，能將 backup vault 變成可供監管機關稽核的防竄改備份儲存。對於「監管機關要求 7 年防竄改保留」或「勒索軟體加密了我們的生產環境和備份——讓備份無法被碰觸」這類情境，Vault Lock 是 SOA 正確答案。

兩種模式

• Governance mode——Vault Lock 生效，但擁有 backup:DeleteRecoveryPoint 和對應 vault access policy 權限的主體仍可在排程到期前刪除 recovery points，而 backup:PutBackupVaultAccessPolicy 仍可放寬存取權限。Governance mode 防範的是意外操作和無特權使用者；它無法防範擁有正確 IAM 權限的惡意特權內部人士。
• Compliance mode——Vault Lock 生效，且在 72 小時寬限期到期後，任何人都無法移除或弱化鎖定，包含 AWS 帳號 root user、AWS Support，甚至明確的重新鎖定操作。Recovery points 無法在排程保留期到期前刪除；鎖定時設定的最短保留期無法縮短；最長保留期也無法降低。

72 小時寬限期

當你以 compliance mode 執行 put-backup-vault-lock-configuration 時，AWS 會開啟一個 72 小時寬限期，在此期間你可以呼叫 delete-backup-vault-lock-configuration 反悔——例如你設錯了保留值。超過 72 小時的實際時鐘時間後，鎖定就變得不可更動。72 小時寬限期的存在，正是因為 compliance mode 是不可逆的：AWS 給你三天的時間在變成永久設定前測試設定是否正確。

何時選擇哪種模式

RDS 自動備份與 Point-in-Time Restore（PITR）

即使在 AWS Backup 統一管理一切之前，RDS 本身就有驅動 PITR 的自動備份機制。了解它對 SOA-C02 而言是必修。

RDS 自動備份運作方式

當你啟用自動備份（保留期 1–35 天，預設 7 天），RDS 會：

1. 在設定的備份時間窗內，每天對儲存 volume 執行一次 snapshot。
2. 每 5 分鐘擷取一次 transaction logs，並儲存在 S3 後端的內部位置。
3. 將 snapshots 加上 transaction logs 組合起來，支援在保留期內任意秒數的 PITR（最近可還原時間通常因 log 傳輸節奏而落後當前時間 5 分鐘）。

Point-in-time restore 程序

PITR 是「剛剛刪了錯誤的資料表」情境的標準還原方式。操作步驟：

1. 從 RDS 主控台（或 restore-db-instance-to-point-in-time CLI）選取來源 DB instance。
2. 選擇最近可還原時間或保留窗口內的自訂時間戳記。
3. 設定新的 DB instance——名稱、instance 等級、儲存容量、Multi-AZ、安全群組、subnet group、parameter group。還原會建立新的 instance；無法覆蓋來源。
4. RDS 配置新 instance，套用至所選時間戳記的 snapshots，精確重播 transaction logs 至指定秒數，並回報新端點。
5. 切換：更新應用程式的連線字串（或者，若你使用 Route 53 / RDS Proxy，將別名指向新端點）。
6. （選擇性）確認新 instance 運作正常後，解除損毀的來源 instance。

切換步驟是操作上最關鍵的一環。PITR 會產生新的端點 hostname（mydb-restored.cluster-xyz.us-east-1.rds.amazonaws.com）；寫死舊端點的應用程式不會自動切換。SOA-C02 經常考「PITR 後有什麼改變？」——答案永遠包含「應用程式必須重新指向新端點」。

PITR 對比 snapshot restore

• PITR：還原至保留窗口內的任意秒數——從最近一次自動 snapshot 往前推算並重播 transaction logs。
• Snapshot restore：還原至精確的 snapshot 時間點（手動 snapshots 與每日自動 snapshots 均適用）——不重播 log，還原落在 snapshot 的時間戳記。

當損毀時間已精確掌握且希望盡量少遺失資料時，優先選 PITR。當需要更早的已知良好狀態時（損毀是在 35 天前引入的，或你希望使用版本發布前手動建立的特定 snapshot），優先選 snapshot restore。

在災難期間提升 read replica

當主要的 RDS instance 所在 Region 無法使用或發生 Regional 事件時，SysOps 程序是提升另一個 Region 的 read replica：

1. 確認 read replica 健康，且 replica lag 在可接受範圍內（CloudWatch ReplicaLag 指標）。
2. 如果還能連到主要端，可選擇性暫停寫入，以縮小 RPO。
3. 從 RDS 主控台（或 promote-read-replica CLI）提升 replica。
4. 提升動作會中斷複寫，將 replica 轉換為獨立的主要 instance。原本的主要 instance 在可恢復連線後，必須重建為新主要 instance 的 replica，或予以解除。
5. 將應用程式連線字串（或 DNS 別名）更新為提升後 instance 的端點。
6. 若需要讀取擴展層，從新的主要 instance 重新建立 read replicas。

S3 Versioning 與 MFA Delete

S3 versioning 是 S3 端資料保護的基礎。一旦啟用，每次對物件執行 PUT 都會建立一個帶有唯一版本 ID 的新版本；每次執行 DELETE 都會寫入一個刪除標記（同樣是一個版本），它會讓物件在預設 GET 請求中隱藏，但保留所有先前版本供還原使用。

Versioning 狀態

一個 bucket 有三種 versioning 狀態：

• Unversioned（新 bucket 的預設值）——PUT 直接覆蓋物件；DELETE 是永久性的。
• Versioning-enabled——PUT 建立新版本；DELETE 寫入刪除標記；先前的版本可還原。
• Versioning-suspended——已有版本的物件保留其版本歷史，但新的 PUT 操作會建立版本 ID 為 null 的版本（覆蓋任何現有的 null 版本），DELETE 則在 null 版本上寫入刪除標記。Suspended 並非 Disabled——一旦啟用 versioning，就永遠無法回到原始的 Unversioned 狀態。

還原先前版本

有兩種方式可以還原被覆蓋或「刪除」的物件：

• 刪除刪除標記——如果 DELETE 寫入了刪除標記，移除該標記會讓最近的先前版本重新出現，成為當前版本。
• 將特定先前版本複製到自身——aws s3api copy-object --version-id <prior> 會將特定版本複製為新的當前版本，適用於需要還原上方還有其他版本的舊版本時。

MFA Delete

MFA Delete 是在啟用 versioning 的 bucket 上額外設定的保護。啟用後：

• 永久刪除物件版本時需要在請求中附上 MFA 驗證碼。
• 暫停或重新啟用 versioning 也需要 MFA 驗證碼。

MFA Delete 有異常嚴格的規則：

• 只有 AWS 帳號 root user 才能啟用或停用它，IAM user 無法操作——就連管理員 IAM user 也不行。
• 必須透過 AWS CLI 或 API 設定；S3 主控台不提供此切換功能。
• 需要向 root user 註冊的硬體 MFA 裝置或虛擬 MFA；裝置的序號加上當前驗證碼必須放入 API 呼叫中。

考生經常因為選擇「bucket 管理員 IAM user 透過 S3 主控台啟用 MFA Delete」這類答案而失分。這在兩點上都是錯的：只有 root user 才能啟用 MFA Delete，而且主控台不提供此選項——必須透過 CLI 或 SDK 操作。正確的考試程序是：以 root 身分（需 MFA）登入，執行 aws s3api put-bucket-versioning --bucket <name> --versioning-configuration Status=Enabled,MFADelete=Enabled --mfa "<serial> <code>"。參考：https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiFactorAuthenticationDelete.html ::

S3 Lifecycle Rules 與 30 天 Transition 最短限制

S3 lifecycle rules 會自動在儲存類型之間轉換物件，或依排程讓物件到期。Lifecycle 是讓 S3 成為耐久、按成本分層備份目標的操作槓桿。

儲存類型 transition

支援的 transition 遵循「只能往更冷更便宜走，通常不能回頭」的流向：

• S3 Standard → S3 Standard-IA、S3 Intelligent-Tiering、S3 One Zone-IA、Glacier Instant Retrieval、Glacier Flexible Retrieval、Glacier Deep Archive。
• S3 Standard-IA → S3 Intelligent-Tiering、S3 One Zone-IA、Glacier Instant Retrieval、Glacier Flexible Retrieval、Glacier Deep Archive。
• S3 Intelligent-Tiering → Glacier Instant Retrieval、Glacier Flexible Retrieval、Glacier Deep Archive（Intelligent-Tiering 本身也會自動在 Standard ↔ IA 之間調整）。
• Glacier 類型 → Glacier Deep Archive（不能透過 lifecycle 轉回較熱的類型；唯一回頭的方式是 restore，且那會產生新的副本）。

30 天最短限制

兩條獨立的 30 天規則是高頻考點：

• 從 S3 Standard 轉移至 S3 Standard-IA 或 S3 One Zone-IA 的最短年齡：30 天。在第 10 天就 transition 的 lifecycle rule 會驗證失敗。
• 在 S3 Standard-IA / S3 One Zone-IA 轉移至 Glacier 類型前的最短停留期：30 天（因此從 Standard → IA → Glacier 的鏈式最短總天數至少是 60 天）。

各儲存類型也有個別的最短停留時間：物件一旦進入 S3 Standard-IA 或 S3 One Zone-IA，必須至少停留 30 天 才能刪除或 transition，否則需支付提前刪除費用。Glacier Flexible Retrieval 的最短停留期為 90 天；Glacier Deep Archive 為 180 天。Lifecycle rules 會遵守這些限制；臨時刪除則需支付剩餘儲存成本的提前刪除費用。

Transition 的物件大小最短限制

小於 128 KB 的物件不會被 lifecycle rules 從 S3 Standard 或 Standard-IA transition 至更冷的類型——每個物件的額外開銷會超過節省的費用。這些物件會留在原位。這就是為什麼 S3 小物件工作負載更適合使用 Intelligent-Tiering（它有自己的小物件處理機制），而非明確的 lifecycle rules。

Versioning 與 lifecycle 的交互作用

對於啟用 versioning 的 bucket，lifecycle rules 可以分別針對當前版本和非當前版本：

• Transitions 和 Expiration 適用於當前版本。
• NoncurrentVersionTransitions 和 NoncurrentVersionExpiration 適用於已不再是當前版本的版本（因為有更新版本上傳）。
• 常見模式：當前版本保留在 Standard，非當前版本在 30 天後 transition 至 Glacier Flexible Retrieval，365 天後到期。這樣在版本化的同時控制成本，讓最新狀態保持在熱儲存。
• 另有 ExpiredObjectDeleteMarker: true 設定，可清除孤立的刪除標記（其所有底層版本已到期的刪除標記），避免 bucket 累積無效指標。

S3 Cross-Region Replication（CRR）

S3 Cross-Region Replication 會將來源 bucket 的物件，異步地複製到不同 AWS Region 的目標 bucket。CRR 是 SOA 對「確保 S3 資料能在 Regional 停機中存活」和「出於合規要求，將資料副本存放在不同司法管轄區」情境的標準答案。

先決條件

CRR 有四個強制先決條件——每一個都是考試測驗重點：

1. Versioning 必須在來源和目標 bucket 上都啟用。CRR 複寫的是版本；沒有 versioning，規則就無法建立。
2. 必須有一個 IAM role，並授予 S3 從來源讀取物件和寫入目標的權限（s3:GetReplicationConfiguration、s3:ListBucket、s3:GetObjectVersionForReplication、s3:GetObjectVersionAcl、s3:GetObjectVersionTagging，以及目標上的 s3:ReplicateObject、s3:ReplicateDelete、s3:ReplicateTags）。
3. 一條 replication rule 指定來源前綴/tag 篩選條件、目標 bucket、目標儲存類型（可選覆蓋），以及是否複寫刪除標記、replica 修改，以及既有物件（S3 Batch Replication 功能可補齊在規則建立之前就已存在的物件）。
4. 相容的 KMS 設定（若任一 bucket 使用 SSE-KMS）——來源 role 必須具備來源 key 的 kms:Decrypt 和目標 key 的 kms:Encrypt，且 replication rule 必須列出目標 KMS key。

什麼會被複寫，什麼不會

預設複寫：規則建立後的新物件、物件 metadata、ACLs、tags、object lock 保留設定。透過 rule 旗標可選：刪除標記（預設關閉）、既有物件（透過 Batch Replication）、replica 修改（目標物件被修改後，複寫回來源——用於雙向複寫）。

不複寫：以 SSE-C 加密的物件（S3 無法存取金鑰）、規則建立前就存在於來源 bucket 的物件（除非執行 Batch Replication）、來源物件的擁有者在目標上沒有必要 ACL 授權的物件。

Replication Time Control（RTC）

標準 CRR 是盡力而為，沒有 SLA。Replication Time Control（RTC） 是一項選擇性功能，額外提供：

• 15 分鐘 SLA：99.99% 的物件在來源 PUT 後 15 分鐘內完成複寫。
• CloudWatch 複寫指標——BytesPendingReplication、OperationsPendingReplication、ReplicationLatency（依規則）。
• EventBridge 事件，用於複寫失敗情況。

RTC 每 GB 複寫費用較高，但它是讓 S3 CRR 的 RPO 承諾可量測的唯一方式。SOA-C02 在任何「S3 資料的 RPO 為 15 分鐘」情境下，都偏好 RTC。

Same-Region Replication（SRR）

SRR 與 CRR 使用相同的機制，但兩個 bucket 都在同一個 Region。SRR 使用情境：將多個 bucket 的 log 匯集到同 Region 的一個分析 bucket、將生產資料複製到同 Region 的沙箱 bucket 供測試，以及在不同存取策略下分別存放生產和稽核副本。

CRR 不能取代備份

CRR 複寫的是變更，包含刪除標記（若已啟用）和覆寫操作。如果來源 bucket 發生惡意或意外刪除，且啟用了刪除標記複寫，目標 bucket 也會收到相同的刪除標記，資料同樣隱藏。若要在刪除與損毀情境中存活，你還需要 versioning（CRR 本來就要求）、目標上的 MFA Delete 或 Object Lock，以及最好還有獨立的 AWS Backup plan 或 AWS Backup for S3 備份來源。

Data Lifecycle Manager（DLM）管理 EBS Snapshots 與 AMIs

Amazon Data Lifecycle Manager 是 AWS 原生服務，依 tag 排程建立、保留及複製 EBS snapshots 和 AMIs。DLM 是 SOA 在「不需要自寫 Lambda 就能自動化 EBS snapshots」或「自動化 AMI 建置以輪換 golden image」情境下的首選答案。

DLM 策略類型

• EBS snapshot policy——依 tag 排程對 EBS volumes 建立 snapshots，含保留設定、cross-region copy 及跨帳號共享規則。
• EBS-backed AMI policy——依 tag 排程從 instances 建立 AMIs（可選擇性重新開機以確保應用程式一致性），含保留設定和 cross-region copy。
• Cross-account copy event policy——自動將從其他帳號收到的 snapshots 複製到你帳號的加密保存庫。

排程與保留

DLM 排程指定：

• Frequency——cron(0 5 * * ? *) 表示每天 UTC 05:00、rate(12 hours) 或以間隔為基礎的設定。
• Retention——以數量計（保留最近 7 個）或以天數計（保留 30 天）。考試偏好以數量計的 snapshot 輪換方式。
• 套用至建立的 snapshots 的 tags，讓它們本身也可被其他自動化選取。
• Cross-region copy——目標 Region、目標的加密 KMS key、複製保留設定。

DLM 對比 AWS Backup

SOA 考生何時選哪個？

• DLM 最適合範圍僅限 EBS snapshots 和/或 AMIs、團隊已採用 tag 驅動工作流程，且不需要跨資源類型集中報告的情境。DLM 是免費的（只需支付 snapshots 本身的費用）。
• AWS Backup 最適合範圍涵蓋多種資源類型（EC2 + RDS + EFS + DynamoDB）、需要集中式策略與稽核報告、需要 Vault Lock 或 compliance mode，或必須統一備份任務通知的情境。

對於純 EBS 機群且已有 golden AMI 工作流程和 tag 導向擁有權的團隊，DLM 更為精簡。對於多樣化的多服務環境，即使 AWS Backup 每個 recovery point 的費用略高，它在操作上的簡便性更佔優勢。

Cross-region snapshot copy 與加密陷阱

DLM（以及手動的 copy-snapshot API）可以將 snapshot 複製到另一個 Region。那個不直覺的操作規則是：

• 來源 snapshot 可能是用來源 Region 的客戶自管 CMK 加密的。
• 目標 Region 使用不同的 KMS key（CMK 是 Regional 的）。你必須在複製參數中指定目標 Region 的 KMS key；如果省略，AWS 會使用目標 Region 的 aws/ebs AWS 管理金鑰——這樣可以運作，但會失去客戶自管金鑰的控制權。
• Cross-Region snapshot copies 不會自動用與來源相同的 key 加密。加密金鑰一定會改變。
• 跨帳號共享加上 cross-region copy 時，目標帳號必須在目標 key 上具有 kms:DescribeKey 和 kms:CreateGrant，且來源 CMK 必須授予目標帳號 kms:CreateGrant 才能複寫。

S3 Glacier 儲存類型與取回層級

Glacier 不是單一儲存類型，而是三種，加上與 Object Lock 相容的 Standard 層，且每種都有各自的取回特性。SOA-C02 要求你熟記取回時間。

Glacier 類型

• S3 Glacier Instant Retrieval——毫秒級取回，讀取延遲與 S3 Standard 相當；適合極少存取（每季一次）但取回延遲必須保持低的資料。儲存成本低於 Standard-IA，但取回費用較高。
• S3 Glacier Flexible Retrieval（前身為「S3 Glacier」）——三個取回層級（Expedited、Standard、Bulk），最短停留 90 天；適合極少取回的備份。
• S3 Glacier Deep Archive——兩個取回層級（Standard、Bulk），最短停留 180 天；AWS 最低成本儲存；適合需保存多年的合規性典藏。

取回時間——必背數字

Restore 的運作方式

Glacier（Flexible Retrieval 或 Deep Archive）的 restore 是異步的：你呼叫 restore-object 並指定取回層級和還原副本的可用期間（1–N 天）。S3 會在 Standard/Standard-IA 中建立一個可在請求期間存取的暫時副本；底層的 Glacier 物件仍留在 Glacier。你需要支付暫時副本和取回費用。可用期間到期後，暫時副本被移除，底層 Glacier 物件依然保留。

對於 Glacier Instant Retrieval，沒有 restore 步驟——你直接 GET。該類型設計用於極少存取資料的低延遲讀取；成本模型是較便宜的儲存，但每 GB 取回費用比 Standard 貴。

災難復原策略：Backup/Restore、Pilot Light、Warm Standby、Multi-Site

AWS 災難復原白皮書定義四種策略。SOA-C02 期待你認識每種策略的操作步驟，而非從頭發明策略。

1. Backup and restore

• RTO：數小時至數天。
• RPO：數小時（取決於備份頻率）。
• DR Region 的操作規模：僅備份（S3 cross-region、AWS Backup cross-region copy）。
• 切換步驟：災難發生時，在 DR Region 配置新基礎設施（CloudFormation）、從 cross-region 備份還原資料、重新導向流量。
• 最適合：開發/測試、低優先級工作負載，可接受多小時停機的情境。

2. Pilot light

• RTO：數十分鐘至數小時。
• RPO：分鐘級（資料持續複寫中）。
• DR Region 的操作規模：運算資源最少（通常為零），但資料層是活躍的：RDS cross-region read replica 運行中、DynamoDB Global Tables 活躍、S3 CRR 複寫中、AMIs 預先建置好。
• 切換步驟：擴展休眠的運算資源（Auto Scaling group desired-capacity 從 0 增加至 N）、提升 RDS read replica 為主要、更新 Route 53 指向 DR Region。
• 最適合：RPO 要求嚴格但可容忍分鐘級 RTO 的工作負載；是常見的甜蜜點。

3. Warm standby

• RTO：分鐘級。
• RPO：秒至分鐘級。
• DR Region 的操作規模：規模縮小但持續運行的生產環境副本——小型 ASG 容量、ELB 運行中、資料庫複寫中。
• 切換步驟：將 ASG 擴展至完整生產容量、更新 Route 53（或使用會自動切換的 Route 53 failover routing policy）、提升 DB replica。
• 最適合：幾分鐘停機即代表真實金錢損失的關鍵營收工作負載。

4. Multi-site active/active

• RTO：近乎零。
• RPO：近乎零。
• DR Region 的操作規模：完整生產容量，兩個 Region 同時透過 Route 53 latency 或 weighted routing 處理流量。
• 切換步驟：沒有切換——Route 53 health checks 會自動將失效的 Region 從輪換中移除。
• 最適合：零層級關鍵任務工作負載（支付、人身安全）；成本最高。

情境模式：監管機關要求 7 年防竄改保留

SOA-C02 的典型情境。法規遵循團隊說：「我們接受 SEC 17a-4 稽核。備份必須保留 7 年並可證明防竄改——就算是我們的管理員也不能刪除。」操作手冊：

1. 在生產 Region 建立 AWS Backup vault，使用客戶自管 KMS CMK（讓金鑰存取記錄在 CloudTrail）。設定一個 backup plan，涵蓋相關資源（RDS、EBS、DynamoDB、S3），每日備份，保留 7 年（2557 天）。
2. 以 compliance mode 啟用 AWS Backup Vault Lock，最短保留期設為 7 年。等待 72 小時寬限期確認設定完全正確，然後讓鎖定變成不可逆。
3. Backup plan copy action 複製到第二個 Region 的 vault，套用相同的 Vault Lock compliance 設定——防止主要 vault 因 Regional 損失而滅失。
4. 針對 S3 資料，在來源 bucket 上啟用 Object Lock compliance mode，預設保留期設為 7 年，加上 versioning 加上關閉刪除標記複寫的 CRR，讓來源的刪除不會串聯至目標。
5. 對 vaults 的 KMS keys 和 buckets 啟用 CloudTrail data events，記錄每次存取；傳送至有獨立 Object Lock 的單獨日誌典藏帳號。

這個組合是監管機關期望的：多層 WORM、獨立的日誌證據、多 Region 耐久性。

情境模式：RDS 支援應用程式的跨 Region DR 演練

另一個典型情境。團隊為 pilot-light 架構安排了跨 Region DR 演練。應用程式在 us-east-1 使用 RDS，在 us-west-2 有 cross-region read replica，靜態資源使用 S3 CRR。演練操作手冊：

1. 驗證複寫健康狀態：read replica 的 CloudWatch ReplicaLag 低於 5 秒；S3 CRR 的 CloudWatch BytesPendingReplication 為零。
2. 驗證 Route 53 health checks 已設定 failover routing——主要記錄指向 us-east-1 ALB，次要指向 us-west-2 ALB；health check 目標為 us-east-1 的 health endpoint。
3. 觸發故障切換，模擬主要故障：停用 us-east-1 的 health check endpoint，或調整其 threshold 讓 Route 53 判定為不健康。
4. 在 us-west-2 提升 read replica 為獨立主要 instance。
5. 在 us-west-2 將休眠的 ASG 從 desired-capacity 0 擴展至生產容量。
6. 確認 Route 53 已完成切換（dig 應用程式 hostname；觀察 TTL 邊界的轉換）。
7. 對次要 Region 進行端到端應用程式功能驗證。
8. 回切：演練結束後，將原本的 us-east-1 主要重建為新 us-west-2 主要的 replica，在追上進度後反向提升——或者更簡單地，在維護時間窗內從新主要的 snapshot 還原至新的 us-east-1 instance 並回切。

這個演練會暴露每個團隊在第一次 DR 演練時都有的操作缺口：過時的 ASG launch template、次要 Region 過期的 ACM 憑證、參照主要 Region ID 的安全群組，以及從未複製過去的 KMS keys。SOA-C02 偏好能識別這些缺口的考生。

常見陷阱總覽 — 備份與災難復原

每次 SOA-C02 考試都會出現兩到三個這樣的干擾選項。

陷阱 1：AWS Backup 還原會覆蓋原始資源

它不會。還原會建立新資源。切換是獨立的步驟。

陷阱 2：Vault Lock compliance mode 之後可以移除

72 小時寬限期之後，任何 IAM 主體——包括 root——都無法移除或弱化鎖定。

陷阱 3：S3 lifecycle transition 可以在 10 天後觸發

Transition 至 Standard-IA 或 One Zone-IA 需要從建立起至少 30 天。Glacier 最短停留期為 90 天（Flexible Retrieval）和 180 天（Deep Archive）。

陷阱 4：IAM 管理員可以透過主控台啟用 MFA Delete

不行。MFA Delete 僅限 root user，且只能透過 CLI/SDK 操作。

陷阱 5：CRR 是備份

它是複寫。刪除標記複寫若啟用，刪除動作也會被傳播。Versioning + Object Lock + AWS Backup 是額外的防護層。

陷阱 6：CRR 會自動複寫既有物件

不會。只有規則建立後的新物件才會複寫。既有物件需要 S3 Batch Replication 補齊。

陷阱 7：Cross-Region snapshot copy 保留來源 KMS key

KMS keys 是 Regional 的。目標副本使用目標 Region 的 key（你必須指定，否則會使用 AWS 管理的預設值）。

陷阱 8：PITR 可以還原至同一個 DB instance

不行。PITR 永遠建立帶有新端點的新 DB instance。切換是必要的。

陷阱 9：提升 read replica 後原本的主要 instance 依然在位

提升會中斷複寫，建立獨立的主要 instance。原本的主要 instance 不再是提升後 instance 的複寫來源，必須重新設定或解除。

陷阱 10：Glacier Expedited 取回適用於任意大小的物件

Expedited 通常僅支援約 250 MB 以內的物件；較大的物件必須使用 Standard 或 Bulk。請依物件大小規劃取回層級。

陷阱 11：停用 versioning 可以回到未啟用 versioning 的狀態

Versioning 一旦啟用，只能 Suspended——無法 Disabled。現有版本會持續保留，直到 lifecycle 讓它們到期。

陷阱 12：AWS Backup 是免費的

你需要支付儲存費用（溫儲存和冷儲存）、還原費用（每 GB）和 cross-region copy 費用。免費額度極少；操作上的結論是積極地將 lifecycle 設定為冷儲存。

SOA-C02 對比 SAA-C03：操作視角

SAA-C03 和 SOA-C02 都考備份與 DR，但視角不同。

SAA 考生選擇策略；SOA 考生執行程序、在出問題時除錯，並在事故期間操作還原。

考試訊號：如何辨識 Domain 2.3 題型

SOA-C02 上的 Domain 2.3 題型有可預期的模式。認識它們，你在每道題的作答時間會大幅縮短。

• 「還原會建立新資源」——所有 AWS Backup 和 RDS PITR 題型。注意「還原後的端點是什麼」或「下一步是什麼」。
• 「Lifecycle rule 失敗或意外觸發」——幾乎都是 30 天 Standard-IA 最短限制、90 天 Flexible Retrieval 最短限制或 180 天 Deep Archive 最短限制。
• 「合規性防竄改保留」——Vault Lock compliance mode 加上 72 小時寬限期，常與 S3 Object Lock compliance mode 組合出現。
• 「CRR 沒有在複寫」——某一側的 versioning 未開啟、IAM role 缺失、KMS key 存取被拒，或規則是在既有物件存在後才建立的（需要 Batch Replication）。
• 「Cross-region snapshot copy 無法讀取」——未指定目標 Region 的 KMS key，或目標帳號缺乏 key grants。
• 「災難復原程序」——提升 RDS read replica、擴展 DR Region ASG、更新 Route 53、驗證。
• 「自動排程 snapshots」——純 EBS 用 DLM，多資源環境用 AWS Backup。
• 「防止意外刪除」——versioning + MFA Delete（root user，僅限 CLI）。
• 「勒索軟體防護備份」——AWS Backup Vault Lock compliance mode，加上獨立帳號，加上 S3 Object Lock 用於物件層級資料。

決策矩陣 — 各 SysOps 目標對應的備份方式

考試時可用此表快速查找。

FAQ — 備份與災難復原

Q1：我的 RDS PITR 完成了，但應用程式無法連線——我漏了什麼？

新的 DB instance 有新的端點 hostname。PITR 從不覆蓋來源——它建立了 mydb-restored（或你指定的任何名稱），帶有新的 DNS 端點，如 mydb-restored.cluster-abc.us-east-1.rds.amazonaws.com。你的應用程式仍然指向舊端點。操作修正方式：更新應用程式的連線字串（在 Parameter Store、Secrets Manager 或環境變數中），或者——如果你使用 Route 53 / RDS Proxy——將別名重新指向新 instance。然後確認新 instance 有正確的安全群組、subnet group 和 parameter group；PITR 預設使用來源的設定，但允許你在還原時覆蓋。最後，只有在確認新 instance 正確提供服務後，才解除舊 instance。

Q2：為什麼我的 S3 lifecycle rule 被 InvalidArgument 拒絕？

最常見的原因是違反了最短年齡規則。S3 lifecycle 要求：

• 從 S3 Standard 轉移至 S3 Standard-IA 或 S3 One Zone-IA 前，至少等待 30 天。
• Standard-IA / One Zone-IA 在轉移至 Glacier 類型前，至少停留 30 天。
• Glacier Flexible Retrieval 的最短停留期為 90 天；Glacier Deep Archive 的最短停留期為 180 天。

如果你的規則寫了 Days: 10 用於 IA transition，S3 會拒絕。修正規則至 30 天以上。第二個原因是同一規則中動作衝突（transition 和 expiration 在同一天）。第三個原因是篩選器語法——規則前綴不能與另一條規則的前綴衝突，以至於排程變得不明確。

Q3：Vault Lock compliance mode 對比 governance mode——勒索軟體防護選哪個？

每次都選 Compliance mode。取得管理員憑證的勒索軟體攻擊者，在 governance mode 下可以呼叫 backup:DeleteRecoveryPoint 並在加密生產環境前清除你的備份。Compliance mode 在 72 小時寬限期過後，即使是 AWS root user 也禁止在排程到期前刪除 recovery points。代價是：如果你設錯了保留設定，就無法修正；必須等待 recovery points 自然到期。72 小時寬限期的存在，是為了讓你在鎖定成為不可逆前測試設定。對於 SOA-C02，「勒索軟體」、「內部威脅」或「監管機關要求防竄改」都對應到 compliance mode。

Q4：S3 CRR 如何處理設定規則前就已存在的物件？

預設情況下，CRR 只複寫規則建立後新建立的物件——既有物件不會補齊。若要複寫既有物件，需執行 S3 Batch Replication，它會建立一次性任務，依規則的篩選條件複製既有物件。Batch Replication 按物件數量和處理的 GB 計費。操作順序：建立 replication rule，然後從主控台 CRR 規則的「Replicate existing objects」工作流程啟動 Batch Replication 任務（或使用 s3control create-job，Operation: S3ReplicateObject）。等待批次任務完成，再視目標 bucket 為完全同步。

Q5：Cross-region 複製 EBS snapshot 後，目標 volume 還原失敗，出現 KMS 存取被拒——為什麼？

KMS keys 是 Regional 的。來源 snapshot 是用來源 Region 的客戶自管 CMK 加密的；複製操作用目標 Region 的 key 重新加密了它。如果你在複製參數中未指定目標 KMS key，AWS 使用了目標 Region 的 aws/ebs AWS 管理金鑰——而嘗試還原 volume 的 IAM 主體可能缺乏對該管理金鑰的 kms:Decrypt（在你的帳號有限制性 SCP 時有可能，但機率較低）。更常見的情況是：你在目標指定了客戶自管 CMK，但執行還原的 IAM 主體在該 CMK 的金鑰策略中沒有 grant。修正方式：預先在目標 Region 建立客戶自管 CMK，授予還原主體 kms:Decrypt，並在 DLM cross-region copy rule 中（或 copy-snapshot --kms-key-id）引用該 CMK。

Q6：使用冷儲存的 AWS Backup recovery point 可以設定的最短保留期是多少？

transition 至冷儲存的最短年齡是在溫儲存中保留 90 天（不能在備份後立即 transition）。進入冷儲存後，recovery point 必須至少在那裡保留 90 天 才能刪除——這是 AWS Backup 強制執行的最短停留期，類似於 S3 Glacier 的提前刪除規則。因此，任何冷層 recovery point 的最短總保留期是至少 90 + 90 = 180 天。試圖指定更短冷儲存保留期的 plan 會被拒絕。對於更短的總保留期，請將 recovery points 只保留在溫儲存中（不做冷 transition）；溫儲存沒有最短限制，支援從 1 天起的任意保留期。

Q7：我應該在每個生產 S3 bucket 上啟用 MFA Delete 嗎？

可能不是每個 bucket，但對於存放不可替代資料的 bucket（法規典藏、客戶資料的主副本、關鍵工作負載的唯一備份）應該啟用。取捨如下：

• 優點：就算管理員 IAM 憑證被盜，也無法在沒有 root user MFA token 的情況下永久刪除物件版本或變更 versioning 狀態。
• 缺點：每次合法的版本清除（lifecycle non-current expiration 沒問題；手動刪除版本操作則需要）都要求 root user 攜帶 MFA——操作上相當不便。

務實的模式：在法規典藏 bucket 和最後防線備份 bucket 上啟用 MFA Delete，但不是每個工作 bucket。對於非典藏 bucket，偏好使用S3 Object Lock governance 或 compliance mode 作為較少干擾的替代方案，因為 Object Lock 適用於特定物件版本，並且可以與正常 IAM 驅動的非鎖定物件刪除共存。

Q8：我可以用 AWS Backup 備份 S3 bucket 嗎？

可以——AWS Backup 已新增 S3 支援，它會備份物件和 bucket 層級設定（versioning 狀態、加密、ACLs、tags、lifecycle、public access block、replication）。備份可以跨 Region 和跨帳號，並可參與 Vault Lock。操作使用情境：你希望在 RDS、EBS、EFS、DynamoDB 和 S3 上有單一稽核介面——不只依賴 S3 versioning + CRR，AWS Backup 讓你對整個資源環境的 recovery points 套用統一的保留和鎖定策略。還原時建立新 bucket 或複製到現有 bucket。AWS Backup for S3 的計費方式為存儲於 vault 的每 GB 加上還原費用；對於寫入頻繁的 bucket，儲存成本可觀，因此大多數團隊只對關鍵 bucket 使用 AWS Backup for S3，其餘則依賴 versioning + CRR。

Q9：RDS read replica 的 ReplicaLag 與 S3 CRR 的 replication latency 在操作上有何差異？

ReplicaLag（read replica DB instance 上的 CloudWatch 指標）衡量的是 replica 在 transaction-log 重播上落後 primary 多少秒。ReplicaLag 為 60 秒的 replica 表示有一分鐘的資料過期；提升它最多損失一分鐘的寫入。這個指標持續發布，是 RDS 複寫最重要的監控訊號。S3 CRR 的 ReplicationLatency（CloudWatch，需啟用 RTC 才有）衡量的是每個物件從來源 PUT 到目標可用的時間；有 RTC 時，SLA 是 99.99% 在 15 分鐘內。沒有 RTC，S3 預設不發布 replication latency，且對非常大的物件或在節流期間，盡力而為的複寫可能需要更長時間。SOA-C02 有時問「如何監控複寫是否跟得上？」——答案是 RDS 的 ReplicaLag 和 S3 CRR 的 ReplicationLatency（需有 RTC）。

Q10：我們需要 S3 資料的 RPO 為 15 分鐘，RDS 資料庫的 RPO 為 5 分鐘。操作設定是什麼？

針對 S3：在來源和目標 bucket 上啟用 versioning，設定 CRR with Replication Time Control（RTC）（提供 SLA 保障的 15 分鐘 RPO 目標），加上 CloudWatch 對 ReplicationLatency 和 BytesPendingReplication 的 alarms，以便在複寫落後時收到通知。若不想讓 CRR 傳播刪除，關閉刪除標記複寫；或在目標上啟用 Object Lock compliance mode，讓版本無論如何都防竄改。針對 RDS：啟用 Multi-AZ（Region 內 60–120 秒故障切換）加上 35 天保留期的自動備份（Region 內 PITR），以及用於跨 Region 故障切換情境的 cross-region read replica（ReplicaLag 通常低於 5 秒）。對 ReplicaLag > 300（5 分鐘）以及最近可還原時間與當前時間之差設定 CloudWatch alarm。這個組合能以可量測、可告警的訊號同時達成兩個 RPO 目標。

延伸閱讀與相關操作模式

• What Is AWS Backup
• AWS Backup Plans
• AWS Backup Vaults
• AWS Backup Vault Lock
• Restoring a Backup with AWS Backup
• RDS Point-in-Time Restore
• Promoting an RDS Read Replica
• Using S3 Versioning
• Configuring MFA Delete
• Managing the Lifecycle of S3 Objects
• S3 Lifecycle Transition Considerations
• Replicating Objects in S3
• Locking Objects with S3 Object Lock
• S3 Storage Classes
• Glacier Retrieval Options
• Amazon Data Lifecycle Manager
• Copying an EBS Snapshot
• Disaster Recovery of Workloads on AWS — Whitepaper
• AWS SOA-C02 Exam Guide v2.3（PDF）

備份與災難復原程序就緒後，接下來的操作層級是：RDS 和 Aurora 韌性（PITR 和 read replica 提升所在的資料庫層）、CloudTrail 和 AWS Config（證明備份操作正在執行、recovery points 不可篡改的稽核軌跡）、資料保護與加密（加密 vaults 和 cross-region snapshots 的 KMS keys），以及 CloudWatch metrics 和 alarms（在下一場真實災難迫使故障切換之前，及早發現複寫延遲和備份任務失敗的監控層）。

• RDS and Aurora Multi-AZ, Read Replicas, and Caching — SOA-C02 Study Notes
• CloudTrail and AWS Config for Audit and Compliance — SOA-C02 Study Notes
• Data Protection: KMS, ACM, Secrets Manager, and Security Findings — SOA-C02 Study Notes
• CloudWatch Metrics, Alarms, and Dashboards — SOA-C02 Study Notes