可靠性架構：Multi-AZ、Multi-Region 與鬆耦合

可靠性架構是一門設計學科，目標是讓系統在它實際會遭遇的所有故障範圍內持續兌現承諾——不只是那些罕見的大災難，更包括每小時都可能發生、爆炸半徑小卻積少成多的日常故障，這些故障共同決定了工作負載能否達到服務等級目標。在 SAP-C02 中，可靠性架構是任務聲明 2.4（「為新方案設計符合可靠性需求的策略」）的核心，同時也橫跨災難復原（2.2）、效能（2.5）與持續改善（3.x）。凡是題目中出現「99.99% 可用性」、「零資料遺失」、「必須在 AZ 故障後存活」或「必須處理突增 50 倍流量」這類數字，都是可靠性架構題——四個選項通常個個聽起來有說服力，卻只有一個符合 Well-Architected 可靠性原則。

本指南假設你已具備 Associate 等級的 HA 模式知識（Multi-AZ、ASG、ALB、RDS Multi-AZ），並聚焦於 Professional 層級的可靠性架構：Professional 深度的設計原則、故障模式分析、隔艙模式（bulkheads）與 Cell-Based Architecture、控制平面與資料平面韌性、相依性隔離、優雅降級、以 AWS 原生服務實作 Circuit Breaker、冪等性 Token、AWS Resilience Hub 量化評估、AWS Fault Injection Service 受控混沌工程、Route 53 Application Recovery Controller 明確容錯移轉，以及將 Service Quotas 視為第一類可靠性風險。本章最後以一個情境演練作結：一個付款平台必須同時達到 99.99% 可用性並保證零重複扣款。

為什麼可靠性架構在 SAP-C02 如此重要

Associate 等級考的是 HA 辨識——「選 Multi-AZ 的選項」。Professional 等級考的是你能否規劃可靠性預算：將 99.99% 可用性（每年 52.6 分鐘停機）轉化為具體設計決策、根據相依性拓樸選擇 Active-Active 或 Active-Passive，並說明每一分錢花在哪裡。考試要求你剔除那些「看起來」可靠、實則暗藏相依性陷阱的選項——例如「使用單一全球 DynamoDB 表」，卻未指出對該表的控制平面操作並非 Multi-Region。SAP-C02 的可靠性架構，重點在於相依性圖、故障範圍與復原機制的推理，而非服務細節的死背。

SAP-C02 可靠性題目中反覆出現四個模式：(1) 有狀態後端必須在 AZ 故障後零資料遺失；(2) 突發工作負載不能因重試風暴或配額耗盡而自我癱瘓；(3) Multi-Region 容錯移轉必須是明確且可稽核的，而非含糊和碰運氣；(4) 實驗必須在停機前就驗證容錯移轉能正常運作。知道每個模式對應的 AWS 推薦方案——分別是靜態穩定性、指數退避加 Jitter 加 DLQ 加 Service Quotas 監控、Route 53 Application Recovery Controller 路由控制、AWS Fault Injection Service——就是 700 分與 850 分之間的差距。

白話文解釋 Reliability Architecture

可靠性架構有很多相互重疊的術語——HA、DR、韌性、可用性、持久性、容錯。用台灣人熟悉的三個生活場景，讓這些抽象概念立刻變清晰。

類比一：醫院急診室

想像一間繁忙的急診室。可用性目標就是醫院承諾「你會在 N 分鐘內被診治」——承諾的等級越高，服務台後面就必須存在更多備援。故障模式分析是醫療主任每個月主持的死亡率與發病率檢討會：每一次可預防的失誤，哪裡出了問題、為什麼，以及怎樣的設計改善能防止重演。隔艙模式（Bulkheads）就是獨立的急救間——某一間急救間被多車事故塞爆，隔壁的兒科急救間仍能正常運作，因為它有自己的人員、設備與備品倉。Cell-Based Architecture 就是在全市各地開設多間完全獨立的急診室：一間醫院發生化學物質外洩，不會填滿全市每一間候診室，因為每個 Cell 都是自給自足的。控制平面 vs 資料平面是醫院行政辦公室（控制平面——排班、訂床）與真正在看診的護理師和醫師（資料平面）的差別；即使行政辦公室休息，資料平面也必須繼續運作。Circuit Breaker 是分流規則——當急診室滿載時停止接受非緊急病患，保護重症案例不被等待時間拖垮。冪等性 Token 是病患手環 + 就診 ID——無論急診混亂中護理師拿到同一份病歷幾次，也只會開一次帳單。AWS Fault Injection Service 是消防局長每季舉辦的演習：模擬大規模傷亡事件，測試備用發電機是否真的會啟動，而不是等真正的地震來測試。Route 53 Application Recovery Controller 路由控制就是牆上那個預先接好線路的「改叫救護車去 B 醫院」開關——一個動作，不用開會討論；這個機制被設計成就算所有電腦系統都掛掉也能運作。

類比二：連鎖門市備援機制

一個可靠的工作負載就像台灣的連鎖便利商店應急體系。總部會把全台門市分成若干獨立責任區——這就是隔艙模式（Bulkhead pattern）。某一區發生大停電，只影響該責任區內的門市，其他責任區照常營業。Cell 就像每家門市都有自己的備用倉儲與緊急發電機——即使總倉無法補貨，單店可以撐過一段時間，且每家店服務的客群不重疊，任何一家出事都不至於讓所有人撲空。Shuffle sharding 是門市補貨路線的設計：每家門市同時由兩條不同的物流車隊負責，如果其中一條車隊出問題，不是全部門市都斷貨，只有「恰好依賴那條車隊」的少數門市受影響，且因為路線是交叉分配的，任何兩家店同時受同一個問題影響的機率極低。相依性隔離是規定每個責任區有自己的冷凍機、備用電、通訊設備——某區冷凍機壞了，不會連累隔壁區的冷凍機跟著停。優雅降級是當部分品項缺貨時，門市仍正常開放、只是部分商品暫停販售，而不是直接關門。Service Quotas 配額風險就像每輛補貨車都有載重上限：如果沒人確認載重就硬塞進去兩倍的貨，車子在半途壞掉，配額不足的問題就此引爆，就算門市設計再好也沒用。

類比三：電力網格

