AWS Direct Connect簡介

雲端計算已經走入到每個企業中。然而，一些大型企業過去都是自建資料中心，購買了大量的基礎設施，在使用公有云服務時又不能拋棄原有的裝置，因此採用混合雲的方式，既可以保護原有的投資，又可以通過公有云的方式來隨時按需使用。很多企業都正在通過混合雲的方式來逐步走上全方位採用雲的道路。

過去，使用者需要通過在傳統的公網架設VPN（Virtual Private Network，虛擬專用網路），來保障資料傳輸的安全性，但是，這種方式無法完全保證頻寬、低延遲、時效性。而AWS Direct Connect可以實現低頻寬的成本，更穩定的網路效能，更可靠的網路效果，並且可以相容AWS其他的雲端計算服務幫助使用者實現混合雲的架構。

AWS Direct Connect服務使用標準的802.1q VLAN標準，可將連線客戶資料中心和AWS的單個專線連線邏輯分割成多個虛介面（Virtual Interface）。這樣客戶可以通過同一個連線訪問共享資源（如通過公有IP 地址空間提供服務的Amazon S3中的物件）和專有資源（如使用私有IP空間在VPC中執行的Amazon EC2例項），同時又能在公有和專用環境之間保持網路隔離。

如下圖所示，從客戶路由器到AWS Direct Connect路由器的乙太網連線上的不同VLAN與不同的虛介面相關聯，客戶可以通過Public VIF訪問諸如S3，DynamoDB、AWS API端點等在公共地址空間中的服務，也可以通過Private VIF與繫結到VPC的VGW相連線，實現對多個VPC的訪問。

AWS Direct Connect有 1Gbps 和 10Gbps 兩種埠可用。客戶可以通過建立多個連線來實現更大的頻寬和更高的冗餘。而對於頻寬要求不高的客戶也可向支援 AWS Direct Connect 的 APN 合作伙伴預定頻寬粒度更細的託管連線。需要注意的是每個託管連線僅能支援訪問單個VPC，或者只能訪問公有地址空間的AWS服務端點。當然客戶可以通過多個託管連線用於訪問多個VPC。

常見的接入場景及分工介面

場景一： 客戶網路邊界已經到達特定Direct Connect 節點

如圖所示，客戶在特定的Direct Connect 節點（圖中虛框所示位置）所在的機房已經部署了網路邊界裝置，那麼可以向運營該節點的運營商訂購 到AWS Direct Connect路由器的樓內跳線即可完成連線。

此場景下，分工介面較為簡單：

各部分的技術要求分解如下：

場景二： 客戶通過乙太網專線 與AWS Direct Connect互聯

如圖所示，客戶資料中心的網路邊界通過AWS合作伙伴或者獨立第三方提供的乙太網專線相互連線。

此場景下， 802.1q VLAN終結在客戶側路由器上， AWS Direct Connect路由器與 客戶路由器建立BGP鄰居並相互發布路由資訊；這裡特別需要關注的是，乙太網專線需要支援VLAN透傳，確保雙方向的乙太網幀能夠攜帶正確的VLAN 標籤抵達對端。

此場景下，建議分工介面如下：

各部分的技術要求分解如下：

場景三： 客戶通過 MPLS網路與AWS Direct Connect互聯

如圖所示，客戶資料中心的網路邊界通過AWS合作伙伴或者獨立第三方提供的MPLS網路相互連線。

此場景下， 802.1q VLAN終結在MPLS 網路的PE路由器上， AWS Direct Connect路由器與 PE路由器建立BGP鄰居並相互發布路由資訊；

建議分工介面如下：

各部分的技術要求分解如下：

當然對於某些MPLS服務提供商而言，上述技術需求不一定能夠滿足；在這種場景下，客戶可以通過在Direct Connect節點部署CE路由器來解決，此時這個場景就等同於前述場景一，相當於客戶把網路邊界通過第三方MPLS網路延伸到Direct Connect 節點。

案例、經驗與最佳實踐

案例一

某客戶A需要建設連線國內總部和海外某AWS Region的乙太網專線；因客戶自身供應商名單的限制，客戶選用了獨立的第三方供應商建設專線，在建設過程中由於網路資源和覆蓋不全，供應商又將該連線的海外部分鏈路分包給其它供應商，導致在整個實施過程週期長、溝通成本高、進度緩慢； 在最後樓內跳線環節中出現了尾纖插錯口的差錯，但是由溝通效率低，該問題耗費了接近一週時間才最終修正。

