Amazon SAP-C02: 運算與 Auto Scaling — 學習指南

By Laurynas Brazys · 1 August 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

屬於 AWS Solutions Architect Professional SAP-C02 — 學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.

EC2 執行個體設計、儲存與網路

設計 EC2 執行個體的第一步，是將工作負載特性與執行個體系列進行匹配，在 vCPU、記憶體、網路和本機儲存之間取得平衡。根據效能剖析，選擇運算優化 (C)、記憶體優化 (R/X)、儲存優化 (I/D) 或 GPU (P/G) 類型。利用 Nitro 型執行個體和 ENA/SR-IOV 來獲得高網路吞吐量與低延遲。對於延遲敏感或高 IOPS 的暫時性資料，可考慮使用 I3/I4 或 Nitro SSD 上的執行個體儲存 (ephemeral)；對於持久性區塊儲存，則使用具備 Provisioned IOPS (io2/io2 Block Express) 的 EBS，並啟用 EBS 加密搭配 KMS 進行金鑰管理。當執行個體位於 Application Load Balancer 後方的 VPC 中時，請確保面向網際網路的 ALB 放置在公有子網路，而目標則位於私有子網路；ALB 放置不當或安全群組設定錯誤是常見的陷阱。使用 Placement Groups (cluster 用於低延遲 HPC，partition 用於大規模分散式有狀態系統，spread 用於故障隔離) 來影響執行個體的放置位置，但需接受其權衡取捨：cluster 提供最佳效能，但會降低可用區 (AZ) 層級的容錯能力。對於傳輸中資料加密，可使用在 ALB 終止的 TLS，或透過 NLB passthrough 進行端對端 TLS。決策標準需權衡成本與效能：密度更高的執行個體類型可降低成本，但可能增加爆炸半徑和授權成本；應優先透過 CloudWatch、AWS Compute Optimizer 和負載測試來進行「適當調整大小 (right-sizing)」，而非依賴經驗法則。

Auto Scaling 群組、政策與生命週期管理

Auto Scaling Groups (ASG) 的設計應著重於彈性、韌性與成本效益，並結合使用啟動範本 (launch templates)、混合執行個體政策 (mixed-instances policies)、生命週期掛鉤 (lifecycle hooks) 與擴展政策 (scaling policies)。使用啟動範本對 AMI、執行個體類型覆寫、EBS 組態和使用者資料進行版本控制；採用容量優化 (capacity-optimized) 的 Spot 分配策略或多樣化策略的混合執行個體，可降低中斷風險並節省成本。在擴展行為方面，對於可預測的指標 (CPU、每個目標的請求計數)，應優先採用目標追蹤擴展政策 (target-tracking policies)；當需要由閾值驅動的多階段動作時，則使用步階擴展 (step-scaling)；預測性擴展 (predictive scaling) 可為已知的每日模式預先佈建容量。實作生命週期掛鉤，以便在執行個體終止前執行自訂的初始化或清空 (drain) 任務；結合暖集區 (warm pools) 以縮短服務就緒時間，並利用排程擴展 (scheduled scaling) 設定營業時間的基準容量。健康狀態檢查應整合 ELB 和 EC2 的健康狀態檢查，以避免過早替換執行個體。注意常見陷阱，例如因過於激進的冷卻時間所造成的縮減抖動 (scale-in churn)、在混合 ASG 中執行個體權重設定不當，以及未考慮到應用程式的暖機時間。對於有狀態的服務，應避免快速縮減，以免遺失記憶體內的快取；在成本與韌性的權衡上，由 Spot 支援的容量並搭配 On-Demand 作為後備方案可節省成本，但需要處理中斷，而 100% On-Demand 則能以較高成本最大化可預測性。

容器與協同運作：ECS、EKS 與 Fargate 的選擇

在 Amazon ECS、EKS 和 Fargate 之間的選擇，取決於營運模型、控制需求與工作負載模式。Fargate 免除了節點管理，對於優先考慮營運簡易性的團隊而言是理想選擇，但其每 vCPU 定價較高且有暫時性儲存空間的限制；它支援 Fargate Spot 以節省成本。對於希望使用容器協同運作但又不想面對 Kubernetes 複雜性的客戶，ECS 提供了與 AWS 的緊密整合及簡易性。當需要 Kubernetes 生態系、可攜性或進階排程功能時，EKS 則更為合適；可考慮使用受管節點群組 (managed node groups) 或自我管理 (Self-Managed) + Karpenter 來進行動態的適當調整大小。網路限制 (ENI/pod 密度) 與 CNI 行為會影響 pod 密度與節點大小；在 EKS 上，使用用於服務帳戶的 IAM 角色 (IAM Roles for Service Accounts) 和用於持久性磁碟區的 EBS CSI，可減少憑證擴散並實現每個 pod 的獨立儲存。對於共享檔案系統，根據吞吐量與延遲需求，可使用 EFS (NFS) 或 FSx (Lustre)；對於高元資料 (metadata) 操作的容器，應避免使用 NFS 作為後端——建議使用 EFS，並根據工作負載調整其吞吐量模式。實作 cluster autoscaler 或 Karpenter 進行節點擴展，並使用 ALB/ECS 服務指標進行服務自動擴展。常見的陷阱包括忽略 pod 中斷預算 (pod disruption budgets)、低估 Kubernetes 控制平面的配額，以及過度佈建節點而非採用箱式打包 (bin-pack) 策略——應在控制、成本與營運開銷之間進行權衡取捨，以驅動最終的選擇。

