AWS 認證準備 ch13 災難復原與韌性架構
下一章→
CH 13 高頻必考

災難復原與韌性架構

RTO / RPO四種 DR 策略跨區複製AWS Backup備份與還原

這是 SAA 考試佔比最高領域(設計韌性架構)的核心,卻最容易被跳過。本章先把兩個衡量指標 RTO(多久能救回來) 與 RPO(最多能接受掉多少資料) 弄懂,再對照 四種災難復原策略(Backup & Restore → Pilot Light → Warm Standby → Multi-Site)在「成本 vs 復原速度」上的取捨。最後把前面各章學過的服務(S3 跨區複製、Aurora 全球資料庫、DynamoDB Global Table、Route 53 Failover)串成一張完整的備援地圖——考試最愛考「這個 RTO/RPO 要求,該選哪種策略」。

整個災難復原(DR, Disaster Recovery)的選型,都建立在這兩個問題上。考試題目會用它們的數字大小暗示你該選哪種策略:

  • RPO(Recovery Point Objective,復原點目標)= 你最多能接受掉多少「資料」,用時間衡量。RPO = 1 小時,代表災難發生時,最多容忍遺失「最近 1 小時」的資料——也就是至少每小時要備份/複製一次。RPO 往回看,指向「上一個安全存檔點」。
  • RTO(Recovery Time Objective,復原時間目標)= 你最多能接受服務「停機」多久。RTO = 30 分鐘,代表災難發生後 30 分鐘內服務必須恢復。RTO 往前看,指向「多快能重新上線」。
⭐ 一句話記牢:RPO 看「資料」能掉多少(往回看到上次備份),RTO 看「時間」能停多久(往前看到恢復上線)。兩個數字都是「越小 = 要求越高 = 成本越貴」。
💡 舉例:銀行轉帳系統 RPO 幾乎要 0(一筆都不能掉)、RTO 也要極短;而一個內部週報系統,RPO 可以是 24 小時(掉一天的資料再跑一次就好)、RTO 可以是幾小時。需求不同,該花的錢差很多。
🚨 考試陷阱:題目說「最多只能遺失 5 分鐘的交易資料」= 在講 RPO;說「必須在 15 分鐘內恢復服務」= 在講 RTO。看到「遺失資料」聯想 RPO,看到「恢復/停機時間」聯想 RTO。

AWS 官方把 DR 策略分成四種,由「便宜但慢」到「昂貴但快」排列。這是本章最核心、最常考的一張心智圖:

  • ① Backup & Restore(備份與還原):平時只把資料「備份」到另一個 Region,DR 區完全沒有運算資源在跑。災難時才臨時建立基礎設施、還原資料。
    → 成本最低 💲,但 RPO/RTO 最長(數小時)。
  • ② Pilot Light(指示燈):像瓦斯爐的長明小火——只讓核心(通常是資料庫)在 DR 區持續複製、隨時待命,但應用伺服器平時是關閉的。災難時才點火啟動應用層並擴展。
    → 成本低 💲💲,RPO 短(分鐘級,因為 DB 一直在同步),RTO 中等(要花時間開應用機)。
  • ③ Warm Standby(溫備援):DR 區有一套完整但縮小規模的環境「一直在跑」(所有元件都在,只是機器數量少、規格小)。災難時直接放大規模(scale up/out)接手全部流量。
    → 成本中高 💲💲💲,RPO/RTO 都是分鐘級。
  • ④ Multi-Site Active/Active(多站點雙活,又稱 Hot Standby):兩個 Region 都以完整規模同時運行、同時服務真實流量。災難時把流量全導到存活的那區即可。
    → 成本最高 💲💲💲💲,RPO/RTO 近乎即時(秒級、幾乎零停機)。
⭐ 順口溜:備份還原(Backup)→ 指示燈(Pilot Light)→ 溫備援(Warm Standby)→ 雙活(Multi-Site),一路「越來越貴、越來越快」。DR 區平時的活躍度:無運算 → 只有 DB → 縮小版全套 → 全規模雙份。
🚨 最愛考的判斷:題目同時給你「預算」和「RTO/RPO 要求」,要你選 CP 值最合適的一種——不是越貴越好,是「剛好滿足要求的最便宜方案」。要求鬆(可停機數小時)就別選 Multi-Site 浪費錢。

