examlab .net 用最有效率的方法,考取最有價值的證照
本篇導覽 約 27 分鐘

PrivateLink、VPC Endpoints 與 Endpoint Policies

5,400 字 · 約 27 分鐘閱讀 ·

ANS-C01 網域 2.2 深入探討 PrivateLink:閘道端點 (僅限 S3 與 DynamoDB) 與介面端點、以 NLB 為後端的端點服務、用於資料周邊的端點策略、用於服務發現的私有 DNS、跨帳戶共享、重疊 CIDR 的存取模式。

立即做 20 題練習 → 免費 · 不用註冊 · ANS-C01

PrivateLink 是 ANS-C01 考試中約一半多帳戶場景題會涉及的連線性問題。Solutions Architect 考試通常將 VPC 端點視為「讓 S3 存取私密化的一種工具」。而進階網路專家 (Specialty) 考試則會問:「某 SaaS 提供商向 200 個客戶 VPC 暴露一項服務,客戶端具有重疊的 10.0.0.0/16 CIDR,SaaS 想要透過手動核准與按客戶日誌實現對每個客戶的存取控制 — 該使用何種拓撲、端點類型、策略結構,以及 DNS 如何解析?」這就是 PrivateLink 端點服務架構,ANS-C01 至少有 4-6 個題目圍繞此領域展開。

本主題涵蓋了 PrivateLink 的全方位原語:閘道端點 (僅限 S3 與 DynamoDB) 與 介面端點 (其他所有服務,由 NLB 驅動) 的對比、針對 SaaS 提供商的端點服務、用於資料周邊 (Data perimeter) 的端點策略、用於服務名稱解析覆蓋的私有 DNS、透過授權主體與 AWS RAM 進行的跨帳戶共享、PrivateLink 作為唯一可行方案的 CIDR 重疊場景、用於成本與營運鞏固的集中式介面端點中心 (Hub) 模式,以及安全性群組與端點策略的相互作用。本主題對應 任務陳述 2.1 (實作跨多個 AWS 帳戶、區域與 VPC 的路由與連通性)

PrivateLink 是 AWS 原生解決傳統路由無法處理的三大問題的答案:(a) 私有存取 AWS 服務,無需經過公有網際網路、NAT 或對等連接;(b) 跨帳戶暴露服務,無需共享 IP 空間或對等路由;(c) CIDR 重疊的 VPC 之間的連通性,這是 VPC 對等連接與 TGW 無法處理的。ANS-C01 期望你識別出這些情境並選擇 PrivateLink 作為答案。

本主題的框架是服務級別的連通性,而非網路級別的連通性。傳統路由 (對等連接, TGW, VPN) 連接的是網路 — 一旦一個網路的封包能到達另一個網路,其中的任何服務在安全性群組允許下都是可達的。PrivateLink 專門連接服務:一個端點僅暴露一個特定服務,且只有該服務透過端點可達,提供者網路上的其他服務均不可見。這種服務級別的隔離是考試重點測試的安全性與架構屬性。

考試會以三種方式測試 PrivateLink。閘道 vs 介面的選擇詢問「哪種服務對應哪種端點類型?」並包含「KMS 使用閘道端點」之類的干擾項 (這是錯的 — 只有 S3 與 DynamoDB 支援閘道端點)。端點策略設計詢問「如何透過端點策略防止對非組織儲存貯體的存取?」端點服務架構詢問「如何設計一個向 200 個客戶 VPC 暴露且具備按客戶授權的 SaaS 服務?」 — 這是典型的 PrivateLink 端點服務範疇。

PrivateLink 結合了幾種原語 (閘道端點、介面端點、端點服務、端點策略),在不需要路由或對等連接的情況下實現私有服務連通。以下三個類比有助於理解這些組件。

類比一:大樓內部的氣動傳輸管系統 (Pneumatic Tube System)

將 VPC 想像成一個辦公室樓層,AWS 服務 (如 S3 和 DynamoDB) 是大樓中央供應室,而公有網際網路則是街道。沒有 VPC 端點時,存取 S3 就像要走出大樓到街道上,再從大樓正門進入 — 慢、暴露在外且昂貴 (NAT GW 資料費 + IGW 費)。閘道端點就像辦公室樓層與供應室之間內部的氣動傳輸管,專供 S3 和 DynamoDB 使用。傳輸管不需要 ENI 或 IP 地址,它只是一個路由條目,說明「對於此服務,請使用傳輸管」。它是免費的。介面端點則是在你的辦公室安裝了一條專用的電話線,擁有自己的分機號碼 (具備私有 IP 的 ENI),透過 PrivateLink 直接連接到 AWS 服務。每條電話線都有小時費與通話費 (按 AZ + 按 GB)。端點服務是你 (SaaS 提供商) 為客戶安裝的專用電話線 — 你的客戶辦公室各有一台電話 (介面端點),連接到你的服務 NLB。端點策略是每條線路上的來電過濾規則 — 僅允許特定分機或通話類型。

