AWS Target Group 與 VPC 關係完整教學

很多人第一次建 Target Group 時都會卡在這一步：「為什麼要我選 VPC？」

這問題看起來很小，但其實搞懂它，你對整個 AWS 負載平衡的理解會清楚很多。

這篇文章用白話文帶你搞懂這件事，不講太多理論，直接告訴你「為什麼」跟「怎麼做」。

先搞懂這三個東西是什麼

在講重點之前，先搞懂三個主角。這段有點長，但基礎打好，後面會看得很順。

整體架構圖

先看一下這三個東西怎麼串在一起：

flowchart LR
    subgraph Internet
        User[👤 用戶請求]
    end

    subgraph AWS
        subgraph VPC["🔒 VPC（私人網路）"]
            LB[🔀 Load Balancer<br/>流量分配器]
            TG[📋 Target Group<br/>後端伺服器名單]

            subgraph Targets[Targets]
                EC2_1[🖥️ EC2-1<br/>10.0.1.10]
                EC2_2[🖥️ EC2-2<br/>10.0.1.11]
                EC2_3[🖥️ EC2-3<br/>10.0.1.12]
            end

            LB -->|2.查名單| TG
            TG -->|3.健康檢查| Targets
            LB -->|4.轉發流量| EC2_1
            LB -.->|備用| EC2_2
            LB -.->|備用| EC2_3
        end
    end

    User -->|1.發送請求| LB

    style VPC fill:#e8f4ea,stroke:#2d6a4f
    style TG fill:#fff3cd,stroke:#856404
    style LB fill:#cce5ff,stroke:#004085

流程說明：

1. 用戶發請求 → 打到 Load Balancer
2. Load Balancer 查 Target Group → 看誰可以接
3. Target Group 做健康檢查 → 確認機器活著
4. 轉發流量 → 丟給健康的 EC2

重點是：Target Group 和它管理的機器，都在同一個 VPC 裡面。

這就是為什麼建 Target Group 要選 VPC。

VPC：你在 AWS 上的私人網路

VPC 是什麼？

VPC（Virtual Private Cloud）就是你在 AWS 上租的一塊「私人網段」。你可以想像成：AWS 有一棟超大的資料中心大樓，VPC 就是你在裡面隔出來的一間獨立辦公室，有自己的門禁和內部網路。

VPC 裡面有什麼？

你在 AWS 上建的大部分東西，都是放在 VPC 裡面的：

• EC2：虛擬機器
• RDS：資料庫
• ECS / EKS：容器服務
• Lambda（如果設定連接 VPC 的話）
• ElastiCache：快取服務

VPC 的幾個重要特性

為什麼這很重要？

因為你的機器（EC2）會拿到一個 Private IP，這個 IP 是「屬於某個 VPC」的。

同樣是 10.0.1.10，在 VPC-A 跟 VPC-B 可能是完全不同的兩台機器。

所以當 AWS 要連到你的機器時，光知道 IP 不夠，還要知道是哪個 VPC。

Target Group：後端伺服器的名單

Target Group 是什麼？

Target Group 就是一份「誰可以接收流量」的清單。

Load Balancer 會看這份清單，把請求分給上面的機器。

你可以把它想成餐廳的「服務生排班表」：

• 排班表上有哪些服務生（Target）
• 每個服務生目前有沒有空（健康狀態）
• 經理（Load Balancer）根據排班表派任務

Target Group 可以放什麼？

Target Group 會做什麼事？

1. 記錄 Target 清單：知道有哪些機器可以接請求
2. 健康檢查：定期去 ping 每台機器，確認還活著
3. 回報狀態：告訴 Load Balancer 哪些機器是健康的
4. 設定分流規則：比如權重、Sticky Session 等

健康檢查是什麼意思？

Target Group 會定期（預設 30 秒）發一個請求到你的機器，看它有沒有正常回應。

像這樣：

Target Group → 發 HTTP GET /health → EC2
EC2 → 回 200 OK → Target Group 標記為 healthy
EC2 → 沒回應或回 500 → Target Group 標記為 unhealthy

Target Group → 發 HTTP GET /health → EC2
EC2 → 回 200 OK → Target Group 標記為 healthy
EC2 → 沒回應或回 500 → Target Group 標記為 unhealthy

只有 healthy 的機器才會收到真正的用戶流量。

Load Balancer：流量分配器

Load Balancer 是什麼？

Load Balancer（負載平衡器）就是一個「流量分配員」。它站在最前面，接收所有進來的請求，然後根據規則分給後面的伺服器。

為什麼需要 Load Balancer？

想像你開了一家很紅的飲料店：

• 只有一個店員 → 排隊排到死
• 有五個店員 → 客人分散處理，速度快很多
• Load Balancer 就是那個「叫號機」，幫你把客人分給不同店員