DR 策略是「觀念」,真正落地要靠前面章節學過的這些跨 Region 複製能力。把它們串起來就是一張備援地圖:

  • S3 Cross-Region Replication(CRR,跨區複製):自動把物件非同步複製到另一個 Region 的 bucket。前提是兩邊都要開啟版本控制(Versioning)。用於資料層的異地備份。
  • RDS:可建跨區 Read Replica(災難時手動 Promote 成主庫),或把自動備份的快照跨區複製。
  • Aurora Global Database:DR 界的優等生——一個主 Region 可寫、最多 5 個次要 Region 唯讀,跨區複製延遲通常小於 1 秒,主區故障時可在約 1 分鐘內把次區提升為主區。適合要求低 RPO/RTO 的關鍵系統。
  • DynamoDB Global Tables:多 Region 多主動(Multi-Master)寫入,每區都能就近讀寫、彼此同步。天生就是 Active/Active。
  • Route 53 Failover 路由 + Health Check:DNS 層的自動切換。健康檢查發現主站掛掉,就把使用者流量自動導向備援站——這是把上面各層「接起來」讓使用者無感切換的關鍵。
  • EBS Snapshot:磁碟的時間點快照存在 S3(跨 AZ 耐久),可跨區複製用於異地重建。
⭐ 對應記憶:資料檔案 → S3 CRR;關聯式 DB 低 RPO → Aurora Global Database;NoSQL 全球雙寫 → DynamoDB Global Tables;流量自動切換 → Route 53 Failover。
💡 AWS Elastic Disaster Recovery(AWS DRS,前身 CloudEndure):對「整台伺服器」做區塊級(block-level)持續複製到 AWS,是把地端或雲上主機快速故障轉移的專用服務。題目出現「將現有伺服器(含作業系統)持續複製、快速 failover 到 AWS」時想到它。

當你有一堆不同服務(EC2、EBS、RDS、DynamoDB、EFS、Storage Gateway…)各自要備份時,逐個設定既麻煩又容易漏。AWS Backup 就是把這些備份「集中管理」的服務:

  • 統一備份計畫(Backup Plan):用一套策略(多久備一次、保留幾天)一次涵蓋多種服務,不必每個服務各自設定。
  • 跨 Region / 跨帳號複製:可以把備份自動複製到另一個 Region 或另一個 AWS 帳號,實現異地備援與帳號隔離。
  • Backup Vault Lock(保存庫鎖定):以 WORM(Write Once Read Many,一次寫入不可竄改)模式鎖住備份,連管理員也刪不掉。用於合規與防勒索軟體——就算帳號被入侵,備份也刪不掉、改不了。
  • 集中稽核:搭配 AWS Backup Audit Manager 檢查備份是否符合規定。
⭐ 題目關鍵字:「集中管理多個服務的備份」「用單一策略統一保留政策」「備份要跨帳號/跨區且不可被刪改(合規/防勒索)」→ 全部指向 AWS Backup(+ Vault Lock)。
🚨 別搞混:AWS Backup 是「排程與集中管理」備份;真正低 RPO 的即時複製(如 Aurora Global DB、DynamoDB Global Tables)是各服務自己的功能,不是 AWS Backup 做的。

這三個詞常被混用,但考試會故意把它們當誘答選項。它們解決的是不同層級的問題:

  • 高可用 High Availability(HA):對抗單一 AZ / 單台機器故障。做法是同一個 Region 內跨多個 AZ部署(如 RDS Multi-AZ、ELB + Auto Scaling 跨 AZ)。通常自動、即時切換,目標是「平常就不要掛」。
  • 災難復原 Disaster Recovery(DR):對抗整個 Region 級的重大災難(天災、大規模服務中斷)。做法是跨 Region備援。就是本章的四種策略。
  • 備份 Backup:對抗資料被誤刪、損毀、勒索加密。是資料的「時間點副本」,讓你能回到過去某個狀態。HA 幫不了你——如果資料被刪,兩個 AZ 的副本會「同步地」一起被刪。