無伺服器運算模式、Lambda 限制與事件驅動設計

無伺服器 (Serverless) 架構雖然可以減少維運負擔，但需要採用特定的架構模式來處理並行、狀態管理以及下游系統的限制。Lambda 非常適合用於短時間、事件驅動的任務、透過 API Gateway 或 ALB 實現的 API 後端，以及使用 SQS 或 SNS 進行的非同步處理。對於需要編排長時間執行的工作流程，應使用 Step Functions；而存取資料庫時，則可透過 DynamoDB 或 RDS Proxy 來緩解連線風暴 (connection storms)。要注意 Lambda 在 VPC 環境中因建立 ENI 所造成的冷啟動延遲；對於延遲敏感的端點，可使用預置並行 (provisioned concurrency) 來緩解，或使用 VPC 端點和 RDS Proxy 來限制連線數。可透過 SNS + SQS 實現扇出/扇入 (fan-out/fan-in) 模式，或使用 Kinesis/MKS 進行有序的串流處理；並利用 SQS 的無效信件佇列 (dead-letter queues) 和冪等 (idempotent) 的處理程式來管理重試與重複的訊息。應妥善規劃並行數量限制、預留並行 (reserved concurrency) 和節流 (throttling)，以避免連鎖故障 (cascading failures)；並透過節流、帶有抖動 (jitter) 的重試機制，以及斷路器 (circuit breakers) (可使用 API Gateway 或自訂實作) 來設計反壓 (backpressure) 機制。成本與效能之間的權衡很明確：Lambda 對於突發性、短時間的工作負載具有成本效益，而 Fargate 或 EC2 則更適合持續性高 CPU 使用率或長時間執行的任務。常見的陷阱包括：依賴同步重試機制導致下游系統過載、將狀態儲存在本地的 /tmp 目錄並期望其能持久保存，以及未對延遲關鍵的流程預先配置資源以應對冷啟動。

實務問題：NovaTel 企業聯絡中心遷移案

情境：NovaTel 企業營運一個混合式聯絡中心，其通話路由在地端機房處理，並透過 Direct Connect 連接至 AWS。他們在兩個可用區域 (Availability Zones) 的 EC2 上執行會話代理 (session brokers)，並希望遷移到一個由 AWS 管理的聯絡中心，以確保地端 PBX 與雲端服務之間具有高可用性及可預測的延遲。

挑戰：他們需要為 SIP 流量提供低延遲的連線、一個可擴展且能容忍 Spot 執行個體中斷的語音處理運算層，以及一個不會增加維運複雜度的跨區域災難復原 (DR) 策略。

建議方法：

部署 Amazon Connect 以提供聯絡中心功能，並使用 Site-to-Site VPN 或搭配 AWS Transit Gateway 的 Direct Connect 來建立低延遲的 SIP 中繼線路 (SIP trunking)，該線路終止於一個設定了 TLS passthrough 的 NLB，而 NLB 則位於會話代理 (session brokers) 的前端。
將會話處理元件以混合式的 Auto Scaling Group 執行，其啟動範本 (launch templates) 採用容量優化 (capacity-optimized) 的 Spot 執行個體，並搭配 On-Demand 執行個體作為備援。同時，使用 Placement Groups (spread) 來對關鍵的代理程式進行故障隔離。
對於需要暫時性、低延遲儲存空間的有狀態通話媒體，使用具備執行個體儲存 (instance store) 的執行個體 (Nitro) 進行媒體緩衝，並將會話元數據 (session metadata) 複製到啟用 multi-AZ 複寫的 DynamoDB 或 ElastiCache。對於持久性資料，則採用 RDS (Multi-AZ) 或 Aurora Global DB，並搭配跨區域的讀取複本 (read replicas) 以實現災難復原。
實作生命週期掛鉤 (lifecycle hooks) 和暖集區 (warm pools) 以最小化代理程式的冷啟動時間，使用 Route 53 的加權容錯移轉 (weighted failover) 進行跨區域災難復原，並透過 CloudWatch + SNS/SQS 實現警報和自動化的容錯移轉腳本 (runbooks)。

理由：使用受管的聯絡中心服務可減輕維運負擔，而採用 Spot 的混合式 ASG 則能優化成本；將暫時性的媒體資料隔離在執行個體儲存上可維持效能，而將持久狀態複製到 DynamoDB/ElastiCache 以及使用 multi-AZ 的 RDS/Aurora，則能提供符合專業架構最佳實務的彈性與快速容錯移轉能力。

← 安全性、身分識別與合規性 · 所有領域 · 儲存與資料管理 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →