AWS PrivateLink 與 VPC Endpoint 架構

什麼是 AWS PrivateLink？SAP-C02 為何重視它？

AWS PrivateLink 是 AWS 的核心技術，能在不透過路由、不建立 VPC 對等連線、不暴露整段 CIDR 的前提下，將單一服務跨越 VPC 邊界對外提供。在 SAP-C02 的層次，AWS PrivateLink 並非 Amazon VPC 網路功能的可選附加項目，而是整個 Professional 等級情境家族的標準答案：被購併公司之間的重疊 CIDR、向數百個客戶 VPC 銷售私有服務的 SaaS 廠商、絕對不能碰觸公共網際網路的 AWS Marketplace 整合、從私有子網路最小權限存取 AWS 服務 API，以及傳統「每個 VPC 對等連線到每個 VPC」模型因自身重量而崩潰的跨帳號架構。

SAP-C02 考試指南將 AWS PrivateLink 列入 Domain 2（設計新方案，29%）與 Domain 4（持續改善現有方案，25%），是少數幾乎出現在每份 SAP-C02 考卷中的網路服務之一。只把 AWS PrivateLink 理解為「S3 的 Interface VPC Endpoint」的考生，將錯失大多數可得分數。Professional 等級考試要求你區分生產端（VPC Endpoint Service）與消費端（Interface VPC Endpoint），在 CIDR 重疊導致路由不可行時選擇 AWS PrivateLink 而非 VPC 對等連線或 Transit Gateway，設計與 IAM resource policies 不同性質的 Endpoint Policies，並將 Private DNS、Route 53 aliases 和 security group 規則整合為一致的部署架構。

本學習主題以 SAP-C02 要求的深度，端對端解說 AWS PrivateLink：兩種 VPC Endpoint（Gateway 與 Interface）、生產端在 Network Load Balancer 後方發布的 Endpoint Service、跨帳號與跨區域運作機制、AWS Marketplace 整合，以及告訴你何時 AWS PrivateLink 勝過 VPC 對等連線、何時 Transit Gateway 是更好的集線器的關鍵決策框架。本文假設你已熟悉 Amazon VPC 基礎知識；若子網路、路由表或 NAT Gateway 仍有疑問，請先複習那些主題再回來學習 AWS PrivateLink。

白話文解釋

在深入 AWS PrivateLink 機制之前，三個類比能讓整個服務瞬間清晰。Professional 等級考試獎勵能夠在這些心智模型與技術名稱之間自由切換的考生。

類比一：大樓專用電梯間

想像一棟 40 層的辦公大樓，每一層都是不同公司擁有的獨立 Amazon VPC。傳統 VPC 對等連線就像在兩層樓之間鑽一條私人走廊：兩層的任何人都能走進對方的任何辦公室。對兩個友善的租戶來說也許還行，但這根本無法擴展，而且一旦兩層樓恰好使用相同的辦公室編號（都用 201–220 號——即 CIDR 重疊），就完全行不通了。AWS PrivateLink 是大樓專屬的服務電梯系統：每個租戶只向系統登記一項服務（例如「17 樓的法律審閱服務」）。9 樓的人需要法律審閱時，走到自己樓層的服務電梯入口，按下專屬按鈕，直達那個服務，從不踏入 17 樓的走廊，也看不到任何房間號碼，更不會與自己 9 樓的號碼衝突。電梯系統在背後完成所有轉換。這正是 AWS PrivateLink 透過 Interface VPC Endpoint 的運作方式：它在消費端 VPC 內建立一個本地 ENI，透過 AWS 骨幹將單一服務的流量路由到生產端，完全無視 CIDR 衝突。

類比二：銀行金庫專屬通道（Endpoint Service vs Interface Endpoint）

想像一棟複合式大樓，每個企業客戶辦公室是消費端 VPC，地下室的中央金庫是生產端 VPC。金庫管理方發布一份專屬服務申請表——那張申請表就是 VPC Endpoint Service。客戶撥打辦公室內的金庫直線電話——那支電話就是 Interface VPC Endpoint。大樓內部的專屬通訊系統把來自 412 室的電話（消費端子網路內的 ENI）透過金庫的單一受理櫃台（Network Load Balancer）轉接給值班人員（NLB 後方的 EC2 或容器目標）。客戶永遠不需要知道金庫的平面圖，也看不到個別人員的分機號碼，更無法直接走進金庫。金庫端則能夠接受或拒絕特定辦公室的請求（endpoint connection acceptance）、設定費率，或隨時撤銷存取權限。這就是 AWS PrivateLink 與 VPC 對等連線的生產端/消費端不對稱性——對等連線是對稱的，兩端互相完整可見。

類比三：外交使館的簽證窗口（重疊 CIDR 的解法）

想像兩個國家，歷史上都把國民編號為 1 到 1,000,000，編號系統完全重疊——雙方各有一百萬個「42 號公民」。在兩國記錄系統之間建立傳統 VPN 毫無意義，因為「42 號公民」根本無法辨別。於是，每個國家在對方首都開設簽證申辦窗口：一個本地地址、本地窗口，專門處理單一業務（簽證申請）。公民走到本地窗口，窗口透過專屬外交通道轉送請求並帶回回應。兩國的國民資料庫從不對等連線、從不交換 ID 編號、從不發生衝突。AWS PrivateLink 就是 AWS 網路的簽證窗口：當兩個 VPC 有重疊的 10.0.0.0/16 範圍（企業購併後的經典難題），你無法建立對等連線，也無法透過 Transit Gateway 路由——除非為每個 IP 設置昂貴的 1:1 NAT。但你可以把其中一個 VPC 的服務發布為 PrivateLink Endpoint Service，讓另一個 VPC 透過帶有全新本地 ENI IP 的 Interface Endpoint 來使用，重疊問題就此無關緊要。這是 SAP-C02 前三名的考試模式，值得熟記在心。

有了大樓服務電梯、銀行金庫專屬通道與外交使館簽證窗口這三個類比，AWS PrivateLink 的每個元件與陷阱都變得更容易對應到實際架構。

