災難復原策略與業務持續性

AWS 災難復原策略定義了工作負載在面對區域級故障、大規模資料毀損事件，以及高可用性（HA）架構本身無法應對的重大中斷時，如何確保業務持續性。在 SAA-C03 考試中，你必須熟悉四大標準災難復原策略——備份與還原（Backup and Restore）、Pilot Light、暖備援（Warm Standby）、多站點主動－主動（Multi-Site Active-Active）——以及各自的 RTO/RPO 特性、成本取捨，以及實作每種模式所對應的具體 AWS 服務。災難復原策略同時涵蓋資料複寫機制（S3 CRR、Aurora Global Database、DynamoDB Global Tables）、流量容錯移轉（Route 53），以及區塊級複寫（AWS Elastic Disaster Recovery）。掌握災難復原策略對 Domain 2（設計具韌性的架構）至關重要，該領域佔 SAA-C03 考試權重的 26%。

本頁屬於任務陳述 2.2——「設計高可用性和／或容錯架構」。它是 high-availability-multi-az 主題的兄弟頁面。HA 涵蓋單一 Region 內部（Multi-AZ、ALB、ASG）；災難復原策略則涵蓋 HA 無法解決的跨 Region 與業務持續性面向。有關備份保留原則、WORM 與治理相關問題，請參閱 data-governance-compliance。

什麼是 AWS 災難復原策略？

AWS 災難復原策略是預先設計好的架構模式，能讓工作負載在主要 Region 發生故障後，在次要 Region（或次要基礎設施）中恢復運作。AWS 在官方白皮書《Disaster Recovery of Workloads on AWS》中記錄了四種標準災難復原策略——SAA-C03 考試大量參考此文件。四種策略各自以成本換取復原速度；身為解決方案架構師，你的任務是挑選 RTO/RPO 特性符合業務需求、且成本最具說服力的策略。

SAA-C03 考試以三種重複出現的題型考察災難復原策略。第一種是定義題，要求你將 RTO/RPO 數值與策略名稱配對。第二種是情境題，描述業務需求（例如「金融交易平台，零資料損失」），並詢問哪種災難復原策略最合適。第三種是服務對應題，詢問哪項 AWS 服務能實作特定的複寫保證（S3 Replication Time Control 適用 15 分鐘 SLA；Aurora Global Database 約 1 秒延遲；DynamoDB Global Tables 適用主動－主動寫入）。

為何災難復原策略的重要性超越 HA

高可用性（HA）在單一 Region 內可防範 AZ 級故障——例如變電站跳電、機房淹水、影響單棟建築的冷卻系統故障。災難復原策略則防範 HA 無法應對的情境：全 Region 服務中斷、涵蓋數百公里的自然災害、同時蔓延到所有 AZ 的軟體 bug、加密主要 Region 所有 EBS Volume 的勒索軟體，以及法規要求在不同司法管轄區設置 DR 站點。每個嚴肅的生產工作負載都同時需要 HA 和災難復原策略。

四種標準災難復原策略

AWS 將災難復原策略依成本對復原時間排列成一個梯階：

1. 備份與還原（Backup and Restore） — 成本最低，RTO 最高（數小時）。定期備份跨 Region 複製；基礎設施在需要時重建。
2. Pilot Light — 低成本，RTO 數小時。核心資料已複寫並持續運行；應用層在容錯移轉前保持休眠。
3. 暖備援（Warm Standby） — 中等成本，RTO 數分鐘。在 DR Region 中持續運行縮減規模的完整技術堆疊。
4. 多站點主動－主動（Multi-Site Active-Active） — 成本最高，RTO 數秒。兩個 Region 均具備完整生產容量，同時提供即時流量。

白話解說 — 用生活情境理解災難復原策略

災難復原策略聽起來很抽象，但四種選項可以清楚地對應到日常的備援行為。以下用三種不同領域的類比，讓你在考試時至少有一種能迅速喚起記憶。

類比一 — 備援的火種保留策略

四種災難復原策略就像廚房的備援火種計畫。

• 備份與還原是「把食譜和食材清單存進保險箱」的做法。廚房失火後，團隊得重新租廚房、取出食譜、重新訂食材、重新招募廚師，才能重新開張。成本最低，但停業時間可能以天計算。「食材」對應的是複製到 DR Region 的 S3 備份；「食譜」對應的是 CloudFormation 或 Terraform 模板；「新廚房」就是災難發生後重新建起的基礎設施。

• Pilot Light 是「在第二個據點備好一車冷藏醬料與麵糰」的做法。爐火沒開，但易腐食材都是新鮮的。主廚房失火後，廚師趕到現場，點燃爐火，幾小時內就能出餐。在 AWS 中，這對應到在 DR Region 已有複寫的資料庫（Aurora Global Database 次要叢集、DynamoDB Global Tables 複本），運算基礎設施已定義好但尚未啟動。

• 暖備援是「經營一間每天正常出餐、但容量只有主廚房一成的小型快閃廚房」的做法。它有員工、有測試、也有真實客人。主廚房失火後，快閃廚房全速拉升至 100% 容量。在 AWS 中，ASG 以最低容量運行、ALB 已上線、資料庫透過複寫持續接收寫入。

• 多站點主動－主動是「同時經營兩間等規模的旗艦廚房，東區顧客去 A 廚房、西區顧客去 B 廚房，菜單完全相同」。A 廚房失火，B 廚房接收全部客流，毫不中斷。在 AWS 中，DynamoDB Global Tables 在兩個 Region 接受寫入並解決衝突；Aurora Global Database 可快速晉升，或以應用層協調兩個獨立叢集。

類比二 — 保險保障階梯

災難復原策略的行為就像為房屋購買保險。

