高可用性與 Multi-AZ 設計

高可用性與 Multi-AZ 設計是所有希望在 AWS 上抵禦資料中心故障的正式環境工作負載的骨幹。備考 SAA-C03 時，你必須能夠看到任何情境題，立刻判斷哪些 AWS 服務的組合能達到指定的可用性目標——無論是部署在 Application Load Balancer 後方的無狀態 Web 層、跨三個 Availability Zone 延伸的 EC2 Auto Scaling Group、RDS Multi-AZ 備援節點、具備跨 AZ 副本的 Aurora 叢集，還是 Route 53 健康檢查驅動的 DNS 故障轉移（failover）。解決方案架構師的成敗繫於高可用性與 Multi-AZ 設計，因為 Domain 2 近半數的題目都在考你能否在不過度支出的前提下消除單點故障（SPOF）。

本頁隸屬 Domain 2（設計具彈性的架構），Task Statement 2.2，聚焦於單一 AWS Region 內的高可用性與 Multi-AZ 設計。跨 Region 的災難復原——RTO／RPO 目標、Pilot Light、Warm Standby、Active-Active——屬於姊妹主題 disaster-recovery-strategies。Aurora 或 DynamoDB DAX 的原始資料庫效能特性，請參閱 high-performing-database-solutions。CloudFront 與 Global Accelerator 的 API 前門模式，請參閱 api-gateway-and-edge。

什麼是高可用性與 Multi-AZ 設計？

AWS 上的高可用性與 Multi-AZ 設計，意指以下列方式架構工作負載：任何單一元件的故障——一台實例、一個機架、整個資料中心，甚至整個 Availability Zone——都不會使系統離線。典型的高可用性與 Multi-AZ 設計模式是：在兩個或三個 Availability Zone 中分別部署每一層的冗餘副本，在前端放置能偵測不健康端點的負載平衡器或 DNS 路由器，並使用能跨 AZ 自動複製狀態的受管服務（RDS Multi-AZ、Aurora、DynamoDB、EFS）。

高可用性（HA）與容錯（FT）相關但不相同。HA 以正常運行時間百分比為目標——例如 99.95%——並允許故障轉移期間發生短暫中斷（數秒至數分鐘）。FT 更嚴格：即使在元件故障期間，系統也必須在不讓使用者察覺中斷的情況下繼續服務。Multi-AZ RDS 屬於 HA（故障轉移 60–120 秒）。Aurora 將跨 AZ 副本晉升為寫入節點也屬於 HA。DynamoDB 更接近 FT，因為它原生具備多 AZ 特性，沒有可見的故障轉移事件。真正的 FT 通常需要應用程式層的冗餘設計，而不僅僅是基礎設施層面。

高可用性與 Multi-AZ 設計為何對 SAA-C03 至關重要

高可用性與 Multi-AZ 設計在 SAA-C03 考試中以三種反覆出現的形式呈現：

1. 消除 SPOF — 「某公司將 Web 應用程式運行於單一 EC2 實例，並在單一 AZ 中使用 RDS 資料庫。哪些架構變更能以最少的程式碼修改提供最高的可用性？」
2. 服務選擇 — 「應用程式需要毫秒以下的故障轉移且不重置 TCP 連線。應選 ALB 還是 NLB？」
3. 陷阱題 — 將 Multi-AZ RDS（HA）與 Read Replica（讀取擴展）對立，或將 ALB（Layer 7）與 NLB（Layer 4）對立，或考察跨 AZ 負載平衡的開啟與關閉。

高可用性與 Multi-AZ 設計的四大支柱

SAA-C03 所有 HA 題目都可以歸結為四大支柱。請將這四點刻入肌肉記憶。

1. 冗餘 — 每一個可能故障的元件都有兩份以上：AZ、實例、NAT Gateway、負載平衡器節點、資料庫副本。
2. 健康偵測 — ELB 目標健康檢查、Route 53 健康檢查、Auto Scaling 健康檢查、RDS Multi-AZ 心跳。
3. 自動故障轉移 — 無需人工介入。RDS Multi-AZ DNS 切換、Auto Scaling 替換實例、Route 53 DNS 故障轉移、ALB 分區切換（zonal shift）。
4. 無狀態應用程式層 — 使任何替換實例都能為任何使用者工作階段提供服務，無需重播先前的狀態。

白話文解釋 High Availability and Multi-AZ Design

High Availability and Multi-AZ Design 聽起來像一長串專有名詞，其實它的核心精神就是「把所有會壞的零件都準備兩份以上，放在不同的房間，壞了會自動切換」。下面用三個生活化類比，把 High Availability and Multi-AZ Design 講到透。

類比一：熱炒店廚房與雙主廚（Multi-AZ 與 Load Balancer）

想像你開一家 24 小時營業的連鎖熱炒店。

• 一個廚房配一位主廚 = 單一 EC2 + 單一 AZ。主廚請假，餐廳就關門。這就是 single point of failure。
• 同一個廚房配兩位主廚 = 同 AZ 雙 EC2。好一點，但如果廚房失火、停電、淹水，兩位主廚都無法工作。
• 兩個獨立廚房、各配一位主廚 = 跨 AZ 的 EC2。其中一間廚房出事，另一間繼續出餐。這就是 Multi-AZ。
• 門口站一位「帶位員」幫你決定去哪個廚房 = Application Load Balancer。帶位員會一直敲門確認哪間廚房還在運作（health check），壞掉的那間就不再送客人過去。
• 餐廳老闆同時租下第三間廚房備用 = 三 AZ 的 Auto Scaling Group。客流量突然暴漲，老闆就臨時召回三間廚房的兼職廚師；客流量低，就讓兼職廚師下班，節省薪水。這就是 Auto Scaling。

這個類比直接回答了 High Availability and Multi-AZ Design 幾個核心問題：為什麼要多 AZ？因為不同廚房不會一起失火。為什麼要 Load Balancer？因為客人不會自己知道哪間廚房還開著。為什麼要 Auto Scaling？因為人力成本昂貴，按需求伸縮最划算。

類比二：雙線道高速公路與備用車道（RDS Multi-AZ vs Read Replica）

把資料庫想成高速公路。

