Amazon SAA-C03: 高可用性、容錯與災難復原 — 學習指南

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

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

Multi-AZ 部署與複寫

Multi-AZ 架構是為了解決單一資料中心或可用區 (Availability Zone) 的故障——僅此而已。這個區別是高可用性設計中最常被誤解的一點。一個 Multi-AZ 部署可以容忍單一 Region 內某個 AZ 的損失；但它無法容忍整個 Region 的中斷、區域性服務受損，或是意外刪除資源後，該刪除動作立即複寫到備援執行個體的情況。複寫會忠實地傳播錯誤的資料——例如邏輯損毀、結構描述錯誤、勒索軟體寫入——這就是為什麼複寫和備份是互補的，而不是互相替代的。

對於 Amazon RDS，Multi-AZ 會在不同的 AZ 中佈建一個同步的備援複本。寫入操作在確認 (acknowledgment) 前回同時提交到兩個執行個體，使得 RPO 基本上為零，而在自動容錯移轉期間的 RTO 通常為 60-120 秒。在傳統的 Multi-AZ 執行個體部署中，備援執行個體是不可讀取的——它的存在純粹是為了耐用性和容錯移轉。Multi-AZ 叢集部署（兩個可讀取的備援執行個體）能進一步縮短容錯移轉時間，並提供一些讀取擴展性，但仍然僅限於單一 Region。

若要擴展讀取能力，請新增讀取複本 (read replicas)。讀取複本使用非同步複寫，其目的是為了分擔報表、分析和儀表板查詢的負載。將讀取複本視為高可用性 (HA) 的容錯移轉機制是錯誤的，原因有三：複寫是非同步的（提升為主資料庫時會遺失資料）、提升操作是手動或透過腳本執行的（非自動），而且主要端點不會被保留。當不斷增長的工作負載需要更多讀取容量且不希望增加新的複雜性時，就新增讀取複本；當需求是零資料遺失的自動容錯移轉時，就使用 Multi-AZ。當關聯式引擎的 RPO/RTO 必須在 Region 故障後仍能達成時，Aurora Global Database 提供了亞秒級的跨區域複寫延遲和亞分鐘級的受管容錯移轉 RTO。

Amazon ElastiCache 的複寫群組 (replication groups) 也遵循同樣的模式。一個啟用了 Multi-AZ 的 Redis 複寫群組會在多個 AZ 中維護一個主要節點和一個或多個複本；如果主要節點故障，ElastiCache 會將一個複本提升為主要節點，並更新主要端點。為了水平擴展，Redis（啟用叢集模式時）會將資料分區到多個分片 (shards) 上，每個分片本身就是一個複寫群組。相較之下，Memcached 不會進行複寫——節點遺失意味著該分區的資料遺失。

Amazon FSx 為 FSx for Windows File Server 和 FSx for ONTAP 提供了 Multi-AZ 部署類型，透過在偏好 (preferred) 和備援檔案伺服器之間進行同步複寫來實現。FSx for Lustre 通常是單一 AZ 的（暫存型或持續型）；Lustre 的耐用性來自於與 S3 資料儲存庫的關聯，而非來自 AZ 複寫。

# RDS Multi-AZ with cross-Region read replica for DR
DBInstance:
  Type: AWS::RDS::DBInstance
  Properties:
    Engine: sqlserver-ee
    MultiAZ: true              # AZ-level HA (synchronous)
    BackupRetentionPeriod: 35
    CopyTagsToSnapshot: true
    DeletionProtection: true

RDS 自動備份與時間點復原

RDS 自動備份結合了每日快照與每 5 分鐘持續上傳交易日誌到 S3 的功能，從而提供在 1-35 天保留期間內任何一秒的時間點復原 (PITR)。如果您的 RPO 是 2 小時，RDS 的原生備份功能就已經能滿足需求——不需要額外的快照排程，而且除非您需要跨區域複本、跨帳戶隔離，或超出 RDS 快照複製所能提供的 Vault Lock 語意，否則在其上疊加 AWS Backup 是多餘的。對於不高的 RPO 需求，預設的自動備份通常是成本最低且正確的解決方案。

