contract 組成

Load Balancer Contract 可以拆成四個部分：

1. routing contract：哪些路徑導向哪些服務，如何處理權重與版本。
2. health contract：哪些訊號代表可接流量，何時摘除節點。
3. connection contract：長短連線的 idle timeout、keepalive、重試規則。
4. drain contract：版本切換時如何讓 in-flight request 安全收斂。

這四個部分共同定義 rollout 的穩定性。服務端 readiness 與平台端健康檢查要對位，否則會出現「服務已啟動但尚未可服務」的切換抖動。

draining 與 shutdown

draining 的責任是讓舊實例在下線前完成現有請求。drain 視窗的 workload 分類詳見 5.6 Platform Lifecycle Contract，本段聚焦 LB 如何配合 drain：短請求 API 的 drain 視窗可較短；長連線、串流或 websocket 場景需要更長窗口與明確 reconnect 策略。

部署流程中，LB 摘流量、服務停止接新請求、服務完成在途請求、實例退出，這四步要有固定順序。順序穩定後，rollback 才能在同一套機制下運作。

timeout 與 sticky session

idle timeout 是連線資源與使用者體驗的平衡點。timeout 太短會增加重連與錯誤，太長會占用連線與資源。設定時依請求型態與峰值流量校準、按 SLI 訊號迭代閾值。

Timeout 層級串聯

一條請求路徑上的 timeout 分佈在多個層級，每層各自有預設值。全路徑的 timeout 設計原則是由外到內遞減：外層（離使用者近）的 timeout 要大於內層（離資料源近），否則外層先放棄，內層還在處理一個已經沒人等的請求。

這張表的每一層 timeout 都要比它的下一層大。如果 LB timeout 30 秒但 application 設了 60 秒，LB 會在 30 秒回 504 給使用者，但 application 仍然持有連線等 DB 回應——佔用連線資源卻無法交付結果。

timeout 設計的常見失誤是只調 LB 層：團隊看到使用者回報 timeout，直接把 LB timeout 從 30 秒調到 120 秒。結果是慢請求佔用 LB 連線更久、連線池被慢請求填滿、其他正常請求也開始排隊 timeout。穩定做法是先在 application 或 DB 層找出延遲根因，而非放大外層 timeout 來「等更久」。

sticky session 適合需要短期會話一致性的場景，但它會提高特定節點負載不均與失效轉移成本。採用 sticky policy 前要先定義會話狀態落點與失效時的回復路徑。

LB + CDN 連線生命週期協調

當 LB 上游有 CDN 時、兩層的 timeout / retry 行為要對齊、否則會出現「使用者已經 timeout 但 origin 還在處理」這類雙層不一致：

• CDN edge timeout 通常比 origin LB timeout 短（5-30 秒）— edge 認定 origin 慢就放棄。若 origin LB timeout 是 60 秒、edge 在 30 秒已放棄回 504、origin 還在處理一個沒人在意的 request。應對齊兩邊的 timeout 上限。
• CDN retry policy 在 edge miss 後若拿不到 origin response、預設不會重試（避免雙倍 origin 流量）— LB 端的 idle timeout 設計要假設「只有一次機會」、不依賴上游重試
• 長連線（WebSocket、SSE、gRPC）通常繞過 CDN — 直接連到 origin LB。這些連線的 idle timeout 跟一般 HTTP 不同、要單獨配置
• Edge cache HIT 時 LB 完全沒收到 request — 容量規劃時要把 cache hit ratio 算進 origin RPS、不是用使用者 RPS 直接 size LB

詳見 5.9 邊緣分發與靜態資源 的 origin protection 段。

切流失敗的回退判讀

切流失敗的回退判讀第一步是先分辨「平台問題」跟「流量生命週期問題」、再決定回退手法。平台問題用重啟服務恢復、流量生命週期問題用凍結切換並等待震盪收斂。回退手法錯位會把事故推進第二階段。

切流失敗的本質是 connection lifecycle 跟切換時序錯位、平台元件本身往往是健康的。對應 5.C9 反例：平台切流未先 Draining：揭露切流失敗常因 connection lifecycle 管理錯位、重啟動作會放大震盪。以下基於通用工程知識展開回退節奏。

回退節奏有兩個時序階段、性質不同。

