評估韌性模式，有效率地設計雲端架構

營運韌性 (Operational Resilience) 是通過了解並適應不斷變化的人員、流程和技術，據以提供持續不中斷服務的能力。《AWS 架構最佳實踐白皮書》將韌性定義為「在承受負載 (更多的服務請求)、攻擊 (無論是因錯誤還是蓄意) 以及工作負載的任何元件發生故障時，所具備恢復的能力」。

在雲端中實現營運韌性是 AWS 與您之間的共同責任。AWS 負責確保您所使用的基礎設施設計具有冗餘規劃，以及雲端服務 (應用系統的建構模組) 的持續可用，且已準備好因應可能影響基礎設施的各類事件。而您在營運韌性方面的責任，包括如何在 AWS 中設計、部署和測試您的應用系統，以滿足其可用性和韌性要求。舉例而言，針對近乎零停機要求的關鍵任務應用系統，這類應用系統將會要求 AWS 基礎設施和服務與您設計及部署的應用系統，即使發生中斷狀況下，仍須隨時保持可用。
在雲端上建立具有韌性的工作負載通常需要評估多個因素，然後才能決定適合其工作負載的最佳架構。一般企業中會擁有多個關鍵性各異的應用系統，每個應用系統在韌性、複雜度和成本方面都有不同的需求。您將有多種選擇來建立工作負載以實現韌性和成本控制，以及評估哪種選項最符合您的需求。

AWS 專為因應停機和事故而建構，並在設計 AWS 服務時亦將其納入考量，因此當中斷發生時，對您和服務持續性的衝擊將盡可能降到最低。為了避免單點故障，AWS 最大程度地減少在全球基礎設施間服務的互聯互通。AWS 的全球基礎設施分佈在五大洲，且在本文出版時，AWS 的全球基礎設施包含有 33 個地理區域 (Region)，並涵蓋了 105 個由一至多個資料中心組成的可用區 (Availability Zone, AZ) ，AWS 仍持續地佈局新的區域和可用區，您可以通過連結檢視：AWS 最新的全球基礎設施佈局。

區域 (Region) 之間是相互隔離的，這意味著一個區域的中斷問題將不會影響其他區域。與如今多數企業的地端機房環境相比，AWS 基礎設施的全球分散佈局，大幅降低了地理位置的集中風險。關於 AWS 基礎設施的設計與控制，可詳閱：AWS 資料中心的虛擬導覽。

區域 (Region) 之間是相互隔離的，這意味著一個區域的中斷問題將不會影響其他區域。與如今多數企業的地端機房環境相比，AWS 基礎設施的全球分散佈局，大幅降低了地理位置的集中風險。AWS 仍持續地佈局新的區域和可用區，您可以通過此連結檢視 AWS 最新的全球基礎設施佈局。

AWS 在整體基礎設施和服務都採用了隔離設計，通過多重結構以提供不同級別的獨立和冗餘元件。從最高層的區域 (Region) 設計來看，為了最小化服務間的互聯互通，AWS 在每個區域都部署了基礎設施和服務的專用堆疊。區域是自主且相互隔離的，但 AWS 仍然允許客戶依據需求執行跨區域資料複製及其他操作。為了實現這些跨區域的功能運作，AWS 非常謹慎地確保區域之間的相互依賴性和調用模式是非同步的 (asynchronous)，並採取安全機制加以隔離。例如，AWS 設計了 Amazon Simple Storage Service (Amazon S3) 的功能，允許客戶將資料從原區域 (例如 us-east-1) 複製到另一個區域 (例如 us-west-1)，但也同時將 S3 設計成在各區域內自主運行的模式，因此當 us-east-1 的 S3 服務停機時，不會導致 us-west-1 的 S3 服務受到影響。

在 AWS 中，絕大多數的服務可完全獨立運行於單一區域中，僅少數涉及提供全球交付服務例外，例如 Amazon Route 53 (Domain Name Service, DNS)，其資料層 (Data Plane) 的設計能夠實現 100% 的可用性。

