上一篇處理的是 AWS 內部不同 VPC 之間的連線。
但企業環境中的系統不一定全部都在雲端，公司可能仍有辦公室網路、資料中心，或尚未搬上 AWS 的內部系統。
例如：
公司內部網路
172.16.0.0/16
│
│ ?
▼
AWS Production VPC
10.20.0.0/16
當公司內部網路與雲端需要持續互通，就形成了 Hybrid Network（混合網路）。
在 AWS 中，常見的兩種連線方式是：
兩者都能把企業網路延伸到 AWS，但解決的問題不太一樣。
例如：
兩週內要讓公司內部人員連上 AWS 的新系統。
和：
未來幾年都要在公司資料中心與 AWS 之間持續傳輸大量資料。
需要的網路設計就可能完全不同。
Site-to-Site VPN（站台對站台 VPN） 會在企業端設備與 AWS 之間建立 IPsec 加密隧道。
常見架構可以理解成：
公司內部網路
│
防火牆 / 路由器
│
│ IPsec VPN
│ 經由網際網路
▼
AWS
公司端實際負責建立 VPN 的，是自己管理的防火牆、路由器或其他 Customer Gateway Device（客戶端閘道裝置）。
AWS 中另外會建立一個 Customer Gateway（客戶閘道） 資源，用來記錄公司端設備的公有 IP、路由等資訊；它本身並不是 AWS 幫公司建立的一台路由器。
AWS 端則常見兩種連接方式：
例如：
公司內部網路
│
VPN
│
▼
Transit Gateway
┌──┼──┐
▼ ▼ ▼
Prod Shared Security
VPN 的優勢是可以利用既有的網際網路連線，當公司設備與網路條件已經具備時，通常比新建專用線路更容易快速導入。
但要注意：
IPsec 解決的是傳輸加密，不會讓網際網路本身變得更穩定。
實際連線品質仍會受到網路供應商的路徑、壅塞、封包遺失，以及公司端設備效能等因素影響。
如果公司與 AWS 之間的連線會長期存在，而且有：
就可以進一步評估 AWS Direct Connect（DX）。
概念上：
公司資料中心
│
│ 專用網路連線
▼
Direct Connect 據點
│
▼
AWS
Direct Connect 的主要流量不需要經過一般公用網際網路，而是透過 AWS 的 Direct Connect 據點建立專用網路連線。
但它並不是進 AWS Console 建立一個資源就完成了。
實際導入通常還會牽涉：
公司網路
↓
電信業者 / Direct Connect Partner
↓
Direct Connect 據點
↓
AWS
因此 Direct Connect 的建置時程還會受到線路、設備、電信業者與實際交付流程影響。
相較於一般透過網際網路建立的 VPN，Direct Connect 比較適合需要長期、大量傳輸，或希望網路路徑與可用頻寬較容易預期的情境。
但：
使用專用連線，不代表延遲一定比較低。
實際延遲仍然會受到地理距離、線路設計與應用程式本身的處理時間影響。
另外，Direct Connect 預設不會自動加密傳輸中的資料。
如果企業要求傳輸加密，可以在應用層使用 TLS，或依架構需求在 Direct Connect 上搭配 VPN。
因此可以先簡單記成：
Site-to-Site VPN
→ 經由網際網路建立 IPsec 加密連線
Direct Connect
→ 建立專用網路連線
兩者解決的問題不同，也可以同時存在。
可以先整理成：
| 比較項目 | Site-to-Site VPN | Direct Connect |
|---|---|---|
| 連線方式 | 經由網際網路建立 VPN | 專用網路連線 |
| 傳輸加密 | 使用 IPsec | 預設不自動加密 |
| 導入方式 | 可利用既有網路與設備 | 需安排據點、業者與線路 |
| 導入速度 | 條件具備時通常較快 | 受線路交付時程影響 |
| 連線品質 | 受到網際網路路徑影響 | 較容易規劃穩定的路徑與容量 |
| 常見情境 | 快速建立混合網路、作為備援 | 長期、大量或重要的跨站流量 |
假設現在的需求是：
兩週內要讓公司人員連到 AWS 新系統，目前主要是一般互動操作，也沒有大量持續性的資料傳輸。
那可以優先評估 Site-to-Site VPN，先利用既有網路建立加密連線。
但如果一開始就知道：
公司資料中心與 AWS 未來每天都會持續傳輸大量資料，而且這條連線會成為正式環境的重要依賴。
就可以提早規劃 Direct Connect，而不是等 VPN 開始成為瓶頸後才處理。
混合網路還有一個很重要的設計問題：
主要路徑失敗時，流量要走哪裡？
每一組 AWS Site-to-Site VPN Connection 本身包含兩條 VPN 隧道，而且 AWS 建議兩條都完成設定，以便其中一條無法使用時進行切換。
但：
VPN Tunnel 1 ─┐
├─ 同一台防火牆
VPN Tunnel 2 ─┘
│
同一條網路線路
仍然不能算完整的備援。
如果防火牆或網路供應商的線路本身發生故障，兩條 VPN 隧道都有可能一起受到影響。
Direct Connect 也是一樣。
公司資料中心
│
單一 Direct Connect
│
▼
AWS
仍然存在單點故障。
因此正式環境可能設計成：
主要路徑
→ Direct Connect
備援路徑
→ Site-to-Site VPN
或建立多條彼此獨立的 Direct Connect 連線。
但有備援路徑以外，還需進一步確認：
以上可以統整為一句話：
高可用不是看有幾條 VPN 或專線，而是檢查整條網路路徑是否仍存在共同故障點。
前幾篇已經從單一 VPC，一路延伸到多 VPC 與混合網路。
下一篇會把視角重新拉回應用程式的入口，看看使用者流量進入 AWS 後，該如何選擇 Application Load Balancer（ALB）與 Network Load Balancer（NLB），以及 HTTP Routing、TCP / UDP、固定 IP 等需求會如何影響選型。
iThome鐵人賽
看影片追技術