1. 前言

基於多區域架構中的 DR（災難復原）需求，或是工作負載的延遲要求，實務上常會遇到想把同一分割區（partition）內的多個區域，例如東京區域（ap-northeast-1）與大阪區域（ap-northeast-3），透過不經由網際網路的封閉式網路互相連接的情境。AWS 提供了多種方式可實現這件事，各自具有不同的特性、限制與成本結構。

我曾經試過用 Transit Gateway 來做多區域架構，不過之前沒有實際比較過速度，所以想說來實驗看看，到底差異會有多大。
本文是在個人的 AWS 帳號上實際建置以下 3 種方式，並在 AZ 內、同一區域內 AZ 間、區域間實測延遲與吞吐量，整理出差異、成因與選型指引。

• VPC Peering（跨區域）
• AWS PrivateLink（跨區域）
• AWS Transit Gateway（跨區域 Peering）

也歡迎大家一邊讀一邊猜猜看，哪一種會最快。

不過，像 Site-to-Site VPN 之類的方式也有人可能會想到，但這次不納入實測。原因後面會說明。

另外，本文是寫給已經大致理解 AWS VPC Networking 基礎（子網路、路由表、安全群組），並想了解多區域設計實務上取捨的工程師。

2. 驗證的整體樣貌

2.1 比較對象路徑

以下是這次比較的內容。

分類｜路徑｜連接方式
A｜東京 1a ↔ 東京 1a｜同一 AZ 內（基準）
B｜東京 1a ↔ 東京 1c｜同一區域內 AZ 間（基準）
C｜東京 1a ↔ 大阪 3a｜VPC Peering
D｜東京 1a ↔ 大阪 3a｜Transit Gateway inter-region peering
E｜東京 1a ↔ 大阪 3a｜PrivateLink（跨區域）

把 A 和 B 放在基準位置，是為了把「跨區域本身的成本」與「跨 AZ 的成本」分開看。A 與 B 雖然過去已經被很多人測過，但除了和 C～E 的差異外，再加上和 A、B 的比較，我認為也能掌握東京到大阪之間在物理距離上大概有多遠這個基準，因此這次也納入量測。

2.2 為什麼不比較 Site-to-Site VPN

若要以 VPC 直連的方式建立 Site-to-Site VPN，雙方 VPC 都需要準備 Virtual Private Gateway 與 Customer Gateway，而且 Customer Gateway 端通常還要在帶有 EIP 的 EC2 上跑軟體 VPN（例如 strongSwan）。這比較偏離本文主軸，也就是「僅使用 AWS 的託管服務就能完成的封閉式連線」。此外，考量到該架構的複雜度與可獲得的洞見（例如 IPsec 開銷的影響）多半已是已知結果，因此這次先不做實測。

3. 各方式的技術細節

先簡單說明一下各方式。

3.1 VPC Peering

• 以 1 對 1 的方式連接兩個 VPC。不支援傳遞式 Peering（即使 A 與 B Peering、B 與 C Peering，A 也不能直接到 C）。當 VPC 數量增加時，需要做全互連（full mesh）設計，N 個 VPC 需要 N(N-1)/2 條 Peering 連線。
• 路由是透過在各 VPC 的路由表中手動新增靜態路由來完成，不會自動傳播。

另外，查了一下，東京區域似乎從 2018 年開始就支援 inter-region peering（跨區域 VPC Peering）了。

3.2 AWS PrivateLink（跨區域）

• PrivateLink 是把位於 NLB（Network Load Balancer）後方的服務，透過 VPC Endpoint Service，以單向方式提供給其他 VPC。
• 以往只能在同一區域內，從 Interface Endpoint 連到 Endpoint Service；但在 2024 年 11 月後，cross-region 連線正式 GA，可以原生連到其他區域的 Endpoint Service。

