這些題目為學習目的而獨立製作，並非 AWS 官方考題、實際考題、外流題或考題庫。
SAA-038
對於在東京區域運作的 Web 應用程式,希望在發生區域規模的故障時自動切換至大阪區域的待命環境。使用者所使用的網域名稱不可變更。下列哪項架構最為合適?
選項
解析與正確答案
閱讀解析與正確答案（劇透：建議先自行作答）
正確答案：C. 以 Route 53 的容錯移轉路由政策將東京設為主要、大阪設為次要,並為主要記錄關聯健康檢查
解析
若要在維持相同網域名稱的情況下於區域間自動切換,應結合 Route 53 的容錯移轉路由政策與健康檢查。當主要的健康檢查失敗時,DNS 回應會自動切換至次要的端點。
各選項解析
A. 建立橫跨東京與大阪的 Auto Scaling 群組,於東京端異常時在大阪啟動執行個體
Auto Scaling 群組雖可橫跨單一區域內的多個可用區域,但無法橫跨區域。
B. 以 Route 53 的加權路由將東京設為權重 100、大阪設為權重 0,偵測到故障時手動對調權重
加權路由本身雖為有效功能,但既然權重的變更為手動,便不符合「自動切換」的需求。從故障偵測到切換的時間也取決於人員的反應速度。
C. 以 Route 53 的容錯移轉路由政策將東京設為主要、大阪設為次要,並為主要記錄關聯健康檢查
正解。可藉由健康檢查的失敗次數與間隔調整切換速度,並將 DNS 記錄的 TTL 設得較短以加快生效。
D. 在 Application Load Balancer 的目標群組中同時註冊東京與大阪的 EC2 執行個體,並以健康檢查分流
Application Load Balancer 本身就是東京區域內的資源,因此東京發生區域規模的故障時 ALB 也會一併無法使用,不構成跨區域的切換。若使用 IP 位址類型的目標群組搭配跨區域 VPC 對等互連,確實可以將其他區域的執行個體註冊為目標(執行個體 ID 類型的目標則僅限於負載平衡器所在的 VPC),但 ALB 依賴單一區域這一點並未改變。
實際使用情境
Amazon Route 53 的路由政策依用途區分。簡易路由僅回傳單一目的地;加權路由依指定比例分配流量(用於金絲雀發布或分階段移轉);延遲型路由回傳從用戶端來看延遲最小的區域;地理位置路由依來源的地理位置回傳;容錯移轉路由則定義主要 / 次要兩套系統,僅在主要異常時回傳次要。主動 / 被動型的災難復原架構即對應容錯移轉路由。 自動切換的關鍵在於 Route 53 健康檢查。健康檢查會由世界各地的檢查點定期對目標端點(IP 或網域名稱)發送請求,預設以 30 秒間隔(快速模式則為 10 秒間隔)在失敗次數超過閾值時判定為 Unhealthy。此外,也有以 CloudWatch 警示狀態作為健康檢查的方式,以及將多個健康檢查以 AND / OR 結合的計算型健康檢查。由於切換是以 DNS 回應的變化呈現,實際的切換速度取決於「健康檢查的偵測時間 + 記錄的 TTL + 用戶端解析器的快取」。將 TTL 縮短至 60 秒左右為慣例做法;若需要更快的切換,則應考慮如 AWS Global Accelerator 這類不依賴 DNS 的方式。 SAA-C03 中,「區域故障時自動容錯移轉至其他區域」「希望以相同網域名稱切換」等需求下,容錯移轉路由 + 健康檢查即為正解。誤答則排列出跨區域使用 ALB 或 Auto Scaling 群組的架構,但兩者皆可憑「屬於區域內服務」的知識排除。加權路由則須判讀出其「手動」的性質與需求不符。