這篇文章建立四層邊界：最外層的 VPC 隔離、中層的 public / private subnet 切分、流量進出的 route table 與 NAT、以及最貼近服務的 security group。每一層解決的問題不同，疊起來才是一個可審計、可收斂的網路。

VPC：網路隔離的最外層邊界

VPC（Virtual Private Cloud）先圈定整個系統的網路地址空間 — 一塊邏輯隔離的私有網段，是其餘所有網路切分的起點。在 VPC 裡開出來的所有資源預設只看得到同一個 VPC 內的成員，與其他 VPC、與其他帳號的網路天然隔離。它是後面所有切分動作的容器 — 沒有 VPC，subnet 與 security group 無處依附。

CIDR 規劃：一次決定、事後難改

建立 VPC 時最關鍵的決策是 CIDR 區塊的大小。這個範圍要一次規劃足夠大，因為事後擴張地址空間在多數雲上是麻煩且容易出錯的操作。AWS 雖然允許在 VPC 上追加 secondary CIDR，但追加的網段不能與原有的重疊，也不是所有服務都能自然使用跨 CIDR 的 subnet，routing 的複雜度會因此上升。

CIDR 規劃要同時考慮三件事。第一是容量：/16 提供約六萬五千個位址，對多數單一環境的 VPC 足夠寬裕，切成 /24 的 subnet 也有 256 個可用子網。第二是不重疊：未來若要透過 VPC peering、Transit Gateway 或 VPN 把這個 VPC 接回地端機房或其他環境，重疊的 CIDR 會讓路由無法解析。三個環境各自是 10.0.0.0/16，在彼此不需要互連時不是問題，但一旦要開 peering 就會撞車 — 這時候改 CIDR 的代價是重建整個 VPC。第三是預留：如果公司同時有多個 VPC（不同環境或不同產品線），用連續但不重疊的大段分配（如 dev 10.0.0.0/16、staging 10.1.0.0/16、prod 10.2.0.0/16）讓路由表更乾淨。

 1resource "aws_vpc" "main" {
 2  cidr_block           = "10.0.0.0/16"
 3  enable_dns_support   = true
 4  enable_dns_hostnames = true
 5
 6  tags = {
 7    Name        = "platform-prod"
 8    Environment = "production"
 9  }
10}

enable_dns_support 和 enable_dns_hostnames 在多數場景都該開啟。沒開 DNS hostname 時，EC2 instance 不會拿到可解析的 hostname，某些服務依賴 DNS 尋址而非 IP（如 VPC endpoint 的 private DNS），關著會讓它們靜靜失敗而不報錯。

判讀訊號：規劃 CIDR 時先問「這個環境三年後會有幾個 subnet、跨幾個可用區、要不要跟其他 VPC 或地端互連」。風險集中在地址耗盡與網段衝突 — 兩者都得在開第一個 subnet 之前定案。VPC 只負責隔離與定址，它不決定哪個服務能對外，那是 subnet 與 security group 的工作。環境之間的 VPC 該怎麼分，是模組四：環境分離與模組化的主題。

public 與 private subnet 的切分原則

一塊資源對外暴露到什麼程度，取決於它被放進哪個 subnet。VPC 內部按可用區與暴露程度切出來的子網段，決定資源有沒有一條通往網際網路的路徑。判斷一個資源該放 public 還是 private，問題只有一個：它需不需要被網際網路直接定址。

兩類 subnet 的定位

public subnet 放的是必須接收外部入站流量的元件 — 對外的負載平衡器、NAT Gateway、堡壘主機（bastion）。這些資源透過 route table 連到 Internet Gateway，因此能被外部 IP 直接觸及。private subnet 放的是只該在內網被存取的元件 — 應用伺服器、資料庫、快取、內部佇列。它們沒有通往 Internet Gateway 的路由，外部無法主動連入，需要對外時才透過 NAT 出去。

public subnet 的真實樣貌是「薄薄一層」：它通常只住負載平衡器與 NAT 這類入口設施，而不是業務邏輯。常見陷阱是為了 SSH 方便把應用伺服器直接開在 public subnet 並配公網 IP，等於把每一台業務主機的管理埠暴露在掃描流量下 — 全球的 bot 會在秒級頻率對公網 IP 的 22 埠嘗試登入。private subnet 的住戶反而是系統的主體 — 資料庫放這裡是因為它一旦能被外網定址，攻擊面就從「打穿入口層」變成「直接連資料庫埠試密碼」。

跨可用區冗餘

每個 subnet 綁定單一可用區（Availability Zone）。高可用設計通常是每種角色跨至少兩個可用區各開一個 subnet：兩個 public、兩個 private，讓單一可用區故障時另一區的同類 subnet 還能承接。subnet 的 CIDR 切法要留足空間 — 如果 VPC 是 /16，每個 subnet 用 /20（約四千個位址）可以在三個可用區各開 public + private 共六個 subnet，還有大量空間留給未來擴展。

 1locals {
 2  azs = ["ap-northeast-1a", "ap-northeast-1c", "ap-northeast-1d"]
 3}
 4
 5resource "aws_subnet" "public" {
 6  for_each          = toset(local.azs)
 7  vpc_id            = aws_vpc.main.id
 8  cidr_block        = cidrsubnet(aws_vpc.main.cidr_block, 4, index(local.azs, each.key))
 9  availability_zone = each.key
10
11  tags = { Name = "public-${each.key}" }
12}
13
14resource "aws_subnet" "private" {
15  for_each          = toset(local.azs)
16  vpc_id            = aws_vpc.main.id
17  cidr_block        = cidrsubnet(aws_vpc.main.cidr_block, 4, index(local.azs, each.key) + length(local.azs))
18  availability_zone = each.key
19
20  tags = { Name = "private-${each.key}" }
21}

cidrsubnet 函式自動切分子網段，避免手動計算 CIDR。第二個參數 4 表示在 /16 基礎上加 4 bit 得到 /20，第三個參數是序號。public 與 private 各佔不同序號區間，保證不重疊。

對外入口怎麼把流量分到跨可用區的 private 後端，是 devops 層負載平衡的範圍。這裡只要確保 subnet 的地圖在多 AZ 下對稱。

route table 與 NAT：流量的進出路徑

離開一個 subnet 的封包往哪走，逐條寫在 route table 這組轉送規則裡 — 它掛在 subnet 上，是封包出口方向的依據。一個 subnet 是 public 還是 private，技術上的差別就在它關聯的 route table 裡有沒有一條指向 Internet Gateway 的預設路由。subnet 的對外性質由它關聯的 route table 賦予，而非寫在 subnet 自身的屬性。