AWS PrivateLink 核心模型：生產端、消費端與中間的 Load Balancer

AWS PrivateLink 在 Amazon VPC 之上正式化了生產端/消費端服務模型。與 VPC 對等連線（對稱）或 Transit Gateway（集線器輻射式路由器）不同，AWS PrivateLink 刻意設計為不對稱且限定服務範圍。

生產端：VPC Endpoint Service

生產端是擁有你想對外提供服務的 VPC。生產端需要建立：

1. 自己 VPC 中的一個 Network Load Balancer (NLB)，其目標群組指向執行實際服務的 EC2 執行個體、容器或 IP 目標。自 2023 年起，Gateway Load Balancer (GWLB) 也可作為安全設備鏈的 Endpoint Service 前端——適用於 SAP-C02 場景中的內嵌式防火牆稽核。
2. 附加到該 NLB 的 VPC Endpoint Service 設定，取得格式為 com.amazonaws.vpce.<region>.vpce-svc-<hash> 的唯一服務名稱。
3. 允許連線的 AWS principals 白名單（帳號 ID、IAM role 或使用者）。
4. 可選的接受設定（自動接受或手動接受）。手動接受表示每個新的消費端連線都需要生產端審核批准——常見於 SaaS 與 Marketplace 模式。
5. 可選的Private DNS 名稱設定，透過在公共 DNS 放置 TXT 記錄以驗證網域所有權，讓消費端能使用如 api.example-saas.com 的自訂網域，而非冗長的 vpce-... DNS 名稱。

消費端：Interface VPC Endpoint

消費端是任何想要連接生產端服務的 VPC（相同帳號或跨帳號，自 2024 年起也可跨區域）。消費端建立一個 Interface VPC Endpoint，它會：

1. 在選定子網路內，每個 Availability Zone 各產生一個 Elastic Network Interface (ENI)，每個 ENI 都有一個來自消費端 VPC CIDR 的私有 IP。
2. 為這些 ENI 附加 security group，控制消費端 VPC 中的哪些資源可以到達該 Endpoint。
3. 可選地附加 Endpoint Policy（resource-based IAM policy），進一步限制 Endpoint 會轉送給服務的操作。
4. 可選地登記 Private DNS 名稱，在消費端 VPC 內覆蓋服務的公共 DNS——讓使用 s3.us-east-1.amazonaws.com 的現有用戶端程式碼，能夠在不修改的情況下透明地透過 Endpoint 路由。

流量路徑

當消費端 EC2 執行個體呼叫服務時：

1. DNS 將服務名稱解析為 Interface Endpoint 的 ENI 私有 IP（透過 Private DNS 或明確的 alias）。
2. 流量進入消費端 VPC 內的 ENI——從不透過 Internet Gateway、NAT Gateway 或 Transit Gateway 離開消費端 VPC。
3. AWS PrivateLink 透過 AWS 骨幹將 TCP 串流轉發到生產端的 NLB。
4. NLB 將請求分配給健康的目標。
5. 回應沿相同的私有路徑返回。

流量在整個過程中從不經過公共網際網路，兩端 VPC 從不看到彼此的 CIDR，路由也從不需要調和。這就是 AWS PrivateLink 的根本超能力。

VPC Endpoints：Gateway vs Interface

AWS PrivateLink 是 Interface VPC Endpoints 背後的技術，但 Amazon VPC 還提供第二種更早期的類型——Gateway VPC Endpoints。SAP-C02 要求你清楚區分兩者，因為它們在計費、實作與功能上有完全不同的特性。

Gateway VPC Endpoints

Gateway Endpoints 是舊有設計，目前僅適用於兩項 AWS 服務：Amazon S3 與 Amazon DynamoDB。其實作方式使用路由表前綴清單條目（例如 us-east-1 中 S3 對應的 pl-63a5400a）。當子網路的路由表包含指向 Gateway Endpoint 的前綴清單時，來自該子網路的 S3 或 DynamoDB 流量會靜默地透過 AWS PrivateLink 的前身機制路由，而非經由 Internet Gateway 離開。

Gateway Endpoint 對 SAP-C02 重要的特性：

• 無每小時費用、無每 GB 費用——完全免費。
• 區域範圍——無法跨區域使用 Gateway Endpoint。
• 路由表相依性——每個需要 Endpoint 存取的子網路都必須更新其路由表。
• 無 ENI、無私有 IP——不消耗 CIDR 空間。
• 不支援跨 VPC、跨帳號或本地端使用——Gateway Endpoint 只能從其所屬的 VPC 使用；透過 Direct Connect 或 VPN 的本地端流量無法到達 Gateway Endpoint。
• 支援 Endpoint Policies——可限制 Endpoint 允許的 S3 儲存桶或 DynamoDB 資料表。

Interface VPC Endpoints（由 AWS PrivateLink 驅動）

Interface Endpoints 適用於幾乎所有 AWS 服務（寫作當時已有數百項），加上客戶發布的服務與 AWS Marketplace 服務。其實作方式是在你子網路中每個 AZ 部署一個帶有私有 IP 的 ENI——IP 來自你的 VPC CIDR。

Interface Endpoint 對 SAP-C02 重要的特性：

• 每個 AZ 每個 Endpoint 收取每小時費用，另加每 GB 資料處理費用——大規模使用時費用不容忽視。
• 支援跨 VPC、跨帳號，以及（自 2024 年起）跨區域。
• 可從本地端透過 Direct Connect 或 Site-to-Site VPN 存取——這是非常重要的 SAP-C02 模式（混合式架構存取 AWS API，不須走公共網際網路）。
• Private DNS 整合——可在 VPC 內覆蓋 AWS 服務的公共 DNS 主機名稱。
• Security Group 強制執行——為 Endpoint ENI 附加 SG 以控管流量。
• 支援 Endpoint Policies——限制操作、資源或 principals。

快速決策規則