類比二:具備服務櫃檯的圖書館

VPC 是一個研究圖書館。AWS 服務是圖書館系統中專業的服務櫃檯 (珍本書籍、檔案、微縮膠片、期刊訂閱)。公有網際網路是城市的公共圖書館目錄。沒有端點時,前往珍本書籍檔案室意味著要走到建築物外面去。閘道端點是閱覽室與檔案室之間的秘密通道 — 僅限兩個特定檔案室 (S3 和 DynamoDB),免費,除了路由圖條目外不需要鑰匙。介面端點是直通檔案室諮詢台的專用電話線,有自己的分機和一位審查通話的館員 (安全性群組)。每次通話都有往返費用。端點服務 (PrivateLink) 是指你自己營運一個檔案室,並為其他訂閱的圖書館提供直連電話線。端點策略每條電話線可以請求內容的規則 — 「此線路僅能由本研究聯盟的讀者請求 A 區的書籍」。

類比三:設有專科診所連線的醫院

VPC 是醫院的一個病房。AWS 服務是醫院網絡中其他地方的專科診所 (放射科、病理科、藥房)。公有網際網路是前往另一家醫院。閘道端點是病房與兩個特定診所 (S3 和 DynamoDB) 之間的內部走廊。病人可以自由走動 — 無需識別證、無檢查站、無費用。介面端點是病房與專科診所之間的專用內部電話線 — 病房端有一台電話 (ENI + IP),診所接待處 (NLB 目標群組) 在另一端。每次通話有按小時與按分鐘的收費。端點服務是當你院區的實驗室向其他醫院的病房提供私有遠距醫療時 — 他們透過自己的端點訂閱你的服務。端點策略每條電話線能做什麼的範圍 — 「此線路僅能撥打放射科,僅限 X 光請求,且僅限經核准的醫師」。

對於 ANS-C01,當問題對比閘道端點 (免費、僅限 S3/DynamoDB、無 ENI) 與介面端點 (按 AZ ENI 收費) 時,氣動傳輸管類比是最高價值的心理模型。對於資料周邊與端點策略問題,來電過濾規則子類比讓分層策略變得直觀。對於 SaaS 端點服務,為客戶安裝的專用電話線是最清晰的。參考資料:https://docs.aws.amazon.com/vpc/latest/privatelink/concepts.html

PrivateLink 定義了生產者 (服務提供者) 與一個或多個消費者 (服務使用者)。生產者發佈一個由網路負載平衡器 (NLB) 或閘道負載平衡器 (GWLB) 支援的端點服務。消費者建立連線至生產者端點服務的介面端點

生產者端 — 端點服務

生產者建立一個連結至 NLB (或 GWLB) 的端點服務。端點服務具有:

  • 服務名稱 — 全球唯一,格式為 com.amazonaws.vpce.<region>.vpce-svc-xxxxx
  • 授權主體 (Allowed principals) — 獲准對此服務建立端點的 IAM 主體 (帳戶、角色)。
  • 核准旗標 — 對消費者端點連線的手動或自動核准設定。
  • 私有 DNS 名稱 (選用) — 消費者可以在內部解析的自訂 DNS 名稱 (例如 api.saas.example.com)。

消費者端 — 介面端點

消費者在自己的 VPC 中建立一個介面端點,並指定生產者的服務名稱。該端點:

  • 在消費者選擇的子網路中,每個 AZ 布建一個 ENI
  • 每個 ENI 在消費者的子網路 CIDR 中有一個私有 IP
  • 具有控制哪些用戶端可以連接的安全性群組
  • 透過 DNS 解析服務 — 私有 DNS 或自動生成的 DNS 名稱。

AWS 受管服務使用的是什麼

對於 AWS 受管服務 (KMS、Secrets Manager、STS、Systems Manager、ECR、SQS、SNS、EventBridge 等),AWS 本身即是生產者。消費者建立一個目標為 AWS 受管服務名稱 (例如 com.amazonaws.<region>.kms) 的介面端點。機制相同,只是生產者是 AWS。

PrivateLink 不提供雙向網路連通性。它是單向的:消費者可以呼叫生產者,但生產者無法發起與消費者的連線。若需雙向連通性,請使用 VPC 對等連接、TGW 或 Site-to-Site VPN。

  • 閘道端點 (Gateway endpoint):基於路由表的 S3 與 DynamoDB 端點;無 ENI,免費。
  • 介面端點 (Interface endpoint):基於 ENI 的端點,用於 AWS 服務或透過 PrivateLink 的自訂服務。
  • 端點服務 (Endpoint service):生產者端的構造,透過 PrivateLink 暴露服務,由 NLB/GWLB 支援。
  • 授權主體 (Allowed principals):獲准連線至端點服務的 IAM 主體。
  • 端點策略 (Endpoint policy):端點上的 IAM 形式資源策略,控制流經的流量。
  • 私有 DNS (Private DNS):AWS 管理的公有服務 DNS 覆蓋,指向端點 ENI。
  • 服務名稱 (Service name):端點服務的全球識別碼;格式 com.amazonaws.vpce.<region>.vpce-svc-xxx
  • 字首清單 (Prefix list):受管的 CIDR 列表;針對 S3、DynamoDB 等存在 AWS 受管字首清單。
  • 參考資料:https://docs.aws.amazon.com/vpc/latest/privatelink/concepts.html

