可靠性改善：消除現有架構的 SPOF

診斷切入點：可靠性改善從誠實盤點開始

現有系統的可靠性改善是 SAP-C02 Domain 3 最常見的題型：你拿到的不是空白白板，而是一個已在實際環境中出過問題的生產工作負載。考題幾乎都從某個症狀開始（這個應用程式上季故障三次）、加上一個限制條件（維護視窗不得超過 10 分鐘），以及一項 SLA 要求（99.5% 必須達到 99.95%）。你的可靠性改善計畫必須把症狀轉化成一份依優先順序排列的修復行動清單，每個行動都要有對應的 AWS 服務來支撐，且不需要重寫應用程式。

考生最常犯的錯誤是跳過診斷直接進入解法模式——「加上 Multi-AZ」——而沒有先完成診斷切入點。正確的可靠性改善工作流程從三項並行的資料蒐集任務開始。第一，對現有應用程式堆疊執行 AWS Resilience Hub 評估，讓工具列舉資源層級的彈性政策，並找出與你宣告的 RTO/RPO 之間的差距。第二，手動走過架構圖，列出每個發生故障就會讓工作負載停擺的元件；這就是你的單點故障（SPOF）清單。第三，從 CloudWatch Logs、Personal Health Dashboard 及工單系統中取出事件歷史，了解哪些 SPOF 確實已經出過問題，讓可靠性改善工作依真實發生機率排序，而非依照主觀的恐懼感。

本主題以 SAP-C02 Pro 深度走完整個可靠性改善修復循環。你將學會如何跨越運算、資料、網路、身份和跨區域等維度識別 SPOF；如何排序修復工作，讓風險最高的元件優先處理；如何在不重寫程式碼的情況下，將 AWS Fault Injection Service (FIS) 實驗、Route 53 Application Recovery Controller (ARC) 路由控制、RDS Proxy 以及每個 AZ 專屬 NAT Gateway 導入正在運行的系統。這裡的每個模式都是針對正在運行的工作負載所設計的可靠性改善——不是全新設計的演練。

可靠性改善情境：99.5% 的單體式應用

把這個情境記在腦中，讓後面的每個修復模式都能對應回來。一個單區域的單體式應用，跑在幾台 EC2 執行個體後面，前面是一個 Application Load Balancer，連接一個 single-AZ 的 MySQL RDS 執行個體，用 ALB sticky cookie 儲存 session 狀態，透過單一 NAT Gateway 對外連線，在單一區域用一個 ACM 憑證終止 TLS，透過一個地端 IdP 進行聯合身份驗證，並以硬編碼的端點指向一個 DynamoDB Streams 消費者。上季故障了三次——一次因為 AZ 異常，一次因為 RDS 儲存空間耗盡，一次因為 NAT Gateway 達到埠分配上限。業務單位已將 SLA 從 99.5% 提升至 99.95%，意味著每年允許的停機時間從 43 小時降到約 4.4 小時。

你有 90 天、沒有應用程式程式碼的所有權，並且有一條硬性規定：任何維護視窗不得超過 10 分鐘。以下所有可靠性改善動作都必須遵守這個限制。這種現實中的限制框架，正是 SAP-C02 考試獎勵那些清楚知道哪些 AWS 服務可以直接掛載到現有工作負載、而哪些服務需要重寫才能使用的考生的原因。

為什麼從 99.5% 到 99.95% 是一次等級躍升

從 99.5% 到 99.95% 並不是「再多一點可靠性」——而是允許停機預算縮短了 10 倍。這個跳躍要求結構性的可靠性改善：消除 SPOF，而不只是調整它們。能夠承受一個 AZ 故障的工作負載可以維持單區域，但那個區域中的每個共享依賴——單一 RDS、單一 NAT、單一憑證——的重要性就提升了一個數量級。

大多數團隊忽略的隱藏 SPOF 清單

大多數團隊只列出顯而易見的 SPOF（資料庫、NAT）就停下來了。可靠性改善的考試模式測試的是隱藏的那些：一個即將到期的 ACM 憑證；Lambda 環境變數中硬編碼的 regional endpoint；每個聯合登入都必須通過的單一 Identity Provider；只與一個 VPC 關聯的 Route 53 private hosted zone；一個帳號的 root credentials 掌握整個爆炸半徑。

白話文解釋 可靠性改善（Reliability Improvement）

在正在運行的生產工作負載上進行可靠性改善，是 SAP-C02 Domain 3 最常出現的題型。三個貼近台灣日常生活的類比，能讓「為什麼這是排序問題，而不是重新設計問題」一秒就懂。三個都讀過之後再進入後面的 SPOF 清單，判斷下一個修復動作的邏輯會清晰很多。

類比一：可靠性改善如同老公寓電梯翻修