關於 PrivateLink，我個人認為很重要的一點是 Private DNS 的行為。同區域內的 PrivateLink，只要把 PrivateDnsEnabled: true 設為啟用，就能透過 AWS 內部 DNS 解析直接用服務名稱存取；但跨區域的 endpoint 不支援這種 Private DNS 自動解析。因此需要明確使用 endpoint 專屬 DNS 名稱（例如 vpce-xxxx.vpce-svc-xxxx.ap-northeast-3.vpce.amazonaws.com）來做名稱解析與使用。

此外，這次也是我第一次用 PrivateLink 連接區域間的服務。建置過程中踩到 3 個限制，順手記錄下來。（如果你本來就知道，可以直接跳過……）

限制 1：NLB 在 IPv6 Source NAT 關閉時不能有 UDP 監聽器

我原本想在透過 PrivateLink 對外公開的 NLB 上設定 TCP_UDP 監聽器，結果被 Network Load Balancers used with AWS PrivateLink cannot have TCP_UDP listeners when 'EnablePrefixForIpv6SourceNat' is set to 'off' 這個錯誤擋下來。後來即使改成單獨的 UDP 監聽器，也一樣報錯，因此推測 PrivateLink 底下的 NLB，只要不啟用 IPv6 Source NAT（EnablePrefixForIpv6SourceNat），就根本不能有 UDP 監聽器。
而要做 IPv6 化，需要為 VPC 與子網路配置 IPv6 CIDR，還要改成雙堆疊 NLB，這超出這次範圍，因此經由 PrivateLink 的量測（路徑 E）只測 TCP。其他路徑（A～D）則 TCP、UDP 都有測，所以看第 6 章結果時請注意這點。

限制 2：NLB 不會轉送 ICMP

一開始我原本想用 ICMP ping 來測延遲，但在確認動作時 ping 竟然 100% loss。看起來 PrivateLink 的 NLB 雖然是 L4 pass-through，但 L3 協定（ICMP）本來就不會轉送。
因此後來改成所有路徑都統一用 TCP 連線建立時間來量測（詳見第 5 章）。這裡有點卡關，但回頭看其實也讓我更直接體會到 PrivateLink「單向公開、協定受限」的設計理念。

限制 3：cross-region 支援需要提供端 NLB 至少 2 AZ 以上

啟用 cross-region PrivateLink 時也踩到一個限制。執行 aws ec2 modify-vpc-endpoint-service-configuration --add-supported-regions 時，出現 Services must support at least 2 availability zones for cross region 錯誤而失敗。也就是說，要啟用 cross-region PrivateLink，提供端的 NLB 必須跨越至少 2 個 AZ。
（我一開始只把 NLB 放在與測試用 instance 相同的 1 個 AZ 中。）
後來再補一個 AZ 的 NLB 專用子網路，把 AZ 數量增加到 2 後就通過了。

3.3 AWS Transit Gateway（跨區域 Peering）

• Transit Gateway 是 Hub-and-Spoke 型連線，可集中管理多個 VPC。
• 跨區域時要使用 TGW peering attachment。
• Peering attachment 不支援路由傳播。和 VPC attachment 不同，必須手動在 TGW 路由表中加入對端 CIDR 的靜態路由。
• 在 Peering attachment 處於 pending-acceptance 狀態時，不能新增路由。必須按照「建立 attachment → 執行 accept → 確認狀態變為 available → 新增路由」的順序處理。

3.4 MTU 的差異

原本準備時我以為跨區域（VPC Peering、TGW）的 MTU 會限制在 1500，但實際用 ping -M do -s <size>（Don't Fragment 標記）量測後，結果和預期不同。

經路 MTU（實測）
同一區域內（AZ 內 / AZ 間）9001
跨區域 VPC Peering 8500
跨區域 TGW peering 8500
跨區域 PrivateLink 無法量測（因為 NLB 不轉送 ICMP）

路徑 E 也試著用和其他路徑相同的方法（ping -M do）實測，但即使是大約 1200 bytes 的小尺寸也會 100% 封包遺失。正如 3.2 的限制 2 所述，PrivateLink 的 NLB 根本不轉送 ICMP（L3 協定），所以用一般方法無法量測 MTU。