public 與 private 的路由差異

public subnet 的 route table 有一條 0.0.0.0/0 → Internet Gateway，讓未知目的地的流量直接出網、也讓外部可達。private subnet 的 route table 則把 0.0.0.0/0 指向 NAT Gateway。

NAT（Network Address Translation）解決的問題是：private subnet 的資源需要主動對外（拉套件、呼叫第三方 API、抓 OS 更新），但不能因此變得可被外部入站連入。NAT 讓出站流量借用一個公網位址出去、把回應導回原請求者，同時不開放任何外部主動發起的連線。

每 AZ 一個 NAT vs 共享 NAT 的取捨

NAT Gateway 是綁定單一可用區的資源 — 一個 NAT Gateway 活在某一個 public subnet，也就活在那個可用區裡。這帶來一個架構取捨：

共享 NAT（成本優先）：全部 private subnet 的 route table 都指向同一個 NAT。用一份 NAT 成本服務整個 VPC，代價是把 NAT 所在的可用區變成出站方向的單點 — 該可用區故障時，所有 private subnet 的對外連線同時中斷，即使其他可用區的節點本身健康。

每 AZ 一個 NAT（可用性優先）：每個可用區各放一個 NAT Gateway，並讓每一區的 private subnet route table 指向同區的 NAT。出站路徑與 subnet 的跨可用區冗餘對齊，單一 AZ 故障只影響該區。每個 NAT Gateway 的固定月費約 $32 加流量費 $0.045/GB 處理量。三個可用區各一個就是三倍固定費。這筆成本與業務對出站中斷的容忍度對齊——如果單一可用區故障導致全部出站中斷可接受（例如有重試機制），共享 NAT 的成本效益較高。

 1resource "aws_eip" "nat" {
 2  for_each = toset(local.azs)
 3  domain   = "vpc"
 4  tags     = { Name = "nat-${each.key}" }
 5}
 6
 7resource "aws_nat_gateway" "per_az" {
 8  for_each      = aws_subnet.public
 9  allocation_id = aws_eip.nat[each.key].id
10  subnet_id     = each.value.id
11  tags          = { Name = "nat-${each.key}" }
12}
13
14resource "aws_route_table" "private" {
15  for_each = aws_subnet.private
16  vpc_id   = aws_vpc.main.id
17
18  route {
19    cidr_block     = "0.0.0.0/0"
20    nat_gateway_id = aws_nat_gateway.per_az[each.key].id
21  }
22
23  tags = { Name = "private-rt-${each.key}" }
24}
25
26resource "aws_route_table_association" "private" {
27  for_each       = aws_subnet.private
28  subnet_id      = each.value.id
29  route_table_id = aws_route_table.private[each.key].id
30}

判讀訊號：private subnet 的服務拉不到外部套件、或第三方 API 全部逾時，先查它關聯的 route table 有沒有指向健康的 NAT；若只有某一個可用區的節點受影響，多半是那一區的 NAT 或其所在 subnet 出狀況。

NAT 的成本邊界

NAT Gateway 按處理流量計費（每 GB 一個費率），把大量出站流量長期走 NAT 會讓帳單可觀。常見的高流量場景包括：備份上傳到 S3、跨區資料同步、大量 API 呼叫。對於走向 AWS 自家服務的流量，成本效益較好的做法是用 VPC Endpoint（Gateway 型或 Interface 型）讓流量直連服務、繞過 NAT。S3 與 DynamoDB 的 Gateway Endpoint 是免費的，光是把 S3 備份流量從 NAT 改走 Gateway Endpoint 就能在流量大的環境省下可觀的費用。

1resource "aws_vpc_endpoint" "s3" {
2  vpc_id       = aws_vpc.main.id
3  service_name = "com.amazonaws.ap-northeast-1.s3"
4
5  route_table_ids = [for rt in aws_route_table.private : rt.id]
6
7  tags = { Name = "s3-gateway-endpoint" }
8}

NAT 的數量取捨與出站成本的更完整討論在 devops 模組八：成本管理。route table 與 NAT 只管「能不能出去、走哪條路」，至於某個埠允不允許連，是 security group 的職責。

security group 設計：最小開放

一條連線究竟能不能打到某個埠，由 security group 逐埠拍板 — 它是掛在資源網卡（ENI）層級的有狀態防火牆，規則描述的是哪些來源連得進這個資源。它是貼著服務的最後一道網路邊界 — 即使封包順著 route table 抵達了 private subnet，security group 仍能逐埠決定放不放行。「有狀態」的意思是：放行一條入站連線後，對應的回應出站自動允許，規則只需描述入站方向想開放什麼。

用 group 引用取代 IP 範圍

設計原則是最小開放：每條規則只開「這個服務確實需要被誰連的那個埠」。資料庫的 security group 入站只允許來自應用層 security group 的資料庫埠，而不是某個 IP 範圍。用 security group 互相引用、而非寫死網段，是因為應用節點會隨擴縮而換 IP — 引用來源 group 讓規則跟著成員身分走、不跟著位址走。

 1resource "aws_security_group" "app" {
 2  name_prefix = "app-"
 3  vpc_id      = aws_vpc.main.id
 4  tags        = { Name = "app-sg" }
 5}
 6
 7resource "aws_security_group" "database" {
 8  name_prefix = "db-"
 9  vpc_id      = aws_vpc.main.id
10  tags        = { Name = "db-sg" }
11}
12
13resource "aws_security_group_rule" "db_from_app" {
14  type                     = "ingress"
15  from_port                = 5432
16  to_port                  = 5432
17  protocol                 = "tcp"
18  security_group_id        = aws_security_group.database.id
19  source_security_group_id = aws_security_group.app.id
20}

這條規則表達的語意是「資料庫只接受來自 app group 成員的 5432 連線」。app 的 instance 數量從 2 台增長到 20 台時，規則本身不需要改 — 新 instance 只要也掛了 app 的 security group 就自動被允許。

0.0.0.0/0 的盤點紀律

把入站來源設成 0.0.0.0/0 等於允許整個網際網路連這個埠。對資料庫埠（5432、3306、6379）或管理埠（22、3389）這麼做，會讓服務暴露在持續性的自動掃描與暴力嘗試下。

