→ Klauhal: Application更新憑證很話時間在等待上= = 12/25 11:25
推 Wishmaster: 你為何不開個 case, aws lb 本來就會單獨故障... 12/26 01:20
最近公雲AWS上website主機前端的SSL termination L4負載平衡障礙了一個多小時
a. 同一公雲多系統，僅一個LB tls加解密失效（firewall traffic log看到的app_proto =
tls變為unknown），其他系統與LB都狀態正常
b. aws nlb底層是nginx docker容器，過程中確定異常容器不會自動kill故障容器，再重啟
新容器，nlb屬於軟體定義網路
c. 非website憑證效期問題，且nslookup正常
d. 多系統共享地端至公雲傳輸專線與網路，僅一個系統nlb tls失效，其他系統地端至公雲
nlb網路連線網站正常
e. 非aws sg問題，非aws fw問題，障礙期間aws用戶資源都沒組態變動，一個多小時後，此
nlb自動恢復tls正常，網站連線恢復正常。推測aws底層單一實體機障礙導致nlb容器障礙，
aws解決底層硬體問題後，恢復nlb運作
請教各位大大有過這樣或類似經驗？
nlb log如何外拋至cloudwatch或cloudtrail？
如何偵測nlb失效與復原作業？
Azure LB與GCP LB類似經驗？
謝謝閱讀與指教
參考：
（1）AWS Network Load Balancer在 OSI 模型的第4層（傳輸層）運作，主要處理 TCP 和
UDP 流量。它可實現高可用、高擴展性的負載平衡，支援跨可用區部署，並能處理極高的連
線數量與低延遲需求。適合需要直接控制流量轉送、需要支援靜態 IP 或需要處理非 HTTP(
S) 協定的應用場景。
（2）AWS Application Load Balancer 在 OSI 模型的第7層（應用層）運作，專門處理 HT
TP 和 HTTPS 流量。支援基於請求內容（如 URL、HTTP 標頭、主機名稱等）的進階路由功
能，可實現微服務架構、容器化應用的精細流量管理。提供 SSL/TLS 加密、支援 Lambda
函數、容器化應用，以及豐富的監控與自動擴展功能。
（3）Azure Application Gateway，提供 HTTP(S) 等第7層的流量路由與進階功能（如 WAF
、URL 路由等）。
（4）Azure Load Balancer，負責 TCP/UDP 的第4層負載平衡，支援高可用性與跨區域部署
。Azure Load Balancer 主要功能支援 TCP 和 UDP 協定的流量分發。可部署在虛擬網路內
或對外提供服務。支援區域與跨區域負載平衡，具備高可用性與低延遲。
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.230.100.80 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/MIS/M.1766586976.A.DF6.html