查了一下，2025 年 3 月的更新後，inter-region VPC peering 也支援 Jumbo Frame（最大 8500 bytes）了，而我原先認知的 1500 bytes 是更新前的舊資料。

另外，AWS 官方文件也明確寫著：The MTU for inter-region VPC peering connections is 8500 bytes。

3.5 加密

VPC Peering 與 TGW peering 在跨區域通訊時，都會由 AWS 的網路基礎設施層自動以 AES-256 加密。這是一種不需要使用者額外設定、但在選擇封閉式連線方式時相當有吸引力的特性。

方式｜跨區域加密
VPC Peering（inter-region）｜AES-256（自動，網路層）
TGW peering（inter-region）｜AES-256（自動，網路層）
PrivateLink（cross-region）｜官方文件未明確寫出加密方式（雖然是經由 AWS 骨幹網路，理論上應有某種保護；但找不到像 VPC Peering / TGW 那樣明寫「AES-256」的描述）

3.6 成本比較

各方式的成本結構差很多。以下根據東京區域（ap-northeast-1）的實際單價計算。

項目｜單價（東京區域）
VPC Peering｜連線本身免費（無時間費）
Transit Gateway VPC attachment｜$0.07 / 小時
Transit Gateway peering attachment｜$0.07 / 小時
Transit Gateway 資料處理費｜$0.02 / GB
Interface VPC Endpoint｜$0.014 / 小時（每個 AZ）
VPC Endpoint 資料處理費｜$0.01 / GB（每月 1PB 以內）
Network Load Balancer｜$0.0243 / 小時
NLB Capacity Unit（NLCU）｜$0.006 / 小時（依使用量變動）
跨區域資料傳輸（東京→大阪，送出端計費）｜$0.09 / GB

首先，東京到大阪之間的跨區域資料傳輸費是 $0.09 / GB。

以這個為前提，若維持常時連線，估算每月固定費用（不含依流量計費部分，以 730 小時 / 月換算）如下。

方式｜內含項目｜每月固定費
VPC Peering｜連線本身免費｜$0
Transit Gateway｜4 個 attachment（東京、大阪雙方的 VPC attachment + peering attachment）× $0.07 / 小時 × 730 小時｜約 $204
PrivateLink｜NLB 1 台 × $0.0243 / 小時 × 730 小時 ≒ $17.7
＋ Interface Endpoint 2 AZ × $0.014 / 小時 × 730 小時 ≒ $20.4｜約 $38

在資料量少、連線數少的情況下，VPC Peering 無疑是最便宜的；TGW 則是以固定費換取多個 VPC 集中管理的規模優勢；PrivateLink 則介於兩者之間——這是我實際看數字後的感受。
當 VPC 數量增加到 Full Mesh 的 Peering 連線數量已經難以管理時，TGW 的固定費就開始有其價值，這應該會是成本面上的關鍵。

4. 驗證環境建置

基礎設施全部都是用 CloudFormation 建置的。

4.1 模組構成

檔案內容
tokyo-network.yaml｜東京 VPC、2 AZ 的子網路與 EC2、SSM 用 Interface Endpoint、S3 結果 bucket
osaka-network.yaml｜大阪 VPC、1 AZ 的子網路與 EC2、同上
connectivity-peering-*.yaml（3 個檔案）｜VPC Peering 連線與雙向靜態路由
connectivity-tgw-*.yaml（5 個檔案）｜東京與大阪各自的 TGW、inter-region peering、accept 後新增的靜態路由
connectivity-privatelink-*.yaml（2 個檔案）｜大阪端內部 NLB + VPC Endpoint Service（提供端）、東京端 Interface Endpoint（使用端）

以下是實際使用的模板內容。太長了，所以先收起來。

東京・大阪網路

tokyo-network.yaml```
...（原始範例程式碼略，維持原格式）

osaka-network.yaml```
...（原始範例程式碼略，維持原格式）

VPC Peering

connectivity-peering-connection.yaml```
...（原始範例程式碼略，維持原格式）

connectivity-peering-routes-tokyo.yaml```
...（原始範例程式碼略，維持原格式）