好處：

• 分散流量：不會讓單一機器被打爆
• 高可用：一台掛了，還有其他台可以用
• 彈性擴展：流量大就多開幾台，流量小就關掉

AWS 有幾種 Load Balancer？

大部分的網站用 ALB 就夠了。

Load Balancer 跟 Target Group 的關係

這兩個是搭配使用的：

用戶請求 → Load Balancer → 查 Target Group → 找到健康的機器 → 轉發請求

用戶請求 → Load Balancer → 查 Target Group → 找到健康的機器 → 轉發請求

Load Balancer 本身不知道後面有哪些機器，它是透過 Target Group 來知道的。

一個 Load Balancer 可以配多個 Target Group（根據路徑或 Host 分流），但每個 Target Group 只能屬於一個 VPC。

為什麼建 Target Group 要選 VPC？

簡單講：因為你的機器就在 VPC 裡面

你放進 Target Group 的 EC2、容器這些東西，本來就是部署在某個 VPC 裡面的。

AWS 需要知道「這些機器在哪個網段」，才能正確地把流量送過去。

這就像寄包裹一樣：光知道收件人叫「王小明」不夠，你還要知道他住哪個社區、哪棟樓、哪個門牌號。

VPC 就是那個「社區地址」，Private IP 就是「門牌號」。

更具體一點，Target Group 要做三件事

📍 找到你的機器在哪

問題：Private IP 不是全球唯一的

每台 EC2 都有一個 Private IP，但這個 IP 是私有的，只在那個 VPC 裡面有效。

看這個例子：

兩台完全不同的機器，卻有一模一樣的 IP！這在 AWS 是完全合法的，因為 Private IP 只要在自己的 VPC 裡不重複就好。

所以 AWS 需要 VPC 資訊

當 Target Group 要連到 10.0.1.10，它必須知道是 vpc-aaa 的還是 vpc-bbb 的，不然會連到錯的機器。

🩺 做健康檢查

健康檢查的運作方式

Load Balancer 會定期（預設每 30 秒）對 Target Group 裡的每台機器做健康檢查，確認它們還活著、能正常服務。

flowchart TB
    subgraph VPC["🔒 VPC（私人網路）"]
        LB["🔀 Load Balancer"]
        TG["📋 Target Group"]

        LB --- TG

        TG -->|"健康檢查"| EC2_1
        TG -->|"健康檢查"| EC2_2
        TG -->|"健康檢查"| EC2_3

        EC2_1["🖥️ EC2-1<br/>10.0.1.10<br/>✅ Healthy"]
        EC2_2["🖥️ EC2-2<br/>10.0.1.11<br/>✅ Healthy"]
        EC2_3["🖥️ EC2-3<br/>10.0.1.12<br/>❌ Unhealthy"]
    end

    Note["💡 健康檢查走 VPC 內部網路"]

    style VPC fill:#e8f4ea,stroke:#2d6a4f
    style EC2_1 fill:#d4edda,stroke:#155724
    style EC2_2 fill:#d4edda,stroke:#155724
    style EC2_3 fill:#f8d7da,stroke:#721c24
    style Note fill:#fff3cd,stroke:#856404

健康檢查的細節設定

為什麼健康檢查需要知道 VPC？

因為健康檢查是走 VPC 內部的私有網路，不是走公網。

這表示：

• Load Balancer 要能在 VPC 裡面路由到 Target 的 Private IP
• 安全群組（Security Group）要允許健康檢查的流量進來
• 這一切都只在指定的 VPC 裡面發生

如果不知道 VPC，根本不知道要從哪裡發健康檢查、走哪條網路路徑。

🔁 轉發流量

流量怎麼從 Load Balancer 到 EC2？

當真正的用戶請求進來，Load Balancer 要把流量轉發給後端的 EC2。

這個轉發過程：

flowchart LR
    subgraph Internet["🌐 Internet"]
        User["👤 用戶"]
    end

    subgraph VPC["🔒 VPC"]
        subgraph PublicSubnet["📤 Public Subnet"]
            LB["🔀 Load Balancer<br/>公網 IP: 54.xx.xx.xx"]
        end

        subgraph PrivateSubnet["📥 Private Subnet"]
            EC2_1["🖥️ EC2-1<br/>Private IP: 10.0.1.10"]
            EC2_2["🖥️ EC2-2<br/>Private IP: 10.0.1.11"]
        end

        RT["🔀 Route Table<br/>VPC 內部路由"]
    end

    User -->|"1️⃣ 請求打到公網 IP"| LB
    LB -->|"2️⃣ 查 Route Table"| RT
    RT -->|"3️⃣ 走 VPC 內網"| EC2_1
    RT -.->|"備用路徑"| EC2_2

    style Internet fill:#ffe6e6,stroke:#cc0000
    style PublicSubnet fill:#cce5ff,stroke:#004085
    style PrivateSubnet fill:#e8f4ea,stroke:#2d6a4f
    style VPC fill:#f5f5f5,stroke:#666666