閘道端點 — 僅限 S3 與 DynamoDB

閘道端點是添加至 VPC 路由表的路由目標,用於攔截流向 S3 或 DynamoDB 的流量並透過 AWS 骨幹網路路由,繞過公有網際網路。只有 S3DynamoDB 支援閘道端點 — 其他 AWS 服務均不支援。

閘道端點如何運作

閘道端點作為目標添加至 VPC 路由表。AWS 提供字首清單,列出每個區域中 S3/DynamoDB 的 IP 範圍 (例如 us-east-1 的 S3 為 pl-63a5400a)。路由表條目:目的地 pl-63a5400a (字首清單),目標 vpce-xxxx (閘道端點)。當執行個體向字首清單內的 S3 IP 發送流量時,路由會將其導向閘道端點,隨後透過 AWS 骨幹網轉發。

成本 — 免費

閘道端點無小時費或每 GB 處理費。它們是免費的。對於原本需要 NAT GW 才能存取 S3/DynamoDB 的私有子網路而言,它們是首選。

閘道端點上的端點策略

閘道端點支援端點策略 — 附加在端點上的 IAM 形式資源策略,限制哪些儲存貯體、資料表、主體或動作可透過其存取。最強大的應用是資料周邊 (Data perimeter):端點策略僅允許存取組織帳戶列表中的儲存貯體,即便使用被盜用的憑證,也能防止資料外洩到攻擊者控制的儲存貯體。

閘道端點的限制

  • 僅限 S3 與 DynamoDB。其他所有服務均使用介面端點。
  • 僅限同區域 — 無法透過閘道端點到達另一個區域的 S3。
  • 無跨帳戶直接存取 — 儲存貯體雖然可達,但其 IAM 權限仍然適用。
  • 無法從在地 (On-premises) 環境存取 — 無法透過 Direct Connect 或 VPN 到達閘道端點;這與介面端點不同,後者可跨越混合連線被存取。

閘道端點路由表條目

常見的 ANS-C01 問題:私有子網路的路由表包含指向閘道端點的字首清單條目。字首清單是特定區域的 — 不同區域,字首清單 ID 不同。更新閘道端點策略或路由關聯無需變更用戶端應用程式;字首清單會隨 S3 IP 變更動態調整。

最常見的 ANS-C01 干擾項:選項描述針對 KMS、Secrets Manager、ECR、Systems Manager 或除 S3/DynamoDB 以外任何服務的閘道端點。根本不存在這種東西。 閘道端點專供 S3 與 DynamoDB 使用。其他所有 AWS 服務均使用介面端點 (PrivateLink)。請記住這個二元事實:閘道端點 = 僅 S3 + DynamoDB。如果場景描述對 KMS/Secrets/STS 等的私有存取,答案是介面端點,而非閘道端點。參考資料:https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html

介面端點是你子網路中的一個或多個 ENI,充當 AWS 服務或自訂 PrivateLink 服務的代理。每個 ENI 具有私有 IP、支援安全性群組,且 (在啟用私有 DNS 時) 為 VPC 內的用戶端覆蓋公有服務 DNS。

按 AZ 的 ENI

介面端點在選定的子網路中各布建一個 ENI,通常每個 AZ 一個以實現 HA。這些 ENI 由 AWS 服務或生產者擁有,但位於消費者的子網路中,且擁有來自消費者子網路 CIDR 的 IP。流向這些 IP 的流量會透過 PrivateLink 轉發至生產者的 NLB 或 AWS 服務。

成本

介面端點有按 AZ 按小時的收費外加每 GB 處理費。與 NAT GW 相比,介面端點對於 AWS 服務流量通常更便宜,且安全性更高 (無網際網路傳出)。對於高流量工作負載,與 NAT GW 相比的每 GB 節省可能非常顯著。

介面端點 ENI 上的安全性群組

每個介面端點 ENI 都附有一個安全性群組。預設是 VPC 的預設 SG (通常過於寬鬆)。最佳實踐:建立一個專用 SG,僅允許來自需要存取該端點的用戶端子網路的傳入 TCP 443。SG 控制哪些用戶端可以連接到端點;端點策略控制他們在連接後可以執行什麼操作。

私有 DNS

當你建立一個啟用了私有 DNS 的介面端點時,AWS 會在 VPC 中為該 AWS 服務的標準 DNS 名稱 (例如 secretsmanager.<region>.amazonaws.com) 註冊一個私有託管區域。VPC 中解析此名稱的用戶端將獲得端點 ENI 的私有 IP,而非公有服務 IP。這意味著無需更改應用程式代碼 — 現有用戶端會自動使用端點。

