高效能與彈性運算解決方案

彈性運算擴充（elastic compute scaling）是 AWS Solutions Architect — Associate（SAA-C03）的核心主題。所有強韌、高效能且具成本效益的 AWS 架構，最終都建立在同一個概念之上：依需求自動增減運算容量，讓資源恰到好處。SAA-C03 考試指南任務 3.2「設計高效能且彈性的運算解決方案」直接對應本章，而 Domain 2（韌性）與 Domain 4（成本）的相鄰任務也從不同角度考驗彈性運算擴充。本章以 SAA-C03 實際獎勵的深度進行講解：EC2 執行個體家族、AWS Graviton、購買選項、EC2 Auto Scaling Groups、每一種擴充政策類型（目標追蹤、步進、簡易、排程、預測性）、launch templates、混合執行個體政策、cooldown、warm pools，以及 Spot 中斷處理。預期彈性運算擴充題目在正式 SAA-C03 考試中佔 8 至 12 道情境題。

什麼是 AWS 彈性運算擴充？

AWS 彈性運算擴充是一套在無需人工介入的前提下，以具成本意識的方式自動讓運算容量與工作負載需求匹配的學問。在服務層級，彈性運算擴充結合三個建構積木：（1）運算執行環境——Amazon EC2、AWS Fargate、AWS Lambda 或 AWS Batch；（2）擴充控制器——Amazon EC2 Auto Scaling、Application Auto Scaling、Kubernetes HPA/Cluster Autoscaler 或 Lambda 並行引擎；（3）信號——CloudWatch 指標、ALB 請求數、自訂指標或時間排程。在 SAA-C03 聽到「彈性運算擴充」時，主要指的是 EC2 Auto Scaling，但概念可推廣到 AWS 提供的每一個運算介面。

彈性運算擴充同時解決三個架構問題：

• 高負載下的效能 — 在延遲攀升之前 scale out 水平擴充。
• 閒置時的成本效益 — 需求下降時積極 scale in 縮減。
• 自我修復 — 替換不健康的執行個體，讓期望中的機隊規模隨時達標。

SAA-C03 考試指南明確將可擴充性、高可用性與成本最佳化列為跨領域關注點，這正是彈性運算擴充出現在眾多情境題中的原因。正確的彈性運算擴充答案必須同時平衡三者，而非只顧其一。

為何彈性運算擴充主導 SAA-C03

彈性運算擴充出現在每個 Domain。Domain 2（韌性）透過跨多 AZ 的 Auto Scaling Groups 在 AZ 故障中存活來考驗彈性運算擴充。Domain 3（高效能）透過目標追蹤、預測性擴充與 placement groups 來考驗彈性運算擴充。Domain 4（成本）透過 Spot + On-Demand 混合執行個體政策、Reserved Instances 與 Savings Plans 來考驗彈性運算擴充。深入掌握彈性運算擴充，就能在每個 Domain 都拿分，而不只是其中一個。

白話文解釋 Elastic Compute Scaling

Elastic compute scaling 聽起來很學術，但用日常生活的比喻會瞬間通透。一次記住下面三種完全不同領域的類比，考場遇到 elastic compute scaling 情境題就能秒選。

類比一 — 夜市攤位的人力調度

把 elastic compute scaling 想成一個熱門夜市攤位的人力安排：

• EC2 instance family = 不同職位的攤位人員：煎台師傅（C 家族、CPU 密集）、備料員（T 家族、短時爆發）、收銀員（M 家族、均衡通用）。
• Launch template = 員工手冊：新人第一天，發一本寫好工作服規定、打卡時間、負責品項的手冊（AMI、instance type、security group、user data）。
• Auto Scaling Group = 當班排班表：最少留 2 人（min）、尖峰時段最多 20 人（max）、目前需求 8 人（desired）。
• Target tracking policy = 「讓每位攤位人員平均忙 70%」的 KPI：系統根據 CPU 使用率自動補人手或讓人先下班。
• Scheduled scaling = 夜市開攤前固定加人：知道每天 17:30 會有人潮就提前排班。
• Predictive scaling = 看過去三週人流曲線預判今晚：ML 幫你提前 2 小時補人。
• Warm pool = 後場待命員工：制服穿好、打卡完畢，不在攤台前但隨時可上線，省掉每次招募（boot-up）時間。
• Spot instance = 臨時鐘點工：時薪便宜 70–90%，但老闆可以兩分鐘前通知「今天不用來了」。
• Spot interruption handling = 交接 SOP：鐘點工要下班前先交棒，不要讓鍋子燒焦。

這個類比把 elastic compute scaling 裡「誰做什麼、什麼時候多叫人、什麼時候請人先走」的因果關係一次講清楚。

類比二 — 高速公路收費站

第二個類比用收費站現場解釋 elastic compute scaling 的時間敏感度：

• On-Demand = 常態收費員：隨到隨開，工資最貴但最即時。
• Reserved Instance = 年約員工：一簽一年或三年，時薪打六折，但離職要賠錢。
• Savings Plans = 彈性年約：承諾每小時花多少錢，可以在 C5、M6g、Fargate 間轉場。
• Spot = 義交志工：有空就來、沒空走人，工資超便宜。
• Step scaling = 塞車分級：車流 > 500 輛多開 1 個亭、> 1000 輛多開 3 個、> 2000 輛多開 5 個。
• Simple scaling = 最原始的「多開一個、等冷卻、再看」：有 cooldown，效率比 step scaling 差。
• Cooldown = 新亭開完後的 300 秒觀察期：避免才剛開一個又被叫多開。

