本篇整理 VPC 的四項進階功能，依用途分成三類：

• 連接多個 VPC：VPC Peering、Transit Gateway
• 不經過網際網路使用 AWS 服務：VPC Endpoint
• 記錄 VPC 裡的流量：VPC Flow Logs

這些功能都建立在 Day 5 的 VPC、subnet、route table 之上。

🕸️ VPC Peering：兩個 VPC 一對一連線

每個 VPC 都是一個獨立、隔離的私有網路，預設無法與其他 VPC 互相連線。公司的 VPC 通常不只一個（不同部門、不同環境、不同帳號），需要互通時，最基本的做法是 VPC Peering：在兩個 VPC 之間建立一條一對一的私有連線，可以跨帳號、跨 Region。

建立 peering 連線之後，流量不會自動通過，還需要兩項設定：

1. 兩邊的 route table 各加一條路由：目的地是對方 VPC 的 CIDR，目標是這條 peering 連線
2. Security Group（Day 6）允許來自對方 CIDR 的流量

VPC A（10.0.0.0/16）的 route table
目的地            目標
10.0.0.0/16       local
10.1.0.0/16       pcx-0abc（peering 連線）   ← 送往 VPC B 的流量走 peering

VPC B（10.1.0.0/16）的 route table
目的地            目標
10.1.0.0/16       local
10.0.0.0/16       pcx-0abc                   ← 回程同樣需要路由

限制一：不能轉送

Peering 連線只承載這兩個 VPC 之間的流量，VPC B 不會把來自 VPC A 的流量轉送到其他地方：

• A 與 B、B 與 C 各有 peering 時，A 仍然無法經由 B 連到 C
• 同樣的道理，A 也無法使用 B 的 NAT Gateway、Internet Gateway 或 VPN 連線對外連線

要互通的每一對 VPC，都必須各自建立 peering。

限制二：網段不能重疊

兩個 VPC 的 CIDR 有重疊時，無法建立 peering。原因在於路由：假設兩個 VPC 都使用 10.0.0.0/16，VPC A 的 route table 中，10.0.0.0/16 已經代表 VPC A 自己（local），無法再用同一個網段指向對方；送往 10.0.1.5 的流量，無從判斷應該留在本地還是送往對方。

因此規劃多個 VPC 時，各 VPC 的 CIDR 需要事先錯開。

VPC 數量增加時

由於不能轉送，N 個 VPC 全部互通所需的 peering 數量是 N × (N − 1) ÷ 2：5 個 VPC 需要 10 條，10 個 VPC 需要 45 條，而且每一條都要在兩邊的 route table 加上路由。VPC 數量增加後，peering 的建立與維護成本會快速上升，下一節的 Transit Gateway 就是用來解決這個問題。

🛤️ Transit Gateway：所有網路接到同一個中心

Transit Gateway 是一個中央路由器。每個 VPC 只要連接到 Transit Gateway 一次（每個連接稱為一個 attachment），就能透過它與其他已連接的 VPC 互通；N 個 VPC 只需要 N 個 attachment。

除了 VPC，地端網路也能連接到 Transit Gateway。連接方式有兩種，Day 22 會詳細介紹：

• Site-to-Site VPN：透過網際網路建立加密通道，連接地端與 AWS
• Direct Connect：地端與 AWS 之間的實體專線

地端只要連接到 Transit Gateway 一次，就能連到所有已連接的 VPC。

兩層 route table

使用 Transit Gateway 時，流量會依序經過兩層 route table：

VPC A（10.0.0.0/16）連到 VPC B（10.1.0.0/16）

1. VPC A 的 route table：10.1.0.0/16 → tgw-0123             流量送進 Transit Gateway
2. TGW 的 route table：  10.1.0.0/16 → VPC B 的 attachment   流量轉送到 VPC B

Transit Gateway 可以建立多個 route table，每個 attachment 關聯其中一個，藉此把網路分組。例如開發環境與正式環境的 VPC 使用不同的 route table，兩組之間互不相通，但都能連到共用服務的 VPC 與地端。因此 Transit Gateway 不只能讓所有網路互通，也能控制哪些網路之間不能互通。

範圍

