Amazon DOP-C02: 高可用性、韌性與災難復原 — 學習指南

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

屬於 AWS DevOps Engineer Professional DOP-C02 — 學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.

總覽

AWS 上的高可用性與災難復原著重於在元件、可用區域 (AZ) 或區域性故障下，減少停機時間 (RTO) 與資料遺失 (RPO)。Multi-AZ 設計可以吸收 AZ 故障，且不會造成資料遺失，服務影響也極小；multi-Region 設計則應對區域性中斷和大規模事件。在 active/active、active/passive (warm standby) 和 pilot-light 策略之間做選擇，取決於業務的 RTO/RPO 目標、一致性要求和成本。要達成這些目標，需要在 DNS 路由、運算彈性、負載平衡、資料庫複寫/容錯移轉、具備複寫/版本控制的耐久物件儲存、集中式備份，以及透過故障注入進行的持續性韌性驗證等方面，進行連貫的設計。

針對 RTO/RPO 與智慧路由的架構

Multi-AZ 與 multi-Region：

• Multi-AZ：在負載平衡器後方，將備援執行個體部署在不同 AZ 的至少兩個子網路中。使用具備同步複寫的託管資料庫 (RDS Multi-AZ, Aurora Multi-AZ/cluster)。對於同步儲存，RPO 通常為零；RTO 目標範圍從次分鐘級 (Aurora) 到幾分鐘 (RDS Single-Instance Multi-AZ 容錯移轉)。
• Multi-Region：選擇 active/active 以獲得最低的 RTO、區域隔離和低延遲，或選擇 warm standby/pilot light 以實現成本最佳化的災難復原。資料複寫必須滿足 RPO：非同步資料庫複本、Aurora Global Database (典型 RPO < 1 秒)、DynamoDB global tables (multi-Region, multi-active)，以及 S3 跨區域複寫 (CRR) 搭配可選的複寫時間控制 (RTC) 以提供有 SLA 保證的複寫。

Route 53 路由政策與健康狀態檢查：

• Failover 路由：為同一個名稱建立兩筆記錄：Primary 和 Secondary。將健康狀態檢查與 Primary 記錄關聯 (或對於指向 ALB/NLB 的別名記錄使用「Evaluate Target Health」)。發生故障時，流量會轉移到 Secondary。保持較低的 TTL (例如 60 秒) 以減少 DNS 快取延遲，並使用 CloudWatch Alarms 監控健康狀態檢查的狀態。
• Latency-based 路由：將使用者路由到測量延遲最低的區域。將健康狀態檢查與每筆記錄關聯，以確保只有健康的端點接收流量。與 multi-Region 堆疊和支援最終/強式一致性 (視需求) 的區域性資料存放區搭配使用。
• Weighted 路由：按百分比分配流量，以支援 Canary 版本、A/B 測試或「涓流式」災難復原準備 (例如，持續將 1% 流量導向次要區域)。與健康狀態檢查結合，以便排除不健康的權重。在區域性撤離期間，使用逐漸轉移權重的方式來遷移流量。
• 健康狀態檢查：探測 HTTP(S)/TCP 端點或 CloudWatch Alarms。對於 ALB/NLB 的別名記錄，啟用「Evaluate Target Health」以繼承目標群組的健康狀態。設計健康狀態端點以反映真實的準備就緒狀態 (相依服務可連線、遷移已套用)。對於有狀態的應用程式，應包含相依性檢查 (資料庫、快取)，以避免將流量路由到部分健康的執行個體。

依目標區分的韌性模式：

• 全球性低 RPO、次分鐘級 RTO：採用 active/active 架構，搭配 Route 53 latency-based 路由和健康狀態檢查、區域本地的無狀態運算、DynamoDB global tables 或 Aurora Global Database，以及針對關鍵物件使用具備 RTC 的 S3 CRR。
• 中等 RPO (≤15 分鐘)、RTO ≤4 小時：採用 warm standby 架構，搭配縮減規模的次要區域、非同步資料庫複本 (RDS cross-Region read replica 或 Aurora Global)、Route 53 failover 路由，以及在容錯移轉時用於擴展和提升的 Runbook 或自動化程序。
• 成本最佳化的災難復原：僅為核心資料服務採用 pilot light 架構，使用基礎設施即程式碼 (infrastructure-as-code) 在啟動時擴展應用程式層，RPO 由複寫頻率決定，RTO 則由佈建時間和資料追趕時間決定。

Elastic Load Balancing 與 Auto Scaling

Elastic Load Balancing：

• Application Load Balancer (ALB)： 第 7 層 (Layer 7)，支援主機/路徑路由、WebSocket/HTTP/2、整合式 WAF、透過目標群組 cookie 實現黏性工作階段 (stickiness)，以及基於請求的運作狀態檢查。使用跨可用區負載平衡和取消註冊延遲 (連線清空) 以在縮減 (scale-in) 或部署期間優雅地清空目標。為了解決後端暖機不均的問題，可設定慢速啟動 (slow start) 和異常偵測 (outlier detection)。
• Network Load Balancer (NLB)： 第 4 層 (Layer 4)，提供超低延遲、靜態 IP/Elastic IP、TLS 通透/終止、保留來源 IP，並支援長效連線。適用於 TCP/UDP 協定、高吞吐量工作負載，或必須看見用戶端 IP 的情境。運作狀態檢查可依設定在第 4/7 層進行 TCP/HTTP/HTTPS 檢查。
• 連線清空 (取消註冊延遲)： 設定適當的延遲時間 (例如 60–300 秒)，讓處理中的請求 (in-flight requests) 得以完成。確保部署和 Auto Scaling 終止事件都遵循此延遲設定，以避免中斷使用者。

Auto Scaling 群組：

