災難復原架構：RTO 與 RPO 驅動的設計

災難復原（DR）是一門在破壞性事件發生後讓工作負載重新運作的學科——無論是 Region 中斷、勒索軟體引爆、錯誤部署、意外刪除的 bucket，或是串聯性相依失效。在 SAP-C02 中，災難復原貫穿 Domain 2（設計新方案）、Domain 3（持續改善）以及 Domain 4（加速工作負載遷移與現代化）。凡是提到「RTO 以分鐘計」、「RPO 以秒計」、受監管產業、合規稽核員，或是「業務持續性」字眼的情境，本質上都是偽裝過的災難復原考題。

本指南假設你已熟悉 Associate 等級的基礎構件——Multi-AZ RDS、S3 版本控制、EBS 快照、Auto Scaling、Route 53 健康檢查——並聚焦在快速排除錯誤答案所需的 Professional 等級 DR 模式：DR 策略階梯（Backup and Restore、Pilot Light、Warm Standby、Multi-Site Active-Active）、AWS Elastic Disaster Recovery (DRS)、Route 53 Application Recovery Controller (ARC)、Aurora Global Database、DynamoDB Global Tables、S3 Cross-Region Replication、跨 Region KMS 金鑰、AWS Backup 跨 Region 複製、多 Region landing zone，以及使用 AWS Fault Injection Service 的混沌工程。讀完之後，那道典型的製藥業情境——RTO 15 分鐘、RPO 5 分鐘、多 Region、合規——應該能看成一套前後一致的完整架構。

為什麼災難復原在 SAP-C02 如此重要

在 Professional 等級，AWS 期望你將 DR 視為第一等級的設計輸入，而非事後補強。情境中帶有明確的 RTO 與 RPO 目標、合規限制（HIPAA、PCI DSS、GxP、FedRAMP）以及成本上限，而正確答案是同時符合三項目標的最便宜架構。過度設計和設計不足一樣錯誤——為 RTO 24 小時的工作負載選擇 Multi-Site Active-Active 是錯的，因為浪費金錢；為 RTO 5 分鐘的工作負載選擇 Backup and Restore 也是錯的，因為無法達成目標。

考試也經常讓 AWS DRS 對抗 CloudEndure 舊模式、Route 53 ARC 對抗普通 Route 53 failover record、Aurora Global Database 管理式容錯移轉對抗手動 promote，以及多 Region active-active 對抗帶容錯移轉的 warm standby。知道哪個構件適合哪個 RTO/RPO 區間，是從四個選項快速縮減到一個的最快方法。

白話文解釋 Disaster Recovery

災難復原充斥著大量術語——RTO、RPO、pilot light、warm standby、active-active。三個類比能讓這些概念變得具體好記。

類比一：捷運應變計畫

把一座城市的大眾運輸應變計畫套用進來。Backup and Restore 像是把維修手冊和備用零件鎖在倉庫裡——平時維護費用幾乎為零，但當某條線路中斷時，工程師得先去倉庫取手冊、清點零件，再從頭組裝，重新通車需要好幾個小時。Pilot Light 像是在備用調度室常駐一名值班員和一套熱機待命的號誌系統——核心基礎設施隨時保持上電，但全班人力和全線列車尚未到位，緊急時再電話召集。Warm Standby 像是在另一端已縮編但完整運作的控制中心——有三分之一的班次正常跑，工作人員在崗，一旦主要機房失效立刻接手並擴班。Multi-Site Active-Active 像是兩座規模相同的控制中心同時調度全市列車——平時各分攤一半流量；其中一座中斷，另一座已熟悉所有路線，不需暖機即可承接全部載客量。每往上爬一階都要多花錢，而你只爬到 RTO/RPO 要求你到達的那一階。

AWS DRS 是自動化的互援協定，持續把主要機房每一台設備的鏡像複寫到備用機房——任何時刻都可以切換，且兩邊的設備清單逐位元組吻合。Route 53 ARC 是獨立電源且異地部署的緊急調度通訊系統——即使主城市的通訊網路全面癱瘓，調度員仍能透過這套分散在五個城市的仲裁系統，把列車導向健康的控制中心。Aurora Global Database 是跨城市即時同步的維修記錄系統——在 A 城市記錄的異常報告，B 城市不到一秒就能查到，接手的工程師永遠掌握完整歷史。

類比二：連鎖餐廳的多廚房備援

連鎖餐廳應對廚房火災的計畫，完美對應 DR 的各個層次。Backup and Restore 是把食譜與大批食材存在倉庫——火災後重新租廚房、招募員工、補貨、重新開業，往往需要好幾天。Pilot Light 是在另一個城市租一間保持冷藏運轉、留有備料的備用廚房，但外場人員尚未進駐；主廚房失火後，召集員工翻牌開門。Warm Standby 是另一個城市同步運作半容量廚房，平時服務幾桌午餐客人以保持設備校準和員工手感，若主廚房停擺，一小時內就能擴充到完整晚餐服務。Multi-Site Active-Active 是兩個城市各開一間規模相同的廚房同時接單，由 Load Balancer（DNS）平分訂單；任一廚房停擺，另一間立刻全數承接，無需任何準備。

S3 Cross-Region Replication 是食材資料庫的同步，任一廚房收到進貨時兩邊都即時更新。DynamoDB Global Tables 是POS 系統——在任一城市下單，另一城市幾秒內就能查到訂單；顧客在 A 城市點的餐可以在 B 城市取餐。KMS 多 Region 金鑰 是主金鑰備份，兩地的保險箱用同一把鑰匙就能開，容錯移轉時不需要重新加密。Game day 是不預告的消防演習——店長突然宣告「假設油炸鍋剛爆炸」，員工按手冊執行復原；沒有演習，手冊只是一份空文。

類比三：醫院緊急應變計畫

醫院的業務持續計畫是受監管工作負載最貼切的現實對應。RTO 是病患在沒有醫療照護的情況下能撐多久——心臟科工作負載只有幾分鐘；病歷存檔工作負載可能是幾天。RPO 是可以承受遺失多少病歷——即時心電圖監測趨近於零；季度帳務一天或許可接受。Backup and Restore 是異地磁帶病歷存檔——完整保存，但調閱緩慢。Pilot Light 是另一個院址保持電子健康記錄系統運作但無臨床人員值班——資料持續更新，危機時呼叫人員到位。Warm Standby 是半容量的衛星醫院，已有診所看診能力，主院失效時可擴展到全面急診運作。Multi-Site Active-Active 是兩座規模相同的醫院同時運作，共用相同電子病歷與人力，以郵遞區號分流病患——任一醫院遭遇區域性災難，另一座立刻承接全部病患量。

RTO、RPO 與 DR 策略階梯

在選擇具體的 AWS 服務之前，必須先內化 RTO 與 RPO 如何對應到四種標準 DR 策略。SAP-C02 情境通常會明確給出 RTO 與 RPO 值，或將其嵌入敘述中（「交易廳不能遺失超過 30 秒的訂單」），而正確策略是理論下限同時滿足兩個數字的最便宜方案。

策略一覽

成本倍數是數量級指標——實際成本取決於工作負載形態（運算密集 vs 儲存密集）和 Region 定價。SAP-C02 的關鍵訊號：每往上爬一階，持續開支至少翻倍，因為你在備援 Region 跑了更多基礎設施。

策略一：Backup and Restore

工作負載在 Region A 運行；備份複製到 Region B。災難發生時，從 CloudFormation/CDK/Terraform 在 Region B 全新佈建基礎設施，並從備份還原資料。