• RDS Multi-AZ 就像車道旁邊永遠有一條「備用車道」，平時封閉不開放。主車道塌方時，交通管制立刻把車流切到備用車道。備用車道的寬度與主車道完全一樣（同步複製），切換大約 60–120 秒，乘客會感覺到塞一下下，但車行不會中斷太久。備用車道不接受任何車流（不處理讀取）——它只是等著接手。
• RDS Read Replica 則像在主車道旁邊另開一條「慢車道」，專門讓低速車輛使用（讀取流量）。這條慢車道不能接收寫入，也不會自動變成主車道——它是用來分流，不是用來救命。
• Aurora DB Cluster 更高級：一條主車道加上最多 15 條「即時同步的副車道」，所有副車道都看得到最新的路況，主車道塌方時，任何一條副車道都可以立刻升格成主車道，升格時間通常只要 30 秒左右。

這個類比一錘定音兩個最常混淆的考點：Multi-AZ 是HA（備胎），Read Replica 是scaling（分流）。Aurora 則是把兩者揉在一起。

類比三：電話總機與 DNS 導航（Route 53 Failover Routing）

Route 53 的 health check 與 failover routing 可以想成大型公司的電話總機。

• 客戶打電話進來 = DNS query。
• 總機人員查一張「分機對照表」 = Route 53 routing policy。
• 每 10 秒打一次內線確認每個部門還在上班 = Route 53 health check。
• 發現台北辦公室沒人接電話，總機立刻把電話轉到高雄辦公室 = failover routing。
• 如果是「誰比較近就轉給誰」= latency routing。
• 如果是「70% 轉台北、30% 轉台中」= weighted routing（常用於藍綠部署）。
• 如果是「每次都給你一組隨機的 8 個分機，你自己挑一個」= multi-value answer routing，比 simple routing 多了健康檢查。

三個類比反覆強調同一件事：高可用性與 Multi-AZ 設計的精髓不是「不壞」，而是「壞了有人接手，而且接手速度快到使用者不覺得」。把 AWS 的每一個服務放進這個框架，你就不會在考場上猶豫。

AWS 全球基礎設施 — Region、AZ 與 Local Zone 的 HA 意涵

所有高可用性與 Multi-AZ 設計都從 AWS 全球基礎設施的部署規模開始。不了解 AZ 模型就無法設計 Multi-AZ，不了解 Region 模型就無法設計跨 Region 的 DR。

AZ 是原子級別的故障隔離單位

AWS Availability Zone 是一個或多個具備獨立電力、冷卻、實體安全及網路架構的實體隔離資料中心，與其他 AZ 之間有相當的實體距離（通常數十公里），但透過 AWS 自有的低延遲光纖相互連接。AZ 之間的同步複製是可行的——來回延遲通常在毫秒以下——這正是 RDS Multi-AZ、Aurora 和 EFS 能在不明顯影響寫入延遲的情況下跨 AZ 複製資料的原因。

在高可用性與 Multi-AZ 設計中，每個 AWS Region 至少保證擁有 三個 AZ。這個三 AZ 最低要求，使你能在整個 AZ 中斷的情況下，靠剩餘兩個 AZ 維持法定人數（quorum）——這對 Aurora 等資料庫尤其重要，Aurora 在三個 AZ 中採用 4-of-6 的寫入法定人數。

Local Zone 與 Outposts 讓 HA 更靠近使用者

高可用性與 Multi-AZ 設計通常止於 Region 內的 AZ 邊界，但 AWS 提供了延伸選項：

• Local Zone — 父 Region 的都會區延伸，適用於需要對特定城市使用者提供個位數毫秒延遲的情境。Local Zone 並非完整的 AZ HA 替代品——它是單一故障域。
• AWS Outposts — AWS 在你的場所管理的硬體。適用於邊緣工作負載，但同樣不應計入 HA 的 AZ 數量。

要實現真正的 HA，請跨越兩個或三個 Region 內的 AZ。將 Local Zone 和 Outposts 視為延遲工具，而非可用性工具。

Multi-AZ 部署模式 — EC2、RDS、ElastiCache、EFS

「Multi-AZ 部署」並非單一模式，而是一系列針對各服務的模式。SAA-C03 考試要求你了解每項主要服務如何實現 Multi-AZ。

透過 Auto Scaling Group 實現 EC2 Multi-AZ

純 EC2 不會複製任何東西。若要為 EC2 實現 Multi-AZ，需將實例放入 Auto Scaling Group，並在該 ASG 中設定包含兩個或三個 AZ 的子網路，再在前端放置負載平衡器（ALB 或 NLB）。ASG 會自動在 AZ 之間重新平衡實例。若某個 AZ 中斷，ASG 會在存活的 AZ 中啟動替換實例。

RDS Multi-AZ — 同步備援節點

RDS Multi-AZ 實例部署會在一個 AZ 中建立主要節點，在另一個 AZ 中建立同步備援節點。寫入資料同步複製至備援節點。備援節點不可讀取，不處理流量——它只在故障轉移時接手。故障轉移由主機故障、AZ 故障、儲存故障或手動重新啟動（含故障轉移選項）觸發，通常透過 DNS CNAME 切換在 60–120 秒內完成。

RDS Multi-AZ 也支援較新的 Multi-AZ DB 叢集部署（適用於 MySQL 和 PostgreSQL），使用兩個額外 AZ 中的可讀備援節點，故障轉移通常在 35 秒以內。

Aurora Multi-AZ — 分散式儲存層

Aurora 將運算與儲存解耦。Aurora DB 叢集的儲存磁碟區預設在三個 AZ 中複製六份，採用 4-of-6 寫入法定人數和 3-of-6 讀取法定人數。運算節點（寫入節點 + 最多 15 個讀取節點）可放置於任意 AZ，故障轉移時將讀取節點晉升為寫入節點，通常在 30 秒以內。

ElastiCache Multi-AZ

當你在複製群組中至少有一個位於不同 AZ 的副本，並啟用 Multi-AZ 時，ElastiCache Redis 支援自動故障轉移的 Multi-AZ。Memcached 不支援跨 AZ 複製——它只支援分片節點的自動探索。

EFS 預設即 Multi-AZ

Amazon EFS Standard 預設在 Region 的多個 AZ 中冗餘儲存檔案。你只需透過每個 AZ 的掛載目標，從任意 AZ 的實例掛載檔案系統。無需設定——EFS 開箱即具備 Multi-AZ 特性。EFS One Zone 是較便宜的單一 AZ 層級，並非 Multi-AZ。

Elastic Load Balancing — ALB vs NLB vs GWLB vs CLB