AWS 工作負載就是一個區域電力網格。控制平面是電力公司的調度中心：決定哪些發電機上線、跨變電站分配負載、佈建新的電力連線。資料平面是真正把電流送到家裡的那些輸電線路。當颱風摧毀了調度中心大樓，你不希望每戶人家都跟著斷電——現有的電網拓樸繼續供電（靜態穩定性）。電力公司因此把電網設計成：即使調度中心失聯，資料平面仍能以最後已知的設定繼續運作。家裡的無熔絲開關（斷路器，Circuit Breaker）就是字面上的保險絲：烤麵包機短路跳某一個回路，只隔離那條線路的損壞，冰箱在另一回路照常運作。Route 53 ARC 路由控制是資料中心裡那個手動轉換開關：一個實體拉桿就能把負載從市電切換到發電機，而且這個機制被設計成就算所有電腦系統都失效也能運作。AWS Resilience Hub 是電網可靠性稽核——外部評估員帶著核對清單走遍整個設施，估算電力公司的 RTO 和 RPO 與其公告目標之間的差距，並回傳一份附有優先順序建議的評估報告。AWS Fault Injection Service 是電力公司內部的停電情境演練：刻意在某個週二下午跳開一個斷路器，確認備用變電站在 SLA 內接管負載，在冰風暴真正到來之前找出整合缺陷。

Professional 深度的可靠性設計原則 — 五大戒律

Well-Architected 可靠性支柱定義了五項設計原則。Associate 等級你把它們當清單背；Professional 等級你必須把每一條轉化為架構決策，並能辨識某個答案在哪裡違反了它。

原則一：自動從故障中復原

系統必須能偵測故障並在無人介入的情況下自我修復。在 AWS 上，這意味著：Auto Scaling Group 自動替換不健康的執行個體；ELB target group 健康檢查繞開不健康的任務；RDS Multi-AZ 自動容錯移轉至備用；Aurora Global Database 受管容錯移轉；Lambda 非同步呼叫自動重試並附 DLQ；Step Functions Retry 區塊；EventBridge 與 SQS redrive。SAP-C02 的陷阱是：依賴人員閱讀 PagerDuty 告警才啟動復原的答案——除非情境明確允許手動容錯移轉且 RTO 足夠寬裕，否則直接剔除。

更細緻的 Professional 層級重點是：偵測也必須自動化，且必須區分暫時性與持久性故障，才不會讓復原動作反而放大問題（過於激進的健康檢查不斷重啟一個抖動的執行個體，導致容量崩潰）。

原則二：測試復原程序

可靠性只有在容錯移轉被實際演練後才存在。在 AWS 上，這意味著：透過 EventBridge 排程 GameDay；在 CI/CD 中加入 AWS Fault Injection Service 實驗範本；實際透過 Route 53 ARC 路由控制切換流量進行跨 Region 容錯移轉演練；定期執行附有韌性政策的 AWS Resilience Hub 評估；透過 Amazon CloudWatch Synthetics 或第三方監控從多個 Region 發出合成探針，端對端驗證容錯移轉路徑。

文件上說「我們可以容錯移轉」但近期沒有實際演練，這不算可靠性；SAP-C02 會懲罰輕信這點的考生。當題目說「如何在不影響正式環境流量的前提下定期驗證 DR 計畫」，預期答案是附有停止條件（stop conditions）告警的 AWS FIS。

原則三：水平擴展以提升整體工作負載可用性

用多個小資源取代一個大資源，使單一故障只移除一小部分容量。Professional 層級對此原則的理解是故障隔離，而非只是吞吐量提升——Shuffle Sharding 將這個概念推到極致：將每位客戶分配到隨機的小型副本子集，使單一惡意鄰居影響特定客戶的機率呈幾何級數下降。

在 AWS 上：跨多個 Availability Zones 分散工作負載（永遠要做）、執行多個小型 Cell 而非一個巨型叢集、依客戶 ID 分片資料庫、使用 Route 53 加權路由將流量分散至各 Cell。當某個答案建議用單一垂直擴展的超大執行個體作為可靠性解法，它違反了這條原則。

原則四：停止猜測容量

猜測會導致兩種故障——滿載崩潰，或閒置浪費成本。在 AWS 上，這對應：Auto Scaling（目標追蹤、步階擴展、預測性擴展）；DynamoDB 隨需或附自動擴展的佈建模式；Aurora Serverless v2；Lambda 彈性並行數；SQS 緩衝架構將突發生產者與受限消費者解耦；Spot Fleet 處理容錯彈性批次工作。這項原則同時要求你測量實際的需求訊號（CloudWatch Contributor Insights 追蹤 RequestId 維度、ALB 每目標請求數），而非只看與流量相關性差的 CPU 使用率告警。

Professional 深度的陷阱：「彈性」服務仍有配額——Lambda 並行數、每 Region 的 Fargate 任務數、API Gateway 每秒請求數。如果你的配額還是舊的猜測值，就算用了彈性服務也無濟於事。Service Quotas 監控（本章稍後介紹）正是為了補上這個漏洞。

原則五：透過自動化管理變更

變更必須透過具備自動回滾的自動化流程套用，而非手動操作。在 AWS 上：附有 change sets 的 CloudFormation（以及 StackSets）；附有 pipeline 的 AWS CDK；附有 CloudWatch 告警觸發回滾的 CodeDeploy 藍/綠與金絲雀部署；附有驗證 Lambda 與 CloudWatch 告警回滾的 AWS AppConfig 功能旗標；透過 EC2 Image Builder 產生不可變 AMI；透過 ECR image tags 管理不可變容器映像。無論操作人員多謹慎，手動在正式環境執行 aws ec2 modify-instance 都是可靠性的反模式。

更難的 Professional 深度體現是變更頻率：頻繁的小型變更每次都由自動化回滾守護，遠比季度大型版本發布更好。考試的框架通常是：「一次部署導致 p99 延遲上升——什麼機制能自動回滾？」——答案是 CodeDeploy 金絲雀加上 CloudWatch 複合告警，而非「值班工程師手動還原變更」。

故障模式分析 — 從停機倒推設計

故障模式分析（FMA）或其更量化的版本——故障模式與影響分析（FMEA）——是一套結構化方法：逐一走過每個元件，找出每種可能的故障模式，並問三個問題：發生了什麼、如何偵測、如何復原。SAP-C02 幾乎不要求你直接產出 FMA 表格，但題目本身經常是從 FMA 表格衍生出來的——「RDS 主節點無法存取」、「某 AZ 的 NAT Gateway 降速」、「上游 SaaS 相依服務有 10 分鐘 3 秒延遲」。腦中已對參考架構走過 FMA 的考生，能在幾秒內排除錯誤答案。