• 資料路徑：AWS Backup → 跨 Region 複製 → Region B 的 Backup Vault。涵蓋 EBS 快照、RDS 快照、DynamoDB 隨需備份、透過 CRR 的 S3 物件、FSx 快照。
• 運算路徑：CloudFormation StackSets 或 Terraform pipeline 按需部署 VPC、子網路、安全群組、ALB、Auto Scaling 群組與應用程式層。
• RTO 決定因素：CloudFormation 加上資料還原所需時間——對於非簡單工作負載通常以小時計，因為單是 RDS 快照還原就需要數十分鐘至數小時，而非常大的 S3 資料集可能需要 AWS DataSync 或 S3 Batch 來重新填充。
• RPO 決定因素：備份頻率。每 1 小時排程一次的 AWS Backup 提供約 1 小時的 RPO；Aurora 和 DynamoDB 的 Continuous Backup 提供時間點還原（幾乎達到事件發生前幾秒），大幅降低 RPO。
• 正確答案時機：RTO 4 小時以上、成本為首要考量、工作負載非關鍵或為批次性質，或用於合規存檔（資料保存比快速復原更重要）。

策略二：Pilot Light

工作負載的最小核心在 Region B 持續運作——通常是資料層和網路/IAM 骨架——而運算資源處於停止或縮放至零的狀態。容錯移轉時，啟動或擴展運算，並將流量重新導向。

• 資料路徑：Aurora Global Database 次要叢集、DynamoDB Global Tables 副本、S3 CRR 目的地 bucket、EFS 複寫、FSx 跨 Region 複寫。Region B 的資料層始終保持最新。
• 運算路徑：Launch Template、desired capacity 為零的 Auto Scaling 群組、已停止的 EC2 執行個體，或未部署的 ECS 服務。基礎設施存在但消耗最小成本。
• RTO 決定因素：擴展運算、暖快取和切換 DNS 所需的時間。從零啟動的 Auto Scaling 群組，5–15 分鐘是合理估計；節點已預熱但部署縮放至零的 EKS 叢集，2–5 分鐘。
• RPO 決定因素：資料複寫延遲。Aurora Global Database 通常低於 1 秒；DynamoDB Global Tables 通常低於 1 秒；無 RTC 的 S3 CRR 需數分鐘；有 RTC 則享有 15 分鐘 99.99% SLA。
• 正確答案時機：RTO 30 分鐘至 2 小時、RPO 秒至數分鐘，且全天運行完整備援容量成本過高。

策略三：Warm Standby

Region B 持續運行縮小但完整功能的工作負載版本，服務一小部分真實流量或僅健康檢查流量。容錯移轉時，擴展至完整容量並承接 100% 流量。

• 資料路徑：與 Pilot Light 相同——Global Database、Global Tables、CRR——差別在於應用程式層已在處理請求。
• 運算路徑：Auto Scaling 群組以最小容量運行（例如 Region B 2 個執行個體 vs Region A 20 個）、ECS 服務以較少 task 數量運行、Lambda 函數透過 provisioned concurrency 保持溫熱，或 ALB 已路由至小型機隊。
• RTO 決定因素：從低容量擴展到完整容量所需時間——Lambda 秒級、EC2 Auto Scaling 搭配 warm pool 1–3 分鐘、容器服務依映像檔拉取快取而定需數分鐘。
• RPO 決定因素：與 Pilot Light 相同——本質上是所選資料服務的複寫延遲。
• 正確答案時機：RTO 2–15 分鐘、RPO 秒至一分鐘、工作負載攸關營收，且常態降載容量的成本可接受。

策略四：Multi-Site Active-Active

兩個（或多個）Region 同時服務流量，各以完整或接近完整容量運行。Region 故障時立即將所有流量切換到存活的 Region，無需任何容量預備動作。

• 資料路徑：強制使用多活躍資料存放——DynamoDB Global Tables（每個 Region 均為活躍寫入者）、Aurora Global Database 搭配寫入轉發（單一活躍寫入者、各地讀取）或多個 Aurora 叢集搭配應用層衝突解決、S3 CRR 雙向複寫（兩個 Region 互為來源和目的地）。衝突解決成為設計問題。
• 運算路徑：兩個 Region 均在 DNS 負載平衡（Route 53 延遲路由或地理鄰近路由）或全球加速器後方執行完整堆疊。
• RTO 決定因素：本質上是 DNS TTL 加上 ARC 切換延遲——多數情況下低於一分鐘，而對於已連到存活 Region 的用戶端則為零。
• RPO 決定因素：Region 之間的複寫延遲——DynamoDB Global Tables 通常遠低於 1 秒；Aurora Global Database 搭配寫入轉發低於 1 秒，但非本地寫入存在跨 Region 寫入延遲。
• 正確答案時機：RTO 低於 1 分鐘、RPO 趨近於零、全球用戶群要求低延遲、法規或客戶承諾要求不可有可觀察的停機時間。

情境對應階梯

AWS Elastic Disaster Recovery (DRS) — 區塊層級複寫與 Failback

AWS Elastic Disaster Recovery (DRS)，CloudEndure Disaster Recovery 的後繼者，是 AWS 的管理式區塊層級 DR 服務。它安裝在來源伺服器上——地端實體機、地端虛擬機（VMware、Hyper-V），或另一 Region 的 EC2 執行個體——並持續將每次磁碟寫入複寫到目標 AWS Region 的暫存區。容錯移轉時，DRS 在幾分鐘內從複寫的區塊啟動高度還原的復原 EC2 執行個體。

DRS 運作機制

1. 在每台來源伺服器上安裝 AWS Replication Agent。它列舉磁碟並掛載輕量 I/O 過濾器。
2. Agent 持續將區塊層級的變更傳送到目標 Region 的暫存子網路，資料落在附加於小型複寫伺服器（DRS 管理的機隊）的低成本暫存 EBS 磁碟區上。
3. 保留時間點快照（預設最多 365 天，可設定），讓你可以從任意時間點啟動復原——對勒索軟體復原至關重要。
4. 容錯移轉時，DRS 使用最新快照（或指定的時間點）在目標 Region 啟動 EC2 執行個體，掛載從暫存資料建立的 EBS 磁碟區，並套用 Launch Template 設定（執行個體類型、子網路、安全群組、IAM 角色）。
5. 主站點復原後，failback 將複寫方向從 AWS 反轉回原始環境。

DRS 支援的來源類型

• 地端實體伺服器（Windows Server、Linux）——DRS 是「不需改造應用程式、以 AWS 作為資料中心 DR 站點」的標準答案。
• 地端虛擬機（VMware vSphere、Microsoft Hyper-V）——從 DRS 角度與實體機相同處理。
• 跨 Region EC2——將 us-east-1 的 EC2 工作負載複寫到 us-west-2 作為 Region 層級 DR，而無需重新平台化為 Aurora Global 或其他管理式多 Region 服務。
• 跨雲——其他雲平台上的伺服器也可複寫到 AWS。

RTO 與 RPO 特性

• RPO：穩定狀態下次秒級，對於佈建良好的暫存區通常低於 1 秒。頻寬受限環境在寫入高峰期間可能出現 RPO 漂移——透過 CloudWatch 監控。
• RTO：從啟動容錯移轉到目標 Region 的 EC2 執行個體開始回應流量，通常 5–20 分鐘，取決於執行個體開機時間、啟動後自動化腳本和預熱時間。

Failback

Failback 是 DR 中常被忽略的另一半。一旦主站點恢復健康，你必須將工作負載遷回並重新建立保護：

1. 在原始環境的伺服器上安裝 Failback Client（或使用 EC2 作為來源的 Failback automation）。
2. 將複寫流向從復原 EC2 執行個體反轉回原始伺服器目標。
3. 執行受控的切換，回到原始站點。
4. 以原始方向（來源 → AWS）重新啟動複寫。

SAP-C02 情境經常詢問完整循環——failover 與 failback——而正確答案需要在兩段都使用 DRS，而非只有出站段。

