Amazon SAP-C02: 韌性、災難復原與高可用性 — 學習指南
屬於 AWS Solutions Architect Professional SAP-C02 — 學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.
RTO 與 RPO 規劃：量化容忍度並對應架構
RTO (復原時間目標) 與 RPO (復原點目標) 驅動著從運算規模設定到複寫拓撲的每一項彈性選擇。首先，根據業務影響和停機成本對工作負載進行分類，然後將這些優先順序轉化為可衡量的目標：毫秒級的 RPO 會驅使我們採用同步複寫或專為此目的建置的全域資料庫，而分鐘到小時級的 RPO 則允許使用非同步複寫、快照排程或批次日誌傳送。使用與目標一致的 AWS 服務：Amazon Aurora Multi‑AZ 和 Aurora Global Database 可實現大規模下的低 RTO/RPO；RDS Multi‑AZ 可提供同步的單一區域高可用性；跨區域讀取複本可用於復原和報告；而 AWS Elastic Disaster Recovery (DRS) 則能以最少的應用程式變更，對地端伺服器進行近乎即時的複寫。一個常見的陷阱是，設計時只考慮滿足平均負載，而非最壞情況下的復原操作；另一個陷阱是假設僅靠快照就能滿足交易型系統的 RPO，因為快照之間可能相隔數分鐘，且可能缺乏應用程式一致性。決策上的權衡取捨很直接：同步複寫會增加成本和寫入延遲，但能降低 RPO；非同步複寫則降低延遲和成本，但會增加潛在的資料遺失風險。透過混沌測試、排定的容錯移轉和還原演練來測試計畫，以驗證實際的 RTO/RPO，並找出隱藏的相依性，例如外部驗證、DNS 或 IP 白名單。
多可用區與多區域架構及容錯移轉策略
多可用區 (Multi‑AZ) 架構透過在多個可用區之間放置備援的運算、網路和儲存資源來防禦 AZ 故障；多區域 (Multi‑Region) 則將容錯能力擴展到區域級的故障、自然災害或大型網路分割。根據成本和復原需求，選擇一種架構模式——指示燈 (pilot light)、暖待命 (warm standby)、主動-被動 (active‑passive) 或主動-主動 (active‑active)。指示燈模式在次要區域使用最少的資源以最小化成本，並在容錯移轉期間擴展規模；暖待命模式則保持縮減規模的服務持續運行，以實現更快的復原；主動-主動模式在多個區域提供流量服務以達到最低的 RTO，但需要強大的資料複寫和衝突解決機制。使用 Route 53 搭配運作狀態檢查和容錯移轉路由、使用 Amazon CloudFront 或 Global Accelerator 進行全域流量管理，以及使用像 DynamoDB Global Tables 或 Aurora Global Database 這類的資料服務進行跨區域複寫。常見的陷阱包括：依賴過長的 DNS TTL、未驗證有狀態服務（如 session 儲存、快取）的容錯移轉，以及忽略跨區域資料傳輸成本和合規性限制。在多區域部署的複雜性和成本與可接受的停機時間和資料遺失之間進行權衡；若有疑慮，應檢測和模擬容錯移轉時間，為業務案例提供資訊。
應用程式彈性模式：無狀態化、解耦與狀態管理
透過最小化固定在個別運算節點上的狀態，並解耦元件以防止局部故障連鎖擴散，來為故障而設計。位於 Application Load Balancer 或 Network Load Balancer 後方的無狀態應用程式節點，可實現水平擴展和快速替換。對於 session 狀態，應優先選用如 Amazon DynamoDB 或 Amazon ElastiCache 等外部儲存，而非黏性會話 (sticky sessions)；對於檔案共享，則根據協定和效能需求使用 Amazon S3、Amazon EFS 或 FSx。使用 Amazon SQS、SNS 或 Kinesis 的非同步模式可緩衝流量尖峰、實現重試機制並平滑化背壓，並在容錯移轉期間減少同步相依性。在用戶端實作斷路器 (circuit breakers)、艙壁 (bulkheads) 和指數退避 (exponential backoff)，以隔離故障的子系統。架構師常犯的一個陷阱是低估了冷啟動或擴展規模所需的時間——Lambda 的並行限制、Auto Scaling 的冷卻時間以及暖機策略都會影響 RTO。另一個陷阱是將快取視為持久性；快取必須是可重建的。成本與彈性之間的選擇體現在緩衝區大小和複寫策略上：更高的彈性通常需要更多的預留容量或跨區域複寫，從而增加成本；應選擇能滿足 RTO/RPO 的最小可行備援，同時確保具備可觀測性和自動化能力來偵測和修復故障。
備份、複寫、治理與維運整備度
備份是一種保險；其關鍵在於一致性、安全性、保留期和可復原性。使用 AWS Backup 集中管理 EBS、RDS、DynamoDB、EFS 和 FSx 的備份政策，並強制執行跨帳戶、跨區域的備份副本，以實現地理彈性。對於物件資料，啟用 S3 版本控制搭配生命週期規則，並使用 S3 Replication (CRR) 來達成跨區域的耐久性。透過利用資料庫原生備份、RDS 自動快照或支援 VSS 的 AWS DRS，確保資料庫和 Windows 檔案系統的應用程式一致性快照。跨帳戶複寫和 IAM 最小權限原則對於防止意外刪除至關重要。定期的還原演練可以揭露 IAM 角色缺失、網路問題 (例如 VPC CIDR 重疊) 或外部整合等問題。使用 Systems Manager Automation 將 runbook 自動化，並將容錯移轉程序以 CloudFormation 或 Terraform 進行程式碼化，以減少人為錯誤。常見的陷阱包括：僅依賴無法匯出的時間點快照、未使用客戶自管金鑰加密備份，以及未能監控備份任務的成功與否。在法規要求與保留期及儲存成本之間取得平衡；將較舊的備份分層至 S3 Glacier 以控制成本，同時保持近期的備份可快速存取，以便快速還原。
實務問題：使用案例情境
情境：Meridian Events Inc. 是一家全球性的現場活動企業，在單一 AWS 區域中執行一個票務應用程式。該應用程式使用位於 ALB 後方的 EC2 Auto Scaling 群組，並在一個可用區域 (AZ) 中的 EC2 上運行一個 3 節點的 PostgreSQL 叢集，且每晚進行 EBS 快照。該組織需要將 RTO 降至 10 分鐘以下，RPO 降至 5 分鐘以下，同時將維運開銷和成本降至最低。
挑戰：在跨 AZ/區域的情況下，為資料庫實現近乎連續的可用性和低資料遺失率，並具備可預測的容錯移轉能力，且只需對應用程式進行最少的變更。
建議方法：
- 設定 Amazon RDS for PostgreSQL 的 Multi‑AZ 部署，或遷移至 Amazon Aurora PostgreSQL 並啟用 Multi‑AZ，同時啟用自動化連續備份和快速快照匯出；啟用自動化備份並設定適當的保留期限。
- 使用 Aurora Global Database (或透過 RDS 邏輯/實體複寫至次要區域的讀取複本) 新增跨區域複寫，以滿足地理上的 RPO 目標，並設定 Route 53 的延遲路由搭配運作狀態檢查，以實現受控的區域性容錯移轉。
- 將單一 AZ 的 EC2 PostgreSQL 替換為託管服務以消除主機維護，並重構應用程式的連線邏輯，改用叢集端點或 RDS Proxy 來進行連線池化和更快的容錯移轉處理。
- 實作持續的複寫驗證和 runbook 自動化：使用 Systems Manager Automation 和 CloudFormation 範本進行排程的容錯移轉演練，以快速重建資源；透過 CloudWatch 和 SNS 來檢測指標並發送警示。
基本原理：使用託管的 Multi‑AZ 資料庫服務和跨區域複寫，可降低維運複雜性並達成積極的 RTO/RPO 目標；自動化和定期演練可確保計畫在實務中可行，而 RDS/Aurora 則能將手動容錯移轉步驟和容錯移轉時間降至最低。
練習這些題目 → · 在 ExamRoll.io 上限時練習 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
通過考試 →