上一篇把 Application EC2 放進 Private Subnet，只接受 ALB 轉送的請求，避免它直接暴露在 Internet。

但應用程式除了接收流量，也經常需要主動建立連線，例如：

• 呼叫第三方金流 API
• 下載套件或系統更新
• 從 Amazon S3 讀取檔案
• 從 AWS Secrets Manager 取得資料庫密碼

所以 Private Subnet 並不是「完全不能對外」，而是需要重新思考：

這條 Outbound Traffic 要去哪裡？真的需要經過 Internet 嗎？

這也是 NAT Gateway 與 VPC Endpoint 最重要的差異。

當客戶有這部分的需求時，可以先確認流量目的地，再決定使用哪一條出口，用這個角度去評估架構。

先確認應用程式要連去哪裡

沿用上一篇的訂單網站。

Private App Subnet 中的 Application EC2 現在有三種連線需求：

這三種需求看起來都是 Application EC2 主動發出 HTTPS Request，但目的地不同，因此適合的網路路徑也不一樣。

一般會分成三個類別：

一般 Internet Destination
→ NAT Gateway

S3 / DynamoDB
→ Gateway Endpoint

支援 AWS PrivateLink 的 AWS Service
→ 評估 Interface Endpoint

其中 Secrets Manager 特別使用「評估」，是因為支援 Interface Endpoint，不代表一定需要建立一個。

是否使用 Endpoint，還要一起考慮：

• 是否要求流量走私有路徑
• NAT 是否本來就已經存在
• 流量大小
• Endpoint 成本
• Availability Zone 數量
• 管理複雜度

NAT Gateway：讓 Private Subnet 主動連外

Private Subnet 沒有直接通往 Internet Gateway 的 Route，因此其中的 EC2 無法直接透過 Internet Gateway 與 Internet 通訊。

如果 Private EC2 需要主動存取 Internet，其中一個常見做法就是使用 Public NAT Gateway。

基本架構如下：

Application EC2
Private Subnet
      │
      ▼
Private Route Table
0.0.0.0/0 → NAT Gateway
      │
      ▼
NAT Gateway
Public Subnet
      │
      ▼
Internet Gateway
      │
      ▼
Internet

Private Subnet 的 Route Table 可能是：

其中：

0.0.0.0/0 → NAT Gateway

代表沒有符合更明確 Route 的 IPv4 流量，會送往 NAT Gateway。

Public NAT Gateway 再透過 Internet Gateway 將流量送到 Internet。

這讓 Private Subnet 中的資源可以主動建立對外連線，但 Internet 無法透過 NAT Gateway 任意建立新的連線到 Private EC2。

Public NAT Gateway 為什麼放在 Public Subnet？

Application EC2 在 Private Subnet：

0.0.0.0/0 → NAT Gateway

而 NAT Gateway 所在的 Public Subnet 則需要：

0.0.0.0/0 → Internet Gateway

也就是：

Private Subnet
     │
     ▼
NAT Gateway
     │
     ▼
Public Subnet
     │
     ▼
Internet Gateway

Public NAT Gateway 還會關聯 Elastic IP。

當 Private EC2 透過 Public NAT Gateway 呼叫 Internet 上的 API 時，Internet 端看到的來源 Public IP 會是 NAT Gateway 對應的 Elastic IP。

這在實務上很常用。

例如第三方金流服務要求：

請提供 API 呼叫的來源 IP，加入 Allow List。

就可以提供 NAT Gateway 使用的 Elastic IP：

Application EC2
      │
      ▼
NAT Gateway
Elastic IP
      │
      ▼
Payment API

這樣後端 EC2 即使替換或擴充，也不需要逐台向合作廠商更新來源 IP。

本篇討論的是提供 Internet Outbound 的 Public NAT Gateway。AWS 另外也提供 Private NAT Gateway，可用於私有網路之間的 NAT 情境，但不直接作為 Internet 出口。

NAT 提供出口，但不負責判斷「你該去哪裡」