• 僅在 VPC 內存取 S3、對成本敏感、不需要本地端存取 → Gateway Endpoint（免費）。
• 從本地端透過 Direct Connect 存取 S3，或從不同 VPC/帳號存取 → Interface Endpoint（付費，但可到達）。
• 僅在 VPC 內使用 DynamoDB → Gateway Endpoint（免費）。
• 任何其他 AWS 服務（KMS、SSM、Secrets Manager、SNS、SQS、STS、ECR、EKS……） → Interface Endpoint（無 Gateway 替代方案）。

AWS PrivateLink 解決重疊 CIDR：SAP-C02 的標誌性考試模式

如果你從整個主題只能帶一個模式進考場，就帶這個：AWS PrivateLink 是解決 VPC 間重疊 CIDR 的標準答案。SAP-C02 非常喜歡這個情境，因為它直接對應現實世界的企業購併整合——兩家公司都在內部使用 10.0.0.0/16 且無法建立對等連線。

為何對等連線和 Transit Gateway 在重疊時失敗

VPC 對等連線要求兩個 VPC 的 CIDR 不得重疊，沒有例外。若 A 公司的 VPC 是 10.0.0.0/16，B 公司的 VPC 也是 10.0.0.0/16，對等連線請求在建立時就會被拒絕。Transit Gateway 稍微靈活——它可以在獨立的路由表中保存重疊的附接——但個別的來源/目標配對仍然無法共享同一個 IP。你必須插入 1:1 NAT（通常是自管的 NAT 執行個體或帶有改寫規則的 Network Firewall），把每個執行個體的 IP 轉換為不重疊的範圍。這種做法昂貴、脆弱，且每新增一項服務都需要重新工程。

AWS PrivateLink 為何能繞過重疊問題

AWS PrivateLink 不在 VPC 之間路由封包。它在消費端 VPC 的 ENI 處終止連線，然後從生產端向 NLB 發起新連線。從消費端的角度來看，它是在與自己 VPC 內的本地 IP 通訊。從生產端的角度來看，連線來自 NLB——NLB 看到的是 PrivateLink 指派的來源位址，而非消費端的真實 IP。兩個 VPC 的 CIDR 從不被比較、從不一起路由，也不需要是不重疊的。

這使 AWS PrivateLink 成為一個完全受管、可水平擴展、限定服務範圍的 1:1 NAT 替代方案。你支付 Interface Endpoint 的每小時 + 每 GB 費率，並跳過整個 NAT 執行個體的營運負擔。

何時 PrivateLink 是重疊問題的正確答案

• 購併後 VPC 整合：A 公司購併 B 公司；雙方都使用 10.0.0.0/16；A 公司需要將少數內部服務開放給 B 公司，不須重新規劃任何一方的 IP。
• 多租戶 SaaS：你在 AWS 上執行 SaaS；你的客戶各自帶來擁有隨機 CIDR 的 VPC，許多與你的重疊；你向所有人開放一項 API 服務。
• 共用企業服務：「共用服務」中心 VPC 提供可觀測性、CI/CD 或目錄服務給數十個工作負載 VPC，其中幾個互相重疊——PrivateLink 讓任何工作負載 VPC 都能使用共用服務，無論其鄰居是否重疊。

何時 PrivateLink 不是正確答案

• 你需要雙向、通用的 VPC 連線（多項服務、任意協定、雙向）→ 使用對等連線（若無重疊）或 Transit Gateway（附接不重疊時）。
• 你需要廣播或多播路由 → AWS PrivateLink 僅支援 TCP/UDP 單播。
• 你需要 IPv6 → AWS PrivateLink 對部分服務支援 IPv6，但覆蓋率不完整；請按服務確認。

Endpoint Policies：AWS PrivateLink 上的 Resource-Based 控制

Endpoint Policy 是附加到 VPC Endpoint 的 JSON 文件，進一步限制 Endpoint 允許的操作。它是一種 resource-based IAM policy，與呼叫 principal 的 IAM policy 取交集——有效權限是（principal 的 IAM）、（Endpoint Policy）與（目標服務的 resource policy，若存在）的交集。

Endpoint Policy 語法

語法與標準 IAM 相同，但設定在 Endpoint 上：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": [
        "arn:aws:s3:::examlab-prod-logs/*",
        "arn:aws:s3:::examlab-prod-logs"
      ]
    }
  ]
}

這份 Policy 表示：「只有對 examlab-prod-logs 儲存桶的 S3 GetObject 和 PutObject 才能透過此 Endpoint 執行。」即使呼叫者的 IAM role 允許對任何儲存桶執行 s3:*，Endpoint Policy 也會將 Endpoint 限縮為只對一個儲存桶的兩項操作。

為何 Endpoint Policies 在 SAP-C02 等級非常重要

1. 防止資料外洩。若沒有 Endpoint Policy，具有廣泛 IAM 權限的 EC2 執行個體可能透過 S3 Gateway Endpoint 將企業資料上傳到任何 AWS 帳號的任何 S3 儲存桶。將儲存桶 ARN 限縮在你自己組織帳號 ID 範圍內的 Endpoint Policy，在網路層封鎖了外洩路徑。
2. 最小權限組合。將 Endpoint Policy（每個 VPC）與 IAM policies（每個 role）以及 bucket policies（每個資源）結合，實現縱深防禦。
3. 合規證據。稽核人員喜愛 Endpoint Policies，因為它以單一文件呈現「此 VPC 向此服務可以傳出什麼」。

預設 Endpoint Policy

建立新的 Interface Endpoint 時，預設 Endpoint Policy 是 "Effect": "Allow", "Action": "*", "Resource": "*"——授予完整存取。若你依賴 Endpoint Policies 作為安全控制，必須明確替換預設值。忘記這一點是 SAP-C02 外洩防護問題中的常見陷阱。

Endpoint Policy vs IAM Policy

常見混淆：Endpoint Policies 本身不授予權限。它們是過濾器。若呼叫者的 IAM policy 未授予 s3:GetObject，無論 Endpoint Policy 中有多少 Allow，呼叫都不會成功。Endpoint Policies 相對於 IAM 永遠是削減性的——只能進一步限縮，從不擴展。