完整的 FMA 應覆蓋每個工作負載的以下類別：

• 硬體故障：單一 EC2 執行個體、單一 EBS Volume、單一 AZ、單一 Region。緩解方法：ASG 跨 AZ 分散、Multi-AZ 資料庫、Tier 1 工作負載採 Multi-Region。
• 相依性故障：下游服務回傳 5xx、速度變慢或沉默。緩解方法：逾時設定、指數退避加 Jitter 重試、Circuit Breaker、DLQ、優雅降級。
• 配額耗盡：Lambda 並行數、Fargate 任務數、API 限流、資料庫連線池、KMS 請求數。緩解方法：Service Quotas 監控與配額使用率 CloudWatch 告警、主動申請調高。
• 部署失敗：程式碼缺陷、設定錯誤、Schema 不符。緩解方法：藍/綠、金絲雀、告警觸發自動回滾、AppConfig 功能旗標。
• 流量突增：Slashdot 效應、行銷活動啟動、惡意攻擊。緩解方法：ASG 加上 SQS 請求緩衝、API Gateway 限流、CloudFront 快取、以速率為基礎的 WAF 規則。
• 資料損壞：程式碼缺陷、錯誤的資料遷移、勒索軟體。緩解方法：時間點還原、附 MFA-delete 的 S3 版本控制、AWS Backup Vault Lock（WORM）、跨帳號備份。
• Region 故障：極為罕見，但爆炸半徑極大。緩解方法：Multi-Region Active-Active 或 Pilot Light，並記錄 RTO/RPO。

考試的測驗方式通常是：給定這個情境，目前架構中哪一種故障模式尚未被處理？找到它需要用 FMA 的思維推理，而非靠服務細節的死背。

隔艙模式與 Cell-Based Architecture

隔艙模式將故障隔離，使某個子系統的問題不會拖垮相鄰的子系統。Professional 等級的考試區分三種層次。

服務內隔艙（執行緒池、連線池、佇列）

在單一服務內，針對每個下游相依服務分開資源池。如果服務 A 同時呼叫服務 B 和服務 C，分別給每條呼叫鏈獨立的執行緒池與連線池，這樣 B 的速度下降就不會耗盡 C 需要的資源池。在 AWS 原生服務上，這意味著：每個關注點使用獨立的 Lambda 函式、每個工作流程階段使用獨立的 SQS Queue、每個租戶使用獨立的 RDS Proxy 目標——而非讓一個共用的超大資源池成為故障邊界。

服務層級隔艙（依關注點拆分服務）

拆解單體架構，使爆炸半徑以服務為邊界。「圖片縮放」微服務故障，不應拖垮「使用者登入」。這是帶有明確可靠性理由的微服務設計思維。

Cell-Based Architecture（完整堆疊複製）

Cell 是完整、獨立的工作負載實例（運算 + 快取 + 資料庫），服務互不重疊的流量子集。考試的典型例子：針對 1,000 萬個客戶，不是執行一個巨型 DynamoDB 表與一個 Lambda 叢集，而是執行八個每個服務 125 萬個客戶的 Cell。某個毒化事件損壞了某 Cell 的 DynamoDB 表，只影響八分之一的客戶，而非全部。搭配 Shuffle Sharding——將每位客戶分配至偽隨機的 Cell 子集，使任意兩位客戶的 Cell 交集極小——任何單一 Cell 故障對任意給定客戶對的影響在統計上可以忽略不計。

在 AWS 上實作 Cell 通常使用：Route 53 延遲或加權路由依客戶 ID Hash 將客戶導向「屬於他們的」Cell；API Gateway 搭配自訂網域與每 Cell 的 stage variables；每個 Cell 使用獨立的 VPC 或獨立的帳號來隔離爆炸半徑；一個薄的「Cell 路由器」Lambda 重寫 Cell 分配表。近期 Amazon Builders' Library 論文詳細介紹了這個模式。

控制平面 vs 資料平面韌性

Professional 等級的 AWS 考試要求你理解：每個 AWS 服務都有控制平面與資料平面，且它們有不同的可用性特性。控制平面執行可變更操作（建立叢集、修改執行個體、建立儲存桶、註冊目標），通常是可用性較低、狀態更複雜的 API。資料平面為已佈建資源提供流量服務（執行 Lambda、讀取 S3 物件、查詢 DynamoDB 項目、解析 DNS），是 AWS 工程可用性最高的那一層。在停機情境中，AWS 優先保護資料平面可用性。

Professional 深度的規則是：永遠不要讓你的容錯移轉計畫依賴控制平面 API。 範例：

• Route 53 記錄集更新是控制平面。在 Region 級別容錯移轉情境中，你無法依賴 UpdateHealthCheck 或 ChangeResourceRecordSets 在受影響的 Region 上正常運作，即使是全球範圍，控制平面也比資料平面慢。應使用 Route 53 Application Recovery Controller 路由控制——路由控制資料平面分散於五個 Region，即使大部分 AWS 服務無法存取，UpdateRoutingControlState 仍能正常回應。
• DynamoDB Global Tables 透過資料平面複製資料——如果應用程式能存取另一個 Region，讀寫即可在 Region 故障後存活。建立新表是控制平面操作，在事件期間可能無法使用——因此在需要之前就預先建立所有表。
• Auto Scaling 啟動新執行個體是控制平面活動。靜態穩定的架構會在每個 AZ 預先佈建足夠容量，使 AZ 故障後不需啟動新執行個體就能存活——否則，AZ 事件期間全 Region 同時搶著啟動，會讓所有人的 EC2 RunInstances API 都遭到限流。
• IAM 角色建立與政策變更是控制平面；資料平面（評估請求上已掛載的角色）仍然正常運作。不要設計需要在容錯移轉期間建立新角色的流程。
• AWS KMS 有資料平面（使用現有金鑰加解密）與控制平面（CreateKey、EnableKey）之分。Multi-Region KMS 金鑰是跨 Region 容錯移轉的正確選擇，正是因為資料平面在兩個 Region 都能以同一個共用金鑰 ID 正常運作。

架構上的結論是：你的容錯移轉動作應該是單一翻轉（一個 ARC 路由控制切換、一次 AppConfig 功能旗標變更、一個預先佈建的 Global Accelerator Endpoint 權重變更）——而非一連串的佈建 API 呼叫。

相依性隔離與優雅降級

