Auto Scaling and Monitoring — Elastic Load Balancing、CloudWatch、EC2 Auto Scaling。針對 AWS Certified Cloud Practitioner 考試整理重點與常見誤區。
# 10.1 Elastic Load Balancing(ELB)
生活比喻
ELB 像賣場門口的排隊引導員：看到哪個結帳櫃檯人少就把你導過去，而且他會隨時確認每個櫃檯是不是還開著 —— 櫃檯關了就不再把客人往那邊送。
- 自動把流入的流量分散到多個目標 (EC2、容器、IP 位址), 而且可以跨多個可用區域
- 健康檢查 (Health Check): 定期偵測目標是否正常， 只把流量送給健康的目標 —— 這是它提升可用性的關鍵機制
- 本身是受管服務， 具備高可用性且會自動擴展，不需要你操心它的容量
- 可整合 SSL/TLS 憑證 (搭配 ACM), 在負載平衡器層處理 HTTPS
# 三種負載平衡器
| 類型 | 運作層級 | 適用情境 |
|---|---|---|
Application Load Balancer (ALB) | 第 7 層 (HTTP/HTTPS) | 網頁應用；可依 URL 路徑或主機名稱做路由 |
Network Load Balancer (NLB) | 第 4 層 (TCP/UDP) | 需要極高效能、超低延遲、固定 IP 的場景 |
Gateway Load Balancer (GWLB) | 第 3 層 | 部署第三方虛擬網路設備 (如防火牆) |
考試重點
ALB 與 NLB 的區辨是常考題: 要看 HTTP 內容、依網址路徑分流 → ALB; 要求極致效能、超低延遲、TCP 層 → NLB。另外要記得 ELB 提供的是「高可用」而非「擴展容量」—— 它只負責分流，真正增減機器的是 Auto Scaling。
# 10.2 Amazon CloudWatch
生活比喻
CloudWatch 像汽車的儀表板加上警示燈：隨時顯示車速、油量、水溫 (指標), 油快沒了就亮燈提醒你 (警示), 而且會把行車紀錄存下來 (日誌)。
定義
Amazon CloudWatch:AWS 的監控與可觀測性服務，收集資源與應用程式的指標 (Metrics)、日誌 (Logs) 與事件 (Events), 並可依條件觸發警示 (Alarms) 與自動化動作。
# 核心元件
| 元件 | 做什麼 |
|---|---|
| Metrics (指標) | 數值型的監控資料，如 CPU 使用率、網路流量、磁碟讀寫 |
| Alarms (警示) | 指標超過門檻時觸發動作，如發送通知或啟動 Auto Scaling |
| Logs (日誌) | 集中收集與查詢應用程式與系統日誌 |
| Events / EventBridge | 依系統事件觸發自動化流程 |
| Dashboards (儀表板) | 把多個指標視覺化在同一個畫面 |
常見誤區
兩個高頻陷阱。第一，CloudWatch 監控「效能與健康狀態」,CloudTrail 記錄「誰呼叫了什麼 API」—— 這組區辨在 Module 4 出現過，這裡會再考一次。第二， 記憶體使用率不是 EC2 的預設指標，因為那屬於作業系統內部；要監控記憶體必須安裝 CloudWatch Agent。這題常出現在進階題目裡。
# 10.3 Amazon EC2 Auto Scaling
生活比喻
Auto Scaling 像餐廳的彈性排班：中午尖峰時段自動多叫幾個工讀生來，下午冷清就讓人下班。你不用整天養著十個店員在那邊等客人，也不會在客滿時只有兩個人手忙腳亂。
# 核心元件
| 元件 | 作用 |
|---|---|
| 啟動範本 (Launch Template) | 定義新機器怎麼開：用哪個 AMI、什麼機型、哪個安全群組 |
| Auto Scaling 群組 (ASG) | 管理一群 EC2, 設定最小值 (Minimum)、期望值 (Desired)、最大值 (Maximum) |
| 擴展政策 (Scaling Policy) | 依什麼條件增減機器，通常由 CloudWatch 警示觸發 |
# 擴展政策類型
- 目標追蹤 (Target Tracking): 設定一個目標值，例如「平均 CPU 維持在 50%」, 系統自動調整 —— 最常用也最簡單
- 簡單 / 逐步擴展 (Simple / Step Scaling): 依 CloudWatch 警示分級增減特定數量
- 排程擴展 (Scheduled Scaling): 已知尖峰時段時，依時間表預先擴展
- 預測性擴展 (Predictive Scaling): 依歷史模式預測未來需求並提前擴展
定義
水平擴展 (Scale Out / In): 增加或減少機器的數量 —— 這是 Auto Scaling 做的事，也是雲端的標準做法。垂直擴展 (Scale Up / Down): 把單一機器換成更大或更小的規格，通常需要重啟。考試提到 Auto Scaling 時指的都是水平擴展。
考試重點
Auto Scaling 帶來三個好處，常直接考: 更好的容錯能力 (自動汰換不健康的執行個體)、更好的可用性 (需求上升時自動增加)、更好的成本管理 (需求下降時自動減少，不用養閒置機器)。另外要記住 Auto Scaling 本身不收費，你只付它開出來的 EC2 資源費用。
# 10.4 三者如何協同運作
這三個服務單獨看都很簡單，但考試最愛考的是它們合起來怎麼運作。一個標準的彈性架構是這樣運轉的:
- ELB 接收使用者流量，分散給 Auto Scaling 群組中健康的 EC2
- CloudWatch 持續監控這些 EC2 的 CPU 使用率等指標
- 當平均 CPU 超過設定門檻，CloudWatch 警示觸發
- Auto Scaling 收到訊號，依啟動範本開出新的 EC2 執行個體
- 新機器自動註冊到 ELB, 通過健康檢查後開始接收流量
- 尖峰過後 CPU 下降，Auto Scaling 自動縮減機器數量以節省成本
考試重點
記住各自的分工，別搞混:ELB 負責「分流」、CloudWatch 負責「看數據並發警報」、Auto Scaling 負責「增減機器」。題目若問「哪個服務負責在流量上升時自動增加 EC2」→ Auto Scaling (不是 ELB); 問「哪個服務確保流量不會送到掛掉的機器」→ ELB 的健康檢查。
# 10.5 服務詞彙速查
| 名稱 | 一句話定義 |
|---|---|
| ELB | 把流量分散到多個健康目標的負載平衡服務 |
| ALB | 第 7 層負載平衡器，可依 URL 路徑路由 |
| NLB | 第 4 層負載平衡器，極低延遲高效能 |
| Health Check | ELB 偵測目標是否健康的機制 |
| CloudWatch | 監控指標、日誌與事件，可觸發警示 |
| CloudWatch Alarm | 指標超過門檻時觸發通知或自動化動作 |
| Auto Scaling Group | 管理一群 EC2, 設定最小 / 期望 / 最大數量 |
| Launch Template | 定義新執行個體規格的範本 |
| Target Tracking | 維持某指標在目標值的擴展政策 |
| Scale Out / In | 水平增加 / 減少機器數量 |
# 重點回顧
- ELB 分流並做健康檢查，只把流量送給健康的目標；ALB 走第 7 層 (HTTP),NLB 走第 4 層 (TCP, 超低延遲)。
- CloudWatch 監控效能與健康 (指標、日誌、警示); 記憶體使用率需另裝 CloudWatch Agent。
- CloudWatch 看「效能」,CloudTrail 看「誰呼叫了什麼 API」—— 兩者不要混淆。
- Auto Scaling 做水平擴展，由 ASG 設定最小 / 期望 / 最大值，常用目標追蹤政策；服務本身免費。
- 三者協同：ELB 分流 → CloudWatch 監控觸發警示 → Auto Scaling 增減機器 → 新機器註冊回 ELB。
# 自我測驗
哪個服務負責在流量上升時自動增加 EC2 執行個體?
答：Amazon EC2 Auto Scaling。 ELB 只負責把流量分散給現有的機器，實際增減機器數量的是 Auto Scaling。
ALB 和 NLB 差在哪裡?
答：ALB 運作在第 7 層 (HTTP/HTTPS), 可依 URL 路徑或主機名稱路由；NLB 運作在第 4 層 (TCP/UDP), 提供極低延遲與極高效能。
CloudWatch 和 CloudTrail 的用途有什麼不同?
答：CloudWatch 監控資源的效能與健康狀態 (指標、日誌、警示);CloudTrail 記錄帳戶內誰在何時呼叫了哪個 API, 用於稽核。
EC2 的記憶體使用率可以直接從 CloudWatch 預設指標看到嗎?
答：不行。 記憶體使用率屬於作業系統內部資訊，不是預設指標，必須安裝 CloudWatch Agent 才能收集。
Auto Scaling 群組要設定哪三個數量參數?
答：最小值 (Minimum)、期望值 (Desired)、最大值 (Maximum)。 ASG 會維持期望值，並在最小與最大值之間調整。
使用 EC2 Auto Scaling 需要額外付費嗎?
答：不用。 Auto Scaling 服務本身免費，你只需要為它啟動的 EC2 執行個體與相關資源付費。