connectivity-peering-routes-osaka.yaml```
...（原始範例程式碼略，維持原格式）

#### [](#transit-gateway)Transit Gateway

connectivity-tgw-tokyo.yaml```
...（原始範例程式碼略，維持原格式）

connectivity-tgw-osaka.yaml```
...（原始範例程式碼略，維持原格式）

connectivity-tgw-peering.yaml```
...（原始範例程式碼略，維持原格式）

connectivity-tgw-routes-tokyo.yaml```
...（原始範例程式碼略，維持原格式）

connectivity-tgw-routes-osaka.yaml```
...（原始範例程式碼略，維持原格式）

connectivity-tgw-vpcroute-tokyo.yaml```
...（原始範例程式碼略，維持原格式）

connectivity-tgw-vpcroute-osaka.yaml```
...（原始範例程式碼略，維持原格式）

PrivateLink

connectivity-privatelink-provider.yaml```
...（原始範例程式碼略，維持原格式）

connectivity-privatelink-consumer.yaml```
...（原始範例程式碼略，維持原格式）

4.2 CloudFormation 跨區域限制

CloudFormation 的 Export / Fn::ImportValue 只在同一區域內有效。因此，東京與大阪各自部署完網路 stack 後，我是透過 describe-stacks 取得 Outputs，再以 --parameter-overrides 的方式明確傳給下一個 stack。

OSAKA_VPC_ID=$(aws cloudformation describe-stacks \
  --region ap-northeast-3 --stack-name osaka-network \
  --query "Stacks[0].Outputs[?OutputKey=='VpcId'].OutputValue" --output text)

aws cloudformation deploy \
  --region ap-northeast-1 --stack-name connectivity-peering-connection \
  --template-file connectivity-peering-connection.yaml \
  --parameter-overrides TokyoVpcId=$TOKYO_VPC_ID OsakaVpcId=$OSAKA_VPC_ID

4.3 注意：路由表不能同時持有相同目的地的兩條路徑

實際部署後我才發現，當我想把 VPC Peering 的路由與 TGW 的路由同時加到東京端路由表時，會因為 The route identified by 10.1.0.0/16 already exists 而失敗。

仔細想想其實很合理，因為路由表對於同一個目的 CIDR 只能有一條路由。VPC Peering 和 TGW 都是把對端 VPC 的整個 CIDR 當作目的地，因此不能同時共存於同一個路由表。

所以，VPC 端的靜態路由我拆成 Peering 用與 TGW 用兩個獨立的小型 stack，在實測時只部署其中一個進行切換。至於 PrivateLink，因為它不需要針對 VPC CIDR 做路由，而是直接到 Interface Endpoint 的 ENI，因此不受這個限制，可與 Peering / TGW 並行維持啟用。

5. 量測方法

這次不是只看平均值，而是用 p50 / p95 / p99 百分位數來評估。因為單次平均值對離群值與瞬間壅塞很敏感，可能會誤判各方式之間的實際差異。

• 延遲：原本打算用 ICMP ping 測量，但如前所述，經由 PrivateLink（NLB）時 ICMP 不會直接通過，因此統一改成 TCP 連線建立時間來量測。每條路徑對 iperf3 監聽埠（5201）做 300 次 TCP three-way handshake（每 0.2 秒一次），把連線建立所花的時間當作 RTT 相當值記錄。timeout 設為 0.4 秒（Linux 的 SYN 重傳大約在 1 秒後才會發生，因此設得比那短很多，將 timeout 視為遺失而非慢 RTT）。
• 吞吐量：iperf3 執行 30 秒，搭配 -i 1（每秒間隔報告）。分別測試 TCP 單一串流（-P 1）、TCP 平行串流（-P 4）、UDP（-u，測 jitter 與 packet loss）三種模式，各執行 3 次，彙整區間樣本後計算 p50/p95/p99（每條路徑約 270 筆樣本）。一開始原本規劃 300 秒 × 3 次，但因後面提到的網路 burst credit 枯竭問題，逐步縮短後最後定為 30 秒。

