EC2 Auto Scaling、ELB 與 Multi-AZ 高可用

EC2 Auto Scaling 與 Elastic Load Balancing 是所有水平擴展 AWS 工作負載的核心配對，在 SOA-C02 中從運維角度切入測驗——不是「架構師該選 ALB 還是 NLB」，而是「ALB 在流量高峰期回傳 502、ASG 每十分鐘就震盪一次、新 instance 在完成開機前就被砍掉——請修好它」。Domain 2（可靠性與業務連續性）占全卷 16%，Task Statement 2.1 與 2.2 將擴展性與高可用性合併成一條完整的運行堆疊：Auto Scaling group 從 launch template 啟動 instance、向 ELB target group 完成註冊、ELB health check 決定新 instance 是否能服務流量、ASG 決定要增加、終止還是跨 Availability Zone 重新平衡。SOA-C02 會測試這條管線上的每一個接縫。

本指南從 SysOps 角度走過完整堆疊：Auto Scaling group 的配置方式（launch templates、desired/min/max、AZ 分佈、mixed instances）、三種 scaling policy 的行為與 target tracking 背後的計算（target tracking、step、scheduled）、cooldown 與 warm-up 的存在意義與調校方式（讓 ASG 停止震盪）、lifecycle hooks 的優雅開機與排空、ELB target group 內部結構（instance vs IP target type、health check 門檻值）、health check grace period（解釋了大多數「新 instance 因 unhealthy 被砍」故障的根因）、deregistration delay 與 sticky sessions、ALB / NLB / GLB 的運維差異、Multi-AZ rebalancing，以及 Route 53 health check 如何疊加在上層實現跨 region failover。你也會看到反覆出現的 SOA-C02 場景：502 / 504 疑難排解、ASG 震盪診斷、instance refresh 卡在 0% healthy，以及「load balancer 把流量路由到舊的 unhealthy instance」的症狀。

為什麼 Auto Scaling 與 ELB 是 SOA-C02 Domain 2 的核心

官方 SOA-C02 Exam Guide v2.3 在 Task Statement 2.1（擴展性與彈性）下列出五項技能、在 2.2（高可用性與韌性環境）下列出四項技能。Auto Scaling 與 ELB 幾乎出現在每一項：建立並維護 Auto Scaling 計畫、配置 ELB 與 Route 53 health check、區分單 AZ 與 Multi-AZ 部署、以 EFS 與 Elastic IP 實作容錯工作負載，以及套用 Route 53 路由策略（failover、weighted、latency）。SAA-C03 在設計階段問「架構師應選哪種 load balancer」，SOA-C02 卻不斷問「運行中的堆疊出了問題——你要轉動哪個旋鈕？」——而那個旋鈕幾乎都是 health check grace period、deregistration delay、datapoints to alarm、cooldown、warm-up 或 scaling alarm 上的 treatMissingData。

SysOps 的框架是運維而非架構設計：工作負載已經設計並部署完畢，你的任務是運行它。考試鍾愛這些反覆出現的場景——ALB 在流量高峰期回傳 502（target unhealthy → deregistration delay 太短 → 進行中的請求被丟棄）、CPU alarm 每十分鐘震盪一次（period 60 秒且 M=N=1 過於敏感——改成 3-of-5）、instance refresh 卡住（min healthy percentage 太高導致無法推進），以及 sticky sessions 在部署後失效（lb_cookie 以 target group 為範圍旋轉，但應用程式伺服器的 app_cookie 未配置）。EC2 Auto Scaling、ELB 與 Multi-AZ HA 是所有後續運維決策的插槽：CloudWatch alarms 餵入 scaling policies、VPC subnets 讓 ASG 啟動 instance、IAM instance profile 授予 S3 與 Secrets Manager 存取權，以及 AWS Backup 計畫涵蓋 stateful tier 的底層 EBS volumes。

白話文解釋 EC2 Auto Scaling and Elastic Load Balancing

Auto Scaling 與 ELB 的術語密集難懂——三個類比讓這些運作機制變得直觀好記。

類比一：台灣辦桌的總舖師備料系統

Auto Scaling group 是一套辦桌的總舖師備料系統。Launch template 是標準食譜與工作站設置卡——每位新來的廚師到位就知道要站哪個灶口、用哪把刀、穿哪件圍裙（AMI）、配哪頂廚師帽顏色（security group）。Desired/min/max capacity 是總舖師的人力配置計畫：最少三個廚師確保辦桌不開天窗（min），最多十二個以免灶口不夠用（max），平常備料六個就好（desired）。Target tracking 是總舖師的原則「讓每個灶口維持五成的忙碌度」——若所有廚師都在飆九成忙碌，就再叫人來；若廚師閒到發慌只有兩成，就先讓幾位收工。Cooldown period 是叫人來之後觀察十五分鐘再決定是否再補人的窗口——沒有這個窗口，總舖師會每分鐘瘋狂叫人又趕人。Warm-up time 是新廚師花二十分鐘看菜單、找鹽巴的緩衝期，這段時間他的灶口「使用率」不算進總舖師的平均值——他看起來很閒，但其實還在暖機。

Elastic Load Balancer 是桌邊招呼的領班。Target group 是現有灶口清單。Health check 是領班每十秒走過每個灶口確認廚師有在回應（比出讚 = healthy）。Health check grace period 是新廚師的五分鐘豁免期——領班不會對剛到的新廚師馬上打分數，否則每位剛到的廚師還沒開工就被開除了。Deregistration delay 是三百秒的收尾禮遇——輪班結束的廚師，領班停止給他新訂單，但讓他把手上的菜料理完再下班。Sticky sessions 是**「這是您的固定服務生」規則**——熟客認定某位廚師，每次來都被路由到同一位（cookie）。Multi-AZ 是同一場辦桌分設東西兩個廚房——東廚一半廚師、西廚一半廚師；一邊廚房失火，另一邊辦桌照開。

類比二：捷運列車調度系統

Scaling policy 是一套捷運列車調度系統。Target tracking 是現代演算法——「讓所有月台的平均候車時間維持在三十秒以內」，系統觀察負載、自動決定調度哪班車去哪個方向，調度員不需要指定「如果五號月台有五個人在等而一到三號列車都在跑，就把四號車調去」。Step scaling 是舊式分級規則——「等候超過五人，調兩班；超過十人，調四班」。你手動定義每個台階，系統照規則執行。Scheduled scaling 是早高峰模式——每個平日早上八點半，自動把三班列車預先停在大廳月台等候即將湧入的人潮，不需要等 metrics 出現才反應。Cooldown 是列車出發後的閉門等待——一班車調去十二號月台後，系統不在中途把它改調到七號月台。Lifecycle hook 是安全員驗車窗口——列車到站到「開放乘客上車」之間，安全員有機會簽核；只有收到 CompleteLifecycleAction 後，車門才會打開。

類比三：台灣醫院急診室分診台