DNS 整合：Private DNS、Route 53 與 Per-Endpoint Aliases

AWS PrivateLink 的 DNS 設計出乎意料地微妙，SAP-C02 會定期考察它。三個層次很重要：AWS 服務的 Private DNS、客戶服務的自訂 Private DNS 名稱，以及針對 Endpoint 特定主機名稱的 Route 53 alias records。

AWS 服務 Interface Endpoints 的 Private DNS

當你為 AWS 服務（例如 com.amazonaws.us-east-1.secretsmanager）建立 Interface Endpoint 並勾選 Enable DNS name 選項時，AWS 會在你的 VPC 內建立 Route 53 Private Hosted Zone，覆蓋服務的公共 DNS。此後，從 VPC 內部對 secretsmanager.us-east-1.amazonaws.com 的呼叫會解析為 Endpoint 的私有 ENI IP，不需修改任何應用程式程式碼。這是「我們的應用程式程式碼已存在，不想重寫 Endpoint URL」的最簡單路徑。

Private DNS 覆蓋的前提條件：

• VPC 必須將 enableDnsSupport 和 enableDnsHostnames 設為 true。
• AWS 服務的 Endpoint 必須支援 Private DNS（大多數都支援；請按服務確認）。
• 每個 VPC 中每項服務只能有一個 Endpoint 啟用 Private DNS（否則重複的 zone 會發生衝突）。

客戶發布（AWS PrivateLink）服務的 Private DNS

發布 VPC Endpoint Service 的生產端可以設定像 api.example-saas.com 的 Private DNS 名稱。在 AWS 接受該 DNS 名稱之前，生產端必須透過在網域的公共 DNS 放置 TXT 記錄來驗證網域所有權。驗證完成後，啟用了 Interface Endpoint 上 Private DNS 的消費端 VPC，會自動將 api.example-saas.com 解析為消費端 VPC 內 Endpoint ENI 的 IP。

這正是將 AWS PrivateLink 變成 SaaS API 即插即用替代方案的機制——消費端現有程式碼呼叫 https://api.example-saas.com/v1/... 依然有效，但流量現在透過 AWS PrivateLink 而非公共網際網路傳輸。

Per-Endpoint Route 53 Alias Records

每個 Interface Endpoint 也會暴露每個 Endpoint 的區域 DNS 名稱，例如：

• vpce-0abc123-xyz.secretsmanager.us-east-1.vpce.amazonaws.com（區域性，跨所有 AZ 本地 ENI 負載平衡）
• vpce-0abc123-xyz-<az>.secretsmanager.us-east-1.vpce.amazonaws.com（可用區域性，固定到特定 AZ）

無論是否啟用 Private DNS，這些名稱始終可用。你可以：

• 從你的自訂名稱（internal-secrets.examlab.internal）建立 Route 53 Alias，指向 Endpoint 的區域名稱，實現人性化解析。
• 使用可用區域性名稱讓流量保持在同一 AZ 內（減少跨 AZ 資料傳輸費用——SAP-C02 微妙的成本最佳化技巧）。
• 將區域 alias 與 health checks 結合，在多區域設計中繞過失敗的 Endpoint。

Private DNS 與從本地端透過 Route 53 Resolver 轉發

常見的 SAP-C02 情境：本地端應用程式需要透過 Interface Endpoint 私下呼叫 AWS 服務。路徑如下：

1. 本地端 → Direct Connect / VPN → 到達 VPC。
2. 本地端 DNS 解析器將 *.amazonaws.com 查詢轉發給 VPC 中 Route 53 Resolver Inbound Endpoint。
3. Inbound Endpoint 使用 VPC 的 Private DNS 解析查詢 → 回傳 Interface Endpoint ENI 的私有 IP。
4. 本地端流量隨後透過 Direct Connect 流向該私有 IP，進入 Interface Endpoint，並透過 PrivateLink 到達 AWS 服務。

若沒有 Route 53 Resolver Inbound Endpoint，本地端 DNS 會回傳 AWS 服務的公共 IP，流量就繞過了你的 Interface Endpoint。這是「為何我本地端的呼叫沒有走 Endpoint？」這類高頻考試陷阱的根因。

Interface Endpoints 上的 Security Group 規則：常被遺忘的控制

每個 Interface Endpoint ENI 都附有一個 security group。這個 SG 控制消費端 VPC 內允許到達 Endpoint ENI 的流量。

預設行為

預設情況下，新的 Interface Endpoint 附加到 VPC 的預設 security group，它允許與預設 SG 共享的資源的所有傳入流量——對生產環境來說這是過於寬鬆的設定。最佳做法：

1. 建立專屬 Endpoint SG（例如 sg-vpce-secretsmanager）。
2. 僅允許來自特定來源 SG（你的應用程式層 SG）的 TCP 443 傳入，而非整個 VPC CIDR。
3. 在建立 Endpoint 時附加該專屬 SG。

這確保只有被授權的工作負載才能嘗試連線到 Endpoint。結合 Endpoint Policy（可以呼叫什麼）與 IAM（誰可以呼叫），你獲得三層防禦。

Security Group 的狀態感知語意同樣適用

由於 Interface Endpoints 使用 ENI，它們繼承了標準 Security Group 的狀態感知行為：允許 443 傳入，回應流量自動允許傳出。不需要 NACL 式的回程路徑規則。

跨 AZ 流量與 Security Group 成本影響

若你 AZ-a 的應用程式 EC2 連接到 AZ-b 的 Endpoint ENI，流量跨越 AZ 並在 Endpoint 每 GB 費用之上產生跨 AZ 資料傳輸費用。對高流量場景，可採取：

• 使用可用區域性 DNS 名稱（vpce-...-<az>...）強制同 AZ 解析。
• 或在每個存在消費端工作負載的 AZ 都部署 Endpoint，讓區域 DNS 名稱的 AZ 親和性雜湊流量。