• 備份與還原是便宜的定期保險。每月繳小額保費，房子燒毀後，保險公司需要數週勘查，你暫住旅館，最終從頭重建。成本低，復原慢。在 AWS 中，備份靜靜地存放在 S3 或 AWS Backup 的跨 Region 副本中，災難發生後再從模板和還原的資料重新建置基礎設施。RTO 以小時至一天計算。

• Pilot Light 像擁有一間已接上水電、冰箱已插電、行李箱裡備有必需品的空置第二套房。主要住所失火，當天就能搬進去，之後幾小時再把其他家具補齊。在 AWS 中，DR Region 的資料庫複本已上線，AMI 與模板已備妥，但 Web 伺服器尚未啟動。容錯移轉觸發後，擴展運算層，Route 53 切換流量。

• 暖備援像擁有一棟已完整裝潢、由管家小規模維持日常運作的第二套房。一切正常運作，但這棟房子只能住兩個人，不能住十個。主要住所出問題，家人搬進去，管家迅速備齊物資。在 AWS 中，縮減規模的生產堆疊持續運行；容錯移轉在幾分鐘內觸發擴展與流量切換。

• 多站點主動－主動像同時擁有兩棟全員配置的房子，家庭成員在兩棟之間輪流居住。其中一棟失火，另一棟的生活不會有絲毫中斷。最高成本，零停機。在 AWS 中，兩個 Region 透過 Route 53 延遲型路由、Global Accelerator 或 CloudFront 同時服務用戶流量。

類比三 — 航空公司的備援應變手冊

航空公司對航班緊急備降有一套實際的災難復原策略。

• 備份與還原像把備用零件庫存集中放在一個倉庫。飛機受損後，把零件運到機場，機械師到場，花很長時間修好飛機。成本最低，因為只維護一套庫存，但復原很慢。這對應 AWS 中的備份與還原：一套備份，災難後重建一切。

• Pilot Light 像在每個樞紐機場預先備置引擎重建套件。引擎還沒裝進備用飛機，但套件已就位，機械師組可以迅速完成安裝。核心資產（引擎套件）是「熱」的，周邊基礎設施（飛機）可以快速到位。在 AWS 中，資料層始終在線；運算層可在幾分鐘內從模板建起。

• 暖備援像在每個樞紐機場停放一架已加半桶油的備用飛機，配有一支精簡機組。它每天飛短程航班，但幾分鐘內可以升級為主力航線。在 AWS 中，一個小型但完整的生產環境始終運行。

• 多站點主動－主動像同時運營兩個全容量的樞紐機場，服務相同航線——桃園和高雄，同時都是相同航線的樞紐。桃園因颱風關閉，高雄接收全部旅客，沒有任何班機取消。在 AWS 中，兩個 Region 都接受即時流量，由 Route 53 或 Global Accelerator 負載均衡。

三個類比，一個結論：災難復原策略用金錢換取復原速度。事前付出越多，復原越快。SAA-C03 考試的題幹中永遠會告訴你 RTO/RPO 目標——你的任務是選出仍能滿足目標的最便宜災難復原策略。

RTO 與 RPO — 定義每種災難復原策略的兩個數字

所有災難復原策略的討論都從兩個數字開始：RTO（復原時間目標）與 RPO（復原點目標）。混淆這兩者是 SAA-C03 最常見的陷阱之一。

RTO — 我們能停機多久？

RTO 衡量從災難事件到服務恢復之間可接受的最長時間，永遠以時間長度表示——秒、分鐘、小時或天。RTO 為 4 小時代表企業願意容忍最多 4 小時的停機。RTO 為 30 秒代表需要近乎即時的切換。RTO 決定你選擇四種災難復原策略中的哪一種，因為每種策略都有不同的復原時間下限。

RPO — 我們能損失多少資料？

RPO 衡量可接受的最大近期資料損失量，同樣以時間表示。RPO 為 1 小時代表你可以損失過去 60 分鐘的資料。RPO 為零代表任何已提交的交易都不能遺失。RPO 決定你的資料複寫選擇——每日備份帶來 24 小時 RPO、S3 CRR 通常帶來幾分鐘 RPO、S3 Replication Time Control 提供 15 分鐘 SLA、Aurora Global Database 約 1 秒 RPO、DynamoDB Global Tables 提供亞秒 RPO。

座標軸圖

以 RTO 為橫軸、RPO 為縱軸繪製座標。四種災難復原策略分布在不同象限：

• 右上角（高 RTO、高 RPO）：備份與還原。
• 中間（中等 RTO、中低 RPO）：Pilot Light。
• 中下（低 RTO、低 RPO）：暖備援。
• 左下角（近零 RTO、近零 RPO）：多站點主動－主動。

四種災難復原策略的典型 RTO/RPO 目標

• 備份與還原 — RTO 數小時至 24 小時，RPO 數小時（取決於備份頻率）。
• Pilot Light — RTO 數十分鐘，RPO 數分鐘。
• 暖備援 — RTO 數分鐘，RPO 數秒至數分鐘。
• 多站點主動－主動 — RTO 近零，RPO 近零。

SAA-C03 考試始終使用這些區間。請熟記它們。

策略一 — 備份與還原（成本最低、速度最慢）

備份與還原是入門級的災難復原策略。對於能容忍數小時停機、且在成本限制下無法為待機基礎設施買單的工作負載，這是正確的選擇。

備份與還原的運作方式

1. 生產環境在 Region A（主要）運行。
2. 排程備份將資料複製到 Region B（DR）。常見機制：AWS Backup 跨 Region 複製、S3 Cross-Region Replication、EBS 快照跨 Region 複製、RDS 自動快照複製。
3. 災難發生時，操作人員（或自動化流程）在 Region B 使用基礎設施即程式碼（CloudFormation、CDK、Terraform）佈建基礎設施，從跨 Region 備份還原資料，並透過 Route 53 DNS 變更將流量導向新環境。