把在現有 AWS 工作負載上進行可靠性改善，想像成翻修一棟全天有住戶使用的老公寓電梯。你不能讓整棟大樓停電施工——必須排好順序，讓 A 棟電梯維修的同時 B 棟還能正常運轉，舊的機電控制盤換掉之前新的安全繩得先裝好。這就是為什麼可靠性改善是排序問題。緊急疏散照明要先換，因為它直接影響住戶安全；電梯音樂可以最後再說。SAP-C02 Domain 3 的每道修復題，都是在問「哪條迴路先修，住戶今晚才能安全搭電梯回家？」

類比二：可靠性改善如同廚房現有刀具升級

AWS 給你一組現成的廚房刀具用來做可靠性改善——Multi-AZ、RDS Proxy、Route 53 ARC、Resilience Hub、FIS、Service Quotas、Auto Scaling mixed instance groups。你不需要買一組全新的刀具組；你要做的是從刀架上挑對刀。考試獎勵的是知道每個 SPOF 該用哪把刀的人。Multi-AZ 是處理資料層可靠性的主廚刀；RDS Proxy 是處理連線風暴的削皮刀；Route 53 ARC 是確定性切換流量的剪刀；FIS 是找出刀刃缺口的砥石。

類比三：可靠性改善如同台北市路口增設號誌

沒有號誌的路口車流很快，直到第一個事故讓整條街癱瘓。在現有路口補上交通號誌就是可靠性改善：每個路口可以獨立故障，繞道可以分流車輛，尖峰時刻由號誌配時吸收，不會一個路口卡住就全段塞爆。每個 AZ 專屬的 NAT Gateway、Route 53 ARC 路由控制，以及 Auto Scaling mixed instance groups，扮演的都是交通號誌的角色——將故障隔離、提供明確的切換控制、並適應負載變化。ALB 上的 sticky session 則完全相反：一個沒有號誌的路口，只要那台執行個體停了，整段就卡死。

SPOF 清單：可靠性改善的起點

在任何修復之前，必須用這份清單對照現有架構逐項檢查。每個條目都是一個 SPOF 類別，可靠性改善工作必須消除它，或明確接受並設置補償控制。

Single-AZ RDS 執行個體

Single-AZ RDS 執行個體是典型的 SPOF，也是任何可靠性改善計畫的第一站。AZ 異常、儲存控制器故障或硬體更換，都會導致停機。修復方式是轉換為 Multi-AZ，在第二個 AZ 引入同步備援。Multi-AZ 容錯移轉是自動的，約在 60 至 120 秒內完成，受 DNS TTL 傳播和應用程式連線池行為的影響。

單一 NAT Gateway

一個 AZ 中的單一 NAT Gateway 意味著，如果該 AZ 降級，VPC 中所有私有子網路的外網連線都會中斷——包括路由表指向該故障 NAT 的其他健康 AZ 中的執行個體。更糟的是，單一 NAT Gateway 還受到埠分配上限的限制（每個目的地約 55,000 個同時連線）。可靠性改善要求每個 AZ 各有一個 NAT Gateway，並設置每個 AZ 專屬的路由表，讓各 AZ 獨立對外連線。

跨區域依賴

一個宣稱是 Multi-AZ 但悄悄依賴另一個區域的 S3 bucket、KMS CMK 或 DynamoDB 資料表的工作負載，實際上並不是 Multi-AZ——它是跨區域的，而那條跨區域連線就是新的 SPOF。可靠性改善要求將該依賴複製到主要區域（S3 Same-Region replication、multi-Region KMS keys、DynamoDB global tables），或明確在 RTO 計算中記錄跨區域依賴。

單一 ACM 憑證

一個 ALB 上的單一 ACM 憑證看起來沒問題，直到續約失敗、私鑰被撤銷或網域驗證記錄被刪除。ACM 公開憑證會自動續約，但 private CA 簽發的憑證和匯入的憑證則不會。可靠性改善要盤點每個 TLS 終止點、確保自動續約，並且在災難復原情境中，在 DR 區域預先佈建一個平行憑證（ACM 是區域性服務；us-east-1 的憑證無法服務 eu-west-1 的 ALB）。

硬編碼端點

Lambda 環境變數中包含 api.us-east-1.amazonaws.com，或 EC2 user-data 腳本中有硬編碼的 RDS 端點 DNS 名稱，都是可靠性改善的反模式。Multi-AZ 容錯移轉發生時，DNS 記錄會更新——但前提是用戶端解析 DNS 名稱，而不是快取已解析的 IP。可靠性改善要以 Route 53 記錄取代硬編碼的 IP，以 RDS Proxy 端點取代連線字串，並以執行時期解析的 SSM Parameter Store 查詢取代特定區域的 ARN。

單一 Identity Provider

單一地端 IdP 是單一的身份驗證 SPOF。如果 IdP 停機，所有聯合使用者都無法登入——包括試圖緩解故障的操作人員。可靠性改善要在 IAM Identity Center 中新增緊急存取 IAM 使用者（配備硬體 MFA），或使用具備 Multi-AZ 網域控制器的 AWS Managed Microsoft AD。