構成區域 (Region) 的可用區 (AZ) 則由一至多個資料中心組成，在物理上是相互分離且獨立的設計。在單一區域內的多個可用區間可允許資料複製，並提供低延遲影響的冗余網路以避免局部中斷，這對於需要低延遲網路來運行應用系統的企業來說是一個重要優勢。與此同時，AWS 仍確保可用區彼此間的獨立性，以確保在發生重大事故時服務仍然可用。各可用區擁有獨立的物理基礎設施，且彼此間保有一定距離以降低火災、水災及其他事件的影響。許多 AWS 服務也可在可用區中自主運行，意味著如果單一區域中的一個可用區若停電或無法連線，該區域的其他可用區不會受到影響，或是在軟體發生錯誤的情形下，錯誤散播的影響範圍也將受到限制。可用區的獨立性使 AWS 能夠通過多個可用區來進行服務建構，從而為 AWS 的客戶提供高可用及韌性的區域服務。

此外，AWS 還運用了以細胞為基礎的架構 (Cell-based Architecture) 概念。細胞是由多個各自隔離的執行個體所組成，這些內部服務的結構客戶是看不見的。在以細胞為基礎的架構中，資源和請求被劃分到多個細胞中，而每個細胞的規模是有上限的。這樣的設計降低了單一細胞 (例如一部分客戶的資源及請求) 的中斷，從而干擾到其他細胞的可能性。通過縮小服務故障的爆炸半徑，整體的服務可用性和持續性也得到了保證。用船艙中的隔艙板來舉例，如果建構了足夠且設計得當的隔艙版，將可以在船體受損時限制進水範圍，使船隻得以保持漂浮。

在選擇最適合其應用程式韌性需求的設計時，您需要考慮哪些要素？ 為了幫助回答這些問題，您可以從 5 個核心要素來進行考慮，包含：(1) 設計複雜度、(2) 實施成本、(3) 維運工作、(4) 安全性、和 (5) 對環境的影響。

1. 設計複雜度：每個單獨的工作負載組件都必須具有韌性考量，您需要消除人員、流程和技術元素之間的單點故障。而這將會造成系統複雜度的增加，也通常會增加系統的不可預知行為。您應考慮應用系統的具體韌性要求，並決定增加系統複雜度是否是一種有效的方法，或者評估為維持系統簡單性而計劃災難恢復 (Disaster Recovery, DR) 機制也許是更合適的作法。
2. 實施成本：當您實施更高的韌性時，成本通常會顯著增加，因為需要運行新的軟體和基礎設施元件。重要的是，這類成本必須可與未來潛在損失成本相互抵銷。
3. 維運工作：部署和支援高度韌性的系統需要複雜的操作流程和先進的技術技能。例如，您可能需要使用操作準備審查 (Operational Readiness Review, ORR) 方法來改善操作流程。在您決定實施更高的韌性之前，請評估您的維運能力，以確認您具有所需的流程成熟度和技能水平。
4. 安全性：安全性與韌性的直接關係不大。然而，對於高度韌性的系統，通常需要保護更多元件。使用雲端部署的安全最佳實踐可以在不顯著增加複雜度的情況下，即使面對更龐大的部署範圍，仍能實現安全性目標。
5. 對環境的影響：為了實現韌性的系統而增加的部署範圍可能會增加雲端資源的消耗。但是，您可以進行權衡考量，例如 approximate computing 或策略性實施較慢的回應時間來減少資源消耗。AWS 架構最佳實踐的《可持續性支柱》描述了這類模式，並提供了可持續性最佳實踐的指導。

本文將通過討論圖 1 中的 5 種韌性設計模式 (P1 - P5)，以及採用這些模式時將要考慮的權衡，以協助您依據應用系統的需求，實現不同程度的韌性，並最終實施最適合您需求的架構。

備註：各種模式之間並不互斥，您可依據實際需要決定實施一至多種混合模式組成。

P1 是基於雲端的架構模式，它將雲端基礎設施的可用區 (Availability Zone, AZ) 設計納入架構中以提高系統韌性。如圖 2 所示，P1 模式使用多可用區 (Multi-AZ) 架構，其中應用系統採用單一執行個體，並在單一 AWS 區域 (Region) 內的多個可用區中運行。這使您的應用程式能夠承受可用區級別故障所造成的影響。

