開發者必備的 VPC 安全基礎

開發者需要的 VPC 安全知識，是 Amazon VPC 中那塊直接出現在 DVA-C02 應用層情境題的切片——Lambda 函式如何連到私有子網中的 Amazon RDS、ECS 任務在 Fargate 上如何不透過 NAT Gateway 呼叫 AWS Secrets Manager、安全群組如何將一個微服務串接到另一個，以及為什麼 VPC 安全觀念對開發者而言，往往是透過「我的 Lambda 逾時」或「我的容器無法連到 DynamoDB」這類場景來測驗，而非透過 CIDR 規劃謎題。在 DVA-C02 中，這個主題出現在 Domain 2（安全性，Task 2.1 與 2.2），同時也間接貫穿 Domain 1（事件來源串接）與 Domain 4（冷啟動與連線失敗排查）。解決方案架構師在意子網分層；開發者在意的是為什麼程式碼無法與它需要溝通的服務對話，而 VPC 安全知識正是這個問題的解答。

本指南是 SAA-C03 VPC 廣域筆記的開發者專屬補充，刻意將範疇縮減至 DVA-C02 在應用情境中考驗的概念：安全群組作為第一道防線、NACL 快速提醒、透過 VPC Endpoint 私下呼叫 AWS API、Lambda 在 VPC 內的運作機制（包含 Hyperplane ENI 與冷啟動影響）、Fargate awsvpc 網路模式、透過 AWS Cloud Map 進行 ECS 服務探索、私有子網的對外流量模式、介面端點的執行期相依性、跨 VPC 存取，以及有狀態的回覆埠行為。這是比完整 VPC 網路更窄的主題，而 DVA-C02 正是以這個較窄的框架來出題。

開發者的 VPC 安全觀念在 DVA-C02 上究竟考什麼

開發者在 DVA-C02 上幾乎不需要從頭設計 VPC。考題是把你放進一個已經建好的 VPC 裡，要你做出應用層的決策：Lambda 函式應使用哪個安全群組、容器需要哪個 Endpoint、為什麼 SDK 呼叫一直掛著。這就是開發者 VPC 安全觀念的視角。

開發者的四個核心問題

DVA-C02 上每一道 VPC 安全情境題，都可以化約為以下四個開發者問題之一：

1. 我的運算資源能連到它所依賴的服務嗎？ Lambda 能連到 RDS 嗎、Fargate 能連到 ElastiCache 嗎、EC2 能連到 DynamoDB 嗎。答案藏在安全群組、路由表和 VPC Endpoint 裡。
2. 我的運算資源能私下呼叫 AWS API 嗎？ Lambda 呼叫 AWS Secrets Manager 時，流量是經過網際網路、NAT Gateway，還是介面端點。開發者視角將此視為成本與延遲問題，同時兼顧隱私保障。
3. 服務彼此能互相找到嗎？ ECS 任務不斷啟動與終止，order-service 如何在不硬編碼 IP 的情況下找到 payment-service？答案是：AWS Cloud Map 與私有託管區域。
4. 為什麼我的程式碼逾時？ Lambda 連接 RDS 連了 15 秒後終止。問題是安全群組、子網、ENI、冷啟動還是 DNS？開發者 VPC 安全觀念提供了診斷的優先順序梯。

為什麼開發者 VPC 安全在 DVA-C02 上有獨立主題

解決方案架構師考試測驗 CIDR 區塊和 Transit Gateway；開發者考試測驗「我的 Lambda 無法連到 Secrets Manager」。兩場考試共享同一組底層基礎，但情境截然不同。DVA-C02 的開發者 VPC 安全知識聚焦在應用邊界：掛載到 Lambda 的 ENI、Fargate 上的任務 ENI、包覆 RDS 的安全群組。那是開發者設定、除錯的地方，也是考試期望你在 90 秒內給出正確答案的地方。

白話文解釋 開發者的 VPC 安全觀念

三種不同的類比可以幫助你理解 VPC 安全觀念。挑一個最記得住的，在考試時腦中立即切換回去。

類比一：有門衛與私用電梯的辦公大樓

把你的應用程式想像成一棟多樓層辦公大樓。整棟大樓就是 VPC，每一層樓就是一個子網。開發者的 VPC 安全觀念是關於每扇辦公室門口的保全（安全群組）和私用電梯（VPC Endpoint）——後者讓你不出大樓就能直達安全的服務專區。

每扇辦公室門都有一個拿著個人名單的門衛——那就是安全群組。門衛是有狀態的：如果門衛讓外送員進來，門衛會自動記住這個人，讓他拿著空箱子走出去。忘記面孔的警衛（無狀態，像 NACL）則會在外送員出門時攔住他，要他再次證明身分。開發者只負責設定門衛；維運團隊負責設定樓層閘口的無狀態警衛。

從你辦公室直通 AWS 服務專區的私用電梯就是 VPC Endpoint。分兩種：只進出 S3 和 DynamoDB 的貨運電梯，免費（Gateway Endpoint）；以及能抵達服務專區任何辦公室的普通電梯，按小時計費加每位乘客費用（由 AWS PrivateLink 驅動的 Interface Endpoint）。少了這些電梯，員工就得走出正門、穿越馬路到公車總站（NAT Gateway）、坐車繞一大圈再回來——更慢、也更貴。

VPC 內的 Lambda 函式是 AWS 在你樓層幫你設置的臨時工作桌。早年 AWS 每來一位臨時工就得租一張新桌子（每個並行單位一個 ENI，冷啟動很慢）。自 2019 年起，AWS 改用 Hyperplane ENI，也就是共享的熱桌池——新來的臨時工坐到已經備妥的桌子，立刻開始工作。這正是開發者 VPC 安全觀念所仰賴的冷啟動改善。