私有 DNS 要求 VPC 的 enableDnsSupport=trueenableDnsHostnames=true。若不滿足,私有 DNS 將失效,用戶端仍會解析為公有 IP。

無私有 DNS 時的端點 DNS 名稱

每個介面端點還會獲得以下格式的端點專用 DNS 名稱

  • 每 VPC 名稱:vpce-<id>-<sub>.<service>.<region>.vpce.amazonaws.com
  • 每 AZ 名稱:vpce-<id>-<sub>-<az>.<service>.<region>.vpce.amazonaws.com

用戶端可以直接使用這些名稱,或在啟用私有 DNS 時使用標準服務 DNS 名稱。

這是一個高頻出現的 ANS-C01 區別。介面端點:每個 AZ 一個 ENI、有 IP、有 SG、有按 AZ 小時費與每 GB 費用、支援幾乎所有 AWS 服務 + 自訂 PrivateLink。閘道端點:無 ENI、無 IP、無 SG、無費用、僅支援 S3 與 DynamoDB。考試經常測試「哪些服務對應哪種端點類型」 — 請死記硬背。對於 KMS、Secrets Manager、STS、Systems Manager、ECR、SNS、SQS、Kinesis 等任何服務,介面端點是唯一選擇。參考資料:https://docs.aws.amazon.com/vpc/latest/privatelink/concepts.html

端點策略 — 資料周邊的槓桿

端點策略是附加在 VPC 端點上的 IAM 形式資源策略。它限制了哪些主體、動作與資源可透過該端點存取。端點策略與基於身分的策略以及基於資源的策略一同被評估;有效權限是三者的交集。

預設策略 — 完全存取

預設情況下,端點策略授予 * (完全存取) — 意味著端點在 IAM 與資源策略之外不增加額外限制。這對開發而言很方便,但對生產安全性而言不足。

限制性端點策略 — 資料周邊模式

S3 閘道端點上典型的資料周邊策略:

{
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": ["s3:GetObject", "s3:PutObject", "s3:ListBucket"],
    "Resource": "*",
    "Condition": {
      "StringEquals": {
        "aws:PrincipalOrgID": "o-xxxxxxx"
      }
    }
  }]
}

這僅允許當呼叫主體位於組織 o-xxxxxxx 內時存取 S3。即便被盜用的存取金鑰具備 IAM 權限,來自組織外的金鑰也無法透過此端點到達 S3 — 端點會拒絕該請求。

與儲存貯體策略及 SCP 配合

完整的資料周邊由三層組成:

  1. 帶有 aws:PrincipalOrgID端點策略 — 限制誰能使用該端點。
  2. 帶有 aws:SourceVpceS3 儲存貯體策略 — 限制哪些端點能到達該儲存貯體。
  3. 帶有 aws:ResourceOrgID服務控制策略 (SCP) — 限制組織內的主體能呼叫哪些儲存貯體。

三者結合:防止向組織外儲存貯體的資料外洩 (由 SCP 阻斷)、防止從外部向你的儲存貯體寫入 (由儲存貯體策略阻斷)、防止外部主體使用你的端點 (由端點策略阻斷)。

介面端點策略

介面端點也支援端點策略。對於 KMS、Secrets Manager、STS 等服務,端點策略可控制哪些金鑰、秘密或角色可透過端點存取。常見模式:KMS 端點策略將 kms:Decrypt 限制在特定的 KMS 金鑰 ARN,防止透過此端點使用任何其他金鑰。

ANS-C01 期望你識別出這三層資料周邊。單獨任何一層都有繞過方式。僅端點策略:阻止外部主體使用端點,但無法阻止透過 NAT GW 的流量到達外部儲存貯體。僅儲存貯體策略:阻止外部端點,但無法阻止你的主體存取外部儲存貯體。僅 SCP:阻止你的主體存取外部儲存貯體,但無法阻止外部主體使用你的端點。三者協同,才能形成完整的雙向周邊。關於「防止對非組織儲存貯體的任何 S3 存取」的問題,通常期望選擇這三者的組合。參考資料:https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html

端點服務 — SaaS 提供商模式

端點服務是生產者端的 PrivateLink 構造,用於向消費者暴露服務。該服務由 NLB (TCP/UDP/TLS) 或 GWLB (透明內嵌流量) 支援。

生產者設定

  1. 生產者在其 VPC 的 NLB (或 GWLB) 後方部署服務。
  2. 生產者在同一個 VPC 中建立一個端點服務,並將其連結至 NLB。
  3. 生產者添加授權主體 — 獲准連線的消費者帳戶或角色。
  4. 生產者可選擇性地啟用核准要求 — 每個消費者端點連線都需手動批准。
  5. 生產者可選擇性地註冊一個自訂私有 DNS 名稱 (例如 api.saas.example.com)。