經驗與最佳實踐：

• 支援 AWS Direct Connect 的 APN 合作伙伴［1］具備豐富的專案實施經驗和完善的流程，能夠快速完成Direct Connect連線的部署，建議客戶在實施時予以考慮;
• 樓內跳纖環節，自測環節應當在客戶路由器或專線終結裝置處面向AWS側做硬環，客戶可自助在控制檯上觀察該連線對應的AWS側路由器的介面的狀態，如果連線狀態未能從down跳轉為up，責說明光纖或連線有異常，需要即時排查；全流程的排查請參見AWS Direct Connect使用者指南的相關章節［2］;

案例二

某客戶B在與獨立的第三方供應商購買乙太網專線的過程中，未能充分溝通VLAN透傳的技術需求，導致在專線實施的最後驗證環節專線供應商因資源利用率的問題拒絕支援此技術要求，除非客戶大幅提升專線頻寬。

經驗與最佳實踐：

• 在前期需求溝通階段客戶應與供應商充分溝通所適用場景的技術需求，避免後期被動；
• 部分獨立的第三方專線供應商在特定場景下會對提供千兆光口、VLAN透傳等功能，附帶要求客戶承諾比較高的簽約頻寬（例如50Mbps ~ 200Mbps，具體請諮詢相關專線供應商）才予以滿足；
• 在低頻寬、連線單個VPC的場景下，建議客戶向支援 AWS Direct Connect 的 APN 合作伙伴預定連線；

案例三

某客戶C使用場景二所示的乙太網專線連線與AWS 互聯，並選用了獨立的第三方運營商進行專線建設。在專線鋪設過程中，第三方運營商因資源問題無法直接在終結裝置上提供1000BASE-LX光口，而是 使用了獨立的電轉光裝置完成介面型別轉換。在後續的使用過程中，曾經出現由於該轉換裝置出現故障而導致專線臨時中斷， 影響了業務可用性。

經驗與最佳實踐：

• 專線的可用性取決於整條鏈路中可靠性最弱的一環，客戶需要與專線供應商明確各個環節的可用性SLA及如何保障的議題;
• AWS Direct Connect支援客戶通過多條連線實現相互負載分擔和冗餘，同時也支援專線與VPN之間的相互備份。可用性要求較高的場景下，建議客戶通過兩個或以上的Direct Connect連線，或者採用VPN備份方式在專線意外中斷時保護業務可用性；
• 專線的備份機制需要時常驗證和演練，確保在異常情況下能夠按預期工作;

案例四

某客戶D的業務需求需要一條能夠保證從AWS海外區域到國內某資料中心的低延遲、穩定的鏈路用於傳輸實時視訊流。通過與支援AWS Direct Connect 的 某APN 合作伙伴訂購了一條頻寬為20Mbps的託管連線，整個實施過程在3天以內即告完成，客戶實測頻寬和線路丟包率、抖動等都符合業務需求，而且該連線的頻寬具備一定彈性。該APN合作伙伴承諾的擴容等後續服務的響應和實施週期等都明顯快於傳統方式。

經驗與最佳實踐：

• 對於小頻寬、僅需要與單個VPC進行互聯的應用場景，支援 AWS Direct Connect 的 APN 合作伙伴的託管連線能夠給予客戶更快的實施週期和更靈活的簽約頻寬；在適用的場景、或者專案週期較為緊迫的情況下推薦選用；
• 客戶可以訂購多個類似的託管連線，實現與多個VPC分別互聯；

參考連結

作者介紹

丁成銀

AWS解決方案架構師，獲得AWS解決方案架構師專業級認證和DevOps工程師專業級認證。負責基於AWS的雲端計算方案架構的諮詢和設計，同時致力於AWS雲服務在國內的應用和推廣，在數字媒體、電信、網際網路和遊戲、企業混合IT等方面有著豐富的實踐和設計經驗。在加入AWS之前，歷任數字媒體娛樂系統工程師、寬頻業務架構師、雲解決方案架構師，負責數字媒體娛樂系統、雲端計算解決方案等服務的諮詢和架構設計工作。