流程說明

1. 用戶請求打到 Load Balancer 的公網 IP（在 Public Subnet）
2. Load Balancer 查 Route Table，找到目標 EC2 的路徑
3. 流量透過 VPC 內部網路 轉發到 Private Subnet 的 EC2

💡 重點：第 2、3 步都是走 VPC 內網，不會繞到外面去，所以速度快、延遲低。

轉發流量需要的網路元件

所以 VPC 資訊不可或缺

Load Balancer 需要知道 Target 在哪個 VPC，才能：

• 在對的 VPC 裡建立 ENI
• 透過對的 Route Table 找到 Target
• 確保 Security Group 允許流量通過

舉個完整的例子

假設你有兩台 EC2 當 web server：

建 Target Group 時選 vpc-aaa，會發生什麼事？

1. Target Group 知道去哪裡找機器

• 去 vpc-aaa 裡面找 10.0.1.10 和 10.0.1.11
• 不會跑去其他 VPC 亂找

2. 健康檢查可以正確執行

• Load Balancer 在 vpc-aaa 裡面發 HTTP GET 請求
• 走 VPC 內部網路到達 EC2
• 透過 sg-web Security Group 進入

3. 流量轉發有正確路徑

• 用戶請求進來 → Load Balancer 收到
• 查 Target Group → 發現 web-01 和 web-02 都健康
• 透過 vpc-aaa 的內部路由 → 把流量丟給其中一台

如果你不選 VPC 會怎樣？

AWS 不讓你這樣做。建 Target Group 時 VPC 是必填欄位，因為：

• 10.0.1.10 可能存在於好幾個 VPC
• 不知道 VPC 就不知道網路路徑
• 健康檢查和流量轉發都會失敗

一個 Target Group 只能配一個 VPC（以及怎麼繞過這個限制）

AWS 的硬規定：一個 Target Group 只能綁一個 VPC

這是 AWS 的設計限制，沒有例外。當你建立 Target Group 時，選了 vpc-aaa，就只能放 vpc-aaa 裡面的機器，不能混著放 vpc-bbb 的機器進去。

在 Console 上長這樣：

建立 Target Group
├── Target Group 名稱：my-web-targets
├── Target Type：Instance
├── VPC：vpc-aaa ← 選了就不能改，也不能選多個
└── ...

建立 Target Group
├── Target Group 名稱：my-web-targets
├── Target Type：Instance
├── VPC：vpc-aaa ← 選了就不能改，也不能選多個
└── ...

為什麼 AWS 要這樣限制？

很多人會覺得這個限制很煩，但其實背後有很實際的原因：

原因一：健康檢查會變得超複雜

假設 AWS 允許你把 vpc-aaa 和 vpc-bbb 的機器放在同一個 Target Group：

flowchart LR
    subgraph VPC_A["VPC-A"]
        LB["Load Balancer"]
        EC2_A["EC2-A<br/>10.0.1.10"]
    end

    subgraph VPC_B["VPC-B"]
        EC2_B["EC2-B<br/>10.0.2.20"]
    end

    LB -->|"健康檢查 ✅ 簡單"| EC2_A
    LB -.->|"健康檢查 ❓ 怎麼過去？"| EC2_B

    style VPC_A fill:#e8f4ea,stroke:#2d6a4f
    style VPC_B fill:#fff3cd,stroke:#856404

問題來了：

• Load Balancer 在 vpc-aaa，要怎麼 ping 到 vpc-bbb 的機器？
• 兩個 VPC 預設是隔離的，網路不通
• 你要先設定 VPC Peering 或 Transit Gateway
• 還要改 Route Table、Security Group…
• 萬一設錯，健康檢查就失敗，流量就斷了

AWS 乾脆不讓你這樣做，省得你踩坑。

原因二：效能會變差

VPC 內部的網路是最快的，延遲通常在 0.1ms 以下。

但如果跨 VPC：

對於高流量的網站來說，這個延遲差異會累積起來，影響用戶體驗。

原因三：管理會變成噩夢

如果允許跨 VPC，你要處理的東西：

AWS 限制在同一個 VPC，就是幫你省掉這些麻煩。

那如果我真的需要跨 VPC 怎麼辦？

有時候你的架構就是分散在不同 VPC，比如：

• 公司併購，兩邊的系統在不同 VPC
• 微服務架構，每個服務有自己的 VPC
• 開發/測試/正式環境分開在不同 VPC