5.1 卡住的點：網路 burst credit 枯竭

一開始用 300 秒 × 3 次的完整負載去測所有路徑時，只有第一個執行的路徑 A 能顯示預期的高吞吐量（TCP 單一 4.96 Gbps、4 並列 12.4 Gbps、UDP 4.98 Gbps），之後的路徑 B～E 幾乎都卡在 TCP 4 並列與 UDP 約 0.77 Gbps 的現象。

我推測原因是檢驗用的 c6i.large 有網路 I/O burst credit。路徑 A 在長時間高負載傳送下把 credit 用光了，而後續路徑在 credit 還沒恢復前就接著執行，因此測到的不是連線方式差異，而是 credit 枯竭時點的差異。

第一次修正是把 iperf3 執行時間從 300 秒縮短成 60 秒，並在路徑間加入 5～10 分鐘冷卻時間。這樣路徑 A 單獨測時的劣化有改善，但路徑 B 之後即使加上 60 秒流程與冷卻，還是會重現同樣劣化。看起來 network I/O burst credit 的恢復並不像 EC2 CPU credit 那麼快，而是更像依據 instance 啟動後的累積量管理，幾分鐘到 10 分鐘的冷卻並不夠。

於是我又把執行時間縮短到 30 秒，並把量測順序反過來，改成 E→D→C→B→A 再測一次。結果最先執行的 E、D 都能維持高吞吐，但第 3 個 C 在維持高吞吐 16 秒後，1 秒內就掉到約 0.77 Gbps，剛好看見 credit 用盡的瞬間。這也確認了不是某個方式本身比較慢，而是依據啟動後累積使用量會耗盡 credit，而且正向與反向順序都能重現相同行為。

5.2（注意）關於這次檢證

雖然百分位數評估提高了對離群值的抗性，但因為是個人驗證，量測期間只有數分鐘，無法捕捉跨日的時段或星期變動。另外，第 6 章的吞吐量是透過在各路徑前重新啟動 instance，讓 credit 回到滿格後單獨量測，以排除 credit 枯竭的影響；但即使如此，仍然是在同一 session、短時間內量測，所以本文中的數值請把它當作趨勢參考。

5.3 執行命令

量測是從本機 PC 透過 aws ssm send-command 把量測腳本送到 EC2 上自動執行。每條路徑只要像下面這樣跑即可。

./scripts/run_measurement.sh <REGION> <CLIENT_INSTANCE_ID> <PATH_ID> <PEER_HOST> <RESULTS_BUCKET> [SKIP_UDP] [DURATION_SEC]

# 例：路徑 A（東京 AZ 內）
./scripts/run_measurement.sh ap-northeast-1 $TOKYO_INSTANCE_A_ID A $TOKYO_INSTANCE_A2_IP $TOKYO_RESULTS_BUCKET 0 30

# 例：路徑 E（PrivateLink，因不支援 UDP，所以 SKIP_UDP=1）
./scripts/run_measurement.sh ap-northeast-1 $TOKYO_INSTANCE_A_ID E $PL_ENDPOINT_DNS $TOKYO_RESULTS_BUCKET 1 30

內部實作很單純，就是在 EC2 上執行 tcp_latency.py（以 TCP 連線建立時間為基礎的延遲探測，300 次）→ iperf3（TCP -P 1 / -P 4 / UDP，各 30 秒 × 3 次，並用 -J 輸出 JSON），把原始資料上傳到 S3。
如前所述，為了避免 credit 枯竭，最後的量測流程改成在每條路徑前先把 EC2 stop → start 一次，然後只測一條。

VPC Peering 與 TGW 不能同時在同一個 VPC CIDR 上持有路由（見 4.3），所以在測 C、D 之前，我會先把對應的 VPC 路由 stack 重新部署一次。

# 從 Peering 切換到 TGW
aws cloudformation delete-stack --region ap-northeast-1 --stack-name peering-routes-tokyo
aws cloudformation delete-stack --region ap-northeast-3 --stack-name peering-routes-osaka
aws cloudformation deploy --region ap-northeast-1 --stack-name tgw-vpcroute-tokyo \
  --template-file connectivity-tgw-vpcroute-tokyo.yaml \
  --parameter-overrides TokyoRouteTableId=$TOKYO_RT_ID TokyoTransitGatewayId=$TOKYO_TGW_ID
