EC2、Auto Scaling 與 Application Load Balancer：壞一台、湧一波都撐得住

💡 先搞懂問題

虛構公司「晴空食品」的線上訂便當網站，一開始只跑在一台 EC2 執行個體（instance）上。平常沒問題，但每天中午十一點半到一點，訂單一湧進來，CPU 就衝到滿、網頁轉圈圈；有一天應用程式卡死，主控台上的 EC2 狀態檢查卻還是綠色的兩個勾，直到客人打電話來才發現；另一次是所在的可用區域（Availability Zone，AZ）出狀況，整個網站停擺。工程師想加開機器，又怕下午沒人時白白付錢。

AWS 對這三個問題的標準解法是一組三件套。啟動範本（launch template）把「要開什麼樣的機器」寫下來：用哪個 AMI（Amazon Machine Image，開機映像）、什麼執行個體類型、套哪些安全群組、開機時跑什麼使用者資料（user data）。EC2 Auto Scaling 依照啟動範本管理一個 Auto Scaling 群組（Auto Scaling group，ASG）：你設定最小、所需（desired）與最大容量，它把執行個體分散到多個 AZ，壞掉的換新，負載高時依調整政策（scaling policy）加開、負載低時減少。Application Load Balancer（ALB）站在最前面，用一個 DNS 名稱接住所有請求，再分給目標群組（target group）裡健康的執行個體；它會定時對每台做健康檢查（health check），沒回應的就不再轉送。

新手最常卡在三個地方。第一，以為開了 Auto Scaling 就有高可用，結果群組只放在一個 AZ，AZ 一出事照樣全停。第二，以為 Auto Scaling 會發現「應用程式卡死」，其實它預設只看 EC2 狀態檢查，只能發現機器或作業系統層級的故障；要連應用程式一起看，群組的健康檢查要加上 ELB 健康檢查。第三，以為加開的機器馬上能接客，其實新執行個體要開機、安裝、暖機，所以有暖機時間（instance warmup）與健康檢查寬限期（health check grace period）這些設定。

生活比喻：連鎖便當店的帶位員與區經理

晴空食品後來把一家店擴成連鎖：大安、信義、松山三家分店分散在不同行政區，每家有幾個出餐櫃位。客人不必知道去哪一家，只要到門口找帶位員，帶位員看哪個櫃位有空、店員有沒有回應，就把客人帶過去；某個櫃位的店員叫了沒反應，帶位員就先不往那裡帶人。區經理手上有一份排班規則：任何時候最少開 3 個櫃位、最多 9 個，平常維持 5 個；排隊的人多到某個程度就加開，閒下來就收掉；哪個櫃位壞了，撤掉換一個新的。新櫃位一律照總部的開櫃 SOP 手冊佈置：同樣的裝潢、同樣大小的櫃台、開店前跑同一份準備清單。

這個比喻有四個地方和實際不同。第一，真實的帶位員只有一個人，ALB 則在你啟用的每個 AZ 都有節點，對外只給一個 DNS 名稱，背後的 IP 會變動，所以不要把 IP 寫死，Route 53 用別名記錄指過去即可。第二，新櫃位不是「人站上去就能出餐」：新執行個體要開機、跑使用者資料、通過健康檢查，通常要幾分鐘，所以預先把軟體裝進 AMI、設定合理的暖機時間，都能縮短這段空窗。第三，「撤掉壞櫃位」在 AWS 是終止（terminate）執行個體再開一台新的，不是修好舊的，執行個體本機上的資料會跟著消失，所以應用程式要設計成無狀態，工作階段放在 ElastiCache 或 DynamoDB、檔案放在 S3 或 EFS。第四，區經理只管台數，不管要開在哪一區的哪個街口：Auto Scaling 會盡量讓各 AZ 的台數平均，某個 AZ 出事時，自動改在其他 AZ 補足。

🎮 互動實驗室一：故障與健康檢查模擬器

先選部署方式、要不要放 ALB，以及 Auto Scaling 群組的健康檢查類型，再按上方紅色按鈕觸發一種故障。畫面會一個階段一個階段播放：ALB 什麼時候停止轉送、Auto Scaling 有沒有發現並換掉不健康的執行個體、服務還活不活著。Auto Scaling 群組的所需容量固定為 3 台，會盡量平均分散到選定的 AZ；時間點是用 ALB 預設健康檢查設定估算的示意值。

🎮 互動實驗室二：調整政策模擬器