DRS 與其他 DR 模式的比較

DRS 在你需要對現有應用程式進行一對一復原而無需修改時是正確選擇。它在以下場景最為適合：

• 直接搬移工作負載，無法重構為 Aurora Global 或 DynamoDB Global Tables。
• 舊式應用程式（具有複雜有狀態服務的 Windows Server、原廠需要原始二進位檔的第三方設備），其 EBS 類似磁碟區由廠商支援。
• 從地端資料中心到 AWS 的混合 DR，消除對次要實體站點的需求。
• 使用最多 365 天 PIT 快照的勒索軟體防護——你可以從加密有效載荷引爆之前一週的時間點啟動復原。

DRS 不是正確答案的情況：

• 已在管理式服務上運行的工作負載（Aurora、DynamoDB、Lambda、ECS Fargate）——這些服務有自己更簡單且便宜的跨 Region 功能。
• 你實際上想要重新平台化遷移的情況——那是 AWS Application Migration Service (MGN)，DRS 的同系列產品，使用相同的複寫 agent 但針對遷移進行計費和行銷。

DRS 安全與合規

• 傳輸加密：agent 到暫存區使用 TLS。
• 靜態加密：暫存 EBS 磁碟區以 KMS 加密；復原磁碟區繼承加密設定。
• 網路隔離：暫存子網路隔離；透過端點與 DRS 服務 API 進行出站通訊。
• IAM 整合：所有操作透過 IAM 角色，可在 CloudTrail 中稽核。
• 合規：DRS 包含在其資料平面 AWS Region 相同的合規範圍內（HIPAA、PCI DSS、SOC、FedRAMP，視情況而定）。

對於受監管產業（製藥、金融、醫療），當問題詢問無法重新平台化的廠商提供套件的應用程式無關跨 Region DR 時，DRS 往往是正確答案。

Route 53 Application Recovery Controller (ARC) — 就緒檢查與路由控制

Amazon Route 53 Application Recovery Controller (ARC) 是 Route 53 的 DR 等級流量控制伴侶。普通的 Route 53 健康檢查和 failover record 對大多數工作負載已足夠，但它們有兩個受監管、嚴格 RTO 工作負載無法接受的限制：（1）DNS 健康檢查在部分故障時可能緩慢且不穩定，（2）控制平面運行於單一 Region。ARC 同時解決這兩個問題。

ARC 的三大支柱

• 就緒檢查（Readiness checks）——持續驗證備援 Region 確實能夠承接流量。ARC 逐一檢查資源屬性（Auto Scaling 容量、ALB 目標群組健康狀態、RDS 執行個體狀態、DynamoDB 佈建輸送量、IAM 角色、KMS 金鑰、服務配額），並回報備援站點是否就緒。
• 路由控制（Routing controls）——人工（或自動化）操作的開/關切換，用於在 Region 之間切換流量。每個路由控制連接到一個 Route 53 健康檢查；切換控制會讓健康檢查通過或失敗，進而驅動 DNS failover 或 ALB 監聽器規則。
• 安全規則（Safety rules）——路由控制上的護欄：斷言規則（例如：「至少一個 Region 必須始終為開啟狀態」）和閘道規則（例如：「要關閉 Region A，Region B 必須為開啟且就緒狀態」），防止單一操作員同時關閉兩個 Region。

ARC 叢集——五 Region 資料平面

關鍵的 Professional 等級細節：ARC 的路由控制資料平面在五個 AWS Region（us-east-1、us-west-2、ap-northeast-1、ap-southeast-2、eu-west-1）作為叢集運行。你呼叫任意叢集端點來切換控制，五個 Region 中的仲裁多數必須確認。此架構能在任一單一 Region 失效的情況下存活——包括你正試圖切離的那個 Region。

每個 ARC 叢集收取固定月費（不容小覷——撰寫本文時每月數百美元），另加每個路由控制的費用。SAP-C02 不測試具體金額，但確實測試架構主張：ARC 的可用性高於 Route 53 本身的容錯移轉決策，因為控制平面跨多個 Region。

就緒檢查深度解析

就緒範圍定義於三個層次：

• 復原群組（Recovery group）——代表一個應用程式的頂層 DR 單位。
• Cell——特定 Region 或 AZ 中應用程式的副本。
• 資源集（Resource set）——要監控的實際 AWS 資源（例如 ALB、ASG、RDS 執行個體）。

ARC 持續依就緒規則（預建規則如「ASG desired capacity 等於 maximum」、「ALB 目標群組有健康執行個體」、「RDS 可用」，加上自訂服務配額規則）評估每個資源。就緒檢查彙整為 Cell 的就緒狀態，再彙整為復原群組的就緒狀態。

你使用就緒檢查作為容錯移轉前的信心確認：在 game day 或真實容錯移轉時，操作員在切換路由控制之前，先驗證目標 Cell 狀態為 READY。這避免了經典的「我們執行了容錯移轉，才發現備援的配額設定是 10 而非 200」問題在生產環境發生。

路由控制與安全規則深度解析

路由控制是一個連結到 ARC 叢集的命名布林值（開/關）。將其與路由控制狀態類型的 Route 53 健康檢查關聯。使用 failover 或加權路由的 Route 53 DNS record 會隨健康檢查的切換而反應。

安全規則防止操作員失誤：

• 斷言規則（Assertion rule）：「控制 A、B、C 的開啟狀態總和至少為 1」——確保至少一個 Cell 始終開啟。
• 閘道規則（Gating rule）：「除非控制 Y 開啟，否則控制 X 不能開啟」——強制執行相依順序。
• 等待期（Wait period）：在切換後強制執行冷卻時間。

安全規則由 ARC 叢集評估，並在控制平面層拒絕無效操作——無論如何點擊主控台都無法違反安全規則。

何時使用 ARC vs 普通 Route 53 健康檢查

普通的 Route 53 failover record + 健康檢查對大多數 Web 應用程式已足夠——免費（健康檢查費用除外）、自動，且廣泛部署。ARC 是正確答案的情況：

• 工作負載無法容忍 Route 53 單一 Region 控制平面的限制。
• 容錯移轉必須由操作員或 runbook 手動編排，而非自動——因為自動 DNS failover 在部分故障時可能誤觸發。
• 合規要求可稽核、明確的容錯移轉決策，並有安全規則和雙人簽核。
• 需要就緒檢查在切換前驗證備援的容量和配額。

ARC 的 SAP-C02 關鍵詞：「高度受監管」、「金融服務」、「醫療」、「可稽核的容錯移轉」、「預先驗證的備援」、「不依賴 Route 53 控制平面進行容錯移轉」。

Aurora Global Database — 寫入轉發、管理式容錯移轉與分離待命

Amazon Aurora Global Database 是 AWS 上的 Professional 等級跨 Region 關聯式資料庫。它將一個 Aurora 叢集延伸至最多五個額外 AWS Region，每個 Region 都有自己的 Aurora 叢集，透過儲存層複寫達到次秒級延遲。對於任何提到「跨 Region 關聯式資料庫且 RPO 低於一秒」的情境，這是 SAP-C02 的預設答案。

架構

• 主要 Region 中的一個主叢集接受讀寫。
• 其他 Region 中最多五個次要叢集透過 Aurora 儲存層複寫（非透過 binlog——Aurora 的儲存是一個分散式共用儲存結構，複寫在資料庫引擎下方處理）。
• 每個次要叢集都是擁有自己讀取節點的完整 Aurora 叢集，能夠在其所在 Region 提供低延遲讀取，並在需要時晉升為完整主叢集。

儲存層的複寫延遲通常低於 1 秒，SLA 通常也低於 1 秒，且常常以數十至數百毫秒計。

管理式容錯移轉