⭐ 一句話分層:HA = 跨 AZ 防單點故障(同區);DR = 跨 Region 防區域級災難;Backup = 防資料被刪改(時間旅行)。三者互補,不是二選一。
🚨 經典陷阱:「RDS Multi-AZ 能不能當災難復原方案?」→ ❌ 不能!Multi-AZ 只在同一個 Region跨 AZ,整個 Region 掛掉照樣完蛋。跨 Region 才算 DR(要用跨區 Read Replica 或 Aurora Global Database)。同理 Multi-AZ 也不能取代備份(誤刪照樣同步刪掉)。
四種 DR 策略對比(考試核心)
策略RPO / RTODR 區平時狀態成本何時選它
① Backup & Restore數小時(最長)只有備份資料,無運算💲 最低預算有限、可容忍較長停機
② Pilot LightRPO 分鐘 / RTO 數十分鐘核心 DB 持續複製待命,應用層關閉💲💲 低關鍵資料需即時、應用可稍後啟動
③ Warm StandbyRPO / RTO 皆分鐘級完整但縮小規模的環境持續運行💲💲💲 中高停機成本高、需快速承接流量
④ Multi-Site Active/Active近乎即時(秒級)全規模雙區同時服務流量💲💲💲💲 最高金融/關鍵系統、近乎零停機
需求情境 → 該選哪種策略
需求情境建議策略理由
預算有限,可停機數小時、掉數小時資料Backup & Restore平時只付備份儲存費,最省
資料一筆都不想多掉(RPO 極小),但 RTO 可接受數十分鐘Pilot LightDB 持續複製確保 RPO,應用災難時再啟動
停機每分鐘都是損失,需數分鐘內恢復Warm Standby縮小版環境隨時待命,放大規模即可承接
金融/關鍵系統,幾乎零容忍停機與資料遺失Multi-Site Active/Active雙區同時服務,故障切換近乎無感
全球用戶要低延遲讀寫,且要能自動撐過區域故障Aurora Global DB / DynamoDB Global Tables跨區複製 <1 秒,天生跨 Region 備援
各服務的跨 Region 備援能力
服務跨區備援機制關鍵特性
S3Cross-Region Replication(CRR)需先開版本控制,非同步複製物件
RDS跨區 Read Replica / 快照跨區複製災難時手動 Promote 成主庫
AuroraGlobal Database次區延遲 <1 秒,可 <1 分鐘提升為主區
DynamoDBGlobal Tables多區多主動寫入,天生 Active/Active
Route 53Failover 路由 + Health Check主站掛掉自動把流量切到備援站
EBSSnapshot 跨區複製異地重建磁碟/EC2
多服務統管AWS Backup(跨區/跨帳號複製)單一策略 + Vault Lock 防刪改

練習題 點選選項查看解析