建立 NAT Gateway 之後，如果 Application EC2 的 Outbound Security Group Rule 允許：

TCP 443
Destination: 0.0.0.0/0

而其他網路條件也允許，那這台 EC2 可以透過 NAT Gateway 建立許多不同的 HTTPS 連線。

NAT Gateway 本身不會判斷：

payment.example.com

是不是公司核准的目的地。

也不會知道：

malicious.example.com

是不是不應該被存取。

所以：

NAT Gateway
≠ Egress Firewall
≠ URL Filter

如果企業有更嚴格的出口需求，例如：

Application 只能連到指定的外部 API Domain。

那還需要進一步評估 Proxy、Firewall 或其他 Egress Filtering 機制。

因此，「Internet 不能主動連進 Private EC2」不代表出口本身已經受到完整限制。

那為什麼存取 S3 不一定要走 NAT？

現在 Application EC2 除了呼叫 Payment API，還需要從 S3 讀取商品圖片。

如果已經有 NAT Gateway，其實可以直接走：

Application EC2
      │
      ▼
NAT Gateway
      │
      ▼
Amazon S3

功能上可以正常運作。

但這裡可以再問一次：

目的地是 Amazon S3，真的需要跟 Internet API 走同一條出口嗎？

答案是不一定。

Amazon S3 支援 Gateway VPC Endpoint，可以讓 VPC 中的 Resource 不需要經過 NAT Gateway 或 Internet Gateway，就能存取 S3。

Gateway Endpoint：讓 S3 流量走另一條路

Gateway Endpoint 目前主要支援：

• Amazon S3
• Amazon DynamoDB

建立 Gateway Endpoint 時，需要指定要關聯的 Route Table。

假設原本 Application Subnet 的 Route Table 是：

建立同 Region 的 S3 Gateway Endpoint 後，會多出類似：

這裡的 Prefix List 可以先理解成由 AWS 維護的一組服務 IP 範圍，不需要自己追蹤 S3 使用哪些 IP。

此時 Application EC2 同時有兩條出口：

S3 Prefix List
→ S3 Gateway Endpoint

0.0.0.0/0
→ NAT Gateway

而 Route Table 會優先選擇更明確的目的地 Route。

因此：

Application EC2
      │
      ├── Amazon S3
      │       ↓
      │ Gateway Endpoint
      │
      └── Third-party API
              ↓
         NAT Gateway

S3 Traffic 符合 AWS-managed Prefix List，因此走 Gateway Endpoint。

第三方 Payment API 不符合 S3 Prefix List，則繼續符合：

0.0.0.0/0 → NAT Gateway

這也是 Day 11「Route Table 決定下一站」觀念的延伸。

NAT Gateway 和 Endpoint 本來就可以同時存在

所以真正的架構通常不是：

NAT Gateway
    VS
VPC Endpoint

而可能是：

                    Application EC2
                          │
             ┌────────────┴────────────┐
             │                         │
             ▼                         ▼
        Amazon S3              Third-party API
             │                         │
             ▼                         ▼
   Gateway Endpoint              NAT Gateway
                                       │
                                       ▼
                               Internet Gateway
                                       │
                                       ▼
                                    Internet

目的地決定出口。

Internet Traffic 才需要送往 Internet。

可以透過 AWS Private Connectivity 存取的服務，則可以依需求使用 Endpoint。

其他 AWS Service 怎麼辦？

Application EC2 可能還需要：

• Secrets Manager
• Systems Manager
• Amazon ECR
• AWS KMS
• CloudWatch
• 其他 AWS Service

這些服務不會全部使用 Gateway Endpoint。

許多支援 AWS PrivateLink 的服務，可以透過另一種類型：

Interface Endpoint

來提供 Private Connectivity。

Interface Endpoint：透過 Private IP 存取服務

建立 Interface Endpoint 時，AWS 會在選定的 Subnet 中建立 Endpoint Network Interface（ENI），並配置 Private IP。

例如 Application EC2 要存取 Secrets Manager：

Application EC2
      │
      │ HTTPS 443
      ▼
