AWS帳號充值方案 AWS伺服器如何配置負載均衡ELB

前言：為什麼要用 ELB

把網站或 API 部署到 AWS 後，你很快會遇到同一個問題：流量來了以後怎麼辦？單一台 EC2 固然能跑，但面對突發流量、維護或故障，停機風險會明顯上升。這時候你需要一個「流量分配器」，讓使用者的請求能平均或依規則分發到多台後端，並且能在某台後端失效時自動摘除。

AWS 的 ELB（Elastic Load Balancing）就是解決方案。它不只是把流量平均分散而已，還提供了監聽器、路由規則、健康檢查、TLS 終止、以及與自動擴展的整合能力。更重要的是，你不必自己寫負載均衡程式、也不必維護硬體設備。

本文會用「你真的要上線」的角度，逐步講清楚如何配置負載均衡 ELB：從規劃架構，到建立目標群組、設定監聽器與健康檢查，再到與 Auto Scaling 協作，最後補上常見錯誤的排查方式。

第一章：先選對 ELB 類型

AWS 目前主力有三種負載均衡：Application Load Balancer（ALB）、Network Load Balancer（NLB）以及較舊的 Classic Load Balancer（CLB）。你要先搞清楚它們各自擅長什麼，否則後面配置會卡得很痛。

ALB：面向 Web 應用，做路由規則很強

ALB 適合 HTTP/HTTPS 流量，支援根據 URL 路徑、主機名（Host header）、查詢參數或標頭等條件進行路由。它也更容易與現代 Web 架構整合，例如使用 WebSocket、OIDC 登入流程（配合其他服務）、以及對應用層的健康檢查。

大多數網站、後台管理、一般 API，都建議優先選 ALB。

NLB：面向 TCP/UDP，高吞吐與低延遲

NLB 偏向傳輸層（L4），對 TCP/UDP 特別友好，常見於需要極低延遲或特定協定的場景，例如部分遊戲服務、訊息傳遞、或特殊網路需求。若你不需要複雜的 HTTP 路由，而是更在意吞吐與穩定性，NLB 是不錯選擇。

Classic ELB：較舊的配置方式，今天通常不建議新案採用

Classic ELB 仍可用於既有系統，但新案多半不需要它。ALB 與 NLB 的功能與彈性更好，且未來演進更明顯。

本文示範：以 ALB 為主

AWS帳號充值方案 為了讓流程更貼近實際 Web/HTTP 案例，後文主要用 ALB 來示範配置。你若使用 NLB，概念仍類似：建立負載均衡器 → 建立目標群組 → 配置端口與監聽 → 健康檢查 → 綁定 Auto Scaling 或手動掛上後端。但介面與一些細節會有所不同。

第二章：規劃網路與基本前提

開始建立 ALB 前，先確認幾個關鍵前提。這一步常被忽略，但實際上它決定你之後能不能順利通。

子網（Subnets）與可用區（AZ）

負載均衡器通常會部署在多個可用區，以確保某一個 AZ 出問題時仍可提供服務。你至少應該選兩個子網（不同 AZ）。

後端 EC2（或其他目標）也要在相對應的 VPC 中，並且它們的網路安全設定必須允許來自 ALB 的流量。

VPC 與路由

確認 ALB 所在子網與後端目標之間的路由是通的。若你使用私有子網放後端，通常需要 NAT（或透過 VPC Endpoints）確保後端能更新套件或存取必要資源；但這跟「ALB 能不能把流量打到後端」是兩件事。

安全群組（Security Group）是核心

ALB 通常會有自己的安全群組。你需要：

• 讓 ALB 的安全群組允許來自外部的流量（例如 443/80）。
• 讓後端目標的安全群組允許來自 ALB 安全群組的流量（例如 80 或你實際應用端口）。

常見錯誤是你只放行了公開網際網路，但後端其實是「只允許 ALB」的方向沒有設好，結果健康檢查失敗或請求一直 502/504。

第三章：建立 ALB（Application Load Balancer）