成本特性

備份與還原幾乎沒有持續性成本，僅需支付儲存費用：你只需為 Region B 的備份資料及偶爾的跨 Region 資料傳輸付費。沒有閒置的 EC2 執行個體、閒置的 RDS 執行個體、閒置的負載平衡器。這使備份與還原成為開發／測試環境、內部工具和非核心營收工作負載的預設選擇。

復原特性

復原時間較長，因為你需要在宣告災難時從頭重建基礎設施。即使有完善的自動化，啟動完整生產堆疊通常也需要至少 30 至 60 分鐘；實際復原往往需要數小時。RPO 與備份頻率相符——每小時備份提供小時級 RPO，每晚備份提供天級 RPO。

常用 AWS 服務

• AWS Backup — 含跨 Region 複製的集中式備份計畫。
• S3 Cross-Region Replication (CRR) — 非同步物件複寫。
• Amazon EBS 快照跨 Region 複製 — Volume 快照後複製。
• Amazon RDS 自動快照 — 透過排程複製傳送到 DR Region。
• CloudFormation / CDK 模板 — 容錯移轉時用於重建的基礎設施藍圖。

策略二 — Pilot Light

Pilot Light 比備份與還原高一階。它讓核心資料層在 DR Region 持續複寫並運行，而應用與 Web 層則保持休眠。

Pilot Light 的運作方式

這個術語來自瓦斯爐：一個持續燃燒的小火種（「引燃火焰」）能在需要時迅速點燃主爐。在 AWS 災難復原策略中，這個「火種」就是資料庫或資料存放：

• Aurora Global Database 次要 Region 接收持續複寫，典型延遲低於一秒。
• DynamoDB Global Tables 複本存在於 DR Region。
• S3 Cross-Region Replication 鏡像物件資料。
• AMI、啟動模板、CloudFormation 堆疊預先暫存於 DR Region，但 EC2 執行個體、ECS 服務與負載平衡器容量尚未啟動（或以零容量運行）。

容錯移轉序列

1. 宣告災難。
2. 將 Aurora Global Database 次要晉升為主要（或啟動寫入端點）。
3. 將 ASG、ECS 服務、Lambda 並發從零擴展至生產容量。
4. 更新 Route 53 DNS 記錄（或觸發預先設定的容錯移轉路由），指向 DR Region。
5. 驗證流量、監控、凍結主要 Region。

成本與復原特性

Pilot Light 的成本高於備份與還原，因為你需要持續為複寫的資料層付費——Aurora Global Database 即使在被動狀態下也需為次要叢集付費，DynamoDB Global Tables 需為複寫寫入付費，S3 複寫儲存需計費。但運算成本接近零。由於大部分時間都花在啟動和預熱運算容量上，復原時間為數十分鐘。

策略三 — 暖備援（Warm Standby）

暖備援再提高一個層次：在 DR Region 中，一個縮減規模但功能完整的生產堆疊持續運行。它不處理任何用戶流量（或僅處理極少量的金絲雀流量），但架構的每一層都處於活躍狀態。

暖備援的運作方式

• 資料庫層：Aurora Global Database、DynamoDB Global Tables 或 RDS 跨 Region 唯讀副本——持續同步。
• 應用層：ECS 服務或 ASG 以最低容量運行（例如，2 個任務而非 20 個，t3.medium 而非 c6i.4xlarge）。
• 負載平衡器：ALB/NLB 已部署且可連接。
• DNS：Route 53 設定了容錯移轉或加權路由，目前將 0%（或極小比例）的流量傳送到 DR Region。

容錯移轉序列

1. 宣告災難。
2. Auto Scaling 原則將 DR Region 的運算層擴展至生產容量。
3. 資料庫晉升（Aurora Global Database 非計畫性容錯移轉通常在一分鐘內完成）。
4. Route 53 容錯移轉記錄翻轉；健康檢查將主要 Region 標記為不健康，DNS 解析轉移至 DR。
5. 用戶重新連線；RTO 以分鐘計算。

成本與復原特性

暖備援比 Pilot Light 明顯昂貴，因為運算層全天候以小規模運行——你需要為執行個體、負載平衡器、快取節點付費。由於無需冷啟動，復原速度更快；發生的一切只是擴展。另一個優點是：DR 堆疊始終在線，主要與 DR 之間的操作漂移極小，還原的可信度更高。

暖備援的變體

• 靜態穩定縮減 — 固定的小型機隊，容錯移轉時擴展。
• 主動－被動（含金絲雀流量） — 將 1-5% 的真實流量路由到 DR，以持續驗證堆疊。

金絲雀變體特別強大，因為它將 DR Region 轉化為一個持續被測試的環境，而非依賴假設。

策略四 — 多站點主動－主動（Multi-Site Active-Active）

多站點主動－主動是災難復原策略梯階的頂端。兩個 Region 同時提供真實用戶流量；任何單一 Region 的故障都被其他 Region 吸收，停機時間極短甚至為零。

多站點主動－主動的運作方式

• 資料層 — 多主資料存放，例如 DynamoDB Global Tables（最後寫入者勝出衝突解決）或啟用了寫入轉發的 Aurora Global Database。對於嚴格一致性，某些架構在單一寫入 Region 保留同步複寫，並由容錯移轉驅動寫入晉升。
• 運算層 — 兩個 Region 均具備完整生產容量。ASG 等比例擴展，ECS 叢集規模相同。
• 流量路由 — Route 53 延遲型路由、AWS Global Accelerator 或具有多來源容錯移轉的 CloudFront，將用戶導向健康且距離最近的 Region。

容錯移轉特性

傳統意義上不存在「容錯移轉事件」。若 Region A 降級，Route 53 健康檢查（或 Global Accelerator 端點健康狀態）將受影響的端點標記為不健康，並將新連線導向 Region B。現有的工作階段可能需要重新連線，但不需要管理員介入。RTO 趨近於零；RPO 取決於複寫技術（DynamoDB Global Tables 提供亞秒；Aurora Global Database 約 1 秒）。

成本與複雜度特性

這是成本最高的災難復原策略——你需要為兩個（或多個）完整生產堆疊付費。它也是操作上最複雜的：部署程式碼變更需要跨 Region 協調，多主資料的衝突解決引入了應用層設計工作。只有當業務停機成本明顯超過雙倍基礎設施成本時，才選擇多站點主動－主動。

S3 複寫 — CRR、SRR 與 Replication Time Control

S3 複寫是物件資料災難復原策略的主力。SAA-C03 考試考察 Cross-Region Replication（CRR）、Same-Region Replication（SRR）與 Replication Time Control（RTC）之間的差異。

Cross-Region Replication（CRR）

CRR 將物件從一個 Region 中的來源儲存桶非同步複製到另一個 Region 的目標儲存桶。典型使用情境：

• 災難復原策略 — 防範 Region 級故障。
• 降低延遲 — 將靜態資源副本放置在多個地理位置靠近用戶的地方。
• 合規 — 在特定司法管轄區維護副本。

CRR 是非同步的。在預設設定下，複寫延遲通常為數分鐘，但沒有 SLA 保證。

Same-Region Replication（SRR）

SRR 將物件複製到同一 Region 中的不同儲存桶。它本身不是 DR 機制（若 Region 故障，兩份副本同時受影響），但支援以下情境：

• 將多個儲存桶的日誌彙總到一個儲存桶以進行分析。
• 在同一 Region 的開發／測試／生產帳號之間複製資料。
• 保留具有不同加密金鑰、物件擁有權或生命週期規則的副本。

Replication Time Control（RTC）

Replication Time Control 是 CRR 的付費功能，提供 15 分鐘 SLA 及額外監控：99.99% 的複寫物件必須在上傳到來源後 15 分鐘內抵達目標。當題幹要求有保證的複寫 SLA 時——最常見於金融服務、醫療或受監管行業的嚴格 RPO 目標——RTC 是正確答案。

其他 S3 複寫功能

• 刪除標記複寫 — 選擇性複寫刪除標記，用於合規稽核。
• Replica modification sync（RMS） — 用於主動－主動模式的雙向中繼資料同步。
• 批次複寫（Batch Replication） — 為啟用複寫之前就已存在的物件進行回填複寫。
• 雙向複寫 — 將兩個儲存桶互相設定為來源和目標，用於主動－主動情境。

AWS Backup — 災難復原策略的集中式備份

AWS Backup 是全託管服務，提供跨多個 AWS 服務的原則驅動集中式備份。當情境詢問「跨服務集中備份」或「EBS、RDS、DynamoDB、EFS 等的統一備份原則」時，它是標準答案。

AWS Backup 支援的服務

• Amazon EBS Volume
• Amazon RDS 資料庫（含 Aurora）
• Amazon DynamoDB 資料表
• Amazon EFS 檔案系統
• Amazon FSx 檔案系統
• Amazon EC2 執行個體
• AWS Storage Gateway Volume
• Amazon Redshift 叢集（透過快照）
• Amazon S3（持續備份並支援時間點還原）
• VMware 工作負載（透過 AWS Backup Gateway）

關鍵概念

• 備份計畫（Backup Plan） — 排程 + 保留 + 生命週期（例如：每日備份、保留 35 天、7 天後轉移至冷儲存）。
• 備份保存庫（Backup Vault） — 復原點的加密儲存容器；支援 AWS Backup Vault Lock 以實現 WORM／不可變備份。
• 資源指派（Resource Assignment） — 依標籤或資源選擇哪些資源納入計畫。
• 跨 Region 複製 — 作為備份計畫的一部分，將復原點複製到 DR Region。
• 跨帳號複製 — 複製到獨立的 AWS 帳號（例如「保存庫帳號」），以防範帳號遭到入侵的情境。
• AWS Backup Audit Manager — 合規報告，確認備份是否按原則執行。

為何 AWS Backup 是災難復原策略的基礎元件

在 AWS Backup 出現之前，多服務的 DR 意味著拼接各服務特有的快照 API、CloudWatch Events、Lambda 自動化和自訂保留邏輯。AWS Backup 將這一切整合到一個具備跨 Region 與跨帳號複製的單一託管控制平面中。對於備份與還原類型的災難復原策略，AWS Backup 在 SAA-C03 上幾乎總是首選答案。

AWS Backup Vault Lock

Vault Lock 提供 WORM 語意：一旦以合規模式啟用，即使是 Root 用戶也無法在保留期到期前刪除復原點。這使備份免受勒索軟體和惡意內部人員的攻擊——這是一個關鍵屬性，因為勒索軟體攻擊者通常在加密主要資料之前先嘗試銷毀備份。

Aurora Global Database — 跨 Region 關聯式 DR

Aurora Global Database 是 SAA-C03 中「需要跨 Region MySQL 或 PostgreSQL 資料庫、複寫延遲極低且容錯移轉快速」問題的標準答案。

架構

• 一個主要 Region 接受讀取和寫入。
• 最多五個次要 Region 接收複寫，典型延遲低於一秒。
• 複寫使用獨立於資料庫引擎的專用儲存層通道，因此不消耗主要 Region 的運算或網路頻寬。
• 每個次要 Region 最多可託管 16 個唯讀副本，用於本地讀取擴展。

容錯移轉行為

• 託管計畫性容錯移轉 — 以近零資料損失將次要 Region 晉升為主要；典型 RTO 約一分鐘。
• 非計畫性跨 Region 容錯移轉 — 分離次要 Region，將其晉升為獨立叢集，並重新指向應用程式；在幾分鐘內完成。
• 託管非計畫性容錯移轉（較新功能） — AWS 管理的非計畫性容錯移轉，保留全球拓撲。

災難復原策略的使用情境

• Pilot Light — 次要 Region 叢集在線，應用層休眠。
• 暖備援 — 次要 Region 託管一個小型應用堆疊，從本地 Aurora 副本讀取。
• 多站點主動－主動 — 結合寫入轉發，允許次要 Region 的應用層提交被轉發到主要 Region 的寫入。

考試陷阱 — Global Database 與跨 Region 唯讀副本

Amazon RDS for MySQL、MariaDB 和 PostgreSQL 也在非 Aurora 引擎上支援「跨 Region 唯讀副本」。這與 Aurora Global Database 不同。跨 Region 唯讀副本使用引擎級邏輯複寫，延遲較高，也無法提供 Aurora Global Database 的亞秒 RPO。當題幹提到「Aurora」+「跨 Region」+「低 RPO」時，答案是 Aurora Global Database。

DynamoDB Global Tables — 多 Region 主動－主動 NoSQL

DynamoDB Global Tables 是 Aurora Global Database 在災難復原策略中的 NoSQL 對應方案。它提供多 Region、多主動複寫，採用最後寫入者勝出的衝突解決機制。

Global Tables 的運作方式

你在 DynamoDB 資料表上啟用 Global Tables 並新增複本 Region。任何 Region 的寫入都會非同步複寫到所有其他複本 Region，通常在一秒內完成。應用程式可以對距離最近的 Region 進行讀取和寫入，並以最後寫入者勝出（基於時間戳記）的語意處理衝突。

為何 Global Tables 適合多站點主動－主動

• 沒有單一寫入瓶頸——所有複本都接受寫入。
• 亞秒複寫延遲——RPO 近零。
• 自動衝突解決——不需要人工介入。
• 與 Route 53 延遲型路由整合——應用程式自然路由到最近的 Region。

成本與注意事項

• 每個複本 Region 都必須佈建（或隨需）寫入容量。Region A 的寫入會複寫到 Region B 和 C，因此三個 Region 都需要支付寫入單位費用。
• 最後寫入者勝出對嚴格一致性工作負載（金融分類帳）可能不適合——使用等冪且無衝突的資料模型。
• 時間點復原（PITR）是依 Region 計算的；在 Global Table 上還原 PITR 需要特別謹慎。

Route 53 容錯移轉 — DNS 層級的流量導向

Route 53 是使災難復原策略容錯移轉對終端用戶可見的控制平面。它將健康檢查結果對應到 DNS 答案，在 Region 之間切換流量，而無需應用程式直接協調。

容錯移轉路由原則

最簡單的模式：一個主要記錄、一個次要記錄、一個健康檢查。若主要 Region 的健康檢查失敗，Route 53 返回次要記錄。這是 Pilot Light 和暖備援災難復原策略的經典主動－被動模式。

健康檢查

Route 53 健康檢查從多個 AWS Edge Location 探測端點。若大多數探測失敗，端點被標記為不健康。健康檢查支援：

• 端點健康檢查 — HTTP/HTTPS/TCP 探測。
• 計算型健康檢查 — 以 AND/OR 邏輯彙總多個子檢查。
• CloudWatch 警示健康檢查 — 從 CloudWatch 指標衍生健康狀態（例如 ALB 錯誤率、自訂業務指標）。

其他與 DR 相關的 Route 53 路由原則

• 加權路由 — 逐步將一定比例的流量切換到 DR，作為金絲雀切換的一部分。
• 延遲型路由 — 將每個用戶傳送到延遲最低的健康 Region（多站點主動－主動）。
• 地理位置路由 — 依國家／大洲將用戶固定到特定 Region。
• 多值答案路由 — 返回多個健康 IP，用於簡單的用戶端容錯移轉。

TTL 的影響

DNS TTL 限制了容錯移轉速度。若你的 TTL 為 300 秒，用戶端在容錯移轉後可能快取主要記錄長達 5 分鐘。在進行災難復原策略演練之前縮短 TTL（30-60 秒）；接受極低 TTL 會略微增加 DNS 查詢成本；當 DNS 快取延遲不可接受時，考慮使用 AWS Global Accelerator。

AWS Elastic Disaster Recovery（DRS）— 區塊級複寫

AWS Elastic Disaster Recovery（AWS DRS，前身為 CloudEndure Disaster Recovery）是針對伺服器——EC2 執行個體、本地端實體伺服器和 VM——進行區塊級複寫並導入 AWS 的服務，適用於災難復原策略使用情境。

DRS 的運作方式

1. 在來源伺服器（本地端、VM 或 EC2）上安裝 AWS Replication Agent。
2. Agent 持續將磁碟區塊複寫到目標 AWS Region 的低成本暫存儲存空間（連接至輕量複寫伺服器的 EBS Volume）。
3. 容錯移轉時，DRS 使用最新複寫狀態在目標 Region 啟動完整佈建的 EC2 執行個體，通常在幾分鐘內完成。
4. 容錯回復時，反向複寫將變更帶回來源。

何時使用 DRS

• 本地端工作負載的直接遷移 DR — 不想重新架構為原生 AWS 服務，但仍需跨雲 DR 的伺服器。
• 跨 Region 的 EC2 DR — 無法進行應用層複寫時的區塊級複寫。
• 跨雲 DR — 從其他雲端複寫到 AWS。

DRS vs 原生服務複寫

若你的工作負載已是雲端原生（Aurora、DynamoDB、S3），請使用服務原生複寫（Global Database、Global Tables、CRR）。DRS 特別適用於區塊層是正確複寫單元的舊式或第三方工作負載。

成本特性