合理出現 0.0.0.0/0 的位置只有對外負載平衡器的 80 / 443 入站 — 因為它的工作本來就是接收公開流量。其餘所有 0.0.0.0/0 都該被質疑。

盤點的做法：列出所有 security group，過濾 source 是 0.0.0.0/0 的 ingress rule，逐條問「這個埠確實需要全世界都連得到嗎」。在 CLI 上可以用一條查詢掃：

1aws ec2 describe-security-groups \
2  --query 'SecurityGroups[].{
3    ID:GroupId,
4    Name:GroupName,
5    OpenPorts:IpPermissions[?IpRanges[?CidrIp==`0.0.0.0/0`]].[FromPort,ToPort]
6  }' \
7  --output table

資料庫埠、SSH、內部 API 出現在這份清單上就是該收斂的目標。管理埠的存取更安全的替代方案是 SSM Session Manager — 它讓你透過 IAM 權限建立 shell session，完全不需要開 22 埠，連線經由 Systems Manager 的控制通道走、不走公網，同時自動留下 session log。誰能透過 IAM 改動這些規則，銜接模組二：身分與憑證地基。

在 CI 層面，模組七：infra 走 PR 流程用 tfsec / checkov 做靜態掃描，自動攔截「敏感埠 + 全開 CIDR」的組合，把 security group 的盤點從人工定期做變成每次 PR 自動做。

邊界設備漏洞帶來的教訓同樣適用於 security group 設計。Check Point CVE-2024-24919 事件顯示 VPN 邊界設備的資訊外洩漏洞可以直接轉為憑證與會話濫用，攻擊路徑是「邊界入口 → 會話竊取 → 內部橫向擴散」。Citrix Bleed 2023 則是邊界設備的會話資料外洩導致重放攻擊。這兩個案例的 infra 層教訓是：邊界設備（VPN concentrator、ADC、bastion）的 security group 只開必要的管理埠，且事件後需要全域 session/token 失效流程。

網路控制面的自動化也有風險。Cloudflare 2026 Route Leak 事件中，自動化路由政策配置的錯誤導致流量擁塞。infra 層的教訓是：路由與 security group 規則的自動化變更需要 pre-check 與影響範圍評估，且要有快速撤回機制——這正是 infra 走 PR 流程的 plan → review → apply 流程要擋的。

NACL 與 security group 的分工

subnet 這一層還有另一道防火牆 — network ACL（NACL），它與 security group 分工在兩個層級。

NACL 的特點是無狀態與支援顯式 deny。無狀態意味著放行了入站不代表回應的出站自動放行，回程封包得自己對得上另一條出站規則 — 這讓 NACL 的維護比 security group 複雜。支援顯式 deny 則是它獨有的能力：security group 只能說「誰可以進」，NACL 能說「誰一定不能進」，這在需要 subnet 邊界封鎖特定已知惡意網段時有用。

多數設計的主力是 security group：它貼著服務、用 group 互相引用就能表達「誰能連誰」，已經涵蓋大部分最小開放需求。NACL 留給少數情境 — 需要在 subnet 邊界擋掉一整段已知惡意網段、或要對某類流量做顯式 deny 時才展開。多數環境讓 NACL 維持預設全通、把存取控制集中在 security group，是可以接受的選擇。重點是知道這一層存在、在需要 subnet 層粗篩時記得它。

為什麼網路要先於核心服務鋪好

網路地基先行，是因為核心服務的安全位置由網路拓樸決定，而不是反過來。資料庫該落在哪個 private subnet、它的 security group 只接受哪個來源、它的出站走不走 NAT — 這些都是服務「出生時」就該確定的屬性。

先有規劃好的 subnet 與 security group，新服務上線只是挑一塊已定義安全等級的位置放進去。網路還沒鋪就先開服務，則往往落在預設 VPC 與寬鬆規則上。預設 VPC 是所有人共享的、CIDR 不可控的、security group 預設全通的 — 把正式服務放在這裡，等於跳過了所有隔離設計。事後再回頭收斂，要在服務已經有流量、有依賴的情況下改網段與防火牆，風險和協調成本都高得多。

這也呼應模組零：infra 是什麼的 day-1 鐵律：邊界與隔離屬於一開始就該存在的地基，不是長出問題後才補的修補。網路規劃好之後，照「從零建置」路線下一步先進模組四：環境分離與模組化確定環境怎麼切，再讓核心服務落進這些 subnet（見模組五：核心服務上 IaC）。

跨分類引用

• → 模組二：身分與憑證地基：誰有權改動 security group 與路由表
• → 模組四：環境分離與模組化：環境之間的 VPC 怎麼分
• → 模組五：核心服務上 IaC：核心服務怎麼落進規劃好的 subnet
• → 模組七：infra 走 PR 流程：tfsec / checkov 自動攔截 security group 全開
• → devops 模組八：成本管理：NAT 與出站流量的成本取捨
• → Security Group 稽核與清理：SG 規則盤點、未使用 SG 識別、清理工作流

概念位置

完整的 server 入口由兩個欄位定義：

Port 是 16 bit 數字（0 ~ 65535）、其中 0 ~ 1023 是 well-known port（HTTP 80、HTTPS 443 等、需 root 權限才能 bind）、1024 ~ 65535 是 user port、本地 LLM 工具都用這個區間（Ollama 11434、LM Studio 1234、llama.cpp 8080）。同一個 port 在同一個 listen address 上同時只能被一個 process 持有、要兩個 Ollama 並存就要其中一個換 port。

三個常見 listen address 的語意：

可觀察訊號與例子

驗證 server 真的在聽預期地址：

1# macOS 下查誰佔了 11434
2lsof -i :11434
3# COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
4# ollama  1234 mac  6u IPv4 0xabcd      0t0 TCP localhost:11434 (LISTEN)

TCP localhost:11434 (LISTEN) 表示這個 process 只接 localhost 進來的封包。改 listen address 把 Ollama 暴露到 LAN：

1OLLAMA_HOST=0.0.0.0:11434 ollama serve
2# lsof 之後會看到 TCP *:11434 (LISTEN)、星號表示所有介面

curl 用不同 host 名稱呼叫同一個 server：

1curl http://localhost:11434/api/version    # 走 loopback、最快
2curl http://127.0.0.1:11434/api/version    # 跟上面等價
3curl http://<本機 LAN IP>:11434/api/version # 若 listen 在 0.0.0.0、會通；只 listen localhost 會 connection refused

「為什麼桌機跑 Ollama、筆電連不到」的最常見原因就是 Ollama 沒改 listen address、預設只接受 loopback。