成熟的可靠性架構假設每個相依服務都會故障，並設計成降速但仍運作，而非全有或全無。

相依性隔離技術

• 對每個對外呼叫設定逾時，並設在呼叫者本身逾時預算之內。如果服務 A 有 2 秒 SLA 並呼叫 B，呼叫 B 的逾時必須遠低於 2 秒，這樣即使 B 掛起，A 仍能在 SLA 內回應。
• 指數退避加 Jitter 重試。AWS SDK 預設實作了這項機制；自訂客戶端必須跟進。Jitter 這部分至關重要——數千個客戶端的同步重試會製造雷群效應，把 100 毫秒的短暫中斷放大成數分鐘的停機。
• 有界的重試次數加上 DLQ / Dead-Letter 目標。SQS DLQ 在 N 次接收嘗試後介入；Lambda 非同步呼叫失敗目標；Step Functions Retry 區塊搭配 MaxAttempts。
• 非同步耦合，在延遲允許的情況下透過 SQS 或 EventBridge 實作。同步 API 呼叫將呼叫者可用性與被呼叫者可用性綁在一起；事件驅動模式會緩衝被呼叫者的停機，不讓它升級為呼叫者的停機。
• 快取最後一次成功的回應，使短暫的相依服務停機對呼叫者透明不可見。CloudFront、ElastiCache 或帶有 TTL 的進程內快取。

優雅降級策略

當相依服務真的無法存取且快取無法彌補時，設計讓服務繼續提供縮減版體驗而非回傳 5xx：

• 如果定價服務無法存取，顯示昨天的快取價格並附上「價格最後更新時間：X 小時前」的提示橫幅。
• 如果推薦引擎掛掉，跳過個人化排序，改回傳一份熱門商品清單。
• 如果詐欺偵測引擎速度緩慢，將付款接入待處理佇列並非同步確認，並主動告知客戶。
• 回傳 200 OK 加上縮減的 payload 與 X-Degraded: true 回應標頭，而非 503。

考試通常將優雅降級框架為「必須在下游服務停機 15 分鐘內保持可用」——預期答案結合了非同步佇列、快取回退與操作員可透過 AppConfig 切換的功能旗標。

AWS 原生 Circuit Breaker（Step Functions Retry + Catch + DLQ）

Circuit Breaker 阻止對故障的相依服務持續轟炸，讓它有機會復原，同時呼叫方改用回退或佇列模式。語言層級的 Circuit Breaker 函式庫（Hystrix、Resilience4j）固然存在，但 SAP-C02 要求你用 AWS 原生服務建構相同行為。

標準 AWS 模式：

1. 同步呼叫相依服務，設定緊密的逾時。
2. Step Functions Retry 區塊，使用指數退避（BackoffRate = 2）並限制 MaxAttempts。這是故障後偶爾嘗試的「半開路」Circuit Breaker。
3. Step Functions Catch 區塊，將持久性故障路由到回退分支——傳送至 SQS DLQ、呼叫降級模式 Lambda、將故障記錄至 DynamoDB 供後續對帳、只有在積壓增長時才觸發值班告警。
4. 在工作流程允許非同步的情況下，在相依服務前方放置 SQS 或 EventBridge 緩衝。當相依服務速度變慢，消費者會因 SQS 可見性逾時與 Lambda 並行限制自然產生背壓，自動節流。
5. 相依服務錯誤率的 CloudWatch 告警觸發 AppConfig 功能旗標切換，讓呼叫方進入降級模式——這是一個對所有執行個體可見的軟體定義 Circuit Breaker，無需部署。

同時具備 Retry 與 Catch 子句的 Step Functions 狀態，本質上就是一個 Circuit Breaker。Retry 以退避機制處理暫時性故障；Catch 在重試耗盡時，透過路由到回退狀態來處理——持久化請求、排入佇列等待重新處理，或回傳降級回應。

冪等性 Token — 讓重試安全

重試對可靠性至關重要，但對非冪等操作（刷信用卡、寄送電子郵件、扣除庫存）的天真重試會造成重複執行。冪等性 Token 是「積極重試」與「絕不重複扣款」之間的橋樑。

機制：客戶端產生唯一的冪等性金鑰（UUID v4 或請求的 Hash），並在每次嘗試時附帶。伺服器在持久化儲存中記錄「已處理金鑰 K → 結果 R」；帶有金鑰 K 的重複請求直接回傳 R，不重新執行。記錄上的 TTL 使儲存空間有限。

AWS 原生冪等性機制：

• DynamoDB 條件式寫入，使用 attribute_not_exists(idempotency_key) 作為條件。第一次寫入成功；後續寫入條件失敗，Handler 回傳已儲存的結果。
• SQS FIFO Queue 搭配 MessageDeduplicationId——5 分鐘視窗內相同 Deduplication ID 的訊息被視為重複並只投遞一次。
• AWS Lambda Powertools Idempotency 模組（支援 Python、Node、Java、.NET），透明地將冪等性記錄儲存在 DynamoDB，只需一個標記。
• API Gateway 支援 Client 請求冪等性 Token 作為標頭；整合層將其轉發至後端。
• AWS 付款 SDK（適用於涉及金錢的多個 AWS 服務——RDS 保留執行個體購買、Compute Savings Plans）在建立 API 上明確支援冪等性 Token。

冪等性金鑰必須在第一次嘗試之前產生，並在每次重試時重複使用，包括客戶端崩潰後的重試。如果客戶端在重試時重新產生金鑰，重複處理的問題就會復發。在持久化的地方（客戶的瀏覽器 localStorage、嵌入金鑰的 SQS 訊息）儲存金鑰是設計的一部分。

AWS Resilience Hub — 量化可靠性評估

AWS Resilience Hub 是用於定義、評估並改善應用程式韌性的受管服務，以結構化、可重複的方式進行。在 SAP-C02 中，Resilience Hub 出現在情境談及「定期評估韌性狀態」、「以政策驅動的 RTO/RPO 目標」或「達到目標的建議」時。

韌性政策

韌性政策是第一類物件，為每種中斷類型設定 RTO 和 RPO 目標：Application、Infrastructure、AZ 與 Region。你設定目標（例如，Application RTO = 30 分鐘、AZ RPO = 1 分鐘、Region RTO = 4 小時、Region RPO = 15 分鐘）並將政策附加至應用程式。該政策成為可量測的合約。

評估