以下流程以建立一個面向外部的 ALB 為例。實際介面名稱可能依 AWS 控制台版本略有不同，但概念一致。

步驟 1：建立負載均衡器

在 AWS 管理主控台進入 EC2 > Load Balancers，選擇 Create load balancer。

• 選擇類型：Application Load Balancer。
• 選擇 scheme：通常選 internet-facing（對外服務）；內部服務則可選 internal。
• 選擇 VPC。
• 選擇至少兩個子網（跨 AZ）。
• AWS帳號充值方案 指定安全群組：例如 ALB-SG。

如果你要走 HTTPS，你還要準備憑證（ACM）。憑證可在建立監聽器時選擇。

AWS帳號充值方案 步驟 2：建立目標群組（Target Group）

目標群組是 ALB 把流量導向後端的依據。你要設定：

• 協定與埠（Protocol/Port）：例如 HTTP:80 或 HTTPS:443（視你後端怎麼跑）。
• 目標類型（Target type）：常見是 Instance（EC2），也可能是 IP（如果後端不是 EC2，比如容器或外部 IP）。本文先用 Instance。
• VPC：必須與負載均衡器相同。

建立後你會看到目標群組的細項設定，例如健康檢查、慢啟動（deregistration delay）等。接下來重點是健康檢查。

步驟 3：設定健康檢查（Health Check）

健康檢查決定 ALB 判斷後端是否可用。若健康檢查設定不合理，你會看到：

• 負載均衡器判定目標不健康，結果流量不會轉發。
• 或你以為服務正常，但健康檢查一直 404/超時。

健康檢查至少需要考慮：

• 協定與路徑：例如 HTTP /healthz。
• 通過判定：200-399 之類的範圍（預設通常可用）。
• 間隔與逾時：Interval、Timeout、Healthy threshold、Unhealthy threshold。

建議實務做法：

• 後端提供一個簡單健康檢查端點，只做必要檢查，不要把健康端點做成昂貴的外部呼叫。
• 區分 readiness 與 liveness 的概念（若你使用框架或容器可更精準）；對 ALB 來說，至少確保健康端點能在服務啟動後快速回應。
• 若你使用灰度或有版本切換，健康端點可以依版本返回不同狀態碼，但要符合 ALB 判定邏輯。

第四章：配置監聽器與路由（Listener & Routing Rules）

監聽器是 ALB 接收連線的入口。你可以在同一個負載均衡器上設定多個監聽器，例如：

• 80（HTTP）→ 跳轉到 443（HTTPS）
• 443（HTTPS）→ 根據路徑路由到不同目標群組

即使你只有單一目標群組，也應設定好監聽器與預設規則。

步驟 1：建立監聽器（Listener）

在 ALB 的 Listeners 區塊新增 Listener：

• 協定：HTTP 或 HTTPS。
• 埠：例如 443。
• SSL 憑證：若是 HTTPS，需要從 ACM 選取或上傳。
• Default action：轉送到目標群組（Target group）。

步驟 2：設定規則（Rules）

規則常見用法：