這時候有兩種做法：

做法一：用 IP 類型的 Target（土砲但有效）

概念

不用 Instance 類型，改用 IP 類型的 Target。這樣你可以手動輸入任何 IP，包括其他 VPC 的機器。

步驟

1. 建 Target Group 時，Target Type 選 ip（不是 instance）
2. 手動輸入另一個 VPC 中 EC2 的 Private IP
3. 但是！網路要先打通

網路打通的 checklist

架構圖

flowchart LR
    subgraph VPC_A["VPC-A"]
        LB["Load Balancer"]
        TG["Target Group<br/>（IP 類型）"]
        EC2_A["EC2-A<br/>10.0.1.10"]
    end

    subgraph VPC_B["VPC-B"]
        EC2_B["EC2-B<br/>10.0.2.20"]
    end

    Peering["🔗 VPC Peering<br/>或 Transit Gateway"]

    LB --> TG
    TG --> EC2_A
    TG -.->|"跨 VPC"| Peering
    Peering -.-> EC2_B

    style VPC_A fill:#e8f4ea,stroke:#2d6a4f
    style VPC_B fill:#cce5ff,stroke:#004085
    style Peering fill:#fff3cd,stroke:#856404

優點

• 不用改太多架構
• 現有的 Load Balancer 可以繼續用

缺點

• IP 要自己管，EC2 換了 IP 你要手動更新
• 沒有 Auto Scaling 的自動註冊功能
• 網路設定比較複雜，出錯不好除錯

做法二：用 PrivateLink 或 API Gateway（乾淨但成本高）

概念

不要硬把不同 VPC 的機器塞進同一個 Target Group。改成每個 VPC 各自建立服務，然後用 PrivateLink 或 API Gateway 串起來。

架構圖

flowchart TB
    User["👤 用戶"]

    subgraph Main["主要 VPC"]
        APIGW["🌐 API Gateway<br/>或 ALB"]
    end

    subgraph VPC_A["VPC-A"]
        LB_A["ALB-A"]
        TG_A["Target Group A"]
        EC2_A["EC2-A"]
        Endpoint_A["🔌 VPC Endpoint"]
    end

    subgraph VPC_B["VPC-B"]
        LB_B["ALB-B"]
        TG_B["Target Group B"]
        EC2_B["EC2-B"]
        Endpoint_B["🔌 VPC Endpoint"]
    end

    User --> APIGW
    APIGW -->|"PrivateLink"| Endpoint_A
    APIGW -->|"PrivateLink"| Endpoint_B
    Endpoint_A --> LB_A --> TG_A --> EC2_A
    Endpoint_B --> LB_B --> TG_B --> EC2_B

    style Main fill:#ffe6e6,stroke:#cc0000
    style VPC_A fill:#e8f4ea,stroke:#2d6a4f
    style VPC_B fill:#cce5ff,stroke:#004085

這樣做的好處

缺點

兩種做法怎麼選？

Target Type 有三種，搞清楚差別

建 Target Group 時要選 Target Type，這邊快速講一下三種的差別：

Instance 類型

特性

• 用在 EC2
• 直接選 Instance ID 就好
• 一定要跟 Target Group 在同一個 VPC

適合場景

傳統的網站架構，EC2 數量固定或用 Auto Scaling Group 管理。

IP 類型

特性

• 可以是任何 Private IP
• 手動輸入 IP 位址
• 可以跨 VPC（但網路要自己打通）

適合場景

跨 VPC 架構、連接地端機器、或是 ECS awsvpc 網路模式。

Lambda 類型

特性

• 用在無伺服器架構
• 選 Lambda 函數就好
• 沒有 VPC 限制

適合場景

輕量級 API、Webhook、或是不想管伺服器的場景。

常見問題快問快答

Security Group 記得開

常見的坑

Target Group 的健康檢查會從 Load Balancer 打過來，記得在 EC2 的 Security Group 開放對應的 port。

最常見的坑：健康檢查一直失敗，結果是 Security Group 沒開。

怎麼設定

在 EC2 的 Security Group 加一條：

健康檢查路徑別亂設

為什麼重要

如果你用 HTTP 健康檢查，記得設一個專門的路徑，像是 /health 或 /ping。不要用 / 首頁，因為首頁可能會重導向或需要登入，導致健康檢查失敗。

好的健康檢查端點應該

• 回傳 200 OK
• 不需要登入驗證
• 回應速度快（不要做太多運算）
• 可以順便檢查資料庫連線狀態

總結

搞懂這個，你對 AWS 負載平衡的理解就會清楚很多。下次建 Target Group 的時候，就不會再困惑為什麼要選 VPC 了。