Elastic Load Balancing 是幾乎所有高可用性與 Multi-AZ 設計的前門。SAA-C03 要求你在四種 ELB 類型之間做出選擇，請將決策樹刻入肌肉記憶。

Application Load Balancer（ALB）— Layer 7

ALB 在 HTTP／HTTPS（Layer 7）層運作。它能檢查路徑、Host Header、查詢字串、Cookie 和 HTTP 方法來路由流量。目標類型包含實例、IP、Lambda 函式和其他 ALB。

ALB 主要功能：

• 基於主機和路徑的路由 — 將 /api/* 路由至一個目標群組，將 /static/* 路由至另一個。
• 原生 HTTPS 和 TLS 終止，搭配 ACM。
• WebSocket 和 HTTP/2 支援。
• Sticky Session（基於應用程式或持續時間的 Cookie）。
• 每個目標群組的目標健康檢查。
• 與 AWS WAF 整合，提供 Layer 7 保護。
• Lambda 作為目標，用於無伺服器 HTTP API。

當工作負載為 HTTP／HTTPS 且需要智慧路由時，使用 ALB。

Network Load Balancer（NLB）— Layer 4

NLB 在 TCP／UDP／TLS（Layer 4）層運作。它專為極致效能而生——每秒數百萬請求、超低延遲，以及每個 AZ 的靜態 IP 位址（加上可選的 Elastic IP）。

NLB 主要功能：

• 每個 AZ 的靜態 IP — 適用於以 IP 進行白名單管理。
• 預設保留來源 IP（無需 X-Forwarded-For）。
• NLB 的 TLS 終止（PassThrough 或 Terminated 模式）。
• UDP 支援 — 唯一支援 UDP 的 ELB，適用於遊戲、VoIP、SIP 和 DNS 工作負載。
• 毫秒以下的延遲。

當需要原始 TCP／UDP 效能、靜態 IP 或 UDP 協定支援時，使用 NLB。

Gateway Load Balancer（GWLB）— Layer 3

Gateway Load Balancer 在 IP（Layer 3）層運作，專為部署、擴展和管理第三方虛擬網路設備而設計，例如防火牆、入侵偵測系統和深度封包檢測工具。GWLB 使用連接埠 6081 上的 GENEVE 協定，以透明方式透過設備群組傳輸流量。

GWLB 僅用於網路安全設備插入模式，並非通用應用程式負載平衡器。

Classic Load Balancer（CLB）— 舊版

CLB 是 2009 年最初的 ELB，支援 Layer 4 和基本 Layer 7，適用於 EC2-Classic 和簡單使用案例。AWS 現在將其視為舊版服務，並建議所有新工作負載使用 ALB 或 NLB。CLB 確實出現在 SAA-C03 考試中，但通常作為干擾選項——很少是正確答案。

Target Group（目標群組）

所有現代 ELB 皆路由至目標群組，而非直接路由至目標。目標群組是具備共用健康檢查設定的邏輯目標集合。單一 ALB 可根據規則路由至多個目標群組。單一目標群組可跨多個監聽器共用。

目標類型：

• Instance — 以 EC2 實例 ID 登錄。Auto Scaling 可自動管理登錄。
• IP — 登錄任意 IP，包括透過 Direct Connect 或 VPC 對等連接的內部部署 IP。
• Lambda（僅限 ALB）— 每次請求呼叫一個 Lambda 函式。
• ALB 作為目標（僅限 NLB）— 在 ALB 前方放置 NLB，同時獲得靜態 IP 與 Layer 7 路由。

健康檢查

每個 ELB 會持續探測其目標。可設定的參數：協定（HTTP／HTTPS／TCP）、路徑、連接埠、健康閾值、不健康閾值、逾時、間隔、成功代碼。目標連續失敗 N 次後被標記為不健康並從輪詢中移除；連續成功 N 次後再次標記為健康。

跨 AZ 負載平衡

若未啟用跨 AZ 負載平衡，每個 AZ 本地的 ELB 節點只會將流量分配至其所在 AZ 的目標。啟用跨 AZ 負載平衡後，每個節點會將流量分配至所有 AZ 的目標。

• ALB — 跨 AZ 負載平衡永遠開啟且免費。
• NLB — 跨 AZ 預設關閉，啟用時會產生跨 AZ 資料傳輸費用。
• GWLB — 跨 AZ 預設關閉。
• CLB — 跨 AZ 預設關閉。

EC2 Auto Scaling Group — Launch Template、策略與 Hook

Auto Scaling Group（ASG）是 AWS 在高可用性與 Multi-AZ 設計中維持 EC2 叢集存活且規模適當的機制。請掌握五個關鍵元件。

Launch Template vs Launch Configuration

ASG 需要新實例的藍圖。有兩個選項，但只有一個是推薦的。

• Launch Template — 現代化、有版本控制的藍圖。支援所有 EC2 功能（Spot 混合、T2／T3 Unlimited、Nitro Enclave、容量預留、每個 ASG 多種實例類型）。請使用 Launch Template。
• Launch Configuration — 舊版、無版本控制的藍圖。仍受支援，但缺乏較新功能。AWS 建議遷移離開。

Launch Template 有版本（$LATEST、$DEFAULT 或特定編號），可讓你前進和回滾 AMI 更新。

擴展策略類型

ASG 透過一個或多個擴展策略回應負載。SAA-C03 考試涵蓋四種類型。

Target Tracking Scaling（目標追蹤擴展）

你指定一個目標指標值——例如「保持平均 CPU 在 50%」——Auto Scaling 自動計算達到該目標所需的實例數。它在背後建立 CloudWatch 警示。目標追蹤是大多數工作負載的預設推薦，因為它最容易理解。

Step Scaling（步進式擴展）

基於具有多個步驟的 CloudWatch 警示。例如：「若 CPU > 70%，增加 1 台實例；若 CPU > 85%，增加 3 台；若 CPU > 95%，增加 5 台。」對於流量尖峰工作負載，比目標追蹤更具反應性，且可控制每個觸發層級的擴展幅度。

Simple Scaling（簡單擴展）

一個 CloudWatch 警示觸發一次擴展調整。調整後，冷卻期會阻止進一步的擴展動作，直到冷卻期到期。這是最舊的形式，通常已被步進式擴展取代。

Predictive Scaling（預測性擴展）

使用機器學習根據歷史 CloudWatch 資料（至少 24 小時的資料，最好 14 天）預測流量。它在預期需求之前主動啟動容量，避免被動擴展固有的滯後。預測性擴展最適合具有每日或每週季節性規律的工作負載（例如午餐時段流量尖峰的零售網站）。

Scheduled Scaling（排程擴展）

按照類似 cron 的排程進行擴展。例如：「工作日 09:00 時，將期望容量設為 20；19:00 時，設為 5。」適用於你已知模式，而非讓 Auto Scaling 自行學習的情境。

Lifecycle Hook（生命週期 Hook）

Lifecycle Hook 讓你能在實例啟動或終止轉換期間暫停實例，以便執行自訂動作。有兩種 Hook 類型：

• autoscaling:EC2_INSTANCE_LAUNCHING — 在實例啟動後、投入服務前暫停。用於安裝軟體、執行初始化指令碼或預熱快取。
• autoscaling:EC2_INSTANCE_TERMINATING — 在終止前暫停。用於耗盡連線、上傳最終日誌或完成進行中的交易。

Hook 預設最長暫停實例 48 小時，使其進入 Pending:Wait 或 Terminating:Wait 狀態。你的指令碼呼叫 complete-lifecycle-action 以釋放 Hook（或呼叫 record-lifecycle-action-heartbeat 以延長逾時）。

健康檢查與實例替換

ASG 透過兩個信號檢查每個實例：

• EC2 狀態檢查 — 預設健康來源；實例失敗 → 被替換。
• ELB 健康檢查 — 透過 health-check-type ELB 選擇啟用；若實例未通過 ELB 目標健康檢查，即使 EC2 狀態仍正常，ASG 也會替換該實例。這對於確保應用程式當機（行程卡住但 OS 正常）時實例能被替換至關重要。

結合 EC2 和 ELB 健康檢查，以實現穩健的高可用性與 Multi-AZ 設計。

AZ 平衡與重新平衡

ASG 自動在其設定的 AZ 之間平衡實例。若某個 AZ 暫時無法啟動容量（例如容量不足），ASG 會集中在其他 AZ，並在容量恢復後重新平衡。

Warm Pool（暖機池）

Warm Pool 是一組保持 Stopped 狀態的預初始化實例。當發生橫向擴展時，ASG 將暖機實例晉升至 InService，而非從頭啟動——將啟動時間從數分鐘縮短至數秒。適用於 AMI 開機時間較長的工作負載。

RDS Multi-AZ vs Read Replica — 最常考的區別

這是整個 SAA-C03 高可用性與 Multi-AZ 設計主題中最常被考到的界線。請精確記憶。

RDS Multi-AZ — 用於可用性

• 目的 — 在 AZ 層級故障中存活。
• 複製 — 從主要節點到備援節點同步複製。
• 可讀性 — 備援節點不可由應用程式讀取。它只在接管時使用。
• 故障轉移 — 在主要節點故障、主機問題、網路隔離或手動重新啟動（含故障轉移）時，透過 DNS CNAME 切換自動執行。
• 故障轉移時間 — 單一備援節點部署 60–120 秒；具有兩個可讀備援節點的 Multi-AZ DB 叢集約 35 秒。
• 成本 — 大約是單一 AZ 價格的兩倍（你需為備援節點的運算和儲存付費）。
• 備援節點位置 — 同一 Region，不同 AZ。非跨 Region。

RDS Read Replica — 用於讀取擴展

• 目的 — 減輕主要節點的讀取密集工作負載。
• 複製 — 非同步，因此副本可能稍微落後於主要節點。
• 可讀性 — 是的，應用程式連接至副本執行 SELECT 查詢。每個副本有獨立的端點。
• 故障轉移 — 無自動故障轉移。你可以手動晉升副本成為獨立的主要節點（這會中斷複製連結）。
• 跨 Region — Read Replica 可位於不同 Region（MySQL、MariaDB、PostgreSQL、Oracle）。Multi-AZ 備援節點則不行。
• 數量 — 每個來源 RDS 實例最多 5 個 Read Replica（Aurora 最多 15 個，跨 AZ 和 Region）。

可以同時使用兩者嗎？

可以。常見的高可用性與 Multi-AZ 設計模式是：AZ-a 中的主要節點（啟用 Multi-AZ，因此在 AZ-b 中有同步備援節點），加上兩個非同步 Read Replica——一個在 AZ-c，一個在不同 Region 用於跨 Region 的 DR。你同時獲得 HA 和讀取擴展。

Amazon Aurora DB Cluster — 儲存與運算分離

Aurora 是 AWS 專為雲端打造的原生關聯式資料庫引擎，相容於 MySQL 和 PostgreSQL。它透過將運算與儲存解耦，改變了高可用性與 Multi-AZ 設計的格局。

Aurora 儲存架構

• 儲存磁碟區 — 單一分散式磁碟區，以 10 GB 為單位自動擴展，最大 128 TB。
• 跨三個 AZ 的六個副本 — 每個 AZ 兩個副本。
• 寫入法定人數 — 6 個副本中的 4 個必須確認寫入。
• 讀取法定人數 — 至少 3 個副本可用才能提供讀取服務。
• 自我修復 — Aurora 持續掃描資料區塊，使用其他副本修復任何校驗碼失敗的區塊。

此架構讓 Aurora 能夠在不損失資料且不中斷寫入路徑的情況下，容忍整個 AZ 的遺失（六個副本中的兩個）。

Aurora 運算架構

• 寫入實例 — 一個主要 DB 實例。
• 讀取實例 — 最多 15 個 Aurora 副本，全部從同一個共用儲存磁碟區讀取，複製延遲通常在 100 毫秒以內。
• 故障轉移 — 當寫入節點故障時，Aurora 將讀取節點晉升為寫入節點。典型故障轉移時間在 30 秒以內，若目標 AZ 已有讀取節點，速度可更快。
• 讀取端點 — 單一 DNS 名稱，對所有讀取實例進行負載平衡。

Aurora Serverless v2

Aurora Serverless v2 以細粒度增量（ACU）在 0.5 至 128 ACU 之間自動擴展運算，在數秒內完成調整。非常適合流量不可預測、存取頻率低或開發／測試環境的工作負載。仍提供相同的 Multi-AZ 儲存保證。

Aurora Global Database

對於跨 Region 的 HA，Aurora Global Database 可將一個主要 Region 的資料複製至最多 5 個次要 Region，典型複製延遲在 1 秒以內。託管故障轉移的 RTO 以分鐘計，非計畫性故障轉移則在 1 分鐘以內。這是 AWS 上關聯式資料庫最強大的跨 Region DR 選項，詳細說明請參閱 disaster-recovery-strategies 主題。

Aurora vs RDS — 如何選擇

選擇 Aurora 的情境：

• 更快的故障轉移（30 秒以內 vs RDS Multi-AZ 的 60–120 秒）。
• 更多 Read Replica（15 個 vs 5 個）。
• 無需容量規劃的自動擴展儲存。
• 更佳的效能——Aurora MySQL 通常標榜比標準 MySQL 快 ~5 倍；PostgreSQL 快 ~3 倍。
• 透過 Global Database 實現跨 Region DR。

選擇 RDS（非 Aurora）的情境：

• 需要 Aurora 不支援的引擎（SQL Server、Oracle、MariaDB）。
• 小型工作負載的較低成本。
• 更簡單的運維模型。

RDS Proxy — 無伺服器工作負載的連線池

Lambda 函式和無伺服器應用程式在每次呼叫時建立新的資料庫連線。在高並發下，這會使 RDS 不堪重負，因為每個連線都消耗主要節點的記憶體和 CPU。RDS Proxy 位於客戶端和資料庫之間，維護長期存活的資料庫連線池，並將傳入的客戶端連線多路復用至這些連線上。

RDS Proxy 提供的功能

• 連線池 — 大幅降低高並發客戶端對主要資料庫的負載。
• 更快的故障轉移 — 在 RDS Multi-AZ 故障轉移期間，RDS Proxy 可以將故障轉移時間縮短高達 66%，因為它代表客戶端吸收了 DNS 切換。
• IAM 驗證 — Proxy 可強制執行基於 IAM 的 DB 驗證。
• Secrets Manager 整合 — 憑證自動儲存和輪換。

每當 Lambda 或其他高並發客戶端連接至 RDS／Aurora 時，請使用 RDS Proxy。這是高可用性與 Multi-AZ 設計的最佳實踐，而不僅僅是效能工具。

DynamoDB Multi-AZ 與 Global Tables

Amazon DynamoDB 在 Region 內原生具備 Multi-AZ 特性。你無需設定 Multi-AZ——每個 DynamoDB 資料表的寫入都會同步複製至三個 AZ 的三份副本，讀取預設為最終一致性，但可依需求升級為強一致性讀取。

DynamoDB Global Tables — 多 Region Active-Active

Global Tables 將 DynamoDB 資料表複製至多個 Region，所有 Region 均可寫入（Active-Active 多主節點）。複製為非同步，典型延遲在 1 秒以內。當兩個 Region 同時寫入同一個項目時，使用最後寫入者勝（last-writer-wins）衝突解決。

Global Tables 的使用場景：

• 需要從每個 Region 低延遲寫入的全球分散式應用程式。
• 關鍵工作階段或元數據儲存的災難復原。
• 需要資料存在於多個司法管轄區的合規設定。

DynamoDB Global Tables 是高可用性與 Multi-AZ 設計工具箱中，Aurora Global Database 的 NoSQL 對應方案。

Route 53 — 健康檢查與 Failover 路由

Route 53 是串聯一切的 DNS 前門。它在 ELB 層之上增加可用性，將流量引導離開故障的端點或整個 Region。

Route 53 健康檢查

Route 53 健康檢查會持續探測端點（公開 IP、ALB 或任何 URL），或評估其他健康檢查的狀態（計算型健康檢查），或評估 CloudWatch 警示。三種類型：

1. 端點健康檢查 — 直接透過 TCP、HTTP 或 HTTPS 探測 IP 或網域。間隔 30 秒（標準）或 10 秒（快速）。健康狀態由連續 N 次成功或失敗決定。
2. 計算型健康檢查 — 子健康檢查的布林組合（例如「端點 A 健康且至少 3 個子健康檢查中有 2 個通過」）。
3. CloudWatch 警示健康檢查 — 將 CloudWatch 警示狀態作為信號。適用於無法透過探測確定健康狀態的情況（例如內部佇列深度）。

Route 53 路由策略

七種路由策略驅動故障轉移和流量導向。對於 SAA-C03，五種是考試關鍵。

Simple Routing（簡單路由）

一筆記錄指向一個或多個值（無健康檢查、無智慧）。若返回多個 IP，由客戶端選擇一個。

Failover Routing（故障轉移路由）

主要和次要記錄，各自關聯一個健康檢查。Route 53 在主要記錄健康時返回主要記錄，不健康時故障轉移至次要記錄。經典的主動-被動 DR 模式。

Latency Routing（延遲路由）

返回對查詢解析器具有最低測量網路延遲的記錄。非常適合多 Region Active-Active，讓使用者由最近的 Region 提供服務。

Weighted Routing（加權路由）

按可設定的權重分配流量——例如 Production 和 Canary 之間的 90/10 分配。用於藍綠部署和 A/B 測試。可與健康檢查結合使用，使權重為零的記錄自動被跳過。

Geolocation Routing（地理位置路由）

根據 DNS 解析器的地理位置返回記錄。用於內容本地化或合規（例如歐盟使用者只能訪問歐盟 Region）。

Geoproximity Routing（地理鄰近路由）

類似地理位置路由，但基於座標和偏差（bias）參數來將流量移向或移離某個 Region。

Multi-Value Answer Routing（多值回答路由）

隨機返回最多 8 筆健康記錄，每筆記錄可關聯一個可選的健康檢查。作為 ELB 的輕量替代方案，用於跨多個 IP 的簡單客戶端側負載分散。與 Simple Routing 不同，Multi-Value Answer 會遵守健康檢查。

組合路由策略實現 HA

真實的 HA 設計通常巢狀使用路由策略：

• 主要 Region 延遲路由 → 故障轉移至次要 Region — 正常流量使用延遲路由，並有指向 DR Region 的故障轉移備份記錄。
• 帶健康檢查的跨 Region 加權路由 — 設定每個 Region 的權重，不健康的 Region 自動被跳過。
• 地理位置搭配故障轉移 — 將歐盟客戶服務於 eu-central-1，但主要節點停機時故障轉移至 eu-west-1。

消除單點故障 — 冗餘模式

高可用性與 Multi-AZ 設計的本質，從根本上就是 SPOF 消除的實踐。逐層審查，問自己：「如果這個確切的東西故障了會怎樣？」如果答案是「一切都崩潰」，那它就是一個 SPOF。

常見 SPOF 及其修復方案

• 單一 EC2 實例 → 在 ALB 後方部署跨 2-3 個 AZ 的 ASG。
• 單一 AZ 資料庫 → RDS Multi-AZ 或 Aurora 叢集。
• 單一 NAT Gateway → 每個 AZ 一個 NAT Gateway，各自位於其所在 AZ 的公開子網路，並使用針對子網路的路由表。
• 單一 Internet Gateway → 每個 VPC 最多只能有一個 IGW，但 IGW 是 Region 級別的且原生具備 HA；無需採取行動。
• 單一 Direct Connect 連結 → 搭配 Site-to-Site VPN 作為備援，或透過不同位置建立第二條 Direct Connect。
• 單一 Region → 跨 Region DR（請參閱 disaster-recovery-strategies）。
• 工作階段狀態儲存於單一 EC2 實例 → 外部化至 DynamoDB、ElastiCache 或 RDS，使任何實例都能服務任何使用者。
• 檔案上傳至實例本地磁碟 → 外部化至 S3 或 EFS。

NAT Gateway HA 模式

SAA-C03 一個常見問題：NAT Gateway 要放在哪裡。

• 錯誤 — 在單一公開子網路中只有一個 NAT Gateway，所有私有子網路（跨三個 AZ）都透過它路由。這造成 SPOF：若該 AZ 故障，所有對外網際網路流量都會中斷。
• 正確 — 每個 AZ 各一個 NAT Gateway，位於各 AZ 的公開子網路，並讓每個私有子網路路由至其所在 AZ 的 NAT Gateway。成本較高，但消除了 SPOF。

高可用性與 Multi-AZ 設計中的無狀態 vs 有狀態

高可用性與 Multi-AZ 設計最重要的原則是：讓應用程式層保持無狀態。無狀態的層可以自由擴展、替換和負載平衡，無需協調狀態。

什麼使應用程式層成為無狀態

• 實例上沒有儲存伺服器端工作階段。工作階段存放於 DynamoDB、ElastiCache 或已簽署的 Cookie。
• 實例磁碟上沒有使用者上傳的檔案。檔案上傳至 S3 或 EFS。
• 沒有無法按需重建的記憶體快取。使用 ElastiCache 作為共用快取。
• 資料庫連線是輕量的，或透過 RDS Proxy 進行池化。
• 設定來自 Parameter Store、Secrets Manager 或環境變數，而非內建於實例。

仍有狀態的部分及如何實現 HA

有些狀態是不可避免的——資料庫、檔案儲存、佇列。這些有狀態的服務正是你透過 AWS 受管服務實現 HA 的對象：

• 資料庫 — RDS Multi-AZ、Aurora、DynamoDB、ElastiCache Multi-AZ。
• 檔案 — S3（原生 11 個 9 耐久性，Multi-AZ）、EFS（Multi-AZ）、具備 Multi-AZ 部署的 FSx。
• 佇列 — SQS（受管，Multi-AZ）。
• 串流 — Kinesis（受管，Multi-AZ）。

不可變基礎設施 — 藍綠部署與滾動更新

部署是隱藏的可用性風險。一次錯誤的發布能像 AZ 中斷一樣可靠地讓系統停機。因此，高可用性與 Multi-AZ 設計也涵蓋部署模式。

不可變基礎設施原則

與其就地修補運行中的實例（這會造成設定漂移並帶來損壞風險），不如為每次變更烘焙新的 AMI 或容器映像並替換實例。一旦部署，實例就不再被修改——它要麼在運行，要麼被替換。

藍綠部署（Blue/Green Deployment）

• Blue — 當前運行的 Production 環境。
• Green — 具有新版本的第二個平行環境。
• 切換 — 透過 Route 53 加權記錄、ALB 目標群組交換或 DNS CNAME 變更，將流量從 Blue 切換至 Green。若 Green 出現問題，透過將流量切回 Blue 來回滾。

藍綠部署提供接近零停機時間的部署和快速回滾，代價是在切換視窗期間運行雙倍容量。

滾動更新（Rolling Update）

在同一個 ASG 內分批替換實例。每批啟動新實例，等待它們在 ELB 後方變為健康狀態，然後終止舊實例。比藍綠部署成本低，但回滾路徑較慢。

CodeDeploy 與 ASG Refresh

AWS CodeDeploy 同時支援藍綠和滾動模式。EC2 Auto Scaling 提供 Instance Refresh，以受控的波浪方式替換實例，匹配 Launch Template 的當前版本。

監控高可用性 — CloudWatch、X-Ray 與 Route 53

你無法守護你無法測量的可用性。高可用性與 Multi-AZ 設計包含監控技術堆疊。

Amazon CloudWatch

• 指標 — 每個實例、每個 ELB、每個 ASG、每個 RDS 的指標。
• 警示 — 觸發 SNS 通知、Lambda 修復動作或 Auto Scaling 動作。
• 複合警示 — 使用 AND／OR 邏輯組合多個警示，實現更乾淨的告警。
• CloudWatch Synthetics — Canary（無頭瀏覽器）持續探測面向使用者的端點。
• CloudWatch Logs Insights — 即時查詢日誌。

AWS X-Ray

跨微服務的分散式追蹤。每個請求被標記追蹤 ID，每個服務報告其 Span。X-Ray 服務地圖視覺化延遲和錯誤的來源——在診斷具有許多運動部件的 HA 架構時不可或缺。

Route 53 健康檢查指標

每個 Route 53 健康檢查本身就是一個 CloudWatch 指標。即使 DNS 已完成故障轉移，也要對「健康檢查失敗」發出警示，通知運維團隊——靜默發生的故障轉移仍然是值得調查的故障。

服務配額與限流 — 備援環境中的 HA

即使你的架構完美，隱藏的配額也可能在 Region 故障轉移期間破壞可用性。例如：

• 每個子網路的 ENI 限制 — 橫向擴展可能達到子網路 ENI 配額。
• 每個 Region 的 Elastic IP 限制 — 每個 Region 有軟性配額（預設 5 個）。
• RDS 實例配額 — 可能阻礙晉升 DR 副本。
• ALB 目標群組限制 — 每個群組的目標數量。
• Auto Scaling Group 最大規模 — 在故障轉移測試前提高。

在宣告 DR Region 就緒之前，請為你需要擴展的服務申請提高配額。配額提高是非同步審批的——請在災難發生之前申請，而不是在災難發生時。

高可用性與 Multi-AZ 設計的關鍵數字與必記事實

高可用性與 Multi-AZ 設計的常見考試陷阱

陷阱 1 — Multi-AZ vs Read Replica

最常被考的混淆點。Multi-AZ = HA、同步、不可讀、自動故障轉移。Read Replica = 讀取擴展、非同步、可讀、手動晉升。仔細閱讀情境題幹：「在 AZ 中斷中存活」→ Multi-AZ；「減輕讀取流量」→ Read Replica。

陷阱 2 — ALB vs NLB 層決策

ALB 處理 Layer 7（路徑路由、Header、WAF 等 HTTP 功能）。NLB 處理 Layer 4（TCP／UDP、靜態 IP、低延遲）。一旦情境提到 UDP、靜態 IP 或無需 X-Forwarded-For 的來源 IP 保留 → NLB。一旦提到基於路徑的路由、基於主機的路由或 WebSocket → ALB。

陷阱 3 — 跨 AZ 負載平衡

ALB 跨 AZ 永遠開啟且免費。NLB 跨 AZ 預設關閉，啟用時收取跨 AZ 資料傳輸費用。詢問「在流量進入的 AZ 內保持流量最具成本效益的方式」時，指向關閉跨 AZ 的 NLB。

陷阱 4 — 單一 NAT Gateway SPOF

題目有時描述「公開子網路中的 NAT Gateway 路由所有私有流量」。若所有 AZ 共用一個 NAT，該 AZ 就是 SPOF。正確答案：每個 AZ 各一個 NAT Gateway。

陷阱 5 — 將工作階段狀態放在 EC2 上

任何「黏性（stickiness）解決問題」的情境通常都是誤導。黏性（ALB 上的工作階段親和性）有所幫助，但正確的架構答案是將工作階段狀態外部化至 DynamoDB 或 ElastiCache，使黏性變得不必要。

陷阱 6 — Route 53 延遲路由 vs 地理位置路由

延遲路由 = 最快的網路路徑。地理位置路由 = 使用者的實體位置。若題目說「根據使用者實際所在位置路由」→ 地理位置路由。若說「根據網路效能路由」→ 延遲路由。

陷阱 7 — Auto Scaling 終止策略

預設終止策略是先在 AZ 之間平衡，然後刪除最舊的 Launch Configuration，再接近下一個計費小時。想要「優先終止最舊實例」的情境需要明確設定 OldestInstance 終止策略。

陷阱 8 — RDS Multi-AZ 不是跨 Region

常見的干擾說法：「RDS Multi-AZ 提供跨 AWS Region 的災難復原。」這是錯誤的——Multi-AZ 只在同一 Region 的不同 AZ 之間運作。跨 Region 需要另一個 Region 中的 Read Replica、Aurora Global Database 或 AWS Backup 的跨 Region 複製。

高可用性與 Multi-AZ 設計 vs 災難復原 — 範圍界線

本主題——高可用性與 Multi-AZ 設計——涵蓋單一 Region 內的彈性。姊妹主題 disaster-recovery-strategies 涵蓋跨 Region 的彈性。

• 2.2 HA（本頁） — Multi-AZ、ELB、ASG、RDS Multi-AZ、Aurora、Route 53 健康檢查、SPOF 消除。
• 2.2 DR（姊妹頁） — RPO／RTO 目標、備份與還原、Pilot Light、Warm Standby、Active-Active 多 Region、S3 CRR、Aurora Global Database、AWS Elastic Disaster Recovery（DRS）。

當題目說「在 AZ 中斷中存活」或「單一 Region 內 99.95% 正常運行時間」→ HA 主題。 當題目說「在整個 Region 中斷中存活」、提到 RPO／RTO，或描述跨 Region 複製 → DR 主題。

練習題連結 — Task 2.2 HA 習題

使用測驗引擎演練映射至高可用性與 Multi-AZ 設計概念的 Task 2.2 題目：

• 「一個 Web 應用程式在單一 EC2 實例和一個 AZ 中的 RDS 資料庫上運行。哪些架構變更能以最少的程式碼修改提供最高的可用性？」— 目標：透過 ASG + Multi-AZ 消除 SPOF。
• 「應用程式必須根據 URL 路徑將請求路由至不同的微服務。」— ALB 路徑路由。
• 「遊戲後端提供 UDP 流量，需要靜態 IP 用於防火牆白名單。」— NLB。
• 「讀取量使主要資料庫不堪重負；如何減輕？」— Read Replica。
• 「資料庫必須在 AZ 故障中存活，並具備自動故障轉移。」— RDS Multi-AZ。
• 「流量應導向對每個使用者延遲最低的 Region。」— Route 53 延遲路由。
• 「部署需要零停機時間和快速回滾。」— 透過加權路由或 ALB 目標群組交換實現藍綠部署。
• 「Lambda 呼叫耗盡了 RDS 連線。」— RDS Proxy。

FAQ — 高可用性與 Multi-AZ 設計常見問題

Q1. AWS 上高可用性（HA）與容錯（FT）有何差異？

高可用性（HA）是系統能在大多數元件故障中持續運作的特性，通常以正常運行時間 SLA 表示（99.9%、99.95%、99.99%）。HA 允許故障轉移期間發生短暫中斷——RDS Multi-AZ 花費 60–120 秒晉升備援節點就是典型的 HA 示例。容錯（FT）更嚴格：即使在故障期間，系統也必須在不讓使用者察覺任何中斷的情況下繼續提供服務。實現 FT 通常需要具備自動負載分配的實時冗餘元件，例如 DynamoDB 的 Multi-AZ 寫入路徑，或在每個 AZ 都有健康目標的 ALB。對於 SAA-C03 考試，大多數情境題要求 HA；當題目堅持「無中斷」或「零停機時間」時，你就進入了 FT 領域。

Q2. 在高可用性與 Multi-AZ 設計中，何時應使用 RDS Multi-AZ 而非 RDS Read Replica？

當目標是可用性時使用 RDS Multi-AZ——在 AZ 或主機故障時透過自動故障轉移存活。備援節點是同步的，應用程式無法讀取。當目標是讀取擴展時使用 RDS Read Replica——從主要節點卸載 SELECT 查詢。副本是非同步的、可讀的，若想讓它們成為主要節點則需手動晉升。兩種模式可以共存：Multi-AZ 主要節點處理寫入和 HA，三個 Read Replica 處理報表和分析。考試持續測試這個界線——若情境說「在 AZ 故障中存活」選 Multi-AZ；說「擴展讀取流量」選 Read Replica；說「跨 Region DR」選跨 Region Read Replica 或 Aurora Global Database。

Q3. 如何在 Application Load Balancer 和 Network Load Balancer 之間選擇？

當工作負載是 HTTP 或 HTTPS 且需要 Layer 7 功能時，選擇 Application Load Balancer：路徑路由、主機路由、HTTP Header 比對、原生 WebSocket、HTTP/2、帶 Cookie 的 Sticky Session、搭配 ACM 的 TLS 終止、AWS WAF 整合，或以 Lambda 作為目標。當工作負載是 TCP 或 UDP 且需要 Layer 4 速度時，選擇 Network Load Balancer：每個 AZ 的靜態 IP 位址、Elastic IP、毫秒以下延遲、無需 X-Forwarded-For 的來源 IP 保留，或每秒數百萬請求。僅在透過 GENEVE 協定透明插入第三方網路設備時，選擇 Gateway Load Balancer。對於新設計，基本上永遠不要選擇 Classic Load Balancer——它是舊版服務。

Q4. Auto Scaling Group 應跨越幾個 AZ？

任何正式環境工作負載至少跨越兩個 AZ；三個 AZ 是現代最佳實踐，因為它符合每個 AWS Region 的最低 AZ 數量，並提供法定人數式的彈性。跨越三個 AZ 意味著失去一個 AZ 後，仍有三分之二的容量提供服務。對於延遲敏感或有狀態的工作負載（例如 EC2 上的 Kafka 叢集），需要三個 AZ。對於 ALB 後方的無狀態 Web 層，兩個 AZ 是可接受的，但三個更安全且成本幾乎沒有差異。務必將 ASG 與負載平衡器搭配使用，讓目標群組跨越相同的 AZ，使流量分配與實例放置一致。

Q5. 無狀態應用程式意味著什麼，為何高可用性與 Multi-AZ 設計需要它？

無狀態應用程式層不在本地實例上儲存任何工作階段特定或使用者特定的資料。所有使用者工作階段狀態都存在共用後端儲存中——DynamoDB 用於低延遲鍵值工作階段、ElastiCache 用於記憶體工作階段，或已簽署的 Cookie 用於小型負載。檔案上傳至 S3 或 EFS，而非實例本地磁碟。無狀態性是必要的，因為 Auto Scaling、負載平衡和實例替換只有在任何替換實例都能無需重播先前狀態地處理任何使用者請求時才有效。若狀態存在於特定實例上，終止該實例就意味著失去使用者資料——這完全違背了高可用性與 Multi-AZ 設計的目的。ALB 上的黏性有時被用作暫時解決方案，但正確的答案是將狀態外部化。

Q6. Route 53 故障轉移路由實際上如何偵測故障並切換 DNS？

Route 53 將每筆記錄（例如主要 A 記錄）與一個健康檢查關聯。健康檢查按間隔（標準 30 秒或快速 10 秒）透過 HTTP、HTTPS 或 TCP 探測端點。在可設定的連續失敗次數（通常 3 次）之後，健康檢查被標記為不健康。Route 53 隨後停止在 DNS 回應中返回主要記錄，並開始返回次要記錄。切換在 DNS 解析時發生，因此快取了 DNS 條目的客戶端（記得 TTL）只有在快取到期後才會看到新記錄。請為故障轉移記錄設定較短的 TTL（30–60 秒），讓客戶端能快速獲取變更。另外請記住，Route 53 健康檢查位於 AWS 全球基礎設施的 Edge 層，而非你的 Region 內，這意味著它們本身具備高可用性，且不依賴 Region 是否健康。

Q7. DynamoDB 需要像 RDS 那樣設定 Multi-AZ 嗎？

不需要。DynamoDB 在 Region 內原生具備 Multi-AZ 特性：每次寫入在確認之前會同步複製至三個 AZ 的三份副本。無需啟用任何設定，也沒有可見的故障轉移事件——DynamoDB 的可用性是服務本身的特性。對於跨 Region 複製，請啟用 DynamoDB Global Tables，它將資料表非同步複製至一個或多個次要 Region，所有 Region 均可寫入。Global Tables 提供多 Region Active-Active，採用最後寫入者勝衝突解決機制。這是 Aurora Global Database 的 NoSQL 類比，也是全球分散式應用程式常用的高可用性與 Multi-AZ 設計構建塊。

Q8. 為什麼單一 NAT Gateway 在高可用性與 Multi-AZ 設計中是單點故障？

NAT Gateway 本身在其所在的 AZ 內是高可用服務——AWS 會自動替換故障的 NAT 節點。但 NAT Gateway 恰好位於一個 AZ 中。若三個 AZ 中的私有子網路都將對外網際網路流量路由透過，比如說 AZ-a 中的一個 NAT Gateway，而 AZ-a 發生電力事件，整個工作負載就會失去對外網際網路——不是因為 EC2 或 RDS 故障，而是因為 NAT 依賴關係崩潰了。解決方案是每個 AZ 部署一個 NAT Gateway，將其放在該 AZ 的公開子網路，並設定每個私有子網路的路由表將 0.0.0.0/0 指向其所在 AZ 的 NAT Gateway。成本較高，但消除了 SPOF。這是 SAA-C03 考試中最常被忽視的設計缺陷之一。

高可用性與 Multi-AZ 設計延伸閱讀

• Elastic Load Balancing 使用指南 — https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html
• Application Load Balancer — https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html
• Network Load Balancer — https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html
• Gateway Load Balancer — https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/introduction.html
• Amazon EC2 Auto Scaling 使用指南 — https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html
• Auto Scaling Launch Template — https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-templates.html
• Auto Scaling Lifecycle Hook — https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html
• 預測性擴展 — https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-predictive-scaling.html
• RDS Multi-AZ 部署 — https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html
• RDS Read Replica — https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html
• Amazon Aurora 概覽 — https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.html
• DynamoDB Global Tables — https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html
• Route 53 路由策略 — https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html
• Route 53 DNS Failover — https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover.html
• AWS SAA-C03 考試指南 — https://d1.awsstatic.com/training-and-certification/docs-sa-associate/AWS-Certified-Solutions-Architect-Associate_Exam-Guide.pdf