第一階段：先讓震盪不擴大。發現切流失敗的第一動作是凍結 rollout（不再擴大切換範圍）跟恢復舊入口權重（把 LB 規則 / DNS 加權 / service mesh 流量切回舊版本主導）。新版本不立即關閉、保留作為對照證據。這個階段的目標是穩定當前狀態、為後續分析爭取時間、所有動作要在分鐘級內完成。

第二階段：再讓系統可恢復。震盪不擴大後、進入「等待 + 修正」狀態。長連線跟 reconnect 風暴需要時間消化、盲目重啟新版本實例會把重連集中在新一輪實例上、造成 thundering herd。觀察連線數、reconnect rate、5xx 趨勢回到 baseline 是進入修正階段的訊號。修正動作聚焦於 drain window、idle timeout、health check、client retry 之間的節奏錯位、找出後修正、重新進入小範圍驗證。這個階段的時間尺度通常是小時級、不能用第一階段的緊急節奏對待。

兩階段時序不能合併。把第一階段（凍結 + 切回）跟第二階段（等待 + 修正）並列執行、會在連線尚未穩定時嘗試修正、造成第二次震盪。

回退時最常見的誤判是「LB 顯示新節點 healthy = 服務可服務」。LB 的健康判斷通常是定期 health check 通過，跟「該節點能承受重連潮」是不同問題。事故中要把這兩個訊號分開看：節點層健康（health check pass）、連線層健康（reconnect rate、長連線錯誤率、tail latency）。

切流告警條件

對應 5.C9 反例 的「部署專屬告警條件」段：揭露切流期告警的三個核心訊號（批次內 5xx 突增、長連線重連率快速上升、rollback time 超過既定 RTO）。本段在 case 三條基礎上補第 4 條（per-version error rate 偏離）與操作建議。

切流期告警的核心責任是對應切流批次節奏、跟日常閾值分離。日常閾值在切流期會被切換本身的短暫波動觸發、變成 alert noise；切流期需要更嚴格的「批次內偏差」訊號。

可操作的切流期告警條件：

• 批次內 5xx 異常升高：當前批次相對於前一批的 5xx 升幅超過閾值、停止下一批。
• 長連線重連率飆升：reconnect rate 超過 baseline N 倍、暗示 drain / timeout 錯位。
• 回退時間超過 RTO：執行回退後恢復時間超過既定 RTO、升級為事故等級。
• per-version error rate 偏離：新舊版本 error rate 差距超過閾值、不收斂（屬本章補強、case 未明示）。

這些告警的閾值要在 release plan 中先定義、進事故時直接套用、避免臨時拍定。把切流告警跟一般日常告警分流到不同 channel，避免事故團隊在切流期被日常 noise 淹沒。

判讀訊號

「回退後 reconnect 風暴持續」是切流事故中最容易誤判的訊號。判讀順序：先看是否「凍結切換」已執行（rollout 是否真的停了）、再看「舊入口權重」是否回到主導比例（DNS / LB 規則是否切回）、最後看連線數曲線是否進入下降。三項都做完仍見風暴持續、才考慮新版本實例層級的問題（image / config / runtime 漂移）、而非反向重啟新版本。解凍切換的條件是「連線數曲線回到 baseline + reconnect rate 低於閾值連續 N 分鐘」、不是「等夠久了就解凍」的時間導向。

常見誤區

把 load balancer 當成「只做轉發」的元件，會忽略它在部署與事故中的決策角色。LB 設定定義了流量切換節奏、回退可行性與故障擴散速度。

Health check 跟 readiness 的混淆會在切換時暴露隱性風險。health contract 要反映服務真實 readiness — 含依賴連線池、必要 config、關鍵背景任務狀態 — 而非停在單一探針成功訊號。

把「LB 顯示節點 healthy」當作「服務可承受流量」的訊號，也是事故中的常見誤判。健康檢查通過跟承受重連潮是不同層級的訊號。

案例回寫

流量契約可用 5.C9 反例 回寫。先看事件中的摘流量順序、drain 視窗與連線重建節奏，再回到本章判讀 connection contract 與 drain contract 是否對齊。

這個案例主要支撐的是「連線生命週期與摘流量順序」判讀，不直接支撐 container build 可重現性；若根因在映像與 runtime 漂移，應回到 5.1。