單一區域

單一區域部署對於整個區域的大規模異常來說是一個 SPOF。SAP-C02 的可靠性改善題很少強迫你採用多區域——它要求你說明維持單區域的 RTO/RPO 代價，並測試你是否知道哪些服務需要明確選用多區域（Route 53 ARC readiness checks、Global Accelerator、DynamoDB global tables、S3 CRR）。

修復序列 1：Single-AZ RDS 轉換為 Multi-AZ（不停機）

將 Single-AZ RDS 轉換為 Multi-AZ 是第一個可靠性改善動作，因為它消除了發生機率最高、影響最大的 SPOF。AWS 透過單一 modify-db-instance 呼叫支援這個操作，但 Pro 等級的可靠性改善考生必須了解其失敗模式。

簡單路徑：原地修改

對大多數資料庫引擎而言，aws rds modify-db-instance --db-instance-identifier prod-db --multi-az --apply-immediately 會觸發主執行個體的快照、在第二個 AZ 佈建備援，並啟動同步複製。在這個過程中，主執行個體不會停機——但備援啟動後，由於提交現在需要跨 AZ 同步，寫入延遲會增加幾毫秒。修改作業可能需要一小時甚至更長時間，但這是背景工作，不是中斷。

嚴格視窗下的 Replica 提升路徑

當業務要求的是受控切換，而非「AWS 決定好時機再切」，可靠性改善就要走 read replica 提升路徑。在 AZ B 建立一個 read replica，等待複製延遲歸零後提升該 replica，並透過 Route 53 或 ALB target group 切換將應用程式流量導向新端點。這樣你就有一個明確的切換時間點，但這是單向操作：舊主執行個體成為孤立節點，必須重新匯入或下線。當考題情境說「我們需要一個經過演練的容錯移轉時機」，這個模式就是正確的可靠性改善答案。

容錯移轉的應用程式層可靠性改善

應用程式層必須配合。JDBC 連線池、SQLAlchemy engine 和 .NET 連線字串會快取 DNS。Multi-AZ 容錯移轉後，過時的連線池指向舊 IP，連線最多可能中斷 5 分鐘。客戶端的可靠性改善包括設定短暫的 DNS TTL、在連線借出時啟用連線驗證，以及理想情況下在應用程式與資料庫之間放置 RDS Proxy，讓受管理的中介層處理重新連線的風暴。

修復序列 2：RDS Proxy 應對連線峰值

RDS Proxy 是工作負載容易發生連線風暴時的可靠性改善答案——Lambda 橫向擴展、ECS 任務重啟，或批次工作負載的峰值耗盡資料庫的 max_connections 預算。RDS Proxy 位於用戶端和資料庫之間，集中管理連線並吸收峰值。

何時 RDS Proxy 是正確的可靠性改善方案

如果事件歷史顯示「資料庫 max_connections 耗盡」或「Lambda 峰值後資料庫持續高 CPU」，那就是需要 RDS Proxy 的信號。Lambda cold start 後 1,000 個並發執行個體各自開啟 1,000 個新連線，會壓垮一台 db.m5.large。RDS Proxy 將這 1,000 個 Lambda 請求多工複用到一個可管理的 100 條真實資料庫連線的連線池上。

RDS Proxy 改善容錯移轉時間

沒有 RDS Proxy 時，Multi-AZ 容錯移轉需要 60 至 120 秒加上用戶端重新連線時間。有了 RDS Proxy 在路徑上，容錯移轉對應用程式呈現為約 30 秒的延遲升高，因為 RDS Proxy 在穩定端點後面處理對新主執行個體的重新連線。對於 SLA 嚴格的可靠性改善來說，這是有意義的進展。

將 RDS Proxy 導入正在運行的工作負載

修復步驟很直接：建立 RDS Proxy，關聯現有資料庫，將資料庫憑證儲存在 AWS Secrets Manager，授予 Lambda/ECS 執行角色 secretsmanager:GetSecretValue 和 rds-db:connect 權限，然後在應用程式設定中替換端點。RDS Proxy 也支援 IAM 認證，這樣就不需要處理密碼輪換的複雜性。可靠性改善的爆炸半徑很小：如果 RDS Proxy 出現問題，把端點改回直接連接資料庫就行了。

修復序列 3：單一 NAT Gateway 改為每個 AZ 一個

單一 NAT Gateway 是 Resilience Hub 評估中最常見的可靠性改善發現，因為它太容易設定，也太容易被遺忘。這個修復是純基礎設施工作——不需要修改應用程式。

每個 AZ 專屬的 NAT 拓撲

對每個有私有子網路的 AZ，在該 AZ 的公有子網路中佈建一個 NAT Gateway。更新私有子網路的路由表，使 AZ A 中的子網路將 0.0.0.0/0 路由到 AZ A 的 NAT，AZ B 中的子網路路由到 AZ B 的 NAT，依此類推。現在，AZ A 的 NAT Gateway 故障只影響 AZ A 的工作負載；AZ B 繼續正常對外連線。

