上一篇提到，Route 53 與 Global Accelerator 可以協助把流量導向不同入口，但目的地仍然需要具備接手服務的能力。
假設目前的系統已經跨兩個 Availability Zone（AZ，可用區）部署：
ALB
│
┌─────────┴─────────┐
│ │
AZ-A AZ-C
│ │
Application Application
如果其中一台主機，甚至其中一個 AZ 發生問題，另一邊還能繼續提供服務。
不過，Multi-AZ 的保護範圍有限，若是整個 Region 無法提供服務、資料被誤刪，或錯誤版本同時部署到所有主機，都需要其他復原方式，即使有資料複寫，錯誤操作也可能同步到其他副本。
因此，決定架構前要先確認需要承受哪些故障，再定義兩個目標：
這些條件會影響 Multi-AZ、備份與跨 Region 災難復原該如何搭配。
要把業務對中斷與資料損失的容忍程度轉成架構條件，可以先定義兩個目標：
| 指標 | 意義 | 要回答的問題 |
|---|---|---|
| RTO（Recovery Time Objective，復原時間目標） | 服務中斷後，可接受的最長復原時間 | 多久內必須恢復服務？ |
| RPO（Recovery Point Objective，復原點目標） | 以時間衡量可接受的資料損失範圍 | 最多能接受遺失最近多久的資料？ |
假設系統在 14:00 發生故障，RTO 是 30 分鐘，代表目標是在 14:30 前恢復服務；RPO 是 5 分鐘，代表復原後的資料至少應涵蓋到 13:55。
兩者要分開驗證，如果資料完整，但花了 3 小時才恢復，仍然超過本例的 RTO；如果 5 分鐘內恢復服務，資料卻只能還原到昨天，則超過 RPO。
這裡的「恢復服務」應以使用者能完成關鍵操作為準，例如訂單系統可以開啟首頁，卻仍無法下單，就不能只因為主機已啟動而認定復原完成。
同一個系統也可以針對不同故障設定不同目標，例如單一 AZ 故障時要求快速接手，但整個 Region 無法使用時，可以接受較長的復原時間，若目標越嚴格，通常代表需要付出更高的成本與維運複雜度。
Multi-AZ 的核心，是把服務分散到同一個 Region 中不同的可用區，降低單一 AZ 發生故障時對整個服務的影響。
例如：
Tokyo Region
│
┌────────┴────────┐
│ │
AZ-A AZ-C
│ │
Application Application
如果 AZ-A 故障，仍然可以讓 AZ-C 繼續承接流量，但應用程式跨 AZ 部署後，仍要檢查它依賴的資料庫、儲存與網路路徑。
例如兩台 EC2 分別位於不同 AZ，卻都連到同一個沒有備援的資料庫，資料庫故障時，兩台應用程式仍然無法提供完整服務，需要驗證的是整條服務鏈能否接手，而不只是主機有沒有分散。
以 RDS Multi-AZ DB instance deployment（單一備援執行個體的部署方式） 為例，RDS 會在另一個 AZ 維持同步的 Standby（備援執行個體），並在主要執行個體發生符合條件的故障時，自動進行 Failover（容錯移轉）。
根據 AWS 官方文件，這類部署的容錯移轉通常需要約 60～120 秒，大型交易或較長的復原程序可能讓時間增加，這個時間只描述資料庫的切換過程，應用程式仍需重新建立連線，才能恢復操作。
因此，除了啟用備援，我還會確認：
如果需要承受的是主機或單一 AZ 故障，Multi-AZ 是主要的設計方向；如果整個 Region 都無法提供服務，也必須在指定時間內恢復，就需要進一步評估 Multi-Region（跨區域）的災難復原策略。
服務有備援之後，還需要考慮資料誤刪或寫入錯誤時，要如何復原。
Replication（複寫） 會持續將資料變更傳送到另一份副本，讓副本維持較新的狀態，支援故障接手。
Backup（備份） 則保留可還原的歷史狀態，搭配 Point-in-time Recovery（時間點復原，PITR），可以在支援的保留範圍內，將資料還原到錯誤發生前，因此複寫與備份通常需要搭配使用。
用一情境來做說明，假設 Production Database 持續把資料 Replication（複寫）到另一個位置：
Tokyo Database
│
│ Replication（複寫）
▼
Singapore Database
這可以讓另一邊維持一份較新的資料，對降低 RPO 很有幫助。
但如果今天發生的是：
有人誤刪訂單
↓
刪除動作被同步
↓
另一邊的資料也被刪除
那 Replication 並不能讓你回到刪除前。
這時就會需要 Backup（備份） 或 Point-in-time Recovery（時間點復原） 之類可以回到歷史狀態的能力。
講到這應該會比較理解 Replication 和 Backup 的功能及差別，以下再舉幾個簡單的情境例子：
| 故障情境 | 優先評估的保護方式 |
|---|---|
| 單一主機或 AZ 故障 | Multi-AZ 與容錯移轉 |
| 資料誤刪或錯誤修改 | 備份、版本保留與時間點復原 |
| 整個 Region 無法使用 | 跨 Region 備份或備援環境 |
| 錯誤版本部署 | 版本回復與分階段部署；若已破壞資料，還需資料復原 |
以 RDS 的時間點復原為例，它會依指定時間點建立一個新的資料庫實例，而不是直接把原本的資料庫「倒帶」，團隊需要先驗證還原結果，再決定要補回特定資料，還是將應用程式切換到新資料庫。
這裡還有一個容易忽略的問題：假設 14:00 發生誤刪，但直到 14:30 才被發現，期間仍有新訂單寫入，若直接將整個系統切回 14:00 前的資料，這些有效的新訂單也會缺失，因此復原流程還要處理事故後的有效資料。
備份工作成功，只能證明備份已產生，不能證明服務能在目標時間內恢復 ，還原測試需要確認備份可用、資料正確，以及應用程式能重新完成關鍵操作。
如果業務要求在主要 Region 無法使用時，仍能從另一個 Region 恢復服務，就需要設計跨 Region 的 Disaster Recovery（DR，災難復原）策略。
備援端可以只保留還原所需的資料與設定，也可以維持一套隨時能接手的系統。
AWS 常見的 DR Strategy（災難復原策略）可以依備援端平常準備到什麼程度，大致分成四種（以下策略由準備程度低 → 高來做說明）：
| 策略 | 備援 Region 平時的狀態 | 復原時需要做什麼 |
|---|---|---|
| Backup and Restore（備份與還原） | 保留備份、程式與部署設定 | 建立環境、還原資料，驗證後切換入口 |
| Pilot Light（核心資源待命） | 持續複寫資料，維持資料庫等必要核心資源 | 啟動或建立其餘服務，擴充容量並切換入口 |
| Warm Standby（暖備援） | 維持縮小規模、可運作的完整系統 | 視需求擴充容量並切換流量 |
| Active-Active（雙活） | 多個 Region 同時提供服務 | 將流量移離故障 Region，確認剩餘容量與資料一致性 |
Pilot Light 與 Warm Standby 的差別，在於備援端平時能不能處理請求，前者還需要啟動或建立部分元件；後者已經可以運作，只是容量較小。
Active-Active 也需要處理資料問題，如果多個 Region 都能寫入資料，就要設計一致性與衝突處理方式；如果仍由單一 Region 負責寫入，該 Region 故障時，也要準備寫入端的接手流程。
備援端準備得越完整，事故後需要執行的工作通常越少，有助於縮短 RTO，RPO 則取決於備份頻率、複寫方式與實際資料落差。
越往下，通常能做到越短的 RTO / RPO，但平常要維持的資源、資料同步與營運複雜度也會增加，因此應依 RTO、RPO 選擇，並透過演練確認實際復原能力。
假設一套企業內部系統已採用 Multi-AZ，現在要補上 Region 層級的復原能力，業務可以接受整個 Region 無法使用時，RTO 為 4 小時、RPO 為 24 小時，團隊也具備自動化部署能力。
這個案例中可以優先考慮跨 Region 的 Backup and Restore，不先維持長期運行的 Warm Standby 環境，這能減少平時維護的資源，但團隊必須承擔事故後建立環境、還原資料與切換服務的工作。
選擇成立的前提，是演練結果符合目標：
如果實測光是還原資料就超過 4 小時，這個方案便不符合需求，必須調整還原方式或提高備援端的準備程度。
若業務進一步要求 RTO 為 15 分鐘、RPO 為 1 分鐘，此時則可以改評估持續複寫搭配 Warm Standby，讓備援端平時就能運作，可以減少事故後的部署工作。
同樣的系統，允許花幾個小時重建，與必須在十幾分鐘內接手，需要準備的資源不同，架構選擇上應先定義 RTO / RPO，再來決定需要 Multi-AZ、Backup、Replication，還是跨 Region DR，最後再用演練結果確認是否足夠。
下一篇會補上網路篇的實作當做網路篇的結尾（想了想還是決定加入一點實作內容）！會使用兩個 VPC，帶讀者逐步設定 VPC Peering、雙向路由與 Security Group，觀察每一步如何影響連線結果。
iThome鐵人賽
看影片追技術