負載平衡器：Application Load Balancer（ALB）
寫給耀達 Lite 雲端進銷存的部署討論（2026-10-30）。接續〈資料庫擴充指南〉（db-scaling.html）第 8 節的「②③ 負載平衡器＋多個容器」。
前提：AWS 東京、ECS Fargate 用 Express Mode 建立、前面有 CloudFront、後面是 Aurora PostgreSQL。
1. 先講結論
- ALB：擋在一群容器前面的「接待員」。店家的每個請求先到它這裡，它再挑一個健康、有空的容器交給它處理。
- 它解決的事：容器可以隨時多開、少開、換新版，店家完全感覺不到；某個容器壞了，它會自動避開。
- HTTPS 在 ALB 這裡解開：店家到 ALB 是加密的，ALB 到容器是 AWS 內部網路上的一般 HTTP，容器的程式不用處理憑證。
- Express Mode 已經自動建好一台，第一版幾乎不用自己設定，要知道的是它的預設值和限制。
- 費用：東京每小時 0.0243 美元，一個月約 17.7 美元，再加上按流量計的 LCU 與公開 IP 費用。第一版估計每月 30～40 美元。
- 還沒定的一題：ALB 要放在公開網路、只收 CloudFront 的流量，還是藏在私有網路、讓 CloudFront 從內部連進來（第 11 節）。這題會牽涉 NAT 費用，留到第 7 題「環境與發布」一起談。
2. ALB 是什麼
用餐廳來比喻：
- 容器是廚師：耀達 Lite 的程式同時跑好幾份一模一樣的，每一份就是一位廚師，誰都會做每一道菜。
- ALB 是門口的帶位員：客人（店家的請求）一進門，帶位員看哪位廚師有空，就把單子交給他。客人不用知道後面有幾位廚師、叫什麼名字。
- 健康檢查是帶位員每 30 秒探頭問一次「你還好嗎？」：連續兩次沒回應的廚師，就先不派單給他。
「Application」的意思是它看得懂 HTTP：網址路徑、主機名稱、標頭、Cookie 都能拿來決定往哪裡送。只看 IP 和連接埠、不看內容的是另一種負載平衡器（第 13 節）。
3. 耀達 Lite 為什麼需要它
如果只有一個容器、店家直接連到它，下面每一件事都會讓店家看到錯誤畫面：
| 情境 | 沒有 ALB | 有 ALB |
|---|---|---|
| 人變多，ECS 自動多開兩個容器 | 新容器的位址店家不知道，用不到 | 新容器通過健康檢查後自動加入分派 |
| 半夜人少，ECS 關掉多的容器 | 正在處理的請求被切斷 | 先停止派新單，等手上的做完再關（第 8 節） |
| 發布新版 | 要停機換版 | 新版容器先上、舊的排空再下，店家不會斷線 |
| 某個容器當掉或卡住 | 連到它的店家全部出錯 | 健康檢查發現後不再派單給它，ECS 換一個新的 |
| AWS 東京某一個機房出問題 | 容器剛好在那裡就全掛 | ALB 跨至少兩個可用區域，另一區的容器繼續服務 |
| HTTPS 憑證 | 每個容器都要裝憑證、自己更新 | 憑證只裝在 ALB，AWS 自動更新 |
這些就是 db-scaling.html 第 4 節「容器不存狀態」那條規矩的理由：任何一個請求都可能被派到任何一個容器，容器隨時可能被關掉，所以登入狀態、購物車這類東西不能只存在某個容器的記憶體裡。
4. 裡面的四個零件
在 AWS 主控台打開一台 ALB，會看到這幾個名詞：
①監聽器（Listener）：在某個連接埠等請求，例如 HTTPS 的 443。HTTPS 憑證就掛在這裡。
②規則（Rule）：依照主機名稱、網址路徑、標頭等條件決定送去哪裡，也可以直接回固定內容或轉址。Express Mode 用「主機名稱」來分：同一台 ALB 後面可以掛好幾個服務，各有各的網址（第 10 節）。
③目標群組（Target group）：一群做同一件事的容器。ECS 開新容器時自動把它登記進來，關掉時自動移除。
④健康檢查（Health check）：定期對每個容器發一個請求，看它還能不能正常回應（第 6 節）。
5. 一個請求走過的路
店家在銷貨單按「存檔」時：
- 店家的瀏覽器用 HTTPS 送出請求，先到 CloudFront 在台灣附近的節點。
- 存檔這種請求每次內容都不同，CloudFront 不能拿快取回應，於是轉送到東京的 ALB。
- ALB 解開 HTTPS，看規則決定要交給哪個目標群組，再從群組裡挑一個健康的容器。
- 容器的 C# 程式收到請求，經過 RDS Proxy 寫進 Aurora，把結果原路回傳。
「HTTPS 在 ALB 解開」是什麼意思：加密是為了不讓網路上的人偷看。店家到 ALB 這段要經過網際網路，所以要加密；ALB 到容器這段在 AWS 的私人網路裡，外面的人碰不到，Express Mode 預設就用一般 HTTP。好處是 C# 程式不用管憑證，憑證到期也是 AWS 自動換。
6. 健康檢查
Express Mode 建好的目標群組預設這樣檢查：
| 設定 | 預設值 | 白話 |
|---|---|---|
| 檢查路徑 | / | 對每個容器發 GET / |
| 間隔 | 30 秒 | 每 30 秒問一次 |
| 逾時 | 5 秒 | 5 秒內沒回應就算失敗 |
| 判定不健康 | 連續 2 次失敗 | 大約 1 分鐘內就不再派單給它 |
| 判定恢復健康 | 連續 5 次成功 | 大約 2 分半後重新派單 |
| 成功的回應碼 | 200 | 回其他狀態碼都算失敗 |
| 新容器的寬限期 | 300 秒 | 剛啟動的 5 分鐘內，健康檢查沒過也不會被 ECS 換掉 |
容器全部不健康時，ALB 反而全部都派：AWS 稱為 fail open。如果群組裡的容器全都沒通過檢查，ALB 會當作檢查本身出了問題，把請求平均派給所有容器，不是全部擋掉。
這帶出一個設計重點：健康檢查的路徑要很輕，例如專門寫一個 /health，只回「程式還活著」，不要在裡面查資料庫。如果檢查會查資料庫，資料庫一慢，所有容器同時被判不健康，ECS 會開始輪流換容器，問題反而變大。資料庫的狀況交給監控和告警（第 8 題）去看。
7. 怎麼分派：輪流、最少處理中、黏著
| 方式 | 做法 | 適合 |
|---|---|---|
| 輪流（Round robin，預設） | 健康的容器依序一人一個 | 每個請求的工作量差不多 |
| 最少處理中（Least outstanding requests） | 派給手上還在處理的請求最少的那個 | 請求的輕重差很多，例如有的開單、有的跑報表 |
| 加權隨機（Weighted random） | 隨機挑，可以搭配「自動降低出錯容器的流量」（ATW） | 容器偶爾會有一個出狀況、又不至於健康檢查失敗 |
第一版用預設的輪流就好。等報表變多、監控看到某些容器特別忙，再考慮改成最少處理中，隨時可以改。
黏著（Sticky sessions）：耀達 Lite 不需要
ALB 可以發一個 Cookie，讓同一個使用者之後的請求都送到同一個容器。這是給「把登入狀態存在容器記憶體裡」的舊式程式用的。耀達 Lite 的容器不存狀態（db-scaling.html 第 4 節），任何容器都能處理任何請求，所以不開。不開的好處：容器數量變動時，流量馬上就能平均分配。
8. 部署與縮減時：先排空再關掉
容器要被關掉時（發布新版、半夜縮減），ALB 不會直接把它拔掉：
- ECS 把容器從目標群組移除，容器進入「排空中」（draining）。
- ALB 不再派新的請求給它，但讓它把手上的請求做完。
- 手上沒有請求了就完成移除；最多等 300 秒（預設）。
- ECS 才送出停止訊號，容器有 30 秒收尾（Express Mode 預設），之後強制關閉。
Express Mode 發布新版用的是金絲雀部署（canary）：先讓一小部分流量走新版，沒出錯再全部切過去。Express Mode 另外建一個警報，專門偵測部署出錯。這個部署方式在 Express Mode 裡不能改。
對寫程式的影響：C# 程式收到停止訊號時，要讓手上的請求做完再結束。ASP.NET Core 有內建的關機等待機制，實作時要確認等待時間不超過容器的 30 秒收尾時間（這個搭配還沒實測）。
9. 要小心的限制
閒置逾時預設 60 秒：一條連線超過 60 秒都沒有資料往來，ALB 就切斷它。店家按「匯出全年銷貨明細」，如果伺服器算了 70 秒才開始回傳，店家會看到錯誤。
- 可以把逾時調長（1～4000 秒），但這只是治標。
- 治本是
db-scaling.html第二階段寫的：成本計價、匯出改成背景工作。按下去先回「處理中」，做好再通知店家下載。第一版的報表如果都很快，可以先不做，但匯出功能設計時就要想好。 - AWS 建議程式本身的連線逾時要比 ALB 長，不然偶爾會出現 502 錯誤。
- 至少要兩個可用區域：ALB 一定橫跨兩個以上的機房，所以 VPC 至少要有兩個子網路，各在不同的可用區域。Express Mode 用預設 VPC 時會自動處理。
- 健康檢查不支援 WebSocket：以後如果要做「別人改了庫存，畫面即時更新」這類功能，健康檢查仍然用一般的 HTTP 路徑。
- 常見的錯誤碼：店家看到 502 通常是容器回應有問題或連線被容器先關掉；503 是沒有任何容器可以派；504 是容器太久沒回應。監控要盯這三個數字。
10. Express Mode 幫忙建好的 ALB
用 Express Mode 建立服務時，AWS 一次建好下面這些，不用自己一個一個設定：
| 項目 | Express Mode 的預設 |
|---|---|
| 監聽器 | HTTPS 443，附一張 AWS 自動申請的憑證（給它產生的網址用） |
| 規則 | 依主機名稱分派 |
| 公開或內部 | 看給它的子網路：公開子網路就建公開的 ALB，私有子網路就建內部的 ALB |
| 共用 | 同一個 VPC 裡最多 25 個 Express Mode 服務共用一台 ALB，超過才自動多建一台 |
| 健康檢查 | 第 6 節的那些預設值 |
| 自動擴充 | CPU 平均維持在 60%；最少 1 個、最多 20 個容器。也可以改成依記憶體或依「每個容器每秒的請求數」（這個數字就是 ALB 量出來的） |
| 部署 | 金絲雀部署，不能改 |
| 存取紀錄 | 預設關閉 |
兩件跟第 7 題「環境與發布」有關的事，這裡先記下，不在這裡決定：
- 測試區如果跟正式區放在同一個 VPC，會共用同一台 ALB。省錢，但兩邊的流量、設定綁在一起。要分開就放不同的 VPC 或不同的 AWS 帳號。
- AWS 文件寫明，Express Mode 服務的負載平衡器設定「不能更新」。ALB 本身的屬性（例如閒置逾時、存取紀錄）可以到 ALB 那邊改，但跟 ECS 服務綁在一起的那部分由 Express Mode 管。如果以後需要很細的控制，可能要從 Express Mode 改成自己建 ALB 與 ECS 服務。
11. ALB 跟 CloudFront 怎麼接
店家的請求要先過 CloudFront（才會經過 WAF 防火牆），再到 ALB。重點是不能讓人繞過 CloudFront 直接打 ALB，不然防火牆形同虛設。有兩種擺法：
| 甲：公開 ALB，只收 CloudFront | 乙：內部 ALB＋VPC origin | |
|---|---|---|
| 怎麼擋繞路 | ALB 的安全群組只允許 CloudFront 的 IP 範圍；再由 CloudFront 加一個祕密標頭，ALB 規則沒看到就拒絕 | ALB 根本沒有公開位址，網際網路連不到 |
| 為什麼甲還要祕密標頭 | CloudFront 的 IP 範圍是所有人的 CloudFront 共用的。別人也可以開一個自己的 CloudFront 指向我們的 ALB，只靠 IP 範圍擋不掉，要再檢查只有我們知道的標頭。乙沒有這個問題。 | |
| 容器連外面的服務（寄信、金流、電子發票、拉程式映像檔） | 容器有自己的公開 IP，直接連出去 | 私有子網路要另外架 NAT 閘道才能連出去 |
| 額外費用 | ALB 與每個容器的公開 IP，每個每小時 0.005 美元 | NAT 閘道：第三方整理的東京價格約每小時 0.062 美元（一個月約 45 美元）加每 GB 0.062 美元，未在 AWS 官方頁確認 |
| 設定難度 | Express Mode 預設就接近這樣，再補安全群組與標頭規則 | 要自己規劃 VPC、子網路、NAT |
已查證的事實：
- CloudFront 的 VPC origin 支援東京（可用區域
apne1-az3除外），也支援台北。 - CloudFront 月費方案的官方文件建議用 VPC origin，讓 ALB 只收 CloudFront 的流量；在月費方案下，CloudFront 跟 ALB 之間的傳輸費用免收。
- VPC origin 不支援 gRPC 與 Lambda@Edge 的部分觸發點，耀達 Lite 都用不到。
未驗證：Express Mode 建的 ALB 只開 HTTPS，憑證是給它自動產生的網址用的。CloudFront 用 VPC origin 或自己的網域連過去時，憑證與主機名稱要怎麼對上，還沒有查到明確的文件，也還沒實測。真正建置前要先試一次，這可能是 Express Mode 跟乙方案之間的接縫。
Claude 的看法（還沒定，留到第 7 題再問）：第一版傾向甲。容器一定要連外面的服務（至少寄信、金流），乙每個月多出的 NAT 費用比甲的公開 IP 費用高；甲配上祕密標頭，安全性在第一版夠用，而且最貼近 Express Mode 的預設。等店家數上來、或公司資安要求更嚴時再搬到乙。
12. 費用（東京）
價格取自 AWS 官方價目表（東京 ap-northeast-1），未稅，以美元計：
| 項目 | 單價 | 一個月（730 小時） |
|---|---|---|
| ALB 本身 | 0.0243／小時 | 約 17.7 |
| LCU（用量單位，見下方） | 0.008／LCU‧小時 | 平均 1 LCU 約 5.8 |
| 公開 IPv4 位址（甲方案的 ALB，兩個可用區域至少 2 個） | 0.005／個‧小時 | 約 7.3 |
| 公開 IPv4 位址（甲方案每個容器 1 個） | 0.005／個‧小時 | 每個約 3.65 |
LCU 怎麼算
LCU 是「ALB 這一小時忙不忙」的單位，看下面四項，取用量最高的那一項計費：
| 項目 | 1 LCU 等於 |
|---|---|
| 新連線 | 每秒 25 條 |
| 同時連線 | 每分鐘 3,000 條 |
| 處理的資料量 | 每小時 1 GB（容器當目標時） |
| 規則判斷 | 每秒 1,000 次；前 10 條規則免費，規則不超過 10 條時這項不算 |
耀達 Lite 第一版（試用到幾百家店），平均通常不到 1 LCU，表上用 1 LCU 算是偏高的估計。
粗估：甲方案、兩個容器時，ALB 相關每月約 17.7＋5.8＋7.3＋7.3 ≈ 38 美元。實際數字等月費試算時用 AWS Pricing Calculator 一起算。
免費額度：價目頁同時寫著舊制（每月 750 小時＋15 LCU）和 2025-07-15 之後的新制（新帳號最多 200 美元抵用額度）。適用哪一種要看公司 AWS 帳號何時開，不要先算進去。
13. AWS 的其他負載平衡器
| 種類 | 看什麼 | 適合 | 耀達 Lite |
|---|---|---|---|
| Application Load Balancer | HTTP 內容：網址、主機名稱、標頭 | 網站、API | 用這個（Express Mode 固定用它） |
| Network Load Balancer | 只看 IP 與連接埠，不看 HTTP 內容 | 極高流量、需要固定 IP、非 HTTP 的協定 | 用不到 |
| Gateway Load Balancer | 把流量導去防火牆設備檢查 | 自己架網路資安設備 | 用不到 |
| Classic Load Balancer | 舊世代 | 舊系統 | 不要用 |
API Gateway 也能擋在程式前面，但它比較適合搭 Lambda；耀達 Lite 用的是常駐容器，ALB 比較直接，也是 Express Mode 的固定組合。
14. 名詞對照
| 名詞 | 白話 |
|---|---|
| 負載平衡器（Load Balancer） | 把請求分給多台伺服器或容器的接待員 |
| 監聽器（Listener） | 在某個連接埠等請求的入口，HTTPS 憑證掛在這裡 |
| 規則（Rule） | 決定請求要送去哪個目標群組的條件 |
| 目標群組（Target group） | 一群做同一件事的容器 |
| 健康檢查（Health check） | 定期問每個容器「你還好嗎」 |
| 排空（Draining） | 不再派新請求、等手上的做完 |
| 黏著（Sticky session） | 同一個使用者固定送到同一個容器；耀達 Lite 不用 |
| 可用區域（Availability Zone） | 同一個地區裡互相獨立的機房 |
| 安全群組（Security group） | AWS 的防火牆規則，決定誰能連進來 |
| VPC／子網路 | 公司在 AWS 裡自己的私人網路，再切成幾塊 |
| VPC origin | 讓 CloudFront 從私人網路直接連到內部 ALB 的功能 |
| NAT 閘道 | 讓私有子網路裡的容器可以連出去、外面卻連不進來的出口 |
| LCU | ALB 的用量計費單位 |
| 金絲雀部署（Canary） | 先讓一小部分流量試新版，沒問題才全部切換 |
15. 來源
- AWS：Amazon ECS Express Mode（不另收費、共用 ALB）
- AWS：Resources created by Amazon ECS Express Mode services（ALB、目標群組、健康檢查、擴充、部署的預設值；最多 25 個服務共用一台 ALB）
- AWS：Health checks for Application Load Balancer target groups（預設值、fail open、不支援 WebSocket）
- AWS：Edit target group attributes（排空 300 秒、分派方式、黏著、跨可用區域）
- AWS：Edit attributes for your Application Load Balancer（閒置逾時 60 秒、keepalive 3600 秒）
- AWS：Elastic Load Balancing pricing（LCU 的四個項目、免費額度）
- AWS 價目表 API：
pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSELB/current/ap-northeast-1/index.json（東京 ALB 每小時 0.0243、LCU 0.008，2026-10-30 下載） - AWS：Amazon VPC pricing（公開 IPv4 每小時 0.005，負載平衡器也算）
- AWS：Restrict access with VPC origins（支援地區、限制）
- AWS：CloudFront flat-rate pricing plans（月費方案下 CloudFront 到 ALB 的傳輸費免收、建議用 VPC origin）
- cloudburn.io：AWS NAT Gateway Pricing（第三方，東京 NAT 閘道價格，未在官方頁確認）