管理式容錯移轉（也稱為管理式計畫容錯移轉）是在受控條件下——game day、計畫性維護，或確認的 Region 中斷後——將次要叢集晉升為主叢集的現代方式：

• 你從主控台、CLI 或 API 啟動管理式容錯移轉，指定目標次要 Region。
• Aurora 協調切換：將選定的次要叢集晉升為主叢集、將原來的主叢集降級為次要叢集，並在背景重新調整所有複寫方向。
• 管理式容錯移轉的典型 RTO 低於 1 分鐘；RPO 趨近於零（低於 1 秒），因為晉升時複寫已保持最新。

管理式容錯移轉保留了 Global Database 拓撲——無需手動分離/重新附加——且比舊的「分離並晉升」變通方案更安全，後者會留下需要手動重新合併的獨立叢集。

分離待命（非計畫性容錯移轉）

對於非計畫性容錯移轉——當主要 Region 確實中斷且管理式容錯移轉無法連到它時——你使用分離並晉升路徑：

1. 從 Global Database 中移除主叢集（在次要叢集的主控台中，因為主叢集可能無法連到）。
2. 次要叢集成為可以晉升為主叢集的獨立 Aurora 叢集。
3. 將應用程式寫入重定向到（現在獨立的）叢集。
4. 災難過後，透過建立新的次要叢集或從備份還原來重建 Global Database。

分離待命是即使主要 Region 的 Aurora 控制平面不可用，也能達到次分鐘 RTO 主張的路徑。代價是：災難前的主叢集和現已晉升的叢集是兩個獨立的資料庫；協調任何後期交易是應用程式的責任。

寫入轉發

Aurora Global Database 寫入轉發是一項讓次要叢集接受應用程式寫入語句而無需容錯移轉的功能。寫入透過 AWS 骨幹網路轉發到主要 Region，在那裡執行，結果返回到發出請求的次要叢集。這讓全球用戶的應用程式能使用單一寫入端點（本地次要叢集），而 Aurora 透明地將寫入路由到主叢集。

寫入轉發特性：

• 支援 Aurora MySQL 和 Aurora PostgreSQL（請查閱目前的版本矩陣）。
• 增加跨 Region 寫入延遲（數十至數百毫秒）——次要叢集的讀取仍在本地進行，速度快。
• 提供 session 一致性層級：EVENTUAL、SESSION、GLOBAL——依工作負載在延遲和一致性之間取捨。
• 適合多 Region 主動讀取、單一主要寫入模式，讓應用程式使用簡單用戶端同時跨 Region 分配工作負載。

Aurora Global Database vs Multi-AZ vs 讀取副本

在 SAP-C02 中需要區分：

• Multi-AZ Aurora（預設）：單一叢集，資料透過儲存結構在三個 AZ 複寫。處理 AZ 故障，無法處理 Region 故障。RPO 為零，透過自動容錯移轉 RTO 為 30–60 秒。
• Aurora 跨 Region 讀取副本（舊式）：使用 binlog 在另一個 Region 建立讀取副本的單一 Region 叢集。已被 Global Database 取代用於新設計；仍出現在舊式系統中。
• Aurora Global Database：透過儲存複寫的叢集中的叢集。Region 層級 DR。RPO 低於 1 秒，管理式容錯移轉 RTO 低於 1 分鐘，非計畫性 RTO 低於幾分鐘。

DynamoDB Global Tables — 多 Region、多活躍複寫

Amazon DynamoDB Global Tables 為 DynamoDB 表格提供全受管的多 Region、多活躍複寫。它是 Aurora Global Database 的 NoSQL 對應，但一致性模型根本不同：每個 Region 都是寫入者，衝突以基於條目最新時間戳記的最後寫入者獲勝（last-writer-wins）解決。

架構

• 在 Region A 建立表格，然後在 Region B、C 等新增副本（版本 2019.11.21 是當前的「Global Tables v2」——忽略需要容量匹配的舊 v1）。
• 對任意副本的寫入通常在秒內、常常低於 1 秒，傳播到所有其他副本。
• 讀取始終在本地 Region 進行；寫入在本地執行並在背景複寫。
• 每個副本都有自己的佈建或隨需容量設定。

一致性模型

• 單一 Region 內，DynamoDB 提供強一致性或最終一致性讀取，與通常情況相同。
• 跨 Region，複寫是最終一致性（秒級）——Region A 的寫入不會立即在 Region B 可見。
• 衝突（在複寫視窗內有兩個 Region 對同一個金鑰進行寫入）透過 DynamoDB 指定的 aws:rep:updatetime 時間戳記屬性的最後寫入者獲勝解決——在不使用設計模式的情況下，無法進行應用程式控制的衝突解決（見下方）。

避免意外的設計模式

• Region 黏性 session：透過 Route 53 地理鄰近路由將每個用戶的寫入路由到單一 Region，使衝突少見。跨 Region 容錯移轉將用戶移到新 Region；背景複寫進行協調。
• 冪等寫入：設計條目，使重新套用相同寫入是安全的。
• 僅附加事件流：透過使用不可變的事件金鑰避免從多個 Region 更新同一個金鑰。
• DynamoDB Streams + Lambda 自訂協調：當業務邏輯必須合併衝突的寫入時，讀取 Streams 並將協調後的狀態寫回。

DynamoDB Global Tables 是正確答案的情況

• 工作負載適合 NoSQL：鍵值或文件格式、單一條目查詢、可預測的存取模式。
• 需要多 Region 寫入以提供用戶延遲（全球用戶群）。
• RTO 必須趨近於零且 RPO 在秒級。
• 成本可接受：每個副本本質上是完整副本，因此你在每個 Region 都付出儲存和容量費用。

SAP-C02 關鍵詞：「多 Region 寫入」、「跨大陸用戶的低延遲」、「DynamoDB」、「跨 Region 最終一致性」。

跨 Region 備份

DynamoDB 的時間點還原（PITR）是按表格且按 Region 的。為了合規，也使用 AWS Backup 搭配跨 Region 複製，以在 DR Region 保留可還原的快照，獨立於 Global Tables 複寫之外——這防範了 Global Tables 會欣然複寫的邏輯損壞（錯誤部署寫入垃圾資料）。

S3 Cross-Region Replication (CRR) 與 Same-Region Replication (SRR) 搭配 Replication Time Control

Amazon S3 Replication 以非同步方式在 bucket 之間鏡像物件。它是跨 Region S3 DR 的 SAP-C02 預設答案，但有足夠多的細節——RTC、SRR、複寫篩選器、刪除複寫、加密處理、批次操作——讓考試樂於測試邊界情況。

CRR vs SRR

• Cross-Region Replication (CRR)：來源和目的地 bucket 在不同 Region。用於 DR、全球讀取的延遲最佳化，以及合規強制的 Region 隔離。
• Same-Region Replication (SRR)：來源和目的地 bucket 在同一 Region，通常在不同帳號中。用於將日誌集中到中央帳號、資料主權（在 Region 內但在不同帳號保留副本），以及測試資料填充。

兩者共用相同的底層複寫引擎；Region 配對區分它們。

Replication Time Control (RTC)

S3 Replication Time Control (RTC) 是保證 99.99% 的新物件在 15 分鐘內複寫完成的進階複寫層，大多數物件在秒內複寫。RTC 包含：

• 15 分鐘 SLA 適用於 99.99% 的物件，以 AWS 服務積分為後盾。
• CloudWatch 中的複寫指標（BytesPendingReplication、OperationsPendingReplication、ReplicationLatency）用於即時監控。
• EventBridge 中的複寫事件用於自動化（例如，當物件超過閾值時觸發 Lambda）。

RTC 的成本高於標準複寫（每 GB 資料傳輸加上 RTC 附加費）。當工作負載對 S3 資料有嚴格的 RPO 時選用——例如，實驗室資料必須在 15 分鐘內抵達 DR Region 以滿足 RPO 的製藥工作負載。

