Amazon SOA-C02: 運算與 Auto Scaling — 學習指南
屬於 AWS SysOps Administrator Associate SOA-C02 — 學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.
這個領域涵蓋了管理 EC2 執行個體與 Auto Scaling，以提供可靠且具成本效益的運算容量。其重點在於執行個體生命週期操作、擴展策略、負載平衡器整合、為效能與彈性所做的放置，以及影響可用性與狀態的維護/終止行為。操作上的精通意味著能選擇正確的執行個體類型、啟動組態模式、擴展政策以及健康狀態檢查整合，以便在控制成本的同時滿足服務等級協議 (SLA)。
EC2 執行個體生命週期與管理
EC2 生命週期管理始於啟動組態的設定點：使用啟動範本 (Launch Templates) (
undefined
/ 主控台) 來擷取 AMI、執行個體類型、IAM 執行個體描述檔、使用者資料 (user-data)、網路介面、EBS 映射以及中繼資料選項；範本支援版本控制，這使得不可變部署 (immutable deploys) 變得直接簡單。不可變部署會使用新的啟動範本版本（或新的啟動範本），並建立一個新的 Auto Scaling 群組，或使用 ASG 執行個體更新來替換執行個體；當變更會影響開機行為或 AMI 層級的修補時，應避免對執行中的執行個體進行原地升級。
操作上的 CLI/主控台模式包括用於一次性啟動的
undefined
，以及用於 ASG 驅動啟動的
undefined
。根據開機時間，在 AMI 烘焙 (AMI baking) (使用 Packer/CodeBuild) 和使用者資料啟動指令碼之間做選擇：將重度相依性烘焙到 AMI 中以縮短開機時間；使用使用者資料 (user-data) 進行環境特定的串接。對於暫時性儲存，請記住執行個體儲存磁碟區會在終止時遺失；如果您需要在執行個體終止後保留 EBS 的資料，請將根磁碟區和資料磁碟區設定為 DeleteOnTermination=false。
Auto Scaling 群組、政策與生命週期掛鉤
Auto Scaling 群組 (ASG) 是透過啟動範本或啟動組態來設定的，並控制跨可用區域的期望/最小/最大容量。選擇啟動範本 + MixedInstancesPolicy 來建立成本最佳化的機群，該機群混合了隨需 (On-Demand) 和 Spot 執行個體，並搭配一份執行個體類型清單；使用執行個體權重和容量最佳化分配策略以獲得可預測的容量。對於部署，偏好使用不可變模式：建立一個新的啟動範本版本，並執行 ASG 執行個體更新或藍/綠交換，而不是重新設定現有的執行個體。
擴展政策的表達方式如下：
- 目標追蹤 (Target tracking) (
undefined
)：設定一個預先定義的指標（如 ALB RequestCountPerTarget 或 ASG 平均 CPU）和一個目標值；ASG 會自動處理調整。
- 步階擴展 (Step scaling) (
undefined
)：定義 CloudWatch 警示，根據違規的嚴重程度觸發特定的調整步驟（例如 +2、+4）；對於突發性工作負載很有用。
- 簡易擴展 (Simple scaling) (舊式)：帶有冷卻時間的單一步驟調整；通常已被目標追蹤或步階擴展所取代。
使用生命週期掛鉤 (lifecycle hooks) (
undefined
) 來暫停執行個體的終止/啟動。生命週期掛鉤讓您能夠在完成前，清空連線、複製狀態（到 S3/RDS），或透過 SNS/SQS/Lambda 通知協調系統；務必設定 HeartbeatTimeout 和一個預設動作，以避免卡在某個狀態。
Elastic Load Balancing 類型與健康狀態檢查
根據流量模式選擇負載平衡器類型：Application Load Balancer (ALB) 用於 HTTP/HTTPS，具有基於內容的路由以及主機/路徑規則；Network Load Balancer (NLB) 用於極致效能和 TCP/UDP 的靜態 IP；Classic Load Balancer (CLB) 僅用於舊式堆疊。使用
undefined
和
undefined
建立 ALB 和目標群組；透過使用 ASG 的目標群組關聯來註冊 ASG 目標，以實現自動化的生命週期健康狀態整合。
健康狀態檢查的整合需要將 ASG 和 ELB 的健康狀態檢查對齊：將 ASG 的 HealthCheckType 設定為 ELB (
undefined
)，這樣一來，只有在負載平衡器將其目標標記為健康後，執行個體才被視為健康。健康狀態檢查的類型與其影響：
- ALB/NLB 目標群組健康狀態檢查：支援 HTTP/HTTPS/TCP 並測量應用程式層級的就緒狀態；建議用於 Web 應用程式。
- 僅使用 ASG 健康狀態檢查：用於簡單的主機層級檢查（例如 EC2 狀態檢查）。
HealthCheckGracePeriod：給予新執行個體時間來開機、執行使用者資料 (user-data)，並通過應用程式層級的檢查。
黏性工作階段的影響：ALB 目標群組的黏性工作階段使用基於應用程式 cookie 的親和性（基於持續時間），這可以改善工作階段親和性，但會降低負載的均勻分佈並使滾動更新複雜化。NLB 支援用戶端 IP 親和性；僅在工作階段狀態無法外部化時才使用黏性工作階段。
執行個體放置、容量規劃與擴展指標
放置決策會影響延遲與故障網域：放置群組 (placement groups) 提供叢集 (cluster，低延遲網路)、分散 (spread，每個機架一個執行個體，適用於關鍵執行個體) 與分割 (partition，故障隔離的分割區) 等策略。ASG 預設會在可用區域 (AZ) 之間平衡執行個體；建議採用感知 AZ 的容量規劃，以避免單一 AZ 的熱點。CLI 指令：aws ec2 create-placement-group –strategy cluster|spread|partition。
容量規劃需考量執行個體類型、採購選項與指標：
- 執行個體類型：根據工作負載選擇 CPU/記憶體/網路優化系列 (M/C/R/T/D/I)；透過具代表性的負載測試來衡量。
- 採購選項：On-Demand 用於可預測性，Reserved 或 Savings Plans 用於穩定狀態的成本降低，Spot 用於暫態工作負載的成本效益；使用 MixedInstancesPolicy 來結合不同類型與採購選項。
- 擴展指標：預設的 ASG 指標使用群組內的平均 CPU；建議使用應用程式層級的指標，例如 ALB 的 RequestCountPerTarget 或自訂的 CloudWatch 指標 (例如佇列深度) 進行目標追蹤。常見模式：
- 當您需要每個執行個體處理穩定的請求數量時，請使用目標追蹤搭配 ALB/request-count-per-target。
- 對於突然的大量尖峰流量，並有明確的恢復步驟時，請使用步階擴展。
- 對於每日週期性的工作負載，可考慮使用預測性擴展。
執行個體復原、終止行為與維護
透過啟用硬體問題的自動復原 (使用 CloudWatch 警示搭配 EC2 Recover 動作) 與處理排程事件 (describe-instance-status)，來規劃執行個體的故障與維護。設定 instance-initiated-shutdown-behavior 與 EBS 的 DeleteOnTermination 旗標來控制磁碟區的生命週期；使用 aws ec2 modify-instance-attribute –instance-id i-xxx –block-device-mappings 進行調整。
ASG 中的終止行為：ASG 終止政策決定要先終止哪個執行個體 (預設：最舊的啟動組態或根據執行個體健康狀況與 AZ 平衡的啟發式演算法)。重要的操作細節：
- 本機狀態是暫時的：執行個體儲存磁碟區與記憶體內的快取會在終止時遺失。不要假設替換的執行個體會保留本機狀態；將關鍵資料持久化到 EBS (搭配適當的快照/備份)、S3 或外部快取 (ElastiCache)。
- 使用生命週期掛鉤 (lifecycle hooks) 在終止前將流量抽乾並卸載狀態。
- 使用執行個體重新整理 (instance refresh) 或藍/綠部署進行維護，以安全地替換執行個體；aws autoscaling start-instance-refresh –auto-scaling-group-name my-asg –preferences file://prefs.json。
常見陷阱與決策標準
- 依賴預設的冷卻時間與僅限 CPU 的指標：應選擇與應用程式行為一致的指標 (ALB RequestCountPerTarget、佇列深度)；設定冷卻時間以容納啟動時間，並設定 HealthCheckGracePeriod 以避免擴展行為來回擺盪。
- 未使用生命週期掛鉤進行優雅終止：若無掛鉤，進行中的請求與本機快取會遺失；應實作掛鉤搭配 SNS/SQS/Lambda 來抽乾流量並持久化狀態。
- 假設執行個體替換會保留本機狀態：本機的執行個體儲存與記憶體內快取是暫時的；應設計為無狀態的執行個體，或將狀態複製到持久性儲存。
- 過度使用黏性會話 (stickiness)：黏性會話會增加負載分佈不均，並使擴展與更新變得複雜；建議使用外部會話儲存 (ElastiCache, DynamoDB) 以利於向外擴展。
- 忽略 AZ 平衡與放置群組：在單一 AZ 或叢集群組中放置過多執行個體會產生單點故障；應使用 ASG 的多 AZ 分佈與適當的放置群組策略。
- 錯誤設定健康狀態檢查整合：ASG 的 health-check-type 必須與 ELB/目標群組的健康狀態檢查相符，且 HealthCheckGracePeriod 必須足夠長以容納應用程式初始化，否則健康的執行個體將會被終止。
實務問題：使用情境
StreamingCo 經營一個影片縮圖 API，每天都會遇到流量尖峰，並在 EC2 執行個體上使用本機磁碟快取；最近，擴展速度變慢，且被終止的執行個體會遺失快取，導致回應時間不佳。
- 將啟動組態遷移到啟動範本 (Launch Template)，並將執行階段的相依性烘焙到一個輕量級的 AMI 中；使用 aws ec2 create-launch-template 與版本控制來進行不可變部署。
- 設定一個帶有 MixedInstancesPolicy 的 ASG，其中列出多種執行個體類型以及 Spot + On-Demand 的分配策略，以平衡成本與容量。
- 掛載一個 ALB，並在 ALB 的 RequestCountPerTarget 指標上使用目標追蹤擴展 (TargetTrackingScaling)，同時將 HealthCheckGracePeriod 設定為應用程式的啟動時間。
- 在 ASG 終止時實作生命週期掛鉤，以抽乾連線，並在終止前執行一個 Lambda/SNS 流程，將必要的快取鍵持久化到 ElastiCache 或 S3。
- 將會話與快取狀態外部化到 ElastiCache 或 S3，並使用放置群組/AZ 分佈來滿足延遲與故障網域的需求。
理由：使用啟動範本與不可變部署可減少啟動時的變異性；以 ALB 為目標的目標追蹤擴展將擴展行為與請求負載而非 CPU 掛鉤；生命週期掛鉤可防止終止時的資料遺失；將快取外部化可消除對暫時性本機狀態的依賴，從而透過混合執行個體/採購策略實現快速、安全的擴展並降低成本。
練習這些題目 → · 在 ExamRoll.io 上限時練習 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
通過考試 →