這個比喻的價值在於把 elastic compute scaling 的 policy 家族差異 視覺化：step 和 simple 的差別、cooldown 的實際作用。

類比三 — 物流倉儲的堆高機調度

第三個類比專門拆解 mixed-instances policy 和 Spot fallback：

• Warehouse = Auto Scaling Group：你要把貨物（請求）在時限內全部處理完。
• 堆高機型號清單（multiple instance types）= 你告訴調度系統「m5.large、m5a.large、m5n.large、m6i.large 都可以」：任何一款能做這工作。
• On-Demand base capacity = 必備基本堆高機數：例如至少 4 台要自有，確保可靠度。
• Spot % = 超過基本量後用外包堆高機：剩下 80% 從 Spot 市場抓最便宜的型號。
• Capacity-optimized allocation strategy = 調度系統自動挑 最不容易被收回 的 Spot 池：降低 Spot interruption 機率。
• Spot interruption notice = 外包司機收到兩分鐘「車要被收回」簡訊：系統要在兩分鐘內讓司機把堆高機停好、交接。

透過這個比喻你會理解為什麼 SAA-C03 考題裡，「fault-tolerant + 最低成本 + 多種 instance type」幾乎等於 mixed-instances policy with Spot fallback 的標準答案。

EC2 執行個體家族 — 為彈性運算擴充選擇正確的機型

彈性運算擴充的第一步是選對執行個體機型。若底層執行個體家族選錯，任何擴充政策都救不了你。SAA-C03 要求你能依家族字母將工作負載特性對應到正確執行個體家族。

通用型 — T 與 M 家族

• T 家族（T3、T3a、T4g） — 可爆發的通用型。基礎 CPU 較低；閒置時累積 CPU credits，爆發時消耗。適合低流量 Web 伺服器、開發/測試環境、CPU 平均使用率低但偶爾爆發的微服務。T4g 使用 AWS Graviton。
• M 家族（M5、M5a、M6i、M6a、M6g、M7g、M7i） — CPU 與記憶體均衡。適合生產環境 Web 應用程式、小型資料庫，以及 CPU 或記憶體需求都不特別突出的後端服務的首選家族。

運算最佳化 — C 家族

• C 家族（C5、C5n、C6i、C6g、C6gn、C7g、C7i） — 每元最高 CPU 效能。批次處理、HPC、科學模擬、影片編碼、廣告投遞、遊戲伺服器、高吞吐量 Web 伺服器。C6gn 提供 100 Gbps 網路。許多 C 家族 SKU 可在 AWS Graviton 上取得。

記憶體最佳化 — R、X 與 z 家族

• R 家族（R5、R5a、R6i、R6g、R7g） — 高記憶體對 vCPU 比，適合記憶體快取、即時分析、ElastiCache 自管、中型資料庫。
• X 家族（X1、X1e、X2、X2idn、X2iedn） — 極高記憶體（最高約 4 TB）。SAP HANA、大型記憶體內資料庫、工作集龐大的 Apache Spark。
• z 家族（z1d） — 高頻 CPU 加上高記憶體，適合具單執行緒授權限制的關聯式資料庫。

儲存最佳化 — I、D 與 H 家族

• I 家族（I3、I3en、I4i、Im4gn、Is4gen） — 高本地 NVMe IOPS。NoSQL 資料庫（Cassandra、MongoDB）、OLTP 交易儲存。
• D 家族（D2、D3、D3en） — 高密度 HDD 本地儲存。MapReduce、分散式檔案系統、日誌處理。
• H 家族（H1） — HDD 與運算均衡，適合大數據工作負載。

加速運算 — G、P、Inf、Trn、F 家族

• G 家族（G4dn、G4ad、G5、G5g） — 圖形 GPU，適合遊戲串流、具成本效益的 ML 推論。
• P 家族（P3、P4、P5） — 高端 NVIDIA GPU，適合 ML 訓練與 HPC。
• Inf（Inf1、Inf2） — AWS Inferentia 晶片，專為 ML 推論設計。
• Trn（Trn1、Trn1n） — AWS Trainium 晶片，專為 ML 訓練設計。
• F（F1） — FPGA，適合客製化矽晶片加速。

AWS Graviton — ARM 架構執行個體

AWS Graviton 是 AWS 自研的 ARM 架構 CPU 家族（Graviton、Graviton2、Graviton3、Graviton4）。Graviton 執行個體類型名稱以字母 g 結尾——例如 M6g、C7g、R7g、T4g、Inf2（Inferentia 使用自有晶片，但運行在 Graviton 主機上）。對於範圍廣泛的工作負載，Graviton 相較同等級 x86 執行個體提供最高 40% 的性價比提升，尤其是 Web 伺服器、容器、Java/.NET 服務、開源資料庫與記憶體快取。

在 SAA-C03 中，遇到以下情境請優先考慮 Graviton：

• 在相容工作負載上「相同或更好效能下的最低成本」。
• 「容器化或無伺服器工作負載的最佳性價比」——AWS Fargate 與 AWS Lambda 都提供 Graviton 執行環境。
• 「永續/低碳運算」——Graviton 每單位工作通常消耗更少電力。

並非所有工作負載都能順暢移植——僅提供二進制的 Windows 應用程式、部分老舊 x86 函式庫或 GPU 密集訓練任務需要 x86 和/或加速器——但提到「在典型 Web 層或微服務上最低成本且不犧牲效能」的彈性運算擴充答案幾乎都涵蓋 Graviton。

EC2 購買選項 — 彈性運算擴充的成本層

彈性運算擴充不只是「跑多少執行個體」的問題，也關乎「如何購買」。SAA-C03 要求你熟練運用全部四種購買選項，以及合規用途的 Dedicated Hosts。

On-Demand — 預設選項

按秒計費（Windows 及部分 Linux 發行版按小時計），無需承諾。On-Demand 是無法預測工作負載的基準，也是 Spot 容量消失時的備援。當題目強調彈性與短期工作負載時，彈性運算擴充答案預設選 On-Demand。

Reserved Instances — 1 或 3 年承諾

Reserved Instances（RI）承諾 1 或 3 年，最高享有 On-Demand 72% 折扣。

• Standard RI — 折扣最高，但鎖定在特定執行個體家族、作業系統、區域（或可用區間的 Zonal 保留）。
• Convertible RI — 折扣稍低，但可跨家族、作業系統、租用模式進行兌換。
• Scheduled RI — 大多數使用情境已停用，SAA-C03 通常不考。

RI 是計費結構——自動套用於符合條件的執行中執行個體，不會主動為你啟動執行個體。在彈性運算擴充答案中，RI 覆蓋 Auto Scaling Group 的穩定基準層。

Savings Plans — 承諾每小時消費金額

Savings Plans 承諾 1 或 3 年的每小時消費金額，最高享有 72% 折扣。兩種類型：

• Compute Savings Plans — 適用於 EC2、AWS Fargate 與 AWS Lambda，不限執行個體家族、區域、租用模式或作業系統。彈性最高，折扣略低於 EC2 Instance Savings Plans。
• EC2 Instance Savings Plans — 折扣更高，但鎖定特定家族與區域。

對於混合 EC2、Fargate 與 Lambda 的現代彈性運算擴充設計，Compute Savings Plans 通常是 SAA-C03 偏好的答案，因為它能隨工作負載架構演進而靈活調整。

Spot Instances — 最高 90% 折扣

Spot Instances 使用 AWS 閒置容量，提供最高 90% 折扣。代價是：AWS 可在發出 2 分鐘中斷通知後收回執行個體。Spot 最適合可容忍中斷、無狀態或可設定檢查點的工作負載——資料處理、CI 建置、佇列後方的無狀態 Web 層、批次作業、渲染。

Dedicated Hosts 與 Dedicated Instances

Dedicated Hosts 提供實體伺服器，適用於 BYOL（自帶授權）或合規需求。Dedicated Instances 保證 VM 不與其他客戶共用實體硬體，但不暴露主機。兩者成本較高且降低彈性運算擴充的彈性；僅在授權或法規有明確要求時才選用。

EC2 Auto Scaling Groups — 彈性運算擴充的核心

EC2 Auto Scaling Group（ASG）是 AWS 上主要的彈性運算擴充原語。ASG 將多個 EC2 執行個體組成群組，以便作為單一機隊進行擴充、健康檢查與替換。

ASG 關鍵參數

• Minimum capacity — 下限。ASG 永遠不會低於此數量。
• Desired capacity — 目標值。ASG 主動將執行中的數量驅向此值。
• Maximum capacity — 上限。ASG 永遠不會超過此數量。
• Launch template / launch configuration — 新執行個體的藍圖。
• VPC subnets — ASG 在這些子網路（通常跨多個 AZ）中平衡分布執行個體。
• Health check type — EC2（預設，基於 EC2 狀態檢查）或 ELB（使用負載平衡器目標健康狀態）。
• Health check grace period — 啟動後多久開始計算健康檢查；對啟動時間較長的工作負載至關重要。
• Termination policies — scale in 時決定終止哪個執行個體的規則（預設、最舊執行個體、最新執行個體、最舊 launch configuration、距下次計費最近、allocation strategy）。

AZ 平衡 — 彈性運算擴充附贈的高可用性

ASG 會自動在你指定的子網路（AZ）之間平衡執行個體。若某個 AZ 故障，ASG 會在剩餘 AZ 啟動替換執行個體以恢復期望容量。將跨多 AZ 的 ASG 與負載平衡器結合，高可用性就成為彈性運算擴充的自然副產品——這正是 Domain 2 韌性題目如此頻繁指向 ASG 的原因。

健康檢查與自我修復

若執行個體未通過 EC2 狀態檢查或 ELB 健康檢查，ASG 會終止它並啟動替換執行個體。自我修復是彈性運算擴充的重要優勢之一；正確的 SAA-C03 答案通常寫「具 ELB 健康檢查的 Auto Scaling Group」，而非「手動 EC2 執行個體搭配 CloudWatch alarm 在故障時替換」。

Launch Templates 與 Launch Configurations

Launch template（或已停用的舊版 launch configuration）告訴 ASG 如何啟動新執行個體——AMI、instance type、key pair、security groups、IAM instance profile、user data、block device mappings、network interfaces、metadata options 與 tags。

為何 Launch Templates 勝出

Launch templates 有版本控制，支援所有現代 EC2 功能（Spot 選項、Capacity Reservations、T2/T3 unlimited、Placement Groups、tag specifications、metadata v2 IMDSv2），且可被多個服務引用（EC2 fleet、Spot fleet、ASG）。Launch configurations 是舊版產品；AWS 明確建議所有新的彈性運算擴充工作以及預測性擴充與混合執行個體政策都使用 launch templates。

多版本與預設版本

你可以維護多個 launch template 版本（v1、v2、v3……）並將其中一個標記為預設。更新 ASG 的 launch template 版本就能推進 ASG，可選擇性搭配 instance refresh。

Instance Refresh