值得記住的複寫功能

• 依前綴或物件標籤篩選——僅複寫特定子集。
• 刪除標記複寫——可開啟/關閉；SAP-C02 經常測試預設情況下不複寫刪除標記，這對抗勒索軟體的複寫設計是正確的（來源的刪除不會傳播）。
• 副本修改同步——當副本被獨立修改時，同步變更回去。
• 現有物件複寫——透過 S3 Batch Replication 複寫在設定複寫之前就存在的物件。
• KMS 加密物件——如果來源使用 SSE-KMS，為複寫角色設定來源金鑰的 kms:Decrypt 和目的地金鑰的 kms:Encrypt；使用多 Region KMS 金鑰來簡化。
• 跨帳號複寫——如果你啟用變更物件所有權，目的地 bucket 擁有複寫的物件。
• 雙向複寫——在兩個 bucket 上設定複寫以用於 active-active 模式。

S3 多 Region 存取點

對於 active-active S3 架構，S3 Multi-Region Access Points (MRAP) 提供單一全球端點，使用 AWS Global Accelerator 路由到最近的健康 bucket。結合雙向 CRR，MRAP 讓應用程式無論在哪個 Region 都使用同一個 URL，而 S3 處理流量引導和容錯移轉。

跨 Region KMS 金鑰管理

加密金鑰跨 Region 的方式與資料不同。正確處理這一點是 SAP-C02 的常見考題，因為它很微妙。

單一 Region KMS 金鑰（預設）

常規的 AWS KMS 金鑰是Region 範圍的。用 us-east-1 中的金鑰加密的密文，只能由 us-east-1 中的同一個金鑰解密。對於跨 Region DR，你需要在目的地端解密後再重新加密，或繞過它進行設計。

多 Region KMS 金鑰

多 Region KMS 金鑰（2021 年引入）在各 Region 之間共用金鑰材料和金鑰 ID。你在一個 Region 建立主要多 Region 金鑰，並在其他 Region 建立副本；任何副本加密的密文都可以被任何其他副本解密，因為它們共用金鑰材料。

金鑰屬性：

• 所有副本具有相同的金鑰 ID（ARN 中帶有 Region 前綴）。
• 金鑰材料在建立時在 Region 之間安全複製；你也可以在多 Region 模式下使用匯入的金鑰材料。
• 輪換一致性地套用於所有副本。
• 金鑰政策是按 Region 的——你可以在不同 Region 允許不同的 principal。
• 只有對稱和非對稱金鑰支援多 Region；HMAC 金鑰在許多實作中是單一 Region（查閱文件取得目前支援資訊）。

多 Region 金鑰是正確選擇的情況：

• Region A 中加密的應用程式資料必須在 Region B 以低成本和低延遲解密。
• SSE-KMS 加密物件的跨 Region S3 複寫，目的地副本重新加密密文時無需跨 Region 傳輸明文。
• 帶有加密的 DynamoDB Global Tables，其中每個副本都能在本地解密。

何時保留單一 Region 金鑰

• 合規或資料主權要求每個 Region 的密碼學隔離。
• 工作負載是單一 Region，僅有跨 Region 備份——AWS Backup 使用目的地 Backup Vault 的金鑰自動處理重新加密。
• 金鑰材料絕不能離開特定 Region（某些受監管產業）。

AWS Backup — 跨 Region 與跨帳號備份複製

AWS Backup 是支援大多數 AWS 資料服務（EBS、RDS、DynamoDB、EFS、FSx、Storage Gateway、S3、Neptune、DocumentDB、Redshift 等）的集中式備份服務。對於 DR，三項 Backup 功能至關重要。

跨 Region 備份複製

備份計畫包含一個複製動作，將每個復原點傳送到另一個 Region 的 Backup Vault。複製在目的地以 KMS 加密（使用目的地 vault 的金鑰或多 Region 金鑰），並獨立計算到兩個 vault 的生命週期政策中。

跨帳號備份複製

將復原點傳送到另一個 AWS 帳號中的專用 Backup 帳號。隔離帳號可以透過 SCP 鎖定，拒絕所有人（包括 root）執行 backup:Delete* 和 s3:Delete*，提供真正防篡改的復原點集。這是抵抗勒索軟體備份的黃金標準。

Vault Lock — WORM 合規

AWS Backup Vault Lock 對 vault 套用 **WORM（Write-Once-Read-Many）**不可變性：

• 治理模式（Governance mode）：具有特定 IAM 權限的管理員可以覆寫鎖定。
• 合規模式（Compliance mode）：任何人，包括 root，都無法在保留期到期之前刪除復原點或縮短保留期。一旦鎖定，合規模式無法降級。

Vault Lock 是 SAP-C02 情境提到「七年保留」、「SEC 17a-4」、「勒索軟體」或「有法規要求的不可變備份」時的正確答案。

組織備份政策

AWS Organizations 備份政策將備份計畫傳播到 OU 中的每個帳號，確保統一的備份態勢。結合 AWS Backup 的委派管理員，你可以在無需每個帳號個別設定的情況下實現一個組織一套備份態勢的治理。

多 Region Landing Zone

多 Region landing zone 是所有按工作負載 DR 模式所依附的架構骨架。SAP-C02 有時會詢問治理規模的多 Region 選擇，而非只是某個應用程式的 DR。

組成要素

• AWS Organizations，透過 SCP 套用多 Region 治理。
• AWS Control Tower，受治理 Region 延伸至包含 DR Region。Control Tower 的主 Region 在建立時固定；次要 Region 作為受治理 Region 新增，並接受基準 guardrail。
• 組織 CloudTrail trail，傳遞到 Log Archive bucket，並以 S3 CRR 複寫到第二個 Region 的副本。
• AWS Config 彙整器，在 Audit 帳號中彙整每個 Region 的資源狀態。
• IAM Identity Center，帶有主 Region；執行個體本身透過單獨的策略進行容錯移轉（IAM Identity Center 有自己的 DR 策略——查閱目前文件取得詳細資訊）。
• 每個 Region 中的 Transit Gateway，跨 Region 互連，承載 VPC 間和混合連接。
• 關聯到多個 Region VPC 的 Route 53 私有託管區域，用於內部 DNS 解析。
• 用於必須容錯移轉的工作負載資料的 KMS 多 Region 金鑰。
• 每個 Region 中的 AWS Backup vault，帶有跨 Region 複製計畫和跨帳號隔離。
• 帶有服務管理權限的 CloudFormation StackSets，將基準資源部署到每個 OU 和每個 Region。

Region 配對策略

選擇主要和 DR Region 時需注意：

• 延遲：較近的配對減少複寫延遲（影響 Aurora Global Database、DynamoDB Global Tables、DRS RPO）。
• 合規：資料主權可能限制 Region 選擇（例如，歐盟工作負載只容錯移轉到歐盟 Region）。
• 服務可用性：DR Region 必須支援工作負載使用的每項服務——某些服務在非美國 Region 的推出可能晚了好幾年。
• 爆炸半徑獨立性：避免在同一個都會區配對；選擇在不同電力網路和對等互連結構上的 Region。
• 成本：Region 之間的資料傳輸按費計算；某些配對比其他配對便宜。

標準配對

常見的企業配對：

• 北美：us-east-1 ↔ us-west-2（不同海岸，不同電力區域）。
• 歐洲：eu-west-1 ↔ eu-central-1（愛爾蘭 ↔ 法蘭克福）。
• 亞太：ap-northeast-1 ↔ ap-southeast-1（東京 ↔ 新加坡）。

SAP-C02 情境很少要求你選擇特定的 Region，但確實會詢問哪些 Region 支援所需的服務——在押注某個 Region 之前，先確認服務可用性。