晴空食品從 10:00 到 13:50 的負載（以「需要幾台跑滿 100% 的執行個體」表示，示意數字），每 10 分鐘一格。選一種調整政策，調整最小、最大、初始所需容量與暖機時間，按「播放」逐格看執行個體數與平均 CPU 怎麼變化。這是為了看懂概念的簡化模型，不是 AWS 實際的演算法：平均 CPU ＝ 負載 ÷ 已上線台數；新執行個體在暖機期間不分擔負載、也不算進平均；目標追蹤在 CPU 高於目標時立刻依比例加開，低於目標 8 成連續 3 格才縮減；步進調整在高於目標 10、30 個百分點時加 1、加 2 台，低於目標 20 個百分點時減 1 台；排程調整在 10:40～12:40 把所需容量設為尖峰值。

🛠️ 操作教學：建立啟動範本、ALB 與 Auto Scaling 群組

跟著 8 個步驟，在左邊的示意主控台替晴空食品建立啟動範本，再建立 Auto Scaling 群組：選 VPC 與多個 AZ 的子網路、連接到新的 ALB 與目標群組、開啟 ELB 健康檢查、設定容量與目標追蹤政策。VPC 與子網路沿用 VPC 教學頁建立的那一套。你填的名稱、執行個體類型、子網路與容量會即時反映到右邊的 AWS CLI 與 CloudFormation；目前步驟對應的那幾行以黃色底標示。填錯時畫面會說明原因，修正後才能進到下一步。

自己動手時要注意

權限：執行的 IAM 身分要能建立啟動範本、負載平衡器與 Auto Scaling 群組，例如 ec2:CreateLaunchTemplate、ec2:RunInstances、elasticloadbalancing:CreateLoadBalancer、elasticloadbalancing:CreateTargetGroup、elasticloadbalancing:CreateListener、autoscaling:CreateAutoScalingGroup、autoscaling:PutScalingPolicy；啟動範本若指定了 IAM 執行個體設定檔，還需要 iam:PassRole。Auto Scaling 會用服務連結角色 AWSServiceRoleForAutoScaling 代你啟動與終止執行個體，第一次使用時自動建立。

費用：Auto Scaling 本身不另收費，費用來自它開出的執行個體、EBS 磁碟、ALB（依小時加上容量單位計費）與公有 IPv4 位址，以及私有子網路連出去時的 NAT 閘道。最大容量就是你願意付費的上限，練習時把它設小。2025-07-15 以後建立的帳戶採抵用金制的 Free Tier，練習費用會先從抵用金扣；選擇免費方案（Free account plan）的帳戶，抵用金用完或滿 6 個月就會關閉（查證日期 2026-10-07）。

收尾：先刪 Auto Scaling 群組（加 --force-delete 會一併終止群組裡的執行個體），再刪負載平衡器與目標群組，最後刪啟動範本；如果直接終止執行個體而不刪群組，Auto Scaling 會馬上再開新的補回所需容量。用 CloudFormation 建立的，刪除堆疊就會依相依順序刪除它建立的所有資源。

# 方法一：CloudFormation 建立的，刪除堆疊即可（無法復原，確認名稱再執行）
aws cloudformation delete-stack --stack-name qingkong-web

# 方法二：CLI 建立的，依序刪除（ARN 中的 111122223333 等請換成自己的值）
aws autoscaling delete-auto-scaling-group --auto-scaling-group-name qingkong-web-asg --force-delete
aws elbv2 delete-load-balancer --load-balancer-arn arn:aws:elasticloadbalancing:ap-northeast-1:111122223333:loadbalancer/app/qingkong-web-alb/0123456789abcdef
aws elbv2 delete-target-group --target-group-arn arn:aws:elasticloadbalancing:ap-northeast-1:111122223333:targetgroup/qingkong-web-tg/0123456789abcdef
aws ec2 delete-launch-template --launch-template-name qingkong-web-lt

範例裡沒有任何存取金鑰、密碼或真實的帳戶 ID，111122223333 是 AWS 文件慣用的佔位帳戶。用 CLI 前先以 aws configure sso（IAM Identity Center）或 aws configure 設定好身分，再用 aws sts get-caller-identity 確認目前是哪個帳戶。啟動範本裡也不需要放任何金鑰：執行個體要存取其他 AWS 服務時，用 IAM 執行個體設定檔取得暫時憑證。

📘 原理補完

啟動範本：把「要開什麼樣的機器」寫下來

