AWS 認證準備 ch03 自動擴展與負載平衡
下一章→
CH 03 高頻考點

自動擴展與負載平衡

ALBNLBGWLBAuto Scaling Groups擴展策略

本章講兩件互相搭配的機制：負載平衡（ALB / NLB / GWLB 三種各自的分層與用途）與自動擴展（Auto Scaling Group 的三個關鍵數值、四種擴展策略）。理解 ELB 如何與 ASG 協同運作，是設計高可用架構的基本功。

🧱 白話：先分清楚兩個地基詞——Port 是「同一台機器裡的房號」（IP 找到大樓、Port 找到房間），TCP/UDP 是兩種寄送策略（掛號信 vs 明信片）。→ 基礎篇 ch01 網路基礎；TLS/憑證的原理見 基礎篇 ch03 加密與 HTTPS。

這裡的 Layer 3/4/7 指的是 OSI 網路模型的分層——可以想成資料要送到目的地，中間會層層打包/拆包，每一層負責看懂不同的資訊：Layer 3（網路層）只看得懂 IP 位址（送到哪台機器）；Layer 4（傳輸層）多懂 Port 與 TCP/UDP 連線狀態（送到那台機器的哪個服務）；Layer 7（應用層）才看得懂 HTTP 協定本身的內容，例如網址路徑、Header。層級愈高，負載平衡器能檢查、決策的資訊就愈細，但處理起來也相對愈重、延遲愈高。

  • ALB（Application Load Balancer）— Layer 7：看懂 HTTP/HTTPS，可以根據 URL 路徑（/api, /images）、Host Header、HTTP Headers、Query String 來路由流量。支援 WebSocket。最適合：微服務、容器（ECS/EKS）、需要進階路由的 Web 應用。
  • NLB（Network Load Balancer）— Layer 4：處理 TCP/UDP/TLS，速度極快（毫秒級延遲）。支援靜態 IP（Static IP）和 Elastic IP。最適合：高效能場景、需要固定 IP 的應用、遊戲伺服器、IoT。
  • GWLB（Gateway Load Balancer）— Layer 3：用來串接第三方虛擬網路設備（防火牆、IDS/IPS）。使用 GENEVE 協定（6081 埠——GENEVE 是一種流量封裝協定，作用是把原始封包包一層外殼送去給檢測設備看，設備看完再依原樣轉出去，讓「繞去給防火牆檢查」這件事對兩端完全透明）。流量先通過安全設備再轉給後端。