Interface Endpoint ENI
Private IP
      │
      ▼
AWS Secrets Manager

與 Gateway Endpoint 不同，它不是單純在 Route Table 中加入 S3 Prefix List Route。

因為 Endpoint 有自己的 ENI，所以也可以關聯 Security Group。

例如：

endpoint-sg

Inbound:
TCP 443
Source: app-sg

代表只有符合 app-sg 的 Application Resource 可以建立 HTTPS Connection 到 Endpoint ENI。

如果 Application Security Group 也另外限制 Outbound，則還需要確認 App 端 Outbound Rule 同樣允許這條 HTTPS 連線。

Gateway Endpoint 和 Interface Endpoint 差在哪？

雖然兩個都叫 VPC Endpoint，但運作方式並不相同。

可以先簡單記成：

Gateway Endpoint
→ Route-based

Interface Endpoint
→ Private IP / ENI-based

Interface Endpoint 為什麼要注意 Private DNS？

假設程式原本使用 AWS SDK 存取 Secrets Manager，對應的 Regional Endpoint 可能是：

secretsmanager.ap-northeast-1.amazonaws.com

如果建立 Interface Endpoint 後，應用程式還必須全部修改成另一個特殊 URL，維護起來會很麻煩。

因此，對 AWS Service 的 Interface Endpoint，通常會搭配 Private DNS。

啟用後，如果 VPC 的 DNS Hostnames 與 DNS Resolution 也已經開啟，原本 AWS Service 的 DNS Name 可以解析至 Interface Endpoint ENI 的 Private IP。

概念上就是：

原本：

secretsmanager.ap-northeast-1.amazonaws.com
                 ↓
          Public Endpoint

建立 Interface Endpoint 並正確設定 Private DNS 後：

secretsmanager.ap-northeast-1.amazonaws.com
                 ↓
         Private IP
                 ↓
       Interface Endpoint

應用程式通常不需要修改原本的 SDK 呼叫方式。

這裡有一個需要確認的點是：

建立了 Interface Endpoint，不代表應用程式就一定已經使用它。

還需要確認 DNS Resolution、Private DNS 與 Application 實際使用的 Endpoint Name。

有 Endpoint，不代表自動取得 AWS 權限

這裡也可以連回前面的 IAM 篇。

VPC Endpoint 解決的是：

封包要走哪一條網路路徑？

IAM 解決的是：

這個身分能不能執行這個操作？

例如：

Application EC2
      │
      ▼
S3 Gateway Endpoint
      │
      ▼
Amazon S3

網路已經可以到 S3。

但如果 EC2 使用的 IAM Role 沒有：

s3:GetObject

仍然無法讀取物件。

因此：

VPC Endpoint
≠ AWS Service Permission

Endpoint Policy 又是什麼？

部分 VPC Endpoint 可以設定 Endpoint Policy，限制哪些 Principal 可以透過這個 Endpoint 對哪些 Resource 執行哪些 Action。

但 Endpoint Policy 是額外的一層控制，不會取代 IAM Policy 或 Resource Policy。

概念上可能同時存在：

IAM Policy
     +
Endpoint Policy
     +
Resource Policy

例如存取 S3 時，還可能受到 Bucket Policy 影響。

這裡也有一個容易忽略的地方。

假設 Endpoint Policy 規定：

只能透過這個 Endpoint 讀取 product-assets Bucket。

不代表 EC2 就一定不能：

EC2
 ↓
NAT Gateway
 ↓
S3 Public Endpoint
 ↓
其他 Bucket

因為 Endpoint Policy 主要控制的是經過該 Endpoint 的請求。

如果企業要求：

這個 Bucket 只能透過指定 VPC Endpoint 存取。

那通常還需要在 Resource Side 搭配 Bucket Policy 等控制，例如限制 aws:SourceVpce。

所以：

Private Path 與 Access Control 仍然要分開思考。

Secrets Manager 到底要走 NAT 還是 Interface Endpoint？

回到文章一開始的第三個需求：