Instance refresh 逐步替換 ASG 中的執行個體，以採用新的 launch template 版本。你設定 MinHealthyPercentage（更新期間機隊必須維持的健康比例）與 WarmupSeconds（新執行個體被視為初始化的時長）。Instance refresh 是 SAA-C03 認可的，在不停機的情況下推進彈性運算擴充機隊的方式。

擴充政策類型 — 四種（加上預測性）家族

EC2 Auto Scaling 支援多種擴充政策類型，差異在於如何決定調整期望容量。SAA-C03 要求你能將情境對應到正確的政策類型。

目標追蹤擴充 — 現代預設推薦

目標追蹤擴充是現代預設選項。你選擇一個指標（CPU 使用率、ALB 每目標請求數、網路位元組進出，或自訂 CloudWatch 指標）與目標值（例如 50% CPU）。EC2 Auto Scaling 在背後建立 CloudWatch alarms，並調整期望容量使指標維持在目標附近。它能自我調節、設定容易，且對 scale-out 與 scale-in 的處理同樣對稱。

使用目標追蹤的時機：

• 可以用單一指標目標（CPU、每執行個體 RPS、自訂指標的平均佇列深度）表達工作負載目標。
• 希望設定後即可不管（fire-and-forget）的政策。

步進擴充 — 對 Alarm 突破的精細回應

步進擴充以多個階梯回應 CloudWatch alarm 突破：「若 CPU 50–70% 新增 1 個執行個體；70–85% 新增 3 個；85%+ 新增 5 個。」當流量爆發呈非線性時，它比目標追蹤更積極且精準。步進擴充的冷卻方式與簡易擴充不同——它使用執行個體暖機期間，讓上次擴充動作的效果計入指標計算。

使用步進擴充的時機：

• 流量爆發不均勻，且你需要分層回應。
• 需要精細控制每個突破層級新增的執行個體數量。

簡易擴充 — 舊版單步驟

簡易擴充觸發單一動作（新增或移除 N 個執行個體或一個百分比），然後等待 cooldown 期間（預設 300 秒）再回應下一個 alarm。簡易擴充較老舊，很少是 SAA-C03 偏好的答案——步進擴充或目標追蹤幾乎總是勝出。簡易擴充存在的主要原因是用來說明 cooldown 語意。

排程擴充 — 以時間為基礎

排程擴充在特定日期時間（或依 cron 排程重複）更改 min/max/desired。適用於可預測的每日、每週或季節性模式——「每個工作日 08:30 UTC scale up 至 20，18:00 UTC scale down 至 5」。排程擴充與目標追蹤互補：排程設定最低下限，目標追蹤處理偏差。

預測性擴充 — ML 驅動

預測性擴充使用以 14 天歷史負載訓練的機器學習模型，預測未來 48 小時的負載，並在預測需求到來之前預先提供容量。這是唯一主動 scale out 的政策類型；其他所有政策都是被動回應指標突破閾值。預測性擴充與目標追蹤完美搭配——預測性擴充設定基礎容量曲線；目標追蹤處理日內偏差。

使用預測性擴充的時機：

• 工作負載有明確的每日/每週模式（每天早上執行的批次作業、夜間尖峰的消費者應用程式、上班時間的企業應用程式）。
• 執行個體啟動時間夠長，以致被動擴充無法及時追上爆發。
• 希望在可預測的爆發中消除冷啟動延遲。

混合執行個體政策 — 多種 Instance Types 與 Spot Fallback

混合執行個體政策是彈性運算擴充與深度成本最佳化的交匯點。單一 ASG 可跨越多種 instance types，並混合 On-Demand 與 Spot 容量。

混合執行個體政策的組成

• LaunchTemplate — 基礎範本。
• Overrides — 替代 instance types 清單（可選擇性加上權重與子網路）：例如 m5.large、m5a.large、m5n.large、m6i.large、m6a.large、m6g.large。
• InstancesDistribution — 控制 On-Demand 與 Spot 的分配比例：
  • OnDemandBaseCapacity — ASG 必須維持的 On-Demand 執行個體絕對數量（基準可靠性）。
  • OnDemandPercentageAboveBaseCapacity — 基準之上的額外容量中必須是 On-Demand 的比例（例如基準之上 20% On-Demand + 80% Spot）。
  • SpotAllocationStrategy — capacity-optimized（SAA-C03 偏好的最低中斷率答案）或 lowest-price、capacity-optimized-prioritized、price-capacity-optimized。
  • SpotInstancePools — 使用 lowest-price 時要使用的 Spot 池數量。
  • SpotMaxPrice — 通常不設定，支付目前 Spot 市場價格。

為何多種 Instance Types 對 Spot 至關重要

Spot 可用性是以每種 instance type 每個 AZ 為單位。若你的 ASG 在單一 AZ 只能使用 m5.large，中斷就會連鎖。若你允許跨三個 AZ 使用 m5.large、m5a.large、m5n.large、m6i.large、m6a.large、m6g.large，你實際上有數十個 Spot 池可選擇，而 capacity-optimized 策略會挑選最不可能被中斷的池。這是實現穩定 Spot 密集彈性運算擴充的最大槓桿。

屬性型 Instance Type 選擇

現代 ASG 支援屬性型 instance type 選擇：你不必列出明確的 instance types，而是指定需求（vCPU 範圍、記憶體範圍、網路效能、架構、加速器類型），AWS 自動挑選相符的家族。屬性型選擇讓 ASG 在 AWS 發布新一代執行個體時仍具前瞻相容性。

Cooldowns、Warmups 與 Lifecycle Hooks

