AWS 的高可用性設計以可用區域作為主要故障域。可用區域是具備獨立電力、冷卻與網路的實體隔離設施，因此將相同的運算執行個體部署在兩個或多個可用區域，代表任何單一設施的停電都不會讓整個服務層停擺。Application Load Balancer 具備可用區域感知能力，會對每個已註冊的目標執行健康檢查，並自動停止將流量路由至不健康可用區域中的目標。將執行個體群納入 EC2 Auto Scaling group 後，即使某個執行個體甚至整個可用區域故障，替換容量也會在健康的可用區域中自動啟動，以維持預設數量。由於應用程式本身已是無狀態，此模式完全不需要修改程式碼，只需調整基礎架構。Multi-AZ 搭配 ALB 與 Auto Scaling group 的組合，正是 AWS Well-Architected 可靠性支柱中針對無狀態 Web 層所描述的參考架構。

白話文解釋

想像一家只有一個廚房的披薩連鎖店。那個廚房的烤箱一旦壞掉，所有訂單都得等到有人趕去修好才能繼續。若在不同街區開設第二間廚房，並配備一套聰明的派單系統，將每筆訂單分派給當下正常運作的廚房，就能把一間脆弱的店面變成具備韌性的作業。ALB 就是那套派單系統，Auto Scaling group 是連鎖店經理——當某間廚房關閉時，他會立刻在別處開設替補廚房——而可用區域則是各個獨立的街區。顧客永遠不會察覺是哪間廚房做出他們的披薩。

選項分析

A：錯誤。升級到同一可用區域中更大的執行個體會讓網站跑得更快，但對可用區域停電毫無幫助——故障域完全沒有改變。
B：正確。Multi-AZ 部署搭配 ALB 與 Auto Scaling group，是無狀態 Web 應用程式的 AWS 高可用性標準模式。
C：錯誤。快照與備用 AMI 可加速復原，但仍需人工或流水線重建並重新掛載，代表仍有可測量的停機時間——這是備份與還原的災難復原方案，而非高可用性。
D：錯誤。同一可用區域的兩個執行個體共享電力、冷卻與網路；可用區域事件會同時讓兩者下線。Route 53 輪詢同樣因 DNS TTL 快取而導致客戶端容錯移轉延遲。