aws cloudformation deploy --region ap-northeast-3 --stack-name tgw-vpcroute-osaka \
  --template-file connectivity-tgw-vpcroute-osaka.yaml \
  --parameter-overrides OsakaRouteTableId=$OSAKA_RT_ID OsakaTransitGatewayId=$OSAKA_TGW_ID
# 若要從 TGW 切回 Peering 就反過來做

6.2 的補充實驗（切出 NLB 帶來的延遲差）是利用 PrivateLink 提供端的內部 NLB 即使在經由 VPC Peering / TGW 時，也能直接以 private IP 到達這個特性，只要把目的地從 instance 改成 NLB 的 private IP 即可。

# 取得 NLB 的 private IP（每個 AZ 會回傳多個）
NLB_ARN=$(aws cloudformation describe-stacks --region ap-northeast-3 \
  --stack-name privatelink-provider \
  --query "Stacks[0].Outputs[?OutputKey=='NlbArn'].OutputValue" --output text)
aws ec2 describe-network-interfaces --region ap-northeast-3 \
  --filters "Name=description,Values=ELB net/xxxxxxxxxx/xxxxxxxxxxxxxxxx" \
  --query 'NetworkInterfaces[].[AvailabilityZone,PrivateIpAddress]'

最後，把所有路徑的 S3 原始資料同步到本機，計算 p50/p95/p99。

python3 scripts/aggregate_results.py \
  --bucket <tokyo-results-bucket> \
  --bucket <osaka-results-bucket> \
  --out results_summary.csv

6. 結果

終於來到測量結果。

6.1 延遲（TCP 連線建立時間，單位 ms）

路徑｜p50｜p95｜p99｜max
A（同一 AZ 內）｜0.21｜0.26｜0.31｜2.08
B（AZ 間）｜1.65｜1.70｜1.74｜4.53
C（VPC Peering）｜8.89｜9.94｜10.02｜10.81
D（TGW）｜11.01｜12.33｜12.77｜17.95
E（PrivateLink）｜13.32｜14.58｜16.00｜19.65

所有路徑的 loss rate 都是 0%（只有 E 因為後面提到的原因，採用 60 秒流程量測的結果）。A→B→C→D→E 呈現漂亮的單調增加，清楚看得出跨 AZ 的成本（A 與 B）、跨區域的成本（B 與 C/D/E），以及各連線方式本身的額外成本（C、D、E）是層層疊加的。

6.2 補充實驗：NLB 會多出多少 ms

E（PrivateLink）是最慢的結果，但我想切分看看，這到底是 PrivateLink 機制本身慢，還是單純因為經過 NLB 而慢，所以又做了補充實驗。
PrivateLink 提供端所使用的內部 NLB（大阪 VPC 內）即使透過 VPC Peering / TGW 也能直接到其 private IP，所以我把 C、D 的路徑維持不變，只把目的地從原本的 instance 改成 NLB 的 private IP，重新做 TCP 連線建立時間測試（300 次探測，單次量測。這個實驗與 6.1 的執行時間不同，因此 C、D 的直接值與 6.1 的數值有幾百微秒誤差）。

路徑｜目的地｜p50(ms)｜NLB 增量
C｜instance 直接｜8.73｜-
C + NLB｜NLB 經由｜9.94｜+1.21 ms
D｜instance 直接｜10.88｜-
D + NLB｜NLB 經由｜11.59｜+0.71 ms
E｜PrivateLink（跨區域）｜13.32｜-

從 C、D 都看得出來，只要多經過 NLB，就會增加約 +0.7～1.2 ms。再把 D + NLB（11.59 ms）和 E（13.32 ms）相比，還會剩下大約 +1.7 ms 的差距。也就是說，E 的慢大致可以拆成以下幾部分：