當回退後錯誤率仍高或重連風暴延續，通常表示 timeout 與 sticky policy 仍在放大舊連線狀態。先重建連線生命週期時序，再把回退判斷同步到 8.19 Incident Decision Log。

跨模組路由

load balancer contract 是部署平台與操作控制面的匯流點。

1. 與 5.6 的交接：drain 的生命週期定義與 workload 分類回到 Platform Lifecycle Contract。
2. 與 04 的交接：版本切換訊號與錯誤率證據進入 Observability Evidence Package。
3. 與 06 的交接：canary 放行與回退條件進入 Release Gate。
4. 與 07 的交接：入口治理與管理面保護進入 7.3 入口治理與伺服器防護。
5. 與 08 的交接：切換與回退判斷記錄到 Incident Decision Log。
6. 與 5.9 邊緣分發 的交接：CDN 是 origin LB 的上游、edge miss 後流量進 origin LB、timeout / retry 設定要協調。

下一步路由

要把 LB 合約放進整體部署流程，接著讀 5.2 Kubernetes 部署策略 與 5.C9 反例。要把部署切換接到事故流程，接著讀 8.19 Incident Decision Log。

ALB 掛在 public subnet、引用專屬的 security group，security group 的入站通常只開 80 和 443 對 0.0.0.0/0（這是少數合理出現全開的位置，因為 ALB 的工作本來就是接收公開流量）。後端運算節點住在 private subnet，它們的 security group 入站只允許來自 ALB security group 的流量 — 這個 group-to-group 引用讓規則跟著成員身分走，不跟著 IP 走（見模組三：網路地基）。

ALB 與 listener 設定

ALB 資源本身描述的是它掛在哪些 subnet、用哪個 security group、是對外（internal = false）還是內部。Listener 則是掛在 ALB 上的監聽端點，每個 listener 綁定一個 port + protocol 的組合。

1resource "aws_lb" "api" {
2  name               = "api-${var.env}"
3  internal           = false
4  load_balancer_type = "application"
5  security_groups    = [aws_security_group.alb.id]
6  subnets            = [for s in aws_subnet.public : s.id]
7}

HTTP 到 HTTPS 的強制跳轉

正式服務通常同時建兩個 listener：port 443 接受 HTTPS 流量並轉發到後端，port 80 接收 HTTP 流量後直接回一個 301 redirect 到 HTTPS — 確保使用者即使用 http:// 開頭訪問也會被導到加密連線。

 1resource "aws_lb_listener" "https" {
 2  load_balancer_arn = aws_lb.api.arn
 3  port              = 443
 4  protocol          = "HTTPS"
 5  ssl_policy        = "ELBSecurityPolicy-TLS13-1-2-2021-06"
 6  certificate_arn   = aws_acm_certificate.api.arn
 7
 8  default_action {
 9    type             = "forward"
10    target_group_arn = aws_lb_target_group.api.arn
11  }
12}
13
14resource "aws_lb_listener" "http_redirect" {
15  load_balancer_arn = aws_lb.api.arn
16  port              = 80
17  protocol          = "HTTP"
18
19  default_action {
20    type = "redirect"
21    redirect {
22      port        = "443"
23      protocol    = "HTTPS"
24      status_code = "HTTP_301"
25    }
26  }
27}

ssl_policy 決定 ALB 接受哪些 TLS 版本與密碼套件。選擇以安全與相容性為取捨 — ELBSecurityPolicy-TLS13-1-2-2021-06 只接受 TLS 1.2 和 1.3，能阻擋過時協定的降級攻擊，但會拒絕仍在使用 TLS 1.0/1.1 的極舊用戶端。對面向公眾的 API 或網站，TLS 1.2 以上是合理的底線；如果有明確的舊用戶端需求（例如嵌入式設備），再往下調但要知道代價。

多服務共用 ALB

一個 ALB 可以掛多個 listener rule，用 host header 或 path 把流量分到不同的 target group。這讓多個微服務共用一個 ALB（省成本），而不需要每個服務各開一個：

 1resource "aws_lb_listener_rule" "auth" {
 2  listener_arn = aws_lb_listener.https.arn
 3  priority     = 10
 4
 5  condition {
 6    path_pattern { values = ["/auth/*"] }
 7  }
 8
 9  action {
10    type             = "forward"
11    target_group_arn = aws_lb_target_group.auth.arn
12  }
13}