類比二：有供應商通行證的餐廳廚房

大型餐廳有一個中央廚房（應用層）、一個食材儲藏室（RDS）、一個香料架（ElastiCache），以及一面供應商牆（S3、DynamoDB、Secrets Manager 等 AWS 服務）。開發者的 VPC 安全觀念在於哪些員工可以去哪裡，以及食材如何進入廚房。

每個工作站都有顏色識別的供應商通行證——那就是安全群組。食材儲藏室只對持有 app-tier-sg 通行證的員工開放；應用層門衛只接受持有 web-tier-sg 通行證的員工下單。這條通行證鏈就是安全群組自我引用，是微服務串接最乾淨的做法，因為不需要硬編碼 IP。容器重啟後 IP 改變，通行證（安全群組）依然有效，鏈結依然運作。

通往街道的裝卸區門就是 NAT Gateway——員工可以走出去取貨，但外人無法走進來。通往 AWS 供應商牆的內部氣動管道就是 VPC Endpoint——廚師把訂單射向 Secrets Manager，密封膠囊帶著食材回來，沒有任何人離開廚房。

Lambda 函式（自由接案的餐廳廚師）進入廚房工作時，AWS 不會每次都重新搭建工作台——廚師拿的是預先備好的共享刀架（Hyperplane ENI）。如果廚師要出去拿餐巾紙（呼叫 Secrets Manager），應該走氣動管道，而不是跑到裝卸區——這就是開發者 VPC 安全觀念中 VPC Endpoint 對比 NAT Gateway 的選擇。

類比三：有空側走廊的機場

一座機場（你的 VPC）有候機廳（子網），每個候機廳對應一個特定的登機門區（AZ）。旅客（封包）需要通行證才能進入每個登機門（安全群組），而整座機場外圍有柵欄（NACL）把守，只有當有人試圖翻越圍欄而非走正門時，柵欄才會發揮作用。

空側走廊連接所有登機門，通往 AWS API 所在的安全供應商區。通往免稅大賣場（S3/DynamoDB）的走廊免費——那就是 Gateway Endpoint。通往各精品小店（Secrets Manager、KMS、SQS）的走廊按每小時每個候機廳收取通行費，加上每位旅客的費用——那就是 Interface Endpoint。少了這些空側走廊，旅客就得**離開安全區、出到陸側、攔計程車（NAT Gateway）**再重新過安檢進來。

Fargate 上的 ECS 任務像是包機，停靠在自己的專屬登機門——在 awsvpc 網路模式下，每個任務有自己的 ENI、自己的 IP 和自己的登機門通行證（安全群組）。Lambda 函式則像是共用廊橋協議，AWS 預先備妥空橋（Hyperplane ENI），讓登機作業迅速完成。

安全群組 — 開發者的第一道防線

安全群組是開發者 VPC 安全的起點，也是大多數 DVA-C02 題目的所在。安全群組是有狀態、ENI 層級的虛擬防火牆，開發者無時無刻都在設定它——在 Lambda、ECS 任務定義、RDS 執行個體、ElastiCache、負載平衡器上都要設定。

有狀態行為，以及開發者為何喜歡它

安全群組是有狀態的。如果你在 db-sg 上允許來自 lambda-sg 的 TCP 5432 入站流量，PostgreSQL 回給 Lambda 的回覆封包就會自動放行。你不需要在 db-sg 上寫出站規則，也不需要在 lambda-sg 上寫入站規則給回覆用。這種有狀態行為是開發者 VPC 安全感覺比原始防火牆管理更簡單的最大原因——狀態機幫你處理了回覆邏輯。

對照 NACL（下節說明）：NACL 是無狀態的，所以你必須在 DB 子網明確允許出站暫時埠（1024–65535），並在 Lambda 子網允許入站暫時埠，才能讓回覆封包回到來源。開發者幾乎從不需要想這件事，因為安全群組已經處理好了。

僅允許，無拒絕規則

安全群組只支援允許規則——你無法寫「拒絕 IP 10.0.5.0/24」。如果需要封鎖特定來源，要麼收緊允許規則，要麼將拒絕推到 NACL 層處理。對於絕大多數開發者 VPC 安全情境，僅允許已經足夠，因為你表達的是正向的應用意圖（「應用層在 5432 埠呼叫資料層」）。

來源引用 — 自我引用與鏈結模式

開發者 VPC 安全中最強大的功能，是讓安全群組規則的來源或目的地引用另一個安全群組。你不需要硬編碼 IP；你只需說「允許任何標記了安全群組 app-tier-sg 的 ENI 發起 TCP 5432 入站」。當應用層擴展、重新取得 IP 或重新部署後，規則依然有效。

自我引用（安全群組允許自己的 sg-id 作為來源）是同一層服務互相通訊的標準模式——同一服務中的 ECS 任務互相溝通、ElastiCache 叢集節點互相溝通、Redis Sentinel 節點互傳 gossip 訊息。開發者 VPC 安全涵蓋這個模式，因為自我引用的安全群組是「任何持有此 SG 的執行個體能與其他持有此 SG 的執行個體通訊」唯一正確的做法——不需要硬編碼 VPC CIDR（那樣會過度授權）。

預設出站與預設入站

全新的安全群組有沒有入站規則（什麼都不允許進入）和一條 0.0.0.0/0 全放行出站規則（什麼都允許出去）。開發者常忘記預設出站是全開的——如果你需要限制出口（例如合規要求「只能呼叫 api.stripe.com」），必須替換預設出站規則，改成更窄的規則。