• 「跨區域」本身的成本（C、D 的 8～11 ms）
• 「經過 NLB」的成本（約 +0.7～1.2 ms）
• 「PrivateLink cross-region endpoint 機制」本身的成本（約 +1.7 ms，推測與 Interface Endpoint 的 ENI 處理（含 NAT）及 cross-region tunneling 有關）

6.3 吞吐量

如 5.1 所述，透過在各路徑前重啟 instance、把 credit 補滿後再單獨量測，可以得到排除 credit 枯竭影響的乾淨數值。

路徑｜TCP 單一（p50, Gbps）｜TCP 4 並列（p50, Gbps）｜UDP（p50, Gbps）
A（同一 AZ 內）｜4.96｜12.4｜4.98
B（AZ 間）｜4.96｜12.4｜4.98
C（VPC Peering）｜2.41｜10.58｜4.98
D（TGW）｜2.50｜9.67｜4.98
E（PrivateLink）｜2.36｜9.99｜不測（見 3.2）

同一區域內（A、B）不論 AZ 內或 AZ 間，TCP 4 並列都在 12.4 Gbps 左右，幾乎一樣，接近 instance 型號的實力值。
另一方面，在跨區域的 C～E 中，TCP 4 並列出現了 VPC Peering（10.58G）> PrivateLink（9.99G）> TGW（9.67G）的實質差異。與同一區域相比，單純跨區域就會讓吞吐量下降接近 2 Gbps（我認為其中一個原因是後面提到的 MTU 差異：9001 vs 8500）。

TCP 單一串流在 C～E 都大約落在 2.36～2.50 Gbps，方式之間沒有像 TCP 4 並列那麼明顯的差異。當 RTT 達到 8 ms 以上時，單一 TCP flow 的有效頻寬很容易被 bandwidth × RTT 限制住，因此在沒有做平行化的情況下，可能比起方式本身，RTT 的影響更大。

UDP 在 A～D 都幾乎維持在 4.98 Gbps，幾乎看不出方式差異。雖然我是用 iperf3 -u -b 0（不限制速率）送出，但也有可能是 client 端送出速率本身已經封頂，因此 UDP 不是很適合拿來觀察各方式的帶寬差異。

7. 考察

以下整理這次量測結果，並加入我自己的看法。

7.1 為什麼延遲會排成這個順序

• A→B（約 +1.4 ms）：同一區域內跨 AZ 的成本。AZ 間本來就是不同資料中心，出現這樣的增加很合理。
• B→C（約 +7.2 ms）：跨區域本身的成本。東京與大阪之間的物理距離與 AWS 骨幹網路的 hop 數應該是主因。
• C→D（約 +2.1 ms）：VPC Peering 與 TGW 的差異。TGW 提供 Hub 功能，會多經過 VPC attachment 與 peering attachment 這些 hop，因此比單純 1 對 1 連線的 VPC Peering 稍慢，這在架構上很自然。
• D→E（約 +2.3 ms）：從 6.2 的補充實驗可知，其中約 +0.7～1.2 ms 可用「經過 NLB」解釋，剩下約 +1.7 ms 應該是 PrivateLink cross-region endpoint 機制本身的額外負擔。

為什麼 PrivateLink 會有額外的 +1.7 ms

這只是我的理解，但我認為 TGW 與 PrivateLink 本來就是不同類型的機制。（如果有更深入了解的朋友，也歡迎指正）

• TGW 是用 L3 routing 來連接：TGW peering 只是兩個 TGW 之間加密後的站點間連線，封包基本上只是逐 hop 做 L3 轉送。VPC Peering 與 TGW 本質上都是提供路徑，途中不會把連線終止再重新封裝。
• PrivateLink 是以 proxy 方式連接：Interface Endpoint 不只是單純對應到對端 VPC 的路徑，而是包含雙向 NAT 的服務連接機制。（PrivateLink 會使用 NAT，以便即使網段重疊也能通訊）

基於這個差異，我認為經過 PrivateLink 時會多出 1.7 ms 左右的延遲。

7.2 與 MTU 的關係