評估針對應用程式定義執行（可從 CloudFormation、Terraform、Resource Groups 或 AppRegistry 匯入），並回傳每種中斷類型的估計 RTO 和 RPO，加上政策符合性裁決。如果應用程式使用 RDS 單 AZ，AZ RTO 估計可能是 30 分鐘，標記為不符合 5 分鐘目標。

建議

針對每個落差，Resilience Hub 提出修復範本——例如「在 RDS 執行個體 X 啟用 Multi-AZ」、「為 Y 新增 CloudWatch 告警」、「匯出 Runbook 文件 Z」。建議分類為 application、alarms 與 runbooks，並附有估計的成本影響。

Resilience Hub + AWS Fault Injection Service 整合

Resilience Hub 產生的測試建議可轉換為 AWS FIS 實驗範本，形成閉環：政策說「AZ RTO 5 分鐘」，評估說「估計 4 分鐘，符合」，而 FIS 實驗透過注入 AZ 故障並測量實際復原時間，來驗證這個估計值。

考試中，當題目提到「持續評估架構是否符合目標 RTO 和 RPO」或「產生優先排序的可靠性改善建議」時，預期答案是 Resilience Hub——不是手工試算表或 Trusted Advisor 檢查。

AWS Fault Injection Service — 受控混沌工程

混沌工程是在正式環境（或預正式環境）注入受控故障、驗證系統實際行為是否符合設計者宣稱的學科。AWS Fault Injection Service (FIS) 是在 AWS 資源上執行混沌實驗的受管服務，無需自行撰寫故障注入工具。

實驗範本

FIS 實驗範本宣告：

• Actions（動作）——要注入的故障。範例：aws:ec2:stop-instances、aws:ec2:terminate-instances、aws:ec2:reboot-instances、aws:rds:failover-db-cluster、aws:rds:reboot-db-instances、aws:ecs:stop-task、aws:eks:pod-cpu-stress、aws:fis:inject-api-throttle-error、aws:fis:inject-api-internal-error、aws:fis:inject-api-unavailable-error、aws:network:disrupt-connectivity、aws:ssm:send-command（自訂故障的任意 SSM 文件）。
• Targets（目標）——要套用動作的資源。以資源 ID、標籤篩選器或資源類型加選取模式（ALL、COUNT、PERCENT）選定。
• Stop conditions（停止條件）——一旦違規就自動終止實驗的 CloudWatch 告警。這是區別 FIS 與魯莽混沌的關鍵安全護欄。
• Log configuration（日誌設定）——實驗事件傳送至 CloudWatch Logs 或 S3 以供稽核。

爆炸半徑控制

FIS 將實驗範圍限制在你指定的目標，但真正的爆炸半徑由以下方式控制：

• 目標選取模式——從單一執行個體（COUNT: 1）開始，然後逐步升至百分比。
• 停止條件——p99 延遲或錯誤率的告警必須在故障注入開始傷害真實使用者時自動停止實驗。
• 先在非正式環境設定範圍，然後在正式環境的單一 Cell，再逐步擴大。
• IAM 實驗角色——使用範圍限定在受測資源的專用服務角色，而非管理員角色。

新的 SSM 支援故障動作

近期 FIS 版本使用 SSM 文件注入 AWS API 呼叫的 API 限流與內部錯誤，模擬 Region 服務降速而不實際對 AWS 施加壓力——客戶端看到錯誤，從而驗證呼叫方的重試與 Circuit Breaker 行為。

FIS 在 CI/CD 中

韌性不能只靠「每季 GameDay 跑一次」——它必須是持續的。團隊通常在每次發布 Pipeline 的 Staging 環境中執行部分 FIS 實驗（與金絲雀部署並行的金絲雀實驗），並定期對正式環境進行更大規模的 GameDay 實驗（每月），全程保持值班人員在線。

Route 53 Application Recovery Controller — 路由控制與就緒檢查

Route 53 Application Recovery Controller (ARC) 是明確、可稽核、以資料平面韌性為核心的容錯移轉機制，適用於無法容忍隱式 DNS 容錯移轉的應用程式。它建立在 Route 53 之上，但架構上截然不同。

路由控制 — 「大紅色開關」

路由控制是一個狀態（On 或 Off），透過 ARC 控制 API 翻轉。該 API 有一個跨五個 Region 的叢集資料平面，被設計成在大規模 AWS 事件期間仍保持可用。Route 53 記錄使用綁定至路由控制狀態的健康檢查——當路由控制切換為 Off，Route 53 立即停止路由至相關端點。

路由控制被分組到控制面板中，控制面板可以設定安全規則（斷言規則與閘道規則），防止意外停機——例如「us-east-1 或 us-west-2 路由控制中至少有一個必須為 On」，防止操作員在慌亂中同時將兩者切換為 Off。

就緒檢查 — 起飛前驗證

就緒檢查持續檢查備援 Region 中的一組資源，並回報它們是否確實已準備好接收流量。受檢資源包括 DynamoDB 表（複製狀態）、RDS 執行個體（可用性）、NLB/ALB（執行個體健康）、Auto Scaling Group（容量）、Lambda（已設定的別名）、IAM 角色、KMS 金鑰等——覆蓋 100+ 種資源類型。就緒檢查是設定層面的檢查，而非即時流量測試；它告訴你備援端是否在結構上等同於主端。

路由控制 vs Route 53 健康檢查

標準 Route 53 健康檢查探測端點 URL；探測失敗觸發 DNS 切換。這有兩個 Professional 層級的弱點：

1. 健康檢查可能過於敏感（單一 500 回應就讓檢查失敗）或過於寬鬆（降速的服務在 /health 仍回傳 200）——調校困難，且 DNS 變更是隱式的。
2. 健康檢查依賴 Route 53 控制平面傳播遵循 TTL 的更新——在 Region 級別停機期間並不理想。

路由控制是由人員或自動化明確翻轉的開/關切換器，由一個專為這個時刻設計的資料平面支撐。就緒檢查確保你切換到的備援端確實已就緒。

Route 53 ARC 是 SAP-C02 的答案，當情境說「明確的容錯移轉」、「不能依賴自動 DNS 健康檢查」、「防止意外容錯移轉的安全規則」、「誰啟動容錯移轉的稽核日誌」或「切換前確認備援端已就緒」。如果情境允許簡單的健康檢查式 DNS 容錯移轉，Route 53 ARC 就是大材小用。

Service Quotas 作為第一類可靠性風險