開發者實際上會碰到的規則與安全群組數量限制

• 每個 ENI 最多 5 個安全群組（可申請增加到 16 個）。
• 每個安全群組最多 60 條入站規則與 60 條出站規則（申請提升上限後最多 1000 條）。
• 每個區域最多 10,000 個安全群組（軟性限制）。

安全群組鏈結範例 — Lambda 到 RDS 再到 ElastiCache

lambda-sg:
  inbound: （無——Lambda 是被呼叫的，不是被直接連接的）
  outbound: allow-all（預設）

db-sg（掛載到 RDS）：
  inbound: TCP 5432 from lambda-sg
  outbound: allow-all（預設）

cache-sg（掛載到 ElastiCache Redis）：
  inbound: TCP 6379 from lambda-sg
  outbound: allow-all（預設）

這就是一個從 RDS 讀取並快取到 ElastiCache 的 Lambda 函式的完整安全設定。乾淨、引用穩定、通過資安審查。開發者 VPC 安全對這個模式給予充分的回報。

NACL — 開發者需要知道的（剛好夠用就好）

開發者在 DVA-C02 上幾乎不會設定 NACL，但考試期望你能辨識出問題是出在 NACL 還是安全群組。這一節保持簡短精準。

無狀態、子網層級、有編號

NACL 位於子網邊界，對每一個進出的封包獨立評估。因為它是無狀態的，你必須同時寫入站和出站規則。因為它是有編號的，評估從最小規則編號開始往上，遇到第一個符合就停止——不論符合的是允許還是拒絕。

預設 NACL vs 自訂 NACL

• 預設 NACL：雙向允許所有流量。大多數 VPC 使用此設定。
• 自訂 NACL：拒絕所有流量直到你加入規則。除非要實作子網層級的護欄，否則幾乎不需要自訂 NACL。

何時開發者 VPC 安全會將問題歸咎於 NACL

大多數時候，開發者 VPC 安全中的連線失敗是安全群組問題，而非 NACL 問題。但如果考題說：

• 入站規則看起來沒問題但連線仍失敗 — 懷疑 NACL 缺少暫時埠出站規則（1024–65535）。
• 從一個子網到另一個子網的封包被丟棄 — 懷疑目的地子網的入站方向 NACL。

安全群組 vs NACL 速查表

VPC Endpoint — 私下呼叫 AWS API

這是開發者 DVA-C02 VPC 安全中價值最高的一節。預期至少會有一題考 Gateway vs Interface Endpoint 的差異，以及至少一題考「我的 Lambda 如何在不走網際網路的情況下連到 Secrets Manager」。

開發者為何在意

當你的 Lambda 函式呼叫 secretsmanager.us-east-1.amazonaws.com，它呼叫的是一個公開的 AWS 端點。從私有子網中的 VPC 掛載 Lambda，這個公開端點只有在有通往網際網路的路徑時才能連到——要麼透過 NAT Gateway（按每 GB 計費）、要麼透過位於 VPC 內的 Interface Endpoint（也要付費，但在大量使用時更便宜，且流量不離開 AWS 的網路）。開發者 VPC 安全主要就是這些路徑之間的決策矩陣。

Gateway Endpoint — 免費，僅支援 S3 和 DynamoDB

Gateway Endpoint 是路由表中的一個目標。你為 Amazon S3 或 Amazon DynamoDB 建立一個，AWS 就會在你選定的路由表中插入一條前綴清單路由，之後流往這些服務的流量就會透過端點離開子網，而不是流向網際網路。

開發者必須知道的 Gateway Endpoint 特性：

• 支援的服務：只有 Amazon S3 和 Amazon DynamoDB。
• 免費。 無小時費、無每 GB 費用。
• 基於路由表。 程式碼不需要修改；SDK 繼續呼叫公開端點主機名稱，DNS 正常解析，但封包走私有路由。
• VPC 範疇。 不支援跨區域、不支援跨帳號。
• 大幅優化成本。 如果你的 NAT Gateway 帳單主要由 S3 流量貢獻，新增一個 Gateway Endpoint 可以立刻將這部分費用歸零。

Interface Endpoint — AWS PrivateLink，其餘所有服務

Interface Endpoint 是一個置於子網中、IP 來自子網 CIDR 的 ENI，由 AWS PrivateLink 驅動。大多數 AWS 服務都支援 Interface Endpoint，包括：

• AWS Secrets Manager
• AWS Systems Manager（Parameter Store）
• AWS KMS
• Amazon SQS
• Amazon SNS
• AWS Step Functions
• Amazon ECR（API + Docker）
• Amazon CloudWatch Logs
• AWS Lambda（私下呼叫其他 Lambda）
• Amazon API Gateway（私有 API）
• Amazon EventBridge

開發者必須知道的 Interface Endpoint 特性：

• 按每個 AZ 每小時計費，加每 GB 處理費。 每個 AZ 的小時費加起來不少，因此對於小型工作負載，只選你實際使用的 AZ。
• 啟用私有 DNS。 勾選「啟用 DNS 名稱」後，AWS 會在你的 VPC 內覆蓋服務公開主機名稱的 DNS 解析，讓 SDK 程式碼不需要修改。
• 端點 ENI 上有安全群組。 是的，端點 ENI 本身有安全群組。它必須允許來自應用程式安全群組的 HTTPS 443 入站流量。
• 端點策略。 一份類似資源策略的 IAM 文件，限定哪些操作可以通過此端點（例如「只允許 secretsmanager:GetSecretValue，其他都不行」）。

Gateway vs Interface Endpoint 決策表

DVA-C02 常考的成本範例