跨區域與跨帳號的 AWS PrivateLink

跨帳號 Endpoints

跨帳號是最常見的情況：生產端帳號發布 Endpoint Service，其他 AWS 帳號的消費端建立指向該服務名稱的 Interface Endpoints。生產端透過 Endpoint Service 上的允許 principals 清單控制存取；消費端透過其 Endpoint Policy 和 security group 控制存取。任何一方都可以單方面撤銷存取——生產端移除消費端的 principal ARN，或消費端刪除 Endpoint。

跨帳號 AWS PrivateLink 是以下架構的基礎：

• AWS Marketplace SaaS：廠商發布 Endpoint Services；買家訂閱並獲得 Endpoint 連線權利。
• 企業共用服務：一個「平台團隊」帳號發布可觀測性、CI/CD 或安全服務；工作負載帳號透過 Interface Endpoint 使用它們，不需要全面開放的跨帳號 IAM。
• AWS Organizations 模式：中央安全帳號開放 SOAR 或 SIEM 介面；每個工作負載帳號透過 Interface Endpoint 連線，不需要廣泛的跨帳號 IAM。

跨區域 Endpoint 連線

在 2024 年之前，AWS PrivateLink 嚴格限制在同一 AWS Region——消費端和生產端必須在同一個 AWS Region。2024 年發布的跨區域 Endpoint 連線改變了這一點：位於 us-east-1 的消費端現在可以建立指向 eu-west-1 中 Endpoint Service 的 Interface Endpoint。AWS 透過 AWS 骨幹處理跨區域傳輸，並按跨區域 PrivateLink 費率計費。

SAP-C02 的關鍵事實：

• 跨區域是每個 Endpoint Service 各自選擇加入（生產端啟用「允許跨區域 Endpoints」並指定允許的區域）。
• Private DNS 不會自動延伸到跨區域——消費端使用區域 Endpoint DNS 名稱。
• 跨區域 AWS PrivateLink 與 Transit Gateway 跨區域對等連線競爭：PrivateLink 的服務範圍更窄，對低流量的單一服務更划算；Transit Gateway 更廣泛但建置成本更高。
• 並非每項 AWS 服務都支援跨區域 Interface Endpoints；客戶發布的 Endpoint Services 則支援。

跨區域使用情境

• 擁有單一控制平面的多區域 SaaS：控制平面在一個區域；其他區域的資料平面消費端透過跨區域 PrivateLink 呼叫控制平面。
• PrivateLink 消費服務的災難復原：消費端可以將其 Endpoint 容錯移轉到 DR 區域的 Endpoint Service，無需重新架構應用程式。
• 資料主權：主權區域的生產端對跨區域消費端開放唯讀 API，同時將靜態資料保留在主權區域。

AWS Marketplace 與透過 AWS PrivateLink 的 SaaS 服務交付

AWS Marketplace 與 AWS PrivateLink 緊密整合，用於私有 SaaS 服務交付。當 Marketplace 賣家發布由 VPC Endpoint Service 支援的服務時，買家可以訂閱並透過 AWS Marketplace 的佈建流程獲得自動建立 Endpoint 的權利。

Marketplace 流程

1. 賣家在自己的 VPC 中建立 SaaS 產品，由 NLB 前端。
2. 賣家發布 VPC Endpoint Service，對已核准的 Marketplace 買家停用手動接受，或透過 Marketplace 授權檢查進行自動接受。
3. 買家在 AWS Marketplace 發現該產品並訂閱。
4. Marketplace 將買家的 AWS 帳號 ID 傳遞給賣家的允許 principals 清單。
5. 買家在其 VPC 中建立 Interface Endpoint，指向賣家的服務名稱。
6. Private DNS（若已設定）讓買家現有程式碼能以穩定的主機名稱透過 AWS PrivateLink 呼叫賣家的 API。

為何 Marketplace + PrivateLink 是最佳組合

• SaaS API 呼叫無需公共網際網路出口——對受管制產業而言是重大合規優勢。
• 無需針對每個客戶建立 VPC 對等連線——賣家不必追蹤每個客戶的 CIDR 並逐一對等連線。
• 計費與授權與 AWS Marketplace 綁定——賣家不必建立自訂授權層。
• 客戶生命週期自動化——訂閱取消後撤銷允許的 principal，在 AWS PrivateLink 層終止 Endpoint 連線。

在 SAP-C02 中，當情境提到 「AWS Marketplace 中的第三方 SaaS 廠商」 加上 「私有連線」 或 「無網際網路出口」 時，答案涉及 AWS PrivateLink 支援的 Marketplace Endpoint Services。

NLB 作為 Endpoint Service 的前端服務

AWS PrivateLink 要求生產端以 Network Load Balancer (NLB) 或（對安全設備鏈而言）Gateway Load Balancer (GWLB) 作為服務前端。不支援其他類型的 Load Balancer 作為 Endpoint Service 目標。

為何是 NLB 而非 ALB

• NLB 在 Layer 4 運作（TCP/UDP/TLS），這正是 PrivateLink 終止的層次。
• NLB 保留來源 IP（對 IP 保留的目標群組），讓生產端在需要時能看到消費端來源。
• NLB 可擴展至數百萬個連線，無需預熱，符合 PrivateLink 的規模預期。
• NLB 支援跨可用區域負載平衡（可選，伴隨跨 AZ 資料費用）。

ALB 是 Layer 7（HTTP/HTTPS），自 2023 年起你可以用 ALB 目標群組前置 NLB（NLB with ALB target 功能）以在後端使用 HTTP 功能——但面向 PrivateLink 的 Load Balancer 仍必須是 NLB。

多 AZ NLB 與 PrivateLink

Endpoint Service 後方的 NLB 應該是多 AZ以提供生產端高可用性。消費端的每個 Interface Endpoint 也是多 AZ（每個你啟用的 AZ 各一個 ENI）。若要完整的端對端 HA，請在兩端啟用相同的 AZ——若消費端啟用了 AZ-a 和 AZ-b，但 NLB 僅在 AZ-c，Endpoint 在 AZ-a/b 就會無法連線。