成本與埠耗盡作為可靠性改善的驅動因素

每個 AZ 一個 NAT 會增加成本（每個 NAT 按小時計費加上資料處理費），但同時也將埠分配分散到多個 gateway，直接修復了埠耗盡類型的故障。如果事件歷史中提到「SNAT port exhaustion」或「許多執行個體對單一第三方 API 的對外連線間歇性失敗」，每個 AZ 一個 NAT 不是選項——而是必要的可靠性改善。

混合方案：用 VPC Endpoints 減少 NAT 依賴

在修復為每個 AZ 一個 NAT 之前，先審計哪些流量通過 NAT。如果大多數流量是 S3 或 DynamoDB，新增 Gateway VPC endpoints 可以完全消除這些流量的 NAT 路徑，同時達到成本降低和可靠性改善的效果。其他 AWS 服務（Secrets Manager、SSM、KMS）的 Interface endpoints 可以進一步降低 NAT 負載，並消除對公網際網路呼叫 AWS API 的故障依賴。

修復序列 4：Auto Scaling Group 混合執行個體類型與 Spot 再平衡

Auto Scaling Group 中單一執行個體類型，是一個不那麼明顯維度的可靠性改善 SPOF：容量可用性。如果區域中 m5.large 已售罄，你的 ASG 就無法橫向擴展，在流量峰值期間這就是一個偽裝的中斷。

多種執行個體類型提供容量多樣性

修改現有 ASG 的 launch template，加入包含三到四種執行個體類型（m5.large、m5a.large、m6i.large、m6a.large）的 mixed instance policy，並讓分配策略設為 price-capacity-optimized。ASG 現在會從有庫存的容量池中取用，將橫向擴展失敗轉化為成本維度的問題。

Spot 搭配 Capacity Rebalance

對於容錯層，將 On-Demand 與 Spot 混合使用。啟用 Capacity Rebalance，使 ASG 能接收 EC2 Spot 再平衡建議，並在 Spot 中斷發生前主動替換執行個體。搭配 target tracking scaling，同時達到可靠性改善和成本降低的效果。

修復序列 5：以 DynamoDB Session Store 取代 Sticky ALB Session

Sticky ALB session 是可靠性改善的反模式，因為它將使用者綁定到單一執行個體。當那個執行個體停止時，使用者就會被登出，所有該使用者進行中的交易都會失敗。Pro 等級的可靠性改善要把 session 狀態移出執行個體。

DynamoDB 作為 Session Store

修復模式：建立一個 DynamoDB 資料表 sessions，以 session ID 為 partition key，設置 TTL 屬性用於自動過期，並使用 on-demand 容量或具備 auto-scaling 的 provisioned 容量。將記憶體內的 session middleware 替換為 DynamoDB 後端的實作（express-session 搭配 connect-dynamodb、ASP.NET Core 搭配對應的 DynamoDB 資料保護提供者等）。

安全地關閉 Stickiness

一旦 session 存入 DynamoDB，就可以關閉 ALB target group 的 stickiness 設定。在低流量時段進行此操作，並監控異常。這裡的可靠性改善同時解鎖了水平擴展——任何執行個體都可以服務任何使用者——並簡化了藍/綠部署，因為暖機不再需要將特定使用者路由到特定執行個體。

ElastiCache 替代方案

如果工作負載需要毫秒以下的 session 查找，ElastiCache for Redis 是替代的 session store。使用具備 Multi-AZ 容錯移轉的叢集模式以提升快取層的可靠性；否則 ElastiCache 本身就會成為新的 SPOF。

混沌測試修復：AWS Fault Injection Service 實驗

可靠性改善計畫只有在經過排練後才是可信的。AWS Fault Injection Service (FIS) 是受管的混沌工程服務，讓你可以在現有工作負載上執行受控的故障實驗。在考試中，每當題幹說「驗證新設計能承受 AZ 故障」或「證明容錯移轉確實有效」，FIS 就是正確的可靠性改善答案。

FIS 實驗範本結構

一個 FIS 實驗包含 actions（要破壞什麼）、targets（哪些資源）、stop conditions（爆炸半徑擴大時中止的 CloudWatch alarms）以及授權 FIS 執行操作的 IAM role。針對單體式應用情境的可靠性改善，候選實驗包括：

依元件逐項修復的實驗

• RDS：aws:rds:reboot-db-instances 搭配 forceFailover = true，驗證 Multi-AZ 容錯移轉路徑。
• NAT/AZ：aws:network:disrupt-connectivity 作用於一個 AZ 的子網路，驗證每個 AZ 專屬 NAT 的隔離效果。
• EC2：aws:ec2:terminate-instances 驗證 ASG 替換和透過 DynamoDB 的 session 連續性。
• API/延遲：aws:fis:inject-api-internal-error 作用於選定的 API，驗證用戶端重試和斷路器邏輯。