Lambda 函式每天從私有子網呼叫 AWS Secrets Manager 100 萬次。沒有 Interface Endpoint 時，每次呼叫都經過 NAT Gateway：你需要支付 NAT Gateway 小時費加每 GB 資料處理費。有了 Interface Endpoint，你支付端點每 AZ 小時費加每 GB 資料處理費，而且流量從不離開 AWS 的網路。在中等流量規模下，Interface Endpoint 在成本和延遲上都勝出——而且消除了對 NAT Gateway 的強硬依賴，後者是單點故障設計上的隱憂。

Lambda 在 VPC 內 — ENI、Hyperplane 與冷啟動

這是 DVA-C02 上最常考的開發者 VPC 安全問題：什麼時候該把 Lambda 函式放進 VPC、代價是什麼，以及為什麼冷啟動突然變慢了。

預設：Lambda 不在你的 VPC 裡

預設情況下，Lambda 函式執行在 AWS 自己的服務 VPC 中，而非你的 VPC。它開箱即有網際網路存取，但無法存取你 VPC 中的私有資源（RDS、ElastiCache、私有 EC2 執行個體、內部 ALB）。如果 Lambda 需要與上述任何資源溝通，你就要將函式掛載到你的 VPC。

將 Lambda 掛載到 VPC

設定 Lambda 函式的 VPC 設定時，你要選擇：

• 一個或多個私有子網（選至少兩個 AZ 中的子網以確保高可用）。
• 一個或多個用於 Lambda ENI 的安全群組。

Lambda 接著會代你在這些子網中放置 ENI，讓函式能進入 VPC。

Hyperplane ENI — 2019 年解決冷啟動的關鍵

2019 年以前，AWS Lambda 在 VPC 掛載函式擴展時，會為每個並行單位配置一個 ENI。ENI 建立需要 10–30 秒，導致冷啟動受到嚴重懲罰——首次呼叫一個擴展中的並行槽時，出現 15 秒的尖峰並非罕見。

2019 年 AWS 引入了 Hyperplane ENI：一個由多個執行環境共用的共享艦隊級 ENI。Hyperplane ENI 預先非同步配置，並在許多 Lambda 並行單位之間攤銷。對開發者 VPC 安全的影響：

• 將 Lambda 掛載到 VPC，不再造成明顯的冷啟動懲罰，與非 VPC Lambda 相比冷啟動時間相當。
• ENI 建立仍然在函式層級發生——在設定期間和擴展邊界時，但執行時間的 ENI 掛載現在實際上是零成本的。
• 子網的 IP 位址消耗更少，因為 ENI 是共享的。你不再需要為了容納 Lambda 並行而分配龐大的 /20 子網。

對於 DVA-C02：若題目問到 Lambda 在 VPC 內的歷史冷啟動痛點，正確答案引用 Hyperplane ENI 作為解決方案。若問到目前的冷啟動緩解方式，答案是預配置並行加上程式碼層級的優化，而且 VPC 掛載通常不再是主要問題。

VPC 掛載的 Lambda 呼叫 AWS API

Lambda 一旦在你的 VPC 內，就失去預設的網際網路存取。如果函式需要呼叫 AWS Secrets Manager 或 AWS KMS，你的選項是：

1. 為 Secrets Manager、KMS 及函式呼叫的任何其他 AWS 服務新增 Interface Endpoint。Lambda 透過私有 IP 存取端點。無需 NAT、不走網際網路。
2. 將 0.0.0.0/0 路由到公有子網中的 NAT Gateway。Lambda 從 AWS 網路透過網際網路存取公開 AWS 端點。可行，但按每 GB 計費。

開發者 VPC 安全在 DVA-C02 上幾乎總是偏好選項一：為 Lambda 依賴的 AWS 服務建立 Interface Endpoint。NAT Gateway 路由適合偶一為之的外部 HTTPS API 呼叫（例如 Stripe webhook 回呼），但用於 AWS API 流量則相當浪費。

Lambda VPC 檢核清單

• 選至少兩個不同 AZ 的私有子網以確保高可用。
• 掛載一個安全群組，不需要入站規則（Lambda 由服務呼叫，不是直接被連接）；出站預設全放行。
• 在目標的安全群組入站規則中允許 Lambda SG 作為來源（例如 db-sg 入站 TCP 5432 允許 lambda-sg）。
• 對於 AWS API 呼叫，為函式使用的特定服務新增 Interface Endpoint。避免在大規模情境下為 AWS API 流量使用 NAT Gateway。
• 對於公開網際網路呼叫（Stripe、Twilio 等），將 0.0.0.0/0 路由到公有子網的 NAT Gateway。

Fargate 網路 — awsvpc 模式與任務 ENI

Fargate（以及 EC2 上使用 awsvpc 模式的 ECS）與傳統 EC2 上的 ECS 行為不同。每個任務有自己的 ENI、自己的私有 IP 和自己的安全群組。DVA-C02 測驗這一點，因為它改變了你串接安全群組和消耗 IP 的方式。

awsvpc 讓每個任務擁有自己的 ENI

在 awsvpc 網路模式下：

• 每個 ECS 任務獲得一個專用的 ENI，掛載到你在任務定義/服務設定中選擇的子網。
• 每個任務有自己的私有 IP，來自該子網的 CIDR。
• 每個任務攜帶自己的安全群組，與 EC2 主機或 Fargate 基礎架構分開。

對比舊版 bridge 模式，許多容器共用 EC2 主機的 ENI 和埠對應。awsvpc 更簡單、更安全，並且是 Fargate 所必需的。在 DVA-C02 上，除非題目明確說明，否則假設使用 awsvpc。

對開發者 VPC 安全的影響