目標類型

• 執行個體目標（傳統 EC2 登錄）。
• IP 目標（用於 ECS/EKS Pod、透過 VPN/DX 的本地端伺服器，或任何 ENI）。
• ALB 目標（L4 NLB 後方的 L7 功能）。
• Lambda 目標不直接支援；若要透過 AWS PrivateLink 開放 Lambda，可以用 API Gateway VPC Link（其本身底層就是 AWS PrivateLink）前置，或讓函式在 ALB 目標群組後方執行。

AWS PrivateLink vs VPC 對等連線 vs Transit Gateway：Professional 等級的決策

SAP-C02 持續考察 AWS PrivateLink、VPC 對等連線與 Transit Gateway 三者之間的決策。正確答案取決於 CIDR 重疊、服務粒度、規模與成本。

決策矩陣

決策樹

1. 這是否為開放單一服務（或少量固定服務）的需求？ 是 → 傾向 AWS PrivateLink。
2. VPC 的 CIDR 是否重疊？ 是 → AWS PrivateLink（對等連線和 TGW 沒有 NAT 就無法使用）。
3. 少於約 5 個 VPC 需要完整雙向連線，且無重疊？ 是 → VPC 對等連線。
4. 5 個以上 VPC，或需要混合式（本地端）連線，且需要許多服務？ 是 → Transit Gateway。
5. 消費端群體未知或龐大（向眾多客戶提供 SaaS）？ → AWS PrivateLink（天然可水平擴展）。
6. 按服務交付收費？ → 透過 Marketplace 整合的 AWS PrivateLink。
7. 你需要三個以上 VPC 的傳遞性路由？ → Transit Gateway。

大規模的成本

AWS PrivateLink 的每小時 + 每 GB 模型，單一 Endpoint 看起來很小，但隨消費端數量線性增長。擁有 1,000 個客戶 Endpoint 的 SaaS，需支付 1,000 × 每小時費用 × AZ 數量。在這種規模下，Transit Gateway 共用服務模型在純成本上可能實際上優於 PrivateLink——但前提是 CIDR 約束允許。許多 SAP-C02 問題的關鍵就在這裡：若 CIDR 重疊或消費端群體確實是多租戶外部客戶，就支付 PrivateLink 的費用；這是唯一可行的設計。

常見誤解

• 「PrivateLink 只是更安全的對等連線」——錯。它的範圍限定在服務，是單向且不對稱的。
• 「Transit Gateway 可以取代 PrivateLink」——錯。TGW 需要不重疊的 CIDR；PrivateLink 不需要。
• 「PrivateLink 流量在傳輸中會自動加密」——AWS 骨幹上的流量並非強制在網路層加密；依賴應用程式層的 TLS 以確保保密性。

AWS PrivateLink 可觀測性與營運

Endpoint 上的 VPC Flow Logs

Interface Endpoint 的 ENI 會像其他任何 ENI 一樣產生 VPC Flow Logs。日誌行顯示消費端用戶端 IP 與 Endpoint ENI IP 之間的流量，並捕獲 Endpoint ID 作為中繼資料。Flow Logs 不會顯示遠端（生產端 VPC）的活動——這在設計上是不透明的，既是隱私功能，也是除錯的麻煩。

CloudWatch Metrics

AWS PrivateLink 按每個 Endpoint 發布 CloudWatch Metrics：

• PacketsDropped：封包被拒絕時遞增（常見原因：無允許的 principal，或 Endpoint Policy 拒絕）。
• ActiveConnections：目前並發連線數。
• BytesProcessed：資料傳輸量（驅動每 GB 計費）。
• RstPacketsReceived / RstPacketsSent：TCP 重置診斷。

生產端還能獲得 Endpoint Service Metrics，顯示每個消費端連線的 NewConnectionCount 和 BytesProcessed，讓 SaaS 計費和容量規劃能追蹤每個租戶的使用量。

Connection Acceptance 工作流程

啟用手動接受時，生產端的 CloudWatch Events 會在每個 PendingAcceptance 連線時觸發。典型的自動化流程如下：

1. EventBridge 規則捕獲 PendingAcceptance 事件。
2. Lambda 根據白名單驗證請求帳號 ID（例如 AWS Marketplace 授權檢查）。
3. Lambda 呼叫 AcceptVpcEndpointConnections 核准或 RejectVpcEndpointConnections 拒絕。
4. 稽核軌跡寫入 CloudTrail 以符合合規要求。

此模式是 SAP-C02 受控 SaaS 上線自動化設計的標準答案。

AWS PrivateLink 限制與需記住的配額

• 每個 VPC 的 Interface Endpoints 數量：50（軟性上限，可提高）。
• 每個帳號每個區域的 Endpoint Services 數量：20（軟性上限）。
• 每個 Endpoint Service 的允許 principals 數量：100（軟性上限）。
• 每個 Endpoint 的最大並發連線數：每個 AZ 55,000（軟性上限；可透過額外 Endpoints 擴展）。
• 閒置逾時：Interface Endpoint 為 350 秒；長期存活連線（資料庫、訊息佇列）需要在 350 秒以下的 TCP keepalives。
• PrivateLink 中無跨 VPC ICMP——僅支援 TCP（以及透過 NLB UDP 監聽器的 UDP）。
• 無多播、無廣播、部分服務不支援 IPv6——請按服務確認。
• Gateway Endpoints 僅限 S3 和 DynamoDB——請勿嘗試對其他服務使用 Gateway Endpoint。
• Endpoint Service 需要 NLB 或 GWLB——ALB 無法直接前端 VPC Endpoint Service。

SAP-C02 的典型 AWS PrivateLink 考題類型