• 擴展政策：
  • 目標追蹤擴展： 將一個指標 (如 CPUUtilization、ALB RequestCountPerTarget) 維持在目標值。這是用於 Web/API 機群最簡單且最具適應性的政策。
  • 步階擴展： 當指標跨越閾值時，依定義的步階進行擴展。適用於具有可預測模式的突發流量。
  • 排程擴展： 針對已知事件 (如促銷、產品發布) 預先擴展，以避免容量冷啟動。
  • 預測性擴展： 可選用 ML 預測每日/每週模式的需求。
• 生命週期掛鉤： Launching:Wait 和 Terminating:Wait 讓您可以在執行個體就緒和銷毀時設定閘門。使用掛鉤來：
  • 在執行個體進入服務前，進行啟動 (bootstrap) 程序 (如 SSM Automation、使用者資料完成、AMI 預熱)。
  • 在終止前收集日誌和產出物，以利進行根本原因分析。
  • 協調藍/綠部署或就地部署，這些部署必須確認就緒訊號 (例如

undefined

)。

• 暖集區 (Warm pools)： 將預先初始化的執行個體以 Stopped 或 Running 狀態附加到 ASG，以大幅降低擴展 (scale-out) 延遲。暖集區特別適合搭配冗長的啟動 (bootstrap) 步驟 (如安裝大型套件、下載模型)。設定最小暖容量和重複使用政策。可與生命週期掛鉤 Launching:Wait 結合，僅在應用程式就緒檢查通過後才完成掛鉤，確保一致的切換時間。
• 韌性設定： 為 Spot 執行個體啟用容量重新平衡 (Capacity Rebalance)、使用多種執行個體類型/分配策略、將運作狀態檢查與目標群組的運作狀態綁定，並使用執行個體重新整理 (instance refresh) 搭配運作狀態防護機制來進行安全的滾動更新。

資料層的韌性、複寫與備份

關聯式資料庫：

• RDS Multi-AZ： 同步複寫到位於不同可用區 (AZ) 的備援執行個體；自動容錯移轉會將 DNS 端點更新至備援執行個體。這能防護可用區和執行個體故障，對於具備 Multi-AZ 備援的單一可用區資料庫執行個體，RPO 約為 0，RTO 通常為數分鐘。適用於 MySQL/PostgreSQL 的較新 Multi-AZ DB 叢集提供更快的容錯移轉速度，並具備多個可讀取的備援執行個體。
• 讀取複本： 用於讀取擴展和災難復原 (DR) 的非同步複寫。使用跨區域讀取複本進行 DR；將複本提升 (promotion) 為主要資料庫是手動操作 (或透過執行手冊/Serverless 函式自動化)，且會產生大於 0 的 RPO。確保 binlog 或邏輯複寫已正確設定，並監控複寫延遲。
• Aurora： Aurora Multi-AZ (叢集) 使用共享儲存，並在多個可用區中擁有複本；容錯移轉通常在分鐘內完成。Aurora Global Database 提供基於儲存的實體複寫至次要區域，典型的 RPO < 1 秒，RTO < 1 分鐘。使用受管的計劃性容錯移轉來進行零資料遺失的遷移，或在災難事件中使用非計劃性容錯移轉。寫入器/讀取器端點將拓撲抽象化；應用程式應實作具備退避機制的重試。

物件儲存與災難復原 (DR)：

• S3 版本控制： 啟用版本控制以防止覆寫/刪除，並支援 CRR。設定生命週期政策，將較舊的版本轉移到較便宜的儲存體，並設定適當的保留期限。
• S3 跨區域複寫 (CRR)： 來源和目標儲存貯體皆需啟用版本控制。使用一個複寫 IAM 角色；如果儲存貯體是跨帳戶的，需在目標儲存貯體政策中新增權限，允許來源角色執行

undefined

和 put 操作。對於 KMS 加密的物件，授予該角色對來源金鑰的

undefined

權限，以及對目標金鑰的

undefined

權限。請考慮：

• 複寫時間控制 (RTC)： 讓 99.9% 的物件在 15 分鐘內完成複寫，並提供指標/警示。
• 視需求複寫刪除標記和所有權控制。
• 使用 S3 批次複寫 來處理現有物件。
• 用於 SLA 的複寫指標和通知。
• DynamoDB： 使用全域資料表 (global tables) 以實現多區域/多寫入器、低延遲和高可用性 (HA)。或者，啟用 PITR (時間點復原) 和隨需備份以供復原。

使用 AWS Backup 進行集中式備份：

• 備份計畫： 定義排程 (CRON)、備份視窗、生命週期 (轉移至冷儲存、保留期限)，以及複製到其他區域/帳戶的動作。透過標籤或 ARN 指派資源，以實現政策驅動的涵蓋範圍。
• 備份文件庫： 具備獨立 KMS 加密金鑰和存取政策的邏輯容器。啟用 AWS Backup Vault Lock 以實現 WORM (一次寫入，多次讀取) 不可變性，並建立抗勒索軟體的態勢。使用跨帳戶文件庫複本以減少爆炸半徑。
• 跨帳戶備份： 在 Organizations 中，將備份政策應用於成員帳戶以達成一致的治理。設定文件庫存取政策，允許從中央備份帳戶進行複製/還原。定期執行自動化還原演練，以衡量 RTO 並驗證執行手冊。
• 整合： 保護 EBS、EC2、RDS/Aurora、DynamoDB、EFS、FSx 等服務。將排程和保留期限與法規的 RPO/RTO 要求對齊，並在需要時與應用程式一致性靜止 (application-consistent quiescing) 進行協調 (例如使用 SSM 前/後置指令碼)。

← 容器與無伺服器維運 · 所有領域 · 事件驅動架構與自動化 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →

瀏覽 Amazon →