設計責任

選 listen address 是信任邊界決定：

• 127.0.0.1（預設）：機器本身就是信任邊界、外部進不來、最安全
• 0.0.0.0 在家用 / 信任 LAN：把 server 暴露給同網路裝置、便於多裝置共用、風險可接受
• 0.0.0.0 在公共 Wi-Fi / 對 internet：等於對所有路過裝置開放、Ollama 沒有內建 auth、需要 SSH tunnel 或 reverse proxy + auth 才安全

Port 衝突的處理順序：用 lsof 確認佔用方身分 → 若是舊版自己 kill、若是別的服務改自己的 port → 同步更新 IDE plugin 的 apiBase。完整資料流判讀見 0.7 隱私資料流。

匯出所有 security group 與規則

稽核的第一步是把當前所有 SG 和它們的規則拉出來存成可查詢的 JSON。這份 JSON 是後續所有分析的輸入，也是「稽核那天環境長什麼樣」的快照。

 1aws ec2 describe-security-groups \
 2  --query 'SecurityGroups[].{
 3    GroupId:GroupId,
 4    GroupName:GroupName,
 5    VpcId:VpcId,
 6    Description:Description,
 7    IngressRules:IpPermissions,
 8    EgressRules:IpPermissionsEgress,
 9    Tags:Tags
10  }' \
11  --output json > sg-inventory-$(date +%Y%m%d).json

這份檔案通常幾百 KB 到幾 MB，存進 repo 的 inventory/ 目錄，方便日後比對變化。如果帳號有多個 region，每個 region 各跑一次並標明 region。

用 jq 快速看有多少 SG 和總規則數：

1jq 'length' sg-inventory-*.json
2jq '[.[].IngressRules | length] | add' sg-inventory-*.json

找出 0.0.0.0/0 全開的入站規則

0.0.0.0/0 入站代表允許整個網際網路連到這個埠。對外 ALB 的 80/443 開 0.0.0.0/0 是設計意圖，但資料庫埠（5432、3306、6379）、SSH（22）或管理埠開 0.0.0.0/0 是需要收斂的目標。

1jq -r '.[] | select(.IngressRules[]?.IpRanges[]?.CidrIp == "0.0.0.0/0") |
2  {GroupId, GroupName, OpenPorts: [.IngressRules[] |
3    select(.IpRanges[]?.CidrIp == "0.0.0.0/0") |
4    "\(.FromPort // "all")-\(.ToPort // "all")/\(.IpProtocol)"
5  ]}' sg-inventory-*.json

輸出會列出每個有全開規則的 SG 和對應的 port 範圍。對每一條命中，判斷：

IPv6 的 ::/0 也要一併查：

1jq -r '.[] | select(.IngressRules[]?.Ipv6Ranges[]?.CidrIpv6 == "::/0") |
2  .GroupId' sg-inventory-*.json

找出未使用的 security group

未使用的 SG 是沒有任何網路介面（ENI）掛載的 SG。它不影響任何正在運行的資源，但佔用 SG 配額（每個 VPC 預設上限 2500 個），而且它的規則會讓稽核清單更長、更難判讀。

1aws ec2 describe-network-interfaces \
2  --query 'NetworkInterfaces[].Groups[].GroupId' \
3  --output text | tr '\t' '\n' | sort -u > sg-in-use.txt
4
5jq -r '.[].GroupId' sg-inventory-*.json | sort -u > sg-all.txt
6
7comm -23 sg-all.txt sg-in-use.txt > sg-unused.txt
8cat sg-unused.txt

sg-unused.txt 裡列出的就是當前沒有任何 ENI 引用的 SG。注意幾個例外：

• default SG：每個 VPC 都有一個 default SG，即使未使用也無法刪除，可以跳過
• 被其他 SG 引用：某個 SG 雖然沒有掛在任何 ENI 上，但被另一個 SG 的入站規則引用為 source — 刪除它會讓引用方的規則失效
• 被 launch template 或 auto-scaling group 引用：新啟動的實例會套用這個 SG，刪了之後新實例啟動會失敗

依賴檢查：刪除前確認沒有間接引用

直接刪一個 SG 之前，確認沒有其他資源引用它。AWS 在 SG 被引用時會擋住刪除（報 DependencyViolation），但提前知道引用方可以避免白跑一趟。

 1SG_ID="sg-0abc123"
 2
 3# 哪些 SG 的入站規則引用了這個 SG 作為來源
 4jq -r --arg sg "$SG_ID" '.[] |
 5  select(.IngressRules[]?.UserIdGroupPairs[]?.GroupId == $sg) |
 6  "\(.GroupId) (\(.GroupName)) 的入站規則引用了 \($sg)"' sg-inventory-*.json
 7
 8# 哪些 ENI 掛了這個 SG
 9aws ec2 describe-network-interfaces \
10  --filters Name=group-id,Values=$SG_ID \
11  --query 'NetworkInterfaces[].{Id:NetworkInterfaceId,Desc:Description,Status:Status}' \
12  --output table
13
14# 哪些 RDS instance 使用這個 SG
15aws rds describe-db-instances \
16  --query "DBInstances[?VpcSecurityGroups[?VpcSecurityGroupId=='$SG_ID']].[DBInstanceIdentifier]" \
17  --output text
18
19# 哪些 ELB 使用這個 SG
20aws elbv2 describe-load-balancers \
21  --query "LoadBalancers[?SecurityGroups[?contains(@,'$SG_ID')]].[LoadBalancerName]" \
22  --output text

如果所有查詢都回傳空，這個 SG 可以安全刪除。

清理流程：標記 → 通知 → 等待 → 刪除

批量清理不是一次 delete-security-group 的事。安全的流程有四步：

標記候選

對每個要清理的 SG 加一個 tag 標明狀態和預定刪除日期：

1aws ec2 create-tags \
2  --resources sg-0abc123 sg-0def456 \
3  --tags Key=cleanup-status,Value=pending-deletion \
4         Key=cleanup-date,Value=2026-07-10 \
5         Key=cleanup-reason,Value="unused-no-eni-no-reference"

通知

如果 SG 有 owner tag，通知該 owner：「這個 SG 預計在 cleanup-date 刪除，如果仍在使用請回報」。如果沒有 owner tag（多數需要清理的 SG 都沒有），在團隊頻道公告清理清單。

等待