1. 重疊情境：「兩個被購併的 VPC 都使用 10.0.0.0/16。將中央日誌服務從 VPC-A 開放給 VPC-B。最具營運效率的方式？」→ AWS PrivateLink（在 VPC-A 的 NLB 上設定 VPC Endpoint Service，在 VPC-B 中建立 Interface Endpoint）。
2. 外洩防護情境：「私有子網路中的 EC2 執行個體只能存取兩個核准的 S3 儲存桶。如何實現？」→ 帶有儲存桶範圍 Endpoint Policy 的 Gateway Endpoint（並收緊 IAM）。
3. 混合式存取：「本地端應用程式必須透過現有 Direct Connect 呼叫 Secrets Manager，不走公共網際網路。」→ Interface Endpoint + Route 53 Resolver Inbound Endpoint + 本地端 DNS 轉發。
4. SaaS 廠商：「第三方 Marketplace 廠商需要向 100 個客戶 VPC 開放 API，不走網際網路，CIDR 未知。」→ VPC Endpoint Service（PrivateLink）搭配 AWS Marketplace 整合。
5. 大規模成本情境：「1,500 個 VPC 都需要同一個共用服務；它們沒有重疊；成本最佳化為首要目標。」→ Transit Gateway 共用服務，而非 PrivateLink（規模使成本曲線翻轉）。
6. 跨區域：「主要服務在 eu-west-1；us-east-1 和 ap-southeast-1 的消費端只需要私下存取這一個 API。」→ 跨區域 PrivateLink，而非 TGW 跨區域對等連線。
7. DNS 陷阱：「Endpoint 上的 Private DNS 在 VPC 內的 EC2 可以使用，但本地端不行。」→ 缺少 Route 53 Resolver Inbound Endpoint。
8. NLB 唯一限制陷阱：「ALB 前端了服務；為何我無法建立 Endpoint Service？」→ Endpoint Service 需要 NLB 或 GWLB；在前方放置 NLB，或使用 ALB 作為 NLB 目標。
9. Endpoint Policy 預設值：「啟用 S3 Endpoint 後，仍然可以外洩資料到任意儲存桶——為何？」→ 預設 Endpoint Policy 是開放的；以儲存桶範圍的 Policy 替換。
10. 跨帳號上線自動化：「自動核准新客戶的 Endpoint 連線。」→ EventBridge + Lambda + AcceptVpcEndpointConnections API。

AWS PrivateLink vs API Gateway VPC Link：相關的重要區別

部分 SAP-C02 問題會將 AWS PrivateLink 與 API Gateway 的 VPC Link 功能混在一起。兩者的關係：

• API Gateway REST API 搭配 private VPC 整合，使用底層是 AWS PrivateLink 的 VPC Link 連接到你 VPC 中的 NLB。
• API Gateway HTTP API private 整合使用類似的 VPC Link 連接 ALB 或 NLB。
• API Gateway Private REST APIs 本身透過 AWS PrivateLink Interface Endpoints 對外提供，讓其他 VPC 中的用戶端能私下呼叫 API Gateway。

換言之，API Gateway 在兩個方向都使用 AWS PrivateLink。在考試中，若情境涉及「private API Gateway」或「API Gateway 呼叫 VPC 中的後端而不走網際網路」，無論名稱是否出現，AWS PrivateLink 都是底層機制。

遷移模式：從 VPC 對等連線到 AWS PrivateLink

何時遷移

• 對等連線規模已超過可維護性（N(N-1)/2 個連線在超過幾十個 VPC 後爆炸性增長）。
• 新購併帶來了無法重新規劃 IP 的重疊 CIDR。
• 安全審查要求服務範圍的存取，而非整個 VPC 對等連線。
• 合規要求每個服務的稽核日誌（Endpoint 層級的 CloudTrail 比對等連線層級的 VPC Flow Logs 粒度更細）。

遷移步驟

1. 清查每個對等連線中的服務；針對每項服務，確認相容 NLB 的前端方式。
2. 在每個生產端 VPC 中建立 VPC Endpoint Service；附加 NLB；設定允許的 principals。
3. 在消費端建立帶有相符 Private DNS 名稱的 Interface Endpoints；在切換期間雙軌並行（對等連線 + Endpoint）。
4. 將應用程式流量切換到 Endpoint 主機名稱；監控 Endpoint 上的 CloudWatch ActiveConnections 以及對等連線上的 BytesTransferred。
5. 一旦基於對等連線的流量降至零，移除對等連線。

這種漸進式方式是 SAP-C02 偏好的模式：沒有大爆炸式的一次性切換、每個步驟都有明確的可觀測性，且任何階段都可以回滾。

FAQ：SAP-C02 AWS PrivateLink 熱門問題

Q1：什麼時候應該使用 AWS PrivateLink，而非 VPC 對等連線或 Transit Gateway？

當你需要開放一項特定服務（而非整個 VPC），且以下一項或多項條件成立時，使用 AWS PrivateLink：VPC 有重疊的 CIDR 範圍（對等連線和 TGW 失效）、消費端群體龐大或為外部客戶（SaaS 模型）、存取必須是單向的（生產端從不主動發起連回），或你需要細粒度的每個消費端撤銷能力。VPC 對等連線適用於小型、靜態、雙向且 CIDR 不重疊的配對。Transit Gateway 適用於 5 個以上 VPC 需要廣泛傳遞性路由，且 CIDR 不重疊，或需要大規模混合式本地端連線的情況。

Q2：Gateway VPC Endpoints 和 Interface VPC Endpoints 的確切差異是什麼？

Gateway Endpoints 僅適用於 S3 和 DynamoDB，免費，透過路由表前綴清單條目運作，限於區域本地，且無法從本地端存取。Interface Endpoints（AWS PrivateLink 產品）適用於數百項 AWS 服務加上客戶發布的服務，按小時按 AZ 加每 GB 計費，透過帶有私有 IP 的 ENI 運作，可透過 Direct Connect 或 VPN 從本地端存取，且支援跨帳號和跨區域。對 VPC 內的 S3/DynamoDB 預設使用 Gateway Endpoint 節省成本；其他一切則使用 Interface Endpoint。

Q3：AWS PrivateLink 如何解決對等連線無法處理的重疊 CIDR 問題？