Stop Conditions 作為爆炸半徑守衛

每個在生產環境進行的可靠性改善修復 FIS 實驗都必須附加一個 CloudWatch alarm 作為 stop condition——例如「如果 5xx 錯誤率在 2 分鐘內超過 1%，則中止」。如果 stop condition 觸發，FIS 會自動回滾並終止實驗。這是讓你能在生產環境而非複製環境執行混沌測試的可靠性改善保險。

Route 53 ARC 修復：確定性的容錯移轉控制

Route 53 Application Recovery Controller (ARC) 是當 Route 53 health-check 容錯移轉太過機率性時的可靠性改善答案。ARC 新增了路由控制（手動開關）和 readiness checks（持續驗證複本是否確實就緒）。

在現有 Route 53 記錄上新增路由控制

修復順序：建立一個 ARC 叢集（五個區域端點用於仲裁），定義 control panel，建立路由控制，然後透過 ARC alias 將每個路由控制附加到現有的 Route 53 記錄上。Route 53 記錄現在只解析到路由控制處於 On 狀態的端點。容錯移轉時，操作人員透過 ARC 叢集的資料平面切換路由控制——這是一個基於仲裁的決策，不會被區域控制平面中斷靜默覆蓋。

對現有基礎設施的 Readiness Checks

Readiness check 持續評估資源設定（跨區域的 ASG 容量是否匹配？DynamoDB 資料表是否健康？Route 53 記錄是否一致？），並在偵測到漂移時發出警報。這裡的可靠性改善是降低容錯移轉失敗的機率，因為 DR 複本悄悄與主要環境產生了偏差。

Zonal Shift 用於 AZ 層級的可靠性改善

Zonal shift 是更輕量的 ARC 功能——它讓你可以暫時停止將 ALB/NLB 流量路由到某個 AZ，而不需要編輯 Load Balancer 設定。對於單體式應用情境，當某個 AZ 表現異常但 AWS 尚未宣告受損時，Zonal shift 是一鍵式的可靠性改善。

Zonal Autoshift

Zonal autoshift 是更新的演進：AWS 監控 AZ 健康狀態，並自動將流量從受損的 AZ 移走，健康後再移回來。在現有的 ALB 和 NLB 上啟用此功能，作為零人工介入的可靠性改善基線。

AWS Resilience Hub 評估現有應用程式

AWS Resilience Hub 是評估現有工作負載對照你宣告的 RTO/RPO 表現，並產生優先修復清單的評估服務。在 SAP-C02 考試中，每當題幹說「評估現有工作負載的目前彈性狀態」，Resilience Hub 就是正確的可靠性改善答案。

定義彈性政策

彈性政策為四種中斷類型宣告 RTO 和 RPO：Software（應用程式層）、Hardware（執行個體/磁碟區）、AZ（單一 AZ 下線）、Region（單一區域下線）。Resilience Hub 衡量應用程式達到每個 RTO/RPO 的能力，並為每個元件給出「Policy met / Policy breached」判定。

將現有應用程式加入 Resilience Hub

你可以將 Resilience Hub 指向 CloudFormation stack、Terraform state 檔案、resource group 或 EKS 叢集。它會檢視宣告的資源，根據每個資源的設定推算出隱含的彈性（Single-AZ RDS = AZ RTO breach；Single NAT = AZ RTO breach；無備份計畫 = hardware RPO breach），並產生一份優先排序的建議清單。

用 Resilience Hub 完成修復循環

每次可靠性改善修復後，重新執行評估，確認對應的政策項目從「breached」翻轉為「met」。這是 SAP-C02「如何驗證修復已生效」的答案——你不是憑眼睛看架構圖，而是重新執行 Resilience Hub 評估。

配額監控修復：Service Quotas 與 CloudWatch

配額突破會造成看起來像應用程式錯誤的中斷。可靠性改善包含主動的配額監控，因為你不能讓系統撞上一道看不見的牆。

Service Quotas API 用於程式化審計

Service Quotas API 列出每個 AWS 服務在每個區域的已套用配額。每週執行一個 Lambda，將目前用量（透過 CloudWatch 指標或 describe-* API 呼叫）與已套用配額進行比較，並在達到 70% 時發出 SNS 警報——這是最精簡但有效的可靠性改善。

CloudWatch Alarms 監控用量指標

許多服務在 AWS/Usage namespace 下發布用量指標。為 CallCount（API 速率限制）或 ResourceCount（EC2 執行個體數量）等指標建立 CloudWatch alarms。搭配 EventBridge 規則，當 alarm 觸發時自動提交 Service Quotas 增加申請——這是作為自動化的可靠性改善，而非被動的工單處理。

可靠性改善必須涵蓋的常見配額