0 / 24
01 / 24
一家公司的內部報表系統,經評估後可以容忍「災難時最多遺失 24 小時的資料」以及「服務中斷數小時」,且希望費用越低越好。最適合的災難復原策略是?
A Multi-Site 雙活方案
B Warm Standby 溫備援
C Backup Restore 備援
D Pilot Light 指示燈
解析
需求非常寬鬆(RPO 24 小時、RTO 數小時)且要求最省錢,正是 Backup & Restore 的適用場景:平時只把備份放到另一個 Region,不維持任何運算資源,成本最低。災難時才臨時建立基礎設施還原。選更貴的 Warm Standby / Multi-Site 會為了用不到的復原速度浪費大量成本——DR 選型的原則是『用剛好滿足要求的最便宜方案』。
02 / 24
某電商平台要求:災難發生時交易資料最多只能遺失幾分鐘(RPO 極小),但服務可以接受約 30 分鐘的恢復時間(RTO 中等),同時希望盡量控制平時成本。最合適的策略是?
A Backup & Restore:僅保留跨區備份,平時無運算資源
B Pilot Light:核心資料庫持續跨區複製,應用層平時關閉
C Multi-Site Active/Active:雙區同時全量服務流量
D RDS Multi-AZ:僅同一 Region 跨 AZ 備援
解析
Pilot Light 剛好符合:讓核心資料庫在 DR 區『持續複製』確保 RPO 只有幾分鐘;應用伺服器平時關閉以省成本,災難時才啟動並擴展,換來中等的 RTO(數十分鐘)。Backup & Restore 的 RPO 太長(數小時)不符;Multi-Site 成本過高;RDS Multi-AZ 只在同一 Region 跨 AZ,無法應對整個 Region 級的災難。
03 / 24
一個關聯式資料庫應用需要跨 Region 的災難復原,要求次要 Region 的資料延遲極低(約 1 秒內)、且主 Region 故障時能在約 1 分鐘內切換為可寫入。最佳選擇是?
A RDS 跨 Region Read Replica
B S3 Cross-Region Replication
C Aurora Global Database
D DynamoDB Global Tables
解析
Aurora Global Database 專為此設計:主 Region 可寫、次要 Region 唯讀,跨區複製延遲通常 <1 秒,主區故障時可在約 1 分鐘內把次區提升為主區。RDS 跨區 Read Replica 也能做 DR,但複製延遲與切換速度不如 Aurora Global DB。DynamoDB Global Tables 是 NoSQL(題目要關聯式);S3 CRR 是物件儲存,不適合當交易資料庫。
04 / 24
以下關於「RDS Multi-AZ 能否作為災難復原(DR)方案」的敘述,哪一項正確?
A 可以,Standby 位於不同 AZ 已可涵蓋整個 Region
B 不行,Multi-AZ 僅跨 AZ 備援,無法涵蓋整個 Region
C 可以,Multi-AZ 會自動跨 Region 複製資料
D 可以,Multi-AZ 與 DR 是同一套機制
解析
Multi-AZ 提供的是『高可用(HA)』,只在同一個 Region 內跨不同 AZ 做同步備援,能應對單一 AZ 故障,但整個 Region 級的災難(天災、區域性中斷)會讓所有 AZ 一起失效。真正的災難復原必須『跨 Region』——例如跨區 Read Replica 或 Aurora Global Database。HA、DR、Backup 是三個不同層級的機制,別混用。
05 / 24
一家受法規監管的金融公司要求:所有備份必須跨帳號保存、且一旦寫入就『不可被任何人(含管理員)刪除或竄改』,以符合合規並防範勒索軟體。應採用什麼方案?
A 讓各服務各自分別備份並限制管理權限
B 改用集中備份服務並開啟寫入鎖定
C 只存到單一 S3 儲存桶並開啟版本控制
D 改用 RDS 內建自動備份並延長保留天數
解析
AWS Backup 可集中管理多服務的備份策略,Backup Vault Lock 以 WORM(Write Once Read Many)模式鎖定備份,讓備份在保留期內連 root/管理員也無法刪除或修改,正是合規與防勒索的解法;再搭配跨帳號複製達到隔離。單靠 IAM 政策可被有權限者改動;單一服務的自動備份無法集中管理也無不可變保護。
06 / 24
某公司想把地端資料中心的多台實體/虛擬伺服器(含作業系統與應用)持續複製到 AWS,以便災難時能快速故障轉移(failover)並在雲上啟動。最適合的服務是?
A 用集中備份服務排程
B 用災難復原專用服務
C 用跨區複製物件功能
D 用資料搬遷同步工具
解析
AWS Elastic Disaster Recovery(AWS DRS,前身 CloudEndure Disaster Recovery)對整台伺服器做區塊級(block-level)持續複製到 AWS,災難時可快速將其在雲上啟動並 failover,是伺服器層級 DR 的專用服務。AWS Backup 著重排程式備份而非持續複製與快速轉移;S3 CRR 只複製物件;DataSync 是資料搬遷同步工具,非 DR failover。
07 / 24
一個線上交易平台幾乎無法容忍任何停機或資料遺失(RTO/RPO 近乎為零),預算充足。最符合需求的災難復原策略是?
A Backup Restore 備援
B Pilot Light 指示燈
C Warm Standby 溫備援
D Multi-Site 雙活方案
解析
當 RTO/RPO 要求近乎為零、且預算允許時,Multi-Site Active/Active 是唯一能滿足的策略:兩個 Region 都以完整規模同時運行並服務真實流量,任一區故障時把流量導向存活區即可,切換近乎無感。其餘三種策略都有數分鐘到數小時不等的恢復延遲,無法達到近乎零停機。
08 / 24
一個電商網站評估:災難時停機每分鐘都造成可觀營收損失,需在「數分鐘內」恢復並承接全部流量,預算充足但尚未到需要雙區同時全量服務的程度。最適合的 DR 策略是?
A Warm Standby
B Backup & Restore
C Pilot Light
D 單區 Multi-AZ
解析
Warm Standby 在 DR 區維持一套「完整但縮小規模」的環境持續運行,災難時放大規模即可在數分鐘內承接全部流量,RTO/RPO 皆分鐘級。Backup & Restore / Pilot Light 恢復較慢;Multi-Site 成本更高(需求未到近乎零停機)。
09 / 24
想確保 S3 中的重要資料在「整個 Region 發生災難」時仍有異地副本可用。應?
A 啟用跨區複製到異地區域
B 只在同一區域開版本控制
C 改用單區低頻儲存類別
D 只啟用傳輸加速功能
解析
S3 CRR 自動把物件非同步複製到另一個 Region 的 bucket(需啟用版本控制),提供區域級災難的資料層備援。同區版本控制只防誤刪不防區域災難;One Zone-IA 反而只存單一 AZ。
10 / 24
一個使用 DynamoDB 的全球應用希望「任一 Region 故障時,其他 Region 能立即無縫接手讀寫」。應?
A 改用 DynamoDB 的多區多主動複製表
B 只在單一區域部署並每日執行備份
C 額外加裝 DAX 快取來加速讀取速度
D 只在同一區域內啟用 Multi-AZ 設定
解析
DynamoDB Global Tables 在多個 Region 維持多主動複製,任一區故障時其他區已是可讀寫的最新副本,可立即接手,天生具備跨區韌性。單區備份恢復慢;DAX 是快取;DynamoDB 本就跨 AZ(非跨區)。
11 / 24
主站在 us-east-1,備援站已部署在 us-west-2。想讓「主站故障時使用者流量自動切到備援站」。應?
A 用健康檢查自動切換流量
B 手動修改 DNS 紀錄切換
C 在兩站台間建立對等連線
D 改走專線直接連接兩站
解析
Route 53 Failover 路由搭配 Health Check,會在主端點健康檢查失敗時自動把流量導向備援端點,是把跨區備援『接起來讓使用者無感切換』的關鍵。手動改 DNS 慢且不可靠。
12 / 24
想為 EC2 的 EBS 磁碟資料建立跨 Region 的災難備援,以便異地重建。應?
A 建立快照並跨區複製
B 僅在同一 AZ 保留副本
C 改用暫存儲存空間
D 擴大現有磁碟容量
解析
EBS Snapshot 存於 S3(跨 AZ 耐久),可跨 Region 複製,災難時在異地用快照重建磁碟/AMI,達成跨區資料備援。Instance Store 是臨時的;單 AZ 磁碟無法對抗區域災難。
13 / 24
一個系統每 6 小時做一次備份、沒有其他複製機制。若在兩次備份之間發生災難,其 RPO(可能遺失的資料)大約是?
A 最多約 6 小時的資料
B 幾乎不會遺失資料
C 固定遺失 24 小時資料
D 無法估計遺失多少
解析
RPO 取決於『上一個安全備份點到災難發生』之間的資料量。每 6 小時備份一次,最壞情況(災難剛好發生在下次備份前)會遺失最近約 6 小時的資料,因此 RPO 約 6 小時。要更小 RPO 需更頻繁備份或即時複製。
14 / 24
一個應用只做了 RDS Multi-AZ 與跨 AZ 的 Auto Scaling。若「整個 Region」發生大規模中斷,會如何?如何補強?
A 僅跨 AZ 無法抵禦區域中斷
B 已足應付整個區域中斷
C 架構完全不受任何影響
D 只要多加幾個 AZ 就夠
解析
Multi-AZ 與跨 AZ ASG 提供的是『同一 Region 內』的高可用,無法抵禦整個 Region 的災難。要應對區域級災難需加入跨 Region 的 DR(跨區 Read Replica / Aurora Global DB、S3 CRR、跨區備份等)。
15 / 24
一份重要資料做了 Multi-AZ 高可用部署。若有人「誤刪或遭勒索軟體加密」了這份資料,Multi-AZ 能救回來嗎?
A 不能,須靠時間點備份還原
B 能,副本會保留原始資料
C 能,觸發自動切換即可還原
D 能,本身即等同於備份
解析
高可用(Multi-AZ)是同步/近同步複製,誤刪或加密會一起反映到副本,救不回來。要對抗誤刪/竄改/勒索必須靠『備份』——資料的時間點副本,讓你回到過去某個乾淨狀態。HA 與 Backup 是不同層次。
16 / 24
一個非關鍵的內部工具,可容忍災難時停機一整天、資料掉數小時。團隊卻打算為它建 Multi-Site Active/Active。最適當的建議是?
A 改用較省的備援方案
B 維持雙活較為安全
C 降級為溫備援折衷
D 直接取消所有備援
解析
DR 選型原則是『用剛好滿足 RTO/RPO 的最便宜方案』。此系統需求非常寬鬆(RTO 一天、RPO 數小時),Backup & Restore 就夠且最省;為它上 Multi-Site 是為用不到的復原速度付高昂成本,不划算。
17 / 24
想用「單一集中服務」管理 EBS、RDS、DynamoDB、EFS 的備份,並自動把備份複製到另一個 Region 供 DR。應?
A 設定並開啟跨區複製
B 各服務分別手動備份
C 僅用快照涵蓋全部
D 僅用自動備份涵蓋
解析
AWS Backup 集中管理多種服務的備份策略,並可設定自動跨 Region(與跨帳號)複製備份,一次涵蓋多服務的 DR 需求。逐服務手動備份難以一致管理與確保跨區複製。
18 / 24
關於災難復原計畫,下列哪個實務最重要卻最常被忽略?
A 定期實際演練 DR 流程並驗證
B 只要把復原文件寫好即可
C 等真正災難發生才第一次執行
D 只要備份存在就一定能還原
解析
DR 計畫必須『定期演練』——很多備份在真正需要時才發現無法還原、或恢復時間遠超預期。定期測試故障切換與還原、驗證 RTO/RPO 真能達成並讓團隊熟悉流程,是可靠 DR 的關鍵。
19 / 24
使用 Aurora Global Database 的應用,主 Region 發生故障。關於恢復,何者正確?
A 約 1 分鐘內提升次區為主要
B 須從快照重建,需數小時
C 故障當下資料必定大量遺失
D 此架構無法跨區域恢復
解析
Aurora Global Database 的次要 Region 以極低延遲(通常 <1 秒)複製,主區故障時可在約 1 分鐘內把次區提升為可寫主庫,達成很低的 RTO 與 RPO,優於從快照重建的做法。
20 / 24
採用 Pilot Light 策略時,DR 區「平時」的狀態最符合下列哪一項?
A 核心 DB 持續複製,應用層關閉
B 完整規模環境持續全數運行
C DR 區平時完全沒有任何資源
D 兩區以全規模同時服務流量
解析
Pilot Light 像長明的小火——只讓核心(通常是資料庫)在 DR 區持續複製、隨時待命,應用伺服器平時關閉以省成本,災難時才『點火』啟動應用層並擴展。全量運行是 Warm Standby/Multi-Site;完全沒資源是 Backup & Restore。
21 / 24
工程師設定 S3 跨區複製(CRR)時,系統要求先完成另一項設定才能繼續。這項前提是?
A 兩邊 bucket 都開啟版本控制
B 兩個 bucket 屬於同一帳號
C 來源 bucket 關閉公開存取
D 兩個 bucket 都用 SSE-KMS 加密
解析
S3 Cross-Region Replication 的前提是「來源與目的 bucket 都開啟版本控制(Versioning)」。加密與公開存取設定都不是 CRR 的必要條件;CRR 也可以複製到其他帳號的 bucket。
22 / 24
應用程式使用 RDS for MySQL,想以較低的成本做跨 Region 災難復原:平時資料持續同步到另一區,災難時由人工切換成可寫入的主庫。最直接的做法是?
A 開啟 RDS Multi-AZ
B 建立跨區 Read Replica
C 每週手動匯出資料庫
D 改用 DynamoDB Global Tables
解析
RDS 可以建立跨 Region 的 Read Replica 持續非同步複製,災難時手動 Promote 成獨立的主庫,這正是 Pilot Light 常見的資料庫做法。Multi-AZ 只在同一 Region 內,Region 掛了照樣停擺;每週匯出的 RPO 長達一週;換成 DynamoDB 等於改寫整個應用。
23 / 24
採用 Warm Standby 策略時,DR 區「平時」的狀態最符合下列哪一項?
A 只有備份檔,沒有任何運算資源
B 只有資料庫持續複製,應用層關閉
C 與主區同規模,同時服務真實流量
D 完整但縮小規模的環境一直在跑
解析
Warm Standby 在 DR 區保有一套「完整但縮小規模」的環境持續運行(所有元件都在,只是台數少、規格小),災難時直接放大規模接手流量。只有備份是 Backup & Restore;只有 DB 在同步是 Pilot Light;兩區全規模同時服務是 Multi-Site Active/Active。
24 / 24
需求文件寫著:「系統發生災難後,必須在 15 分鐘內恢復對外服務。」這句話定義的是哪一個指標?
A RPO(復原點目標)
B SLA 的可用性百分比
C RTO(復原時間目標)
D 備份的保留天數
解析
「多久內要恢復服務」講的是停機時間,也就是 RTO(往前看到重新上線)。RPO 衡量的是最多能遺失多少資料(往回看到上一個存檔點)。看到「恢復/停機時間」聯想 RTO,看到「遺失資料」聯想 RPO。