• 每個任務的安全群組細粒度。 若你在同一個叢集中執行三個服務，每個服務可以有自己的安全群組。orders-sg → payments-sg 這樣的鏈結輕鬆實現。
• IP 消耗與任務數量線性相關。 執行 100 個任務的服務會從子網消耗 100 個 IP。請相應調整子網大小（/24 提供 251 個可用 IP，扣除 AWS 保留的 5 個）。
• Fargate 主機模型中，每個任務不會有獨立的 ENI。 這是歷史上的混淆——每個任務有一個 ENI，Fargate 主機的抽象對你隱藏了。考試考的重點是任務本身是網路單位，而非容器執行個體。
• AWS API 呼叫的任務角色。 每個任務承擔一個 IAM 任務角色（與用於拉取映像和推送日誌的 ECS 任務執行角色不同）。任務角色決定了應用程式碼可以呼叫哪些 AWS API。

Fargate 私下存取 AWS API

與 Lambda 相同的模式：

• S3 或 DynamoDB → Gateway Endpoint，免費。
• 任何其他 AWS 服務 → Interface Endpoint，按 AZ 小時費加每 GB 費用。
• 從 ECR 拉取映像 → 為 ecr.api、ecr.dkr 建立 Interface Endpoint，以及 S3（Gateway Endpoint），因為 ECR 將層存在 S3 中。
• 寫入日誌到 CloudWatch Logs → 若想避免走 NAT 路徑，為 logs 建立 Interface Endpoint。

透過 AWS Cloud Map 與私有託管區域進行 ECS 服務探索

服務會不斷啟動與消失。天真的設計直接硬編碼 IP，一旦 ECS 替換任務就會出問題。開發者 VPC 安全要求你了解 ECS 如何解決這個問題。

AWS Cloud Map + Route 53 私有託管區域

ECS 整合 AWS Cloud Map，自動註冊和取消註冊服務執行個體。Cloud Map 可以用以下方式為服務提供支援：

• 範疇在你 VPC 的 Route 53 私有託管區域中的 DNS A 記錄項目。
• 支援埠感知探索的 SRV 記錄。
• 透過 DiscoverInstances API 進行基於 API 的探索，適用於更進階的使用案例。

當你在 ECS 服務上設定 serviceRegistries，Cloud Map 會建立一個類似 orders.internal. 的項目，A 記錄指向每個目前任務 ENI 的 IP。客戶端只需對 orders.internal. 做 DNS 查詢，並在目前任務 IP 之間輪詢。

為何這對開發者 VPC 安全重要

• 不硬編碼 IP。 程式碼從環境變數讀取主機名稱，DNS 處理剩下的事。
• 安全群組仍然把關流量。 DNS 探索告知客戶端連接到哪裡；目標任務上的安全群組決定是否接受連線。
• 僅適用於 awsvpc 模式，因為每個任務需要自己的 IP 才能有 A 記錄。
• 私有託管區域範疇設定。 私有託管區域與一個或多個 VPC 關聯；Cloud Map 項目只能從這些 VPC 內部解析。

替代方案：ALB 加路徑或主機名稱路由

對於 HTTP 服務，在每個服務前面放一個內部 Application Load Balancer，並使用主機名稱或路徑路由，是更常見的模式。Cloud Map 更適合非 HTTP 協定（使用自訂埠的 gRPC、原始 TCP 服務），以及希望在不使用中間設備的情況下進行客戶端負載平衡的場景。

私有子網對外流量 — NAT Gateway vs Interface Endpoint

私有子網依定義沒有通往 Internet Gateway 的預設路由。開發者在實務上有兩個對外流量選項，開發者 VPC 安全考驗你何時選哪個。

NAT Gateway — 可連任何目的地，按每 GB 計費

公有子網中的 NAT Gateway 讓私有子網的資源能夠對外存取網際網路和公開 AWS 服務端點。在以下情況選擇它：

• 你的程式碼透過公開網際網路呼叫第三方 API（Stripe、SendGrid、GitHub 等）。
• 你呼叫數量龐大的 AWS 服務，為每個服務新增 Interface Endpoint 反而比走 NAT 更貴。
• 你偏好運維簡便，且 NAT 帳單在可接受範圍內。

開發者常見的坑：

• 每個 AZ 需要一個 NAT Gateway 以確保彈性。單一 NAT Gateway 是跨 AZ 的單點故障。
• 按每 GB 處理費計費——S3 或 DynamoDB 流量流過 NAT 是浪費，用免費的 Gateway Endpoint 就夠了。
• 每個 NAT Gateway 按小時計費。

Interface Endpoint — 私有，對 AWS API 而言規模愈大愈划算

當你的 Lambda 或 Fargate 任務主要與 AWS API 溝通，Interface Endpoint 幾乎總是正確答案：

• 流量從不離開 AWS 的網路。
• 不依賴 NAT Gateway——少一個單點故障。
• 在持續流量下，比 NAT Gateway 資料處理費更便宜。
• 端點策略提供額外的 IAM 風格護欄。

組合模式 — AWS API 用 Endpoint，外部流量用 NAT

生產環境的開發者 VPC 安全標準模式：

1. Gateway Endpoint 用於 Amazon S3 和 Amazon DynamoDB（免費，輕鬆得利）。
2. Interface Endpoint 用於應用程式大量呼叫的特定 AWS 服務（Secrets Manager、KMS、SQS、SNS、ECR、CloudWatch Logs）。
3. NAT Gateway 僅用於連到第三方 API 的公開網際網路出口。

這個組合將 NAT 成本和 NAT 依賴降到最低，同時維持良好的開發者體驗。

VPC Endpoint 的執行期相依性