AWS Backup 作為集中式控制平面

AWS Backup 是一個由政策驅動的控制平面，用於跨 EBS、EC2 (以 AMIs 形式)、RDS、Aurora、DynamoDB、EFS、FSx、Storage Gateway、S3 等服務進行備份。您不需要為特定服務編寫快照邏輯的腳本，而是定義備份計畫 (backup plans)，將描述備份頻率、備份時段、開始/完成時段、生命週期轉換至冷儲存、保留期和目標文件庫的規則分組。資源是透過標籤 (tag) 或 ARN 進行資源指派 (resource assignments) 來納入備份範圍的，因此像 Backup=Daily 這樣的標籤慣例就成為了管理備份覆蓋範圍的操作契約。對於數百個 EC2 執行個體的機群，基於標籤的選擇是最低工作量的方法——只需套用標籤，讓 AWS Backup 自動列舉，而無需為每個執行個體編寫排程。

備份文件庫 (backup vault) 是一個經 KMS 加密的容器，用來存放復原點。存取權限由文件庫上的資源政策控制。

BackupPlan:
  BackupPlanName: tier1-daily
  Rules:
    - RuleName: daily-35day
      TargetBackupVault: vault-locked-compliance
      ScheduleExpression: cron(0 5 ? * * *)
      StartWindowMinutes: 60
      CompletionWindowMinutes: 180
      Lifecycle:
        MoveToColdStorageAfterDays: 30
        DeleteAfterDays: 365
      CopyActions:
        - DestinationBackupVaultArn: arn:aws:backup:us-west-2:111122223333:backup-vault:dr-vault
          Lifecycle: { DeleteAfterDays: 365 }

跨區域與跨帳戶複本

CopyActions 區塊是建立跨區域 (cross-Region) 災難復原 (DR) 複本的機制。AWS Backup 會處理快照複製、使用目標 Region 的 KMS 金鑰重新加密（目標文件庫必須引用該 Region 的金鑰），並套用獨立的生命週期。EBS 和 RDS 快照預設存放在來源 Region——如果整個 Region 受損，這些快照也會跟著受損。任何提及區域性彈性的法規或業務需求，都必須包含一個明確的跨區域複製步驟，無論是透過 AWS Backup 的複製動作、RDS 自動快照的跨區域複製，還是 DLM 政策與跨區域目標。

對於跨帳戶 (cross-account) 複本，AWS Organizations 會為 AWS Backup 委派一個管理員帳戶；來源文件庫的政策允許目標帳戶存取，而目標文件庫則允許從來源複製。這是集中化災難復原 (DR) 的一種具成本效益的方式：由一個管理帳戶持有來自多個工作負載帳戶的復原點，並且可以還原到任一 Region。對於 EC2，將 AMI 複製到第二個 Region 再加上快照共享，可讓您在該處啟動執行個體，而無需準備暖機的基礎設施。加密快照需要共享 CMK——目標帳戶或 Region 需要 kms:CreateGrant 權限以及對該金鑰的存取權。遺漏了這一步是跨帳戶還原會無聲無息地失敗的原因。

24 小時的 RPO 可以透過每日自動快照並跨區域複製來低成本地滿足——這遠比跨區域讀取複本或暖機備援叢集便宜得多。只有當 RPO 需求降低到快照頻率無法滿足時，才需要收緊為持續複寫。

AMI 生命週期與 EC2 備份

有兩種機制可以自動化 EC2 備份：Data Lifecycle Manager (DLM) 和 AWS Backup。DLM 比 AWS Backup 更早出現，它能根據政策排程建立 EBS 快照或 AMI，並支援跨區域和跨帳戶的複製動作。AWS Backup 則涵蓋了 DLM 的功能，並增加了集中式政策、Vault Lock 和跨多種服務的範疇。當您已經為其他服務執行 AWS Backup 時，請優先選用它；若您的情境僅涉及 EBS/AMI 且不需要保管庫功能，則使用 DLM。