EC2 是 IaaS：AWS 負責實體主機與虛擬化層（Nitro System），作業系統修補、應用程式與安全群組設定是你的責任。啟動範本記錄開一台執行個體需要的參數：AMI、執行個體類型、金鑰對、網路介面與安全群組、IAM 執行個體設定檔、儲存、執行個體中繼資料選項與使用者資料。啟動範本有版本，Auto Scaling 群組可以指定「預設版本」「最新版本（$Latest）」或固定某一版，改 AMI 時新增一版，再用執行個體重新整理（instance refresh）逐批換新。舊的啟動組態（launch configuration）功能較少，官方建議改用啟動範本。

AMI 不要寫死某個 ID：AMI 屬於單一區域，而且會定期發布修補過的新版。AWS 把各作業系統最新的 AMI ID 放在 Systems Manager 的公用參數，例如 Amazon Linux 2023 的 /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64（Arm 版把結尾換成 arm64）。啟動範本的 ImageId 可以直接寫 resolve:ssm: 加參數名稱，CloudFormation 則常用 AWS::SSM::Parameter::Value<AWS::EC2::Image::Id> 型別的參數，或 {{resolve:ssm:…}} 動態參考。要注意架構一致：Graviton 的 t4g、m7g 等類型只能搭 arm64 的 AMI，t3、c7i 等 x86 類型只能搭 x86_64 的 AMI，操作教學會檢查這一點。使用者資料（user data）在第一次開機時執行，原始大小上限 16 KB；要讓新機器更快上線，可以把軟體預先裝進自訂 AMI，使用者資料只做最後的設定。

Auto Scaling 群組：最小、所需、最大，加上跨 AZ

Auto Scaling 群組最核心的是三個數字：最小容量是任何時候都不低於的台數，最大容量是費用的上限，所需容量是現在要維持的台數，必須介於兩者之間。調整政策、排程動作或你手動修改，改的都是所需容量；群組再負責把實際台數拉到所需容量。群組綁定 VPC 裡的多個子網路，每個子網路屬於一個 AZ，Auto Scaling 會盡量讓各 AZ 的台數平均；某個 AZ 無法使用時，它改在其他 AZ 啟動執行個體補足所需容量，那個 AZ 恢復後再逐步重新平衡。

群組會定期檢查每台執行個體的健康狀態，判定不健康的就終止並啟動新的一台，這就是「自我修復」。其他常用功能包括：混合執行個體政策（混用多種類型與 On-Demand、Spot）、生命週期勾點（lifecycle hook，開機或終止前先做事）、暖池（warm pool，預先準備好已初始化的執行個體），以及預設暖機時間（default instance warmup），讓新執行個體在暖機期間不被算進彙整指標。

Application Load Balancer：接聽程式、目標群組與健康檢查

ALB 在第 7 層運作。接聽程式在某個通訊協定與連接埠（例如 HTTPS 443）等待連線，依規則（路徑、主機名稱、標頭等）決定轉給哪個目標群組；目標群組裡是一組目標（執行個體、IP 或 Lambda 函式），每個目標群組有自己的健康檢查設定。建立 ALB 時至少要選兩個 AZ 的子網路，對外的 ALB 要放在公有子網路，執行個體則可以放在私有子網路，只讓 ALB 的安全群組連進來。ALB 預設開啟跨區域負載平衡（cross-zone load balancing），請求會平均分給所有 AZ 裡健康的目標。

健康檢查的預設值（instance 與 ip 類型的目標，2026 年 10 月查證）：每 30 秒檢查一次、逾時 5 秒、連續 2 次失敗判定為不健康、連續 5 次成功判定為健康、成功代碼 200、路徑 /。不健康的目標會被移出輪替；如果一個目標群組裡的目標全部不健康，ALB 會「失效開放」（fail open），把請求送給所有目標，避免完全不轉送。實務上建議另外寫一個輕量的 /health 路徑，檢查應用程式真正能服務，而不只是網頁伺服器有開。

兩種健康檢查：看「燈有沒有亮」還是看「有沒有回應」

Auto Scaling 群組預設只用 EC2 狀態檢查：執行個體不在 running 狀態，或系統狀態檢查（AWS 端的主機、電力、網路）、執行個體狀態檢查（作業系統、網路設定）失敗時，才判定不健康。應用程式卡死、記憶體洩漏讓網頁一直逾時、網頁伺服器程序掛了，這些情況作業系統還活著，EC2 狀態檢查照樣通過。把群組的健康檢查類型加上 ELB 之後，只要目標在 ALB 的目標群組裡被判定不健康，Auto Scaling 也會判定它不健康並替換。群組放在負載平衡器後面時，官方建議開啟 ELB 健康檢查。