一旦採用 VPC Endpoint，應用程式就會產生新的執行期相依性，而開發者 VPC 安全的考試經常探測這一點。

端點 ENI 上的安全群組陷阱

Interface Endpoint 有自己的 ENI 和自己的安全群組。如果你的 Lambda 或任務無法連到端點，第一個懷疑對象是：

• 端點安全群組缺少來自應用程式安全群組的 HTTPS 443 入站規則。
• 應用程式安全群組出站規則受限，沒有允許 HTTPS 443 流向端點的私有 IP 或端點的安全群組。

兩個安全群組都必須放行流量。由於安全群組預設出站全開、入站全關，通常缺少的是端點上的入站規則。

DNS — 啟用私有 DNS

建立 Interface Endpoint 時，請確保啟用私有 DNS已開啟（預設如此）。這樣會在你的 VPC 內覆蓋 AWS 服務公開主機名稱的 DNS 解析（例如 secretsmanager.us-east-1.amazonaws.com），讓名稱解析到端點的私有 IP。若未啟用，你必須讓 SDK 指向自訂端點 URL，這樣很脆弱。

私有 DNS 要能運作，VPC 必須將 enableDnsSupport 和 enableDnsHostnames 都設為 true。這兩個值在新 VPC 上預設為 true，但有時在自訂設定中會被停用。

端點策略 — 類 IAM 的允許清單

每個 VPC Endpoint 都有一個端點策略（一份資源型策略文件）。預設允許所有操作；在零信任的開發者 VPC 安全設計中，你可以縮小範疇：

{
  "Statement": [{
    "Effect": "Allow",
    "Principal": "*",
    "Action": ["secretsmanager:GetSecretValue"],
    "Resource": "arn:aws:secretsmanager:us-east-1:111122223333:secret:prod/app-*"
  }]
}

這條策略表示「只有對 prod/app-* 命名空間下 secret 的 GetSecretValue 操作允許通過此端點。」設定錯誤的 Lambda 嘗試讀取其他 secret 時，會在端點被拒絕。

區域不符

Interface Endpoint 是區域性的。us-east-1 的端點不會服務發往 us-west-2 的請求。如果你的程式碼明確建構跨區域端點 URL，VPC Endpoint 不會攔截這些請求。對於跨區域私有存取，你需要不同的模式（Transit Gateway 加跨區域端點，或跨區域 PrivateLink 設定）。

跨 VPC 存取 — VPC Peering vs PrivateLink

開發者經常需要讓一個 VPC 中的工作負載呼叫另一個 VPC 中的服務——共享服務帳號、合作夥伴 SaaS、其他微服務團隊的 VPC。DVA-C02 開發者 VPC 安全測驗 VPC Peering 與 AWS PrivateLink 之間的選擇。

VPC Peering

VPC 對等連線在網路層連接兩個 VPC。特性：

• 非遞移。 A 對等到 B，B 對等到 C，並不代表 A 能存取 C。
• CIDR 不能重疊。
• 雙方都要更新路由表，加入對方的 CIDR。
• 安全群組可以在同一個區域內引用對等的安全群組。
• 無小時費；你只需支付資料傳輸費用。
• 所有埠、所有協定——一旦路由建立，兩個 VPC 可以像同一個 VPC 一樣互相定址。

何時選擇對等連線：兩個受信任的 VPC 位於同一帳號或同一組織內，預期有廣泛的任意對任意連線，且 CIDR 已規劃好。

AWS PrivateLink

AWS PrivateLink 透過消費者 VPC 中的 Interface Endpoint 暴露一個服務。特性：

• 單向。 消費者發起；提供者不會進入消費者的 VPC。
• 無 CIDR 重疊限制。 每一方只看到自己子網中端點的私有 IP。
• 範疇限定在特定服務（提供者 VPC 中的 NLB），而非整個 VPC。
• 一對多。 一個服務可以被多個客戶 VPC 消費。
• 消費者端按每個 AZ 每小時計費，加每 GB 費用。
• SaaS 友善。 大多數涉及 SaaS 供應商的開發者 VPC 安全情境都隱含 PrivateLink。

何時選擇 PrivateLink：你要將一個特定服務（一個 API、一個資料庫代理）暴露給許多消費者；CIDR 可能重疊；你想要最小權限的連線，而非完整的網路合併。

決策表

有狀態的回覆埠與暫時埠範圍

開發者 VPC 安全大量依賴安全群組的有狀態特性，因此值得精確說明「有狀態」在實務上的含義。

連線追蹤的運作方式

當受 client-sg 保護的 ENI 上的客戶端，對 server-sg 保護的伺服器發起 TCP 連線時：

1. 客戶端從 client-ip:50123（作業系統暫時埠池中的來源埠）發送 SYN 到 server-ip:443。
2. server-sg 必須有入站規則允許來自 client-sg 的 TCP 443。
3. server-sg 是有狀態的，因此反向的 5 元組（server-ip:443 → client-ip:50123）自動獲准回傳。
4. client-sg 在出站方向也是有狀態的——SYN-ACK 回覆無需特定的入站規則就能回來。

開發者無需為回覆路徑設定任何東西。這是安全群組與 NACL 在開發者 VPC 安全中的根本差異。

無狀態在哪裡出問題：NACL

如果流量同時跨越 NACL，請記住：

• 伺服器子網的出站 NACL 必須允許 TCP 1024–65535（暫時回覆範圍）回到客戶端。
• 客戶端子網的入站 NACL 必須允許來自伺服器的 TCP 1024–65535。

若開發者 VPC 安全情境中有 NACL，且應用程式「逾時」但安全群組看起來沒問題，幾乎都是這個原因。

暫時埠範圍細節

