AWS ELB 實用入門指南 – 讓你的網站不再當機

Published August 13, 2025 by 徐培鈞
架構

在現代網路世界中，成功的網站往往面臨一個甜蜜的煩惱：用戶太多了！

當越來越多人造訪你的網站時，單一伺服器很快就會不堪負荷。

這時候，你需要的不只是更多伺服器，還需要一個聰明的「交通指揮」來管理這些流量。

AWS ELB (Elastic Load Balancer) 就是這個智能的交通指揮系統，它能確保你的網站在任何情況下都能穩定運行，給用戶最佳的使用體驗。

從單一伺服器到負載均衡架構

單一伺服器的困境

最初的簡單架構

graph TB
    User[用戶] --> Domain[網域名稱]
    Domain --> Server[單一伺服器]
    Server --> DB[(資料庫)]

    %% 樣式設定
    classDef userStyle fill:#e1f5fe,stroke:#01579b,stroke-width:2px
    classDef serverStyle fill:#f3e5f5,stroke:#4a148c,stroke-width:2px
    classDef dbStyle fill:#e8f5e8,stroke:#1b5e20,stroke-width:2px
    classDef domainStyle fill:#fce4ec,stroke:#880e4f,stroke-width:2px

    class User userStyle
    class Server serverStyle
    class DB dbStyle
    class Domain domainStyle

現實中會遇到的問題

流量問題

  • 同時只能處理有限的用戶
  • 流量高峰時網站變慢
  • 嚴重時可能完全當機

可靠性問題

  • 伺服器故障 = 網站完全無法使用
  • 維護更新時必須停機
  • 沒有備援方案

擴展性問題

  • 無法快速應對流量增長
  • 硬體升級有極限
  • 成本效益不佳

多伺服器架構的需求

從單一到多台伺服器的思考

當網站成長到一定規模，單一伺服器已經無法滿足需求時，我們自然會想到：

  • 用多台伺服器同時處理請求
  • 但問題來了：用戶的請求要怎麼分配給這些伺服器？
  • 如何確保每台伺服器的負載平均？
  • 當某台伺服器故障時，如何自動轉移流量？

這就是為什麼我們需要「負載均衡」。

什麼是負載均衡？

負載均衡的基本概念

銀行櫃台的比喻

想像一下銀行的櫃台服務：如果只有一個櫃員，客人就要排很長的隊；但如果有多個櫃員，還有一個服務人員負責引導客人到最短的隊伍，整體效率就會大幅提升。

負載均衡的核心原理

負載均衡 (Load Balancing) 就是這個概念在網路世界的應用：

  • 智能分配：把工作（網站請求）分散給多個工作者（伺服器）
  • 負載監控：確保沒有任何一個工作者過度忙碌
  • 自動容錯：當某個工作者無法工作時，其他人可以接手

負載均衡架構的優勢

新架構帶來的改變

加入負載均衡器後：

graph TB
    User[用戶] --> LB[負載均衡器]
    LB --> Server1[伺服器 1]
    LB --> Server2[伺服器 2]
    LB --> Server3[伺服器 3]
    Server1 --> DB[(資料庫)]
    Server2 --> DB
    Server3 --> DB

    %% 樣式設定
    classDef userStyle fill:#e1f5fe,stroke:#01579b,stroke-width:2px
    classDef serverStyle fill:#f3e5f5,stroke:#4a148c,stroke-width:2px
    classDef lbStyle fill:#fff3e0,stroke:#e65100,stroke-width:3px
    classDef dbStyle fill:#e8f5e8,stroke:#1b5e20,stroke-width:2px

    class User userStyle
    class Server1,Server2,Server3 serverStyle
    class LB lbStyle
    class DB dbStyle

立即獲得的好處

效能提升

  • 多台伺服器同時處理請求
  • 總處理能力倍數增長
  • 回應時間大幅縮短

高可用性

  • 一台伺服器故障，其他台繼續服務
  • 可以輪流維護，不需停機
  • 99.9% 以上的可用時間

靈活擴展

  • 流量增加時，快速加入新伺服器
  • 流量減少時，移除多餘伺服器
  • 按需付費，降低成本

AWS ELB：託管式負載均衡解決方案

什麼是 AWS ELB？

ELB (Elastic Load Balancer) 是 AWS 提供的完全託管負載均衡服務，它會：

  • 自動分散流量到多個目標
  • 持續監控伺服器健康狀態
  • 根據需求自動調整容量
  • 提供高可用性和安全性

為什麼選擇 ELB 而不是自建？

省時省力

  • AWS 負責維護和更新
  • 不需要專業的負載均衡知識
  • 幾分鐘就能完成設定

高可靠性

  • AWS 的基礎設施保證
  • 跨多個可用區域部署
  • 內建災難恢復機制

成本效益

  • 按使用量付費
  • 不需要購買昂貴的硬體負載均衡器
  • 自動擴展，避免資源浪費

ELB 的類型選擇

AWS 提供三種不同的 Load Balancer，每種都有最適合的使用場景：

Application Load Balancer (ALB) – 第7層負載均衡器

最適合：網站、API 服務、微服務架構

ALB 是最智慧的負載均衡器，它能「看懂」HTTP/HTTPS 請求的內容，做出聰明的分配決策。

智慧路由範例：