Application EC2
→ Secrets Manager

這裡就沒有像 S3 Gateway Endpoint 那麼直接。

假設系統本來就需要 NAT Gateway 呼叫 Payment API，而且 Secrets Manager Request 很少，也沒有規定 AWS API 必須走 Private Connectivity。

那麼：

Application EC2
      │
      ▼
NAT Gateway
      │
      ▼
Secrets Manager Public Endpoint

可能已經符合需求。

這時只為了少量 Secrets Manager Traffic，再在多個 AZ 建立 Interface Endpoint，不一定比較划算。

但如果企業安全需求明確規定：

AWS Service API 不應依賴 Internet / NAT Path。

或：

Private Workload 不應具備一般 Internet Outbound。

那就可以考慮使用 Interface Endpoint 。

例如：

Application EC2
      │
      ▼
Secrets Manager Interface Endpoint
      │
      ▼
Secrets Manager

因此 Secrets Manager 的答案不是一定使用 NAT，也不是一定建立 Endpoint，而是需要依照 Network Requirement、安全要求、流量與成本一起評估。

NAT Gateway 與 Interface Endpoint 的成本怎麼判斷？

假設公司原本就需要 NAT Gateway：

Third-party API
→ NAT

再考慮是否建立：

Secrets Manager
→ Interface Endpoint

可以從幾個問題判斷：

1. Secrets Manager Traffic 有多少？
2. 是否要求 Private Connectivity？
3. Endpoint 要部署幾個 AZ？
4. 是否希望未來移除 NAT？
5. Application 還有哪些 Internet Dependency？
6. NAT Traffic 中有多少其實是 AWS Service Traffic？

如果 NAT Gateway 大量處理的是支援 Gateway Endpoint 或 Interface Endpoint 的 AWS Service 流量，就可以進一步評估 VPC Endpoint，減少 NAT Gateway 的資料處理成本。

因此，成本評估應該看整體：

Traffic Volume
      +
NAT Usage
      +
Endpoint 數量
      +
Availability Zone 數量
      +
Security Requirement

而不是只比較單一服務的每 GB 價格。

回到這個訂單服務，應該怎麼設計？

在目前需求下：

• 需要呼叫第三方 Payment API
• 經常存取同 Region 的 S3
• 偶爾讀取 Secrets Manager
• Application EC2 不接受 Internet 主動連入

可以先設計成：

                         Application EC2
                          Private Subnet
                                │
            ┌───────────────────┼───────────────────┐
            │                   │                   │
            ▼                   ▼                   ▼
      Amazon S3          Payment API        Secrets Manager
            │                   │                   │
            ▼                   │             先依需求評估
   Gateway Endpoint             │                   │
                                ▼              ┌────┴────┐
                          NAT Gateway          │         │
                                │              NAT    Interface
                                ▼              │      Endpoint
                       Internet Gateway        │
                                │              │
                                ▼              ▼
                             Internet      AWS Service

目前可以採用：

第三方 Payment API

Application EC2
→ NAT Gateway
→ Internet Gateway
→ Payment API

因為目的地是一般 Public Internet Service。

Amazon S3

Application EC2
→ S3 Gateway Endpoint
→ Amazon S3

因為是同 Region S3，可以使用沒有額外 Endpoint 使用費的 Gateway Endpoint。

Secrets Manager

如果沒有強制 Private Connectivity，而且請求量不高，可以先沿用既有 NAT。

如果之後安全要求提高，或希望減少對 NAT Path 的依賴，再建立 Secrets Manager Interface Endpoint。

如果完全不需要對外呢？

前面一直在討論 NAT 與 Endpoint，但實際做架構時，還有第三個答案：

什麼都不要。

例如上一篇的 Database：

PostgreSQL
Private DB Subnet

如果它不需要：

• Internet
• 第三方 API
• S3
• 其他 AWS API

那就沒有必要特地替它配置：

0.0.0.0/0 → NAT

也不需要為了「可能用得到」建立一堆 Interface Endpoint。

可以只保留真正需要的：

