本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
可靠性
定義
可靠性是指服務或系統在必要時執行其預期功能的能力。系統可靠性可以透過其在指定時間範圍內的操作品質水準來測量。與彈性形成對比，彈性是指系統從基礎設施或服務中斷中動態且可靠地復原的能力。
如需如何使用可用性和彈性來測量可靠性的詳細資訊，請參閱 AWS Well-Architected Framework 的可靠性支柱。
關鍵問題
可用性
可用性是工作負載可供使用的時間百分比。常見目標包括 99% （每年允許 3.65 天的停機時間）、99.9% （8.77 小時） 和 99.99% （52.6 分鐘），其中一小部分是百分比中的九位數 （99% 為「二九」，99.9% 為「三九」等）。 AWS 與內部部署資料中心之間的聯網解決方案可用性可能與整體解決方案或應用程式可用性不同。
網路解決方案可用性的關鍵問題包括：
-
如果我的 AWS 資源無法與我的內部部署資源通訊，是否可以繼續運作？ 反之亦然？
-
我應該將計劃維護的排程停機時間視為包含在可用性指標中或排除在可用指標之外嗎？
-
與整體應用程式運作狀態分開，我如何衡量聯網層的可用性？
Well-Architected Framework Reliability Pillar 的可用性區段提供計算可用性的建議和公式。
彈性
彈性是工作負載在以下方面的能力：從基礎架構或服務中斷恢復、動態取得運算資源以符合需求，以及緩解中斷狀況 (例如，設定錯誤或暫時性網路問題)。如果備援網路元件 （連結、網路裝置等） 沒有足夠的可用性自行提供預期的函數，則其對故障的恢復能力較低。結果是使用者體驗不佳和降級。
網路解決方案彈性的關鍵問題包括：
-
我應該允許多少次同時發生、分散的故障？
-
如何透過連線解決方案和內部網路來減少單一故障點？
-
分散式拒絕服務 （DDoS） 事件的漏洞是什麼？
技術解決方案
首先，請務必注意，不是每個混合網路連線解決方案都需要高水準的可靠性，而且提高可靠性水準會相應增加成本。在某些情況下，主要站台可能需要可靠 （備援和彈性） 連線，因為停機時間對業務的影響較高，而區域站台可能因為發生故障事件時對業務的影響較低，而不需要相同層級的可靠性。建議參考AWS Direct Connect 復原建議
為了在恢復能力的情況下實現可靠的混合網路連線解決方案，設計需要考慮以下方面：
-
備援：旨在消除混合網路連線路徑中的任何單一故障點，包括但不限於網路連線、邊緣網路裝置、跨可用區域和 DX 位置的備援 AWS 區域，以及裝置電源、光纖路徑和作業系統。為了本白皮書的目的和範圍，備援著重於網路連線、邊緣裝置 （例如，客戶閘道裝置）、 AWS DX 位置和 AWS 區域 （適用於多區域架構）。
-
可靠的容錯移轉元件：在某些情況下，系統可能正常運作，但無法在所需的層級執行其功能。在單一故障事件期間，這種情況很常見，其中發現規劃的備援元件以非備援方式運作，因為使用量，其網路負載沒有其他位置可前往，導致整個解決方案的容量不足。
-
容錯移轉時間：容錯移轉時間是次要元件完全接管主要元件角色所需的時間。容錯移轉時間有多個因素：偵測失敗所需的時間、啟用次要連線所需的時間，以及通知網路其餘部分變更所需的時間。可以使用VPN連結的失效對等偵測 （DPD） 和 AWS Direct Connect 連結的雙向轉送偵測 （BFD） 來改善故障偵測。啟用次要連線的時間可能非常短 （如果這些連線一律處於作用中狀態）、可能是短時間時段 （如果需要啟用預先設定的VPN連線） 或更長的時間 （如果需要移動實體資源或設定新資源）。通知網路的其餘部分通常透過客戶網路內的路由通訊協定進行，每個通訊協定都有不同的收斂時間和組態選項 – 這些組態超出了本白皮書的範圍。
-
流量工程：彈性混合網路連線設計的流量工程旨在解決正常和失敗情況下，流量應如何通過多個可用連線。建議遵循故障設計概念 ，其中您需要查看解決方案在不同故障情況下的運作方式，以及業務是否接受。本節討論一些常見的流量工程使用案例，旨在增強混合網路連線解決方案的整體彈性。AWS Direct Connect 有關路由和討論幾個流量工程選項來影響流量流的章節 BGP （社群、BGP本機偏好設定、AS Path 長度）。若要設計有效的流量工程解決方案，您需要充分了解每個 AWS 網路元件在路由評估和選擇方面如何處理 IP 路由，以及影響路由選擇的潛在機制。其詳細資訊超出本文件的範圍。如需詳細資訊，請參閱視需要的 Transit Gateway Route Evaluation Order 、Site-to-Site VPNRoute Priority 和 Direct Connect Routing 和BGP文件。
注意
在VPC路由表中，您可以參考具有其他路由選擇規則的字首清單。如需此使用案例的詳細資訊，請參閱字首清單的路由優先順序。 AWS Transit Gateway 路由表也支援字首清單，但一旦套用，它們就會擴展到特定的路由項目。
具有更特定路由的雙 Site-to-SiteVPN連線範例
此案例是以小型內部部署站台為基礎，透過網際網路連接至 的單一 AWS 區域 備援VPN連線 AWS Transit Gateway。圖 10 中描述的流量工程設計顯示，透過流量工程，您可以透過以下方式影響提高混合連線解決方案可靠性的路徑選擇：
-
彈性混合連線：備援VPN連線各提供相同的效能容量，使用動態路由通訊協定 （BGP） 支援自動容錯移轉，並使用VPN無效對等偵測加快連線失敗偵測。
-
效能效率：在兩個VPN連線ECMP之間設定 ， AWS Transit Gateway 有助於最大化整體VPN連線頻寬。或者，透過廣告不同的更具體路由以及網站摘要路由，可以管理兩個VPN連線之間的負載獨立性
圖 10 – 具有更特定路由的雙 Site-to-SiteVPN連線範例
具有多個 DX 連線的雙內部部署站台範例
圖 11 中所示的案例顯示位於不同地理區域的兩個內部部署資料中心網站，並使用 AWS Direct Connect 搭配 DXGW和 AWS 使用 的最大恢復能力連線模型 （如 AWS Direct Connect 恢復力建議 所述
透過將BGP社群屬性與通告 的路由建立關聯 AWS DXGW，您可以影響來自 AWS DXGW 端的輸出路徑選擇。這些社群屬性會控制指派給公告路由 AWS的 BGP 本機偏好設定屬性。如需詳細資訊，請參閱 AWS DX Routing 政策和BGP社群 。
為了最大限度地提高 AWS 區域 連線層級的可靠性，每對 AWS DX 連線都會進行設定，ECMP以便可以同時將兩者用於每個內部部署站台與 之間的資料傳輸 AWS。
圖 11 – 具有多個 DX 連線的雙內部部署站台範例
透過此設計，目的地為內部部署網路 （具有相同的公告字首長度和BGP社群） 的流量將使用 分散到每個站台的雙 DX 連線ECMP。不過，如果 DX 連線ECMP不需要 ，則可以使用先前討論的相同概念，並在路由政策和BGP社群文件中描述，進一步在 DX 連線層級設計路徑選擇。
注意：如果內部部署資料中心內的路徑中存在安全裝置，則需要設定這些裝置，以允許流量透過一個 DX 連結離開，並從相同資料中心網站內的另一個 DX 連結 （兩個連結都與 搭配使用ECMP） 離開。
VPN 連線作為 DX AWS 連線的備份範例
VPN 可以選取 以提供備份網路連線至 AWS Direct Connect 連線。一般而言，這種類型的連線模式是由成本所驅動，因為它因為網際網路上的效能不確定，而為整體混合連線解決方案提供較低程度的可靠性，而且無法透過公有網際網路SLA取得連線。這是有效且符合成本效益的連線模型，當成本是最高優先順序考量且預算有限時，或可能作為臨時解決方案使用，直到可以佈建次要 DX 為止。圖 12 說明此連線模式的設計。此設計的一個關鍵考量因素是， VPN和 DX 連線都在 終止 AWS Transit Gateway，相較於可透過連接至 的 DX 連線公告的路由，VPN連線可以公告更多路由 AWS Transit Gateway。這可能會導致路由狀況欠佳。解決此問題的選項是在客戶閘道裝置 （CGW） 設定從VPN連線接收路由的路由篩選，僅允許接受摘要路由。
注意：若要在 上建立摘要路由 AWS Transit Gateway，您需要指定路由表中任意連接的靜態 AWS Transit Gateway 路由，以便沿著更具體的路由傳送摘要。
從 AWS Transit Gateway 路由表的角度來看，內部部署字首的路由會從 AWS DX 連線 （透過 DXGW） 和 從 接收VPN，字首長度相同。在 的路由優先順序邏輯之後 AWS Transit Gateway，透過 Direct Connect 接收的路由比透過 Site-to-Site 接收的路由具有更高的偏好設定VPN，因此透過 的路徑 AWS Direct Connect 將優先於到達內部部署網路 （in-premise network）。
圖 12 – 作為 DX AWS VPN連線備份的連線範例
下列決策樹會引導您做出所需的決策，以達到彈性 （這將產生可靠的） 混合網路連線。如需詳細資訊，請參閱AWS Direct Connect 彈性工具組 。
圖 13 – 可靠性決策樹
