在現代網路世界中，成功的網站往往面臨一個甜蜜的煩惱：用戶太多了！
當越來越多人造訪你的網站時，單一伺服器很快就會不堪負荷。
這時候，你需要的不只是更多伺服器，還需要一個聰明的「交通指揮」來管理這些流量。
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 終止的運作流程：
- 用戶發起 HTTPS 請求 → 瀏覽器向 ALB 發送加密的 HTTPS 請求
- ALB 處理 SSL 握手 → ALB 使用設定的 SSL 憑證與用戶建立安全連線
- 解密請求內容 → ALB 將加密的 HTTPS 請求解密成明文
- 轉發 HTTP 請求 → ALB 以未加密的 HTTP 方式轉發給後端伺服器
- 處理回應 → 後端伺服器處理請求並回傳 HTTP 回應
- 加密回應 → 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 serverStyleALB 多網域 SSL 終止的實際應用：
假設你的公司有三個不同的服務需要 HTTPS 加密：
企業需求：
main.company.com→ 主網站（需要 SSL 加密）api.company.com→ API 服務（需要 SSL 加密）admin.company.com→ 管理後台（需要 SSL 加密）
ALB 如何處理這三個網域：
- 統一入口：所有三個網域的流量都先到達同一個 ALB
- 自動憑證選擇：
- 用戶訪問
main.company.com→ ALB 自動使用主網站的 SSL 憑證 - 用戶訪問
api.company.com→ ALB 自動使用 API 的 SSL 憑證 - 用戶訪問
admin.company.com→ ALB 自動使用管理後台的 SSL 憑證
- 智慧路由：
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 地址。
傳統的申請流程：
- 向對方申請 API 存取權限
- 提供你的 IP 地址清單
- 對方將你的 IP 加入白名單
- 開始使用 API
ALB 遇到的問題：
- 無法提供固定 IP，申請過程變複雜
- 需要使用網域名稱，但很多企業系統不接受
- IP 變更時需要重新申請，耗時費力
NLB 解決的方案：
- 直接提供固定 IP 給對方
- 申請過程簡單快速
- 永遠不用擔心 IP 變更問題
DNS 查詢速度更快
什麼是 DNS 查詢？
當用戶在瀏覽器輸入 www.yoursite.com 時，電腦需要透過 DNS 系統找出這個網址對應的 IP 地址，才能建立連線。
ALB 的 DNS 查詢過程：
- 用戶輸入 api.company.com
- DNS 查詢發現這是一個 CNAME 記錄，指向 alb-xxx.amazonaws.com
- 再次查詢 alb-xxx.amazonaws.com 的真實 IP 地址
- 最終得到 IP 地址並建立連線
NLB 的 DNS 查詢過程：
- 用戶輸入 api.company.com
- DNS 直接回傳固定的 IP 地址 52.1.2.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 個步驟：
- 選擇埠號：決定要負載均衡哪個 Port（如網站用 80，HTTPS 用 443）
- 加入伺服器：把你的 EC2 伺服器加入清單
- 設定健康檢查：告訴 CLB 怎麼檢查伺服器是否正常
- 完成！：就這麼簡單，你的負載均衡器開始運作了
與其他負載均衡器的設定複雜度對比：
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 適合這種情況？
最小化改動：
- 不需要修改現有的程式碼
- 不需要學習複雜的路由規則
- 可以直接把現有伺服器加入負載均衡
實際遷移過程：
- 複製現有伺服器：把你的應用程式安裝到多台 EC2 上
- 建立 CLB：用簡單的設定把這些伺服器串聯起來
- 切換 DNS：把網域名稱指向 CLB
- 完成遷移：享受高可用性的好處
真實企業案例：
某家經營 15 年的電商網站，原本使用單台實體伺服器。隨著業務成長，經常因為流量高峰導致網站緩慢。他們選擇用 CLB 進行雲端遷移，不需要重寫任何程式碼，就成功解決了效能問題，網站穩定性從 95% 提升到 99.5%。
CLB 的投資考量
什麼時候應該選擇 CLB？
適合 CLB 的情況：
- 技術團隊經驗有限，需要簡單易懂的解決方案
- 專案時程緊迫，沒有時間學習複雜功能
- 應用需求簡單，不需要進階路由功能
- 預算有限，想要最經濟的負載均衡方案
什麼時候應該直接選擇 ALB？
- 現代 Web 應用或 API 服務
- 需要微服務架構
- 有路徑路由需求
- 團隊有足夠的技術能力
升級路徑：
很多公司會先用 CLB 快速上線，隨著業務成長和需求複雜化，再逐步升級到 ALB 或 NLB。這是一個務實的選擇，讓你可以在不同階段使用最適合的工具。
總結：
CLB 就像一把好用的萬能工具，雖然不是最先進的，但簡單可靠，特別適合新手或簡單應用。在負載均衡的世界裡，有時候「夠用」比「完美」更重要。
三種 ELB 的選擇指南
| 情況 | 推薦選擇 | 理由 |
|---|---|---|
| 現代 Web 應用、API 服務 | ALB | 智慧路由、豐富功能 |
| 微服務架構 | ALB | 可以根據路徑分配不同服務 |
| 遊戲、即時通訊 | NLB | 極低延遲、支援 UDP |
| 需要固定 IP | 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 之旅
重點回顧
- ELB 是網站穩定運行的重要保險 – 讓你不再害怕流量暴增或伺服器故障帶來的風險
- 選對類型非常重要 – ALB 適合大部分現代網站，NLB 適合有高效能需求的應用
- 設定過程並不困難 – 跟著 AWS 的設定精靈，大約 30 分鐘就能完成基本配置
- 投資報酬率很高 – 相對小的成本投入，換來網站運行的大幅穩定提升
下一步行動建議
如果你是 AWS 新手：
- 先使用 AWS 免費方案來實驗 ALB 功能
- 建立一個簡單的測試環境來熟悉操作
- 在熟悉基本操作後再應用到正式的生產環境
如果你已經有現有網站：
- 仔細評估目前網站的流量模式和穩定性需求
- 制定詳細的 ELB 導入時程規劃
- 準備完善的備援方案，確保轉換過程順利無阻
記住： 網站的穩定性會直接影響用戶體驗和最終的業務成果。
投資 ELB 不只是單純的技術升級，更是對用戶服務品質的承諾和對自己業務的長期保護。
現在就開始規劃你的 ELB 導入策略吧！