• 依 URL 路徑轉發：/api/* → api-target-group；/admin/* → admin-target-group。
• 依網域名稱轉發：不同子網域對應不同目標群組。
• 依標頭轉發：例如特定條件走灰度版本。

建議：先把路由規則保持簡單，確保單一路徑打通後再加入複雜條件。你會更容易定位問題。

步驟 3：啟用 HTTP 到 HTTPS 的導流（可選但建議）

如果你要強制使用 HTTPS，一般會：

• 在 80 的監聽器設定 redirect action 到 443。
• 避免同時提供混合流量造成憑證或重定向問題。

第五章：把後端掛上去（Register Targets）

目標群組建立後，你需要把後端 EC2（或其他目標）掛上去。這部分影響你是否能立刻通。

AWS帳號充值方案 手動掛載 EC2（適合測試）

在 Target group 裡選擇 Targets，點 Add targets，把目標 Instance 選進去。掛上後等待健康狀態變為 healthy。

如果長時間不是 healthy，通常是：

• 後端安全群組沒有允許入站。
• 健康檢查路徑錯誤（例如 /healthz 實際回 404）。
• 應用服務沒在該埠 listen。
• 後端回應太慢或超時。

使用 Auto Scaling（適合正式環境）

正式環境通常會使用 Auto Scaling Group（ASG）。做法是：

• 建立 Launch Template（含 AMI、instance type、安全群組、啟動腳本等）。
• 建立 ASG 並選擇目標群組。
• 設定 Desired/Min/Max Capacity。
• 選擇伸縮策略：用 CPU、RequestCount、或自訂指標。

當 ASG 新增實例時，它會自動註冊到目標群組。健康檢查通過後才會開始分流，這能降低冷啟動造成的錯誤。

第六章：啟用 TLS 與憑證最佳實務

如果你用 HTTPS，上線時最容易出錯的不是路由，而是憑證或 TLS 設定。

ACM 憑證的基本流程

通常你會用 ACM 申請憑證，完成域名驗證（DNS 或 email）。驗證通過後，憑證就能用於 ALB 監聽器。

建議做到：

• 憑證類型匹配：單一網域或通配符。
• 確定憑證覆蓋的網域名就是你實際訪問的網域。
• 設定好到期提醒或自動續約流程。

TLS 終止位置：放在 ALB 通常更簡單

實務上常見做法是「TLS 終止於 ALB」，也就是外部用 HTTPS 連到 ALB；ALB 再以 HTTP（或 HTTPS）轉發到後端。這樣你集中管理憑證，也降低後端的配置負擔。

若你後端也要端到端加密，可用 HTTPS，但你要確保後端也有憑證或採用私有端證書方案。

第七章：健康檢查與除錯思路（非常關鍵）

ELB 能不能用，常常不是「你做了什麼」，而是「你怎麼驗證」。以下提供一套從外到內、由表入裡的排查順序。

第一層：確認前端到 ALB 的連線

• AWS帳號充值方案 用瀏覽器或 curl 直接訪問 ALB 的 DNS/自訂網域。
• 若是 HTTPS，先確認憑證是否正確，是否有重定向循環。
• 若回應是 502/503，通常代表 ALB 沒有可用目標或路由問題。

第二層：看目標群組健康狀態（Target Health）

在目標群組內查看每個目標是 healthy / unhealthy。若全部 unhealthy，你幾乎可以直接鎖定健康檢查或網路安全設定。

• 若是某些 unhealthy：可能是特定實例或其安全群組設定有差異。
• 若全部不健康且是健康檢查路徑錯：通常會是 404 或超時。

第三層：檢查後端安全群組與防火牆

安全群組常見問題：

• 後端 SG 沒有允許 ALB SG 對應埠。
• 後端 OS 層（例如 iptables、ufw）擋住了連線。
• AWS帳號充值方案 你配置了不同埠：例如 ALB 導到 80，但後端實際用 8080。

第四層：檢查健康檢查端點回應

健康檢查端點要保證：

• 路徑存在並回應預期狀態碼。
• 在冷啟動期間也能在健康檢查的節奏內回應。
• 不依賴外部服務的成功結果（否則外部一掛就全站被判為不健康）。

第五層：確認應用是否真的在 listen

到 EC2 上檢查：

• AWS帳號充值方案 服務是否啟動。
• 監聽埠是否正確（例如 netstat 或 ss）。
• 若你使用 Docker，容器映射與主機安全設定是否一致。

第八章：與自動擴展（Auto Scaling）協作

當你有多台後端時，負載均衡是前半段；後半段是「當流量增加時自動補上」。ASG 讓容量跟著需求走，降低你手動干預的成本。

擴展觸發條件（建議不要只看 CPU）

很多網站 CPU 可能不高，但請求量已經爆了。你可以考慮用：

• ALB 的 RequestCount（每秒請求數）
• 延遲或錯誤率指標（若你有整合監控）
• AWS帳號充值方案 自訂指標（例如隊列長度、背景任務堆積）

CPU 仍可作為參考，但不要把它當成唯一真相。

健康狀態與新實例冷啟動（Grace period）

新實例加入時應用可能需要初始化（讀配置、連線 DB、載入緩存）。如果你健康檢查過於敏感，會導致實例被反覆登出/登入。

常見做法：

• 調整健康檢查的時間參數（interval、timeout、threshold）。
• 設定 ASG 的 health check grace period（如果使用 instance health 或與系統檢查搭配）。
• 讓健康端點在必要初始化完成後才回應成功，避免過早宣告 ready。

第九章：常見錯誤與快速修正

下面列出一些最常見的 ELB 配置坑，你可以把它當作上線前的自查清單。

錯誤一：健康檢查路徑不正確

你在目標群組設定的路徑是 /healthz，但實際服務是 /health 或 /status。結果健康檢查永遠回 404，ALB 一直判定 unhealthy。

修正：確認後端實際端點，並用測試確認回應碼與內容。

錯誤二：後端沒開對埠或安全群組沒放行

AWS帳號充值方案 ALB 導到 80，但後端只在 8080 listen；或安全群組沒有允許來自 ALB SG。

修正：核對 ALB target group 的 port，並檢查後端 SG 入站規則。

錯誤三：回應時間太長導致健康檢查超時

你把健康端點寫得很複雜，例如等待外部服務回應才返回成功。當外部服務稍慢，健康檢查就超時。

修正：健康端點只做必要檢查；外部依賴應在更合理的方式下影響業務狀態，而不是直接拖垮健康檢查。

錯誤四：HTTPS 憑證與網域不匹配

你用的是憑證 A 覆蓋了 example.com，但實際訪問是 api.example.com，或相反。

AWS帳號充值方案 修正：確認憑證涵蓋的網域與 SAN，必要時重新申請或選用通配符憑證。

錯誤五：路由規則沒符合到目標

你設定了規則：Host = admin.example.com 才導向 admin 目標群組，但實際請求的 Host 不對（例如忘了 DNS 指向），結果落在預設 action 或直接導向錯誤群組。

修正：檢查請求的 Host header；確認規則優先序與預設 action。

第十章：上線前檢查清單（建議照做）

在你正式把流量導到 ELB 前，花幾分鐘做確認，能省下後面一整天的排錯。

• ALB 所在子網跨兩個或更多 AZ，且目標群組目標在同一 VPC。
• ALB 監聽器設定正確（80/443、憑證、預設轉送到正確目標群組）。
• 目標群組 port/協定設定正確，健康檢查路徑存在且回應碼符合預期。
• 後端安全群組允許來自 ALB 安全群組的入站埠。
• 目標群組顯示 healthy，且在替換或重啟後仍能維持穩定。
• 若搭配 Auto Scaling，確認冷啟動與 grace period 設定合理，避免反覆摘除。
• 監控與告警已設定（ALB 目標錯誤率、延遲、5xx、健康檢查失敗等）。

結語：把 ELB 當成「流量的安全閘門」

AWS 的 ELB 不是單純的「加一個負載均衡器」，而是把流量、健康狀態與容量管理串成一個系統。ALB 讓你能以應用層規則導流；目標群組讓你定義什麼叫做「可接收流量」；健康檢查則替你持續監控後端是否真的正常。再加上 Auto Scaling，你的服務就能在故障與壓力下依然維持穩定。

只要你遵循一個原則：先確保健康檢查通過、再逐步增加路由規則與擴展策略，你就能快速把 ELB 正確落地。等下一次你遇到 502 或健康狀態異常時，你也會知道該從哪一層開始查，避免陷入盲目調整。

如果你希望我再用你的實際情境（例如：你用 ALB 還是 NLB、後端是 EC2 還是容器、是否要 HTTPS、健康檢查路徑等）把步驟寫成可直接照做的版本，告訴我你的架構與端口，我可以幫你整理一份更貼近你系統的配置清單。