⭐ 選擇口訣：看路徑/Host 選 ALB（Layer 7）；需要固定 IP / 超低延遲 / TCP 選 NLB（Layer 4）；要加虛擬防火牆選 GWLB。
💡 ALB 進階功能：
• 路徑路由：/api/* → 後端 A，/web/* → 後端 B
• 加權目標群組：同一路徑 80% 流量給 v1，20% 給 v2（藍綠部署）
• Lambda 作為目標：ALB 可以直接呼叫 Lambda 函數

Target Group 是 ALB/NLB 路由的目標集合，支援以下類型：

  • EC2 執行個體：最常見，直接指向 EC2。
  • IP 位址：可指向任何 IP，包含 On-Premises 伺服器（透過 VPN/Direct Connect）。
  • Lambda 函數：只有 ALB 支援，NLB 不支援。
  • 另一個 ALB：ALB 可以路由到另一個 ALB（進階路由）。
💡 Health Check：每個 Target Group 都有 Health Check 設定。ALB/NLB 定期檢查目標健康狀態，不健康的目標會被暫時移出輪詢，直到恢復正常。
  • 目的：根據需求自動增減 EC2 執行個體數量，同時確保在多個 AZ 均衡分布，維持高可用。
  • 三個關鍵數值：Minimum（最少幾台）、Desired（期望幾台）、Maximum（最多幾台）。
  • Launch Template：定義 ASG 啟動新實例時的規格（AMI、Instance 類型、SG、User Data 等）。比舊版 Launch Configuration 更靈活，可以混用 On-Demand 和 Spot。
  • ASG + ELB：ASG 新增的 EC2 會自動被 ELB 的 Target Group 登記；被移除的 EC2 會自動被從 Target Group 取消登記。
  • Health Checks：ASG 可以使用 EC2 健康狀態或 ELB 的 Health Check。ELB Health Check 更嚴格（應用層確認），建議生產環境使用。
  • Lifecycle Hooks：在實例啟動或終止過程中插入自訂操作（如安裝軟體、備份資料）。
🚨 考試陷阱：ASG 終止策略預設會先終止最舊 Launch Configuration 的實例，再選擇最靠近下一個計費小時的實例。
  • Manual Scaling（手動）：直接修改 Desired 數量。適合臨時需求或測試。
  • Scheduled Scaling（排程）：在預定時間點調整容量。適合：已知的固定流量規律（如每天早上 9 點上班流量暴增）。
  • Dynamic Scaling — Simple / Step：根據 CloudWatch Alarm 觸發。Simple 是二元（觸發就+N台）；Step 可以設定多段（CPU 70% 加 1 台，CPU 90% 加 3 台）。
  • Dynamic Scaling — Target Tracking：設定一個目標指標值（如 CPU 平均 50%），ASG 自動加減台數來維持這個目標。最推薦、最常用。
  • Predictive Scaling（預測性）：使用 ML 分析歷史流量模式，提前預測並擴展容量，避免反應延遲。
💡 Cooldown Period（冷卻期）：擴展動作執行後，ASG 預設等待 300 秒再評估是否需要再次擴展，避免頻繁波動。使用 Golden AMI 可縮短啟動時間，從而可以縮短冷卻期。
ALB vs NLB vs GWLB 完整比較
特性ALBNLBGWLB
OSI 層Layer 7（應用層）Layer 4（傳輸層）Layer 3（網路層）
協定HTTP, HTTPS, WebSocketTCP, UDP, TLS所有 IP 流量（GENEVE）
路由依據路徑、Host、Headers、QueryIP + Port—（透明傳遞）
靜態 IP❌ 無（只有 DNS）✅ 支援（可綁 EIP）❌
延遲毫秒級極低（微秒級）一般
目標類型EC2, IP, Lambda, ALBEC2, IP, ALBEC2（虛擬設備）
主要用途微服務、ECS、進階路由高效能、固定IP、遊戲防火牆/IDS/IPS 串接
ASG 擴展策略比較
策略觸發方式適合場景推薦度
Manual手動設定 Desired臨時調整、測試低
Scheduled時間排程已知規律的流量高峰（上下班時段）中
Simple / StepCloudWatch Alarm 觸發需要精確控制擴展步驟中
Target Tracking自動維持目標指標值大多數場景的最佳選擇★★★ 最推薦
PredictiveML 預測歷史模式流量有規律週期的應用高（搭配 Target Tracking）

練習題 點選選項查看解析

0 / 24
01 / 24
一個電商網站需要根據 URL 路徑將流量分發：/api/* 導向後端 API 服務，/static/* 導向靜態資源伺服器。應該使用哪種負載平衡器？
A NLB（第 4 層負載平衡器）
B ALB（第 7 層負載平衡器）
C GWLB（第 3 層負載平衡器）
D CLB（傳統負載平衡器）
解析
ALB 是 Layer 7 負載平衡器，可以讀取 HTTP 請求的 URL 路徑、Host Header、查詢字串等，實現進階路由。路徑路由（Path-based routing）正是 ALB 的核心功能，讓同一個 ALB 能分發流量給不同的 Target Group。NLB 在 Layer 4 工作，看不懂 URL 路徑。
02 / 24
一個遊戲公司的後端伺服器使用 UDP 協定，且客戶端遊戲需要連接到固定的 IP 位址（不能 DNS 輪詢）。應該選擇哪種負載平衡器？
A ALB（應用負載平衡器）
B NLB（網路負載平衡器）
C GWLB（閘道負載平衡器）
D Route 53（加權路由）
解析
NLB 是這個場景的唯一選擇：它支援 UDP 協定（ALB 不支援 UDP），且每個 NLB 節點可以綁定 Elastic IP（靜態 IP），讓客戶端可以連接到固定 IP。ALB 只支援 HTTP/HTTPS/WebSocket，且不支援靜態 IP（只有 DNS 名稱）。
03 / 24
一家公司想在其 AWS VPC 和 On-Premises 之間的所有流量上強制套用第三方防火牆設備進行深度封包檢測（DPI）。最適合的 AWS 服務是？
A ALB 搭配 WAF 規則設定
B NLB 搭配 Security Group 設定
C Gateway Load Balancer（GWLB）
D AWS Shield Advanced 服務
解析
GWLB 專門用於將第三方虛擬網路設備（如 Palo Alto、Check Point 等防火牆）整合到 AWS 網路流量路徑中。它在 Layer 3 工作，透明地將所有流量送往虛擬設備進行檢測，再轉回目標。WAF 只能處理 HTTP 層的 Web 攻擊；NLB 不能整合第三方安全設備。
04 / 24
一個 Web 應用使用 ASG 管理 EC2 執行個體。你希望 ASG 自動維持 CPU 使用率在 60% 左右，不需要手動設定觸發規則。最適合的擴展策略是？
A Scheduled Scaling（排程）
B Simple Scaling（簡單）
C Target Tracking（目標追蹤）
D Manual Scaling（手動）
解析
Target Tracking Scaling 是最推薦的動態擴展策略。你只需指定一個目標指標值（如 平均 CPU 60%），ASG 會自動計算需要增減多少實例來維持這個目標，不需要手動設定觸發 Alarm 和加減台數的邏輯。它類似於空調的恆溫模式，最為智慧和簡便。
05 / 24
一個 ASG 正在運行中，你注意到它在壓力測試時頻繁地快速增加實例後又立即縮減，造成系統不穩定。最適合解決這個問題的設定是？
A 提高 Maximum 容量上限
B 縮短 Health Check 寬限期
C 延長 Cooldown Period（冷卻期）
D 改用 Manual Scaling（手動）
解析
Cooldown Period（冷卻期）的作用是在擴展動作後，讓 ASG 暫停一段時間再評估是否需要再次擴展，避免因為連續觸發導致實例數量劇烈抖動。預設 300 秒。增長冷卻期可以讓新啟動的實例有時間穩定並分擔流量，再讓 ASG 重新評估是否還需要更多實例。
06 / 24
ALB 的 Target Group 中，以下哪種目標類型是 NLB 不支援的？
A EC2 執行個體（實例）
B IP 位址（含 On-Premises）
C Lambda 函數（無伺服器）
D 另一個 ALB（巢狀路由）
解析
Lambda 函數只能作為 ALB 的目標，NLB 不支援將 Lambda 作為 Target Group 成員。這是因為 ALB 在 Layer 7 工作，可以處理 HTTP 請求並呼叫 Lambda；而 NLB 在 Layer 4 工作，處理的是 TCP/UDP 連線，無法直接觸發 Lambda。
07 / 24
一個線上課程平台每天固定晚上 8 點大量學生上線、午夜後驟降，流量的時間模式相當固定。最有效率的 ASG 擴展方式是？
A Scheduled Scaling（排程擴展）
B Simple Scaling（單一告警反應）
C 人工每日手動調整台數規模
D 長期維持在最大台數規模
解析
流量有「可預期的時間規律」時，Scheduled Scaling 依排程在尖峰前先擴充、離峰後縮減最有效率。動態策略是反應式、可能有延遲；手動不可靠；長期開最大量浪費成本。
08 / 24
想讓 ASG 根據歷史流量以機器學習「預測」未來需求並提前擴展，且不想自己設定排程時間。應用哪種策略？
A Simple Scaling（簡單擴展）
B Predictive Scaling（預測擴展）
C Manual Scaling（手動擴展）
D Scheduled Scaling（排程擴展）
解析
Predictive Scaling 分析歷史 CloudWatch 資料以機器學習預測未來負載並提前佈署容量，適合有週期性但不想手動排程的情境。Scheduled 需自行指定時間；Simple/Manual 是反應式或人工。
09 / 24
關於 Auto Scaling Group 的三個容量數值（minimum / desired / maximum），何者正確？
A desired 可以超過 maximum 數值
B desired 維持在 min／max 之間
C minimum 代表尖峰時段台數
D 三個數值全部須設成相同
解析
ASG 會盡量維持 desired capacity，並在 minimum（保底）與 maximum（上限）之間依擴展策略調整。desired 不能超過 maximum，也不會低於 minimum。
10 / 24
一台 EC2 的作業系統正常（EC2 狀態檢查通過），但其上的應用程式已當掉無法回應 HTTP。想讓 ASG 汰換這台，應設定 ASG 使用哪種健康檢查？
A 僅使用 EC2 狀態檢查
B 改用 ELB（應用層）健康檢查
C 停用所有健康檢查機制
D 查閱 CloudTrail 稽核紀錄
解析
預設 ASG 只看 EC2 狀態檢查（硬體/OS 層），無法察覺應用當掉。啟用 ELB 健康檢查後，ASG 依負載平衡器對應用端點的健檢結果判定是否不健康並汰換，才能抓到「機器活著但應用掛了」。
11 / 24
使用 ALB 時各 AZ 的後端執行個體數量不均，想讓流量平均分配到「所有 AZ 的所有健康目標」。應？
A 直接關閉健康檢查功能設定
B 啟用 Cross-Zone Load Balancing
C 改為只使用單一 AZ 部署方式
D 增加更多 Listener 監聽規則
解析
Cross-Zone Load Balancing 讓負載平衡器把流量平均分配到所有 AZ 的所有健康目標（而非先平均分到各 AZ 再分內部）。ALB 預設啟用且不收跨 AZ 費；NLB 預設關閉、啟用會產生跨 AZ 資料費。
12 / 24
一個應用把使用者 session 存在各自 EC2 的記憶體中，使用者被導到不同執行個體時 session 就遺失。用 ALB 最直接的緩解方式是？
A 啟用 ALB Sticky Sessions 功能
B 直接關閉健康檢查功能設定
C 整組改用 NLB 取代 ALB 部署
D 減少執行個體數量部署規模
解析
ALB 的 Sticky Sessions 用 cookie 讓同一使用者在一段時間內固定被導到同一後端，暫解 session 綁定問題。更好的長遠做法是把 session 外部化（ElastiCache/DynamoDB）讓後端無狀態。
13 / 24
當 ASG 要移除一台 EC2 時，希望它先處理完現有連線再下線、不中斷進行中的使用者請求。應設定？
A 設定 Deregistration Delay 延遲
B 選擇立即強制終止該實例
C 直接關閉健康檢查功能設定
D 改用 Sticky Sessions 黏性機制
解析
Deregistration Delay（連線耗盡）讓目標在被移除前保有一段時間處理完既有連線、不再接受新連線，避免中斷進行中的請求，對優雅縮容或滾動部署很重要。
14 / 24
要定義 ASG 啟動 EC2 的規格（AMI、機型、SG、User Data 等），AWS 目前建議使用哪個、且支援版本控制與最新功能？
A Launch Configuration（舊版設定）
B Launch Template（啟動範本）
C 在 ASG 中硬編規格參數設定
D 改用 Placement Group 群組設定
解析
Launch Template 是目前建議做法，支援版本控制、混合執行個體類型、Spot + On-Demand 混用等新功能；Launch Configuration 是舊版、功能受限且不再獲得新特性。
15 / 24
要讓 Web 層在單一 AZ 故障時仍維持服務，ASG 應如何設定？
A 全數放在同一個 AZ 內
B 橫跨多個 AZ 子網路部署
C 只開一台超大規格機器
D 關閉健康檢查以免誤判
解析
讓 ASG 橫跨多個 AZ 的子網路，執行個體會分散到不同 AZ；當一個 AZ 故障，其他 AZ 的執行個體仍能服務，ASG 也會在健康 AZ 補足容量。集中單一 AZ 或單機都是單點故障。
16 / 24
想根據負載嚴重程度做不同幅度的擴展——CPU 到 70% 加 1 台、到 90% 一次加 4 台。應用哪種策略？
A 採用 Target Tracking 策略
B 採用 Step Scaling（階梯式）
C 採用 Scheduled Scaling 排程
D 採用 Manual Scaling 手動
解析
Step Scaling 依 CloudWatch 告警的不同門檻套用不同幅度的調整（越嚴重加越多），適合需要分級反應的情境。Target Tracking 只鎖定單一目標值自動調整；Scheduled 依時間；Manual 純手動。
17 / 24
後端應用需要看到「用戶端真實來源 IP」做記錄與白名單控制。哪種負載平衡器天生在第 4 層保留來源 IP？
A ALB（應用負載平衡器）
B NLB（網路負載平衡器）
C GWLB（閘道負載平衡器）
D Classic LB（傳統型）
解析
NLB 運作在第 4 層並保留用戶端來源 IP，後端可直接看到真實 client IP。ALB（L7）預設把來源 IP 放在 X-Forwarded-For 標頭而非封包來源。要 L4 直通 + 真實來源 IP 選 NLB。
18 / 24
一個 ASG 中有一台正在處理長時間任務的執行個體，不希望它在縮容時被選中終止。應？
A 啟用該實例 Scale-in 保護
B 直接關閉整個 ASG 群組
C 調高 CPU 擴展觸發門檻
D 整組改用 NLB 取代 ALB
解析
Instance Scale-in Protection 可保護特定執行個體在縮容事件中不被終止，適合正在處理不可中斷工作的機器。關閉 ASG 會失去自動擴展能力；其他選項與此無關。
19 / 24
想在 ASG 啟動新執行個體「進入服務前」先完成自訂初始化，或在終止「前」先把日誌上傳保存。應使用？
A 設定 Lifecycle Hooks 掛鉤
B 啟用 ALB Sticky Sessions
C 開啟 Cross-Zone Load Balancing
D 調整 Cooldown Period 冷卻期
解析
Lifecycle Hooks 讓執行個體在「啟動中」或「終止中」暫停於等待狀態，讓你執行自訂動作（安裝、註冊、抽離流量、備份日誌）後再繼續，適合需要優雅上線/下線的流程。
20 / 24
同一個 ALB 想依「網域名稱」分流：api.example.com 導到 API 目標群組、shop.example.com 導到商店目標群組。應使用？
A 設定 Host-based Routing 路由規則
B 整組改用 NLB 取代 ALB 部署
C 改用 Placement Group 群組設定
D 開啟 Cross-Zone Load Balancing
解析
ALB 支援 host-based routing——在 listener 規則中依 Host 標頭（網域名稱）把請求導到不同目標群組，一個 ALB 即可服務多個網域/服務。NLB 是 L4 不看主機名。
21 / 24
新版本上線前，團隊想先把同一路徑 10% 的流量導到 v2、其餘 90% 留在 v1，觀察沒問題再逐步調高。用 ALB 最直接的做法是？
A 設定加權目標群組
B 改用 NLB 以 IP 分流
C 設定 Sticky Sessions
D 開兩個 ALB 各自對外服務
解析
ALB 的加權目標群組（Weighted Target Groups）可以在同一條 listener 規則裡，把流量依比例分給多個 Target Group（例如 v1 90%、v2 10%），常用於金絲雀與藍綠部署。兩個 ALB 需要再靠 DNS 分流；NLB 看不懂 HTTP 路徑；Sticky Sessions 是讓同一使用者固定到同一台，不是比例分流。
22 / 24
公司正在遷移上雲，希望同一個 ALB 後面同時掛 AWS 上的 EC2 與機房裡的舊伺服器（已透過 Direct Connect 相連）。Target Group 應選哪種目標類型？
A EC2 執行個體（instance）
B IP 位址（ip）
C 另一個 ALB
D Lambda 函數
解析
目標類型選 IP 位址時，可以指向任何可路由到的 IP，包含透過 VPN／Direct Connect 相連的 On-Premises 伺服器。instance 類型只能指向 VPC 內的 EC2；Lambda 與 ALB 目標都不能代表機房裡的實體伺服器。
23 / 24
ASG 每次擴展時，新 EC2 都要花 10 分鐘在 User Data 裡安裝套件才能開始服務，常常流量高峰都過了才就緒。最有效的改善方式是？
A 把 Maximum 調到更大
B 縮短 Cooldown Period
C 預先製作 Golden AMI
D 改用 Manual Scaling
解析
Golden AMI 是把套件與設定預先安裝好的映像檔，新實例開機後幾乎馬上就能服務，大幅縮短啟動時間（也因此可以縮短冷卻期）。調高 Maximum 不會讓單台更快就緒；只縮短冷卻期而不縮短啟動時間，只會讓 ASG 在新機還沒上線前又重複擴展。
24 / 24
企業客戶的防火牆只允許連到固定 IP，但服務本身需要依 URL 路徑分流到不同後端。在不自建 Proxy 的前提下，哪種架構同時滿足兩者？
A ALB 直接綁定 Elastic IP
B NLB 直接依路徑分流
C GWLB 搭配防火牆設備
D NLB 後面接 ALB 作目標
解析
ALB 沒有靜態 IP（只有 DNS 名稱），NLB 有靜態 IP 但看不懂 URL 路徑。NLB 的目標類型支援 ALB，所以把 ALB 掛在 NLB 後面：客戶連 NLB 的固定 IP，再由 ALB 做路徑路由。GWLB 是串接安全設備用的，不做應用層路由。

點擊卡片翻面查看答案，共 5 張。

QUESTION
ALB vs NLB 選擇關鍵差異？
點擊翻面
ANSWER
ALB → Layer 7，看 HTTP 路徑/Host，適合微服務
NLB → Layer 4，TCP/UDP，支援靜態 IP，超低延遲
點擊翻回
QUESTION
NLB 最大的兩個獨有特性？
點擊翻面
ANSWER
① 支援靜態 IP（可綁定 EIP）
② 支援 UDP 協定
（ALB 兩者都不支援）
點擊翻回
QUESTION
GWLB 的用途是什麼？
點擊翻面
ANSWER
串接第三方虛擬網路設備（防火牆/IDS/IPS）。流量先透過 GWLB 導向安全設備檢測，再轉回目標。使用 GENEVE 協定。
點擊翻回
QUESTION
ASG Target Tracking 的概念？
點擊翻面
ANSWER
設定一個目標指標（如 CPU 60%），ASG 自動計算要增減多少台來維持該目標，最推薦的擴展策略。
點擊翻回
QUESTION
ASG Cooldown Period 的作用？
點擊翻面
ANSWER
擴展動作後的緩衝期（預設 300 秒），讓 ASG 暫停評估，避免新實例還沒穩定就又觸發下一次擴展。
點擊翻回