P1 模式適用於部署對業務影響性較小的應用系統 (例如員工內部應用系統)，這類系統對韌性的要求較低。您可將較低業務影響的應用系統部署在由 Auto Scaling Group 管理的單一 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體，並利用 Amazon EC2 的運作狀態檢查來自動檢測故障。如果某個可用區發生故障，Amazon EC2 會主動知會 Auto Scaling Group 在另一個未受影響的可用區中重新建立其應用系統。

權衡考量

在 5 個韌性模式中，P1 是較低的韌性等級，此模式可減輕應用系統因單一可用區故障的中斷疑慮，但這也會以應用系統復原的能力作為代價。如果某可用區發生故障，在新的可用區中重新佈建新資源期間，它將會中斷終端使用者對應用系統的訪問，而這個狀態稱作雙峰行為 (Bimodal Behavior)。

P2 模式使用單一區域內跨多個可用區 (Multi-AZ) 的多組執行個體 (Multiple Instances) 來提高韌性。此模式採用靜態穩定性機制 (Static Stability) 來避免雙峰行為。靜態穩定系統會保持其穩定並以固定模式運行，無論其運行環境如何變化。在 AWS 中設計靜態穩定機制的關鍵優勢在於，因資源容量已預先超額部署，如此可降低在中斷期間額外佈建新資源並進而恢復的複雜性。當中斷期間 (例如某個可用區的資源故障) 維持運作所需的資源都已存在，AWS 服務控制層就不需要另外需要確保新資源恢復成功狀況下，資源就已經呈現可用狀態。若要瞭解有關靜態穩定性、資料層和控制層的更多細節，請檢閱 Amazon Builders’ Library 中的《使用可用區實現靜態穩定性》一文。

如圖 3 所示，假設您有一個面向消費者的網站，該網站對於停機時間容忍度較低，且每當網站停機時都可能導致企業收入損失。因此針對該網站您可以在 2 個可用區中預先超額佈建 2 組 EC2 執行個體。通過運作狀態檢查，若在某個可用區發生故障時，Elastic Load Balancer (ELB) 會將流量從受影響的可用區移轉出去，讓網站得以持續穩定運行。若要瞭解更多有關使用運行狀態檢查的資訊，請參閱 Amazon Builders’ Library 中的《實作運作狀態檢查》一文。

權衡考量

P2 可以舒緩可用區中斷的影響，亦不會造成應用系統終端用戶遭遇停機，但須權衡成本議題。從基礎設施成本的角度來看，P1 的成本較低，因為它佈建的運算資源較少，並且只有在故障發生時才啟動新的執行個體。然而，P1 的雙峰行為可能會在大規模事件期間影響到終端用戶。

實施 P2 您的應用系統需要支援跨多個執行個體的分散式運作。如果您的應用系統可以支援此模式，您就可以將工作負載部署到區域內所有的可用區 (通常是 3 個或更多)。當您部署的可用區越多，相對的將能夠減少整體部署的成本，因為您在 2 個可用區中需要配置 2 倍的運算資源，而在 3 個可用區內也許只需佈建 1.5 倍的運算資源，即可達到相同的高可用性等級。

P3 使用多區域 (Multi-Region) 模式來增強功能韌性，如圖 4 所示。它將不同的關鍵應用系統分散部署在多個不同的區域。例如您通過多個數位通路向消費者提供銀行服務，例如信用餘額查詢等。消費者可通過行動應用程式、聯絡中心和網路應用程式等方式來存取銀行服務。如果將每個數位通路都各自部署在獨立的區域，這將能減輕區域級別的服務中斷的影響。

當消費者的行動應用程式所在的區域發生中斷時，造成行動應用程式無法使用，消費者仍可以通過部署在另一個區域的網路銀行來存取銀行服務。區域服務中斷的情況很少見，但實施這樣的模式將可確保您的終端用戶在服務中斷期間，仍能通過其他管道正常存取關鍵業務服務。

權衡考量

P3 減輕了區域服務中斷時同時影響多個系統的可能性。然而，跨多個區域運作的應用系統組合將需要大量的維運規劃和管理。並且，依功能性的隔離仍可能會因為應用系統依賴於其他區域中部署的共同下游系統和使用的資料來源而受到影響。因此，區域範圍內的事故仍可能會導致服務中斷，但影響範圍應該會有所降低。