對於位於 Auto Scaling group 後方、沒有持久性本機資料的無狀態 (stateless) Web 層而言，備份正在運行的 EC2 執行個體是浪費資源的。正確的做法是預先烘焙 (bake) 一個強化的 AMI (透過 EC2 Image Builder 或 CI 管線)，在啟動範本中引用它，然後讓 ASG 處理執行個體的替換。備份的力氣應該集中在有狀態 (stateful) 的層級，其原生的自動化備份機制才能滿足 RPO。

不可變性：Vault Lock 與 Object Lock

一個在您帳戶中的普通快照，任何擁有正確 IAM 權限的人都可以刪除——單純的快照無法滿足不可變性的要求。法規制度 (如 SEC 17a-4、FINRA、HIPAA、GDPR) 經常要求「寫入一次，讀取多次」(write-once-read-many, WORM) 的保留機制，即使是管理員也無法規避。AWS 有兩種機制可以實現這一點。

AWS Backup Vault Lock 在備份保管庫上強制執行 WORM：

在合規模式下，一旦冷卻期結束，任何使用者——包含 root 帳戶——都無法縮短保留期、在到期前刪除復原點，或移除鎖定本身。這能有效抵禦內部人員的刪除行為，以及已完全入侵帳戶的勒索軟體操作者。

aws backup put-backup-vault-lock-configuration \
  --backup-vault-name ComplianceVault \
  --changeable-for-days 3 \
  --min-retention-days 2555 \
  --max-retention-days 2920

S3 Object Lock 在物件層級提供 WORM 功能，分為治理模式 (擁有 s3:BypassGovernanceRetention 權限的特權使用者可以覆寫) 或合規模式 (任何人，包括 root，都無法刪除或縮短保留期)。Legal Hold (合法保留) 則獨立於保留期之外。Object Lock 需要啟用版本控制，且必須在儲存桶建立時啟用才能獲得完整保護。

為故障轉移區域預留容量

一個假設在大型災難事件發生當天，故障轉移區域仍會有 EC2 容量可用的災難復原計畫，根本稱不上是個計畫。當一個區域故障時，所有人會同時進行故障轉移，而執行個體類型——特別是大型、GPU 或特殊規格的——可能會耗盡。目標區域中的 On-Demand Capacity Reservations (ODCRs) 保證了特定執行個體類型、平台和 AZ 的容量，無論是否使用都會計費。您可以搭配 Savings Plan 來抵銷成本。對於長期的 GPU/ML 承諾，可應用 Capacity Blocks；若需要系列彈性，Capacity Reservation Fleet 可涵蓋多個執行個體系列。原則就是：如果業務要求在災難復原區域有受保障的運算能力，就去預留它——不要依賴盡力而為 (best-effort) 的 On-Demand 可用性。

災難復原策略的選擇

AWS 將災難復原策略標準化為四個層級，每個層級在成本和復原能力之間都有不同的權衡：

正確的層級是由業務的 RPO 和 RTO 決定的——而非架構師的偏好。24 小時的 RPO 可以容忍每日的跨區域快照複製 (備份與還原)。秒級的 RPO 則需要持續複寫——例如跨區域讀取複本、Aurora Global Database、DynamoDB Global Tables 或 S3 Cross-Region Replication。試圖用每晚的快照來達成 5 分鐘的 RPO，在架構上是不可能的，無論預算多少。反過來說，為每個工作負載都預設使用 active-active 是一種成本上的反模式 (cost antipattern)：它需要全域一致的資料 (DynamoDB Global Tables 或啟用寫入轉發的 Aurora Global)、全規模的重複運算資源，以及透過 Route 53 或 Global Accelerator 進行的複雜流量導向。請選擇能滿足所規定 RPO/RTO 的最便宜模式——對於 2 小時的 RPO，備份與還原或指示燈通常就足夠了，而暖待命則是過度設計。