Transit Gateway 是 Region 層級的資源，只能連接同一個 Region 的 VPC。跨 Region 時，在各 Region 各建一個 Transit Gateway，再以 Transit Gateway peering 將它們互相連接。

跨帳號時，Transit Gateway 建在一個專門的網路帳號裡，再用 AWS RAM（Resource Access Manager，在帳號之間共用資源的服務）共用給其他帳號，讓其他帳號的 VPC 建立 attachment。

與 VPC Peering 比較

🚪 VPC Endpoint：不經過網際網路使用 AWS 服務

private subnet 裡的 EC2 沒有公開 IP，存取 S3 時的預設路徑是：EC2 → NAT Gateway（Day 5）→ Internet Gateway → S3 的公開端點。這條路徑有兩個缺點：

• 費用：NAT Gateway 依處理的資料量收費，大量傳輸時，費用可能超過 EC2 本身
• 網路路徑：流量必須經過 NAT Gateway 與 Internet Gateway 這條對外路徑；若資安或法規要求流量不得經過網際網路，這條路徑就不符合要求

VPC Endpoint 讓 VPC 內的資源直接連到 AWS 服務，不經過 NAT Gateway 與 Internet Gateway。VPC Endpoint 分成 gateway endpoint 與 interface endpoint 兩種，下圖比較三種存取 S3 的路徑：

Gateway endpoint

Gateway endpoint 不是網路介面，而是 route table 中的一條路由：目的地是 S3（或 DynamoDB）的 IP 範圍清單（稱為 prefix list），目標是這個 endpoint。

private subnet 的 route table
目的地                 目標
10.0.0.0/16            local
0.0.0.0/0              nat-0abc    ← 其他網際網路流量仍然走 NAT Gateway
pl-63a5400a（S3）      vpce-0def   ← 送往 S3 的流量改走 gateway endpoint

route table 會選擇最精確的路由。S3 的 prefix list 比 0.0.0.0/0 精確，所以送往 S3 的流量改走 endpoint，其他流量則不受影響。

Gateway endpoint 不收費，但只支援 S3 與 DynamoDB，而且只能存取同一個 Region 的服務。

Interface endpoint

Interface endpoint 是在 subnet 中建立一個具有私有 IP 的網路介面，對該服務的請求都送往這個私有 IP。它支援大多數 AWS 服務，並可以套用 Security Group，控制哪些來源可以連入。

啟用 Private DNS 後，服務原本的網址（例如 sqs.ap-northeast-1.amazonaws.com）在 VPC 內會解析成這個私有 IP。應用程式不需要修改任何設定，請求就會改走 interface endpoint。

Interface endpoint 依時數與處理的資料量收費。

兩者的關鍵差異：有沒有 IP

**Gateway endpoint 只是 route table 中的一條路由，沒有 IP；interface endpoint 是一個具有私有 IP 的網路介面。**兩者在使用範圍上的差異，都從這一點而來：

• Gateway endpoint 只對套用該 route table 的 subnet 有效。地端，以及透過 peering 或 Transit Gateway 連接的其他 VPC，都不使用這張 route table，因此無法使用
• Interface endpoint 有私有 IP，任何能連到這個 IP 的網路都能使用，包括透過 VPN、Direct Connect 連接的地端，以及透過 peering、Transit Gateway 連接的其他 VPC

選擇依據：VPC 內的資源存取 S3 或 DynamoDB，使用免費的 gateway endpoint；地端要透過 Direct Connect 以私有連線存取 S3，或要存取的是其他服務，使用 interface endpoint。兩種可以同時存在。

限制存取範圍

兩種 endpoint 都可以附加 endpoint policy，限制透過這個 endpoint 能存取哪些資源，例如只允許存取公司自己的 bucket。

