如果你剛開始接觸 AWS，看到 Load Balancer、Target Group、VPC 這些名詞可能會有點頭痛。別擔心，這篇文章會用最白話的方式，帶你一步步理解它們是什麼、怎麼運作、為什麼要這樣設計。
簡單來說，這些東西就是在處理一件事：怎麼把使用者的請求，安全又聰明地分配給後端的伺服器。
先搞懂網路基礎架構
在講 Load Balancer 之前，我們需要先認識幾個 AWS 網路的基本元件，不然後面會看不懂。
VPC — 你的專屬網路空間
VPC（Virtual Private Cloud）就是你在 AWS 裡擁有的一塊獨立、專屬的網路空間。
想像你買了一塊地，圍起來變成一個封閉社區。這個社區是你的，外人進不來，你可以決定裡面要蓋什麼、怎麼規劃。
AZ — 不同的機房
AZ（Availability Zone）是 AWS 在同一個地區內的不同機房。
重點是：這些機房彼此獨立，一個故障不會影響另一個。
就像你的社區橫跨兩個街區，就算其中一個街區停電，另一個街區還是有電。所以我們通常會把服務分散放在不同的 AZ，確保高可用性。
Subnet — 社區裡的分區
Subnet（子網路）就是把 VPC 這個社區再劃分成不同區域。
通常會分成兩種：
Public Subnet（公開子網路）
社區裡靠近大門的區域，外面的人可以直接走進來。適合放需要對外服務的東西，例如 Load Balancer。
Private Subnet（私有子網路）
社區裡面比較內部的區域，外人不能直接進入，要透過管理員（ALB）帶進來。適合放後端伺服器、資料庫這些你不想直接暴露的資源。
Internet Gateway — 社區大門
IGW（Internet Gateway）就是這個社區的大門，所有從外面進來的流量都要經過它。
沒有這道門，你的社區就是完全封閉的，外面的人進不來。
認識 Load Balancer
搞懂網路架構後，我們來看主角。
ALB — 聰明的接待員
ALB（Application Load Balancer）的工作就是：接收所有使用者的請求，然後聰明地分配給後端的伺服器。
想像你開了一家超人氣餐廳，門口擠滿了客人。ALB 就是站在門口的接待員，負責接待所有上門的客人，然後決定要把他們帶到哪一桌。
ALB 放在哪裡？
這是很多人搞混的地方，讓我說清楚：
ALB 的節點是放在 Public Subnet 裡面的。
當你建立一個 ALB 時，AWS 會要求你選擇至少兩個不同 AZ 的 Subnet。然後 ALB 會在每個你選的 Public Subnet 裡面各放一個節點。
為什麼要放在不同 AZ？為了高可用性。如果某個 AZ 的機房掛了，另一個 AZ 的 ALB 節點還可以繼續服務。
ALB 資源 vs ALB 節點
這邊要區分一下：
- ALB 資源：你在 AWS 創建時取的名稱（例如
my-application-alb），這是你管理的單位 - ALB 節點：AWS 自動幫你在各個 Subnet 裡建立的實際機器，你不用管它
你操作的是同一個 ALB 資源，但背後 AWS 會自動管理多個節點來處理流量。
認識 Target Group
Target Group — 後端伺服器的名單
Target Group 就是一份「名單」，上面記錄著哪些後端伺服器可以處理請求。
ALB 收到請求後，會去查這份名單，然後從裡面挑一台健康的伺服器來處理。
舉個例子，假設你有一個 web-tg 的 Target Group，裡面登記了三台 EC2：
Target Group: web-tg
├── EC2-A (10.0.10.11) ✅ 健康
├── EC2-B (10.0.10.12) ✅ 健康
└── EC2-C (10.0.10.13) ❌ 不健康當請求進來，ALB 只會把流量分給 EC2-A 或 EC2-B，不會送去 EC2-C。
Target Group 裡面有什麼設定？
建立 Target Group 時，你需要設定幾個東西：
| 設定項目 | 說明 | 範例 |
|---|---|---|
| 名稱 | 這份名單叫什麼 | web-tg、api-tg |
| Target Type | 名單上要放什麼類型的目標 | EC2、IP、Lambda |
| Protocol | 用什麼協定跟後端溝通 | HTTP、HTTPS |
| Port | 後端伺服器監聽的 Port | 80、3000、8080 |
| VPC | 這些目標在哪個 VPC 裡 | 你的 VPC |
| Health Check | 怎麼檢查目標是否健康 | 每 30 秒打一次 /health |
Target Type — 名單上可以放誰？
Target Group 支援三種類型的目標：
Instance（EC2 執行個體）
最常見的選擇。你直接把 EC2 的 Instance ID 加進名單，例如 i-0abc123def456。ALB 會自動去找這台 EC2 的 IP 來送流量。
IP（IP 位址）
直接指定 IP 位址，例如 10.0.10.50。這個適合：
- 目標不是 EC2（例如地端機器透過 VPN 連進來）
- 你想更精確控制流量要送去哪
Lambda（Lambda 函數）
把 Lambda 函數當作後端。請求進來就直接觸發 Lambda 執行，完全不用管伺服器。適合流量不穩定、不想一直開機器的場景。
認識 Listener 與 Routing Rules
Listener — ALB 的服務窗口
當你建立 ALB 之後，還要設定 Listener，告訴 ALB「你要聽哪些 Port 進來的請求」。
最常見的設定：
- HTTP :80 — 一般網頁流量
- HTTPS :443 — 加密的網頁流量
你可以想像成櫃檯開了幾個服務窗口，客人要到對的窗口才會被受理。
一個 ALB 可以同時設定多個 Listener，例如同時聽 80 和 443。
Routing Rules — ALB 的分派規則
光是聽到請求還不夠，ALB 還要知道「這個請求要轉給誰處理」。
這就是 Routing Rules（路由規則） 的工作。它會根據你設定的條件，決定把請求轉給哪個 Target Group。
例如：
- 網址是
/api/users開頭 → 轉給 users-tg - 網址是
/api/orders開頭 → 轉給 orders-tg - 都不符合 → 回傳 404
每個 Listener 底下都可以設定多條 Routing Rules。
ALB、Listener、Routing Rules、Target Group 怎麼一起運作？
這四個東西是一起運作的，我們用一個具體情境來說明：
假設你開了一家公司，有兩個部門：
- 客服部門：處理客戶問題
- 業務部門：處理訂單
你請了一個櫃檯人員，負責接待所有上門的客人。
| 現實世界 | AWS 元件 | 負責什麼 |
|---|---|---|
| 櫃檯人員 | ALB | 接收所有請求 |
| 櫃檯開的服務窗口 | Listener | 決定要聽哪些 Port（80、443） |
| 櫃檯的分派規則 | Routing Rules | 根據條件決定找哪個部門 |
| 各部門的員工名單 | Target Group | 記錄誰可以處理工作 |
完整流程是這樣跑的
Step 1：Listener 決定要不要受理
客人來到櫃檯，櫃檯有兩個窗口：
- 80 號窗口（HTTP）
- 443 號窗口（HTTPS）
客人要先到對的窗口，櫃檯才會受理。
Step 2：Routing Rules 決定找哪個部門
客人：「我要問產品問題」（請求 /api/support）
櫃檯看規則：「/api/support 開頭的是客服的事」→ 找客服部門
客人：「我要下訂單」（請求 /api/orders）
櫃檯看規則：「/api/orders 開頭的是業務的事」→ 找業務部門Step 3：Target Group 決定分給誰
櫃檯查客服部門的員工名單（support-tg）：
├── 小明 ✅ 有空
├── 小華 ✅ 有空
└── 小美 ❌ 請假中（不健康）
→ 把工作分給小明或小華，不會給小美對應到 AWS 實際設定
ALB: my-application-alb
│
├── Listener: HTTP :80
│ │
│ └── Routing Rules（路由規則）:
│ ├── IF path = /api/support → 轉給 support-tg
│ ├── IF path = /api/orders → 轉給 orders-tg
│ └── 都不符合 → 回傳 404
│
└── Listener: HTTPS :443
│
└── Routing Rules:
└── （跟上面一樣的規則）
Target Groups:
├── support-tg（客服部門名單）
│ ├── EC2-A (10.0.10.11) ✅ Healthy
│ └── EC2-B (10.0.10.12) ✅ Healthy
│
└── orders-tg（業務部門名單）
├── EC2-C (10.0.20.11) ✅ Healthy
└── EC2-D (10.0.20.12) ❌ Unhealthy（不會收到請求）Routing Rules 可以根據什麼條件分流？
| 條件類型 | 範例 | 用途 |
|---|---|---|
| 路徑 | /api/users、/api/products | 根據 URL 路徑分到不同服務 |
| 網域 | admin.example.com、api.example.com | 根據子網域分到不同服務 |
| Header | X-App-Version: v2 | 根據特定 Header 做 A/B 測試 |
| Query String | ?platform=mobile | 根據參數分流到不同版本 |
為什麼 Target Group 要獨立出來？
想像一下這個情況：
客服部門要加人了
❌ 如果名單寫死在櫃檯的規則裡：
- 你要去改 Routing Rules
- 等於要重新設定 ALB
✅ 如果名單是獨立的（Target Group）：
- 直接在客服名單加一個人就好
- 櫃檯的規則完全不用動
搭配 Auto Scaling 更強大
當流量暴增，AWS 自動幫你多開幾台 EC2：
- 新機器自動加進 Target Group 名單
- ALB 馬上就能把流量分給它們
流量變小，多餘的機器被關掉：
- 自動從名單移除
- 整個過程全自動，你不用改任何設定
完整請求流程
現在我們把所有元件串起來，看看一個請求是怎麼跑的：
一個重要觀念：VPC 內部路由
你可能會問：「ALB 在 Public Subnet，EC2 在 Private Subnet，它們怎麼溝通？」
答案是：同一個 VPC 內，Public 跟 Private Subnet 天生就可以互相溝通。
它們不需要繞出去再繞回來，直接透過 VPC 內部的路由就可以連線。這也是為什麼我們可以把 EC2 放在 Private Subnet（比較安全），但 ALB 還是可以把流量送過去。
Health Check：確保機器還活著
Target Group 裡有一個超重要的功能：Health Check（健康檢查）。
ALB 會定期去「戳」名單上的每一台機器，確認它還活著。如果某台機器沒回應，就會被標記為「不健康」，ALB 就不會再把請求送給它。
重點：只有健康的機器才會收到請求！
可以設定的參數
| 參數 | 說明 |
|---|---|
| Path | 檢查哪個網址，通常是 /health |
| Interval | 多久檢查一次，例如每 30 秒 |
| Timeout | 等多久算超時 |
| Healthy Threshold | 連續幾次成功才算健康 |
| Unhealthy Threshold | 連續幾次失敗才算不健康 |
常見問題快問快答
在裡面。ALB 的節點會被放在你指定的 Public Subnet 裡。
安全。Private Subnet 不能直接從外面連進來，只有透過 ALB 才能存取。
同一個 VPC 內，它們天生就可以互通，透過內部路由就好。
就是一份後端伺服器的名單，ALB 根據這份名單決定把請求送去哪。
設在 Target Group 裡面。每個 Target Group 可以有自己的健康檢查設定。
小結
把握這幾個重點，你就算入門了：
- VPC 是你的專屬網路空間，裡面分成 Public 跟 Private Subnet
- ALB 放在 Public Subnet，負責接收和分配請求
- Target Group 是後端伺服器的名單，ALB 根據它來轉發請求
- EC2 通常放在 Private Subnet，比較安全
- Health Check 確保只有健康的機器會收到請求
- 同一個 VPC 內，Public 跟 Private Subnet 可以直接互通
下一步可以研究 Auto Scaling Group 怎麼跟 Target Group 搭配，讓你的服務能根據流量自動伸縮！