DRS 的穩定狀態成本較低——你只需為暫存 EBS Volume 和小型複寫伺服器付費。完整容量成本只有在啟動復原執行個體時才會產生。這使 DRS 非常適合無法重新架構的基礎設施的 Pilot Light 災難復原策略。

跨 Region vs 跨 AZ — 選擇正確的故障邊界

SAA-C03 的一個反覆出現的陷阱是詢問 Multi-AZ 是否足夠，還是需要 Multi-Region。正確答案取決於業務必須能夠應對的故障情境。

Multi-AZ 能防範的情境

• 單一資料中心損失（火災、洪水、停電事件）。
• 單一 AZ 網路分區。
• 單一 AZ 硬體機隊故障。
• 影響一個都會區子區域的局部自然災害。

Multi-AZ 是高可用性，而非災難復原。AWS 上大多數生產工作負載應預設採用 Multi-AZ——RDS Multi-AZ、跨 2-3 個 AZ 的 ASG、S3（預設 Multi-AZ）、EFS（預設 Multi-AZ）。

Multi-AZ 無法防範的情境

• 全 Region 服務控制平面中斷（罕見但真實存在）。
• 涵蓋整個 Region 地理範圍的自然災害。
• 同時部署到所有 AZ 的軟體 bug 或設定錯誤。
• 要求 DR 站點位於不同司法管轄區的法規。
• 加密一個 Region 中所有 Volume 的勒索軟體事件。
• 帳號級入侵（除非結合跨帳號複製）。

對於上述任何情境，你需要跨 Region 的災難復原策略。

決策框架

依序提出四個問題：

1. 法規是否要求跨 Region DR？（某些司法管轄區的銀行、醫療）。若是，Multi-Region 是必要的。
2. RTO/RPO 是什麼？ 若要求在業務僅需應對部分 Region 中斷的情況下達到一分鐘以內的 RTO，Multi-AZ 可能足夠；若要求在全 Region 中斷的情況下達到一分鐘以內的 RTO，則需要 Multi-Region。
3. 成本容忍度是多少？ 在主動－主動極端情況下，Multi-Region 的基礎設施成本大約翻倍；需與停機的營收損失進行量化比較。
4. 用戶的地理分布範圍有多廣？ 全球用戶群通常能從兼具 DR 功能的 Multi-Region 部署中獲得延遲優勢——DR 成本被效能收益所抵消。

將災難復原策略對應到業務需求

SAA-C03 考試經常提供業務描述，讓你挑選災難復原策略。使用以下決策樹。

步驟一 — 閱讀 RTO 和 RPO 目標

若題目提供明確的 RTO/RPO 數字，直接對應：

• RTO 24 小時以上，RPO 24 小時以上 → 備份與還原。
• RTO 1-4 小時，RPO 數分鐘 → Pilot Light。
• RTO 5-30 分鐘，RPO 數秒至數分鐘 → 暖備援。
• RTO 數秒，RPO 近零 → 多站點主動－主動。

步驟二 — 閱讀成本信號

若題目強調「最低成本」、「成本受限」或「最小化費用」，在滿足 RTO/RPO 的前提下，優先選擇最左側的策略（備份與還原）。若題目強調「關鍵任務」、「零停機」、「永遠在線」，則優先選擇最右側的策略。

步驟三 — 閱讀服務提示

特定服務提及會影響正確答案：

• 「DynamoDB」+「多 Region」+「主動－主動」→ DynamoDB Global Tables（多站點主動－主動）。
• 「Aurora」+「近零 RPO」+「分鐘級 RTO」→ Aurora Global Database（Pilot Light 或暖備援）。
• 「從本地端持續複寫伺服器」→ AWS Elastic Disaster Recovery。
• 「跨服務集中備份」→ AWS Backup。
• 「物件的 15 分鐘複寫 SLA」→ S3 Replication Time Control。

步驟四 — 根據成本容忍度進行驗證

最後，確認架構成本合理。若題幹說「重視成本的新創公司」，不要選擇多站點主動－主動——即使 RTO 目標在技術上符合。

資料耐久性 vs 可用性 — S3 十一個九詳解

SAA-C03 考試考察一個微妙的概念：資料耐久性與資料可用性不同。

• 耐久性（Durability） — 資料不遺失的機率。S3 Standard 提供 99.999999999%（十一個九）的耐久性，統計上意味著在 1,000 萬個物件中每 1,000 萬年才可能遺失一個。
• 可用性（Availability） — 資料可存取的機率。S3 Standard 提供 99.99% 的可用性——四個九。

十一個九的耐久性意味著在 Region 內資料遺失幾乎不可能。但若整個 Region 無法連線（可用性事件），資料也無法存取。Cross-Region Replication（CRR）透過為你提供第二個 Region 的可用性作為備援，超越了耐久性的範疇，進入了災難復原策略的領域。

測試與演練災難復原策略

從未測試過的災難復原策略計畫更像是一種希望，而非計畫。AWS 提供了多種測試機制。

AWS Backup 還原測試

AWS Backup 還原測試（2023 年推出）按排程自動執行還原演練：AWS Backup 將復原點啟動到沙箱環境中，驗證還原成功，然後拆除——無需操作人員介入。這是持續驗證備份與還原型災難復原策略的最低摩擦方式。

DRS 演練模式

AWS Elastic Disaster Recovery 支援「演練」復原：你可以在目標 Region 啟動復原執行個體，而不影響生產複寫。這允許按排程（每月或每季）進行完整的端到端容錯移轉測試，而不觸及即時系統。

Aurora Global Database 切換

Aurora Global Database 支援「託管計畫性容錯移轉」（切換）——以零資料損失優雅地將次要 Region 晉升為主要 Region。定期安排切換演練能建立操作信心。

Route 53 容錯移轉測試

