選擇 AWS 上的災難備援方案

我們聊到選擇方案的時候，不外乎就是好用跟多少錢

一般人，通常第一直接就是，就給我一個real – time吧 ，我的環境 always on 完全不會死掉 !!

欸 ? Real – time 嗎 ? 太好了 ! 肥羊來了 !! 兩倍的價錢阿~~

其實隨著RTO/RPO越小，也就是伺服器斷線時間越小/失去的資料越少，價錢當然也就越高

我們更應該要去檢視自己的架構，不應該盲目追從最高級的方案，應該得要選擇最適合自己的 !

AWS 上災難備援方案分為哪幾種

從 RPO/RTP 設定層級中，
由 小時 > 分鐘 > 秒至分鐘 > Real Time 來分類
越往右的方案，恢復時間越少，成本也越高 ！

備份和恢復（Backup and Restore）：

以下圖為例，可以看到在第一個可用區運行的服務，建立快照至第二個可用區預備
當災難來襲時，使用第二個可用區的快照來建立服務

簡易架構圖：

舉例：跨區域備份/跨帳號備份 – S3開啟 Cross-region backup

使用AWS服務（如Amazon S3）來儲存和管理數據備份
在災難發生時，可以從這些備份中恢復數據
適用於對恢復時間和恢復點要求不是非常嚴格的場景
可以參考Day 19 高可用性架構 > S3 跨可用區複寫資料

機房間遠程複寫（Pilot Light）：

簡易架構圖：

舉例：AWS 雲原生的Database – Aurora
他會預設你做一個主從式架構，如果使用RDS則是可以自己建立主從式架構 !

在次要地區建立一個最小化的關鍵核心環境（例如資料庫的一個只讀副本）
災難發生時，可以快速擴展到完整的生產環境
較低的成本相對於全面運行的DR站點

可以參考Day 20 高可用性架構 > 雲原生資料庫 AWS RDS Multi-AZ

暖備（Warm Standby）：

在次要地區運行一個縮小規模的實時環境
災難發生時，迅速將流量切換到這個次要地區，並根據需要進行擴展

簡易架構圖：

舉例：AWS DRS (AWS Elastic Disaster Recovery)

可以快速、可靠地復原內部部署和以雲端為基礎的應用程式，從而最小化停機時間和資料遺失
在主要可用區和次要可用區中間
有複寫主機不斷的在將主要可用區服務的資料複寫至次要可用區的EBS磁碟區中

熱備（Hot Standby）

直接在次要地區複製一模一樣且同時運行的架構 !

簡易架構圖：

說到這邊大家會發現，其實『災難備援 DR 這回事』，
和我們前幾天所說的『高可用架構』、『備份』有非常大的關聯

明天就來大家看看，之前沒提過的 AWS RDS (AWS Elastic Disaster Recovery) 吧 !