一個常見的收斂機會：如果每個服務都各自開了一個 ALB，但流量都從同一個入口進來、只是路徑不同，可以收斂成一個 ALB 加 listener rule。每個 ALB 有固定的小時費，少開幾個月費就少幾筆。反過來，當不同服務的安全等級或流量特性差異大到需要獨立的 security group 和 WAF 規則時，分開 ALB 才合理。

target group 與健康檢查

Target group 定義一組接收流量的後端（ECS task、EC2 instance 或 IP），以及判斷這些後端是否健康的檢查邏輯。它是 ALB 和實際運算之間的橋樑。

 1resource "aws_lb_target_group" "api" {
 2  name        = "api-${var.env}-tg"
 3  port        = 8080
 4  protocol    = "HTTP"
 5  vpc_id      = aws_vpc.main.id
 6  target_type = "ip"
 7
 8  health_check {
 9    path                = "/healthz"
10    interval            = 15
11    healthy_threshold   = 2
12    unhealthy_threshold = 3
13    timeout             = 5
14    matcher             = "200"
15  }
16}

健康檢查的閾值設計

健康檢查的路徑與閾值是最常被忽略的判讀點。各參數之間的交互作用決定了兩個時間窗口：新後端多久後開始接流量、壞後端多久後被移出。

healthy_threshold = 2 配 interval = 15 代表一個新啟動的後端要等 30 秒（兩次通過）才開始接流量。unhealthy_threshold = 3 代表連續三次失敗（45 秒）才被移出。閾值太寬鬆會把壞掉的後端留在輪替裡，讓部分使用者持續收到錯誤；太嚴格會在部署瞬間 — 新容器啟動、應用還在初始化 — 就判定不健康，反覆移出移入，使用者看到間歇性失敗。

健康檢查路徑的選擇

path 指向的端點應該能反映應用是否確實能服務請求，而不只是 process 還活著。一個只回 200 的空端點（所謂 liveness check）證明 HTTP server 在跑，但不代表它能連到資料庫、能讀到必要的 config。較合理的做法是讓 /healthz 至少檢查核心依賴的連線（例如 ping 一下 DB），失敗時回 503。代價是健康檢查會跟著核心依賴一起報不健康 — 如果 DB 暫時斷了，所有後端都會被判定不健康，ALB 會回 503 給使用者。這是正確的行為：如果應用確實無法服務請求，把它標成不健康比假裝健康好。

判讀方式：部署後觀察 target group 裡的 healthy / unhealthy 轉換次數。如果每次部署都看到新 target 在 healthy 與 unhealthy 之間跳動，代表初始等待不夠 — 應用的啟動時間超出 healthy_threshold * interval，考慮加大 healthy_threshold 或設定 ECS 的 startPeriod（啟動寬限期）讓健康檢查在應用初始化期間暫停。

TLS 憑證：ACM 簽發、DNS 驗證與自動續期

HTTPS listener 引用的 TLS 憑證也屬於 ALB 的接線。用 ACM（AWS Certificate Manager）簽發的憑證在 IaC 裡完整描述 — 涵蓋網域與 DNS 驗證方式 — 讓「憑證存在、驗證、掛載」整條鏈都進版本控制，而非在 Console 手動上傳一份會過期沒人盯的憑證。

ACM 簽發的憑證使用 DNS 驗證時，ACM 要求在指定的 DNS 記錄上放一段驗證值。Terraform 可以自動建立這段記錄並等待驗證通過：

 1resource "aws_acm_certificate" "api" {
 2  domain_name       = "api.${var.domain}"
 3  validation_method = "DNS"
 4
 5  lifecycle { create_before_destroy = true }
 6}
 7
 8resource "aws_route53_record" "cert_validation" {
 9  for_each = {
10    for dvo in aws_acm_certificate.api.domain_validation_options : dvo.domain_name => dvo
11  }
12  zone_id = data.aws_route53_zone.main.zone_id
13  name    = each.value.resource_record_name
14  type    = each.value.resource_record_type
15  records = [each.value.resource_record_value]
16  ttl     = 60
17}
18
19resource "aws_acm_certificate_validation" "api" {
20  certificate_arn         = aws_acm_certificate.api.arn
21  validation_record_fqdns = [for r in aws_route53_record.cert_validation : r.fqdn]
22}

create_before_destroy 的必要性

create_before_destroy = true 確保憑證更新（例如加 SAN 或續期觸發重建）時先建新的再刪舊的，避免 listener 在交接期間沒有可用憑證。Terraform 預設行為是先刪後建，會造成一個短暫的 HTTPS 中斷窗口 — listener 找不到憑證、所有 HTTPS 連線失敗直到新憑證簽發並驗證完畢。

ACM 簽發的憑證自動續期：只要 DNS 驗證記錄還在（由 Terraform 管理，所以會一直在），ACM 在到期前 60 天自動續期。這是把憑證管理成本降到接近零的做法 — 不需要排程提醒、不需要手動下載上傳。判讀訊號：如果 CloudWatch 出現 DaysToExpiry 降到 30 以下的 alarm，代表自動續期失敗，通常是 DNS 驗證記錄被手動刪了或 Route 53 zone 變了。

多網域憑證（SAN）

一張 ACM 憑證可以涵蓋多個網域（Subject Alternative Names），例如 api.example.com 和 admin.example.com 共用一張。在 IaC 裡用 subject_alternative_names 列舉：

1resource "aws_acm_certificate" "multi" {
2  domain_name               = "api.${var.domain}"
3  subject_alternative_names = ["admin.${var.domain}", "*.internal.${var.domain}"]
4  validation_method         = "DNS"
5
6  lifecycle { create_before_destroy = true }
7}

共用一張還是分開簽取決於生命週期：如果這幾個網域總是一起上下線、一起變更，共用一張省維護；如果各自獨立演進，分開簽讓變更範圍更小。

DNS zone 管理與 ALB 的銜接

Hosted zone：DNS 記錄的容器

Route 53 的 hosted zone 是一個網域下所有 DNS 記錄的容器。public hosted zone 管理對外可見的網域（如 example.com），private hosted zone 管理只在 VPC 內可解析的內部網域（如 internal.example.com），讓服務之間用 DNS 名稱互連而不靠 IP。

多環境的 DNS 管理常用子網域 delegation：production 用 example.com（主 zone），dev 和 staging 各用 dev.example.com 和 staging.example.com（子 zone）。子 zone 可以放在不同帳號、由不同團隊管理，主 zone 只需要一組 NS 記錄指向子 zone。這讓環境之間的 DNS 邊界跟帳號邊界對齊。

 1resource "aws_route53_zone" "main" {
 2  name = var.domain
 3}
 4
 5resource "aws_route53_zone" "staging" {
 6  name = "staging.${var.domain}"
 7}
 8
 9resource "aws_route53_record" "staging_ns" {
10  zone_id = aws_route53_zone.main.zone_id
11  name    = "staging.${var.domain}"
12  type    = "NS"
13  ttl     = 300
14  records = aws_route53_zone.staging.name_servers
15}

hosted zone 也是 ACM 憑證 DNS 驗證的依賴 — ACM 簽發憑證時需要在對應的 zone 寫入一條驗證記錄，zone 不存在或不在同帳號就接不上。把 zone 的建立排在 ACM 之前，讓依賴圖自然正確。

ALB 的穩定 DNS 記錄

ALB 重建後 DNS 名稱會改變。穩定對外的方式是在 Route 53 建一條 alias 記錄指向 ALB，使用者連的是 api.example.com，DNS 自動解析到 ALB 目前的位址：

 1resource "aws_route53_record" "api" {
 2  zone_id = data.aws_route53_zone.main.zone_id
 3  name    = "api.${var.domain}"
 4  type    = "A"
 5
 6  alias {
 7    name                   = aws_lb.api.dns_name
 8    zone_id                = aws_lb.api.zone_id
 9    evaluate_target_health = true
10  }
11}

evaluate_target_health = true 讓 Route 53 在 ALB 所有 target 都不健康時把這條記錄標為不健康。如果有多個 region 的 ALB 做了 failover routing，這個設定能讓 DNS 層自動切換到健康的 region — 屬於跨區域容災的地基，在 devops 模組展開。