給 7-14 天的寬限期。期間如果有人回報某個 SG 仍在使用，把 cleanup-status 改成 retained 並補上正確的 owner tag。

刪除

寬限期過後，對仍是 pending-deletion 的 SG 執行刪除：

1for sg in $(aws ec2 describe-security-groups \
2  --filters Name=tag:cleanup-status,Values=pending-deletion \
3  --query 'SecurityGroups[].GroupId' --output text); do
4  echo "Deleting $sg"
5  aws ec2 delete-security-group --group-id $sg 2>&1
6done

DependencyViolation 代表有遺漏的引用，跳過該 SG 並重新調查。

自動化持續治理

手動稽核適合第一次清理，持續治理靠自動化：

AWS Config 規則

restricted-ssh 和 restricted-common-ports 是 AWS Config 的 managed rule，啟用後會持續監控 SG 規則，新增的 0.0.0.0/0 規則會在幾分鐘內被標記為 non-compliant。

Prowler 定期掃描

在 CI 排程中定期跑 Prowler，掃描結果存進 repo 作為趨勢追蹤：

1prowler aws --services ec2 --checks ec2_securitygroup_allow_ingress_from_internet_to_any_port \
2  -M json-ocsf -o inventory/prowler/

PR 流程攔截

模組七的 checkov/tfsec 護欄在 PR 階段攔截新增的 0.0.0.0/0 規則。這是把治理從「事後稽核」推到「事前攔截」的關鍵一步：稽核能發現已存在的問題，PR 護欄能阻止新問題被引入。

AWS Security Hub 啟用 Foundational Security Best Practices 標準後，會自動聚合 SG 相關的合規 finding 並提供統一 dashboard，適合作為管理層報告的來源。Security Hub 整合了 Config rules 和 Prowler 各自能發現的問題，提供單一窗口追蹤合規趨勢。

稽核節奏

第一次稽核最花時間（半天到一天，取決於 SG 數量）。之後的節奏取決於環境變動速度：

稽核產出一份報告：SG 總數、0.0.0.0/0 規則數、未使用 SG 數、上次稽核以來的變化。這份報告可以作為治理進度的量化指標，納入月報。

跨分類引用

• → 網路地基 — security group 設計：SG 的設計原則（最小開放、group 互相引用）
• → infra 走 PR 流程：checkov/tfsec 在 PR 階段攔截 0.0.0.0/0
• → 治理好習慣 — tagging：tag 是識別 SG owner 和清理候選的依據

這一章建立四層邊界：最外層的 VPC 隔離、中層的 public / private subnet 切分、流量進出的 route table 與 NAT、以及最貼近服務的 security group。每一層解決的問題不同，疊起來才是一個可審計、可收斂的網路。

VPC：網路隔離的最外層邊界

VPC（Virtual Private Cloud）先圈定整個系統的網路地址空間 — 一塊邏輯隔離的私有網段，是其餘所有網路切分的起點。在 VPC 裡開出來的所有資源預設只看得到同一個 VPC 內的成員，與其他 VPC、與其他帳號的網路天然隔離。它是後面所有切分動作的容器 — 沒有 VPC，subnet 與 security group 無處依附。

建立 VPC 時最關鍵的決策是 CIDR 區塊的大小，例如 10.0.0.0/16 提供約六萬五千個位址。這個範圍要一次規劃足夠大，因為事後擴張地址空間在多數雲上是麻煩且容易出錯的操作。同時要避免與公司其他網段重疊：未來若要透過 VPC peering、Transit Gateway 或 VPN 把這個 VPC 接回地端機房或其他環境，重疊的 CIDR 會讓路由無法解析。

 1resource "aws_vpc" "main" {
 2  cidr_block           = "10.0.0.0/16"
 3  enable_dns_support   = true
 4  enable_dns_hostnames = true
 5
 6  tags = {
 7    Name        = "platform-main"
 8    Environment = "production"
 9  }
10}

判讀訊號：規劃 CIDR 時先問「這個環境三年後會有幾個 subnet、跨幾個可用區、要不要接地端」。風險集中在地址耗盡與網段衝突 — 兩者都得在開第一個 subnet 之前定案。邊界是：VPC 只負責隔離與定址，它不決定哪個服務能對外，那是 subnet 與 security group 的工作。環境之間的 VPC 該怎麼分，是「模組四：環境分離與模組化」的主題，這裡只先確保單一 VPC 的地址規劃站得住。

public 與 private subnet 的切分原則

一塊資源對外暴露到什麼程度，取決於它被放進哪個 subnet — VPC 內部按可用區與暴露程度切出來的子網段，決定資源有沒有一條通往網際網路的路徑。判斷一個資源該放 public 還是 private，問題只有一個：它需不需要被網際網路直接定址。

public subnet 放的是必須接收外部入站流量的元件 — 對外的負載平衡器、需要公開的 NAT Gateway、堡壘主機（bastion）。這些資源透過 route table 連到 Internet Gateway，因此能被外部 IP 直接觸及。private subnet 放的是只該在內網被存取的元件 — 應用伺服器、資料庫、快取、內部佇列。它們沒有通往 Internet Gateway 的路由，外部無法主動連入，需要對外時才透過 NAT 出去。

public subnet 的真實樣貌是「薄薄一層」：它通常只住負載平衡器與 NAT 這類入口設施，而不是業務邏輯。常見陷阱是為了 SSH 方便把應用伺服器直接開在 public subnet 並配公網 IP，等於把每一台業務主機的管理埠暴露在掃描流量下。private subnet 的住戶反而是系統的主體 — 資料庫放這裡是因為它一旦能被外網定址，攻擊面就從「打穿入口層」變成「直接連資料庫埠試密碼」。

每個 subnet 綁定單一可用區，所以高可用設計通常是每種角色跨至少兩個可用區各開一個 subnet：兩個 public、兩個 private，讓單一可用區故障時另一區的同類 subnet 還能承接。對外入口怎麼把流量分到跨可用區的 private 後端，是「devops 模組一：負載平衡」的範圍。

route table 與 NAT：流量的進出路徑

離開一個 subnet 的封包往哪走，逐條寫在 route table 這組轉送規則裡 — 它掛在 subnet 上，是封包出口方向的依據。一個 subnet 是 public 還是 private，技術上的差別就在它關聯的 route table 裡有沒有一條指向 Internet Gateway 的預設路由。換句話說，subnet 的對外性質由它關聯的 route table 賦予，而非寫在 subnet 自身。