如果您正在營運著多種對中斷的容忍度極低的關鍵業務服務，例如讓消費者能夠支付銀行款項。您可以評估在 AWS 上設計災難復原機制 (更多資訊可參閱《Disaster Recovery of Workloads on AWS: Recovery in the Cloud》)，根據系統恢復時間目標 (Recovery Time Objective, RTO) 及資料還原時間點目標 (Recovery Point Objective, RPO) 的要求，分別有備份和還原 (Back & Restore)、指示燈 (Pilot Light)、暖待命 (Warm Standby)、及多站點多活 (Multi-site active/active) 四種常見模式。針對 P4 多區域災備模式，您可以考慮採取指示燈或暖待命模式：

• 指示燈 (Pilot Light)：此模式適用於 RTO/RPO 需求為 10 分鐘級別的應用系統。資料平常會被主動複製，應用系統基礎資源要在災難恢復的區域中預先佈建。成本優化是此模式的關鍵要點，因為災難復原區域中的基礎資源平常將保持關閉狀態，僅在災難恢復期間時啟用以進行復原操作。
• 暖待命 (Warm Standby)：對比於指示燈，此模式通過在災難恢復區域中日常運行較低用量的基礎資源，並藉此顯著改善災難復原的切換效率。在災難恢復期間，災難復原區域的應用系統基礎資源將進行擴展，且通常可以透過自動化來最小化人工操作。如果運作正確，此模式可以實現分鐘級別的 RTO/RPO。

權衡考量

P4 也緩解了區域服務中斷的影響，同時還降低了故障緩解的成本。然而因為基礎資源的變更都需要跨區域同步，因此多區域災備模式會增加整體部署的複雜度。韌性演練也將變得更為複雜，包括如何模擬區域中斷狀況。使用基礎設施即代碼 (Infrastructure as Code, IaC) 來實作自動化部署機制，將有助於解決這類問題。

對於銀行核心和客戶關係管理這類對中斷的容忍度近乎為零的應用系統，您可以利用 P5 模式來部署這些重大關鍵應用系統，因為它需要即時的 RTO 和趨近於零資料遺失的 RPO。通過同時在多個區域中運行工作負載，並允許通過所有區域來同時提供服務。這個模式不僅降低了區域中斷的影響，也解決了對於中斷零容忍的需求 (圖5)。

 權衡考量

P5 降低了區域服務中斷的影響，並投入額外的成本和複雜度來實現趨近於零的 RTO。多活部署通常很複雜，因為牽涉到多個應用系統間的協同工作來提供所需的業務服務。如果您實施此模式，需要注意並考量到跨區域資料非同步複製的事實，以及其對資料一致性造成的影響。

實施此模式需要相當高的流程成熟度，因此建議您可先從其他前述的部署模式開始，再逐步建置此模式。

AWS 已準備好提供營運韌性落實方法，以協助客戶實現對工作負載安全性及韌性的保障。您可以通過各種方式來獲得有關在 AWS 上如何保證其工作負載的安全性與韌性，包括：事故管理機制、由獨立第三方稽核機構所準備的 AWS 基礎設施及服務報告、用於監控、評估及測試其 AWS 環境的服務及工具、以及通過 AWS 的稽核團隊的直接參與。

儘管大規模影響 AWS 基礎設施及服務的事故發生可能性極低，AWS 仍然已準備好因應之道來管理此類事故帶來的影響。AWS 通過持續性的監控指標及告警機制、高嚴重等級的工單處置措施、客戶報告、以及 24x7x365 全年無休的服務暨技術支援專線 (基於 AWS 技術支援計畫)，以掌握事故及服務水平惡化情況。

在發生重大事件時，值班工程師會發起通話以召集問題處理人員，進行事件分析，並決定是否需要調度更多的人員來解決問題。事件負責人會敦促問題處理人員追查事件的根源以緩解事件影響。相關的問題處理人員將採取必要的行動來因應事件。
在確認故障原因、修復程序及受影響的元件後，事件負責人將指示進行文件紀錄及行動，並結束通話。在完成相關的修復工作後，事件負責人將宣布復原階段完成。

針對該事件的事後檢討及深度根源分析將交由相關團隊處理，無論該事件對外部的衝擊程度為何，在發生任何重大營運議題後，都會召開事後檢討會議，並撰寫錯誤更正 (Correction of Errors, COE) 文件，以掌握根本原因並採取可能的預防措施作為日後的因應機制。預防措施的實施情形將會在每週的營運會議中進行追蹤。