消費者連線

  1. 消費者獲取生產者的服務名稱 (例如 com.amazonaws.vpce.us-east-1.vpce-svc-xxxxx)。
  2. 消費者在自己的 VPC 中建立一個目標為該服務名稱的介面端點
  3. 如果設定了核准要求,生產者需手動核准連線。
  4. 消費者流向端點 ENI 的流量透過 PrivateLink 到達生產者的 NLB,最後到達後端執行個體。

跨帳戶與跨區域

PrivateLink 端點服務預設支援跨帳戶 (假設授權主體包含消費者的帳戶)。跨區域不直接支援 — 位於與生產者不同區域的消費者無法連線至該端點服務。解決方法:在多個區域部署生產者,各區域擁有自己的端點服務;或使用 TGW 對等連接 + 生產者區域中的介面端點。

範例 — 向 200 個客戶 VPC 提供服務的 SaaS 供應商

SaaS 提供商向 200 個客戶 VPC 暴露一個 REST API:

  • 提供商將 API 部署在 NLB 後方;建立端點服務。
  • 提供商將 200 個客戶帳戶添加為授權主體。
  • 提供商將 acceptance required 設為 true,以實現手動上線控制。
  • 每個客戶在自己的 VPC 中建立介面端點,獲取端點 DNS 名稱,並將 API 客戶端指向它。
  • 提供商在 CloudWatch 與 VPC Flow Logs 中看到按客戶劃分的連線記錄 — 實現按客戶日誌。
  • 提供商的 NLB 目標群組可以針對不同客戶設定不同後端 (進階多租戶) 或共享後端 (簡單多租戶)。

對於向客戶 VPC 暴露服務的 SaaS 提供商,PrivateLink 端點服務是 AWS 推薦的模式,優於其他替代方案,如:VPC 對等連接 (對等連接需要維護路由表且 CIDR 重疊是阻礙)、Transit Gateway (TGW 需要更多編排且按消費者的存取控制較粗糙) 或透過網際網路的公有 API (安全性較低且傳出成本較高)。端點服務支援按消費者的授權、手動核准、按 AZ 部署以及連線級別的日誌 — 具備 SaaS 提供商所需的所有營運掛勾。關於「SaaS 向許多消費者 VPC 暴露服務」的 ANS-C01 問題,答案通常是端點服務。參考資料:https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-share-your-services.html

常見的 ANS-C01 場景:兩個或多個具有重疊 10.0.0.0/16 CIDR 的 VPC 需要通訊。VPC 對等連接與 TGW 無法解決此問題 — 因為路由是按目的地 IP 進行的,它們要求 CIDR 空間唯一。PrivateLink 可以解決。

PrivateLink 的資料路徑使用來自消費者子網路的目的地 IP (端點 ENI 的 IP) 來到達後方抽象存在的服務。生產者實際的 VPC CIDR 對消費者是不可見的;消費者僅看到自己子網路中的端點 ENI。因此,即便消費者與生產者都使用 10.0.0.0/16,消費者的流量仍留在其自身的 CIDR 內 (流向端點 ENI),生產者的 NLB 則會接收到經代理的流量,來源 IP 按 NLB 設定被重寫或保留。

使用案例

  • 收購的公司與母公司擁有相同的 RFC 1918 空間 — 必須在不更換 IP 的情況下進行整合。
  • SaaS 提供商必須服務客戶,無論客戶的 VPC CIDR 為何。
  • 多租戶實驗室環境,其中每個租戶都按模板使用 10.0.0.0/16。

限制

  • PrivateLink 是單向的服務暴露 — 而非完整的網路連通性。
  • 對於 CIDR 重疊情況下的完整連通性,選項包括基於 NAT 的替代方案 (罕見且複雜) 或更換 IP (re-IP) (最常見)。

集中式介面端點模式 — 成本與營運鞏固

對於擁有許多 VPC 且每個 VPC 都需要透過介面端點存取 AWS 服務的組織,按 VPC 按 AZ 的每小時成本會不斷累積。集中式介面端點模式將介面端點放置在單個共享 VPC 中,並透過 TGW 或對等連接將其他 VPC 路由至該處。

架構

  • 中央端點 VPC:包含 KMS、Secrets Manager、STS 等服務的介面端點。
  • 支點 VPC:具有 TGW 連接,將 AWS 服務流量透過 TGW 路由至端點 VPC。
  • 中央端點 VPC 中的 Route 53 Resolver 傳出端點:配合將服務 DNS 名稱轉發至中央端點私有 DNS 的規則。

成本效益

不使用集中化:10 個支點 VPC × 3 個 AZ × 5 個服務 = 每月 150 個端點-AZ 小時。 使用集中化:1 個端點 VPC × 3 個 AZ × 5 個服務 = 每月 15 個端點-AZ 小時。

按 AZ 小時收費顯著節省。權衡點:產生的 TGW 資料處理費與跨 VPC 流量,但對許多工作負載而言,整合是勝出的。