Lambda concurrent executions、每個家族的 EC2 vCPU 限制、每個區域的 VPC 數量、每個區域的 EBS 磁碟區儲存空間、每個帳號的 Route 53 hosted zones，以及每個區域的 ACM 憑證，都是常見的嫌疑對象。可靠性改善審計要為組織中每個帳號列舉這些指標，並設定合理的使用餘裕目標。

自我修復自動化修復

需要人類讀取告警的可靠性改善，比以程式碼執行的可靠性改善慢。一旦 SPOF 清單已處理乾淨，就在上面疊加 EventBridge + Lambda/SSM 自動化。

CloudWatch Alarm → EventBridge → SSM Document

標準的自我修復迴圈：CloudWatch alarm 觸發（例如「執行個體已無回應 5 分鐘」），EventBridge 規則匹配 alarm 狀態變更，目標是一個 SSM Automation Document，它會重啟執行個體、輪換憑證，或替換 ASG 成員。操作人員仍會收到通知，但修復已經開始執行。

SSM Runbook 目錄

為已知的故障模式建立 SSM Automation Documents 目錄：「重啟卡住的 RDS 連線池」、「輪換洩漏的 IAM 憑證」、「強制 NAT Gateway 容錯移轉」、「使 CloudFront distribution 失效」。每個 runbook 都是下次事件降低 MTTR 的可靠性改善資產。

Pro 深度：診斷切入點深度剖析

當 SAP-C02 題幹說「一個現有工作負載發生故障」，Pro 等級的診斷切入點序列是：

1. 對目前的 stack 執行 Resilience Hub 評估，取得資源層級的 SPOF 地圖。
2. 查閱過去 90 天的 Personal Health Dashboard 事件——我們是否已經遭遇過 AZ 或區域性事件？
3. 執行 Trusted Advisor 服務限制和容錯檢查，作為快速的可靠性改善直覺檢驗。
4. 查看 CloudWatch dashboards 和 Logs Insights，找出最主要的錯誤來源。
5. 在預備環境中執行 FIS 實驗，驗證 Resilience Hub 評估的預測。

這個切入點序列本身就是可測試的——考題會問「哪個 AWS 服務排第一」，答案幾乎都是 Resilience Hub 或 Trusted Advisor（用於評估階段），接著是 FIS（用於驗證）。

Pro 深度：超越顯而易見的 SPOF 識別

初學者的 SPOF 清單是「Single AZ、Single Region、Single Instance」。Pro 等級的可靠性改善清單還要加上：

配額 SPOF

帳號可以擴展，直到碰到配額就無法繼續。即使架構是冗餘的，那個配額就是 SPOF。

身份 SPOF

單一 IdP、單一緊急存取帳號、單一 AWS Organizations 管理帳號——後者的遺失會阻斷帳號層級的復原。

控制平面 vs 資料平面 SPOF

Route 53 資料平面具備全球彈性；Route 53 控制平面（記錄編輯）hosted 在 us-east-1，可能受損。ARC 的路由控制特別使用資料平面仲裁 API，以在 us-east-1 控制平面中斷時仍能正常運作。Pro 深度的可靠性改善要為每個服務區分控制平面和資料平面。

設定漂移 SPOF

AMI 版本過舊的區域、CloudFormation 範本已偏離的區域、安全群組規則不一致的區域——看起來就緒但實際上並不就緒的 DR 區域。Route 53 ARC 中的 readiness checks 就是答案。

Pro 深度：修復模式原則

每個在現有工作負載上進行的可靠性改善修復都遵循這些原則：

最小安全變更優先

在導入 RDS Proxy 之前先啟用 Multi-AZ。在轉移到 Aurora 之前先導入 RDS Proxy。每個步驟都是可逆的，或爆炸半徑是受控的。

先可觀測，再自動化

在疊加 EventBridge 修復之前，先新增 CloudWatch 指標和 alarms。你需要先看到症狀，才能自動化回應。

先排練，再信任

每個修復都必須透過 FIS 在 staging 環境至少演練一次，並在生產環境演練一次（加上 stop conditions）。從未執行過容錯移轉的可靠性改善，尚未得到真正的驗證。

記錄變更差異

每次修復都會改變彈性政策。更新 Resilience Hub、更新 runbook、更新架構圖。未文件化的可靠性改善會快速衰退。

端對端走過情境：90 天可靠性改善計畫

針對 99.5% 單體式應用情境，Pro 等級的可靠性改善計畫按 90 天排序：

第 1-2 週：評估

對 CloudFormation stack 執行 Resilience Hub；執行 Trusted Advisor；依爆炸半徑標記 SPOF；為 CloudWatch dashboards 和 Service Quotas 用量建立基線。

第 3-4 週：資料層可靠性改善

透過原地修改將 RDS 轉換為 Multi-AZ（不停機）。啟用 35 天的自動備份。導入帶有 Secrets Manager 憑證的 RDS Proxy。透過 FIS reboot-db-instance with forceFailover 測試容錯移轉。