VPC 對等連線和 Transit Gateway 都是路由協定——它們在 VPC 之間轉發 IP 封包，因此需要不重疊的 CIDR 以確保目標不模糊。AWS PrivateLink 不進行路由：它在消費端 VPC 的 ENI 處終止 TCP 連線，然後從生產端發起全新連線。兩個 VPC 的 CIDR 從不被比較或一起路由，因此重疊完全無關緊要。這使 AWS PrivateLink 成為完全受管的 1:1 NAT 替代方案，而你原本必須在 Transit Gateway 上自行建構這種 NAT。

Q4：為何我的本地端伺服器仍然連到 AWS 服務的公共 Endpoint，而非我的 Interface Endpoint？

因為 Interface Endpoint 上的 Private DNS 只在 VPC 的 Route 53 Private Hosted Zone 內覆蓋 DNS。本地端解析器查詢公共 DNS 根，而公共 DNS 根回傳公共服務 IP。修正方法：在 VPC 中部署 Route 53 Resolver Inbound Endpoint，設定本地端 DNS 將 *.amazonaws.com（或特定服務網域）的查詢轉發給 Inbound Endpoint 的 IP 位址。Inbound Endpoint 使用 VPC 的 Private DNS 解析，回傳 Endpoint 的私有 ENI IP，本地端流量隨後透過 Direct Connect 或 VPN 正確流經 Interface Endpoint。

Q5：如何防止透過 S3 Gateway Endpoint 的資料外洩？

三個層次疊加使用：首先，套用 Endpoint Policy，將 Resource 限縮為你組織的儲存桶 ARN（或特定的 aws:PrincipalOrgID 條件）；其次，套用 IAM policies 進一步縮小 principals 的操作和儲存桶；第三，套用 S3 bucket policies，要求 aws:SourceVpce 符合你的 Endpoint ID。請記住預設 Endpoint Policy 是完全開放的——你必須明確替換它。搭配 Endpoint ENI 上的 VPC Flow Logs（Interface）或子網路上的 VPC Flow Logs（Gateway）以獲取稽核證據。

Q6：我能用 AWS PrivateLink 向另一個 VPC 開放 Lambda 函式嗎？

不能直接做到——VPC Endpoint Services 需要 NLB 或 GWLB 作為前端。若要透過 AWS PrivateLink 開放 Lambda，有兩種模式可行：(a) 在 Lambda 前放置 API Gateway Private REST API，它本身就是透過 PrivateLink Interface Endpoint 原生開放的；或 (b) 讓 Lambda 在 ALB 目標群組後方執行，將 ALB 作為 NLB 目標（NLB-with-ALB-target 功能），然後在 NLB 上建立 VPC Endpoint Service。在大多數 SAP-C02 問題中，選項 (a) 是更簡潔的答案。

Q7：當生產端撤銷允許的 principal 時，現有的消費端連線會發生什麼？

撤銷 principal 會阻止新的 Endpoint 連線，但不會立即終止現有連線。目前的 TCP 連線會持續到閒置逾時（預設 350 秒）或生產端明確呼叫 RejectVpcEndpointConnections 拒絕活動連線為止。若要符合合規要求的立即撤銷，應將 principal 移除與主動連線拒絕結合，理想情況下還要收緊 NLB 目標群組上的 security group，以在傳輸層直接丟棄現有連線。

Q8：AWS PrivateLink 流量是否自動加密？

AWS PrivateLink 在 AWS 全球骨幹上傳輸流量，AWS 將其描述為私有、實體隔離的網路。然而，AWS 不保證 PrivateLink 層的線路級加密，就像它對 TLS 的保證那樣。若要強保密性保證，請在應用程式層端對端執行 TLS（消費端 → NLB → 後端目標）。大多數 AWS 服務 Endpoint 已要求 TLS，因此對 AWS 服務 Interface Endpoints 這是自動的；對客戶發布的服務，請在 NLB 監聽器或後端目標上強制執行 TLS。

Q9：如何最小化 AWS PrivateLink 的跨 AZ 資料傳輸費用？

兩種技巧。首先，在每個消費端工作負載所在的 AZ 建立 Endpoint 的 ENI，讓區域 DNS 名稱的 AZ 親和性雜湊流量到同 AZ 的 ENI。其次，在程式碼或用戶端設定中，使用可用區域性 DNS 名稱（vpce-xxx-<az>.service.region.vpce.amazonaws.com）強制同 AZ 目標。在生產端，預設關閉 NLB 跨可用區域負載平衡（NLB 預設關閉）讓 NLB 目標保持在 AZ 本地。在高流量場景，這些做法能從每 GB 費用中節省可觀的成本。

AWS PrivateLink 在 SAP-C02 的延伸閱讀

• AWS PrivateLink User Guide（完整版）
• AWS Well-Architected Framework — Security Pillar（網路保護）
• AWS 白皮書：Building a Scalable and Secure Multi-VPC AWS Network Infrastructure
• AWS re:Invent NET 系列場次關於 PrivateLink 擴展模式（搜尋「NET301」、「NET305」、「NET405」）
• Amazon VPC Peering vs Transit Gateway vs PrivateLink 決策白皮書
• AWS Marketplace Seller Guide — 透過 AWS PrivateLink 的 SaaS 服務交付

將 AWS PrivateLink 作為一級架構工具掌握——而非 Amazon VPC 下的附註——SAP-C02 中關於重疊 CIDR、SaaS 開放、私有 AWS 服務存取和跨帳號服務共享的 Professional 等級考題，將成為最可預測的得分區域。反覆出現的模式是：AWS PrivateLink 用於服務範圍的開放、AWS PrivateLink 用於重疊 CIDR、Interface Endpoint + Route 53 Resolver Inbound Endpoint 用於混合式 DNS，以及 Endpoint Policies 用於外洩防護。熟記這四個模式，搭配 NLB 唯一要求和手動接受自動化模式，AWS PrivateLink 在考試當天將成為穩定的得分區域。