反方向，S3 的 bucket policy 可以使用 aws:SourceVpce 條件，規定 bucket 只接受來自特定 endpoint 的請求：

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": ["arn:aws:s3:::my-bucket", "arn:aws:s3:::my-bucket/*"],
  "Condition": { "StringNotEquals": { "aws:SourceVpce": "vpce-0def" } }
}

這條規則拒絕所有不是經由 vpce-0def 送來的請求，bucket 因此只能從這個 VPC 存取。

PrivateLink

Interface endpoint 背後的技術稱為 AWS PrivateLink。除了 AWS 服務，其他公司或公司內的其他團隊，也能透過 PrivateLink 把自己的服務提供給其他 VPC：

• 提供方：把服務放在 Network Load Balancer（NLB，Day 14）後方，建立 endpoint service
• 使用方：在自己的 VPC 建立 interface endpoint，以私有 IP 連到提供方的服務

PrivateLink 只開放提供方指定的那一個服務，而不是讓兩個 VPC 整個互通；兩邊的 VPC 不需要 peering，網段重疊也不影響。這兩點正好對應 VPC Peering 的限制。

📜 VPC Flow Logs：記錄流量

VPC Flow Logs 記錄 VPC、subnet 或網路介面上的 IP 流量資訊：來源、目的地、port、協定，以及這筆流量被允許還是被拒絕。記錄可以送到 CloudWatch Logs（Day 24）、S3 或 Amazon Data Firehose（Day 20）。

Flow Logs 記錄的是流量的中繼資料，不包含封包內容。最常見的用途是排查連線失敗的原因：從記錄可以判斷流量是否到達，以及是否被 Security Group 或 NACL（Day 6）拒絕。

一筆記錄的內容

以下是一筆預設格式的記錄：

2 123456789010 eni-0a1b2c3d 203.0.113.12 10.0.1.25 49761 22 6 20 4249 1418530010 1418530070 REJECT OK

主要欄位的意義：

這筆記錄表示：外部 IP 203.0.113.12 嘗試以 SSH 連到 10.0.1.25，流量被拒絕。

判斷是 Security Group 還是 NACL 拒絕

Flow Logs 的 action 欄位只記錄允許或拒絕，不會註明是哪一層拒絕的。判斷時需要搭配 Day 6 的觀念：Security Group 有狀態（stateful），允許的連入流量，其回應會自動允許；NACL 無狀態（stateless），連入與回應各自依規則判斷。

不記錄的流量

Flow Logs 不記錄部分流量，例如送往 Amazon 提供的 DNS 伺服器的查詢，以及 EC2 存取 instance metadata（169.254.169.254）的請求。

📌 補充

🧭 從需求回推：該用哪一個

本篇的功能各自解決不同的連線需求。把前面各節的判斷依據串起來，可以整理成一張由需求出發的判斷流程：

依需求分成三條路徑：

• 連接另一個 VPC 或地端：先確認是否只需要開放其中一個服務。是的話使用 PrivateLink，不必讓兩個 VPC 整個互通，網段重疊也不受影響；需要整個網路互通時，VPC 數量少、不需要轉送也不連接地端，使用 VPC Peering，否則使用 Transit Gateway。
• 存取 AWS 服務：存取的是 S3 或 DynamoDB，而且只從 VPC 內部存取時，使用免費的 gateway endpoint；地端也要存取，或要存取其他服務時，使用具有私有 IP 的 interface endpoint。
• 連線失敗、要找原因：開啟 VPC Flow Logs，查看 action 欄位。連入的流量被拒絕，原因在 Security Group 或 NACL 的 inbound 規則；連入被允許、回應卻被拒絕，原因在 NACL 的 outbound 規則。

🧠 AI 出題

問題 1

某影像分析公司在一個 VPC 的 private subnet 執行 40 台 EC2，每天把約 8 TB 的處理結果上傳到同一個 Region 的 Amazon S3 bucket。帳單顯示 NAT gateway 的資料處理費用已經超過這些 EC2 本身的費用。這些 EC2 偶爾仍需要連到網際網路下載套件更新，所以 NAT gateway 會保留。

哪一個方案最符合成本效益（MOST cost-effective）？

• A. 為 S3 建立 interface endpoint 並啟用 private DNS，讓 EC2 透過 subnet 內的網路介面上傳到 S3
• B. 把 NAT gateway 換成每個 AZ 一台的 NAT instance，以 c6g.large 執行並停用 source/destination check
• C. 為 bucket 啟用 S3 Transfer Acceleration，並把 EC2 上傳程式改用 Transfer Acceleration 的端點名稱
• D. 為 S3 建立 gateway endpoint，並在 private subnet 的 route table 加入以這個 endpoint 為目標的路由

問題 2

某公司以 AWS Organizations 管理 14 個帳號，每個帳號各有一個 VPC，各 VPC 的 CIDR 已事先錯開，地端資料中心以 Direct Connect 連到 AWS。開發環境的 6 個 VPC 與正式環境的 7 個 VPC 之間不得互通，但兩組都必須能連到共用服務 VPC 與地端。網路團隊只有兩個人，之後每季還會新增帳號。

哪一個方案的維運負擔最低（LEAST operational overhead）？

• A. 在所有需要互通的 VPC 之間各建立一條 VPC Peering，並在每個 VPC 的 route table 加入對方 CIDR 的路由
• B. 在網路帳號建立 Transit Gateway 並以 AWS RAM 共用，為開發與正式環境各建立一個 Transit Gateway route table
• C. 在網路帳號建立 Transit Gateway 並以 AWS RAM 共用，所有 attachment 共用一個 route table，再以 Security Group 阻擋跨環境流量
• D. 讓每個 VPC 與共用服務 VPC 建立 VPC Peering，並經由共用服務 VPC 的 virtual private gateway 連到地端

問題 3

某公司在自己 VPC 內的 EC2 上執行一套付款驗證 API。數十家企業客戶要求從各自的 VPC 以私有連線呼叫這個 API，流量不得經過網際網路。其中多家客戶的 VPC 使用 10.0.0.0/16，與公司的 VPC 網段重疊。公司的資安政策另外規定，客戶只能存取這個 API，不能連到公司 VPC 內的其他資源。

哪一個方案最符合這些需求？

• A. 把 API 放在 Network Load Balancer 後方並建立 endpoint service，由客戶在自己的 VPC 建立 interface endpoint
• B. 與每家客戶的 VPC 建立 VPC Peering，並把 API 所在 subnet 的 NACL 設為只允許客戶 CIDR 連入 443 port
• C. 建立 Transit Gateway 讓各家客戶以 attachment 接入，並為每家客戶各建立一個獨立的 Transit Gateway route table
• D. 把 API 放在 internet-facing ALB 後方並套用 AWS WAF，只允許各家客戶 NAT gateway 的公開 IP 連入

問題 4

某公司在 private subnet 的 EC2 上執行內部 API，地端網路 192.168.0.0/16 經由 Transit Gateway 呼叫它的 TCP 443 port。上線後，地端的呼叫全部逾時。這個 subnet 使用自訂的 NACL。架構師開啟 VPC Flow Logs 後看到兩種記錄：從 192.168.10.20 連到 EC2 443 port 的流量是 ACCEPT；EC2 從 443 port 送回 192.168.10.20 的 49152 port 的流量是 REJECT。

以最少的設定變更恢復連線，解決方案架構師應該怎麼做？

• A. 在 EC2 的 Security Group 加入 outbound 規則，允許送往 192.168.0.0/16 的 TCP 1024–65535
• B. 在 EC2 的 Security Group 加入 inbound 規則，允許來自 192.168.0.0/16 的 TCP 443 連線
• C. 在 subnet 的 NACL 加入 outbound 規則，允許送往 192.168.0.0/16 的 TCP 1024–65535
• D. 在 subnet 的 NACL 加入 inbound 規則，允許來自 192.168.0.0/16 的 TCP 1024–65535

問題 5

某公司的地端資料中心以 Direct Connect private VIF 連到一個 VPC，地端的批次伺服器每晚要把報表上傳到同一個 Region 的 S3 bucket。資安政策規定，上傳流量不得經過網際網路；而且這個 bucket 只能接受經由公司私有網路送來的請求，即使有人取得有效的存取金鑰，也不能從網際網路存取 bucket。

哪兩個步驟組合起來最安全（MOST secure）？（選擇兩項）

• A. 在 VPC 建立 S3 gateway endpoint，並在地端路由器加入經由 Direct Connect 送往 S3 prefix list 的路由
• B. 在 VPC 建立 S3 interface endpoint，並讓地端伺服器改用這個 endpoint 專屬的 DNS 名稱連到 S3
• C. 在 bucket policy 加入 Deny 陳述，以 aws:SourceIp 條件拒絕來源不在地端私有 IP 範圍的請求
• D. 在 bucket policy 加入 Deny 陳述，以 aws:SourceVpce 條件拒絕不是經由這個 interface endpoint 的請求
• E. 在 interface endpoint 附加 endpoint policy，只允許透過這個 endpoint 對這個 bucket 執行 s3:PutObject

💡 解答

1. D

S3 gateway endpoint 不收費：在 private subnet 的 route table 加入指向 endpoint 的路由後，往 S3 的流量直接經 endpoint 傳送，不再經過 NAT gateway，NAT gateway 的資料處理費就消失了。其他網際網路流量仍照常走 NAT gateway。

A 同樣能讓流量避開 NAT gateway，但 interface endpoint 按小時並依處理的資料量收費，每天 8 TB 會產生持續的費用；它的優勢是地端或其他 VPC 也能使用，這個情境用不到。B 能省掉 NAT gateway 的處理費，但改成自己維護 NAT instance 的可用性與修補，流量也仍然經過轉送主機。C 的 Transfer Acceleration 是讓遠距離上傳經邊緣節點加速，EC2 和 bucket 在同一個 Region，用不到加速，而且要額外付加速費用，NAT gateway 的費用也沒有減少。

2. B

Transit Gateway 讓每個 VPC 只需要一個 attachment。開發與正式環境的 attachment 各自關聯不同的 Transit Gateway route table，兩張表都有共用服務 VPC 與 Direct Connect 的路由，彼此之間卻沒有，兩組因此互不相通，但都能連到共用服務與地端。Transit Gateway 建在網路帳號、以 AWS RAM 共用，新增帳號時只要建立 attachment、關聯到對應的 route table。

A 的 peering 數量會隨 VPC 增加而快速成長，而且 peering 不能轉送，各 VPC 也無法透過它連到地端。C 能連通，但隔離改靠十幾個 VPC 的 Security Group 規則維持，每新增一個帳號都要回頭修改，維運負擔輸給用 route table 分組。D 的錯誤在於 peering 不能轉送：其他 VPC 無法經由共用服務 VPC 的 virtual private gateway 連到地端。

3. A

PrivateLink 只開放提供方指定的那一個服務：API 放在 NLB 後方建立 endpoint service，客戶在自己的 VPC 建立 interface endpoint，以自己 VPC 內的私有 IP 呼叫 API。兩邊的 VPC 不互通、不需要路由，所以網段重疊不影響，客戶也碰不到 API 以外的資源。

B 的 VPC Peering 在 CIDR 重疊時無法建立。C 的 Transit Gateway 同樣靠路由轉送，重疊的網段無法正確路由，而且它連接的是整個網路，不是只開放一個服務。D 的 WAF 能限制來源，但流量走網際網路，違反私有連線的要求。

4. C

Flow Logs 顯示連入的請求被允許、回應被拒絕。Security Group 有狀態，允許的連入流量，其回應會自動放行；NACL 無狀態，回應要另外符合 outbound 規則。回應送往地端的 49152 port 屬於 ephemeral port，所以要在 NACL 加入允許送往 1024–65535 的 outbound 規則。

A 是把 NACL 的處理方式套到 Security Group：Security Group 不會擋已允許連線的回應，加 outbound 規則不會改變結果。B 的 inbound 443 已經是 ACCEPT，問題不在這裡。D 方向錯了，被拒絕的是 EC2 送出的回應，不是連入的流量。

5. B、D

Gateway endpoint 只對套用該 route table 的 subnet 有效，地端經 Direct Connect 進來的流量用不到它；interface endpoint 有私有 IP，地端可以經由 Direct Connect 連到它，用 endpoint 專屬的 DNS 名稱就會解析到這個私有 IP（B）。再在 bucket policy 以 aws:SourceVpce 拒絕不是經由這個 endpoint 的請求（D），即使存取金鑰外洩，從網際網路送來的請求也會被拒絕。

A 是 gateway endpoint 的常見誤解：它沒有 IP，地端的路由無法指向它。C 看似限制了來源，但經由 VPC endpoint 送到 S3 的請求，aws:SourceIp 比對不到私有 IP，這條規則會把合法的請求也一起擋掉；要限制來源 endpoint，用的是 aws:SourceVpce。E 的 endpoint policy 限制的是「透過這個 endpoint 能做什麼」，不會阻止別人從網際網路直接存取 bucket，少了 bucket 這一側的限制。