可靠性不只死於硬體故障——也死於配額耗盡。一個 Multi-AZ、Multi-Region、自動擴展、Shuffle Sharding 的工作負載，仍可能因為有人忘記在黑色星期五流量前調高 Lambda 並行限制而停機。SAP-C02 將配額視為可靠性關注點。

配額分類

• 軟配額（可調整）——透過 Service Quotas 主控台或 API 申請調高。大多數帳號/Region 配額屬於軟配額。
• 硬配額（不可調整）——例如每 Region 最多 5 個 VPC 是軟配額，但每個路由表最多 100 個路由條目長期是硬配額（近期才調高）。記住硬配額的項目。
• 每帳號 vs 每 Region vs 每資源——Lambda 並行數是每 Region 每帳號（所有函式加總）；KMS 請求速率是每金鑰每 Region；DynamoDB 表 WCU/RCU 是每表。

AWS Service Quotas 服務

Service Quotas 服務集中管理可見性與申請：

• 列出所有服務配額（帳號/Region 維度）。
• 直接透過主控台或 RequestServiceQuotaIncrease API 申請調高。
• CloudWatch 指標追蹤配額使用率——Service Quotas 為支援的指標發布 ResourceCount 與配額值，讓你可以設定在配額 80% 時觸發的告警，主動申請調高。
• 自動化配額調高申請——透過 EventBridge 規則監聽 80% 告警，呼叫 Lambda 提出申請。
• 與 Trusted Advisor 整合——服務限制檢查會標記接近配額的資源。

架構時的配額設計

架構設計時，你必須：

• 列舉架構依賴的所有配額：Lambda 並行數（保留 vs 突增）、每 Region Fargate 任務數、每執行個體系列 EC2 vCPU 數、API Gateway 每秒請求數、每 Region DynamoDB 表數、每金鑰每秒 KMS 請求數、每 Event Bus EventBridge 規則數、SES 發送速率、SNS 訊息速率。
• 用峰值流量 × 扇出與這些配額比對。預設 1,000 並行數的 Lambda 在 10 倍流量突增下，在 1,000 的牆壁前撞停——重試風暴放大積壓。
• 針對可預見的流量高峰主動申請調高，而非在當天事發後才反應。
• 對使用率設定告警，讓緩慢增長在成為事故前就可見。
• 使用 Resilience Hub 或 Trusted Advisor 在可靠性評估中浮現配額落差。

考試的典型跡象：「應用程式在負載測試中運作正常，但在正式環境流量增加後失敗」、「新 Region 擴展在部署時突然遭到限流」、「設定錯誤的重試迴圈耗盡了整個 Region 的並行數」——這些都是 Service Quotas 問題，標準答案涉及 Service Quotas 告警、主動調高限制申請，以及隔離並行數的架構（每函式保留並行數、API Gateway 的每租戶節流桶）。

情境演練 — 付款平台，99.99% 可用性，零重複扣款

考慮這個典型的 SAP-C02 風格情境：

一家金融科技公司正在建立新的付款平台。業務要求 99.99% 可用性（每年 52 分鐘停機預算）、任何故障模式下零重複扣款、每次容錯移轉的完整稽核軌跡，以及受控混沌測試以驗證設計。請設計此平台架構。

這個情境幾乎涵蓋了本章的每個概念。完整地走一遍。

1. 可用性目標轉化為架構

單一 Region 架構在 AWS 上達到 99.99% 可用性是可行的，但沒有任何餘裕。謹慎的設計對熱路徑（信用卡授權）採用 Multi-Region Active-Active，以 Multi-AZ 作為內環。兩個 Region 為主與副，正常情況下以延遲路由分流流量，事故期間透過 Route 53 ARC 路由控制明確切換。

2. 資料層 — 防止重複扣款

零重複扣款首先是冪等性需求，其次才是複製需求。

• 冪等性金鑰由商家客戶端產生，並在付款 API 處驗證。DynamoDB 條件式寫入對 payment_intent_id 使用 attribute_not_exists，確保第一次寫入獲勝。
• DynamoDB Global Tables 在各 Region 間複製付款意圖。因為 Global Tables 使用最後寫入者獲勝的衝突解決，設計金鑰使同一筆付款永遠不會從兩個 Region 同時寫入（依商家 ID 分區到 Region）。
• Aurora Global Database 用於帳本（關聯式、交易性），主節點在一個 Region，另一個 Region 有讀取副本。受管計畫容錯移轉在 60 秒內處理 Region 切換。
• Outbox 模式——每筆付款在同一個交易中寫入 DynamoDB 加上 Outbox 事件；Stream 處理器向下游卡片網路發布，並對網路的 PSP API 保持自身的冪等性。

3. 運算層

• API Gateway 作為付款 API 前端，搭配 WAF 進行惡意行為速率限制。
• Lambda 處理授權流程，每個租戶使用保留並行數，防止某個吵雜的商家耗盡資源池。
• Step Functions 協調多步驟流程（授權 → 風險評估 → 撥款），帶有 Retry（對暫時性卡片網路錯誤的指數退避）與 Catch（持久性故障時回退到待持 pending-and-reconcile）。Catch 路徑將記錄寫入 DynamoDB 並附上 pending_reconciliation 旗標，並排入 SQS 供非同步對帳工作者處理——這就是 Circuit Breaker 模式。
• SQS FIFO，MessageDeduplicationId = 冪等性金鑰，保護非同步對帳免於重複處理。

4. 故障隔離

• Cell-Based Architecture：每個 Region 8 個 Cell，商家透過 cell = hash(merchant_id) % 8 確定性地映射到某個 Cell。一個毒化程式碼缺陷損壞了 Cell 3 的狀態，只影響一個 Region 八分之一的商家。
• 卡片網路相依性的 Shuffle Sharding：每個 Cell 連接到卡片網路 8 個端點中隨機選取的 2 個，因此降速的端點只影響選了它的 Cell。
• Lambda 內的隔艙執行緒池——卡片網路 A 和 B 各有獨立的 HTTP 客戶端，具備獨立的逾時和重試預算。

5. 容錯移轉機制 — Route 53 Application Recovery Controller

• 兩個 Region 的路由控制，集中在一個控制面板下。
• 安全規則：「us-east-1-on 和 us-west-2-on 中至少有一個必須為 On」。這防止操作員在恐慌時同時將兩者切換為 Off。
• 就緒檢查：DynamoDB Global Table 複製延遲、Aurora Global Database 副本可用性、備援 Region 的 Lambda 保留並行數、SQS 佇列存在性、KMS Multi-Region 金鑰運作狀態。
• 容錯移轉透過 ARC 資料平面翻轉一個路由控制為 Off（跨五個 AWS Region 可存取，即使在大規模事件期間）。