public subnet 的 route table 有一條 0.0.0.0/0 → Internet Gateway，讓未知目的地的流量直接出網、也讓外部可達。private subnet 的 route table 則把 0.0.0.0/0 指向 NAT Gateway。NAT（Network Address Translation）解決的問題是：private subnet 的資源需要主動對外（拉套件、呼叫第三方 API、抓 OS 更新），但不能因此變得可被外部入站連入。NAT 讓出站流量借用一個公網位址出去、把回應導回原請求者，同時不開放任何外部主動發起的連線。

NAT Gateway 的核心取捨是成本與可用性。它是綁定單一可用區的資源 — 一個 NAT Gateway 活在某一個 public subnet、也就活在那個可用區裡。若全部 private subnet 的 route table 都指向同一個 NAT，這個設計用一份 NAT 成本服務整個 VPC，代價是把 NAT 所在的可用區變成出站方向的單點：該可用區故障時，所有 private subnet 的對外連線同時中斷，即使其他可用區的節點本身健康。要讓出站路徑與 subnet 的跨可用區冗餘對齊，做法是每個可用區各放一個 NAT Gateway，並讓每一區的 private subnet route table 指向同區的 NAT。下面用 for_each 在每個可用區建立一個 NAT，再讓每個 private subnet 的 route table 走本區出口。

 1resource "aws_nat_gateway" "per_az" {
 2  for_each      = aws_subnet.public
 3  allocation_id = aws_eip.nat[each.key].id
 4  subnet_id     = each.value.id
 5}
 6
 7resource "aws_route_table" "private" {
 8  for_each = aws_subnet.private
 9  vpc_id   = aws_vpc.main.id
10
11  route {
12    cidr_block     = "0.0.0.0/0"
13    nat_gateway_id = aws_nat_gateway.per_az[each.key].id
14  }
15
16  tags = { Name = "private-rt-${each.key}" }
17}

每個可用區一個 NAT 是可用性優先的版本；若環境對成本敏感、且能接受出站在單一可用區故障時短暫中斷，也可以退回單一 NAT，但要把它當成明示的取捨、而非預設。判讀訊號：private subnet 的服務拉不到外部套件、或第三方 API 全部逾時，先查它關聯的 route table 有沒有指向健康的 NAT；若只有某一個可用區的節點受影響，多半是那一區的 NAT 或其所在 subnet 出狀況。風險與成本在這裡交會 — NAT Gateway 按處理流量計費，把大量出站流量（例如備份上傳、跨區同步）長期走 NAT 會讓帳單可觀，這類流量較划算的做法是改走 VPC Endpoint 直連雲服務、繞過 NAT。NAT 的數量取捨與出站成本在「devops 模組八：成本管理」有更完整的討論。邊界是：route table 與 NAT 只管「能不能出去、走哪條路」，至於某個埠允不允許連，是 security group 的職責。

security group 設計：最小開放

一條連線究竟能不能打到某個埠，由 security group 逐埠拍板 — 它是掛在資源網卡層級的有狀態防火牆，規則描述的是哪些來源連得進這個資源。它是貼著服務的最後一道網路邊界 — 即使封包順著 route table 抵達了 private subnet，security group 仍能逐埠決定放不放行。它有狀態的意思是：放行一條入站連線後，對應的回應出站自動允許，規則只需描述入站方向想開放什麼。

設計原則是最小開放：每條規則只開「這個服務確實需要被誰連的那個埠」。資料庫的 security group 入站只允許來自應用層 security group 的資料庫埠，而不是某個 IP 範圍。用 security group 互相引用、而非寫死網段，是因為應用節點會隨擴縮而換 IP，引用來源 group 讓規則跟著成員身分走、不跟著位址走。

1resource "aws_security_group_rule" "db_from_app" {
2  type                     = "ingress"
3  from_port                = 5432
4  to_port                  = 5432
5  protocol                 = "tcp"
6  security_group_id        = aws_security_group.database.id
7  source_security_group_id = aws_security_group.app.id
8}

要特別防的是 0.0.0.0/0 全開。把入站來源設成 0.0.0.0/0 等於允許整個網際網路連這個埠，對資料庫埠（5432、3306、6379）或管理埠（22、3389）這麼做，會讓服務暴露在持續性的自動掃描與暴力嘗試下。合理出現 0.0.0.0/0 的位置只有對外負載平衡器的 80 / 443 入站 — 因為它的工作本來就是接收公開流量。判讀訊號：盤點所有 security group，列出 source 是 0.0.0.0/0 的規則，逐條問「這個埠真的需要全世界都連得到嗎」；資料庫埠、SSH、內部 API 出現在這份清單上就是該收斂的目標。管理埠的存取較划算的替代方案是 SSM Session Manager 或堡壘主機，把 22 埠從公網清單上拿掉。誰能透過 IAM 改動這些規則，銜接「模組二：身分與憑證地基」。

subnet 這一層還有另一道防火牆 — network ACL（NACL），它與 security group 分工在兩個層級。NACL 掛在 subnet 上、作用於進出整個 subnet 的流量，而且是無狀態的：入站與出站要各寫一條規則，放行了入站不代表回應的出站自動放行，回程封包得自己對得上另一條規則。security group 則掛在資源網卡（ENI）層、有狀態，放行入站後對應回應自動允許。兩者的另一個差別是 NACL 支援顯式 deny、security group 只能列允許清單，所以 NACL 適合做 subnet 層的粗篩或針對特定來源的明確封鎖。實務上多數設計的主力是 security group：它貼著服務、用 group 互相引用就能表達「誰能連誰」，已經涵蓋大部分最小開放需求。NACL 留給少數情境 — 需要在 subnet 邊界擋掉一整段已知惡意網段、或要對某類流量做顯式 deny 時才展開；多數環境讓 NACL 維持預設全通、把存取控制集中在 security group，是可以接受的選擇，重點是知道這一層存在、在需要 subnet 層粗篩時記得它。

為什麼網路要先於核心服務鋪好

網路地基先行，是因為核心服務的安全位置由網路拓樸決定，而不是反過來。資料庫該落在哪個 private subnet、它的 security group 只接受哪個來源、它的出站走不走 NAT — 這些都是服務「出生時」就該確定的屬性。先有規劃好的 subnet 與 security group，新服務上線只是挑一塊已定義安全等級的位置放進去；網路還沒鋪就先開服務，則往往落在預設 VPC 與寬鬆規則上，事後再回頭收斂，要在服務已經有流量、有依賴的情況下改網段與防火牆，風險和協調成本都高得多。