時間參數是彈性運算擴充中較常被忽略的另一半。

Default Cooldown

Default cooldown（適用於簡易擴充）為 300 秒。在任何簡易擴充動作之後，ASG 在 cooldown 結束前會忽略後續 alarm 突破。這能防止快速振盪——scale out 之後 scale in，接著又 scale out。

Instance Warm-Up（步進擴充與目標追蹤）

Instance warm-up 是不同的概念：它告訴 ASG 一個新啟動的執行個體需要多長時間才能有用（啟動作業系統、安裝應用程式、填充快取）。在暖機期間，ASG 把新執行個體計入容量，但會抑制其對指標的貢獻，使目標追蹤與步進擴充不會過度反應。

Lifecycle Hooks

Lifecycle hooks 在啟動（autoscaling:EC2_INSTANCE_LAUNCHING）或終止（autoscaling:EC2_INSTANCE_TERMINATING）期間，將執行個體暫停在等待狀態，讓你能執行自訂邏輯——設定管理、日誌排清、優雅關閉連線——在執行個體上線或消失之前完成。Lifecycle hooks 是在 scale in 之前排清連線而不遺失使用者工作階段的方式。

Scale-In Protection

Scale-in protection 將特定執行個體（或整個 ASG）標記為不可 scale in。適用於在其他無狀態機隊中的有狀態 leader，或部署期間。

Warm Pools — 消除啟動時間

Warm pool 保留一批已完成啟動、預備就緒的執行個體，以 Stopped 或 Running（已休眠）狀態待機。當 ASG 需要 scale out 時，它從 warm pool 取用——跳過緩慢的啟動 / user-data / 設定管理 / 快取填充流程——在數秒內而非數分鐘內將執行個體轉為 InService。

Warm Pools 是正確答案的時機

• 執行個體需要數分鐘才能啟動並有效運作（大型 AMI、大量 Java 暖機、大快取填充）。
• Scale-out 爆發陡峭，被動政策來不及追上。
• 你希望在可預測性較低的工作負載上獲得預測性擴充的效益。

Warm Pool 狀態

• Stopped — 成本最低（不計算運算費用），重新啟動最慢。
• Running — 重新啟動最快，但須承擔完整運算費用。
• Hibernated — 記憶體狀態保留在磁碟上；中等成本、快速重新啟動，需要支援休眠的執行個體。

Warm pools 與 lifecycle hooks 整合，讓你能在執行個體加入 warm pool 之前完成準備工作，而非在每次 scale-out 時重複執行——這是微妙但強大的彈性運算擴充模式。

Spot 中斷處理 — 在被收回時優雅縮減

Spot Instances 可節省最高 90%，但 AWS 可能收回它們。正確的 Spot 處理是 SAA-C03 的高頻考題。

2 分鐘中斷通知

AWS 決定收回 Spot Instance 時，會透過兩個管道發布通知：

• 執行個體 metadata，位置為 http://169.254.169.254/latest/meta-data/spot/instance-action，包含終止時間戳記。
• EventBridge，透過 EC2 Spot Instance Interruption Warning 事件。

你的應用程式有最多 2 分鐘的時間：

1. 停止接受新工作（從負載平衡器目標群組中取消註冊）。
2. 完成或設定進行中工作的檢查點。
3. 將狀態排清至持久性儲存（S3、DynamoDB、EFS、佇列）。
4. 乾淨地終止。

Capacity Rebalancing

啟用 CapacityRebalance 的 ASG 會對更早的 EC2 Instance Rebalance Recommendation 信號做出反應——AWS 暗示 Spot Instance 處於較高中斷風險（但尚未收到 2 分鐘通知）。ASG 提前啟動替換執行個體，使中斷真正發生時機隊不會低於容量。

結合 Spot 與 SQS 實現容錯

SAA-C03 標準的 Spot 友善模式：SQS 佇列 + Spot worker 的 ASG 搭配混合執行個體政策 + capacity-optimized allocation strategy + lifecycle hooks 在中斷時排清訊息並重新設為可見。此模式在不遺失工作的情況下容忍中斷，並最大化彈性運算擴充的成本節省。

Placement Groups — 彈性運算擴充的拓樸控制

Placement groups 控制你的執行個體在 AZ 內相對位置，這對延遲敏感或可用性敏感的彈性運算擴充至關重要。

Cluster Placement Group

所有執行個體集中在同一個機架/網路脊梁，以獲得最低的執行個體間延遲與最高吞吐量。適合 HPC、緊密耦合的分散式系統、低延遲市場資料。

Spread Placement Group

每個執行個體位於獨立的底層硬體上——每個 AZ 最多七個。適合小型關鍵機隊（有狀態 leader、授權伺服器），其中一個執行個體的硬體故障不應影響其他執行個體。

Partition Placement Group

執行個體分散在邏輯分區（每個 AZ 最多七個），各分區對應不同的硬體機架。供分散式資料庫（Cassandra、HDFS、Kafka）使用，使單一機架故障只影響一個分區。

彈性運算擴充與其他服務的整合

彈性運算擴充很少單獨運作。

與 Elastic Load Balancing 整合

將目標群組附加至 ASG；負載平衡器分配流量，ASG 替換不健康的目標。對 ASG 使用 ELB 健康檢查以確保應用層的活性。

與 SQS 整合 — 解耦 Worker 擴充

對於佇列驅動的工作負載，使用 CloudWatch 目標追蹤政策依自訂指標（ApproximateNumberOfMessagesVisible / GroupInServiceInstances）的每執行個體佇列深度 scale。這是「以 Spot worker 每小時處理一百萬則訊息」情境下的彈性運算擴充答案。