混沌工程與 Game Day

從未測試過的 DR 架構只是一份文件。SAP-C02 期望你了解讓 DR 成真的運營實踐。

AWS Fault Injection Service (FIS)

AWS Fault Injection Service (FIS)——前稱 AWS Fault Injection Simulator——是管理式混沌工程服務。它執行注入受控故障的實驗範本：

• EC2 動作：停止執行個體、重啟執行個體、終止特定 AZ 中的執行個體。
• ECS 動作：停止 task、將服務縮放至零、限制容器流量。
• EKS 動作：驅逐節點、中斷 pod。
• RDS 動作：容錯移轉 DB 叢集、重啟執行個體。
• 網路動作（透過 Systems Manager）：引入延遲、封包遺失、DNS 中斷。
• IAM 動作：模擬權限移除。
• 停止條件（Stop conditions）：安全網 CloudWatch 警報，當爆炸半徑超過閾值時中止實驗。

FIS 是執行預生產 game day 的 AWS 原生方式：排程一個實驗，殺掉 us-east-1 中一半的 EC2 機隊，驗證 Auto Scaling 是否恢復，驗證 Route 53 ARC 就緒檢查是否正確切換，驗證警報是否通知值班人員。

Game Day — 正確執行方式

Game day 是一次有組織的災難情境演習。最佳實踐：

1. 提前定義情境和成功標準（「Region us-east-1 變得無法連到；工作負載必須在 15 分鐘內從 us-west-2 提供服務，RPO 低於 5 分鐘」）。
2. 預先告知值班團隊——有些 game day 是公告的，有些是未公告的，取決於信心水準。
3. 執行故障（透過 FIS 或手動操作）。
4. 對照 RTO/RPO 目標觀察復原情況。
5. 記錄發現：哪些壞了、哪些花了比預期更長的時間、哪些沒被監控到、哪些沒有觸發警報。
6. 修復並重新執行——沒有後續行動的 game day 只是演練，不是學習。

成熟的組織對關鍵工作負載每季執行 game day，並將其納入發布閘門。

典型情境——製藥應用程式：RTO 15 分鐘、RPO 5 分鐘、多 Region、合規

SAP-C02 情境通常濃縮成一個密集的段落。以下是典型的製藥業情境及完整的 Professional 等級深度解答。

情境

一家製藥公司運營一個必須符合 GxP、HIPAA 和 21 CFR Part 11 的臨床試驗管理平台。應用程式包含：Web 層（ALB + Auto Scaling Java 應用程式）、保存病患資料的 Aurora PostgreSQL 資料庫、保存研究協定元資料的 DynamoDB 表格、保存實驗室結果檔案（最多 5 TB 且持續增長）的 S3 bucket、協調工作流程的 Lambda 函數集，以及在 us-east-1 的 EC2 上運行的第三方分析 VM 設備（廠商提供，不可重新設計）。業務要求：RTO 15 分鐘、RPO 5 分鐘、兩個 AWS Region、可稽核的容錯移轉決策、7 年保留且具不可變性的備份、使用客戶管理金鑰的加密，以及從加密生產資料的勒索軟體事件中復原的能力。

解決方案架構

基礎

• AWS Control Tower landing zone，以 us-east-1 為主 Region，us-west-2 新增為受治理 Region。
• 專用帳號：工作負載/生產（主要應用程式）、安全/稽核（GuardDuty/Security Hub/Macie 的委派管理員）、Log Archive、備份（防篡改備份的隔離帳號）、網路（Transit Gateway 中樞輻射）。
• Root SCP 拒絕在緊急存取之外執行 cloudtrail:StopLogging、config:DeleteConfigurationRecorder、kms:ScheduleKeyDeletion、backup:DeleteRecoveryPoint。
• KMS 多 Region 客戶管理金鑰，主要金鑰在 us-east-1，副本在 us-west-2。

資料層

• Aurora PostgreSQL Global Database，主叢集在 us-east-1，次要叢集在 us-west-2。複寫延遲低於 1 秒（以充裕的裕度滿足 5 分鐘 RPO）。管理式容錯移轉是計畫性路徑；分離晉升是非計畫性路徑。
• DynamoDB Global Tables 跨 us-east-1 和 us-west-2，研究協定元資料表格以多活躍方式複寫。兩個 Region 均啟用 PITR。
• S3 bucket 在 us-east-1，帶有 Cross-Region Replication + RTC 到 us-west-2 的 bucket——15 分鐘 SLA 滿足 RPO。S3 Versioning + 合規模式的 Object Lock，保留期 7 年。刪除標記複寫關閉，使來源的刪除不會傳播。

運算層

• Web 層：us-west-2 中的 Warm Standby。ALB + Auto Scaling Group 以最小 2 個執行個體運行（從主要的 20 個縮小）。Launch Template 引用多 Region AMI。
• Lambda：相同函數透過 CloudFormation StackSets 部署在兩個 Region。在主要 Region 活躍，在 DR Region 閒置。
• 廠商 VM 設備：透過 AWS DRS 保護。複寫 agent 安裝在 us-east-1 的 EC2 執行個體上；暫存在 us-west-2。容錯移轉時，DRS 以最新區塊層級狀態啟動復原 EC2——對無法重構的廠商提供設備滿足 15 分鐘 RTO 和次分鐘 RPO。

流量控制

• Route 53 Application Recovery Controller (ARC) 叢集。region-us-east-1-active 和 region-us-west-2-active 的路由控制。安全規則：至少一個 Region 必須始終為開啟狀態；關閉 us-east-1 需要 us-west-2 的就緒狀態為 READY。
• Route 53 failover record 引用連結到路由控制的計算式健康檢查。
• ARC 就緒檢查在批准切換之前驗證 us-west-2 是否有足夠的 ASG 容量、足夠的 RDS 執行個體大小、所需的 IAM 角色和 KMS 金鑰政策。

備份與勒索軟體韌性

• AWS Backup 計畫每 15 分鐘對 Aurora 和 DynamoDB 執行一次（啟用 Continuous Backup，PITR 在秒內）、每小時對 EFS 執行一次、每天對 EBS 執行一次。
• 跨 Region 複製到 us-west-2 Backup Vault。
• 跨帳號複製到隔離的 Backup 帳號。
• 合規模式的 Vault Lock，保留期 7 年——滿足 GxP 和相當於 SEC 的要求。
• AWS DRS 對廠商 VM 保留 30 天 PIT，提供勒索軟體回滾能力。

運營

• AWS Fault Injection Service game day 每季執行：終止主要 Aurora 寫入節點，然後透過強制 ARC 切換終止 us-east-1 Region，驗證 15 分鐘內復原。
• 每個 Region 的 CloudWatch 儀表板監控複寫延遲、ASG desired/actual 和 RTC 待處理物件。
• EventBridge 規則在 ARC 路由控制狀態變更時，透過 SNS + Slack 通知合規團隊。
• Systems Manager Documents 中的 Runbook 帶有手動容錯移轉決策的核准步驟；稽核員在 CloudTrail 中看到核准記錄。

為什麼這個架構是正確的

• RTO 15 分鐘：Warm Standby 運算在分鐘內擴展；ARC 在秒內切換；Aurora 管理式容錯移轉低於 1 分鐘；DRS 對廠商 VM 的復原 5–20 分鐘。
• RPO 5 分鐘：Aurora Global DB 次秒級延遲、DynamoDB Global Tables 次秒級、S3 RTC 15 分鐘 SLA（緊張——如果情境強調 S3 RPO 低於 1 分鐘，你需要新增自訂快速複寫路徑）。
• 多 Region 合規：帶有 CRR 的專用 Log Archive、KMS 多 Region 金鑰、Control Tower 受治理 Region、組織 CloudTrail、Config 彙整器。
• 可稽核的容錯移轉：ARC 安全規則、SSM Document 核准、CloudTrail 記錄每次路由控制切換。
• 勒索軟體：合規模式的 Object Lock、合規模式的 Vault Lock、跨帳號 Backup 隔離、DRS PIT 最多 365 天、刪除標記複寫關閉。
• 成本合理：Warm Standby，而非 Multi-Site Active-Active——因為 RTO 15 分鐘允許擴展時間，而 active-active 在不改善目標的情況下會使運算開支翻倍。