• Linux 通常使用 32768–60999（核心預設值）。
• Windows（較新版本） 使用 49152–65535。
• AWS 對 NACL 的建議是允許 1024–65535 以涵蓋兩者。

開發者 VPC 安全的關鍵數字與必記事實

DVA-C02 常見考試陷阱 — 開發者 VPC 安全

預期 DVA-C02 上至少會出現以下其中幾個。在看選項之前先學會辨識模式。

陷阱一：VPC 內的 Lambda 無法連到 Secrets Manager

題目描述一個剛掛載到 VPC 的 Lambda 函式，現在無法呼叫 AWS Secrets Manager。直覺反應是「新增 NAT Gateway」。更好的答案是「為 Secrets Manager 新增 Interface Endpoint」——在持續流量下更便宜、流量留在 AWS 網路內、消除 NAT 依賴。NAT Gateway 的答案也可接受但次優，DVA-C02 的干擾選項通常兩者都包含。

陷阱二：安全群組自我引用的混淆

情境中有 ElastiCache Redis 節點需要彼此通訊。錯誤修復是「在 6379 埠允許 VPC CIDR」。正確修復是快取安全群組引用自身作為叢集 gossip 埠的來源。自我引用是開發者 VPC 安全的慣用模式。

陷阱三：Gateway vs Interface Endpoint 選擇題

一題說「團隊希望透過私下連到 DynamoDB 來節省 NAT Gateway 費用」。答案：Gateway Endpoint（免費）。接著同一張考卷另一題：「團隊希望透過私下連到 Secrets Manager 來節省 NAT Gateway 費用」。答案：Interface Endpoint（因為 Gateway 不支援 Secrets Manager）。把這兩個服務（S3、DynamoDB）背熟。

陷阱四：Lambda VPC 掛載被歸咎於冷啟動

有干擾選項建議「把 Lambda 從 VPC 移除以修復冷啟動」。Hyperplane（2019 年）之後，VPC 掛載已不是主要的冷啟動原因。正確修復通常是預配置並行、更小的部署套件，或將昂貴的初始化移到 handler 之外。開發者 VPC 安全不再因為掛載 VPC 就要承擔冷啟動代價。

陷阱五：Fargate 任務角色與執行角色搞混

在 awsvpc 模式中，每個任務有兩個 IAM 角色：任務角色（應用程式碼用來呼叫 AWS API 的角色）和任務執行角色（Fargate 基礎架構用來從 ECR 拉取映像和推送日誌到 CloudWatch 的角色）。如果任務無法啟動，懷疑執行角色；如果任務執行但 GetSecretValue 失敗，懷疑任務角色。開發者 VPC 安全連同網路層一起測驗這個區分。

陷阱六：對等連線是非遞移的

三個 VPC 的中樞輻射型對等連線設計，不會讓輻射端之間互相連通。對於 DVA-C02 開發者 VPC 安全，答案要麼是 Transit Gateway（廣泛連線），要麼是 PrivateLink（單一暴露服務）。

陷阱七：直接允許 VPC CIDR 而非引用安全群組

有些干擾選項建議「在 db-sg 的 5432 埠允許 VPC CIDR」來解決 Lambda 到 RDS 的問題。這樣雖然可行，但過度授權。正確答案永遠是「允許 lambda-sg 作為來源」——開發者 VPC 安全獎勵最小權限。

陷阱八：Interface Endpoint 上缺少啟用私有 DNS

Lambda 已掛載到 VPC，Secrets Manager 的 Interface Endpoint 存在，但 SDK 呼叫仍然失敗。懷疑：端點上的啟用私有 DNS 未開啟，因此 SDK 的主機名稱仍解析到公開端點，但 Lambda 沒有網際網路路徑無法存取。開啟私有 DNS 即可修復。

開發者 VPC 安全如何連結到其他 DVA-C02 主題

開發者 VPC 安全在大多數其他 DVA-C02 主題中都是基礎。以下說明每個下游主題如何建立在本筆記之上：

• iam-roles-policies：Lambda 執行角色和 Fargate 任務角色由 VPC 掛載的運算資源承擔；角色控制 AWS API 存取，VPC Endpoint 控制網路路徑。
• lambda-fundamentals：當函式需要存取私有資源時，本筆記中的函式物件 VPC 設定和 Hyperplane ENI 機制直接適用。
• lambda-performance-optimization：冷啟動緩解有時涉及 VPC 掛載；Hyperplane ENI 的討論在此。
• kms-encryption：KMS 在應用程式位於私有子網時，通常透過 Interface Endpoint 連接。
• secrets-manager-parameter-store：Secrets Manager 和 SSM Parameter Store 都常透過 Interface Endpoint 從 VPC 掛載的運算資源存取。
• container-deployment：awsvpc 模式中的 ECS 任務網路在此涵蓋；從私有子網拉取 ECR 映像使用 ecr.api 和 ecr.dkr 的 Interface Endpoint，加上 S3 的 Gateway Endpoint。
• xray-and-debugging：X-Ray 追蹤顯示開發者 VPC 安全鏈中哪個環節卡住了——安全群組封鎖、DNS 還是端點——而 X-Ray 的 Interface Endpoint 保持追蹤資料的私密性。

以上所有下游主題都假設本筆記中的基礎知識。有疑問時，回到這裡。

FAQ — 開發者 VPC 安全常見問題

Q1：2026 年把 Lambda 函式放進 VPC 還會造成緩慢的冷啟動嗎？