Application EC2
      │
      │ TCP 5432
      ▼
PostgreSQL

出口設計時需要注意的幾個重點

NAT Gateway 與 VPC Endpoint 解決的是不同類型的網路需求，因此在設計 Private Subnet 的出口時，不能只看「有沒有 NAT」或「有沒有 Endpoint」，而是要確認每一類流量實際會走哪一條路徑。

Public NAT Gateway 提供 Private Resource 主動存取 Internet 的能力，但不會因此讓 Internet 可以主動建立新的連線到 Private EC2，它主要解決的是 Outbound Connectivity，而不是讓 Private Resource 變成公開服務。

當 NAT Gateway 與 VPC Endpoint 同時存在時，流量也不會全部固定經過 NAT，Route Table 會依照目的地選擇適合的路由，例如同 Region 的 S3 Traffic 可以符合 Gateway Endpoint 的 Prefix List Route，而一般 Internet Traffic 則繼續使用：

0.0.0.0/0 → NAT Gateway

不同類型的 Endpoint 也需要確認不同的設定：

另外，VPC Endpoint 只改變 Network Path，並不會取代原本的 IAM 授權。

即使 EC2 已經可以透過 S3 Gateway Endpoint 抵達 S3，如果 IAM Role 沒有 s3:GetObject，仍然無法讀取物件。

因此在設計時，仍要分開確認：

Network Path
→ 封包能不能到達服務

IAM / Resource Policy
→ 到達服務後，有沒有權限執行操作

同樣地，建立 VPC Endpoint 也不代表 NAT Gateway 一定可以移除。

如果 Application 還需要呼叫第三方 API、下載公開套件，或存取其他沒有 Private Endpoint 的服務，就仍然需要 Internet Outbound Path。

因此，在移除 NAT Gateway 之前，需要先盤點 Application 的所有 External Dependency，而不是只確認目前使用的 AWS Service 是否已經建立 Endpoint。

最終還是回到這篇的核心：

先確認流量的目的地，再決定它應該走 NAT Gateway、VPC Endpoint，還是根本不需要提供出口。

重點回顧

這篇的主要目的其實不是介紹 NAT Gateway 或 VPC Endpoint 的功能，而是希望讀者能透過這篇文章建立一個判斷方式：

看到一條 Outbound Traffic，可以先問它要去哪裡。

如果目的地是一般 Internet：

Public Internet
      ↓
評估 NAT Gateway

如果是 S3 或 DynamoDB：

S3 / DynamoDB
      ↓
優先評估 Gateway Endpoint

如果是支援 PrivateLink 的 AWS Service：

AWS Service
      ↓
評估 Interface Endpoint
      ↓
安全需求 / 流量 / 成本 / AZ 數量

如果根本不需要 Outbound：

No Outbound Requirement
      ↓
不提供不必要的出口

最後可以把 NAT Gateway 與 VPC Endpoint 的角色整理成：

所以 NAT Gateway 與 VPC Endpoint 並不是互相取代的兩個選項。

真正的出口設計應該是：

讓不同的 Traffic 走適合它的路，而不是把所有流量都丟到同一個出口。

下一篇

前兩篇分別從 Private Subnet 的 Inbound 與 Outbound 出發，看了 Route Table、Security Group、NAT Gateway 與 VPC Endpoint 如何共同決定流量路徑。

接下來會繼續從實際的網路需求出發，看看當流量不只存在於單一 VPC 內時，AWS 還有哪些網路元件與連線方式可以使用。

參考資料

• AWS 官方文件｜NAT devices
• AWS 官方文件｜NAT Gateway use cases
• AWS 官方文件｜Gateway endpoints
• AWS 官方文件｜Gateway endpoints for Amazon S3
• AWS 官方文件｜Configure an interface endpoint
• AWS 官方文件｜Access AWS services through AWS PrivateLink
• AWS 官方文件｜NAT Gateway pricing considerations
• AWS｜Amazon VPC Pricing
• AWS｜AWS PrivateLink Pricing