與 ECS Service Auto Scaling 整合

Amazon ECS 使用 Application Auto Scaling（獨立服務）對任務進行 scale——依 ECSServiceAverageCPUUtilization、ECSServiceAverageMemoryUtilization 或 ALB RequestCountPerTarget 等指標的目標追蹤、步進與排程政策。ECS Cluster Auto Scaling 接著透過 Capacity Providers 調整底層 EC2 ASG（EC2 啟動類型）。使用 AWS Fargate 時，沒有底層機隊需要管理——彈性運算擴充止於任務層級。

與 EKS 整合 — Cluster Autoscaler 與 Karpenter

Amazon EKS 使用 Kubernetes Cluster Autoscaler（對節點群組背後的 EC2 ASG 進行 scale）或 AWS Karpenter（直接啟動適當大小的 EC2 容量，比 Cluster Autoscaler 更快且更有效率）。Horizontal Pod Autoscaler 對 Pod 進行 scale；Karpenter 對節點進行 scale。兩者共同提供 EKS 原生的彈性運算擴充。

與 Lambda 整合 — 並行即擴充

AWS Lambda 透過自動生成額外的並行執行環境來 scale。你透過保留並行（限制函式並行以保護下游）和預留並行（預熱執行環境以消除冷啟動）控制彈性運算擴充。Lambda 可在數秒內 scale 到數千個並行呼叫，但每帳戶區域並行限制（預設 1,000）仍然適用。

與 AWS Batch 整合 — 作業驅動運算

AWS Batch 按需提供 EC2 或 Fargate 運算以排清作業佇列。它支援 On-Demand、Spot 以及自動選擇成本最佳化 instance types 的受管運算環境。對於長時間執行、令人尷尬地平行的工作負載，AWS Batch 是彈性運算擴充的答案。

彈性運算擴充必背數字

• ASG default cooldown：300 秒。
• Spot 中斷通知：2 分鐘（120 秒）。
• Predictive scaling 訓練窗口：14 天歷史資料。
• Predictive scaling 預測視野：48 小時。
• Lambda 預設帳戶並行：每區域 1,000（軟性限制）。
• Lambda 最大逾時：15 分鐘。
• RI 折扣：最高 72%（相較 On-Demand）。
• Savings Plans 折扣：最高 72%（相較 On-Demand）。
• Spot 折扣：最高 90%（相較 On-Demand）。
• Placement group spread 限制：每 AZ 7 個執行個體。
• Launch template 版本數：每個範本 10,000 個（軟性限制）。
• ASG 最大執行個體數：帳戶層級軟性限制（通常每個 ASG 2,500 個；可透過配額申請調高）。

彈性運算擴充常見考試陷阱

SAA-C03 以可預測的方式重複考驗彈性運算擴充陷阱。務必熟記。

陷阱一 — 水平擴充 vs 垂直擴充

若情境描述「應用程式使用單一大型資料庫且 CPU 偏高，需要快速增加容量」，垂直擴充（更大的 instance type）可能合適。若情境描述「在流量爆發下的無狀態 Web 層」，使用 ASG 水平擴充才是彈性運算擴充的答案。注意「無狀態」與「流量爆發」是水平擴充的信號。

陷阱二 — 目標追蹤 vs 預測性擴充

目標追蹤是被動的；預測性擴充是主動的。若題目描述「在每天早上尖峰之前預先提供容量」→ 預測性擴充。若描述「將 CPU 維持在 60% 附近」→ 目標追蹤。若情境允許，兩者可以結合。

陷阱三 — Cooldown 誤用

Cooldown 適用於簡易擴充；步進擴充與目標追蹤改用 instance warm-up。聲稱「增加 cooldown 使目標追蹤更平穩」的情境是錯的——目標追蹤正確的調節旋鈕是 InstanceWarmup。

陷阱四 — Launch Configuration vs Launch Template

Launch configurations 無法使用混合執行個體政策、無法指定多種 instance types，且不支援較新的功能。若答案需要混合執行個體政策、Spot 混合或屬性型選擇，launch template 是唯一正確的建構積木。

陷阱五 — Spot 用於有狀態工作負載

Spot 加上「不容忍中斷的有狀態資料庫」是矛盾的。正確的 Spot 模式是無狀態、以佇列為後端、可設定檢查點或已複寫的工作負載。預期會有將 Spot 與錯誤工作負載配對的誘導選項。

陷阱六 — 忽略 ASG 答案中的多 AZ

單一 AZ 的 ASG 喪失其韌性優勢。正確的彈性運算擴充答案會將 ASG 跨多個 AZ 部署——除非情境明確限制在單一 AZ（通常是授權或延遲的邊緣案例）。

陷阱七 — 沒有歷史資料就用預測性擴充

預測性擴充需要約 14 天的指標歷史資料。全新工作負載在累積訓練資料之前無法使用預測性擴充。生命週期早期的工作負載應先使用目標追蹤或排程擴充。

彈性運算擴充 vs 無伺服器 — 如何選擇

透過 EC2 Auto Scaling 實現彈性運算擴充並非永遠是正確選擇。SAA-C03 要求你識別 AWS Lambda 或 AWS Fargate 何時優於 ASG。