這也呼應「模組零：infra 是什麼」的 day-1 鐵律：邊界與隔離屬於一開始就該存在的地基，不是長出問題後才補的修補。網路規劃好之後，照「從零建置」路線下一步先進「模組四：環境分離與模組化」確定環境怎麼切，再讓核心服務落進這些 subnet。

章節文章

跨分類引用

• → 模組二：身分與憑證地基：誰有權改動 security group 與路由表
• → 模組五：核心服務上 IaC：核心服務怎麼落進規劃好的 subnet
• → devops 模組一：負載平衡：入口流量怎麼分到 private subnet 的後端
• → devops 模組八：成本管理：NAT 與出站流量的成本取捨

三種處理策略

Offline-first

功能的核心操作在本地完成，網路用於同步。斷線時使用者仍可操作，重新連線後自動同步差異。

Offline-first 適合的前提是資料可以本地存儲且衝突可以解決。筆記 app、待辦事項、表單填寫 — 使用者的操作產生本地資料，網路只負責把資料同步到 server。

Offline-first 的 UX 設計重點是讓使用者知道同步狀態：已同步、待同步、同步失敗。不需要 gate — 網路狀態不阻擋使用者操作。

Retry with feedback

功能需要網路但可以等待。斷線時顯示狀態和重試選項，使用者決定要等還是離開。

app_tunnel 的 terminal 連線屬於這個模式。WebSocket 連線需要網路，斷線時使用者無法操作終端機。error 和 disconnected 狀態提供重連按鈕讓使用者手動重試。

Retry 策略的 UX 設計重點：

• 告知使用者發生什麼（「連線中斷」而非空白畫面）
• 提供手動重試（重連按鈕）
• 提供退出路徑（返回首頁 — app_tunnel 原本缺少這個）
• 自動重試要有上限和間隔遞增（避免無限重試消耗電量）

Degraded mode

功能部分依賴網路。核心功能離線可用，進階功能需要網路。斷線時自動切換到降級模式，不阻擋使用者操作但功能受限。

降級模式的 UX 設計重點是清楚標示哪些功能可用、哪些不可用。「離線模式 — 搜尋功能暫時不可用」比靜默隱藏搜尋按鈕更透明。

網路狀態的 UI 呈現

全域指示器

在 app 頂部或狀態列顯示「離線」標示。適合網路狀態影響全域功能的 app。

功能級指示器

在需要網路的功能旁邊顯示不可用狀態。適合只有部分功能依賴網路的 app。

非侵入式通知

用 Snackbar 或 Toast 短暫顯示「已恢復連線」或「網路中斷」。適合網路狀態偶爾變化的場景。不適合頻繁斷開重連的場景（通知太多會干擾使用者）。

連線但品質差的場景

網路存在但延遲高或頻繁斷開，比完全離線更難處理。完全離線時 app 可以立即切換到離線模式；連線不穩定時，每次請求可能成功也可能逾時，使用者體驗是「有時候行有時候不行」。

處理策略：

• 設定合理的逾時時間（太短會把慢回應判定為失敗，太長讓使用者等太久）
• 逾時後顯示狀態和重試選項，不自動重試（避免在不穩定網路上累積重試）
• 在 loading 狀態提供取消選項，讓使用者可以中斷等待

下一步路由

• Gate 設計的通用方法論 → Gate 分類與三問設計法
• 權限請求的 UX 設計 → Permission 請求時機與措辭
• 畫面狀態矩陣中的網路狀態 → ux-design 模組一 畫面狀態機
• Server 端背壓如何影響 client UX → DevOps 背壓機制

VPC 用 CIDR 區塊定義地址空間。建立時的 CIDR 大小是一次性決策——事後擴張地址空間在多數雲端平台上是麻煩且容易出錯的操作（AWS 允許追加 secondary CIDR，但追加的網段在 routing 與服務相容性上有限制）。

概念位置

VPC 是模組三：網路地基的最外層邊界。Infra 系列的網路設計從 VPC 開始：先圈定地址空間，再往內切 subnet、掛 route table、設 security group。環境之間的 VPC 怎麼分（每個環境一個 VPC），屬於模組四：環境分離的設計決策。

可觀察訊號

VPC 設計需要關注的訊號：CIDR 空間快用完（subnet 切不出新的子網段）、需要跟其他 VPC 或地端互連時發現 CIDR 重疊（peering 無法建立）、服務被放在預設 VPC 裡（預設 VPC 是所有人共享的、CIDR 不可控的、security group 預設全通的）。

設計責任

規劃 VPC 時要決定：

• CIDR 大小：/16 提供約六萬五千個位址，對多數單一環境足夠
• 不重疊：多個 VPC（不同環境或產品線）用連續但不重疊的大段分配
• DNS 設定：enable_dns_support 和 enable_dns_hostnames 在多數場景都該開啟
• 預設 VPC 的處理：正式服務不該放在預設 VPC，新帳號的預設 VPC 可以刪除或保留唯讀

鄰卡

• Subnet — VPC 內按可用區與暴露程度切出的子網段
• Security Group — 掛在資源上的有狀態防火牆
• CIDR — VPC 的地址空間定義方式
• NAT — 讓 private subnet 出站的地址轉換機制

Subnet 分兩類：

• Public subnet：route table 有 0.0.0.0/0 → Internet Gateway，讓資源能被外部 IP 直接觸及。典型住戶是對外負載平衡器、NAT Gateway。
• Private subnet：route table 把 0.0.0.0/0 指向 NAT Gateway，外部無法主動連入。典型住戶是應用伺服器、資料庫、快取。

Public subnet 的真實樣貌是「薄薄一層」——它通常只住入口設施，業務邏輯跟資料儲存都在 private subnet。

概念位置

Subnet 是模組三：網路地基的中層邊界。VPC 定好地址空間後，subnet 決定「哪些資源能被外網碰到、哪些只能在內網存取」。每個 subnet 綁定單一可用區，高可用設計通常是每種角色跨至少兩個可用區各開一個 subnet。

可觀察訊號

Subnet 配置有問題的訊號：應用伺服器被放在 public subnet 並配了公網 IP（管理埠暴露在掃描流量下）、private subnet 的服務拉不到外部套件（route table 沒指向健康的 NAT）、新服務上線時找不到適合的 subnet（CIDR 切得太小、空間不夠）。

設計責任

規劃 subnet 時要決定：