此情境的常見錯誤答案模式

• Multi-Site Active-Active——對 15 分鐘 RTO 來說過度設計；在沒有好處的情況下使成本翻倍。
• Backup and Restore——無法以完整堆疊重新部署達到 15 分鐘 RTO。
• 普通 Route 53 failover record——缺乏 ARC 提供的可稽核、明確、基於仲裁的控制。
• Aurora 跨 Region 讀取副本（舊式）——延遲比 Global Database 高；已棄用的模式。
• DRS 用於所有服務——對具有原生多 Region 功能的管理式服務（Aurora、DynamoDB、S3、Lambda）來說過度設計。
• 單一 Region KMS 金鑰——在容錯移轉期間需要解密後重新加密，增加複雜度。

常見陷阱——災難復原進階模式

每次 SAP-C02 嘗試中，預計至少會看到其中兩個干擾選項。

陷阱 1：預設選擇最高階

RTO 4 小時的情境不需要 Multi-Site Active-Active。正確答案是最便宜的、滿足 RTO/RPO 的策略——通常是 Pilot Light 或 Warm Standby。在選擇策略之前，始終先閱讀 RTO/RPO 數字。

陷阱 2：混淆 RTO 和 RPO

RTO 是「我們停機多長時間」；RPO 是「我們遺失多少資料」。工作負載可以有嚴格的 RTO（10 分鐘）和寬鬆的 RPO（1 小時），反之亦然。兩者各驅動架構的不同部分——RTO 驅動運算就緒性，RPO 驅動複寫頻率。

陷阱 3：在嚴格 RTO 情境中依賴 Route 53 控制平面

普通的 Route 53 健康檢查和 failover record 從單一控制平面 Region 運行。對於無法容忍控制平面 Region 失效的合規等級嚴格 RTO 工作負載，答案是Route 53 ARC 及其五 Region 叢集。

陷阱 4：將 S3 Replication 視為勒索軟體防護

CRR 向前複寫，如果設定了刪除標記也會複寫刪除標記。對抗勒索軟體你需要合規模式的 Object Lock、版本控制上的 MFA Delete，以及跨帳號 Backup 隔離。單靠 CRR 是不夠的。

陷阱 5：使用 Aurora 跨 Region 讀取副本而非 Global Database

舊式 Aurora 跨 Region 讀取副本（binlog 為基礎）的延遲比 Aurora Global Database（儲存層）更高。對於新的 SAP-C02 設計，Global Database 是答案，除非情境明確將你限定在舊式模式。

陷阱 6：忘記 Global Tables 以最後寫入者獲勝解決衝突

任何提到「兩個 Region 可能更新同一個條目」的多 Region DynamoDB Global Table 情境，都必須承認 LWW。如果需要強的跨 Region 一致性，DynamoDB Global Tables 是錯誤答案——考慮改用帶有寫入轉發的 Aurora Global Database。

陷阱 7：在跨 Region DR 架構中使用單一 Region KMS 金鑰

如果資料在 Region A 以 SSE-KMS 加密並複寫到 Region B，除非金鑰政策允許且金鑰存在於那裡，否則 Region B 無法解密。多 Region KMS 金鑰同時解決這兩個問題。單一 Region 金鑰強制執行解密/重新加密管道，增加延遲和成本。

陷阱 8：認為 DRS 取代了管理式多 Region 功能

DRS 適用於無法重構的直接搬移工作負載。如果工作負載在 Aurora、DynamoDB、S3、Lambda 或具有原生多 Region 支援的管理式服務上運行，請使用這些服務——而非 DRS。對 Aurora 叢集使用 DRS 會複寫運算，但無法正確複寫資料庫層。

陷阱 9：忘記 Failback

容錯移轉只是一半。在 SAP-C02 中，DR 問題有時會詢問完整循環，而正確答案需要指名 DRS failback、Aurora Global Database 反向複寫，或用於回程段的明確備份還原。

陷阱 10：假設自動容錯移轉總是更好

自動容錯移轉（Route 53 健康檢查切換 DNS）在部分故障時可能誤觸發——響應緩慢但仍回應 TCP 健康檢查的後端，讓主站點保持「健康」，而用戶卻飽受痛苦。嚴格 RTO 工作負載偏好透過 ARC 由操作員發起的容錯移轉，就緒檢查提供預先驗證。情境中的「可稽核的明確決策」指向 ARC，而非自動 DNS failover。

陷阱 11：跳過 Game Day

未經測試的 DR 只是文件。提到「公司從未測試過 DR 計畫」的情境永遠是錯的——修正方法是使用 AWS FIS 或手動 runbook 演習排程進行 game day。

決策矩陣——哪個 DR 構件適合哪個目標

FAQ——災難復原進階模式

Q1：對於 RTO 30 分鐘、RPO 1 分鐘的情境，我如何在 Pilot Light 和 Warm Standby 之間選擇？

兩種策略在技術上都能滿足 RPO（無論選哪個，DR Region 的複寫通常都是次秒級），因此區別在於 RTO。Pilot Light 需要 10–20 分鐘，從零將運算擴展到服務流量——包含 Auto Scaling 的映像檔拉取、快取暖機和資料庫連線池暖機。Warm Standby 保持小型機隊已在運行，因此擴展只需 2–5 分鐘。30 分鐘 RTO 有餘裕，所以 Pilot Light 是可接受且更便宜的。如果情境加上變化——「應用程式需要 3 分鐘的快取暖機」或「三分之一的流量必須在 5 分鐘內落下」——Warm Standby 變得正確，因為 Pilot Light 的從零擴展路徑消耗了太多預算。

Q2：什麼時候我需要 Route 53 ARC 而非普通的 Route 53 failover record？

普通的 Route 53 failover record + 健康檢查是自動的、便宜的，對大多數工作負載已足夠。ARC 在以下情況是必需的：（1）容錯移轉必須在主要 Region 控制平面失效的情況下存活——ARC 的資料平面跨五個 Region 以仲裁運行，因此即使主要完全中斷，切換仍然有效；（2）合規要求明確、可稽核、雙人控制的容錯移轉決策，而非自動 DNS 切換；（3）需要就緒檢查在批准切換之前預先驗證備援的容量和配額；（4）安全規則必須防止操作員錯誤，如同時關閉兩個 Region。ARC 叢集的月費不低，因此普通 Web 應用程式留在 Route 53 failover。銀行、醫療和其他受監管工作負載升級到 ARC。

Q3：Aurora Global Database 管理式容錯移轉與分離晉升有什麼區別？

管理式容錯移轉是受控的、協調的次要叢集晉升為主叢集，由 Aurora 的控制平面編排。它保留 Global Database 拓撲，將原來的主叢集降級為次要叢集並重新調整複寫方向。典型 RTO 低於 1 分鐘，RPO 趨近於零。用於計畫性事件和主叢集控制平面仍可連到的確認 Region 故障。分離晉升是緊急路徑：從次要叢集的主控台，將無法連到的主叢集從 Global Database 中分離，使次要叢集成為可以接受寫入的獨立叢集。災難過後，你必須重建 Global Database（建立新的次要叢集，或從備份還原）。在管理式容錯移轉無法連到主叢集時使用分離晉升——這才是真正的 Region 中斷情境。

Q4：我可以對 Aurora 資料庫使用 DRS 嗎？