• 選 EC2 Auto Scaling 的時機：工作負載需要特定 instance types（GPU、裸機）、長時間執行的程序（> 15 分鐘）、請求間的持久性記憶體狀態、每主機的守護程序式工作負載、Reserved Instances 或 Savings Plans 折扣堆疊，或作業系統層級的控制。
• 選 AWS Fargate 的時機：你希望使用容器但不管理主機、工作負載變動使主機閒置、需要每任務計費粒度，或與 ECS/EKS 編排整合而不需管理節點機隊。
• 選 AWS Lambda 的時機：工作負載是事件驅動、短暫（< 15 分鐘）、突發性，且受益於零閒置成本計費，且不需要持久性連線。
• 選 AWS Batch 的時機：你有排隊的、長時間執行且令人尷尬地平行的作業，且可以容忍排程延遲。

最佳的彈性運算擴充結合了這些原語——React 應用程式在 CloudFront + API Gateway + Lambda（函式層級的彈性）、後端在 ECS Fargate（任務層級的彈性），以及 Spot 上的 AWS Batch 批次管道（作業層級的彈性）。

練習題模式 — 任務 3.2 情境

反覆演練這些彈性運算擴充模式，直到對應關係成為反射動作：

1. 「流量無法預測的 Web 層，必須在 AZ 故障中存活，且最小化成本」→ 跨多 AZ 的 ASG 搭配 CPU 或 RequestCountPerTarget 的目標追蹤，以及 Spot + On-Demand 基準的混合執行個體政策。
2. 「執行時間 3 小時的隔夜批次作業」→ 使用 Spot 的 AWS Batch，而非 Lambda。
3. 「每天早上 9 點的流量爆發需要 5 分鐘才能吸收」→ 預測性擴充 + 目標追蹤 + warm pool。
4. 「容器化無狀態 worker 的最低成本」→ ECS on Fargate Spot，或透過混合執行個體政策在 EC2 上使用 Spot 的 ECS。
5. 「需要自動替換不健康的 Web 執行個體」→ 具 ELB 健康檢查類型的 ASG。
6. 「HPC 需要最低的節點間通訊延遲」→ cluster placement group + C 或 Hpc 家族執行個體。
7. 「容錯的分散式資料庫節點機隊」→ partition placement group。
8. 「跨 EC2、Fargate、Lambda 的彈性折扣」→ Compute Savings Plans。
9. 「最高折扣，鎖定特定家族一年」→ EC2 Instance Savings Plans 或 Standard Reserved Instance。
10. 「執行個體必須在 scale in 前排清連線」→ EC2_INSTANCE_TERMINATING 上的 lifecycle hook。
11. 「啟動需要 10 分鐘，爆發無規律」→ Stopped 狀態的 warm pool。
12. 「Scale in 必須保護 leader 節點」→ 在 leader 執行個體上設定 scale-in protection。

彈性運算擴充與其他 SAA-C03 主題的邊界

彈性運算擴充（任務 3.2）與幾個相鄰主題有所接觸。請保持邊界清晰：

• vs 無伺服器與容器（2.1） — 任務 2.1 是「用哪種抽象層？」；任務 3.2 是「它如何 scale？」。Lambda 與 Fargate 在兩個主題中都出現，但角度不同。
• vs 高可用性與多 AZ（2.2） — 任務 2.2 是「它能在故障中存活嗎？」；任務 3.2 是「它能隨需求成長嗎？」。好的 ASG 答案同時滿足兩者。
• vs 成本最佳化運算（4.2） — 任務 4.2 著重採購決策（Spot、Savings Plans、RI）；任務 3.2 著重擴充機制。成本題傾向 4.2 框架；效能或彈性題傾向 3.2 框架。
• vs 訊息傳遞與解耦（2.1） — SQS 驅動的擴充是經典的彈性運算擴充模式，但佇列屬於訊息傳遞主題；worker 機隊是彈性運算擴充。
• vs 高效能資料庫解決方案（3.3） — RDS/Aurora 有自己的擴充原語（Aurora Serverless v2、讀取複本）。彈性運算擴充在運算層；資料庫擴充是獨立主題。

FAQ — 彈性運算擴充熱門問題

Q1. 在彈性運算擴充中，目標追蹤與步進擴充有何差異？

目標追蹤擴充將指標維持在選定的目標值——你選擇「CPU = 50%」，ASG 透過新增或移除容量自我調節。步進擴充以分層回應 CloudWatch alarms——「CPU 50–70% 新增 1 個，70–85% 新增 3 個，> 85% 新增 5 個。」目標追蹤是 SAA-C03 偏好的預設選項，因為它能自我調節且對稱；當你需要精確控制不同突破層級的回應幅度時，步進擴充才勝出。兩者都優於舊版的簡易擴充。

Q2. 在彈性運算擴充中，何時應使用預測性擴充而非目標追蹤？

當工作負載有已知且重複的模式（每天早上尖峰、每週批次執行、上班時間的商業應用程式）且執行個體啟動時間長到被動目標追蹤來不及追上爆發時，預測性擴充才是正確的彈性運算擴充選擇。預測性擴充使用 14 天的歷史資料預測未來 48 小時，並在爆發前預先提供容量。最佳做法是結合預測性擴充（設定曲線）與目標追蹤（處理日內偏差），使彈性運算擴充同時具備主動與被動能力。

Q3. 混合執行個體政策搭配 Spot fallback 如何運作？

混合執行個體政策讓單一 Auto Scaling Group 跨越多種 instance types，並混合 On-Demand 與 Spot 容量。你定義 OnDemandBaseCapacity（基準可靠性）、OnDemandPercentageAboveBaseCapacity（額外容量中必須保留 On-Demand 的比例），以及 Spot allocation strategy——capacity-optimized 是最小化中斷的偏好選擇。ASG 在你列出的 instance types 與 AZ 中挑選最不容易被中斷的 Spot 池，在保持容錯的同時提供最高 90% 的成本節省。混合執行個體政策需要 launch templates——launch configurations 不能使用。

