多雲環境的網路連接設計
多雲中的第一個可能也是主要的挑戰是正確的網路連接。 所有主要的CSP都有自己的網路連接方式，例如 Azure ExpressRoute、AWS Direct Connect、GCP Dedicated Interconnect、VMware NSX 等等。 他們也有自己的所有網路連接的要求和細節。 所以多雲網路連接是企業在多雲環境運作失敗的主要原因之一。 企業在開始構建多雲環境之前確實必須有一個專門的網路計劃。 在本文中，我們將會討論以下主題：
- 探索不同的網路連接概念，例如 VPN 和與主要CSP AWS/Azure/GCP 的直接網路連接(網路專線)
- 設計一個能夠解決成本、安全性、internet 和Service Level的網路拓撲
- 了解雲端中的不同Network Protocol
網路為王 — 多雲的網路連接概念
我們在運用多雲策略加速企業的業務有使用智慧手機來進行與雲端的類比。 我們把它從盒子裡拿出來，開啟電源後。 首先要做的就是將手機與網路連接。 雲端也是如此。 我們可以在任何 CSP 中進行帳戶訂閱並開始在雲端內作業，但企業希望員工可以安全地從辦公室連接到特定的雲端服務。 基本上，有三種選項可以使用：“VPN、網路專線和使用ISP的完全託管服務(例如MPLS-VPN)。”
VPN
常用的技術之一是 VPN。 從本質上講，VPN 是一個以Internet為載體的通道。 它從某個 Ip address或 Ip range連接到 CSP 中gateway service的Ip address。
在我們探討VPN之前，我們必須知道什麼是公有雲。如果我們在 Azure、AWS、GCP 或任何其他公有雲中進行業務部署服務，我們正在將我們的資料中心擴展到這個雲端。因此，它需要在我們的資料中心和公有雲中的擴展之間建立網路連接。最快也最簡單且可能也是最具成本效益的方法是使用 VPN。Internet永遠都存在，理論上我們所要做的就是分配允許與該擴展通訊的 IP address，從而建立一個VPN tunnel。這個tunnel可以位於辦公室位置之間，也可以僅來自一個連接到雲端的用戶。後者是我們所說的client to site VPN。
在公有雲本身中，該網路連接需要在某個地方終止，除非我們希望所有雲端資源都開放給Internet。這種情況很少見，當然不建議這樣做。通常，企業會保護工作負載免受直接和不受控制的外部網路的影響。當我們設置 VPN 時，我們需要在公有雲中配置一個區域，其中包含 VPN 終止的gateway。從gateway出來後，可以使用雲端中的路由規則和路由表將流量路由到雲端中的其他資源。它的工作方式與在傳統資料中心的工作方式相同，在用戶實際進入系統之前，我們將擁有一個特定的連接區域甚至是 DMZ。以下架構顯示了 VPN 連接到公有雲的基本原理。
設計Azure VPN 的網路連接
Azure提供了 VPN gateway來連接我們的地端機房到Azure雲端中，稱為Site to Site VPN．這個方式用的是IPsec與IKE協定．
而如果企業的IT人員從世界任何地方進入到azure雲環境內的系統則可以使用client to site VPN，Azure把它稱為point-to-site VPN ，並支援以下協定：
- OpenVP，使用SSL或TLS
- SSTP(Secure Socket Tunneling Protocol):微軟專有，並只支援Windows Devices
- 基於IPsec的IKE2. Mac電腦也支援此協定
下圖則顯示Azure支援不同的 VPN連線方式：
由上圖可知，要完成這樣的連接在 Azure中第一件要做的事就是設定vNet．而這個vNet內必需要有一個gateway，而這個gateway就會是Azure網路中的endpoint，它會需要一個IP address．
下一步就是將gateway連接到我們的地端機房．我們在地端機房一樣會需要一個網路設備(Router or Firewall )或專門的VPN appliance來與Azure對接．當然我們也可以用Virtual appliance 來對接，像是VMware NSX(software-defined networking)．下圖為一個簡易的Azure VPN gateway設計．
設計AWS VPN 的網路連接
AWS一樣提供了site-to-site與 client-to-site VPN，一樣使用加密的tunnel並連接到AWS的網路．AWS在這一類的網路連接提供了HA的功能，它會有兩個 tunnel(Active-Standby)並且是橫跨數個AWS的機房．
我們需要在 地端機房有一個customer gateway(一樣是我們既有的網路設備)與 並且在AWS上有一個VPG(VPN連線的終點)，而在這我們有兩種選項：
選項一：使用VPG(virtual private gateway)進行單一個地端機房的site-to-site VPN： VPG作為一個AWS VPC與外網網路的橋樑，並且使用IPsec作為其網路協定：
選項二：一樣單一個機房的site-to-site VPN但使用transit gateway來語customer gateway來連接．這通常是我們在 AWS中有多個VPC，並且地端機房需要跟這些 VPC裡的服務都連接上．
而如果我們有多個辦公室或機房要同時連接AWS，則 AWS提供了 CloudHub的功能(傳統的hub-and-spoke 網路模型)．在這個場景中AWS與多個辦公室或機房要啟用BGP網路協定並搭配AS number，並且所有的site的ip address都不可以有衝突．意味著這一種連接方式需要良好的IP規劃．
加速的site-to-site VPN 連接是這裡值得一提的功能。 它使用 AWS Global Accelerator 將流量從地端機房（通常是 WAN）路由到離customer gateway設備最近的 AWS 位置。 此解決方案需要使用transit gateway。 如之前所述，AWS 部署了兩條tunnel：primary和secondary。 兩條tunnel都有一個加速器和，然後通過 AWS global network發送流量，尋找優化的路線以確保應用程式的最佳效能。
通過OpenVPN也可以使用 AWS 的 Client VPN(client-to-site)並且使用TLS連線加密．在這裡我們需要在 VPC 中分配一個subnet，Client VPN 將在該subnet中終止，即所謂的target network。 將 subnet與 Client VPN endpoint關聯起來使我們能夠建立 VPN session。
下圖為一個用戶使用OpenVPN連線進入AWS環境，並且如果該 VPC有跟其他的VPC做peering也可以連到另一個 VPC.
設計GCP VPN 的網路連接
基本上 GCP的 VPN連線方式與AWS/Azure大同小異，一樣使用IPsec建立tunnel連到GCP．而為了建立這個連線，有部署了兩個 gateway：一個用來加密網路流量，另一個則是用來解密的．
GCP提供了兩種類型的VPN: HA(High availability)與Classic VPN. 使用HA VPN從地端機房連線到一個 ＧＣＰ的region機房．這裡與AWS/Azure的差異在於 GCP 自動為 HA VPN gateway選擇兩個public IP address。 這個gateway有兩個interface，對於每個interface，我們得到一個來自ip address pool的固定IP address，並只能用在HA上。 我們可以將多個tunnel 連接到 HA VPN gateway。
當然，我們還需要指向 HA VPN gateway的地端機房 VPN gateway。 下圖顯示了 VPN 如何使用 HA VPN gateway將地端機房連接到 GCP 中的project。
在 HA VPN 使用兩個interface的情況下，Classic VPN gateway只有一個具有單一個public IP address的gateway。 兩種設置之間的一個主要區別是，對於 Classic VPN，我們需要在 GCP 環境中指定路由轉發規則，而 HA VPN 預設情況下會處理這些路由。 下圖顯示了Classic VPN 設置，包括在 GCP 環境中引導流量所需的路由表。
我們已經討論了三大 CSP 中的不同 VPN 選項：AWS/Azure/GCP。 VPN 使用Internet作為載體，但企業通常希望更可靠、更直接地連接到他們的雲端環境。 儘管 VPN 肯定具有成本優勢，但它們在速度/網路through/可靠度方面存在限制。 Direct connection(網路專線)可能是更好的選擇。 在下一節中，我們將探討這些與不同平台的網路專線。
網路專線(Direct connectivity) 的概念
VPN的運作是以internet當作載體．有很多原因，企業通常不太喜歡拿來做主力線路(通常是備援線路)，即使是通過安全、加密的VPN tunnel也不行。 頻寬更穩定、網路流量更可預測且更安全的解決方案是在我們的地端機房中的路由器或防火牆與 CSP 之間的網路專線。 歸根結底，這種方案是關於從一般性的網路設備直接拉專線到CSP的gateway，該設備直接將流量路由到企業租用的ＣＳＰ環境。 前幾大的CSP 都提供網路專線解決方案。 合作夥伴與不同雲端的互連也可以通過託管的ISP（例如是方電訊）獲得。
Azure ExpressRoute
這是Azure的網路專線名稱．Azure的ExpressRoute有幾種部署方式:
- Point-to-point Ethernet
- Any-to-any IPVPN
- cloud exchange co-location
Point-to-point Ethernet
Point-to-point Ethernet在ISO L2 或L3 上進行連結與管理。 在 ISO 中，L2 是data link layer，L3 是network layer。 主要區別在於 L3 提供路由並負責靜態和動態路由，而 L2 只有switching。 L3 通常在涉及 intra-VLAN 時實施。 簡單地說，L3 看得懂IP address，可以在 IP 基礎上路由流量，而 L2 看不懂IP address。 話雖如此，它通常會 — — 或者至少被推薦 — — 在 L3 上進行。
Any-to-any IPVPN
這種方式將企業的 WAN 與 Azure 整合在一起，通過 Azure 中的虛擬資料中心延伸了地端機房，使其真正成為一個將虛擬資料中心作為分公司的環境。 大多數企業是使用 ISP 提供 MPLS-VPN 網路。 ExpressesRoute 使用L3 將網路連接到 Azure。
Cloud exchange co-location
對於將系統託管在第三方廠商的企業來說，這可能是首選。如果co-location 的地方有cloud exchange這項服務，我們可以使用這個服務。通常，這是用L3的方式來管理。co-location環境連接到exchange — — 再從exchange中連接到 Azure。
ExpressRoute 允許我們用 10 到100 Gbps 的網路port直接連接到 Microsoft 的網路。頻寬從 50Mbps 到 10 Gbps 不等。
我們需要了解的最後一件事是 ExpressRoute 設置線路和peering的方式。線路是我們的地端機房和 Microsoft 的雲端服務（例如 Azure 或 Office 365）之間的logical connection。該連接是通過ISP。接下來，有兩種類型的peering: Microsoft peering和private peering。當我們使用 Office 365 或 Dynamic 365 等 Microsoft 雲端服務時，需要 Microsoft peering。private peering 則是連接到 Azure Cloud。
下圖顯示了Microsoft peering與 private peering之間的不同
那麼，企業需要什麼？ 這實際上取決於我們計劃的使用情況。 Azure 也是提供此類 Office 365 的 SaaS 的基礎平台。如果擁有大量員工的公司也使用 Office 365，那麼在調整 ExpressRoute 大小時也應考慮這一點。
AWS Direct Connect
這是 AWS網路專線的名稱．在地端機房它與Azure一樣使用一般性的網路設備與之對連．在AWS端，則會需要連結到一個endpoint，這個endpoint通常是 VPC裡面的VPG或是到AWS service.
這個VPG的連接類似Azure 的private peering, 而AWS service則類似於Microsoft peering — 雖然底層技術是不同的．在AWS中 Azure peering這個術語稱為virtual interface. 簡單來說Direct Connect 包括了兩個components:
- connection本身，意指從地端機房連結到AWS的Direct connect服務
- Virtual interface — 要access到AWS service, 一個 private virtual interface 掛在到我們在 AWS的 VPC, 而public virtual interface則是access到 AWS的外部服務(如S3)．
下圖則為AWS Direct Connect的基本架構圖
AWS Direct Connect提供客戶 1或10G的網路port, 而合作的ISP則會提供頻寬50/100/200/300/500Mbps．
GCP Dedicated Interconnect
GCP的網路專線類似於AWS Direct Connect: 從地端機房的網路設備到google peering edge; 這是在Google提供這些peering zone的託管設施中完成的。 從那裡，網路流量被轉發到 GCP 中的cloud router。
Dedicated Interconnect是單一個 10G 或 100G link或多個Link連接到Cloud router的形式提供。
GCP也提供了與Partner(合作的ISP)的網路專線(稱作Partner interconnect)，作法也類似於AWS．
下圖分別是Dedicated Interconnect與Partner Interconnect的網路架構
透過第三方來管理雲端運算的網路專線
許多ISP(電信商)提供到 Azure、AWS、GCP 的專線連接(通常稱為Communication as a Service)。對於大多數大型企業來說，這可能是首選的方案，因為他們通常已經通過 MPLS 或網路專線來連接 WAN與co-locate的機房。ISP會有一個區域(zones)，他們可以將客戶連接到他們想要的 CSP 的peering zone。在文獻中，這也被稱為cloud hotel，但基本上，它是ISP資料中心內的一個區域，來自ISP客戶的 MPLS/專線可以連接到ExpressRoute/Direct Connect/Dedicated。
這個解案為公司提供了許多優勢。首先，這些網路連接完全由ISP管理，因此企業不用去管網路怎麼連接跟管理。其次，由於ISP可以去跟 CSP談判，他們通常有更多的選擇，可以根據客戶所需的頻寬提供更精細的解決方案。最後，真正多雲的企業可以選擇通過一個ISP連到多個到不同的 CSP。
為避免誤解，企業幾乎總是必須使用ISP來獲得網路專線，因為ISP的資料中心擁有 CSP 的peering 或edge zones的設施。
主要的託管設施、資料中心提供商和託管商提供雲端網路交換。一些很好的例子是 Equinix、NTT(台灣可能是方電訊之類)。所有這些ISP公司在資料中心和連接交換方面都是全球性的，包括Internet上的backbone連接。
Software-defined networking(SDN)
想像一下，你正在開車。 為了讓你順利從 A 到 B，我們鋪設了道路。 儘管各國的道路佈局可能不同，但世界各地的道路基礎架構通常是相同的。 將土壤壓平，然後在上面鋪上硬的東西。 可以是鵝卵石、混凝土板或柏油。 如果連接的道路或多或少由相同的材料製成，效果會更好：當道路在上方的材料方面都是一樣時，您的駕駛將更加順暢。
網路也是如此。 網路是我們處理工作負載的道路。 當這些網路具有相同的拓撲結構時，資料和工作負載的傳輸更容易。
為了持續道路的類比，我們可以將SDN定義為一種神奇的柏油(一種網路的虛擬化)。它在實體網路設備之上建立同質網路，連接不同的環境，甚至在不同的平台上，而無需更改物理網路拓撲。事實是，這個說的比做的還要容易。有相當多的先決條件需要被滿足。
當然，最大的想法是，如果我們可以虛擬化服務器的使用和存儲設備的使用，那麼我們應該能夠對網路做同樣的事情。換句話說：告訴我們的網路，它實際上不僅僅是一個物理網路，它還可以代表連接不同環境的多個網路。
有許多 SDN 解決方案，例如 Cisco ACI、HPE Aruba 和 big switch，但在這一點上，值得稍微詳細討論的是 Vmware 的 NSX 作為 SDN 和 SDDC (Software Defined Data Center)的領先技術。
Vmware 的 NSX 包括虛擬網路和安全性。它是一個網路管理程序，因此它從實體的網路和資安設備（例如防火牆）中抽像出網路邏輯。通過這樣做，NSX 啟用了micr-segmentation，但它還利用網路層的方式使其可以擴展到其他平台。 NSX 是 VMware on AWS(在GCP稱為 Vmware engine, Azure稱為vmware solution) 基礎的一部分：企業可以在 AWS 中建立 VPC，並使用 NSX 將其與地端機房的 Vmware 環境無縫連接，從而將地端機房網路和安全參數擴展到公有雲。
地端機房和 AWS(或GCP) 成為一個資料中心。正如 Vmware 所說，VMware NSX Cloud 提供了一種通用且一致的方式來保護和管理跨公有雲的雲原生工作負載，以及從單一管理平台管理本地工作負載，這表明借助 NSX，企業始終擁有一個他們在 AWS (或GCP)中的單一個View。
從底層技術來說，它在 AWS 全球基礎設施之上，在地端機房和 AWS 中的 VPC 之間使用內建的 IPsec VPN tunnel。下圖顯示了 VMware on AWS 的high level架構，使用 Vmware 技術將地端機房擴展到 AWS：
超前部署 — 為多雲設計網路拓樸
在設計網路拓撲之前，我們需要回答一個問題：企業的業務在網路連通性方面需要什麼？ 但在我們開始設計和實施 VPN 或拉專線之前，還有一些事情需要仔細考量。
第一步是評估。 一家企業通常已經擁有一個網路。 我們將需要評估該網路的配置方式。 終端用戶如何連接到系統？ 他們如何連到Internet？ 流量如何通過系統進行網路路由？ 從網路的角度如何保護這些系統？ Firewall、proxy和reserve proxy是放在哪裡？ 是的，，在我們開始設計我們的網路連到公有雲之前，這一切都很重要。
進行網路設計前的必要工作
如上所述，大多數企業是使用來自 ISP 的網路服務，不管是專線還是Internet。 因此，評估的一部分是探索 ISP 在交付和公有雲網路連接管理方面的產品。 例如，他們能否提供來自cloud hotel或資料中心 peering zoner的直接連接？
在進行網路設計時，我們應該解決許多方面的問題。
成本
正如我們在運用多雲策略加速企業的業務文章中所討論的，成本不僅僅包括購買設備的現金。顯然，公司需要地端機房的路由器和防火牆來建立連接 — — 除非我們沒有地端機房。這些是資本支出成本(CapEX)：通常在一段期間的設備折舊的投資。
其他成本是雲端中虛擬設備的成本：gateway router和firewall。與雲端中的任何東西一樣，我們可以用pay-as-you-go的方式購買，企業按月為其使用的服務支付費用。這是運營成本(OpEx)。接下來是使用網路流量的成本。最後，如果我們不選擇全託管的服務，我們將需要一名工程師來實施解決方案並可能對其進行管理。
計算成本可能會變得複雜。經常被遺忘的一點是，CSP也會計算流量本身的成本：傳入和傳出到雲端平台。以每 GB 的為計價單位，我們必須意識到流量可能會迅速增加，並且inbound/outbound 資料流量成本可能會變得相當高。在 ExpressRoute、Direct Connect 和Dedicated Interconnect中，inbound網路流量是不計費的，outbound才需要。
例如，我們使用 Azure VPN gateway開啟一個網路連接，如下面的屏幕截圖所示。
上圖中，我們使用一個VPN connection是730小時(假設連結是一整個月都不會斷)，如果我們的site to site沒有超過 10個tunnels跟 Point to Site是128個tunnel，我們不會有額外的費用．哪一個費用就是 USD 26.28．
不過還沒算完，Azure通常有一個免費的網路流量費用(例如是100G，這個會變動)．超出這個免費的之後就會有流量費產生．
這只是一個非常簡單的例子，但希望它清楚地表明我們在成本方面需要考量的事項。 在這個例子中，我們只要考慮一個 VPN gateway和 網路流量，但是讓我們假設我們想要監控和保護我們的VPN connection，這將我們帶到下一個問題。
安全性
顯然，我們需要保護我們的網路，以防止未經授權的人連到我們的雲端環境。 VPN 和專線等連接可以使用 IKE、IPsec 和 TLS 進行加密。首先，請檢查服務是否預設是加密的。 GCP 的Dedicated Interconnect是加密的，而 AWS Direct Connect 不是 — — 加密需要額外開啟功能。接下來，我們需要驗證設定。為此我們需要有加密的基本知識與瞭解加密的協定。
然後，我們將不得考量兩端網路的端點。網路連接到底在哪裡終止？我們不希望這一類的連線在實際工作負載（應用程式）所在的同一區域終止，因此強烈建議在網路端點所在的雲端環境中建立一個單獨的segment(有點像傳統機房的DMZ)。這個segment可以保護網路流量流入和流出，也可以將流量路由到 VPC 內的其他segment。這個概念通常被描述為一個Hub。
Cloud Hub可以被視為網路流量的控制中心，所有網路連接都聚集在一起，並且 將流量路由到正確的方向。正確的方向是什麼？這是特定Ip address流量應該去的地方和允許去的地方。我們可以將Hub想像成一個非常複雜的東西。企業的業務需要指定流量規則、協議、政策、PaaS 的 IP 和 SaaS 服務從租戶外部連接，因此需要以正確的方式連接。
企業面臨的一個主要問題是他們在雲端中使用的Internet service的安全性。 VPC內的instance需要往Internet連線可能需要使用Public IP，而這正是企業通常不允許的。 解決此問題的一般方法是 NAT，但這確實帶來了新的挑戰。 顯然，CSP 提供這種傳統的方式是沒有問題的，並提出了更複雜的解決方案。
AWS 與Azure提供稱為Private Link的服務，而GCP稱之為Private Service Connect。Private Link 提供了我們的 VPC 與 PaaS 服務之間的private connection。 這個方式不會將PaaS/SaaS的資料暴露到Internet上(前提是設定有做好)。 Private Link使用Private endpoint，因此不再需要具有 NAT 這一個功能。
下圖為GCP Private service Connect的架構圖
Internet access(指的是公有雲內的服務)
在Internet access方面，我們有兩種選擇：
從公有雲連到Internet：通過公有雲連到Internet。 我們在公共雲中的環境是面向Internet的。 這當然需要強大的安全管理能力。
從ISP的線路從地端機房連到Internet：這是我們從公司網路流向Internet。 使用VPN 或網路專線連到雲端環境。這類似將Public Cloud的VPC當作企業的內網．
擁有多個分公司的大型企業可以有local internet breakouts，每個地點的用戶都可以access internet。 Local breakout旨在降低通過 WAN 的流量，隨著 SaaS 和其他雲端服務的使用量的巨大增長，通過 WAN 傳輸的流量將急劇增加。 因此，local internet breakouts來分散流量對於大型公司來說是一個很好的解決方案。 必須在雲端中傳輸的流量也需要路由和負載均衡。
CSP 擁有各自的骨幹網路和技術來控制和負載平衡流量，確保它基於 DNS 連線到目的地。 在 Azure 中，這就是Traffic Manager，而在 AWS 中，該服務稱為 Route 53，而 GCP 提供 Cloud DNS。
服務等級與其支援
諸如AWS/Azure/GCP等公有雲都有非常高的SLA，不過這個只限定在專線的服務．而 VPN，如同我們之前所提到．是透過Internet為載體來提供地到雲的私有連線，其連線服務有不穩定不可靠的狀況會發生．而其設定與管理還有安全性甚至監控都需要一個技能良好的網路工程師來進行．從企業的業務角度來看有太多非核心業務的事需要考量．所以從這個層面來說一個全託管的CaaS(Communication as a Service)可能是一個選擇．
多雲環境的網路協定
我們在本文中提到了很多縮寫和術語。 如果您不是網路工程師，其中一些術語可能會讓你沒有感。 然而，諸如 BGP、ASN 和 TLS 之類的東西對於理解網路連接是如何作業的是很重要。 好消息是，任何公有雲都是基於Internet的。 如果沒有Internet，我們就不會有雲端運算。 因此，IP、HTTP、還有 HTTPS 等protocol非常重要。 但是其他的呢？ 在雲端網路連接方面，還有很多需要考慮的因素。 畢竟，我們確實希望我們的網路連線是安全的，並且只朝著我們希望它們前進的方向前進。 最重要的是，我們必須啟用網路連接以建立地端於雲端甚至是雲端與雲端的資源之間的通訊。 這需要這些IT資源有同一種語言。像是什麼是IP，HTTP/HTTPS．TCP/UDP，SMTP，BGP等．
這裡我們必須注意的一件事是 IP，基本的 Internet protocol。我們有兩個版本的 IP：即 IPv4 和 IPv6。後者在未來是必需的，因為 IPv4 上的 IP 地址數量有限且即將耗盡，但隨著 NAT的採用和大型企業沒有歸還大量未使用的public IP range，目前這是一個假議題。然而，對於當前和未來數億萬記的IOT devices的使用，IPv6 將會是重要的。實作 IPv6 相當複雜，因為它具有完全不同的語法。
IPv4 地址是32-bit的，而 IPv6 是128 bit。 IPv4 地址類似於 192.168.x.x。轉換為 IPv6，即 0:0:0:0:0:ffff:c480:101。不難想像，將 IPv4 對應到 IPv6 非常複雜。因此，所有 CSP 都支援 IPv6，但並非所有CSP內的雲端服務都支援。如果我們想使用公有雲中的 IPv6，請務必檢查我們要使用的雲端服務有沒有支援。
總結
在本文中，我們探討了連接到公有雲的不同網路概念。沒有網路，什麼都不會動 — — 或者至少什麼都無法連接到。我們已經了解了 VPN 概念與 Azure、Aws 和 GCP 的網路專線之間的主要區別。一個重要的學習是，VPN 比較適合網路品質要求不高的服務，但企業通常需要更好的網路品質，他們應該考慮轉向網路專線方案。要為我們的業務設計網路策略，我們需要考慮一些關鍵參數 — — cost、internet access、security和service level。
從技術的角度來看，我們介紹了 SDN 等概念，還了解到我們可以使用 VMware 的 NSX 等概念將地端網路擴展到公有雲。網路為王，因此我們還需要對網路用於建立連接和啟用流量的各種協議有一個基本的了解，以確保雲端各組件能互相通訊。本文總結了 IPv4 和 IPv6 之間的區別以及對後者的支援程度的簡短說明。