不可以——DRS 複寫 EC2 和地端伺服器的區塊層級 EBS 等效資料。Aurora 在沒有客戶可存取的 EBS 磁碟區的管理式分散式儲存結構上運行。對於 Aurora 跨 Region DR，使用 Aurora Global Database。DRS 適用於直接搬移工作負載：執行自管理資料庫的 EC2 執行個體、廠商 VM 設備、舊式 Windows Server 工作負載，或複寫到 AWS 的地端伺服器。SAP-C02 中常見的錯誤答案是「使用 DRS 複寫 Aurora 叢集」——它做不到，Global Database 才是正確的構件。

Q5：如何在 DR 架構中防護勒索軟體？

勒索軟體防護是分層的，因為向前複寫會欣然傳播惡意刪除和加密。各層次：（1）關鍵 bucket 上的 S3 Versioning 搭配 MFA Delete——攻擊者在沒有 MFA 的情況下無法永久刪除版本；（2）帶有適當保留期的合規模式 S3 Object Lock——在保留期到期之前，物件無法被覆寫或刪除；（3）CRR 搭配刪除標記複寫關閉——來源的刪除不會傳播到目的地；（4）帶有合規模式 Vault Lock 的 AWS Backup——備份本身無法被刪除；（5）跨帳號 Backup 複製到由 SCP 鎖定的隔離帳號——即使生產帳號的 root 也無法存取這些備份；（6）帶有長 PIT 保留（最多 365 天）的 AWS DRS——恢復到攻擊者獲得存取之前的時間點；（7）GuardDuty + Security Hub 偵測表示入侵的異常 API 呼叫。對受監管工作負載同時實施所有這些措施。

Q6：為什麼我會使用 DynamoDB Global Tables 而非在一個 Region 執行 DynamoDB 搭配跨 Region 備份？

選擇取決於你的 RTO 和延遲目標。單一 Region DynamoDB 搭配跨 Region 備份提供以小時計的 RPO（備份頻率）和以分鐘計的 RTO（從備份還原或透過應用程式邏輯重定向）——適合批次或內部工作負載。DynamoDB Global Tables 提供秒級 RPO（複寫延遲）、趨近於零的 RTO（DR Region 已在服務中），以及全球用戶的低延遲讀取。代價是成本（兩個或更多的完整副本）和最後寫入者獲勝一致性模型——如果你的應用程式無法容忍跨 Region 的 LWW 語義，Global Tables 不是直接替換。SAP-C02 中提到「全球用戶群」或「多 Region 活躍寫入」的情境指向 Global Tables；只需要 Region 層級 DR 而不需要 active-active 的情境可以使用單一 Region + 備份。

Q7：如何在不影響生產的情況下測試 DR 計畫？

在鏡像生產拓撲的預生產環境中使用 AWS Fault Injection Service (FIS)。定義終止 EC2 執行個體、停止 ECS 服務、強制 RDS 容錯移轉或模擬網路分區的實驗——帶有連結到 CloudWatch 警報的停止條件，以限制爆炸半徑。對於完整的 DR 演習，在預備環境中排程 game day，實際切換 Route 53 ARC 路由控制、驗證 DR Region 端對端服務流量、驗證就緒檢查，並對照目標衡量實際 RTO/RPO。成熟的組織也在非關鍵時間窗口（例如週六凌晨 2 點）進行生產 game day，帶有明確的預先告知、向前推進標準和回滾計畫——目標是運營信心，而生產是唯一能證明 runbook 有效的環境。記錄每個發現並建立後續行動；沒有後續行動的 game day 只是演練。

Q8：Route 53 ARC 的五 Region 叢集如何在我試圖切離的 Region 失效的情況下存活？

ARC 叢集在五個 Region 的每個 Region 各有一個資料平面副本（us-east-1、us-west-2、ap-northeast-1、ap-southeast-2、eu-west-1）。當你切換路由控制時，用戶端 SDK 呼叫任何五個叢集端點中可連到的一個，當**仲裁（五個中的三個）**Region 確認後，呼叫就被提交。如果你正在從 us-east-1 切離，而 us-east-1 本身已中斷，SDK 只需呼叫其他四個端點中的一個，仲裁從剩餘的四個 Region 形成。這與 Route 53 主控制平面在單一 Region 運行的方式根本不同——當那個 Region 失效時，你無法編輯 record。ARC 就是為解決合規等級工作負載的控制平面相依性問題而建立的。在 SAP-C02 中，如果問題提到「主要 Region 的控制平面不可用，我們仍需要容錯移轉」，ARC 是正確答案。

Q9：對於帶有 Aurora Global Database、S3 CRR、DynamoDB Global Tables 和 AWS Backup 跨 Region 複製的工作負載，正確的加密策略是什麼？

使用 KMS 多 Region 客戶管理金鑰作為所有四項服務的預設加密金鑰。主要金鑰在主要 Region；副本在 DR Region。由於所有副本共用金鑰材料，DR Region 中的加密資料可以被 DR Region 副本解密，無需跨 Region 傳輸明文。每個服務使用獨立的金鑰（Aurora 一個、DynamoDB 一個、S3 一個、Backup 一個），讓金鑰政策變更的爆炸半徑最小，並符合最小權限原則。授予 Aurora 次要叢集的服務角色存取副本金鑰；授予 S3 複寫角色來源多 Region 金鑰的 kms:Decrypt 和目的地多 Region 金鑰的 kms:Encrypt；授予 AWS Backup vault 存取副本金鑰。按合規對齊的排程輪換金鑰；輪換一致性地套用於副本。對於嚴格資料主權要求禁止金鑰材料跨越邊境的工作負載，退回到單一 Region 金鑰搭配複寫邊界的重新加密（由 AWS Backup 跨 Region 複製原生處理），承受延遲成本。

Q10：考慮到兩者在有足夠自動化的情況下都能達到次分鐘 RTO，我何時應該選擇 Multi-Site Active-Active 而非 Warm Standby？

Multi-Site Active-Active 在以下條件之一成立時是合理的：（1）全球用戶群需要從最近 Region 持續獲得低延遲服務——active-active 提供本地性，而 warm standby 從用戶角度讓 DR Region 保持閒置；（2）RTO 對已連到存活 Region 的用戶必須為零——warm standby 至少需要那些遷移用戶的擴展時間，而 active-active 在兩個 Region 已有完整容量；（3）法規或合約承諾要求無可觀察的停機時間；（4）負載超過單一 Region 能夠處理的——active-active 作為容量策略和 DR 策略同樣重要。否則 Warm Standby 是更好的選擇：它以 40–60% 的持續成本達到次分鐘 RTO，避免了多寫入者一致性的複雜性，且在事件響應中更容易推理。Multi-Site Active-Active 的 SAP-C02 信號是明確的全球延遲要求或「零停機時間」用語；Warm Standby 的信號是「嚴格 RTO 但可接受短暫的擴展延遲」。

延伸閱讀

• Disaster Recovery of Workloads on AWS: Recovery in the Cloud (Whitepaper)
• AWS Well-Architected Framework — Reliability Pillar
• AWS Elastic Disaster Recovery (DRS) User Guide
• AWS DRS — Failback
• Route 53 Application Recovery Controller (ARC)
• Route 53 ARC — Routing Controls
• Route 53 ARC — Readiness Checks
• Amazon Aurora Global Database
• Aurora Global Database — Write Forwarding
• Aurora Global Database — Managed Failover and Recovery
• Amazon DynamoDB Global Tables
• Amazon S3 Replication (CRR and SRR)
• S3 Replication Time Control (RTC)
• AWS KMS Multi-Region Keys
• AWS Backup — Cross-Region Copy
• AWS Fault Injection Service (FIS)
• AWS SAP-C02 Exam Guide (PDF)