WAF 與下一步

ALB 支援掛載 AWS WAF（Web Application Firewall），在流量進到應用之前先過一層規則 — 擋已知惡意 IP、防 SQL injection / XSS 的常見模式、限制單一 IP 的請求速率。WAF 的規則也可以寫進 IaC，讓「哪些流量被擋」成為可審查的程式碼而非 Console 上的設定。WAF 的詳細設計屬於安全層的範圍（見 backend 模組七：資安與資料保護），這裡只確認它的掛載點是 ALB。

四類核心服務的 IaC 描述到此完成。下一步是讓這些服務可被觀測——log、metric、alarm 跟資源同生命週期建立，見模組六：可觀測性與 log。

跨分類引用

• → 模組三：網路地基：ALB 的 security group 設計，group-to-group 引用
• → 模組五：stateful 資源的保護策略：ALB 是 stateless，但它引用的 ACM 憑證和 DNS 記錄有自己的生命週期考量
• → devops 模組一：負載平衡：ALB 的運行期調校 — 跨 AZ 流量分配、connection draining、sticky session
• → backend 模組七：資安與資料保護：WAF 規則設計

概念位置

ALB 在核心服務層裡的角色是「入口設施」。它掛在 public subnet 的 security group 上（入站允許 80/443），把流量導向 private subnet 裡的 ECS task 或 EC2 instance。ALB 本身是 stateless 的 — 重建一個 ALB 不會遺失資料，但會換掉它的 DNS 名稱，所以對外服務通常在 ALB 前面掛一個穩定的 Route 53 alias record。

TLS 終結是 ALB 的標準職責：HTTPS listener 引用 ACM（AWS Certificate Manager）簽發的憑證，ALB 處理加解密，後端收到的是 HTTP 明文。憑證由 ACM 自動續期，IaC 用 DNS 驗證方式描述憑證 — 讓「憑證存在、續期、掛載」整條鏈都進版本控制。

可觀察訊號

以下狀況指向 ALB 相關問題：

• 使用者看到 502 — ALB 轉發請求但後端回應異常（健康檢查可能通過但實際請求處理失敗），查 target group 的健康狀態和後端 log
• 使用者看到 503 — target group 裡沒有健康的後端，通常是部署期間所有舊 task 停了但新 task 還沒通過健康檢查
• HTTPS 憑證過期警告 — 如果用 ACM 搭配 DNS 驗證，憑證自動續期；看到過期警告代表 DNS 驗證記錄被刪了或 ACM 服務異常

設計責任

使用 ALB 時要決定：

• 健康檢查參數：檢查路徑（用應用層的 health endpoint、不用根路徑）、間隔、閾值。閾值太寬鬆會把壞掉的後端留在輪替裡，太嚴格會在部署瞬間誤判
• HTTP → HTTPS redirect：port 80 的 listener 設定固定回應 301 redirect 到 443，確保所有流量走加密
• TLS 憑證：用 ACM 搭配 DNS 驗證，讓憑證的簽發和續期自動化
• 穩定 DNS：ALB 前面掛 Route 53 alias record，對外暴露的是自己的 domain name 而非 ALB 的隨機 hostname

鄰卡

• Subnet — ALB 跑在 public subnet，後端跑在 private subnet
• Security Group — ALB 的 security group 是系統對外唯一合理開放 0.0.0.0/0 的位置（僅限 80/443）
• ECS — ALB 透過 target group 把流量導向 ECS task

概念位置

Load balancer 位在 client 與 application instances 之間，是服務接流量與停止接流量的入口控制層，常與 Request Routing 搭配使用。

可觀察訊號

系統需要 load balancer 的訊號是服務有多個 instance、要做 rolling update、需要平滑擴容，或必須在故障時把流量移開。

接近真實網路服務的例子

Kubernetes service、edge proxy、API Gateway 或雲端 LB 都會把 request 導到健康節點。長連線服務也常依賴 load balancer 做 draining，避免關閉中的 instance 繼續接新流量，也會透過 idle timeout 回收空閒連線。

設計責任

設計時要定義健康條件、移除條件、回切條件與排空時間。Load balancer 本身不處理業務邏輯，但它直接影響可用性、切換速度與連線體驗。