DNS 挑戰

挑戰在於:預設情況下,AWS 服務 DNS 名稱 (secretsmanager.<region>.amazonaws.com) 僅在端點所在的 VPC 內解析為其私有 IP。解析相同名稱的支點 VPC 將獲得公有 IP,而非中央端點 IP。解決方法:在支點 VPC 間共享指向中央端點的 Route 53 PHZ (私有託管區域),或使用 Route 53 Resolver 規則 進行轉發。

實作說明

集中式模式增加了營運複雜性 — DNS 配置、TGW 路由管理、跨支點的安全性群組更新。它適用於極大型的多 VPC 組織;擁有 2-5 個 VPC 的較小部署可能更偏好按 VPC 部署端點。

  • 閘道端點:僅限 S3 + DynamoDB,免費,無 ENI,基於路由表。
  • 介面端點:按 AZ 的 ENI、有 SG、按小時 + 按 GB 收費、支援大多數 AWS 服務。
  • 端點服務:生產者端構造,由 NLB 或 GWLB 支援,具備授權主體與選用的核准設定。
  • 預設端點策略:完全存取 (*);需自訂以進行限制。
  • 私有 DNS:要求 VPC 設定 enableDnsSupport=true 且 enableDnsHostnames=true。
  • 服務名稱格式com.amazonaws.vpce.<region>.vpce-svc-xxx (第三方) 或 com.amazonaws.<region>.<service> (AWS)。
  • 跨區域:端點服務不跨區域;需按區域部署生產者。
  • 透過在地環境存取端點:介面端點可透過 DX/VPN 到達;閘道端點則不行。
  • 參考資料:https://docs.aws.amazon.com/vpc/latest/privatelink/concepts.html

從在地 (On-Premises) 環境存取介面端點

介面端點的一個獨特性質是:它們可以從在地環境透過 Direct Connect 或 Site-to-Site VPN 存取,因為其 ENI 的 IP 是可路由的。常見模式:在地系統透過客戶擁有的私有 VPC 中的介面端點呼叫 AWS 服務,而非透過 NAT GW + IGW。

架構

  • VPC 為該 AWS 服務配備了一個介面端點。
  • Direct Connect 或 VPN 將在地連接至該 VPC。
  • 在地 DNS 解析器將 AWS 服務網域轉發至該 VPC 中的 Route 53 Resolver 傳入 (Inbound) 端點,後者解析為介面端點的私有 IP。
  • 在地應用程式透過私有 IP 呼叫 AWS 服務,流量經 DX/VPN 到達 VPC,再透過 PrivateLink 到達 AWS 服務。

為什麼這很重要

對於受規管的工作負載,在地環境不得到達公有網際網路,存取 AWS 服務的唯一途徑是透過客戶自己的 VPC。這消除了對在地環境通往 AWS 公有 IP 空間的 NAT/防火牆的需求。

閘道端點不支持此模式

閘道端點基於路由表並使用 AWS 內部的字首清單。它們無法從在地環境存取 — 字首清單不會透過 DX/VPN 傳遞。因此,從在地存取 S3 無法使用閘道端點;必須使用 NAT GW + IGW (公有路徑) 或 S3 介面端點 (S3 專有的一種介面端點類型,提供基於 ENI 的存取,可與閘道端點並存)。

情境描述在地系統需要透過 Direct Connect 到達 S3,且 VPC 中已部署閘道端點。候選人選擇「配置在地 BGP 以公告字首清單」 — 但 AWS 受管字首清單無法透過 BGP 公告給在地環境。閘道端點僅適用於 VPC 內流量。解決方法:使用 S3 介面端點 (新的基於 ENI 的選項),它可透過 ENI 的私有 IP 從在地到達;或將在地配置為使用 NAT GW + IGW 存取 S3 (公有路徑,對合規性較差)。考試經常測試此區別。參考資料:https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html

陷阱 1:KMS、Secrets Manager 等具備閘道端點

錯。僅 S3 與 DynamoDB 具備閘道端點。其他所有服務均使用介面端點。

陷阱 2:閘道端點擁有 ENI

錯。閘道端點沒有 ENI。它們是路由表中的字首清單條目。

陷阱 3:介面端點是免費的

錯。介面端點有按 AZ 按小時的收費以及每 GB 處理費。

陷阱 4:閘道端點支援安全性群組

錯。閘道端點沒有 ENI,因此沒有安全性群組。請使用端點策略進行存取控制。

陷阱 5:端點服務可跨區域使用

錯。端點服務是區域性的。對於多區域,需按區域部署。

錯。PrivateLink 是單向的服務暴露。若需雙向,請使用對等連接、TGW 或 VPN。

陷阱 7:私有 DNS 在沒有 enableDnsHostnames 的情況下也能工作

錯。私有 DNS 要求 VPC 同時設定 enableDnsSupport=true 且 enableDnsHostnames=true。