6. 混沌工程 — AWS Fault Injection Service

• 實驗一：停止某 AZ 的 ECS 任務（aws:ecs:stop-task，依 AZ 標籤選取目標），停止條件 = p99 授權延遲 > 1 秒持續 2 分鐘。預期結果：ALB 切換到健康 AZ，p99 短暫波動 < 500 毫秒。
• 實驗二：透過 aws:fis:inject-api-internal-error 模擬卡片網路 5xx，停止條件 = 付款成功率 < 99%。預期結果：Circuit Breaker 跳開，待對帳佇列增長，客戶收到「處理中」回應而非 500。
• 實驗三：每季全 Region 容錯移轉 GameDay——將 us-east-1 路由控制切換為 Off，測量復原時間。停止條件 = 任何客戶 5xx > 0.1% 超過 30 秒。如果容錯移轉本身成為事故，自動停止。

7. Resilience Hub

• 韌性政策：Application RTO 5 分鐘 / RPO 30 秒；AZ RTO 1 分鐘 / RPO 0；Region RTO 5 分鐘 / RPO 60 秒。
• 針對 CloudFormation 定義的應用程式每週評估。任何漂移透過 EventBridge 通知至 Slack。
• 評估建議納入待辦清單；從建議產生 FIS 實驗範本。

8. Service Quotas

• 在兩個 Region 主動申請調高 Lambda 並行數（保留 ≥ 峰值商家負載 × 2）。
• 對架構依賴的每個配額設定 CloudWatch 告警在 80% 時觸發。
• 備援 Region 配額作為 Route 53 ARC 就緒檢查的一部分驗證。

9. 變更管理

• 所有基礎設施以 CloudFormation + CodePipeline 管理；變更透過藍/綠 ECS 或 Lambda 別名金絲雀搭配 CodeDeploy 部署；p99 延遲或 5xx 的 CloudWatch 複合告警觸發自動回滾。
• AppConfig 功能旗標用於零環（Ring-0）行為切換（Circuit Breaker 閾值、優雅降級模式）。

最終的架構昂貴、複雜，而且正確。在考試中，遺漏任何一個支柱的答案——缺少冪等性、使用隱式健康檢查 DNS 容錯移轉、沒有就緒檢查、沒有混沌實驗、沒有配額監控——即使其他所有部分都正確，也是錯誤答案。

監控與可觀測性支撐可靠性

可靠性架構在沒有測量的情況下是不完整的。監控層必須證明 SLO 正在被滿足，並在違規前浮現領先指標。

• CloudWatch 儀表板，每個 Cell 與每個 Region 各一份，附有 SLO 消耗速率圖表（本小時消耗的錯誤預算百分比 vs 允許值）。
• 複合告警結合多個訊號——p99 告警加 5xx 告警加合成金絲雀告警——以減少誤報。
• CloudWatch Synthetics 金絲雀從多個 Region 探測端對端使用者旅程，獨立於內部健康檢查。
• CloudWatch Contributor Insights 分析請求日誌，偵測最高使用量來源與熱分區。
• AWS X-Ray 分散式追蹤，測量相依服務延遲與重試速率。
• EventBridge 規則監聽 aws.health 事件，接收 AWS 服務健康儀表板通知。
• Route 53 ARC 路由控制狀態變更記錄至 CloudTrail，提供每次容錯移轉決策的稽核日誌。

Professional 深度的細微之處是測量正確的 SLI——不是「CPU 使用率」，而是使用者可見的延遲百分位數、成功率與錯誤預算消耗。

FAQ — 可靠性架構熱門問題

Q1：高可用性、災難復原與可靠性有什麼差別？

**高可用性（HA）**是系統在常見小規模故障期間持續提供服務請求的特性——一個執行個體死亡、一個 AZ 降速。HA 以正常運作時間百分比衡量，透過 Multi-AZ 冗餘、ASG、ELB、RDS Multi-AZ 處理。**災難復原（DR）**是從罕見大規模事件（Region 遺失、資料損壞、勒索軟體）復原的計畫，以 RTO（復原時間）和 RPO（可接受的資料遺失量）衡量。DR 透過 Multi-Region 複製、備份與容錯移轉 Runbook 處理。可靠性是更廣泛的 Well-Architected 支柱，涵蓋 HA 和 DR，以及相依性隔離、優雅降級、變更管理、測試與配額規劃。在 SAP-C02 中，可靠性題目可能觸及 HA、DR 或周圍的學科；災難復原題目是可靠性題目中專注於 RTO/RPO 驅動設計的特定子集。將本主題與 disaster-recovery-pro-patterns 主題搭配學習，涵蓋兩個視角。

Q2：什麼時候選 Route 53 ARC 路由控制，什麼時候選一般 Route 53 健康檢查？

當工作負載能容忍隱式容錯移轉、復原時間容忍度符合 DNS TTL 傳播，且不需要可稽核的人工啟動開關時，使用一般 Route 53 健康檢查。以下任一情況適用時，使用 Route 53 Application Recovery Controller 路由控制：工作負載需要明確、可人工稽核的容錯移轉（金融服務、醫療保健）；容錯移轉必須在受影響 Region 的 Route 53 控制平面中斷時仍能存活；需要安全規則防止意外同時容錯移轉；或切換前必須透過就緒檢查確認備援端已準備好。Route 53 ARC 的成本不低（叢集費用加每次檢查費用），因此不是預設選項——但對於明確容錯移轉需求的 99.99%+ 工作負載，它是正確的選擇。

Q3：Cell-Based Architecture 與簡單的微服務有什麼差別？

微服務依功能邊界拆解單體——使用者服務、訂單服務、付款服務——讓團隊可以獨立交付，且爆炸半徑以功能為邊界。Cell-Based Architecture 依租戶或流量邊界拆解——Cell A 服務客戶 0-100 萬、Cell B 服務 100-200 萬——讓爆炸半徑以客戶群組為邊界，無論 Cell 內哪個微服務故障都一樣。單一工作負載通常兩者都用：每個 Cell 內有數個微服務，Cell 邊界增加了第二個隔離維度。Shuffle Sharding 在此之上疊加第三層，將每位客戶分配到隨機的 Cell 子集，降低成對客戶故障相關性。在 SAP-C02 中，當題目強調「吵雜鄰居客戶不應影響其他客戶」或「單一程式碼缺陷不應導致所有租戶停機」時，Cell 模式是答案。