• CIDR 切法：VPC 是 /16 時，每個 subnet 用 /20（約四千位址）可以在三個可用區各開 public + private 共六個 subnet
• 跨可用區對稱：每種角色至少跨兩個 AZ，讓單一 AZ 故障時另一區能承接
• public 的住戶限制：只放入口設施，業務邏輯一律放 private

鄰卡

• VPC — subnet 的容器
• NAT — 讓 private subnet 出站的機制
• Security Group — 掛在資源上的埠級存取控制

設計原則是最小開放：每條規則只開「這個服務確實需要被誰連的那個埠」。資料庫的 security group 入站只允許來自應用層 security group 的資料庫埠（如 5432），而不是某個 IP 範圍。用 security group 互相引用（source 指向另一個 group 而非 CIDR）讓規則跟著成員身分走、不跟著位址走——應用節點會隨擴縮而換 IP，引用 group 不會因此失效。

概念位置

Security group 是模組三：網路地基的最內層邊界——貼著服務的最後一道網路防線。即使封包順著 route table 抵達了 private subnet，security group 仍能逐埠決定放不放行。模組七：infra 走 PR 流程用 tfsec / checkov 在 CI 攔截 0.0.0.0/0 全開的規則。

可觀察訊號

Security group 需要收斂的訊號：入站來源是 0.0.0.0/0（允許全網連入），且目標埠是資料庫（5432、3306、6379）或管理埠（22、3389）——合理出現 0.0.0.0/0 的位置只有對外負載平衡器的 80 / 443。盤點方式是列出所有 source 為 0.0.0.0/0 的規則，逐條問「這個埠需要全世界都連得到嗎」。

設計責任

設計 security group 時要決定：

• 引用方式：用 group 互相引用（推薦）vs 用 CIDR 限定範圍
• 開放範圍：只開需要的埠與來源，0.0.0.0/0 只給對外 LB
• 管理埠存取：SSH（22）改用 SSM Session Manager 取代，從公網清單上拿掉
• 與 NACL 的分工：security group 是主力（有狀態、group 引用），NACL 留給少數需要 subnet 層顯式 deny 的情境

鄰卡

• VPC — security group 依附的網路容器
• Subnet — security group 與 subnet 各守不同層級的邊界

概念位置

NAT Gateway 在網路地基裡的角色是 private subnet 的出站閘道。它解決的問題是：private subnet 的設計意圖是「外部連不進來」，但服務仍需要主動對外。沒有 NAT，private subnet 的資源完全無法對外通訊 — 連 apt update 或 pip install 都做不到。

NAT Gateway 是綁定單一可用區的資源，活在某個 public subnet 裡。這帶來一個架構取捨：共享一個 NAT（成本低、出站方向有單點）還是每個可用區各放一個（成本高、出站與 subnet 冗餘對齊）。

可觀察訊號

以下狀況指向 NAT 相關問題：

• Private subnet 的服務拉不到外部套件或第三方 API 全部逾時 — 先查 route table 有沒有指向健康的 NAT
• 只有某一個可用區的節點受影響 — 該區的 NAT 或其所在 subnet 可能故障
• 雲帳單裡 NAT Gateway 的流量費用異常高 — 大量走 NAT 的流量（S3 備份、跨區同步）可用 VPC Endpoint 繞過

設計責任

使用 NAT Gateway 時要決定：

• 數量：每個可用區一個（可用性優先）還是全 VPC 共享一個（成本優先）。每個 NAT 固定月費約 $32 加流量費 $0.045/GB
• 高流量路徑：對 AWS 自家服務的流量（S3、DynamoDB）改用 Gateway Endpoint 直連，繞過 NAT 省流量費
• route table 關聯：每個 private subnet 的 route table 要明確指向哪個 NAT

鄰卡

• Subnet — NAT 放在 public subnet、服務放在 private subnet
• VPC — NAT 屬於 VPC 內部的出站路徑設施

概念位置

CIDR 是 VPC 規劃的起點決策。建立 VPC 時指定的 CIDR 區塊決定了這個 VPC 能容納多少 subnet 和多少資源。這個決策在建立後難以修改——事後擴張意味著追加 secondary CIDR，而追加的網段在 routing 與服務相容性上有限制。

在 infra 系列中，CIDR 規劃出現在模組三：網路地基的 VPC 段落。Terraform 的 cidrsubnet 函式可以從 VPC 的 CIDR 自動切出 subnet 的子網段，避免手動計算。

可觀察訊號

CIDR 規劃出問題的訊號有兩類。第一類是地址耗盡：subnet 切不出新的子網段、或 subnet 內的 IP 分配用完，新資源無法取得位址。第二類是網段衝突：需要透過 VPC peering、Transit Gateway 或 VPN 互連兩個 VPC 時，發現兩端的 CIDR 重疊，路由無法解析，peering 建立失敗。

設計責任

規劃 CIDR 時要決定：

• 大小：單一環境用 /16 通常足夠寬裕，切成 /20 的 subnet 可分配 16 個子網段
• 不重疊：多個環境（dev 10.0.0.0/16、staging 10.1.0.0/16、prod 10.2.0.0/16）用連續但不重疊的區段，為日後互連預留空間
• 與地端的協調：如果未來可能接 VPN 回地端機房，CIDR 要避開地端已使用的私有網段

鄰卡

• VPC — 用 CIDR 區塊定義的邏輯隔離網段
• Subnet — 從 VPC CIDR 切出的子網段

概念位置

nginx 和 ALB 都扮演 reverse proxy 角色。差別在層級：nginx 通常部署在應用層（跟應用伺服器同一台或同一個 VPC 內），ALB 是雲端平台提供的受管服務。兩者的核心功能相同——接收外部流量、轉發到後端、回傳結果。

跟 forward proxy 的方向相反：forward proxy 代替 client 發送請求（client 在內網、proxy 幫它出去）；reverse proxy 代替 server 接收請求（server 在內網、proxy 幫它面對外部）。

可觀察訊號

接手時如果 server 上跑著 nginx 但應用程式用的是 PHP-FPM 或 Node.js，nginx 多半扮演 reverse proxy——它接 HTTP/HTTPS 請求、轉發給後端的 application server。設定檔裡的 proxy_pass（nginx）或 ProxyPass（Apache）就是 reverse proxy 的轉發規則。

設計責任

reverse proxy 常承擔的功能：

鄰卡

• ALB：雲端的受管 reverse proxy + 負載平衡器
• nginx：最常見的 reverse proxy 軟體