Route 53 支援手動標記健康檢查失敗（透過 CLI 或主控台），讓你在不停掉主要端點的情況下觸發容錯移轉路由。這讓團隊能獨立於資料層容錯移轉之外驗證 DNS 層級的容錯移轉。

演練日（Game Day）

除了自動化測試之外，完整的「演練日」模擬災難：運維團隊端到端執行演練手冊，利害關係人根據目標計時 RTO/RPO 達成情況。頻率建議：每個生產工作負載至少每年一次；第一級工作負載每季一次。

關鍵數字與必記事實

常見考試陷阱 — 災難復原策略邊界測試

陷阱一 — RTO 與 RPO 混淆

學生在考試壓力下容易將兩者對調。記憶錨點：RTO 是服務恢復前的時間（停機持續時間）；RPO 是你可能損失多少近期資料。「復原點（Recovery Point）」= 時間點；「復原時間（Recovery Time）」= 中斷持續時間。

陷阱二 — Pilot Light vs 暖備援

兩者都保持資料複寫。區別在於：Pilot Light 中，應用層是休眠的（規模為 0）；暖備援中，應用層以縮減規模運行。若題幹說「縮減規模的生產版本正在運行」→ 暖備援。若說「伺服器沒有在運行，AMI 已準備好」→ Pilot Light。

陷阱三 — Multi-AZ 當成災難復原

Multi-AZ 是 HA，而非 DR。若業務需求包括在全 Region 中斷中存活，單靠 Multi-AZ 是不夠的。考試很愛這個陷阱，因為 Multi-AZ 便宜且誘人；仔細辨別 Region 級故障情境。

陷阱四 — Aurora Global Database vs Aurora 副本

單一 Region 內的 Aurora 唯讀副本用於 HA 和讀取擴展。Aurora Global Database 透過獨立的儲存層通道跨 Region 複寫。若題幹說「跨 Region」，答案涉及 Global Database，而非 Region 內副本。

陷阱五 — 未啟用版本控制的 S3 CRR

S3 Cross-Region Replication 需要在來源和目標儲存桶上啟用版本控制。考試題目有時會隱藏這個先決條件——若某個干擾選項提到「不啟用版本控制就啟用複寫」，該選項是錯誤的。

陷阱六 — DynamoDB Global Tables 與強一致性

DynamoDB Global Tables 使用最後寫入者勝出的最終一致性多主複寫。對於需要跨 Region 嚴格一致性的工作負載（銀行分類帳），Global Tables 可能不合適——答案可能是主要／次要 Aurora Global Database 模式。

陷阱七 — AWS Backup vs 原生服務快照

原生服務快照（EBS 快照、RDS 快照、DynamoDB 備份）仍然與 AWS Backup 並存。若題幹要求「單一管理平面的集中跨服務備份原則」，答案是 AWS Backup。若詢問特定快照功能（EBS 快速快照還原），答案可能是原生服務。

陷阱八 — Route 53 容錯移轉速度

TTL 控制快取 DNS 的用戶端的容錯移轉速度。在計畫性 DR 演練前縮短 TTL 是常規做法；預期「容錯移轉 10 分鐘後用戶仍在連到舊端點」的題目——答案是 DNS TTL 快取。

災難復原策略 vs 高可用性 — 範疇邊界

HA 和災難復原策略是互補的，不是替代關係。

• 高可用性（任務 2.2 的兄弟主題 high-availability-multi-az）— Multi-AZ 部署、負載平衡器、Auto Scaling、RDS Multi-AZ。防範 Region 內故障。通常對 Region 內事件的 RTO 為數秒至數分鐘，RPO 近零。
• 災難復原策略（本主題）— 跨 Region 模式。防範 Region 級故障。RTO 範圍從數秒（多站點主動－主動）到數小時（備份與還原），取決於策略。

大多數生產工作負載同時需要兩者：Multi-AZ 用於日常韌性，災難復原策略疊加在上面應對 Region 級事件。問「我應該用 HA 還是 DR？」是個假二分法；真正的問題是「在每個故障邊界，我需要什麼 RTO/RPO，以及什麼架構能在可接受的成本下實現它？」

練習題主題 — 任務 2.2 對應的演練

使用題庫演練對應到災難復原策略概念的任務 2.2 題目：

• 「RTO 4 小時，RPO 1 小時，最小化成本」→ 備份與還原，搭配每小時 AWS Backup + S3 CRR。
• 「RTO 數分鐘，RPO 數秒，Aurora 支撐的應用」→ Aurora Global Database + 暖備援。
• 「從任何 Region 低延遲的全球主動－主動遊戲排行榜」→ DynamoDB Global Tables + Route 53 延遲路由。
• 「持續將本地端 VM 複寫到 AWS，RTO 達分鐘級」→ AWS Elastic Disaster Recovery。
• 「合規所需的 15 分鐘複寫 SLA」→ S3 Replication Time Control。
• 「在刪除備份的帳號入侵中存活」→ AWS Backup 搭配 Vault Lock 和跨帳號複製。
• 「主要 ALB 失敗時容錯移轉 DNS」→ Route 53 容錯移轉路由搭配 ALB 健康檢查。
• 「將容錯移轉時間縮短至 DNS TTL 以下」→ 加入 AWS Global Accelerator。

FAQ — 災難復原策略常見問題

Q1. 災難復原策略中 RTO 與 RPO 的差異是什麼？

RTO（Recovery Time Objective，復原時間目標）是從宣告災難到服務恢復之間可接受的最長經過時間——它衡量停機容忍度。RPO（Recovery Point Objective，復原點目標）是可接受的最大近期資料損失量，通常以資料時間窗口衡量——它衡量資料損失容忍度。RTO 為 30 分鐘且 RPO 為 5 分鐘的工作負載，必須在 30 分鐘內恢復，且最多只能損失最後 5 分鐘的已提交資料。災難復原策略的選擇是將 RTO 和 RPO 目標與每種策略的成本進行配對；目標越嚴格，所需策略越昂貴。

