All writing2026.09.22 · SAA-C03 · AWS Solutions Architect Associate · 1 min

AWS Compute and Elasticity: Match Runtime, Scaling Unit, and Failure Model

Choose among EC2, Auto Scaling, load balancers, containers and Lambda by control, workload shape and state.

Compute questions become easier when you separate runtime choice, scaling unit, traffic entry, and purchasing model.

Choose the runtime boundary

Requirement Start with
OS control, special agents, long-running process EC2
Containers with AWS-native orchestration ECS
Kubernetes API/ecosystem EKS
Containers without managing instances Fargate
Short event-driven work and minimal operations Lambda
Managed application deployment Elastic Beanstalk

Lambda has execution, package, concurrency, and networking constraints. Containers fit longer-running or portable processes. EC2 is appropriate when control matters enough to justify patching and capacity management.

Scale stateless compute across AZs

An Auto Scaling Group replaces unhealthy instances and adjusts desired capacity. Target tracking is the default for a stable metric; step scaling reacts by alarm severity; scheduled scaling handles known demand. Predictive scaling helps cyclical workloads. Keep session state outside instances when possible.

ALB routes HTTP/HTTPS by host, path, headers, or other Layer 7 rules. NLB handles very high-performance TCP/UDP/TLS and static IP requirements. GWLB inserts virtual network appliances. Health checks determine whether traffic should reach a target; they do not repair application data.

Price the workload shape

  • On-Demand: unknown or short-lived demand.
  • Savings Plans/Reserved commitments: steady baseline.
  • Spot: interruption-tolerant, checkpointable work.
  • Dedicated Host: host-level licensing or compliance.
  • Capacity Reservation: reserve capacity, not a discount by itself.

Exam lens: high availability means at least two failure domains plus health-based routing and replacement. A larger single instance is only vertical scale.

Review card

  • Runtime choice is a control-versus-operations decision.
  • ASG scales instances; ECS service scaling scales tasks.
  • ALB is Layer 7; NLB is Layer 4; GWLB inserts appliances.
  • Externalize state before horizontal scaling.
  • Match purchase model to predictability and interruption tolerance.

Compute 題先分成 runtime、scaling unit、traffic entry 與 purchasing model,就不會被服務名稱淹沒。

先選 runtime boundary

需求 優先想
OS control、special agent、long-running process EC2
AWS-native container orchestration ECS
Kubernetes API/ecosystem EKS
Container 但不管 instance Fargate
Short event-driven work、minimal operations Lambda
Managed application deployment Elastic Beanstalk

Lambda 有 execution、package、concurrency 與 networking 限制。Container 適合長時間或要 portability 的 process。當 control 的價值足以抵消 patching/capacity management,才選 EC2。

跨 AZ 水平擴展 stateless compute

Auto Scaling Group 會替換 unhealthy instance 並調整 desired capacity。穩定 metric 預設用 target tracking;依 alarm severity 調整用 step scaling;已知時間的需求用 scheduled scaling;週期明顯可考慮 predictive scaling。Session state 盡量不放 instance。

ALB 在 Layer 7 依 host/path/header 等路由 HTTP/HTTPS。NLB 處理高效能 TCP/UDP/TLS 與 static IP。GWLB 插入 network appliance。Health check 決定要不要送 traffic,不會修復 application data。

對齊 workload shape 與價格

  • On-Demand:未知或 short-lived demand。
  • Savings Plans/Reserved commitment:穩定 baseline。
  • Spot:可中斷、能 checkpoint 的工作。
  • Dedicated Host:host-level licensing/compliance。
  • Capacity Reservation:保留 capacity,本身不是 discount。

考試視角: High availability 需要至少兩個 failure domains、health-based routing 與 replacement。單台更大 instance 只是 vertical scaling。

複習卡

  • Runtime choice 是 control 與 operations 的取捨。
  • ASG 擴 instance;ECS service scaling 擴 task。
  • ALB Layer 7;NLB Layer 4;GWLB 插 appliance。
  • Horizontal scaling 前先 externalize state。
  • Purchase model 要對應 predictability 與 interruption tolerance。