第 5-6 週：網路層可靠性改善

修復為每個 AZ 一個 NAT Gateway。新增 S3 和 DynamoDB Gateway VPC endpoints。為 Secrets Manager、SSM 和 KMS 新增 Interface endpoints。驗證每個 AZ 的路由表。對一個 AZ 執行 FIS 網路中斷實驗。

第 7-8 週：運算層可靠性改善

將靜態 EC2 群組轉換為具備 mixed instance types 的 ASG。導入 Capacity Rebalancing。將 session 狀態從 sticky ALB cookie 移至具備 TTL 的 DynamoDB sessions 資料表。停用 ALB stickiness。執行 FIS 執行個體終止實驗。

第 9-10 週：流量與容錯移轉可靠性改善

導入 Route 53 ARC 叢集、路由控制和 readiness checks。在 ALB 上啟用 Zonal autoshift。記錄手動 Zonal shift 程序。針對 AZ 容錯移轉進行桌面演練。

第 11-12 週：驗證與自動化可靠性改善

為前三個已知故障模式疊加 CloudWatch → EventBridge → SSM 自動化。執行完整的 Resilience Hub 重新評估，確認每個政策項目顯示「met」。向業務單位呈現新的 SLA 成效報告。

SAP-C02 常見的可靠性改善陷阱

有幾個題目模式持續讓沒有在 Pro 深度演練過可靠性改善的考生失分。

陷阱一：Multi-AZ 等於「容錯」

Multi-AZ 是高可用性，不是容錯。考試區分「能承受一個 AZ 故障」（Multi-AZ）和「在故障期間無需人工介入即可持續服務」（真正的容錯，需要跨 AZ 預先佈建冗餘容量）。

陷阱二：Route 53 Failover Routing 是確定性的

Route 53 health-check 容錯移轉是機率性的——它取決於 health check 評估時機和 TTL。當可靠性改善要求確定性的切換時，ARC 路由控制才是正確答案，而非單獨依賴 Route 53 failover records。

陷阱三：RDS Proxy 是效能工具

RDS Proxy 是一個同時改善連線池效能的可靠性改善工具。考題問「RDS Proxy 解決什麼問題」，正確答案圍繞著連線耗盡和容錯移轉彈性，而非原始延遲。

陷阱四：Cross-Zone Load Balancing 是免費的可靠性改善

Cross-zone load balancing 通常對 ALB 預設為開啟，在同一 VPC 內沒有資料傳輸費用；對 NLB 則預設為關閉，開啟後會產生跨 AZ 資料費用。可靠性改善修復必須考量這個成本/流量取捨。

陷阱五：備份不等於災難復原

同一區域的自動 RDS 快照是備份，不是 DR。真正的 DR 可靠性改善需要跨區域快照複製或跨區域 read replica。SAP-C02 測試這個區別。

白盒走查：可靠性改善決策說明

將這些模式轉化為考試反射動作，走過每個 SPOF 的決策樹。

Single-AZ RDS → 選擇修復路徑

• 引擎支援 Multi-AZ cluster（MySQL 8.0.28+、PostgreSQL 13.6+）？考慮 Multi-AZ DB cluster 以獲得備援上更好的寫入效能。
• 引擎只支援傳統 Multi-AZ？使用傳統 Multi-AZ。
• 寫入延遲敏感度極高？評估 Aurora 而非 RDS Multi-AZ——這是不同的可靠性改善討論。

單一 NAT → 選擇拓撲

• NAT 成本考量高？先新增 VPC endpoints，再部署每個 AZ 一個 NAT。
• 有埠耗盡事件歷史？每個 AZ 一個 NAT 是必要的。
• 對外網際網路的連線很少見？考慮每個 AZ 一個 NAT Gateway 加上 IPv6 的 egress-only Internet Gateway。

Sticky Session → 選擇 Session Store

• 延遲預算 < 5ms 且願意維運快取層？ElastiCache for Redis 搭配 Multi-AZ。
• 延遲預算寬鬆（10ms+）且偏好受管服務？DynamoDB 搭配 TTL。
• Session 存活時間極短（分鐘級）？客戶端 JWT token 完全消除伺服器端 session store。

FAQ

在 SAP-C02 考試中，可靠性改善與災難復原有何不同？

可靠性改善是消除區域內的 SPOF，使工作負載能承受元件和 AZ 故障。災難復原是在整個區域發生大規模事件時仍能存活。考試對「提升可靠性」用於單一區域內的 SPOF 修復，對「災難復原」用於多區域模式。RDS Multi-AZ 是可靠性改善；帶有提升操作的 RDS 跨區域 read replica 是災難復原。兩個主題都在 SAP-C02 Domain 3 中被測試，但它們回答的是不同的題幹。

將 Single-AZ RDS 轉換為 Multi-AZ 真的可以零停機嗎？