同一個網域，不同路徑可以導向不同服務：

  • example.com/api/* → API 伺服器群組
  • example.com/images/* → 檔案處理伺服器群組
  • example.com/admin/* → 管理後台伺服器群組
  • example.com/* → 一般網站伺服器群組

ALB 的進階功能：

基於內容的智慧路由

ALB 能夠「看懂」HTTP 請求的內容，並根據這些資訊做出聰明的路由決策。

根據 HTTP Header 分配流量：

  • 當 User-Agent 包含 “Mobile” 時 → 導向行動版伺服器
  • 當 Accept-Language 包含 “zh-TW” 時 → 導向繁體中文伺服器
  • 當 X-User-Role 為 “admin” 時 → 導向管理員專用伺服器

根據查詢參數分配流量：

  • 網址包含 ?version=beta → 導向 Beta 測試伺服器
  • 網址包含 ?region=asia → 導向亞洲區伺服器
  • 網址包含 ?experiment=new-ui → 導向新介面測試伺服器

智慧健康檢查機制

ALB 的健康檢查不只是簡單的 ping，而是真正模擬用戶請求來確保服務可用性。

這套機制能夠主動發現問題，並在伺服器出現異常時自動進行流量切換。

基本健康檢查設定：

  • 檢查頻率：每 30 秒發送一次 HTTP GET 請求到 /health 路徑
  • 檢查逾時：單次檢查的最大等待時間為 5 秒
  • 檢查路徑：可以自訂檢查路徑，如 /health、/status 或 /api/healthcheck
  • 期望回應：通常期望收到 HTTP 200 狀態碼

健康狀態判定規則：

  • 健康判定：連續 2 次檢查成功後，標記為健康狀態，開始分配流量
  • 故障判定：連續 5 次檢查失敗後，暫時移除該伺服器，停止分配新流量
  • 寬限期處理：新啟動的伺服器會有初始寬限期，避免因啟動時間較長而被誤判

自動恢復機制：

  • 漸進式恢復：伺服器修復後會自動重新加入負載均衡群組
  • 流量預熱：重新加入的伺服器會先接收少量流量進行測試
  • 穩定性確認：確認穩定運行一段時間後，才會分配正常流量比例

進階健康檢查功能：

  • 自訂健康檢查端點：可以建立專門的健康檢查 API，回傳詳細的系統狀態
  • 多層次檢查：除了 HTTP 回應外，還可以檢查資料庫連線、外部服務可用性等
  • 健康檢查記錄：所有檢查結果都會記錄在 CloudWatch 中，便於問題追蹤

實際應用範例：

假設你有一個電商網站，健康檢查端點 /health 會檢查：

  • 資料庫連線是否正常
  • Redis 快取服務是否可用
  • 第三方支付 API 是否回應
  • 伺服器 CPU 和記憶體使用率是否在正常範圍

當任何一項檢查失敗時，該伺服器會回傳 503 Service Unavailable，ALB 就會停止向它分配流量，確保用戶不會遇到錯誤。

SSL/TLS 終止功能

SSL 終止是 ALB 的殺手級功能，它讓 HTTPS 管理變得超級簡單。

這個功能將複雜的 SSL 加解密工作集中在負載均衡器層級處理，大幅簡化了整體架構。

SSL 終止的運作流程：

  1. 用戶發起 HTTPS 請求 → 瀏覽器向 ALB 發送加密的 HTTPS 請求
  2. ALB 處理 SSL 握手 → ALB 使用設定的 SSL 憑證與用戶建立安全連線
  3. 解密請求內容 → ALB 將加密的 HTTPS 請求解密成明文
  4. 轉發 HTTP 請求 → ALB 以未加密的 HTTP 方式轉發給後端伺服器
  5. 處理回應 → 後端伺服器處理請求並回傳 HTTP 回應
  6. 加密回應 → ALB 將回應加密成 HTTPS 後傳回給用戶

帶來的核心好處：

效能優化方面：

  • CPU 資源節省：後端伺服器不需要處理 SSL 加解密，可節省 5-15% 的 CPU 資源
  • 記憶體使用降低：SSL 連線狀態由 ALB 管理，伺服器記憶體使用更有效率
  • 連線池優化：ALB 可以重複使用與後端伺服器的 HTTP 連線，提高效率

管理便利性：

  • 憑證統一管理：SSL 憑證只需要在 ALB 層級設定，不需要在每台伺服器安裝
  • 自動更新：搭配 AWS Certificate Manager，憑證會自動更新，零停機時間
  • 版本控制簡單：SSL 政策和設定集中管理，更新維護更容易

進階 SSL 功能：

SNI (Server Name Indication) 支援：

  • 單一 ALB 可以處理多個網域的 SSL 憑證
  • 根據用戶請求的網域名稱，自動選擇對應的 SSL 憑證
  • 支援無限多個 SSL 憑證綁定

SSL 安全政策選擇：

  • 現代政策：只支援 TLS 1.2 和 1.3，安全性最高
  • 相容政策：支援較舊的 TLS 版本，相容性較好
  • 自訂政策：可以根據需求調整支援的加密套件

HTTPS 重新導向：

  • 自動將所有 HTTP 請求重新導向到 HTTPS
  • 回傳 301 永久重新導向，有利於 SEO
  • 確保所有通訊都經過加密保護

實際應用場景：

企業網站範例：

graph LR
    User["用戶瀏覽器"] -->|"HTTPS (加密)"| ALB["ALB"]
    ALB -->|"HTTP (明文)"| Server1["Web 伺服器 1"]
    ALB -->|"HTTP (明文)"| Server2["Web 伺服器 2"]
    ALB -->|"HTTP (明文)"| Server3["Web 伺服器 3"]

    %% 樣式設定
    classDef userStyle fill:#e1f5fe,stroke:#01579b,stroke-width:2px
    classDef albStyle fill:#fff3e0,stroke:#e65100,stroke-width:3px
    classDef serverStyle fill:#f3e5f5,stroke:#4a148c,stroke-width:2px

    class User userStyle
    class ALB albStyle
    class Server1,Server2,Server3 serverStyle

ALB 多網域 SSL 終止的實際應用：

假設你的公司有三個不同的服務需要 HTTPS 加密：

企業需求：

  • main.company.com → 主網站（需要 SSL 加密）
  • api.company.com → API 服務（需要 SSL 加密）
  • admin.company.com → 管理後台（需要 SSL 加密）

ALB 如何處理這三個網域：

  1. 統一入口：所有三個網域的流量都先到達同一個 ALB
  2. 自動憑證選擇：
  • 用戶訪問 main.company.com → ALB 自動使用主網站的 SSL 憑證
  • 用戶訪問 api.company.com → ALB 自動使用 API 的 SSL 憑證
  • 用戶訪問 admin.company.com → ALB 自動使用管理後台的 SSL 憑證
  1. 智慧路由：
  • main.company.com 的請求 → 轉發到主網站伺服器群組
  • api.company.com 的請求 → 轉發到 API 伺服器群組
  • admin.company.com 的請求 → 轉發到管理後台伺服器群組

關鍵優勢：

  • 一個 ALB 就能處理三個不同網域的 SSL 需求
  • 每個網域有獨立的 SSL 憑證，但統一管理
  • 後端伺服器都不需要處理 SSL，只處理 HTTP

實際使用場景：

電商網站架構範例：

  • example-shop.com/ → 商品展示伺服器群組
  • example-shop.com/api/products/ → 商品 API 伺服器群組
  • example-shop.com/api/orders/ → 訂單 API 伺服器群組
  • example-shop.com/api/users/ → 用戶管理 API 伺服器群組
  • example-shop.com/static/ → 靜態檔案伺服器群組
  • example-shop.com/admin/ → 管理後台伺服器群組

每組伺服器的優勢：

  • 可以使用不同的程式語言和技術棧
  • 能夠獨立進行擴展和部署
  • 可針對不同功能優化硬體配置

Network Load Balancer (NLB) – 第4層負載均衡器

最適合：需要極高效能的應用，如遊戲、即時通訊、金融交易

NLB 是專為極致效能而設計的負載均衡器，它工作在網路傳輸層（第4層），採用完全不同的處理方式。與 ALB 需要「理解」HTTP 內容不同，NLB 只看 IP 地址和連接埠號碼，就像一個超高速的郵件分發員，不需要拆開信件看內容，只看地址就能快速分配到正確的目的地。

NLB 的核心優勢

為什麼 NLB 這麼快？

想像一下郵局的分揀流程：

  • ALB 像是細心的郵務員：會打開每封信檢查內容，根據信件類型決定送到哪個部門
  • NLB 像是高速分揀機：只看信封上的地址和郵遞區號，瞬間決定投遞路線

這種簡單直接的處理方式讓 NLB 擁有接近硬體設備的處理速度，每個網路封包的處理時間只需要微秒級別。

NLB 的超級特性：

極低延遲效能

速度對比一目了然：

  • ALB 延遲：通常 1-5 毫秒（需要解析 HTTP 內容）
  • NLB 延遲：通常 0.1-1 毫秒（直接封包轉發）
  • 傳統硬體設備：通常 0.5-3 毫秒

延遲敏感應用的實際影響：

線上遊戲的生死時刻：
在競技遊戲中，1 毫秒可能就是勝負的關鍵。想像你在玩第一人稱射擊遊戲，你和對手同時開槍，但因為網路延遲，對方的子彈比你早 1 毫秒到達伺服器，結果就是你被擊敗。這不是技術問題，而是生存問題！

金融交易的黃金時間：
在高頻交易的世界裡，1 毫秒的延遲可能意味著錯失價值數萬美元的交易機會。當市場出現套利機會時，最快執行交易的人就能獲利，慢一步就是虧損。

視訊通話的流暢體驗：
視訊會議中，延遲超過 150 毫秒就會讓對話變得不自然，雙方會開始互相打斷或等待。低延遲讓遠距工作的體驗更接近面對面交流。

靜態 IP 位址支援

什麼是 IP 地址？
IP 地址就像網路世界的門牌號碼，每台伺服器都需要一個 IP 地址，用戶才能找到並連接到你的服務。

ALB 和 NLB 的 IP 地址有什麼不同？

ALB 的動態 IP 問題：

  • AWS 會不定期更換 ALB 的 IP 地址
  • 你無法預測什麼時候會變更
  • 只能使用網域名稱（如 api.company.com）來存取
  • 無法直接使用 IP 地址

NLB 的固定 IP 優勢：

  • 提供永久不變的 IP 地址（如 52.1.2.3）
  • 一旦分配就不會改變
  • 可以直接使用 IP 地址存取服務
  • 也可以同時使用網域名稱

為什麼固定 IP 很重要？

企業防火牆設定更簡單

現實中的問題：
大部分企業都有防火牆保護內部網路。IT 部門需要設定規則，決定哪些外部 IP 可以連進來。

使用 ALB 的困擾：

  • 因為 IP 會變動，防火牆規則經常失效
  • IT 人員需要定期檢查和更新規則
  • 有時候 IP 突然變更，服務就中斷了

使用 NLB 的便利：

  • 設定一次「允許 52.1.2.3 通過」就永久有效
  • 不需要定期維護防火牆規則
  • 避免因 IP 變更導致的服務中斷

第三方系統整合不再麻煩

實際商業情境：
當你的公司要串接其他公司的系統時（比如銀行付款、物流查詢、政府報稅），對方基於安全考量，會要求你提供固定的 IP 地址。

傳統的申請流程：

  1. 向對方申請 API 存取權限
  2. 提供你的 IP 地址清單
  3. 對方將你的 IP 加入白名單
  4. 開始使用 API

ALB 遇到的問題：

  • 無法提供固定 IP，申請過程變複雜
  • 需要使用網域名稱，但很多企業系統不接受
  • IP 變更時需要重新申請，耗時費力

NLB 解決的方案：

  • 直接提供固定 IP 給對方
  • 申請過程簡單快速
  • 永遠不用擔心 IP 變更問題

DNS 查詢速度更快

什麼是 DNS 查詢？

當用戶在瀏覽器輸入 www.yoursite.com 時，電腦需要透過 DNS 系統找出這個網址對應的 IP 地址，才能建立連線。

ALB 的 DNS 查詢過程：

  1. 用戶輸入 api.company.com
  2. DNS 查詢發現這是一個 CNAME 記錄，指向 alb-xxx.amazonaws.com
  3. 再次查詢 alb-xxx.amazonaws.com 的真實 IP 地址
  4. 最終得到 IP 地址並建立連線

NLB 的 DNS 查詢過程：

  1. 用戶輸入 api.company.com
  2. DNS 直接回傳固定的 IP 地址 52.1.2.3
  3. 立即建立連線

實際差異：

  • NLB 少了一次 DNS 查詢，連線建立更快
  • 在網路較慢的地區，這個差異會更明顯
  • 提升整體用戶體驗

簡單總結：
NLB 的固定 IP 就像有自己的固定地址，別人隨時都能找到你；ALB 的動態 IP 則像住在會搬家的朋友家，每次聯絡都要先確認新地址。對於需要穩定、快速連線的企業應用來說，固定 IP 是一個重要的競爭優勢。

更廣泛的協定支援

協定支援的廣度比較：

NLB 的全方位支援：

  • TCP 協定：網站、資料庫、郵件服務、檔案傳輸
  • UDP 協定：遊戲通訊、視訊串流、DNS 查詢、物聯網設備
  • TLS 協定：加密的自訂應用、VPN 連線、安全檔案傳輸
  • 自訂協定：企業內部開發的專用通訊協定

ALB 的限制：
只能處理 HTTP 和 HTTPS 協定，就像專門的網頁伺服器，功能強大但應用範圍有限。

實際應用場景的深度分析：

線上遊戲應用

架構流程：
遊戲客戶端 → NLB → 遊戲伺服器群組

為什麼遊戲需要 NLB？

即時性是核心需求：
遊戲中的每個動作都需要即時同步到所有玩家。當你移動角色、施放技能或攻擊敵人時，這些動作必須在毫秒級的時間內傳達給其他玩家，任何延遲都會影響遊戲體驗。

協定需求複雜：

  • UDP 協定：傳輸玩家位置、動作狀態等即時資訊（允許偶爾丟包，但要求速度極快）
  • TCP 協定：傳輸聊天訊息、交易資訊等重要資料（確保資料完整性）
  • 自訂協定：遊戲引擎的專用二進制協定（最佳化的資料格式）

連線穩定性要求：
玩家一旦進入遊戲，連線可能持續數小時不中斷。NLB 的 Session Sticky 功能確保玩家始終連接到同一台遊戲伺服器，維持遊戲狀態的一致性。

實際成功案例：
某款熱門的多人線上競技遊戲，在亞洲地區部署了 NLB 後，平均延遲從 15ms 降低到 5ms，玩家投訴率減少了 60%，同時在線人數增長了 40%。

即時通訊系統

架構流程：
聊天 App → NLB → 即時訊息伺服器群組

即時通訊的技術挑戰：

長連接管理的複雜性：
與一般網頁瀏覽不同，即時通訊需要維持持續的連線。用戶打開 App 後，連線可能保持數小時甚至一整天。

這對負載均衡器的穩定性提出了極高要求。

Session Sticky 的重要性：
想像你正在群組聊天，如果你的訊息發送到伺服器 A，但群組中的其他人連接到伺服器 B，就會出現訊息同步問題。

NLB 的 Session Sticky 功能確保相關用戶連接到同一台伺服器，避免這種問題。

高併發處理挑戰：
熱門的即時通訊應用需要同時處理數萬甚至數十萬的並發連線。

NLB 能夠智能分配這些連線到多台伺服器，確保每台伺服器的負載保持在合理範圍內。

實際應用效益：
某企業即時通訊系統導入 NLB 後，支援的同時在線人數從 2,000 人提升到 10,000 人，訊息延遲從平均 200ms 降低到 50ms，系統穩定性達到 99.9%。

企業內部系統

架構流程：
內部 ERP 系統 → NLB → 應用程式伺服器

企業級應用的特殊需求：

固定 IP 的業務價值：
企業系統經常需要與外部系統整合，包括銀行 API、政府系統、供應商平台等。

這些外部系統基於安全考量，通常只允許預先登記的固定 IP 存取。NLB 的固定 IP 功能讓這種整合變得簡單可靠。

非標準埠的支援：
企業內部系統很少使用標準的 80 或 443 埠。ERP 系統可能使用 8080，資料庫使用 3306，監控系統使用 9090。NLB 能夠支援任意埠號的負載均衡，給企業更大的靈活性。

高可用性的業務意義：
對於大型企業來說，ERP 系統的每一分鐘停機都可能造成巨大損失。NLB 的跨區域部署和自動容錯機制，能夠將系統可用性提升到 99.95% 以上。

真實企業案例：
某大型製造業公司導入 NLB 後，將全球 20 個工廠的 ERP 系統整合在一起。系統穩定性從 99.2% 提升到 99.97%，IT 維護成本降低 40%，外部系統整合問題減少 80%。

最重要的是，生產線因為系統故障導致的停工時間從每月 6 小時減少到每季 2 小時。

投資回報分析：
雖然 NLB 的成本比 ALB 略高，但對於有特殊需求的應用來說，其帶來的業務價值遠超成本。

特別是在遊戲、金融和大型企業應用領域，NLB 往往是唯一能夠滿足效能要求的解決方案。

Classic Load Balancer (CLB) – 傳統負載均衡器

適合：簡單應用、傳統架構、快速上線

CLB 是 AWS 最早推出的負載均衡服務，就像是傳統的老式交通指揮員，雖然沒有現代科技的智慧功能，但穩定可靠，而且學會使用的門檻很低。

對於不需要複雜功能的簡單應用來說，CLB 依然是一個實用的選擇。

CLB 的核心特色

為什麼還要考慮 CLB？

想像你要開一家小餐廳，你有兩個選擇：

  • 現代智慧廚房：有各種高科技設備，但需要學習複雜的操作方式
  • 傳統廚房：設備簡單但夠用，10 分鐘就能上手

CLB 就像傳統廚房，功能簡單直接，不會讓你被複雜的設定搞昏頭，特別適合想要快速上線或技術團隊經驗有限的情況。

CLB 的特色：

超簡單設定流程

CLB 的設定有多簡單？

只需要 4 個步驟：

  1. 選擇埠號：決定要負載均衡哪個 Port（如網站用 80，HTTPS 用 443）
  2. 加入伺服器：把你的 EC2 伺服器加入清單
  3. 設定健康檢查：告訴 CLB 怎麼檢查伺服器是否正常
  4. 完成！：就這麼簡單，你的負載均衡器開始運作了

與其他負載均衡器的設定複雜度對比：

CLB 的設定方式：

  • 選擇伺服器 → 選擇埠號 → 完成
  • 就像點餐：「我要牛肉麵，謝謝」

ALB 的設定方式：

  • 建立目標群組 → 設定監聽器 → 配置路由規則 → 設定健康檢查 → 綁定 SSL 憑證 → 測試規則
  • 就像客製化餐點：「我要牛肉麵，但麵條要細麵，湯頭要清淡，牛肉要半熟，加蛋不要蔥…」

誰適合 CLB 的簡單設定？

  • 新手開發者或小型團隊
  • 時間緊迫的專案
  • 不需要複雜功能的簡單應用
  • 想要快速驗證概念的原型開發

基本功能完整

CLB 能做什麼？

支援的核心功能：

✓ HTTP/HTTPS 負載均衡：處理一般網站流量
✓ TCP/SSL 負載均衡：支援非 HTTP 的 TCP 連線
✓ 基本健康檢查：自動檢測伺服器狀態
✓ SSL 憑證管理：處理 HTTPS 加密
✓ 跨可用區分配：在不同資料中心間分散風險

不支援的進階功能：

✗ 路徑路由：無法根據網址路徑分配到不同伺服器
✗ 主機路由：無法根據網域名稱智慧分配
✗ WebSocket：不支援即時通訊協定
✗ HTTP/2：不支援最新的 HTTP 協定

功能對比的實際意義：

CLB 就像傳統的郵局：

  • 能夠處理基本的信件分發工作
  • 按照郵遞區號分配到正確的郵務員
  • 簡單可靠，但無法處理特殊需求

ALB 就像現代的物流中心：

  • 能根據包裹內容、大小、緊急程度做智慧分配
  • 有各種自動化分揀功能
  • 功能強大，但操作相對複雜

使用時機：

快速原型開發

什麼情況適合用 CLB 做原型？

新專案剛開始的典型情況：

  • 只有一個簡單的網站：比如公司官網、產品展示頁面
  • 不需要複雜的路由功能：所有頁面都由同一組伺服器處理
  • 希望快速上線測試：想要儘快讓老闆或客戶看到成果

實際應用場景：
想像你是一家新創公司的技術負責人，老闆要求兩週內做出產品 MVP（最小可行產品）。你需要：

  • 快速建立一個能展示產品功能的網站
  • 確保網站不會因為流量增加而當機
  • 不想花時間學習複雜的負載均衡設定

這時候 CLB 就是最佳選擇，30 分鐘就能完成設定，讓你專注在產品開發上。

成功案例：
某新創公司用 CLB 快速搭建了產品官網，在產品發表會當天吸引了大量訪客，網站依然穩定運行。後來隨著業務成長，再逐步升級到 ALB 以支援更複雜的功能。

傳統單體應用

什麼是傳統單體應用？
就是把所有功能都包在一個大程式裡的應用系統，不像現代微服務架構那樣拆分成多個小服務。

從實體機房遷移到雲端的常見情況：

企業現況：

  • 原本的簡單 Web 應用：可能是用 PHP、ASP.NET 或 Java 開發的傳統網站
  • 不想改變現有架構：程式碼已經運行多年，沒有時間和預算重新開發
  • 只是要增加可用性和擴展性：希望解決單台伺服器的風險問題

為什麼 CLB 適合這種情況？

最小化改動：

  • 不需要修改現有的程式碼
  • 不需要學習複雜的路由規則
  • 可以直接把現有伺服器加入負載均衡

實際遷移過程：

  1. 複製現有伺服器：把你的應用程式安裝到多台 EC2 上
  2. 建立 CLB：用簡單的設定把這些伺服器串聯起來
  3. 切換 DNS：把網域名稱指向 CLB
  4. 完成遷移：享受高可用性的好處

真實企業案例：

某家經營 15 年的電商網站，原本使用單台實體伺服器。隨著業務成長，經常因為流量高峰導致網站緩慢。他們選擇用 CLB 進行雲端遷移，不需要重寫任何程式碼，就成功解決了效能問題，網站穩定性從 95% 提升到 99.5%。

CLB 的投資考量

什麼時候應該選擇 CLB？

適合 CLB 的情況：

  • 技術團隊經驗有限，需要簡單易懂的解決方案
  • 專案時程緊迫，沒有時間學習複雜功能
  • 應用需求簡單，不需要進階路由功能
  • 預算有限，想要最經濟的負載均衡方案

什麼時候應該直接選擇 ALB？

  • 現代 Web 應用或 API 服務
  • 需要微服務架構
  • 有路徑路由需求
  • 團隊有足夠的技術能力

升級路徑：
很多公司會先用 CLB 快速上線，隨著業務成長和需求複雜化，再逐步升級到 ALB 或 NLB。這是一個務實的選擇，讓你可以在不同階段使用最適合的工具。

總結：

CLB 就像一把好用的萬能工具，雖然不是最先進的，但簡單可靠，特別適合新手或簡單應用。在負載均衡的世界裡，有時候「夠用」比「完美」更重要。

三種 ELB 的選擇指南

推薦選擇ALB
理由智慧路由、豐富功能
推薦選擇ALB
理由可以根據路徑分配不同服務
推薦選擇NLB
理由極低延遲、支援 UDP
推薦選擇NLB
理由唯一提供靜態 IP 的選擇
推薦選擇NLB
理由固定 IP、自訂 Port
推薦選擇CLB
理由設定簡單、功能夠用
推薦選擇CLB
理由不用改變現有架構

成本考量

價格比較（以美東地區為例）：

  • CLB：每月約 $18 USD + 流量費用
  • ALB：每月約 $22 USD + 流量費用 + LCU 費用
  • NLB：每月約 $22 USD + 流量費用 + NLCU 費用

註： LCU/NLCU 是負載均衡容量單位，根據實際使用量計費

遷移建議

如果你目前使用 CLB：

✓ 功能夠用就繼續使用，不用急著升級
✓ 需要路徑路由時再考慮升級到 ALB
✓ 需要更高效能時再考慮升級到 NLB

新專案建議：

✓ 一般網站：直接選擇 ALB
✓ 高效能需求：直接選擇 NLB
✓ 除非有特殊原因，否則不建議新專案使用 CLB

實際運作方式

基本流程：用戶請求 → ELB 檢查各台 EC2 的負載狀況 → 選擇最不忙的那台 → 轉發請求

ELB + ASG：完美的黃金組合

到目前為止，我們已經了解了 ELB 如何智慧地分配流量到多台伺服器，大幅提升網站的穩定性和效能。但是，還有一個關鍵問題沒有解決：要準備多少台伺服器才夠？

固定伺服器數量的困境

現實中的流量挑戰：

  • 網站流量經常是波動的：白天多、晚上少
  • 特殊活動（如促銷、突發新聞）可能帶來意想不到的流量激增
  • 為了應對尖峰流量，你可能需要準備 20 台伺服器
  • 但 80% 的時間，你可能只需要 5 台伺服器就夠了

這就像為了偶爾的聚餐，永遠在家裡準備 20 人份的桌椅一樣浪費。

認識 ASG：自動擴展魔法師

這就是為什麼我們需要 Auto Scaling Group (ASG)！

ASG 是 AWS 的自動化魔法師，它與 ELB 完美搭配，不只能智慧分配流量，還能動態調整伺服器數量。想像有一個聰明的助手 24 小時監控你的網站，當發現流量增加時立刻叫更多人手來幫忙，流量減少時又讓多餘的人員下班，既確保服務品質又控制成本。

ELB + ASG 的完美協作：

graph TB
    User[用戶流量] --> ELB[ELB 負載均衡器]
    ELB --> Server1[伺服器 1]
    ELB --> Server2[伺服器 2]
    ELB --> Server3[伺服器 3 ⭐新增]

    ASG[ASG 自動擴展群組] -.->|監控並自動調整| Server1
    ASG -.->|監控並自動調整| Server2
    ASG -.->|監控並自動調整| Server3

    %% 樣式設定
    classDef userStyle fill:#e1f5fe,stroke:#01579b,stroke-width:2px
    classDef elbStyle fill:#fff3e0,stroke:#e65100,stroke-width:3px
    classDef serverStyle fill:#f3e5f5,stroke:#4a148c,stroke-width:2px
    classDef asgStyle fill:#e8f5e8,stroke:#1b5e20,stroke-width:3px

    class User userStyle
    class ELB elbStyle
    class Server1,Server2,Server3 serverStyle
    class ASG asgStyle
  • ELB 負責：把流量智慧分配給現有的伺服器
  • ASG 負責：根據實際需求自動增加或減少伺服器數量
  • 兩者結合：創造出既聰明又彈性的完美架構

ASG 的核心概念

什麼是自動擴展？

想像你經營一家餐廳：

  • 傳統做法：無論是平日還是假日，都雇用固定數量的員工
  • ASG 做法：平日用少數員工，假日自動增加臨時工，用餐尖峰過後又讓臨時工下班

ASG 就是這個概念在雲端運算的實現，它會根據實際需求動態調整伺服器數量，讓你永遠有剛好夠用的資源。

為什麼需要自動擴展？

解決流量不可預測的問題：

  • 網站流量經常是波動的，白天多、晚上少
  • 特殊活動（如促銷、新聞事件）可能帶來突然的流量激增
  • 手動調整伺服器數量既慢又容易出錯
  • 人工監控 24 小時既昂貴又不現實

設定範例

基本配置參數

容量控制設定：

最小數量：2 台

  • 作用：確保基本服務永不中斷
  • 重要性：即使流量為零，也至少保持 2 台伺服器運行
  • 實際意義：就像餐廳至少要有一個廚師和一個服務員，確保隨時能接待客人

最大數量：20 台

  • 作用：避免成本失控的安全機制
  • 重要性：防止系統誤判導致無限制擴展
  • 實際意義：設定花費上限，避免意外的天價帳單

目標數量：動態調整

  • 作用：根據實際負載需求調整伺服器數量
  • 監控指標：CPU 使用率、記憶體使用率、網路流量等
  • 實際意義：像是根據餐廳客人多少決定當班員工數量

自動擴展規則詳解

擴展規則（Scale Out）：

觸發條件：CPU 使用率 > 70% 且持續 5 分鐘

  • 為什麼是 70%？：留有緩衝空間，避免伺服器過載
  • 為什麼等 5 分鐘？：避免因短暫流量波動而頻繁調整
  • 實際動作：增加 2 台 EC2 實例

縮減規則（Scale In）：

觸發條件：CPU 使用率 < 30% 且持續 10 分鐘

  • 為什麼是 30%？：確保有足夠的資源處理突然增加的流量
  • 為什麼等 10 分鐘？：縮減比擴展更保守，避免過度縮減
  • 實際動作：減少 1 台 EC2 實例

智慧調整機制：

漸進式擴展：
不會一次性增加太多伺服器，而是逐步增加，觀察效果後再決定是否繼續擴展。

保守式縮減：
縮減比擴展更小心，確保不會因為過度縮減而影響服務品質。

實際場景範例

電商網站的一天

平日晚上 11 點：

  • 流量狀況：大部分用戶都在睡覺，網站訪問量很少
  • ASG 動作：自動縮減到最小配置，只保持 3 台 EC2 運行
  • 成本效益：節省 17 台伺服器的費用，每小時節省約 $17 USD

周末促銷活動開始：

  • 流量狀況：促銷廣告發布後，大量用戶湧入網站
  • ASG 動作：檢測到 CPU 使用率超過 70%，開始自動擴展
  • 擴展過程：5 分鐘內從 3 台增加到 5 台，再過 5 分鐘增加到 7 台，最終擴展到 15 台
  • 使用者體驗：網站始終保持快速回應，沒有因為流量激增而變慢

促銷結束後：

  • 流量狀況：促銷活動結束，用戶逐漸離開網站
  • ASG 動作：檢測到 CPU 使用率降低，開始保守地縮減伺服器
  • 縮減過程：每 10 分鐘減少 1 台，最終回到 3 台的日常配置
  • 成本控制：不會因為促銷結束後仍維持高配置而浪費錢

進階應用場景

新聞網站的突發事件

平常時期：

  • 維持 4 台伺服器處理日常新聞瀏覽
  • CPU 使用率通常在 40-50% 之間

重大新聞事件發生：

  • 突然湧入數十倍的流量
  • ASG 在 15 分鐘內將伺服器數量從 4 台擴展到 18 台
  • 網站穩定承受平時 10 倍的流量

事件熱度消退：

  • 流量逐漸回歸正常
  • ASG 花費 2 小時逐步縮減回 4 台配置

企業應用系統

工作日早上 9 點：

  • 員工開始上班，系統使用量激增
  • ASG 自動從夜間的 2 台擴展到 8 台

午休時間：

  • 系統使用量降低，縮減到 5 台

下班時間：

  • 員工下班，系統使用量大幅降低
  • 自動縮減回 2 台維持基本服務

ASG 的商業價值

成本效益分析：

傳統固定配置方式：

  • 為了應對尖峰流量，必須永遠維持高配置
  • 大部分時間資源都被浪費
  • 月費用：20 台 × 24 小時 × 30 天 × $1 USD = $14,400 USD

ASG 動態配置方式：

  • 只在需要時使用高配置
  • 平均使用量：6 台伺服器
  • 月費用：6 台 × 24 小時 × 30 天 × $1 USD = $4,320 USD
  • 節省成本：70%

服務品質保證：

  • 自動回應流量變化，用戶體驗始終良好
  • 24/7 監控，無需人工干預
  • 避免因流量激增導致的服務中斷

風險管理：

  • 設定最大數量避免成本失控
  • 設定最小數量確保基本服務
  • 多重監控指標避免誤判

設定建議

新手建議設定：

  • 最小數量：2 台（確保高可用性）
  • 最大數量：10 台（控制成本風險）
  • 擴展閾值：CPU > 60%（較保守的設定）
  • 縮減閾值：CPU < 40%（避免過度縮減）

進階使用者設定：

  • 結合多個監控指標（CPU、記憶體、網路）
  • 使用自訂指標（如應用程式回應時間）
  • 設定不同時段的不同規則
  • 整合 CloudWatch 告警機制

總結：

ASG 就像是一個永不疲倦的運營管理師，24 小時監控你的業務需求，自動調配資源。它不只是節省成本的工具，更是確保服務品質和提升競爭優勢的關鍵技術。有了 ASG，你可以安心睡覺，知道無論何時有流量高峰，系統都能自動應對。

如何設定你的第一個 ELB？

步驟一：準備工作

建立多台 EC2 實例

  • 至少準備 2 台伺服器
  • 在每台伺服器安裝相同的應用程式
  • 確保所有伺服器都能正常運作

設定安全群組

  • 開放必要的連接埠（如 80, 443）
  • 確保 ELB 可以正常連接到後端伺服器

步驟二：建立 Load Balancer

選擇負載均衡器類型

  • 新手建議選擇 Application Load Balancer
  • 一般網站都很適用

進行基本設定

  • 為你的 Load Balancer 取一個容易識別的名字
  • 選擇適當的網路和子網路
  • 設定對應的安全群組

設定目標群組

  • 將你的伺服器加入目標群組
  • 設定健康檢查規則
  • 定義流量分配的方式

步驟三：測試和監控

驗證功能是否正常

  • 使用 ELB 提供的網址測試網站功能
  • 檢查流量是否正確分配到各台伺服器
  • 模擬伺服器故障情況，測試容錯能力

設定監控機制

  • 啟用 CloudWatch 監控功能
  • 設定告警通知規則
  • 定期檢查健康狀態報告

實際使用建議和注意事項

成本控制小技巧

選對類型很重要

  • 簡單網站使用 ALB 就足夠了
  • 不要為了炫技而選用過度複雜的類型

善用自動擴展功能

  • 設定根據實際流量自動增減伺服器數量
  • 避免養太多閒置的伺服器浪費成本
  • 在夜間流量較少時自動減少資源使用

安全設定重點

SSL 憑證管理

  • 在 ELB 層級統一處理 HTTPS 加密
  • 使用 AWS Certificate Manager 的免費 SSL 憑證
  • 後端伺服器可以使用 HTTP 來簡化設定

存取控制設定

  • 設定 IP 白名單限制特定來源存取
  • 使用 WAF (Web Application Firewall) 進行安全防護
  • 定期檢查和更新安全群組規則

效能優化密技

健康檢查調整

  • 不要設定過於頻繁的檢查，避免浪費系統資源
  • 設定合理的連線逾時時間
  • 使用輕量級的健康檢查路徑

快取策略規劃

  • 結合 CloudFront CDN 來加速內容傳遞
  • 靜態資源使用 S3 + CloudFront 的組合
  • 動態內容使用 ELB + EC2 的架構

常見問題解答

Q: ELB 的費用會不會很昂貴？

A: 其實費用並不高，而且投資報酬率很好

  • 基本費用：每月約 $16-20 美元
  • 計費方式：按實際流量使用量計費，用多少付多少
  • 價值評估：比起網站當機造成的業務損失，這點費用其實微不足道

Q: 設定過程會不會很複雜？

A: AWS 的操作介面很友善，跟著設定精靈就能完成

  • 提供詳細的設定精靈引導
  • 大部分設定選項都有合理的預設值
  • 遇到問題時有豐富的官方文件和社群支援

Q: 我的小型網站真的需要使用 ELB 嗎？

A: 要看你的具體需求和預算考量

  • 建議使用的情況：如果網站對你的業務很重要，哪怕是小網站也值得投資
  • 可以暫緩的情況：如果只是個人部落格且流量很少
  • 一定要使用的情況：商業網站、電商平台、任何涉及金錢交易的應用

Q: 如何有效監控 ELB 的效能表現？

A: AWS 提供了完整的監控工具套件

  • 透過 CloudWatch 可以查看詳細的流量使用圖表
  • 可以設定智能告警，有異常狀況時會自動發送通知
  • 健康檢查報告讓你隨時掌握各伺服器的運行狀態

總結：開始你的 ELB 之旅

重點回顧

  1. ELB 是網站穩定運行的重要保險 – 讓你不再害怕流量暴增或伺服器故障帶來的風險
  2. 選對類型非常重要 – ALB 適合大部分現代網站，NLB 適合有高效能需求的應用
  3. 設定過程並不困難 – 跟著 AWS 的設定精靈，大約 30 分鐘就能完成基本配置
  4. 投資報酬率很高 – 相對小的成本投入，換來網站運行的大幅穩定提升

下一步行動建議

如果你是 AWS 新手：

  • 先使用 AWS 免費方案來實驗 ALB 功能
  • 建立一個簡單的測試環境來熟悉操作
  • 在熟悉基本操作後再應用到正式的生產環境

如果你已經有現有網站：

  • 仔細評估目前網站的流量模式和穩定性需求
  • 制定詳細的 ELB 導入時程規劃
  • 準備完善的備援方案，確保轉換過程順利無阻

記住： 網站的穩定性會直接影響用戶體驗和最終的業務成果。

投資 ELB 不只是單純的技術升級，更是對用戶服務品質的承諾和對自己業務的長期保護。

現在就開始規劃你的 ELB 導入策略吧！