不會，不像以前那樣了。2019 年以前，將 Lambda 函式掛載到 VPC 會在大規模擴展時的每次冷啟動加上 10–30 秒的 ENI 配置懲罰。自 2019 年起，AWS Lambda 使用 Hyperplane ENI——一種共享、預配置的艦隊級網路介面——有效消除了 VPC 掛載的冷啟動懲罰。VPC 掛載的 Lambda 現在冷啟動時間與非 VPC Lambda 相當。剩餘的冷啟動因素是 init 程式碼、部署套件大小、執行環境選擇和預配置並行。在 DVA-C02 上，若干擾選項說「把 Lambda 從 VPC 移除以修復冷啟動」，通常是錯的——修復 init 程式碼或新增預配置並行才對。

Q2：我的 Lambda 應該何時透過 Interface Endpoint 而非 NAT Gateway 呼叫 AWS 服務？

幾乎都是，如果呼叫是持續性的。Interface Endpoint 將流量保持在 AWS 網路內，消除 NAT Gateway 作為單點故障，且在持續流量下每 GB 比 NAT 資料處理費更便宜。典型的開發者 VPC 安全模式是：Gateway Endpoint 用於 S3 和 DynamoDB（免費），Interface Endpoint 用於 Secrets Manager、KMS、SQS、SNS、ECR、CloudWatch Logs 以及函式大量呼叫的其他 AWS API，NAT Gateway 僅用於對第三方 API（Stripe、Twilio、GitHub）的外部網際網路呼叫。對於只呼叫 AWS API 的函式，通常可以完全移除 NAT Gateway。

Q3：讓 ECS 任務 A 安全地與 ECS 任務 B 溝通的正確方式是什麼？

使用搭配 awsvpc 網路模式的安全群組鏈結。任務 A 使用 sg-a 執行，任務 B 使用 sg-b 執行。在 sg-b 上新增一條入站規則 允許 TCP <埠> 來自 sg-a。就這樣。為了讓任務 A 知道任務 B 在哪裡，在 AWS Cloud Map 中使用 Route 53 私有託管區域來登錄任務 B，讓任務 A 能透過 DNS 解析 task-b.internal. 到目前的任務 IP。這個組合——Cloud Map 負責探索、安全群組負責授權——是叢集內服務通訊的開發者 VPC 安全慣用模式。

Q4：端點 ENI 上的安全群組與應用程式上的安全群組有什麼差別？

兩者都必須允許流量通過。應用程式安全群組（在你的 Lambda ENI 或 Fargate 任務 ENI 上）控制到端點的出站流量——其預設的全放行出站規則通常就夠了。端點安全群組（在 Interface Endpoint 的 ENI 上）控制到端點的入站流量——你必須新增一條規則，允許來自應用程式安全群組或 VPC CIDR 的 TCP 443。如果端點安全群組缺少入站規則，SDK 呼叫會因連線錯誤失敗，看起來像是 DNS 或 IAM 問題，但實際上是安全群組問題。在開發者 VPC 安全中，永遠要同時檢查兩個安全群組。

Q5：跨 VPC 存取時，我如何決定使用 VPC Peering 還是 AWS PrivateLink？

當你想要兩個 VPC 之間廣泛的任意對任意網路連線，且你能控制雙方的 CIDR 規劃時，使用 VPC Peering。Peering 免費（僅資料傳輸費），但非遞移且被 CIDR 重疊封鎖。當你想要將一個特定服務（NLB 後面的 API）暴露給多個消費者 VPC、CIDR 重疊可能發生（尤其是跨帳號時），或你是向客戶 VPC 提供服務的 SaaS 供應商時，使用 AWS PrivateLink。PrivateLink 是單向的——消費者連到提供者，反向不行——這通常是安全上的優勢。對於 DVA-C02 開發者 VPC 安全，記住「Peering 合併網路；PrivateLink 暴露服務」。

Q6：為什麼我建了 Interface Endpoint 之後，VPC 掛載的 Lambda 仍然無法解析 secretsmanager.us-east-1.amazonaws.com？

三個可能原因。第一，Interface Endpoint 上的啟用私有 DNS 未開啟——開啟後 SDK 預設主機名稱才會解析到端點的私有 IP。第二，VPC 的 DNS 設定（enableDnsSupport 和 enableDnsHostnames）必須都設為 true，私有 DNS 才能運作。第三，端點安全群組缺少來自 Lambda 安全群組的 HTTPS 443 入站規則。三個都檢查——在開發者 VPC 安全中，這是最常見的 Interface Endpoint 設定錯誤。

Q7：如果我的私有子網沒有網際網路也沒有 VPC Endpoint，我的程式碼還能呼叫 AWS 服務嗎？

不行。私有子網依定義沒有通往網際網路的預設路由（沒有 0.0.0.0/0 → IGW）。沒有 NAT Gateway 或 Interface Endpoint，就沒有通往 AWS 公開服務端點的路徑。你的 SDK 呼叫會掛著直到設定的逾時，然後失敗。修復方式要麼（a）在公有子網新增 NAT Gateway，並讓私有子網的路由表指向它；要麼（b）為程式碼需要的特定 AWS 服務新增 Interface Endpoint。S3 和 DynamoDB 永遠先新增免費的 Gateway Endpoint。開發者 VPC 安全將此基本連線檢查視為任何情境的第零步。

延伸閱讀

• Security Groups for Your VPC
• Network ACLs for Your VPC
• Gateway VPC Endpoints
• VPC Endpoints and AWS PrivateLink
• Configuring a Lambda Function to Access Resources in a VPC
• Lambda Networking Fundamentals (Hyperplane ENIs)
• ECS awsvpc Network Mode
• ECS Service Discovery via AWS Cloud Map
• VPC Peering Guide
• NAT Gateways
• AWS DVA-C02 Exam Guide (PDF)