點擊卡片翻面查看答案,共 6 張。

QUESTION
RTO 和 RPO 分別衡量什麼?
點擊翻面
ANSWER
RPO(復原點目標)→ 最多能掉多少『資料』,往回看到上次備份點
RTO(復原時間目標)→ 最多能停機多久,往前看到恢復上線
兩者都是『越小=要求越高=越貴』
點擊翻回
QUESTION
四種 DR 策略由便宜到貴的順序與復原速度?
點擊翻面
ANSWER
① Backup & Restore(最便宜,數小時)
② Pilot Light(核心 DB 待命,應用關閉)
③ Warm Standby(縮小版全套持續運行)
④ Multi-Site Active/Active(雙活,最貴,秒級近乎零停機)
越往下越貴、RTO/RPO 越短
點擊翻回
QUESTION
Pilot Light 和 Warm Standby 的關鍵差異?
點擊翻面
ANSWER
Pilot Light:DR 區只有『核心資料庫』在跑,應用伺服器平時關閉 → 較省,RTO 較長
Warm Standby:整套元件都在跑,只是『縮小規模』,災難時放大即可 → 較貴,RTO 較短
點擊翻回
QUESTION
HA、DR、Backup 三者分別對抗什麼?
點擊翻面
ANSWER
HA(高可用)→ 跨 AZ,防單一 AZ 故障(同一 Region)
DR(災難復原)→ 跨 Region,防區域級災難
Backup(備份)→ 時間點副本,防資料被誤刪/竄改/勒索
點擊翻回
QUESTION
RDS Multi-AZ 能當災難復原(DR)方案嗎?
點擊翻面
ANSWER
不能。Multi-AZ 只在『同一個 Region』跨 AZ,是高可用(HA),整個 Region 掛掉照樣中斷。
跨 Region DR 要用:跨區 Read Replica 或 Aurora Global Database。
點擊翻回
QUESTION
AWS Backup 的核心價值與 Vault Lock 作用?
點擊翻面
ANSWER
集中管理多服務(EC2/EBS/RDS/DynamoDB/EFS…)備份,單一策略、可跨區/跨帳號複製。
Backup Vault Lock(WORM)→ 備份一旦寫入不可刪改,連管理員也不行,用於合規與防勒索。
點擊翻回