陷阱 8:在地環境可到達閘道端點

錯。閘道端點僅限 VPC 內部。在地環境需使用介面端點 (或專門的 S3 介面端點)。

Q1:為什麼閘道端點僅針對 S3 與 DynamoDB 存在?

歷史原因:閘道端點是最初的 VPC 端點機制,分別於 2015 年 (S3) 與 2017 年 (DynamoDB) 推出。它們利用路由表字首清單與 AWS 骨幹網傳輸流量,無按 AZ 的 ENI 或小時費。對於許多 VPC 存取 S3 與 DynamoDB 的高流量場景,它們極其高效。AWS 隨後在 2017 年推出了介面端點 (PrivateLink) 作為一種更靈活的機制,透過以 NLB 為後端的 PrivateLink 支援任何服務,包括第三方 SaaS。團隊選擇不將閘道端點擴展到更多服務,因為介面端點更好地解決了更廣泛的問題。如今,S3 與 DynamoDB 也提供了介面端點選項,用於需要基於 ENI 存取的案例 (例如在地環境可達性),因此即使這兩項服務現在也具備兩種口味。

Q2:對於 S3,我該如何決定選擇閘道端點還是介面端點?

預設針對 VPC 內部的 S3 存取選用閘道端點 — 它免費、開銷低且支援良好。在以下情況下選用 S3 介面端點:(a) 需要透過 Direct Connect 或 VPN 從在地環境存取 S3 (閘道端點在地不可達);(b) 跨區域存取 (閘道是區域限定的;介面端點在某些模式下可跨區域連通);(c) 需要在資料路徑上進行安全性群組控制 (閘道無 SG);(d) 需要按 AZ 的 DNS 解析以實現流量在地化。代價是:介面端點有按 AZ 小時費與每 GB 處理費。閘道端點免費。對於大多數簡單的 VPC 內工作負載,閘道端點是答案;對於混合雲或複雜的多帳戶模式,介面端點則是。

Q3:資料周邊模式如何結合端點策略、儲存貯體策略與 SCP?

每一層防護不同的向量。帶有 aws:PrincipalOrgID = our-org端點策略限制了誰能使用此端點 — 防範來自組織外的被盜憑證。帶有 aws:SourceVpce = our-endpointS3 儲存貯體策略限制了哪些端點能到達此儲存貯體 — 防範來自公有網際網路或未授權 VPC 的存取。針對 s3:*aws:ResourceOrgID != our-org 設定 Deny 的 SCP 限制了你的主體能存取哪些儲存貯體 — 防止你的主體將資料外洩到攻擊者控制的儲存貯體。三者結合形成了閉環的雙向周邊:無外部外洩 (SCP 阻斷)、無外部注入 (儲存貯體策略阻斷)、端點不被外部利用 (端點策略阻斷)。ANS-C01 期望看到這三者的結合。

Q4:我如何將服務從我的 VPC 暴露給跨帳戶的多個客戶 VPC?

使用 PrivateLink 端點服務。在你的生產者 VPC 中將服務部署在 NLB (TCP/UDP/TLS) 後方。建立連結至 NLB 的端點服務。添加授權主體 — 獲准連線的消費者帳戶。可選擇性啟用核准要求以實現手動上線控制。客戶在其 VPC 中建立目標為你服務名稱的介面端點;你手動核准 (若有要求) 或自動接受。每位客戶的流量從其端點 ENI 流向你的 NLB 並到達後端。透過你 NLB 上的 VPC Flow Logs 實現按客戶日誌;透過授權主體實現按客戶存取控制。跨帳戶原生支持。限制:跨區域需按區域部署;雙向連通需另行建立對等連接或 TGW。

Q5:介面端點啟用與停用私有 DNS 有什麼區別?

啟用私有 DNS (AWS 受管服務的預設值):AWS 在你的 VPC 中為服務的標準 DNS 名稱 (例如 secretsmanager.us-east-1.amazonaws.com) 建立一個私有託管區域。VPC 內的用戶端解析此名稱將獲得端點的私有 IP。無需更改應用程式代碼 — 現有的 AWS SDK 會使用標準名稱並自動利用端點。停用私有 DNS:用戶端解析標準名稱仍會獲得公有服務 IP。要使用端點,應用程式必須顯式指定端點專用 DNS 名稱 (vpce-xxx.secretsmanager.us-east-1.vpce.amazonaws.com)。僅當同一 VPC 內有多個相同服務的端點 (例如 prod 與 staging 分別擁有端點) 或私有 DNS 與自訂 Route 53 PHZ 衝突時,才停用私有 DNS。預設建議啟用。

Q6:為什麼我的介面端點不工作,即便安全性群組已允許流量?