您還可以持續獲得有關自身工作負載韌性的保證。通過 AWS 管理控制台 (AWS Management Console) 提供的服務和工具，您將可以獲得前所未有的能見度、監控和修復能力，以確保其 AWS 環境的安全性和合規性。企業再也不需要仰賴定期的快照紀錄或通過季度及年度的評估作業，來進行其安全性及合規性的驗證。

您擁有許多方式來實現其 AWS 資源安全性及合規性的直接保障，包括但不限於以下 AWS 服務：Amazon EventBridge、AWS Config、Amazon GuardDuty、AWS Config Rules、Amazon Inspector 及 AWS Security Hub 等。

首先，您可以利用 AWS 服務將稽核控制措施整合到通知及工作流程系統中。例如，在這類型的系統中，虛擬伺服器的狀態從待處理變更成運行狀態時，您可以通過 Amazon EventBridge 設計事件觸發，以發動校正措施、日誌記錄、以及在必要時通報負責人員。您也可以將通知與工作流程系統與 AWS 提供基於機器學習的網路安全服務 (例如：Amazon GuardDuty) 進行整合，以偵測異常的 API 呼叫、潛在未授權部署行為及其他惡意活動等。

其次，您還可以將具體的監管要求通過 AWS Config Rules 撰寫為客製化託管規則，以利用 AWS Config 持續追蹤您的資源配置變更；例如，當銀行要求開發人員不得啟動未經加密的儲存磁碟區，您可以事先定義加密規則來標記不合規的儲存磁碟，並自動將其移除。

最後，您可以通過 Amazon Inspector 及 Amazon GuardDuty 等服務，自動且規模化的評估環境的安全性，針對在網路、檔案系統及處理活動，並蒐集大量的活動及配置資料。這些資料中包含 AWS 服務的通訊詳細資料、安全通道的使用情形、正在運行的處理流程細節、以及處理流程間的網路通訊等，最後從 AWS Security Hub (作為 Cloud Security Posture Management, CSPM) 產生一份依嚴重程度排序的匯總調查發現與安全問題清單。

儘管這些服務能夠校正不合規的配置及安全漏洞，AWS 仍然建議您進行應用系統的營運韌性測試。您應測試瞬間故障對於進行應用系統的相互依賴 (包括外部依賴) 影響、部分元件故障的狀況、以及網路通訊品質降低情形等。AWS 主要客戶開發了一套開源軟體來進行這類測試的基礎，或者您也可以通過 AWS 服務 Fault Injection Service (FIS) 來進行韌性測試。

為因應惡性行為者可能存取您環境中關鍵功能或流程的隱憂，您亦能針對 AWS 環境進行滲透測試。您若計劃對 AWS 資源進行滲透測試，應事先向 AWS 提交滲透測試申請通知，因為這類活動與被禁止的安全違規或網路濫用行為間難以區分。

在本文中，介紹了 AWS 如何確保營運韌性的基礎架構及服務設計概念，以確保您可以在 AWS 環境中採用具備高可用且冗餘的基礎環境。本文也介紹了 5 種韌性模式的設計架構，舉例適合各種韌性模式的情境，以及如何將這些模式套用以符合您的業務需求，並且在實施時需要關注的權衡考量，協助您找到更適合應用情境的有效架構。最後，我們也說明了 AWS 如何提供您韌性保障的相關措施。滿足並超越您的安全性及韌性需求將一直是 AWS 的首要目標。

• AWS Well Architected Framework – Resilience Pillar
• Building Resilient Well-Architected Workloads Using AWS Resilience Hub
• Disaster Recovery of Workloads on AWS: Recovery in the Cloud
• Disaster Recovery (DR) Architecture on AWS, Architecture Blog series
• AWS Multi-Region Fundamentals whitepaper

• Amazon Web Services' Approach to Operational Resilience in the Financial Sector & Beyond: https://docs.thinkwithwp.com/whitepapers/latest/aws-operational-resilience/aws-operational-resilience.html
• Understand resiliency patterns and trade-offs to architect efficiently in the cloud: https://thinkwithwp.com/tw/blogs/architecture/understand-resiliency-patterns-and-trade-offs-to-architect-efficiently-in-the-cloud/