本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
範例公司汽車使用案例
白皮書的這一部分示範如何使用考量、需求定義問題和決策樹來協助您決定最佳的混合式網路設計。識別和捕獲的要求是很重要的，因為它們被用作輸入到決策樹。預先擷取需求可避免進一步的設計迭代。如果必須重新審視設計並保留寶貴的資源，則可以將專案完全停止，並且在預先了解需求時最理想地避免這個專案。
實施例公司汽車將在整個部分作為說明客戶使用。他們希望最初部署他們的第一個分析項目AWS。該分析項目專注於分析公司生產的汽車以及公司數據中心已存在的其他數據集中的數據集的數據。最初，該公司的架構團隊認為他們需要一AWS 帳戶個 Amazon VPC 和少數子網來託管生產和開發環境。專案團隊渴望開始使用，而且他們要求儘快存取開發環境。他們的目標是從現在開始三個月後進行生產。
Example Corp. 汽車還計劃用AWS於其他幾個項目，例如將其 ERP 系統，虛擬桌面基礎架構（VDI）以及另外 20 個應用程序從內部部署遷AWS移到未來 6 個月。其他項目的一些要求仍在定義中，但很明顯，它們的AWS 雲端使用率將會增長。
架構團隊決定利用本白皮書中概述的方法。他們使用每個考量下概述的需求定義問題來捕獲輸入來做出他們的設計決策。
它們從與連接類型相關的需求開始，這些需求摘要如下表所示。
表 4-示例汽車公司可靠性輸入
| 連線類型選擇考量 | 需求定義問題 | 答案 |
|---|---|---|
| 部署時間 | 部署所需的時間表為何？ 小時，天，幾週或幾個月？ |
|
| 安全性 | 您的安全要求和政策是否允許使用互聯網上的加密連接來連接AWS或強制使用私人網絡連接？ |
|
| 利用私人網路連線時，網路層是否必須在傳輸過程中提供加密？ | 否，將使用應用程式層加密。 | |
| SLA | 是否需要含服務點數的混合式連線 SLA？ |
|
| 什麼是正常運行時間目標？ |
|
|
| 整個混合網絡是否遵守正常運行時間目標？ |
|
|
| 效能 | 什麼是所需的吞吐量？ |
|
| AWS與內部部署網路之間可接受的最大延遲是多少？ |
|
|
| 最大可接受的網路抖動是多少？ |
|
|
| 成本 | 您AWS每月會傳送多少資料？ |
|
| 您AWS每月會傳送多少資料？ |
|
|
| 此連線是永久性的嗎？ | 是 |
根據收到的需求，架構小組遵循連線類型決策樹狀結構圖 9。它允許架構團隊決定開發、測試和生產環境的連接類型。對於生產環境，他們考慮了立即以及即將到來的要求。對於開發和測試實例公司汽車將建立在互聯網上的 site-to-site VPN。對於生產，他們將與服務提供商合作以將其公司網絡連接起來AWS Direct Connect。示例公司汽車最初考慮使用直接 Connect 託管 Connect，但由於AWS提供 SLA
決定連線類型之後，下一個步驟是擷取會影響連線設計選擇的需求。這與邏輯設計有關，例如連接的配置方式以及用於支持業AWS務和技術需求的服務。
為了掌握延展性和通訊模型需求，架構團隊使用本白皮書相關章節中的需求定義問題。下表摘要說明與這兩個考量相關的需求。
表 5 — 需求定義問題
| 連接性設計選擇考量 | 需求定義問題 | 答案 |
|---|---|---|
| 擴充性 | 需要連線至內部部署站台的目前或預期 VPC 數目為何？ | 2 最初，在 6 個月內增長到 30 |
| 這些 VPC 是否部署在單一AWS 區域或多個區域？ | 單一區域 | |
| 需要連線到多少個內部部署網站AWS？ | 2 個數據中心 | |
| 您每個站台有多少個需要連線的客戶閘道裝置AWS？ | 每個資料中心 2 個路由器 | |
| 預計將向 AWS VPC 廣告多少條路由，以及從側面接收的預期路由AWS數量？ |
|
|
| 是否有計劃在不久的 future 考慮連接AWS的帶寬增加？ |
|
|
| 連接設計模型 | 是否需要啟用 VPC 間通訊 (在一個區域內和/或跨區域)？ | 是的，在 AWS 區域 |
| 是否需要直接從內部部署存取AWS公用端點服務？ | 是 | |
| 是否需要從內部部AWS署使用 VPC 端點存取服務？ | 否 |
根據輸入，架構團隊會遵循「連線設計」區段中的決策樹狀結構。在預計未來 6 個月的 VPC 數量將從 2 增加到 30 之後，架構團隊決定將用AWS Transit Gateway作連線和 VPC 間路由的終止閘道。獨立AWS Transit Gateway的將終止用於開發和測試的 VPN 連接，以及與生產連接AWS Direct Connect。分離的 AWS Transit Gateway s 的使用使變更管理更簡單，並在開發/測試和生產環境之間提供了明確的分界。對於生產，因為需要AWS Direct Connect閘道AWS Transit Gateway。公用 VIF 將用於存取AWS公用端點服務。圖 14 說明了根據收集到的要求在決策樹上採取的路徑。
圖 14 — 範例公司汽車連接設計決策樹
在決定解決方案以滿足可擴展性和通信模型需求之後，下一步是捕獲與可靠性相關的要求。這與所需的可用性和恢復性等級有關。
為了掌握可靠性需求，架構團隊使用本白皮書相關章節中的需求定義問題。需求摘要如下表所示。
表 6 — 可靠性要求問題
| 連接性設計選擇考量 | 需求定義問題 | 答案 |
|---|---|---|
| 可靠性 | 在連線失敗的情況下，對企業的影響程度為何AWS？ |
|
| 從業務角度來看，連接失敗後的成本是否會AWS超過部署高度可靠連接模型的成本？AWS |
|
根據收到的輸入，架構團隊會遵循本白皮書先前涵蓋的可靠性考量部分中的決策樹。在考慮到生產連線的正常執行時間目標為 99.99%，以及服務中斷時所產生的高企業影響之後，架構團隊決定使用 2 個 Direct Connect 位置，並從每個內部部署資料中心到每個 Direct Connect 位置有 2 個連結 (總共 4 個連結)。用於開發和測試的 VPN 連接也將使用兩個 VPN 連接來提供額外的冗餘。使用可靠性一節中討論的路由工程技術，連接性將配置如下：
-
對於開發和測試，流量將使用 ECMP 在通往主要資料中心的 2 個通道上進行負載平衡。這允許更高的吞吐量。通往輔助數據中心的隧道將在主隧道故障的情況下使用。
-
對於生產環境，內部部署和其中一AWS個直 Connect 位置之間的延遲非常相似。在此情況下，已決定透過前往主要資料中心內部部署系統之內部部署系統的兩個連線，負載平衡AWS與內部部署的流量。同樣地，對於在次要資料中心執行的內部部署系統，流量會在兩個連線到次要資料中心之間進行負載平衡。如果連接失敗，BGP 將促進自動故障轉移。
圖 15 說明了根據收集到的要求在決策樹上採取的路徑。
圖 15-實例公司汽車可靠性決策樹