Q4. 什麼是 warm pool？何時應該使用它？

Warm pool 是一批預先初始化的執行個體保留（以 Stopped、Running 或 Hibernated 狀態），ASG 在 scale out 時可直接取用，跳過啟動、user-data、設定管理與快取填充步驟。當執行個體需要數分鐘才能有效運作時——大型 AMI、大量 Java 暖機、大快取載入——warm pools 才是正確的彈性運算擴充答案。Stopped warm pools 幾乎不收費，可在一分鐘內重新啟動；Running warm pools 可在數秒內重新啟動，但須承擔完整運算費用；Hibernated warm pools 將記憶體狀態保留在磁碟上，成本中等，重新啟動速度快。

Q5. 在彈性運算擴充架構中，應如何處理 Spot Instance 中斷？

Spot 中斷處理需要三個層次：（1）監看執行個體 metadata（http://169.254.169.254/latest/meta-data/spot/instance-action）和/或 EventBridge EC2 Spot Instance Interruption Warning 事件上的 2 分鐘中斷通知；（2）在這 2 分鐘內停止接受新工作、完成或設定進行中工作的檢查點，並將狀態排清至持久性儲存（S3、DynamoDB、SQS）；（3）在 ASG 上啟用 CapacityRebalance，使其在 AWS 發送更早的 Rebalance Recommendation 時即啟動替換，縮短機隊容量不足的時間窗口。結合 SQS 驅動的 worker 模式與跨多種 instance types 和 AZ 的 capacity-optimized allocation，可獲得最大韌性。

Q6. Launch templates 與 launch configurations 有何差異？

Launch configurations 是 EC2 Auto Scaling 較舊的不可變藍圖。Launch templates 是現代的版本化替代方案，支援所有當前 EC2 功能（混合執行個體政策、Spot 選項、IMDSv2、Capacity Reservations、屬性型選擇、tag specifications）。AWS 官方建議所有新的彈性運算擴充工作都使用 launch templates。混合執行個體政策、預測性擴充與屬性型 instance type 選擇都需要 launch templates——launch configurations 不支援這些功能。

Q7. 容器在 ECS 與 EKS 上的彈性運算擴充如何運作？

對於 Amazon ECS，Application Auto Scaling 使用目標追蹤、步進或排程政策，依 ECSServiceAverageCPUUtilization 或 ALB RequestCountPerTarget 等指標對任務數量進行 scale。對於 EC2 啟動類型，ECS Capacity Providers 調整底層 EC2 Auto Scaling Group。對於 Fargate，不存在主機層級的 scale——彈性運算擴充止於任務層級。對於 Amazon EKS，Horizontal Pod Autoscaler 對 Pod 進行 scale，Kubernetes Cluster Autoscaler（由 EC2 ASG 支撐）或 AWS Karpenter（直接 EC2 配置）對節點層進行 scale。Karpenter 在現代 EKS 彈性運算擴充中比 Cluster Autoscaler 更快且更具成本效益。

Q8. 在彈性運算擴充中，水平擴充何時優於垂直擴充？

水平擴充（更多同規格的執行個體）更適合無狀態工作負載、線性擴充的架構、Spot 下的成本效益，以及抵抗單一執行個體故障的韌性。垂直擴充（更大的 instance type）更適合無法分片的有狀態工作負載（大型單節點資料庫）、網路分割成本昂貴的記憶體密集工作負載，或遷移期間的快速短期容量提升。在 SAA-C03 中，彈性運算擴充答案幾乎總是偏好在 ASG 中水平擴充——垂直擴充通常是誘導選項，除非情境明確描述無法分片的有狀態工作負載。

摘要 — 彈性運算擴充概覽

• 彈性運算擴充意味著透過 EC2 Auto Scaling（或 ECS、EKS、Lambda、Batch 對應方案）自動讓運算容量與需求匹配。
• 從選對 EC2 執行個體家族（T/M/C/R/X/I/D/G/P）開始，在相容工作負載上考慮 AWS Graviton 以獲得最高 40% 的性價比提升。
• 分層採購選項：Savings Plans 或 Reserved Instances 覆蓋穩定基準，On-Demand 覆蓋尖峰，Spot 搭配混合執行個體政策覆蓋可容錯的大量容量。
• 使用 launch templates（而非 launch configurations）、跨多 AZ 的 ASG，以及正確的擴充政策來驅動彈性運算擴充：目標追蹤作為預設，步進擴充用於分層回應，排程擴充用於已知模式，預測性擴充用於可預測尖峰且啟動時間長的情境。
• 使用 warm pools 消除啟動延遲，lifecycle hooks 排清連線，以及 CapacityRebalance 加 capacity-optimized allocation 最小化 Spot 中斷。
• 將彈性運算擴充與 ELB 結合用於流量分配，與 SQS 結合用於解耦 worker，與 ECS/EKS 結合用於容器，與 Lambda 結合用於事件驅動的爆發。
• 謹記陷阱：混合執行個體政策需要 launch template；Spot 需要容忍中斷；多 AZ 是韌性的必要條件；目標追蹤使用 instance warm-up，而非 cooldown。

掌握彈性運算擴充，你就能在 SAA-C03 的每個 Domain 拿分。同一套心智模型驅動韌性設計（Domain 2）、高效能架構（Domain 3）與成本最佳化（Domain 4）——這正是彈性運算擴充在整個 SAA-C03 學習計畫中槓桿效益最高的主題之一。