做 path-based routing 的 ALB 是急診室入口的分診台。路徑 /api/* 分到一個團隊（API target group）、/admin/* 分到另一個（admin target group）、/* 分到普通科。Listener rule priority 是分診問診的優先順序——數字越小越先問。Target group health check 是床位狀態看板——綠燈代表床位備妥，紅燈代表病人剛離開、床位還在清潔。Deregistration delay 是床位清潔的緩衝期——這張床不再接受新病人入住，但現有病人可以把療程做完再離開。NLB instance vs IP target type 是兩種指定床位的方式：instance（分配的床號，由院方管理）vs IP（病人自帶監控設備的 IP，適合病人跨病房移動的場景）。

Auto Scaling Group 組成元件：Launch Templates、Desired/Min/Max、AZ 分佈

Auto Scaling group 是 SysOps 的機群管理單位。三組設定控制其行為。

Launch templates（與舊版 Launch Configurations）

Launch template 捕捉 instance 啟動時所需的一切：AMI ID、instance type（或 mixed instances 的 type 清單）、key pair、security groups、IAM instance profile、user-data 腳本、block device mapping、network interfaces、監控、休眠、metadata options（SOA 推薦僅啟用 IMDSv2）以及標籤。Launch templates 有版本號——每次編輯都會建立新的版本。ASG 引用特定版本（1、2），或特殊指標 $Latest（永遠指向最新版）和 $Default（標記為預設的版本）。

舊版的 Launch Configurations 不可變、無版本，且不支援較新的功能（mixed instances policies、多 network interfaces、部分較新的 instance type）。AWS 官方已於 2023-12-31 之後建立的新 ASG 中正式棄用 launch configurations。SOA-C02 的舊題目可能出現 launch configurations，但任何現代 ASG 的正確答案都是 launch template。

Desired、minimum 與 maximum capacity

三個整數管理 ASG 的數量：

• MinSize — 下限。ASG 的 scale-in 不會低於此數（若 scale-in policy 會使數量低於 min，則自動夾回 min）。
• MaxSize — 上限。ASG 的 scale-out 不會超過此數（若 scale-out policy 會使數量超過 max，則自動夾回 max）。
• DesiredCapacity — ASG 主動維持的目標數量。Scaling policies 在 [min, max] 範圍內調整 desired。

常見的 SysOps 錯誤：MaxSize 設得太低，在最壞情況的需求下 ASG 到達上限，alarm 持續在 ALARM 狀態，客戶收到錯誤。另一個錯誤是 MinSize = MaxSize = DesiredCapacity（固定大小的 ASG），只提供 AZ rebalancing 與 health 失敗時的 instance 替換，但沒有彈性。

AZ 分佈與 Multi-AZ

ASG 配置一或多個 VPC subnets，每個 subnet 在不同的 AZ 中。ASG 預設會將 instance 平均分散到各 AZ——若 desired = 6 且有三個 AZ 的三個 subnets，每個 AZ 各得 2 個 instance。當某個 AZ 受損，ASG 在倖存的 AZ 中啟動替補容量。

針對 HA，SOA 推薦的基線是每個 ASG 至少兩個 AZ（三個最佳）。單 AZ ASG 只適合批次或開發工作負載，且這些場景能接受 AZ 隔離帶來的影響。

Scaling Policy 類型：Target Tracking、Step、Scheduled — 運維選擇

三種 scaling policy 類型，各有明確的適用場景。

Target tracking — 預設且最常用的類型

Target tracking 將單一 metric 維持在目標值，類似恆溫器。你選擇一個 metric（預定義的 ASGAverageCPUUtilization、ASGAverageNetworkIn/Out、ALBRequestCountPerTarget 或自訂 metric）與目標值（例如 50% CPU）。ASG 在背後建立兩個 CloudWatch alarms——一個用於 scale-out（metric > target）、一個用於 scale-in（metric < target）——並調整 desired 讓 metric 維持在目標值。

Target tracking 的計算邏輯：

• Scale-out 快速且積極——alarm 在短暫評估窗口後觸發（通常 3 個資料點），ASG 新增足夠的 instance 將 metric 拉下來。新增數量依比例計算：若目前 desired = 10 且平均 CPU 是 80%（目標 40%），policy 會目標約 20 個 instance。
• Scale-in 緩慢且保守——scale-in alarm 預設需要連續 15 個資料點（15 分鐘）才會觸發，防止在下一分鐘可能還會用到的容量被終止。

使用 target tracking 的時機：

• Metric 有明確的目標值（CPU 維持 50%、每 target 的 request count 維持 1000）。
• 希望 AWS 管理 alarms 與 scaling 計算。
• 工作負載的流量大致上與所選 metric 成正比。

Step scaling — 分層回應

Step scaling 讓你根據 metric 偏離 threshold 的程度定義各個調整「台階」：

• CPU 70–80% → +2 個 instance。
• CPU 80–90% → +4 個 instance。
• CPU >90% → +8 個 instance。
• CPU 30–20% → -1 個 instance。
• CPU <20% → -2 個 instance。

每個台階都綁定一個 CloudWatch alarm。Step scaling 適用於：

• Metric 與所需容量的關係是非線性的。
• 希望明確控制在高負載下機群擴展的積極程度。
• 工作負載可以接受偶爾的過量或不足。

Scheduled scaling — 可預測的流量模式

Scheduled scaling 在指定時間變更 desired、min 或 max。可配置為一次性或循環（cron）排程：

• 每個平日 08:30 UTC：desired = 10（早高峰）。
• 每個平日 19:00 UTC：desired = 4（離峰）。
• 一次性在黑色星期五 00:00：desired = 50。

Scheduled scaling 的使用時機：

• 已知的流量模式（上班時段、行銷活動、批次視窗）。
• 在預測的流量高峰前預熱——在流量到來前先提高 desired，這樣 target tracking 就不必被動反應。
• 非生產環境的成本節省（開發環境在夜間縮減至零）。

Scheduled 與動態（target tracking / step）policies 可共存於同一個 ASG：排程設定基線；target tracking 處理其餘變化。

Predictive scaling

Predictive scaling 是第四種類型——它分析歷史 CloudWatch metric 資料、學習每日或每週模式，並在預測需求到來前預先啟動容量。通常與 target tracking 搭配：predictive 處理基線曲線，target tracking 吸收未預測的變化。SOA-C02 偶爾提及 predictive scaling，但高頻考題仍集中在 target tracking、step 與 scheduled。

Cooldown Period 與 Warm-Up Time：防止震盪

這兩個設定是 ASG 震盪最常被歸咎的原因。

Cooldown — 動作後的觀察視窗（simple scaling）

Cooldown 適用於 simple scaling policies（舊式的單步類型）。在 scale-out 或 scale-in 動作完成後，ASG 等待 cooldown 時長（預設 300 秒），才考慮同類型的另一個 scaling 動作。目的是給新 instance 時間上線並影響 metric，再讓 policy 再次反應。

Cooldown 不適用於 target tracking 或 step scaling——這兩者使用的是 instance warm-up。

Instance warm-up — Metric 聚合的緩衝期

Instance warm-up（也稱為 EstimatedInstanceWarmup）是剛啟動的 instance 的 metrics 被排除在 ASG 聚合統計之外的時長。原因：CPU 為 0% 的全新 instance 會拉低平均值，讓 target tracking 誤以為機群過度配置，進而過早 scale-in。

典型的 web tier 需要 60–180 秒的 warm-up；bootstrap 較重（configuration management、container pull、JVM warmup、cache 預熱）的 instance 可能需要 300–600 秒。正確的 warm-up 時長應與 instance 達到正常負載所需的實際時間相符。

DefaultInstanceWarmup（ASG 層級）

現代 ASG 支援 DefaultInstanceWarmup 作為 ASG 層級的設定，適用於每個動態 scaling policy、每個 health check grace period 預設值，以及每次 instance refresh——只需設定一個地方，而不必在每個 policy 上重複設定。SOA-C02 期望你知道這個統一設定的存在，並優先在 ASG 上設定 DefaultInstanceWarmup，而非各 policy 分別設定。

AZ Rebalancing：ASG 如何因應不均勻的 AZ 分佈

當 ASG 的 instance 在 AZ 之間分佈不均時——例如某個 AZ 發生障礙，ASG 在倖存的 AZ 啟動替補容量，之後障礙 AZ 恢復——ASG 會觸發 AZ rebalancing：在不足的 AZ 啟動新 instance，並終止過多的 AZ 的 instance，以恢復均勻分佈。

Rebalancing 遵循先 scale-out、再 scale-in 的模式：ASG 先啟動（暫時超過 desired），等待新 instance 進入服務狀態，再終止舊 instance——全程維持容量。同樣的 instance warm-up 規則適用。

幾點運維注意事項：

• AZ rebalancing 可能在意料之外觸發：當 ASG 重新配置以新增 subnet/AZ 時，ASG 發現不足的 AZ 並執行 rebalancing，替換 instance。擴展到新 AZ 時請事先規劃。
• Termination policies（default、oldest、newest、oldest launch configuration、oldest launch template、allocation strategy）決定在 rebalancing 或 scale-in 時終止哪個 instance。預設是優先終止使用最舊 launch template 的 instance 並重新平衡 AZ。
• 暫停的 processes：SysOps 工程師可以暫停 AZRebalance、Launch、Terminate、HealthCheck、ReplaceUnhealthy、AlarmNotification、ScheduledActions 或 AddToLoadBalancer 來調查或暫停活動。暫停 AZRebalance 是在單 AZ 環境測試時常見的除錯手法。

Lifecycle Hooks：自訂開機與排空邏輯的暫停點

Lifecycle hook 讓 ASG 的啟動與終止動作變成可暫停的事件，等待外部的 CompleteLifecycleAction API 呼叫後才繼續執行。

兩種 hook 類型

• autoscaling:EC2_INSTANCE_LAUNCHING — 在新 instance 到達 Pending:Wait 狀態時觸發。ASG 將 instance 保留在該狀態，直到你呼叫 CompleteLifecycleAction（或逾時）。用於 bootstrap 設定、掛載 EFS volume、向第三方 config store 註冊、預熱快取，或在 instance 進入服務前執行整合測試。
• autoscaling:EC2_INSTANCE_TERMINATING — 在 instance 被選定終止時觸發，保留在 Terminating:Wait 狀態。用於排空佇列、刷新日誌、從外部服務登錄檔取消註冊、快照暫存狀態，或在 EC2 終止前將最終日誌上傳到 S3。

Hook 配置

每個 hook 包含：

• HeartbeatTimeout — ASG 逾時前等待的時長（預設 3600 秒，最大 7200 秒）。逾時後執行 DefaultResult 動作。
• DefaultResult — CONTINUE（繼續啟動或終止）或 ABANDON（終止 instance 並回滾）。
• NotificationTargetARN + RoleARN — 通常是 SNS topic 或 SQS queue，供 bootstrap/排空流程消費；或由 EventBridge 直接消費 EC2 Instance-launch Lifecycle Action 事件。

常見運維模式

• Configuration management bootstrap：launch hook → SNS → Lambda → 執行 Ansible/Chef → CompleteLifecycleAction CONTINUE。
• 優雅排空：terminate hook → EventBridge → SSM Automation document → 排空佇列 → 刷新日誌 → CompleteLifecycleAction CONTINUE。
• Container 排空：terminate hook → ECS-style task draining → Lambda 等待任務完成 → CompleteLifecycleAction。
• 終止前快照：terminate hook → SSM Run Command → aws ec2 create-snapshot → 上傳 manifest 到 S3 → CompleteLifecycleAction。

Health Checks：ASG vs ELB — ASG 使用哪個

兩套不同的 health-check 系統並行運作。混淆這兩者是 SOA-C02 最常見的錯誤。

EC2 status checks（ASG 的預設）

每個 EC2 instance 都有 AWS 發布的兩項 status checks：

• StatusCheckFailed_System — AWS 基礎設施故障（主機、網路、AZ）。EC2 Auto Recovery 可自動處理其中許多情況。
• StatusCheckFailed_Instance — instance OS 無法存取（kernel panic、網路配置錯誤、磁碟已滿）。

預設情況下，ASG 只使用 EC2 status checks 來判斷 instance 是否健康。若兩項都通過，instance 被視為健康，無論是否能服務應用程式流量。

ELB target group health checks

ELB target groups 對已註冊的 targets 執行自己的 health checks——通常是對 /healthz 或 /health 發送 HTTP/HTTPS 探針，預期回傳 200，或對某個連接埠進行 TCP 探針。這是更豐富、更感知應用程式的訊號：/healthz 回傳 200 的 target 確認可以存取且應用程式正在回應。

將 ELB health 接入 ASG

只有在 ASG 層級明確啟用 ELB health checks，ASG 才會對 ELB health 做出反應。設定（HealthCheckType）有三種模式：

• EC2（預設）— 只有 EC2 status checks 計入。
• ELB — EC2 status checks 與 ELB target group health checks 均計入。任一失敗的 instance 都會被替換。
• VPC_LATTICE — 用於 VPC Lattice service network targets（較新的範疇，大多數 SOA-C02 題目不涵蓋）。

Health Check Grace Period（SOA 的陷阱）

當全新的 instance 啟動時，ELB 幾乎立即開始對其執行 health checks。若 instance 尚未完成開機（Apache 尚未啟動、Java 尚未暖機），health checks 失敗，ASG 將 instance 標記為 unhealthy 並終止它——只為啟動另一個面臨相同命運的 instance。這就是**「新 instance 在服務流量前不斷被砍」**的症狀。

修復方式是設定 health check grace period：在此時間（秒）內，ELB health-check 失敗不計入 instance 的判定。對於啟用 ELB health checks 的 ASG，預設是 300 秒，但多個 console 路徑與 CLI 預設會產生 0。grace period 太短會砍掉正在開機的 instance；太長則延遲偵測到真正損壞的 instance。

Connection Draining 與 Deregistration Delay：優雅終止

當 ASG 決定終止一個 instance——無論是 scale-in、instance refresh 還是 health 失敗——ELB 必須停止向該 target 發送新連線，同時讓進行中的連線完成。

ALB / NLB 上的 Deregistration delay（connection draining）

當 target 被取消註冊（或移至 draining 狀態），ELB：

1. 停止向它發送新連線。
2. 允許現有連線在 deregistration delay 結束前完成（預設 300 秒，最大 3600 秒）。
3. 延遲到期後，強制關閉所有剩餘連線。

太短的延遲會丟棄進行中的請求——在應用程式日誌與 ELB access logs 中顯示為 502 / 503 尖峰。太長的延遲會拖慢 scale-in（ASG 必須等待所有 draining instance 才能終止它們）。

正確的值取決於工作負載：

• 請求時間短的無狀態 web tier：30–60 秒就夠了。
• 長輪詢或大型檔案上傳的 API：300–900 秒。
• WebSocket 或持久連線：600–1800 秒（或先在應用程式層終止 WebSocket）。

ASG draining vs ELB draining

當 ASG 終止附加到 ELB target group 的 instance：

1. ASG 對 target group 呼叫 DeregisterTargets。
2. Target 在 ELB 進入 draining 狀態。
3. ASG 等待 deregistration delay 結束，才實際終止 EC2 instance。
4. Instance 被終止。

若同時也為 EC2_INSTANCE_TERMINATING 配置了 lifecycle hook，ASG 會同時執行兩者：從 ELB 取消註冊並觸發 lifecycle hook，等待兩者都完成。

ALB vs NLB vs GLB：SysOps 的運維差異

現代 ELB 家族的三種類型。SOA-C02 聚焦在 ALB 與 NLB；GLB 偶爾出現。

Application Load Balancer (ALB) — Layer 7

• HTTP / HTTPS / gRPC / WebSocket 路由。
• Path-based（/api/* → group A，/admin/* → group B）、host-based（api.example.com vs web.example.com）、HTTP header 和 query string 路由。
• Listener rules 含優先順序——先匹配優先；優先順序數字越小、優先權越高。
• Target types：instance（EC2 by ID）、ip（任何 IP，包含透過 VPN/DC 的地端）、lambda（對 HTTP 呼叫 Lambda）、alb（串接另一個 ALB）。
• Sticky sessions：ALB 管理的 lb_cookie（時長可配置），或應用程式管理的 app_cookie（應用程式設定 cookie；ALB 固定對應的 target）。
• WAF 整合：在 Layer 7 層級。
• 有 security groups——操作者控制入站流量。
• 使用 ALB 的時機：HTTP 流量、微服務路由、WAF 保護、header/path-based 路由。

Network Load Balancer (NLB) — Layer 4

• TCP / UDP / TLS 直通。
• 每個 AZ 一個靜態 IP（每個 AZ 一個 Elastic IP），支援 PrivateLink 作為服務端點。
• 極高性能——每秒數百萬個請求、超低延遲。
• Target types：instance、ip（必須是 VPC 可路由的）、alb（少見；NLB 在 ALB 前的模式）。
• Target type 為 instance 時保留來源 IP（ip target type 透過 Proxy Protocol v2）。
• 歷史上 NLB 本身沒有 security group——security groups 只附加到 targets。較新的 NLB 功能新增了可選的 NLB 層級 security groups；SOA-C02 仍測試歷史預設「NLB 沒有 security group」。
• Cross-zone load balancing 預設停用（啟用後需支付跨 AZ 資料傳輸費，但分佈更均勻）。ALB 預設啟用 cross-zone。
• 使用 NLB 的時機：TCP/UDP 非 HTTP、靜態 IP 需求、超高吞吐量、來源 IP 保留、PrivateLink 端點。

Gateway Load Balancer (GLB) — Layer 3 流量檢查

• 將 IP 流量分發到第三方虛擬設備機群（防火牆、IDS/IPS、深層封包檢查）。
• 使用 GENEVE 協定，連接埠 6081。
• 運維場景較為特殊——偶爾出現在 SOA-C02 關於部署 Marketplace 防火牆機群的場景中。

Target group 細節

• 同一個 target group 可以是多個 ALB listener rules 的目的地。
• Health check protocol/path/port 在每個 target group 上配置，而非每個 ALB。
• Slow start mode（僅限 ALB）：新註冊的 targets 在可配置的時長（最大 900 秒）內線性接收越來越多的流量，防止冷快取的雷鳴群效應。預設停用。

Sticky Sessions：lb_cookie vs app_cookie

當工作負載需要同一個客戶端跨請求持續連到同一個 target（instance 記憶體中的舊式 session 狀態、黏性購物車、WebSocket 式親和性），在 ALB target group 上啟用 sticky sessions。

兩種 sticky 模式

• lb_cookie（ALB 管理） — ALB 設定並輪換名為 AWSALB 的 cookie。時長可配置（預設 1 天，最大 7 天）。客戶端攜帶 cookie 回來時，ALB 將其路由到同一個 target。以 target group 為單位的 cookie——不同 target groups 各自維護獨立的 stickiness。
• app_cookie（應用程式管理） — 應用程式設定自己的 session cookie（JSESSIONID、PHPSESSID、自訂名稱）。ALB 觀察 cookie 值，將客戶端固定到上次設定該 cookie 值的 target。應用程式控制 cookie 名稱、domain、path 與存活時間。

運維影響

• lb_cookie 較簡單：在 target group 上啟用，ALB 完成其餘工作。適合任何尚未設定自己 session cookie 的應用程式。
• app_cookie 是應用程式已有 session 管理時的首選——避免兩個 cookie 的混亂，並讓應用程式邏輯控制 session 存活時間。
• Sticky sessions 中斷的情況：cookie 固定的 target 被終止、取消註冊或 health check 失敗。下一個請求重新平衡到新 target——舊 target 上的 session 狀態遺失（除非應用程式將狀態持久化到外部）。

配置參數

在 target group 上：

• Stickiness type — lb_cookie 或 app_cookie。
• Stickiness duration — 對於 lb_cookie，cookie 的有效時長。
• App cookie name — 對於 app_cookie，要觀察的應用程式 cookie 名稱。

Mixed Instances Policy 與 Spot 整合

現代 ASG 支援 mixed instances policy——同一個群組中有多種 instance types，on-demand 與 Spot 分別採用不同的購買選項。對於成本最佳化與韌性來說相當重要。

Policy 元件

• Launch template 加 overrides — 指定多種 instance types（m5.large、m5a.large、m4.large、m5n.large），讓 ASG 在某種類型不可用時可以替換。
• OnDemandPercentageAboveBaseCapacity — 超過 on-demand base 的額外容量中，on-demand 的百分比。其餘為 Spot。
• OnDemandBaseCapacity — 最底層始終為 on-demand 的 instance 絕對數量（通常是你的穩定基線）。
• SpotAllocationStrategy — price-capacity-optimized（首選預設）在最低價格下選擇最穩定的 Spot 容量；lowest-price 優先選最便宜的；capacity-optimized 優先選最深的資源池。
• SpotMaxPrice — ASG 願意為 Spot 支付的可選上限價格。

運維模式

• 穩定基線 + 爆發式 Spot：OnDemandBaseCapacity = 4、OnDemandPercentageAboveBaseCapacity = 0，所有額外容量為 Spot。相比純 on-demand 節省 60–90%。
• 韌性混合：OnDemandPercentageAboveBaseCapacity = 50——基線之上各半 on-demand 與 Spot。以降低節省換取 Spot 中斷的韌性。
• Spot 中斷處理：ASG 透過 instance metadata 收到 2 分鐘的中斷通知；在 EC2_INSTANCE_TERMINATING 上配置 lifecycle hook 以執行排空。Spot Capacity Rebalancing（較新功能）在顯示較高中斷風險的 Spot instance 前主動替換它們。

Instance Refresh：AMI / Launch Template 更新的滾動替換

當 launch template 變更（新 AMI 版本、新 instance type、更新的 user-data）時，ASG 不會自動替換現有 instance——它們繼續執行舊 launch template。Instance refresh 是將機群升級到新 launch template 版本的受控滾動替換。

Instance refresh 的運作方式

你使用 StartInstanceRefresh 啟動替換，並指定：

• MinHealthyPercentage — 替換過程中健康容量的下限（預設 90%，範圍 0–100）。較低的值讓替換更快推進，但以更多容量降低為代價。
• InstanceWarmup — 替換 instance 被視為「in service」以計算健康百分比之前等待的時長（預設繼承自 ASG）。
• CheckpointPercentages + CheckpointDelay — 暫停點，讓團隊在繼續前進行驗證。
• Strategy — Rolling（預設）或 Launch before terminating（較新；先啟動替換再終止）。

替換流程：

1. 選取一批 instance（大小以確保機群維持在 MinHealthyPercentage 以上）。
2. 使用新 launch template 啟動替換 instance。
3. 等待 InstanceWarmup 並確認健康狀態。
4. 終止舊 instance。
5. 重複直到每個 instance 都使用新 launch template。

常見運維問題

• Refresh 卡在 0% complete：MinHealthyPercentage 太高——ASG 無法終止任何 instance 而不跌破門檻值，導致永遠無法開始。降低百分比以使替換得以推進。
• Refresh 失敗，顯示「instance 從未到達 InService」：新 AMI 的 bootstrap 比 warm-up 時長慢；替換 instance 逾時。增加 InstanceWarmup 或在 AMI 中預烤更多內容以縮短開機時間。
• Refresh 跳過某些 instance：在 protected scale-in 狀態的 instance 會被跳過——適合保留你希望保留的 canary 節點。

Multi-AZ 部署：跨 AZ 分散 ASG 以實現容錯

ASG 最重要的單一 HA 配置：多個 AZ 中的多個 subnets。SOA-C02 期望考生知道：

• 容錯需要至少兩個 AZ——三個最佳。
• ASG 平均分散到已配置的 subnets/AZs。
• AZ 失敗時，EC2 在故障 AZ 的啟動不會成功——ASG 在倖存的 AZ 啟動替補容量（這可能需要那些 AZ 有足夠的空間）。
• 故障 AZ 恢復後，AZ rebalancing 重新分散回均勻狀態。
• ASG 必須在所有相同的 AZ 中向 ELB target groups 完成註冊，流量才能持續流動。

Cross-zone load balancing — ALB vs NLB

• ALB：Cross-zone load balancing 預設啟用且無法停用。每個 ALB target 無論 AZ 分佈如何，都接收大致相等的流量。
• NLB：Cross-zone load balancing 預設停用——每個 AZ 的 NLB node 只向同一 AZ 的 targets 轉發流量。在 NLB 上啟用 cross-zone 需支付跨 AZ 資料傳輸費，但當 targets 分佈不均時分佈會更均勻。

當 NLB cross-zone 停用且一個 AZ 有 9 個 instance 而另一個 AZ 只有 1 個時，只有 1 個 instance 的 AZ 接收 50% 的流量（因為 50% 的 NLB nodes 在該 AZ），那個 instance 會被壓垮。SOA-C02 測試這種不對稱性：啟用 NLB cross-zone，或讓各 AZ 的 instance 數量相等。

Elastic IP 與 EFS 的有狀態容錯

有些工作負載無法完全實現無狀態——SysOps 工程師需要針對 stateful tier 使用正確的基礎元件。

Elastic IP

Elastic IP 是分配到你帳號的靜態公有 IP。從運維角度看：

• 用於特定 instance 必須始終在已知公有 IP 可達的場景（舊式白名單合作夥伴整合、地端 VPN 端點）。
• Elastic IP 可以在 failover 時移動到替換 instance——由 CloudWatch alarm 或 EventBridge 事件觸發的 Lambda 函式執行 aws ec2 associate-address。
• 暫存公有 IP 在停止/啟動後不會保留——只有 Elastic IP 才會持久保留。
• 未關聯的 Elastic IP 會收取小額的每小時費用（閒置 EIP 罰款）——Trusted Advisor 會標記此問題。

對於 ELB 前置的工作負載，Elastic IP 通常出現在 NLB（每個 AZ 一個），而非直接在 instance 上。ALB 不暴露靜態 IP（對 ALB 前置使用 Global Accelerator 取得靜態 anycast IP）。

Amazon EFS 共享檔案系統

Amazon EFS 是一個受管的 NFSv4 檔案系統，可同時掛載在 ASG 的每個 instance 上。從運維角度看：

• 當多個 instance 需要共享檔案狀態時使用 EFS（已上傳的媒體、共享設定、CMS 的內容目錄）。
• 每個 AZ 一個 mount target——確保 ASG 啟動的每個 AZ 都有 EFS mount target。
• 效能模式：General Purpose（預設）vs Max I/O。吞吐量模式：Bursting（預設）、Provisioned 或 Elastic。
• Lifecycle policies 將不常存取的檔案移至 EFS-IA 或 EFS Archive 以降低成本。

FSx 替代方案

• FSx for Windows File Server — Windows 工作負載的 SMB 共享（Active Directory 整合）。
• FSx for Lustre — 高效能運算。
• FSx for NetApp ONTAP / FSx for OpenZFS — 特殊工作負載的功能豐富共享儲存。

針對 SOA-C02 有狀態 HA 場景：

• 「多個 EC2 instance 需要讀寫同一組檔案」→ EFS。
• 「特定 instance 重啟後必須保持相同的公有 IP」→ Elastic IP。
• 「Windows 機群需要 SMB 共享」→ FSx for Windows。

Route 53 Health Checks 與 Failover Routing

疊加在 ELB health checks 之上，Route 53 health checks 提供 DNS 層級的健康感知，用於跨 region failover 與 weighted routing。

Health check 類型

• Endpoint health check：來自 Route 53 分散式探針（15 個以上 region）的 HTTP / HTTPS / TCP 探針。可配置間隔（10 秒標準版，30 秒預設版）、失敗門檻、請求字串比對、延遲測量。
• Calculated health check：透過 Boolean 組合最多 256 個子 health checks（AT LEAST N must be healthy）。
• CloudWatch alarm health check：將 CloudWatch alarm 的狀態對應到 health check 結果。當訊號是內部的（佇列深度、錯誤率）而非公共 HTTP 端點時特別有用。

Failover routing policy

Failover routing policy 有兩筆記錄——primary 與 secondary——各自綁定一個 health check：

• 只要 primary 的 health check 健康，DNS 查詢回傳 primary 值。
• 當 primary health check 失敗，查詢回傳 secondary 值。
• TTL 控制客戶端接收到變更的速度。

常見模式：

• 跨 region Active-passive：primary 為 us-east-1 ALB，secondary 為 us-west-2 ALB。東部 region health check 失敗時，DNS 切換到西部。
• Active-passive 搭配地端：primary 為地端機房，secondary 為 AWS warm standby。

其他路由策略（相關）

• Weighted：依百分比在多個值之間分配流量。與 health checks 搭配用於 DNS 層的容錯 blue/green 或 canary。
• Latency-based：將客戶端路由到延遲最低的 region。
• Geolocation / Geoproximity：依地理位置路由。
• Multivalue answer：回傳最多 8 個健康值供客戶端選擇，類似 round-robin DNS 但帶有健康感知過濾。

場景模式：ALB 在流量高峰期回傳 502 — 診斷 Runbook

SOA-C02 反覆出現的疑難排解場景。

症狀

• ALB access logs 顯示 elb_status_code = 502，target_status_code = -（target 無回應）。
• CloudWatch metric HTTPCode_ELB_5XX_Count 偏高；HTTPCode_Target_5XX_Count 也可能偏高。
• Scale 事件期間客戶端可見的錯誤。

Runbook

1. 確認 target group 健康狀態：高峰時有多少 targets 健康 vs 不健康？在 deregistration 期間失去一半 targets 的 ALB，對剩餘流量來說容量不足。
2. 確認 deregistration delay：太短的延遲在 scale-in 或 instance refresh 期間丟棄進行中的連線。若工作負載有長輪詢或大型上傳請求，將延遲提高到 300–900 秒。
3. 確認 ASG 的 health check grace period：太短 → 新啟動的 instance 在開機前被砍 → 有效機群縮小 → 502。
4. 確認 target health check 門檻值：UnhealthyThresholdCount = 2 很激進。不穩定的網路閃爍會讓 targets 反覆進出 unhealthy 狀態。提高到 3–5 以降低敏感度（代價是偵測速度變慢）。
5. 確認應用程式本身：target 回傳的 target_status_code = 502 表示應用程式自己回傳了 502——不是 ELB 注入的。檢查應用程式日誌。
6. 確認 target group 的 connection idle timeout：ALB 預設 60 秒。超過 60 秒的長時間請求會被 ALB 中斷 → 通常是 504（gateway timeout），但配置錯誤的應用程式可能先回傳 502。
7. 確認 security group / NACL：target SG 必須允許來自 ALB SG 在 target port 的入站流量；NACLs 必須允許回程的 ephemeral ports。

依序最常見的根本原因：scale 事件期間 deregistration delay 太短、health check grace period 為 0 或太短、target group health check 門檻值過激進。

場景模式：ASG 每十分鐘震盪一次 — 調校 Runbook

另一個 SOA-C02 典型場景。

症狀

• ASG 啟動 2 個 instance，十分鐘後終止它們，再啟動 2 個。
• CloudWatch alarm 每個週期在 OK → ALARM → OK 之間震盪。
• CPU 圖表在目標值附近顯示鋸齒模式。

Runbook

1. Datapoints to alarm：若 alarm 使用 M = N = 1（一個突破點就觸發 alarm），每次尖峰都會觸發 scale。改為 3 of 5，要求持續突破才觸發。
2. Instance warm-up 太短：target tracking 立即將新 instance 的 metric 計入，看到仍在開機的 instance CPU 很低，計算出「機群過度配置」，執行 scale-in。增加 EstimatedInstanceWarmup 或 DefaultInstanceWarmup 以符合真實開機時間（通常 180–300 秒）。
3. 目標值太緊：目標為 50%，而工作負載自然在 40% 到 60% 之間波動，會持續觸發小規模的 scaling 動作。提高到 60% 並擴大可接受範圍，或對可預測的元件使用 scheduled scaling。
4. Cooldown（僅限 simple scaling）：提高到 300–600 秒。
5. 使用 composite alarm：將 CPU alarm 與持續負載 alarm（5xx 錯誤率或佇列深度）配對——只有兩者都表明真實負載時才 scale。
6. 切換到 anomaly detection：若工作負載有季節性模式；靜態 threshold 會震盪，因為正常波動就能跨越 threshold。

最常見的根本原因：M=N=1 資料點、instance warm-up 太短、目標值太緊。

場景模式：Refresh 後 ELB 仍路由到舊的 Unhealthy Instance

症狀

• 透過 instance refresh 部署新 AMI 後，客戶持續連到回傳 5xx 的舊 instance。
• Target group 顯示健康與不健康 targets 混雜。

Runbook

1. Health check grace period：太長 → ASG 無法足夠快速地偵測到不健康的舊 instance。確認其值不超過推出時間窗口。
2. MinHealthyPercentage 太高：替換無法推進，因為終止一個 instance 會跌破門檻值；舊 instance 繼續服務。
3. Health check protocol/path/port：若新 AMI 更改了 health 端點（例如從 /health 到 /healthz），target group 的 health check 仍然訪問舊路徑 → 所有新 instance 顯示為 unhealthy → refresh 停滯。
4. 卡住的 deregistration：長時間的 deregistration delay 與持久連線的組合，可能讓舊 targets 在整個延遲視窗內保持 draining 狀態。
5. Sticky sessions：持有有效 lb_cookie 的客戶端持續回到舊 targets，即使有較新的健康 targets 可用。Refresh 後，清除受影響 session 的 stickiness，或使用較短的 cookie 時長。

常見陷阱整理 — Auto Scaling 與 ELB

每次 SOA-C02 考試都會出現其中幾個。

陷阱 1：ASG 預設 health check 只有 EC2

除非明確設定 HealthCheckType=ELB，ASG 否則忽略 ELB target 的健康狀態。考生常假設「ALB 正在 health-checking target，ASG 一定在使用那個訊號」——預設情況下並非如此。

陷阱 2：部分路徑的 Health check grace period 預設為 0

API/CLI 省略預設值會得到 0。對於任何非簡單的應用程式，務必明確設定為 ≥120 秒。

陷阱 3：Cooldown 只適用於 simple scaling

Target tracking 與 step scaling 使用的是 instance warm-up，而非 cooldown。調整 cooldown 來修復 target tracking 震盪毫無用處。

陷阱 4：ALB sticky lb_cookie 以 target group 為單位

Blue/green 部署到新 target group 會中斷活躍用戶的 sticky sessions。

陷阱 5：NLB 歷史上沒有 security group

入站過濾必須在 target instance 的 security groups 上進行。（可選的 NLB 層級 SG 是較新的功能。）

陷阱 6：NLB cross-zone 預設停用

AZ 分佈不均會導致部分 targets 被壓垮，而其他 targets 閒置。需要時明確啟用 cross-zone。

陷阱 7：Detailed monitoring 是 1 分鐘 scaling 的必要條件

預設 EC2 monitoring 是 5 分鐘週期；使用 1 分鐘 alarm 的 target tracking 需要在來源 instance 上啟用 detailed monitoring。

陷阱 8：MinHealthyPercentage 太高導致 Instance refresh 卡住

若 ASG 在不跌破門檻值的情況下無法終止任何 instance，refresh 會卡住。降低百分比以使推進成為可能。

陷阱 9：Deregistration delay 太短會丟棄進行中的請求

預設 300 秒是有原因的——只有對真正無狀態且請求時間短的 tier 才降低此值。

陷阱 10：Launch template 更新時 ASG 不會自動替換 instance

Launch template 只在 instance 啟動時才被讀取。現有 instance 繼續執行舊版本。需要 Instance refresh 才能推出變更。

陷阱 11：單 AZ ASG 不提供容錯

SOA-C02 干擾選項：一個 ASG 在一個 AZ 中被描述為「高可用」。它並不是——AZ 失敗會讓整個機群離線。任何生產環境的 HA 聲明最少需要 2 個 AZ。

陷阱 12：Lifecycle hook 逾時時預設被 ABANDON

若 DefaultResult 是 ABANDON（或省略），逾時的 hook 會導致 instance 被終止並回滾。若 hook 是盡力而為的，請設定 DefaultResult=CONTINUE。

SOA-C02 vs SAA-C03：運維視角的差異

考試訊號：如何辨識 Domain 2.1 / 2.2 的題目

Domain 2 的 SOA-C02 題目遵循可預測的模式。

• 「Instance 啟動但在服務流量前被砍」 → health check grace period 預設 0，提高到 ≥180 秒。
• 「ASG 每 N 分鐘震盪一次」 → datapoints to alarm M-of-N、instance warm-up 太短、目標值太緊。
• 「ELB 在高峰期回傳 502 / 504」 → deregistration delay、health check grace period、target health 門檻值、應用程式逾時。
• 「AMI 更新後，機群仍在舊版本」 → 啟動 instance refresh。
• 「Instance refresh 卡住」 → MinHealthyPercentage 太高、InstanceWarmup 太短、health check 路徑已變更。
• 「部署後 Sticky sessions 中斷」 → lb_cookie 以 target group 為單位；改用 app_cookie 或外部化狀態。
• 「需要跨 region failover」 → Route 53 health check + failover routing + 第二 region 的 warm standby。
• 「NLB target 分佈不均」 → cross-zone 預設停用；啟用或讓各 AZ 數量相等。
• 「ASG 保留 unhealthy instance」 → HealthCheckType 為 EC2，改為 ELB。
• 「終止前需要自訂排空邏輯」 → 終止 lifecycle hook，而非 deregistration delay。

決策矩陣 — 每個 SysOps 目標對應的 ASG 與 ELB 構件

考試時用此對照表查找。

FAQ — SysOps HA 的 EC2 Auto Scaling 與 ELB

Q1：為什麼我的 ASG 在 CloudWatch 顯示為健康，但 ALB 卻回傳 502？

最可能的原因是 ASG 使用 HealthCheckType=EC2（預設），因此只計算 EC2 status checks。Instance 通過 EC2 status checks（OS 可回應、主機正常），但應用程式在 Layer 7 是 unhealthy 的。ALB 看到應用程式失敗並回傳 502，但 ASG 從未替換 instance。將 ASG 切換到 HealthCheckType=ELB，讓應用程式失敗觸發替換。同時設定合理的 health check grace period（≥180 秒），避免剛啟動的 instance 在開機前就被砍掉。

Q2：Cooldown 與 instance warm-up 有什麼區別，應該調整哪個？

Cooldown 是 scaling 動作完成後，同類型的另一個 scaling 動作被允許前的等待視窗——只適用於 simple scaling policies（舊式的單動作類型）。Target tracking 與 step scaling 完全忽略 cooldown。Instance warm-up 是剛啟動 instance 的 metrics 被排除在 ASG 聚合統計之外的時長，防止仍在開機的 instance 影響 metric。要修復 target tracking 震盪，增加 ASG 的 EstimatedInstanceWarmup 或 DefaultInstanceWarmup。要修復 simple scaling 震盪，增加 cooldown。混淆這兩者是 SOA-C02 最常見的反震盪錯誤修法。

Q3：什麼時候使用 lifecycle hook、user-data 或 deregistration delay？

User-data 是在首次開機時執行的一次性 OS bootstrap 腳本。快速且原子性，但 ASG 無法等待 user-data、無法回滾，且不接收任何反饋。用於簡單的 OS 層級設定（安裝套件、寫設定檔）。Lifecycle hooks 讓 ASG 在 Pending:Wait（launch hook）或 Terminating:Wait（terminate hook）暫停，並需要明確的 CompleteLifecycleAction API 呼叫才能繼續。用於 ASG 必須等待的任何自訂邏輯，尤其是優雅排空、外部服務註冊或飛行前測試。Deregistration delay 是 ELB 層級的設定，讓進行中的連線在 target 被強制斷開前完成——不執行任何自訂程式碼。搭配使用：用 deregistration delay 實現連線層級的緩衝，用 lifecycle hooks 實現應用程式層級的緩衝。

Q4：為什麼我的 instance refresh 卡在 0% complete？

兩個可能的原因。(a) MinHealthyPercentage 太高——若門檻值是 100% 且 ASG 有 4 個 instance，refresh 無法在不跌破門檻值的情況下終止任何 instance，因此永遠不會開始。降低到 75%（或任何至少留下一個 instance 可替換的值）。(b) InstanceWarmup 比實際開機時間短——refresh 啟動一個替換 instance，在 warm-up 後認為它進入 InService，但實際應用程式尚未完成開機且是 unhealthy 的。Refresh 將 unhealthy target 視為失敗並回滾。提高 warm-up 以符合真實開機時間，或在 AMI 中預烤更多內容以縮短開機時間。

Q5：如何正確調整 health check grace period？

測量新 instance 從啟動到「/healthz 首次回傳 200 OK」需要多長時間——這是最短的 grace period。再加 30–60 秒的緩衝應對變異性。典型值：預烤黃金 AMI 的無狀態 web tier：60–120 秒。需要 JVM 暖機的 Java 應用程式：180–300 秒。從 ECR 拉取 image 的容器主機：300–600 秒。需要完整 domain join + SSM bootstrap 的 Windows instance：600–900 秒。grace period 太短會砍掉正在開機的 instance；太長則延遲偵測到真正損壞的 instance。務必在非生產環境中測試。

Q6：ALB 與 NLB 的 health checks 有什麼區別？

ALB target group health checks 預設基於 HTTP/HTTPS——訪問可配置的路徑與連接埠，預期在可配置範圍內的狀態碼（預設 200），以及可配置的間隔（預設 30 秒）、門檻值（預設 5 healthy / 2 unhealthy）和逾時。NLB target group health checks 支援 TCP、HTTP 或 HTTPS——對於 TCP，health check 是連線建立（無 payload）；對於 HTTP/HTTPS，類似 ALB 但有些微不同的預設值（TCP 的間隔 30 秒，門檻值 3/3 預設）。NLB health checks 從每個 AZ 的每個 NLB node 發出，這就是為什麼在 cross-zone 停用的 NLB 上，AZ 分佈不均會導致流量不均衡。ALB cross-zone 永遠開啟；NLB 預設關閉。

Q7：Route 53 failover routing 如何與 ELB 搭配運作？

兩筆記錄，primary 與 secondary，各自綁定一個 Route 53 health check。Primary 記錄指向 region A 的 ELB；secondary 指向 region B 的 ELB。Route 53 health check 探測 ELB 端點（或任何其他 URL）。Health check 健康時，DNS 查詢回傳 primary 值；失敗時，查詢回傳 secondary。記錄的 TTL（通常 60 秒）控制客戶端接收到變更的速度。從運維角度，secondary region 必須預先配置好 ASG 與 ELB 並處於暖機狀態——DNS failover 很快，但工作負載本身必須準備好接收流量。透過定期 DR 演練測試 failover（手動停用 primary 並確認客戶端已切換）。

Q8：為什麼我的 ALB sticky session 在 blue/green 部署後中斷？

ALB 管理的 sticky sessions 使用 lb_cookie cookie，其範圍限定在單一 target group。當你將流量從舊 target group（blue）切換到新 target group（green）時，現有的 lb_cookie cookie 對新 target group 毫無意義，每個客戶端都被重新平衡到從未見過的 target。若應用程式將 session 狀態存在 instance 記憶體中，這些 session 就遺失了。三種補救方式：(a) 使用 app_cookie（應用程式自己的 session cookie），讓 stickiness 跨 target groups 可攜；(b) 將 session 狀態外部化到 ElastiCache for Redis 或 DynamoDB，讓 target 重新固定不至於遺失狀態；(c) 接受這個中斷作為 blue/green 的一部分並通知用戶。選項 (b) 是 SOA 推薦的長期修復方案。

Q9：NLB cross-zone load balancing 什麼時候重要？

NLB cross-zone 預設停用，意味著每個 AZ 的 NLB node 只將流量轉發到同一 AZ 的 targets。當各 AZ 的 target 數量相等（正常的 ASG 分佈）時，這沒問題——每個 AZ 的流量份額與其 target 份額相符。但當 AZ 不均衡（一個 AZ 有 9 個 target，另一個只有 1 個）時，只有 1 個 target 的 AZ 會被壓垮，因為它仍然接收 50% 的 NLB 流量（NLB 在每個 AZ 有等量的 nodes）。三種修復方式：(a) 在 NLB 上啟用 cross-zone load balancing（需支付跨 AZ 資料傳輸費，但分佈更均勻）；(b) 透過 ASG 的均勻分佈與 AZ rebalancing 維持每個 AZ 相等的 target 數量；(c) 在配置中使用更少的 AZ。SOA-C02 特別測試識別這種不對稱性，與永遠 cross-zone 的 ALB 對比。

Q10：如何診斷「ASG 在 scale-out 期間沒有啟動新 instance」？

按照以下清單逐一確認：(a) MaxSize 已達上限——ASG 無法超過 max；確認目前的 desired vs max。(b) 目標 AZ / instance type 無容量——Spot 資源池耗盡、on-demand vCPU 服務配額超過、instance type 在 AZ 中不可用。查看 CloudWatch alarm 日誌與 ASG activity history。(c) Subnet IP 耗盡——subnet 的 IP 已用完；擴大或新增另一個 subnet。(d) Launch template 引用無效 AMI——AMI 已取消註冊或在 region 中不可用。(e) IAM instance profile 缺失——IAM role 無法假設。(f) 服務配額——vCPU 限制、ENI 限制、EIP 限制、EBS volume 數量。ASG 在 console 的 Activity 標籤頁直接顯示失敗原因——那是你第一個該看的地方。

Q11：多層應用程式應使用單一 ASG 還是多個 ASG？

每個 tier 一個 ASG。Web tier ASG 與 API tier ASG 分開，API tier ASG 與 worker tier ASG 分開。每個各有自己的 launch template、scaling policy、target group 和 health check。這種分離讓你能獨立擴展各 tier（API 可能是 CPU 受限的，worker 是 IO 受限的）、獨立部署（對 web tier 執行 instance refresh 而不影響 worker）、針對每個 tier 調整 health checks（web 使用 HTTP /healthz，worker 完全沒有 ELB）。單一 ASG 承載多個 tier 是反模式——你無法獨立擴展或更新它們。

Q12：Scheduled scaling 什麼時候與 target tracking 搭配，如何搭配？

當工作負載同時具有可預測的基線模式（上班時段、批次視窗）和其上的不可預測變化（隨機用戶流量）時。Scheduled scaling 設定基線：每個平日 08:30，desired = 10；19:00，desired = 4。Target tracking 在基線之上處理變化：將 CPU 維持在 50%，必要時 scale-up 到 20。兩者在同一個 ASG 上共存——排程動作在精確時間將 desired 移到基線，target tracking 從那裡繼續對 metrics 做出反應。沒有 scheduled scaling，target tracking 必須等到早高峰實際到來才能反應，往往讓第一波用戶體驗到性能降級。Scheduled scaling 是「在可預測高峰前預熱」的 SOA 正確答案。

延伸閱讀與相關運維模式

• What Is Amazon EC2 Auto Scaling — User Guide
• Auto Scaling Groups
• Launch Templates for Auto Scaling
• Target Tracking Scaling Policies
• Step and Simple Scaling Policies
• Scheduled Scaling
• Cooldowns for Auto Scaling
• Auto Scaling Lifecycle Hooks
• Health Checks for Auto Scaling Instances
• Health Check Grace Period
• Auto Scaling Instance Refresh
• Auto Scaling Groups with Multiple Instance Types
• What Is Elastic Load Balancing
• Application Load Balancer User Guide
• Network Load Balancer User Guide
• ALB Target Group Health Checks
• Sticky Sessions for ALB
• Deregistration Delay (Connection Draining)
• Route 53 DNS Failover
• Route 53 Health Check Types
• AWS SOA-C02 Exam Guide v2.3 (PDF)