Q2. 如何在 AWS 四種災難復原策略中做選擇？

從業務的 RTO/RPO 目標開始。備份與還原適合 RTO 數小時、RPO 數小時的情境——成本最低，速度最慢。Pilot Light 適合 RTO 數十分鐘、RPO 數分鐘——資料層在線，運算層休眠。暖備援適合 RTO 數分鐘、RPO 數秒至數分鐘——縮減規模的完整堆疊持續運行。多站點主動－主動適合 RTO 近零、RPO 近零——多 Region 全容量——但成本最高。永遠選擇能滿足所需 RTO/RPO 的最便宜災難復原策略；在 DR 上過度投入是常見且可預防的浪費。

Q3. S3 Cross-Region Replication 與 Replication Time Control 的差異是什麼？

S3 Cross-Region Replication（CRR）將物件從來源儲存桶非同步複製到另一個 Region 的目標儲存桶。典型複寫延遲為數分鐘，但在預設設定下沒有服務等級協議。S3 Replication Time Control（RTC）是 CRR 的付費附加功能，提供 15 分鐘 SLA：99.99% 的複寫物件在上傳後 15 分鐘內抵達目標。當災難復原策略需要有保證的複寫窗口時——通常出現在金融、醫療和其他受監管情境中——請使用 RTC。當盡力而為的複寫可接受且希望最小化成本時，使用一般 CRR。

Q4. 何時應使用 Aurora Global Database 而非跨 Region 唯讀副本？

Aurora Global Database 使用儲存層複寫，典型延遲低於一秒，並支援 RTO 約一分鐘的託管跨 Region 容錯移轉。它可擴展到五個次要 Region，每個最多 16 個唯讀副本。RDS 跨 Region 唯讀副本（適用於 MySQL、PostgreSQL、MariaDB、Oracle）使用引擎級邏輯複寫，延遲較高，容錯移轉行為較不可預測。對於需要在 Aurora MySQL 或 Aurora PostgreSQL 上進行近零 RPO 且快速跨 Region 容錯移轉的災難復原策略，務必選擇 Aurora Global Database。只有在無法使用 Aurora 時，才使用非 Aurora 跨 Region 唯讀副本。

Q5. DynamoDB Global Tables 適合每個多 Region 工作負載嗎？

不適合。DynamoDB Global Tables 提供亞秒跨 Region 複寫，採用最後寫入者勝出的衝突解決——非常適合應用程式可以容忍最終一致性寫入的多站點主動－主動災難復原策略。對於需要嚴格跨 Region 一致性的工作負載（例如具有嚴格排序的全球金融分類帳），它們並不合適，因為最後寫入者勝出可能丟失合法的並發更新。在選擇 Global Tables 之前，先根據最後寫入者勝出語意評估你的資料模型；盡可能設計寫入為等冪且無衝突的。

Q6. AWS Elastic Disaster Recovery（DRS）能取代 AWS Backup 嗎？

不能——它們服務於不同目的。AWS Backup 是原則驅動的快照服務，跨多個 AWS 服務（EBS、RDS、DynamoDB、EFS、S3 等）產生時間點復原點，具備保留生命週期和透過 Vault Lock 的 WORM 保護。AWS Elastic Disaster Recovery（DRS）對運行中的伺服器——本地端、VM 或 EC2——執行持續的區塊級複寫，以實現快速的伺服器級復原。AWS Backup 是集中備份的答案；DRS 是持續複寫的答案。許多生產災難復原策略同時使用兩者：DRS 用於無法重新架構的伺服器，AWS Backup 用於託管服務資源。

Q7. Route 53 容錯移轉有多快，如何加快它？

Route 53 容錯移轉速度受兩個因素限制：健康檢查偵測時間（通常為 30 秒至 2 分鐘，取決於間隔和閾值設定）以及 DNS TTL（用戶端快取舊記錄的時間）。使用 60 秒 TTL 和快速健康檢查，端對端容錯移轉通常為 1-3 分鐘。要更快，請結合使用 AWS Global Accelerator，它在任播網路層運作，無需依賴 DNS 快取即可在數秒內將 TCP/UDP 流切換到健康端點。當災難復原策略要求長連線或有狀態協定的一分鐘以內容錯移轉時，Global Accelerator 是正確選擇。

Q8. 如何保護災難復原策略免受勒索軟體或帳號入侵的威脅？

三層防護是標準做法。第一，以合規模式啟用 AWS Backup Vault Lock，使復原點在保留期間不可變——即使是 Root 用戶也無法刪除它們。第二，設定跨帳號備份複製到具有嚴格 IAM 邊界的專用「保存庫帳號」，使生產帳號的入侵無法蔓延到備份。第三，在 S3 複本儲存桶和啟用版本控制的來源儲存桶上強制 MFA 刪除。結合這些控制措施，即使生產帳號完全被入侵，在保存庫帳號中仍有已知良好的復原路徑。對於 SAA-C03 中「保護備份免受勒索軟體威脅」的題目，答案幾乎總是 Vault Lock + 跨帳號複製。

延伸閱讀

• AWS Disaster Recovery of Workloads 白皮書 — https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html
• AWS Disaster Recovery Options in the Cloud — https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html
• S3 Replication (CRR and SRR) — https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html
• S3 Replication Time Control — https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication-time-control.html
• AWS Backup Developer Guide — https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html
• Aurora Global Database — https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html
• DynamoDB Global Tables — https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html
• Route 53 DNS Failover — https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html
• AWS Elastic Disaster Recovery User Guide — https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html
• SAA-C03 Exam Guide (PDF) — https://d1.awsstatic.com/training-and-certification/docs-sa-associate/AWS-Certified-Solutions-Architect-Associate_Exam-Guide.pdf