開啟 ELB 健康檢查時一定要搭配健康檢查寬限期：新執行個體開機、跑使用者資料需要時間，寬限期內 Auto Scaling 不會因為 ELB 檢查失敗就終止它（EC2 狀態檢查則不受寬限期影響）。用主控台建立群組時寬限期預設 300 秒，用 CLI 或 SDK 建立時預設是 0 秒，也就是關閉寬限期，所以操作教學的 CLI 會明確寫 --health-check-grace-period 300。寬限期設得太短，新機器還沒準備好就被判不健康，會陷入「開了又砍、砍了又開」的循環。

調整政策：目標追蹤、步進、排程與預測

目標追蹤像恆溫器：你指定一個指標與目標值（例如平均 CPU 50%），Auto Scaling 自動建立並管理 CloudWatch 警示，依比例加減台數讓指標接近目標；擴展時很積極，縮減時較保守，暖機中的執行個體不算進彙整指標。預先定義的指標有四個：ASGAverageCPUUtilization、ASGAverageNetworkIn、ASGAverageNetworkOut、ALBRequestCountPerTarget。指標要能隨台數等比例變化才適合，例如「每台的請求數」可以，「整個負載平衡器的總請求數」或「延遲」就不適合。官方最推薦先用目標追蹤。

步進調整依 CloudWatch 警示超過門檻的「幅度」分段調整，例如超過 60% 加 1 台、超過 80% 加 2 台，適合需要精細控制的情境；簡單調整一次只做一個調整、中間有冷卻時間，是較舊的做法。排程調整在已知的時間改最小、最大或所需容量，例如每個工作日早上 9 點前加開；預測調整依過去的流量模式預測並提前擴展，適合有明顯週期、而且開機需要較長時間的工作負載。這些方式可以同時使用：排程或預測先把基本台數準備好，目標追蹤再處理臨時的波動。

判斷步驟

1. 先確認要防的是什麼：單台故障、應用程式卡死、單一 AZ 故障，還是流量尖峰。
2. 高可用：Auto Scaling 群組至少選兩個 AZ 的子網路，最小容量至少 2；前面放 ALB，ALB 也要橫跨至少兩個 AZ。
3. 健康檢查：群組放在 ALB 後面時，健康檢查類型加上 ELB，並設定足夠的健康檢查寬限期；目標群組的健康檢查路徑要真的反映應用程式狀態。
4. 擴縮：預設先用目標追蹤；已知時段加排程或預測；設定合理的暖機時間，最大容量就是費用上限。
5. 應用程式要無狀態：工作階段與檔案放到 ElastiCache、DynamoDB、S3 或 EFS，執行個體隨時可以被終止與替換。

容易考錯的地方

Auto Scaling 不等於高可用：群組只放一個 AZ，AZ 故障時沒有地方可以補。題目問「最能提高可用性」時，答案通常是「跨多個 AZ 的 Auto Scaling 群組＋ALB」，而不是「換更大的執行個體」。

應用程式卡死沒被換掉：群組預設只用 EC2 狀態檢查，要把健康檢查類型加上 ELB。干擾選項常寫「開啟 EC2 詳細監控」或「加大執行個體」，都解決不了。

ALB 與 Auto Scaling 的分工：ALB 負責「不轉送給不健康的目標」，Auto Scaling 負責「換掉不健康的執行個體、增減台數」。只有 ALB 沒有 Auto Scaling，壞機器會一直留著；只有 Auto Scaling 沒有 ALB，新機器換了 IP，使用者也連不到。

調整政策的關鍵字：「維持在某個百分比」是目標追蹤；「固定時間」是排程；「依歷史提前」是預測；「依超標幅度分段」是步進。要擴展 ECS、DynamoDB 等非 EC2 資源，則是 Application Auto Scaling。

寬限期與暖機：健康檢查寬限期太短，新機器還沒準備好就被砍；暖機時間太短，彙整指標會被剛開機的機器拉低或拉高，造成過度擴縮。

相關考試：CLF-C02 的雲端技術領域要求認得自動擴展與負載平衡；SAA-C03 的 in-scope 清單列出 Amazon EC2、Amazon EC2 Auto Scaling 與 Elastic Load Balancing，是高可用架構題的常客；SOA-C03 列出 AWS Auto Scaling 與 Elastic Load Balancing；SAP-C02（2026-11-17 起換成 SAP-C03）、DOP-C02 會考更大規模的部署與部署策略。

✅ 自我檢測

以下 6 題都是原創題，選完會立即顯示對錯與解析，全部作答後會出現總分。目前得分：0 / 6