本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 多區域基本概念 1：了解需求
<a name="fundamental-1"></a>

如前所述，高可用性和操作持續性是追求多區域架構的常見原因。可用性指標會測量工作負載在定義期間內可供使用的時間百分比，而操作指標的持續性則會測量大規模且通常更長持續時間事件的復原時間。

[測量可用性](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)是幾乎持續的過程。特定測量可能會有所不同，但通常會圍繞目標可用性指標進行合併，通常稱為*九個* （例如 99.99% 的可用性）。使用可用性目標時，一個大小並不符合全部。您應該在工作負載層級建立可用性目標，並將非關鍵元件與關鍵元件分開，而不是在所有工作負載中套用單一目標。

為了持續操作，通常會使用下列point-in-time測量：
+ **復原時間目標 (RTO)** – RTO 是服務中斷和服務還原之間的最大可接受延遲。此值會決定服務受損的可接受持續時間。
+ **復原點目標 (RPO)** – RPO 是自上次資料復原點以來可接受的時間上限。這會決定在最新復原點和服務中斷之間，哪些資料被視為可接受的資料遺失。

與設定可用性目標類似，RTO 和 RPO 也應在工作負載層級定義。更積極的營運持續性或高可用性需要增加投資。也就是說，並非所有應用程式都可以要求或需要相同等級的彈性。調整業務和 IT 擁有者，根據業務影響來評估應用程式的關鍵性，然後據此進行分層，有助於提供起點。下表提供分層的範例。

此資料表顯示服務層級協議 (SLAs) 彈性分層的範例。


| 彈性方案 | 可用性 SLA | 每年可接受的停機時間 | 
| --- | --- | --- | 
| Platinum | 99.99% | 52.60 分鐘 | 
| 金色 | 99.90% | 8.77 小時 | 
| 銀卡 | 99.5% | 1.83 天 | 

下表顯示 RTO 和 RPO 彈性分層的範例。


| 彈性方案 | 最大 RTO | 最大 RPO | 條件 | Cost | 
| --- | --- | --- | --- | --- | 
| Platinum | 15 分鐘 | 5 分鐘 | 關鍵任務工作負載 | $$$ | 
| 金色 | 15 分鐘 – 6 小時 | 2 小時 | 重要但不重要的任務關鍵工作負載 | $$ | 
| 銀卡 | 6 小時 – 幾天 | 24 小時 | 非關鍵工作負載 | $ | 

當您為彈性設計工作負載時，請考慮高可用性與營運持續性之間的關係。例如，如果工作負載需要 99.99% 的可用性，則每年不超過 53 分鐘的停機時間是可容忍的。至少需要 5 分鐘才能偵測到故障，操作員可能需要另外 10 分鐘才能參與、對復原步驟做出決策，並執行這些步驟。從單一問題中復原需要 30 到 45 分鐘並不罕見。在這種情況下，具有多區域策略以提供隔離的執行個體，以消除相互關聯的影響是有益的。這可讓您在限定時間內容錯移轉，同時獨立分類初始受損，以持續操作。這是定義適當週框復原時間並確保需要一致性的地方。

多區域方法可能適用於具有極端可用性需求 （例如 99.99% 或更高可用性） 的任務關鍵工作負載，或只能透過容錯移轉到另一個區域來滿足嚴格持續操作要求的任務關鍵工作負載。不過，這些要求通常僅適用於企業工作負載產品組合的一小部分，其具有以分鐘或小時為單位的週框復原時間。除非應用程式需要幾分鐘或幾個小時的復原時間，否則最好等待應用程式的區域中斷在受影響的區域內進行修復。這種方法通常與低階工作負載保持一致。

在實作多區域架構之前，業務決策者和技術團隊應符合成本影響，包括營運和基礎設施成本驅動因素。典型的多區域架構會產生的成本是單一區域方法的兩倍。雖然業務持續性有數個多區域模式，例如使用[熱待命](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html#multi-site-activeactive)、[暖待命](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html#warm-standby)或[指示燈](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html#pilot-light)執行，但達到復原目標風險最低的模式將涉及執行熱待命，並將工作負載的成本加倍。

## 金鑰指引
<a name="key-guidance-1"></a>
+ 每個工作負載都應建立 RTO 和 RPO 等營運目標的可用性和持續性，並與業務和 IT 利益相關者保持一致。
+ 可在單一區域中達成大部分的營運目標可用性和持續性。對於無法在單一區域中達成的目標，請考慮多區域，並清楚了解成本、複雜性和利益之間的權衡。