是的，對主執行個體而言——但應用程式端必須能夠承受 DNS 變更，以及備援執行個體建立期間短暫的提交延遲增加。AWS 的操作本身不會暫停主執行個體；讀取和寫入都會繼續。可靠性改善的風險在客戶端：快取 DNS 或持有過時連線的連線池，可能在變更完成後的頭幾分鐘內觀察到錯誤。在轉換之前提前導入 RDS Proxy，可以消除大部分這種客戶端可靠性改善風險。

什麼時候應該選擇 Route 53 ARC 路由控制而非 Route 53 Failover Records？

當你需要不依賴 health check 評估時機的確定性、仲裁支持的流量切換時，使用 ARC 路由控制——通常用於高風險的區域性容錯移轉，在這種情況下，混亂的容錯移轉比原始中斷更糟糕。對於不那麼關鍵的、health check 就已足夠的自動容錯移轉，使用 Route 53 failover records。可靠性改善成熟度通常從 failover records 開始，隨著工作負載的關鍵性提升而晉級到 ARC。

小型工作負載需要 AWS Fault Injection Service 嗎？

是的，程度正比於你對自己可靠性改善故事的信心。如果你無法透過 FIS 證明新的 RDS Multi-AZ 確實執行了容錯移轉，且應用程式確實重新連線，那麼可靠性改善只存在於紙面上。FIS 收費低廉（按操作分鐘計費），每月一個小型混沌實驗是任何有 SLA 支撐的工作負載的最低可靠性改善驗證標準。在考試中，每當題幹說「驗證」或「證明彈性」，FIS 就是標準答案。

當所有東西看起來都是 SPOF 時，如何排列可靠性改善的優先順序？

依兩個維度對 SPOF 排名：發生故障時的爆炸半徑（是讓整個工作負載停擺，還是只影響一個層？）以及故障發生的機率（這個元件歷史上是否不穩定、接近配額，或執行在未更新的軟體上？）。先修復高爆炸半徑、高機率的 SPOF——幾乎總是資料層。然後攻克下一圈：網路對外連線、運算容量、身份。最後，為已知的反覆故障模式自動化修復。Resilience Hub 的優先建議清單提供了一個有主見的起始清單，通常是前 90 天可靠性改善骨幹的正確選擇。

Resilience Hub 與 Trusted Advisor 在可靠性改善上有何不同？

Trusted Advisor 提供全帳號的可靠性改善信號——服務限制、Single-AZ RDS、ASG 未使用 Multi-AZ、缺少快照。它廣泛但不深入，而且對所有帳號免費。Resilience Hub 以應用程式為範圍，衡量你宣告的 RTO/RPO 對照資源層級設定，並產生基於政策的「met / breached」判定。使用 Trusted Advisor 對整個帳號進行衛生掃描；使用 Resilience Hub 進行以 SLA 驅動的每個工作負載可靠性改善計畫。

將 session 移至 DynamoDB 會引入新的 SPOF 嗎？

DynamoDB 是區域性、Multi-AZ 的受管服務，因此將 session 移至 DynamoDB 實際上是減少 SPOF 數量，而非增加。你獲得的可靠性改善是：任何運算執行個體都可以服務任何使用者，且執行個體替換對使用者是透明的。唯一需要考慮的新面向是 DynamoDB 吞吐量——對 on-demand 資料表，吞吐量自動擴展；對 provisioned，你必須設定 auto-scaling，以防流量峰值導致 session 讀取被節流。這是朝著正確方向的可靠性改善取捨。

如何知道可靠性改善工作已經完成？

當 Resilience Hub 彈性政策中的每個項目都顯示「met」、目錄中的每個 FIS 實驗在生產負載下都能乾淨通過、每個配額都低於 70% 用量且有自動增加申請流程，以及每月 SLA 報告連續三個月顯示實際可用性穩定超過目標。可靠性改善在「永遠完成」的意義上從不算完成——但在「達到這個政策等級」的意義上算完成，下一輪可靠性改善循環只有在 SLA 目標本身提升時才會開始。

考試信號摘要

針對 SAP-C02 Domain 3 的可靠性改善考題，標準答案形式是：識別 SPOF 類別，選擇 AWS 原生的修復服務，說明為何停機時間最短，並透過評估和混沌驗證來證明修復效果。你必須建立反射動作的服務包括：AWS Resilience Hub（評估）、AWS Fault Injection Service（驗證）、Route 53 ARC（確定性容錯移轉）、RDS Proxy（連線彈性）、Multi-AZ 和每個 AZ 一個 NAT Gateway（基礎設施冗餘）、ASG mixed instance types 搭配 Capacity Rebalance（運算容量可靠性改善）、DynamoDB session store（無狀態層啟用），以及 Service Quotas 搭配 CloudWatch（主動限制可靠性改善）。掌握這組服務，可靠性改善考題就會變得確定性可解。