如 3.4 實測，跨區域的 VPC Peering / TGW peering MTU 是 8500（同區域內則是 9001）。差距大約 500 bytes，雖然不算大，但在 6.3 的乾淨測試結果中，同區域內（A、B，TCP4 並列約 12.4Gbps）與跨區域 C～E（9.7～10.6Gbps）之間仍然有明顯差異。
若只用 MTU 的差距來解釋接近 2 Gbps 的落差，似乎有點過頭，所以我認為除了 MTU 以外，跨區域的實體距離與 hop 數帶來的開銷也有影響。

7.3 網路 burst credit 很難搞

這次最辛苦的就是吞吐量量測。像 EC2 的 c6i.large 這種 burst performance 類型 instance，網路頻寬也會用 credit 制在內部管理，測試設計（執行時間、執行順序、冷卻時間）如果不同，就會讓看起來明明是同一路徑的數值差很多。
即使把 300 秒縮短成 60 秒、並在路徑間加冷卻，也無法完全消除「先測的路徑比較有利」這種不公平，最後只能靠每條路徑前都重啟 instance 再單獨量測這個土法煉鋼方式收尾。
如果要做這類 benchmark，我覺得可以注意以下幾點：

• 使用網路頻寬有保證、沒有 burst 特性的 instance 類型（這次因成本因素先不考慮）
• 為每條路徑準備完全獨立、沒有 credit 歷史的 instance，或是在量測前直接重啟 instance

7.4 為什麼吞吐量也會出現方式差異

如 6.3 所示，TCP 4 並列的排序是 VPC Peering（10.58G）> PrivateLink（9.99G）> TGW（9.67G）。
有趣的是，延遲上 TGW 比 PrivateLink 快，但吞吐量卻反過來。

我推測 TGW 最慢的原因，除了 7.1 提到的 VPC attachment 與 peering attachment 這些額外 hop 之外，TGW 本身作為集中的 Hub、要處理多個 VPC 與多種連線的共享基礎設施，本來就比單純 1 對 1 連線更容易有吞吐量天花板。
相對地，PrivateLink 雖然在延遲上因為 NAT + NLB 多了一層，但 NLB 本身就是以高吞吐量處理為前提設計的資源，所以在吞吐量上不一定會像 TGW 那麼不利。（這部分仍屬推測）

8. 選擇指引

綜合這次結果，我認為只看速度（延遲）就直接說 VPC Peering 一定是唯一解，還太早。實際選架構時，必須同時看速度、架構（可維運性與未來擴充性）、費用這 3 個面向。
如果只看速度，VPC Peering 的確有優勢；但當 VPC 數量增加、或有「公開範圍希望只限服務層級」這類需求時，答案就會不一樣。

把這次結果從 4 個觀點整理如下。

方式｜速度（p50 延遲）｜吞吐量（TCP 4 並列，p50）｜架構｜費用（常時連線固定費 / 月）
VPC Peering｜8.89 ms（最快）｜10.58 Gbps（最快）｜僅 1 對 1；VPC 數一多就要 N(N-1)/2 條 full mesh，維運會失控｜$0（僅資料傳輸費按量計）
Transit Gateway｜11.01 ms（比 Peering 慢 +2.1 ms）｜9.67 Gbps（最慢）｜Hub-and-Spoke，可集中管理多個 VPC，但仍需維護靜態路由｜約 $204 / 月（4 個 attachment）
PrivateLink｜13.32 ms（比 Peering 慢 +4.4 ms）｜9.99 Gbps（中間）｜不是整個 VPC，而是以服務單位單向公開，不需要 full mesh 可達性｜約 $38 / 月

無論是延遲還是吞吐量，VPC Peering 都是性能最好的結果；但有趣的是，TGW 與 PrivateLink 在延遲與吞吐量的排序會互換（延遲是 TGW 較佳，吞吐量是 PrivateLink 較佳）。
因此，最後還是得看你最重視的是哪一種性能特性。

原文出處：https://qiita.com/sh_fukatsu/items/541051be6cbd4a90f2a6