常見原因:(a) VPC dnsSupport 或 dnsHostnames 被停用 — 私有 DNS 無法運作,用戶端仍解析為公有 IP。修正:啟用這兩項 VPC 屬性。(b) 端點子網路不在用戶端的 AZ 中 — 介面端點是按 AZ 的;若端點僅在 AZ-a 而用戶端在 AZ-b,流量必須跨 AZ 跳轉 (且需透過 DNS 解析為 AZ-a 的端點)。最佳實踐:在用戶端使用的所有 AZ 中部署端點。(c) 端點策略過於嚴格 — 預設策略為 *,但自訂策略可能封鎖了主體或動作。檢查策略與 IAM 權限。(d) 端點 ENI 上的安全性群組不允許用戶端子網路 — 必須允許來自用戶端子網路 CIDR 或 SG 的傳入 TCP 443。(e) 路由表缺少字首清單 (僅限閘道端點) — 對於閘道端點,路由表需要指向端點的字首清單條目。

Q7:集中式介面端點模式如何降低成本?

按 VPC 部署的介面端點具有按 AZ 的小時費 (每個約 $0.01/小時,乘以 AZ 數)。對於一個擁有 20 個 VPC、每個 VPC 在 3 個 AZ 中各需 5 個服務端點 (KMS, Secrets, STS, ECR, Systems Manager) 的組織:20 × 5 × 3 = 每小時 300 個端點-AZ 小時,大約每月 300 × $0.01 × 730 小時 = ~$2,200。使用集中化:1 個端點 VPC × 5 個服務 × 3 個 AZ = 每小時 15 個端點-AZ 小時,每月約 ~$110。節省:在此規模下每月約 ~$2,000。注意:TGW 資料處理費會為跨 VPC 流量增加約 ~$0.02/GB,會部分抵消高流量工作負載的節省。營運複雜性也會增加成本 (DNS 配置、安全性審查)。集中式模式通常在 10 個以上 VPC 時值得採用;較小規模的部署可能偏好按 VPC 部署端點以求簡單。

Q8:介面端點的安全性群組要求是什麼?

每個介面端點的 ENI 都有一個附加的安全性群組。預設是 VPC 的預設 SG (通常過於寬鬆 — 允許來自自身的全部存取)。生產環境建議:為每個端點建立一個專用 SG,僅允許來自用戶端子網路 CIDR 或用戶端 SG 的傳入 TCP 443。傳出規則可保持預設。端點 SG 控制誰能到達端點;端點策略控制他們連線後能做什麼。分層:SG 限制網路暴露面,策略限制操作面。對於呼叫生產者 PrivateLink 服務的消費者端端點,同樣適用此 SG-on-ENI 邏輯 — 消費者透過 SG 控制其 VPC 內誰能到達端點,這與生產者的授權主體控制是分開的。

Q9:為什麼除了 (或取代) 閘道端點外,我還需要 S3 介面端點?

閘道端點有兩個核心限制:(a) 無法從在地環境存取 (透過 Direct Connect 或 VPN),因為它依賴於不會傳遞至在地的字首清單;(b) 資料路徑上沒有安全性群組控制,僅有端點策略。S3 介面端點 (2021 年推出的新功能) 解決了這兩點:它是基於 ENI 的,具有私有 IP,可從在地環境透過 DX/VPN 到達,且支援安全性群組進行精細存取控制。權衡:介面端點不是免費的 (有按 AZ 小時費 + 每 GB 處理費),因此對於單純的 VPC 內 S3 存取,閘道端點仍然更便宜。模式:針對 VPC 內流量使用閘道端點 (免費, 基於路由);針對在地與跨帳戶流量使用 S3 介面端點 (付費, 基於 ENI)。兩者可在同一 VPC 內共存。

VPC 對等連接按目的地 IP 路由封包,這要求兩個 VPC 之間的 CIDR 空間唯一。如果兩者都使用 10.0.0.0/16,目的地為 10.0.0.5 的封包可能意指任何一個 VPC,路由會產生歧義 — 對等連線將無法建立。PrivateLink 的運作方式不同。消費者在其自己的 VPC 中建立一個介面端點,ENI 位於其自己的子網路 (例如消費者 VPC 中的 10.0.5.42)。消費者將流量發送到此本地 IP 來存取生產者的服務。生產者絕不會看到消費者的 CIDR;生產者的 NLB 看到的是來自 PrivateLink 網狀結構的流量。即便雙方都使用 10.0.0.0/16,每一側都留在自己的 CIDR 內 — 無路由衝突。這使得 PrivateLink 成為 SaaS 提供商服務於任意 CIDR 客戶、收購公司整合期間處理重疊空間以及多租戶實驗室的唯一可行連通機制。

進階閱讀

PrivateLink 是服務級別的連通性原語;ANS-C01 的下一層是 Route 53 Resolver 混合 DNS,用於從在地和跨帳戶解析私有端點名稱;Transit Gateway 作為網路織網,透過多帳戶路由補充 PrivateLink;VPC 路由原語 處理端點路由表如何與 TGW 和傳播路由交互;以及用於聲明式定義這一切的 IaC 模式

官方資料來源

更多 ANS-C01 主題