Q4：韌性訊息傳遞如何在 SQS Standard Queue、SQS FIFO 與 EventBridge 之間選擇？

SQS Standard 是最高吞吐量、至少一次、無序佇列。用於不需要順序且冪等性可處理偶爾重複的非同步工作。搭配 DLQ 隔離毒訊息。SQS FIFO 是每群組有序且恰好一次（5 分鐘去重視窗內）。用於付款帳本、狀態機或任何在租戶內需要順序的工作負載。吞吐量上限為每 API 動作加批次後每秒 3,000 則訊息，這可能是一個限制。EventBridge 是扇出、基於內容的路由、Schema 登錄、跨帳號與跨 Region 事件流的事件匯流排。當多個獨立消費者都需要對同一事件做出反應，且生產者不應知道消費者時使用。可靠性層面，EventBridge 以可設定的重試政策與每個目標的 DLQ 重試傳遞至目標。對於本章前面的付款情境，SQS FIFO 是正確的佇列，因為順序與去重很重要；對於「卡片網路發出事件 → 通知 4 個內部系統」的模式，EventBridge 是正確的。兩者結合使用——EventBridge 路由事件，每個目標是消費者擁有的 SQS FIFO 佇列——可以兼得兩者的優點。

Q5：如何決定對故障的下游相依服務的重試激進程度？

重試預算受三個考量限制。第一，呼叫者本身的延遲 SLA——你不能把超過 SLA 的時間花在重試上。如果你承諾 200 毫秒 p99，而下游相依服務有 100 毫秒 p99，你有空間做一次帶退避的重試；你沒有空間做三次。第二，重複執行的代價——如果操作有金鑰保護冪等性，重試成本低；如果沒有，一次重試已有風險，三次就是災難。第三，放大的影響——N 次重試來自 M 個客戶端，在相依服務停機期間產生 N×M 個請求，讓所有人（包括同一相依服務的其他呼叫者）的情況更糟。AWS 的指導：指數退避加 Jitter、有界的重試次數（通常 3-5）、在近期故障達到閾值時跳開的 Circuit Breaker，以及重試耗盡時的 DLQ 或降級回退。Step Functions Retry + Catch 清晰地實作了這個模式；Lambda 搭配 Powertools Idempotency 增加了安全重試保證。

Q6：我的架構使用跨多個 AZ 的 Auto Scaling，這樣不就已經是靜態穩定的嗎？

不一定。靜態穩定性意味著系統在事件發生前的設定下持續運行，無需在事件期間進行控制平面動作（如啟動新執行個體）。如果你的 ASG 在三個 AZ 各以 60% 容量執行——失去一個 AZ 後剩餘 60% × 2/3 = 40% 的總容量，但剩餘 AZ 容量達 100%——你對單一 AZ 故障具備靜態穩定性，因為不需要啟動新執行個體就能繼續服務。如果你的 ASG 在每個 AZ 以 100% 容量執行，失去一個 AZ 需要在剩餘 AZ 多啟動 33% 的執行個體才能維持負載，你就不是靜態穩定的；你依賴 EC2 RunInstances 控制平面在事件期間正常運作。靜態穩定性通常花費更多（過度佈建），但能防止恰恰是控制平面最可能被限流的那些事件。在 SAP-C02 中，如果題目強調「必須在 AZ 停機與 EC2 API 限流同時發生時繼續運作」，答案涉及預先佈建容量的靜態穩定性，而非事件期間的 ASG 擴展。

Q7：AWS Fault Injection Service 可以在正式環境安全使用嗎？

可以，AWS 明確鼓勵——但只有在具備正確護欄的情況下。基本安全機制是：(1) 停止條件與定義客戶影響的相同 CloudWatch 告警連結，任何使用者可見的降速都自動停止實驗；(2) 透過目標選取（單一執行個體 → 單一 AZ → 百分比）進行爆炸半徑控制，從小規模開始逐步升級；(3) 業務時機選擇——不要在財務結帳視窗或行銷活動期間執行混沌；(4) 正式環境實驗需要值班人員在線，以便在意外情況發生時人員可以反應；(5) IAM 角色範圍限定在受測資源。成熟的團隊在預正式環境持續執行 FIS 實驗（作為 CI/CD 的一部分），定期在正式環境執行（每月 GameDay），並以 DR 計畫的持續驗證形式運作。在 SAP-C02 中，當題目說「在不影響客戶的前提下驗證正式環境工作負載的可靠性」，預期答案是附有停止條件的 FIS。

Q8：AWS Resilience Hub 是否取代了 AWS Backup 和災難復原 Runbook 的需求？

不——Resilience Hub 是評估與政策層，而非執行層。它定義 RTO/RPO 目標、評估當前架構是否能達到目標，並建議修復。執行仍然發生在底層服務中：AWS Backup 做跨 Region 備份、Route 53 ARC 做容錯移轉、FIS 做測試、CloudFormation 做佈建備援端、Lambda 做自動化 Runbook。把 Resilience Hub 想成管理系統——告訴你執行層是否能達到 SLO；執行層本身仍是你已經在使用的同一套 AWS 服務。在考試中，當題目問「哪個服務衡量架構是否符合既定韌性目標並建議改善」，答案是 Resilience Hub；當題目問「哪個服務實際執行跨 Region 備份」，答案是 AWS Backup。

延伸閱讀

• AWS Well-Architected Framework — Reliability Pillar
• Reliability Pillar — Design Principles
• Advanced Multi-AZ Resilience Patterns (Whitepaper)
• AWS Resilience Hub User Guide
• Resilience Hub — Resiliency Policies
• AWS Fault Injection Service (FIS) User Guide
• AWS FIS Actions Reference
• Route 53 Application Recovery Controller
• Route 53 ARC — Routing Controls
• Route 53 ARC — Readiness Check
• AWS Service Quotas User Guide
• Step Functions — Error Handling (Retry / Catch)
• Amazon SQS — Dead-Letter Queues
• Amazon Builders' Library — Avoiding Insurmountable Queue Backlogs
• Amazon Builders' Library — Static Stability Using AZs
• Amazon Builders' Library — Workload Isolation Using Shuffle Sharding
• Amazon Builders' Library — Making Retries Safe with Idempotent APIs
• AWS SAP-C02 Exam Guide (PDF)