刪除保護與分層防護

彈性不僅僅是「我們有備份嗎」——而是「任何單一的行為者、錯誤或攻擊能否抹除它們」。分層的控制措施可以防止「一鍵誤刪」的大災難：

• RDS: 啟用 DeletionProtection，並要求在刪除時建立最終快照。
• EC2: 在關鍵執行個體上啟用 DisableApiTermination 和 DisableApiStop。
• DynamoDB: 啟用刪除保護和 point-in-time recovery (時間點復原)。
• S3: 版本控制 + MFA Delete + Object Lock 以實現不可變性。
• CloudFormation: 在有狀態的資源上設定 DeletionPolicy: Retain，並啟用堆疊終止保護。
• IAM SCPs: 拒絕 backup:DeleteRecoveryPoint、backup:DeleteBackupVault、rds:DeleteDBInstance 和 ec2:DeleteSnapshot 等操作，除非是透過緊急應變角色 (break-glass roles) 執行。

aws rds modify-db-instance \
  --db-instance-identifier prod-pg \
  --deletion-protection \
  --backup-retention-period 35 \
  --apply-immediately

將這些措施與合規模式下的 Vault Lock 結合，就能產生深度防禦 (defense in depth)：即使是管理員憑證被盜用，也無法摧毀作為最後一道防線的復原點。

常見陷阱

將 Multi-AZ 當作災難復原 (DR)。 RDS Multi-AZ、ElastiCache Multi-AZ 和 FSx Multi-AZ 都存在於單一 Region 內。一次 Region API 中斷、意外刪除資料表或錯誤套用 schema 變更，都會同時影響到兩個節點。任何提及「另一個 Region」、「區域性故障」或「跨 Region RPO」的需求，都必須採用跨 Region 複寫或複製——單靠 Multi-AZ 無法滿足此需求。

將 Read Replica 與高可用性 (HA) 混淆。 Read Replica 是非同步的，需要手動提升 (promote)，且會變更端點 (endpoint)。它們解決的是讀取擴展 (read scaling) 的問題，而不是自動容錯移轉 (automatic failover)。

假設快照 (snapshot) 等同於合規性。 沒有使用 Vault Lock (合規模式) 或 Object Lock 的快照，可以被任何擁有正確 IAM 權限的主體 (principal) 以及根帳戶 (root account) 刪除。WORM (一次寫入，多次讀取) 的法規保留要求，需要明確設定不可變性 (immutability)，並等待鎖定的冷卻期結束。

為了 Region 等級的 RPO 卻只使用本地快照。 EBS 和 RDS 的快照預設儲存在來源 Region。要達到 Region 層級的彈性 (resilience)，需要明確執行跨 Region 複製的動作。

備份卻沒有經過還原測試或預留容量。 一個從未還原過的快照只是一個假設，不能算是真正的備份。還原演練可以揭露出缺少 IAM 角色、目標 Region 和帳戶中的 KMS 金鑰存取問題，以及無法使用的執行個體類型等問題。若沒有為關鍵工作負載設定 Capacity Reservations，當大家同時進行容錯移轉時，DR Region 可能根本沒有您需要的執行個體類型——這會讓 RTO 變得無法預測。

過度設計成 active-active 架構。 重複的全球運算資源、全球一致的資料複寫，以及複雜的流量導向都非常昂貴。如果 RPO/RTO 的要求沒有高到那種程度，那麼 pilot light 或 warm standby 才是正確的架構。

備份無狀態 (stateless) 的層級。 對 ASG 後方的短暫 (ephemeral) Web 伺服器進行快照，不僅浪費金錢，還會讓復原過程變得複雜。應該要預先製作 (Bake) AMI，在啟動範本 (launch template) 中引用它們，並將備份的投資集中在有狀態 (stateful) 的資料上。

← 管理、維運、可觀測性與成本 · 所有領域

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

瀏覽 Amazon →