Amazon SAA-C03: 運算、Auto Scaling 與執行個體管理 — 學習指南

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

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

EC2 執行個體類型與 AMI

選擇正確的 EC2 執行個體系列是建構良好運算層的基礎，因為系列、世代和大小共同決定了 CPU 架構、記憶體與 vCPU 的比例、網路頻寬以及可用的加速器。通用型 (M6i, M7g, T-series) 適合平衡的 Web 層和混合型工作負載。運算優化型 (C7i, C7gn) 適合受 CPU 限制的模擬、編碼、批次處理和 Web 前端。記憶體優化型 (R7i, X2idn) 專為記憶體內資料庫和快取設計。儲存優化型 (I4i, D3) 專為 NoSQL、HDFS 和資料倉儲設計。加速運算型 (P5, G5, Trn1, Inf) 提供 GPU 或機器學習晶片。Graviton (字尾為 g) 執行個體對於可順利編譯至 ARM64 的向外擴展 (scale-out) 工作負載，通常能提供 20-40% 更佳的性價比。

T 系列是可高載的 (burstable)，預設為標準模式 (standard mode)，在閒置時累積 CPU 積分，並在高載期間消耗積分；當積分用盡時，效能會被節流至基準線。對於有不可預測尖峰的工作負載——例如小型 Web 層、開發/測試環境，或支援具尖峰流量前端的 Elastic Beanstalk 環境——處於無限制模式 (unlimited mode) 的 T 系列執行個體允許執行個體借用積分，並對超額的部分按每 vCPU 小時收取小額附加費，從而避免使用者可見的效能節流。這就是為什麼 CPU 短暫飽和的 Beanstalk 環境，通常是透過啟用無限制模式來解決，而不是升級到更昂貴的運算優化型系列。將 T 系列保留給真正具尖峰特性、平均負載低的工作負載至關重要：在標準模式下持續的 CPU 使用會在幾分鐘內耗盡所有積分。

垂直擴展 (在同一系列內更換為更大型號) 會受限於可用的最大執行個體，變更時需要停機，並會引入單一故障點，且無法將工作負載分散到多個可用區域 (Availability Zone)。每當負載變化顯著時，使用 Auto Scaling 群組進行水平擴展才是正確的解決方案。

黃金 AMI (Golden AMI) 將應用程式碼、執行環境和相依套件預先烘焙到根快照中，從而實現快速且具確定性的啟動——這在 Auto Scaling 回應流量尖峰時至關重要。每次啟動時都透過使用者資料 (user-data) 進行啟動程序 (bootstrapping)，會在最不該發生的時刻增加數分鐘的延遲。

儲存選擇：執行個體存放區 vs EBS、快照與快速快照還原

執行個體提供兩種儲存基底：執行個體存放區 (instance store) (連接到實體主機的暫時性 NVMe) 和 Amazon EBS (網路附加的區塊儲存)。執行個體存放區提供最低的延遲，但其資料會在停止、休眠、終止或硬體故障時被銷毀。將其視為持久性儲存是一個常見且危險的錯誤——它只適用於暫存空間、緩衝區、快取，或像 HDFS 資料節點這類在其他節點上存在複本的複製資料。持久性資料應存放在 EBS 上，並由儲存在 S3 中的快照進行備份。

快照一旦建立就是增量且獨立的，因此將快照還原到一個新磁碟區絕不會影響來源磁碟區。將大型生產資料集複製到測試環境的標準作法，是為來源磁碟區建立快照，再從該快照建立新的磁碟區。然而，從快照還原的磁碟區在首次讀取時會從 S3 延遲載入 (lazy-load) 區塊，這會導致顯著的 I/O 延遲，直到每個區塊都被「暖機」(hydrated) 完成。同樣的延遲載入問題也會影響從根快照較大的 AMI 啟動的新執行個體——它們在啟動後的幾分鐘內會顯得反應遲緩。

EBS 快速快照還原 (Fast Snapshot Restore, FSR) 消除了這種效能懲罰。在快照上針對 ASG 啟動執行個體的可用區域啟用 FSR，從該快照建立的磁碟區就能立即提供完整的預配置效能：

aws ec2 enable-fast-snapshot-restores \
  --availability-zones us-east-1a us-east-1b \
  --source-snapshot-ids snap-0123456789abcdef0

當向外擴展事件必須在幾秒鐘內而不是幾分鐘內增加容量時，這一點至關重要。

使用 ENA 和 EFA 的增強型網路

廣告所宣稱的網路吞吐量會隨執行個體大小而擴展，但只有在存在 Elastic Network Adapter (ENA) 驅動程式時才能實現。ENA 提供基於 SR-IOV 的增強型網路，在較新的執行個體上支援高達 200 Gbps 的速度。現代的 AMI (例如 Amazon Linux 2、近期的 Ubuntu、Windows) 都已內建並啟用 ENA；可使用以下指令進行驗證：

aws ec2 describe-instances --instance-ids i-0abc \
  --query 'Reservations[].Instances[].EnaSupport'

modinfo ena | grep version
ethtool -i eth0

若沒有 ENA，執行個體會默默地降級到較低的吞吐量和較高的抖動 (jitter)，無論選擇哪種置放群組 (placement group)，都會破壞任何低延遲的設計。

對於微秒等級的集體通訊——例如計算流體力學 (CFD)、氣象模擬、分子動力學、大型模型訓練——請加上 Elastic Fabric Adapter (EFA)。EFA 向 MPI 和 NCCL 公開一個作業系統旁路 (OS-bypass) 的傳輸層 (Libfabric)，從而完全繞過核心網路堆疊。EFA 只有在叢集置放群組 (cluster placement group) 內、於支援的執行個體類型 (如 c7gn、hpc7a、p5) 上才能發揮其優勢，並且需要 EFA 驅動程式以及相容的 MPI (Open MPI, Intel MPI) 或 NCCL 建置版本。

aws ec2 create-placement-group --group-name hpc-cg --strategy cluster
aws ec2 run-instances --instance-type hpc7a.96xlarge \
  --placement GroupName=hpc-cg \
  --network-interfaces InterfaceType=efa,DeviceIndex=0,SubnetId=subnet-abc

置放群組

置放群組 (Placement group) 控制執行個體的實體拓撲：

選擇錯誤會浪費此功能。Cluster 置放群組無法跨越 AZ — 其設計本身就是 AZ 內部 (intra-AZ)。由於每個 AZ 七個執行個體的上限，Spread 置放群組無法容納一百個 Web 伺服器。對於一個 40 節點的 Kafka 叢集，Partition 置放是正確的工具，而非 Spread，因為它能將複本的置放與容錯域對齊。為了一般的高可用性，不要將 ASG 限制在單一 AZ 的單一置放群組中 — 應將 ASG 分散到多個 AZ。

對於需要最低節點間延遲的串流分析或 MPI 工作負載，正確的組合是 cluster 置放群組加上啟用 ENA 的執行個體；cluster 置放群組減少了網路躍點數，而 ENA 則提供了實現該延遲優勢所需的每秒封包數容量。

Auto Scaling 群組與啟動範本

Auto Scaling 群組 (ASG) 是一個執行階段的單元，它根據三個整數 — MinSize、DesiredCapacity、MaxSize — 以及一個子網路列表，在一個或多個 AZ 中維持所需的 EC2 執行個體數量。ASG 本身不描述要啟動什麼；這由啟動範本 (launch template) 負責，它是啟動組態 (launch configuration) 的現代替代品。啟動範本支援版本控制、混合執行個體政策、Spot/On-Demand 混合、強制使用 IMDSv2、容量預留以及無限模式的 T-instances。一個啟動範本會參考一個 AMI、執行個體類型、安全群組、IAM 執行個體描述檔、使用者資料以及區塊儲存裝置對應。

典型的無狀態 Web 模式是 AMI + 啟動範本 + ASG + ALB。AMI 提供快速啟動；ALB (或用於 TCP/UDP 的 NLB) 分發流量並驅動健康狀態檢查；ASG 自動將新的執行個體註冊到目標群組中，並終止不健康的執行個體。多 AZ 部署 (至少兩個 AZ，對於仲裁系統則為三個) 是必要的 — 一個綁定到單一子網路的 ASG 無法在 AZ 中斷時存活，因為當該 AZ 受損時，ASG 本身無法啟動替代的執行個體。

MyASG:
  Type: AWS::AutoScaling::AutoScalingGroup
  Properties:
    MinSize: 2
    MaxSize: 20
    DesiredCapacity: 4
    VPCZoneIdentifier: [subnet-a, subnet-b]
    TargetGroupARNs: [!Ref AppTargetGroup]
    LaunchTemplate:
      LaunchTemplateId: !Ref AppLT
      Version: !GetAtt AppLT.LatestVersionNumber
    HealthCheckType: ELB
    HealthCheckGracePeriod: 120

擴展政策：目標追蹤、步階、排程、預測性

ASG 擴展有四種模式，每種模式解決不同的問題：

• 目標追蹤 (Target tracking) 選擇一個指標並將其維持在設定點附近 (例如 ASGAverageCPUUtilization = 50%、ALBRequestCountPerTarget = 1000)。它是自我調整的 — AWS 會管理警示並在指標偏離時調整擴展速度。這應該是預設的選擇。
• 步階擴展 (Step scaling) 根據指標超出範圍的程度，分級增加或移除容量，這在反應幅度必須與警示嚴重性成比例時很有用。
• 簡易擴展 (Simple scaling) 是舊版的功能：每個警示只進行一次調整，在冷卻期間會阻擋後續動作，不應在新設計中選擇。
• 排程擴展 (Scheduled scaling) 在 cron 指定的時間調整 MinSize/DesiredCapacity/MaxSize。
• 預測性擴展 (Predictive scaling) 使用長達 14 天的歷史資料進行機器學習，以預測接下來 48 小時的流量，並在高峰之前預先佈建容量。

動態擴展本質上是滯後的 — 它只有在指標超過閾值後才會反應，而新的執行個體需要數分鐘來啟動、註冊和暖機。對於一個企業內部應用程式，若所有使用者都在 09:00 上線，並在 ASG 擴展跟上之前經歷 2-3 小時的緩慢，那麼單獨使用動態擴展是錯誤的答案。在高峰前疊加排程動作，以在需求到來前提昇 MinSize 和 DesiredCapacity：

ScheduledAction:
  AutoScalingGroupName: web-asg
  ScheduledActionName: pre-sale-warmup
  Recurrence: "0 8 * * *"
  MinSize: 20
  DesiredCapacity: 30
  MaxSize: 200

然後讓目標追蹤來吸收剩餘的變動。當高峰的形狀穩定但其確切時間每天都在變動時，預測性擴展是正確的選擇。對於可預測的非生產環境關機 (例如開發環境在夜間和週末關閉)，一個在週五晚上將 desired=0, min=0 並在週一早上恢復的排程動作是最低開銷的解決方案 — ASG 本身就是排程引擎，不需要 Lambda 或 EventBridge 的黏合程式碼。

指標的選擇與政策的選擇同樣重要。CPU 指標適用於受 CPU 限制的 Web 工作負載，但對於從 SQS 拉取訊息的積壓任務驅動型 worker，您必須根據佇列深度而非 CPU 進行擴展：一個因 I/O 而被阻擋的 worker 可能只顯示 10% 的 CPU 使用率，而佇列中卻累積了數百萬條訊息。使用每個執行個體的 ApproximateNumberOfMessagesVisible，可以將其作為自訂指標公開，或透過內建的 SQSQueueBacklogPerInstance 目標：

backlog_per_instance = messages_visible / running_instances
target = acceptable_latency_seconds / avg_processing_seconds_per_msg

TargetTrackingConfiguration:
  CustomizedMetricSpecification:
    MetricName: BacklogPerInstance
    Namespace: MyApp/Scaling
    Statistic: Average
  TargetValue: 100

同樣地，對延遲敏感的 HTTP 層應追蹤 TargetResponseTime 或 RequestCountPerTarget；受記憶體、磁碟或下游延遲限制的應用程式應發佈一個能反映真正瓶頸的自訂指標。在 CPU 不是限制因素時根據 CPU 進行擴展，會精確地產生執行個體永不向外擴展、佇列無限制地增長，以及 ALB 回傳 5xx 錯誤的故障模式。

健康狀態檢查與生命週期掛鉤

ASG 預設使用 EC2 狀態檢查，這能捕捉到 hypervisor 的故障，但無法偵測到應用程式的故障。在 ASG 上啟用 ELB 健康狀態檢查，會將替換決策委派給負載平衡器的應用程式層級探測，這在作業系統正常但程序卡住時至關重要。請將 HealthCheckGracePeriod 設定得夠長，讓 user data 能執行完畢；否則，新的執行個體會在啟動過程中被終止，陷入循環。

負載平衡器的選擇會影響「健康」的定義：

一個只做 TCP 健康狀態檢查的 NLB 後方的 HTTP 應用程式，會繼續將流量導向一個雖然能接受連線但回傳 500 錯誤的執行個體。改用 ALB——或在 NLB 上設定 HTTP 健康狀態檢查——以恢復有意義的信號。

生命週期掛鉤 (Lifecycle hooks) 會將執行個體暫停在 Pending:Wait 或 Terminating:Wait 狀態，以便外部自動化程序可以介入操作。在啟動時，掛鉤可讓您在 ALB 開始傳送流量前，向組態管理系統註冊、預熱快取或拉取密鑰。在終止時，掛鉤可讓您清空連線 (drain sessions)、寫入日誌 (flush logs)，並從服務網格 (service mesh) 中取消註冊。掛鉤會發出 EventBridge 事件；處理程序必須呼叫 CompleteLifecycleAction，否則掛鉤會逾時並採用其預設動作 (CONTINUE 或 ABANDON)。

暖集區與休眠

對於那些在提供服務前需要載入大型模型、預熱快取或進行 JIT 編譯的應用程式來說，冷啟動時間是個實際問題。暖集區 (Warm pool) 是附加到 ASG 的一個預先初始化備用區：執行個體會啟動、執行啟動程序，然後被停止、保持執行或休眠，並保留在集區中，直到 ASG 擴展時取用。從集區中拉取執行個體可以省去數分鐘的啟動時間。

休眠 (Hibernation) 會將作業系統暫停到加密的 EBS 根磁碟區，這樣 JVM 堆疊、機器學習權重和作業系統分頁快取在恢復時就能立即回復。要求：加密的根磁碟區大小足以容納 RAM、執行個體 RAM ≤ 150 GB 且屬於支援的系列，並在啟動時設定 HibernationOptions.Configured = true。具有 PoolState: Hibernated 的暖集區結合了兩者——執行個體在停止時不收取運算費用，並能在幾秒鐘內恢復，且記憶體已填滿。當應用程式「需要很長時間載入記憶體才能開始運作」時，這是正確的模式。

不可擴展工作負載的自動復原

並非所有工作負載都能水平擴展。那些有 MAC 綁定授權、基於檔案的鎖定，或沒有共享儲存的記憶體內會話狀態的舊式應用程式，無法在多個執行個體上運行——啟動額外的節點會導致資料損毀或授權違規。對於這些應用，彈性來自於自動復原，而非向外擴展。

有兩種模式可行。一個針對 StatusCheckFailed_System 的 CloudWatch 警報，搭配 EC2 復原動作，可以在底層主機故障時，保留執行個體 ID、私有 IP、Elastic IP 和 EBS 附件。更簡單的方法是：一個橫跨多個可用區 (AZ) 且設定 MinSize=MaxSize=1 的 ASG，它會替換掉故障的執行個體，且與復原動作不同，它能夠在 AZ 故障中存活——前提是狀態已從根磁碟區外部化，或者 AMI 是可重建的。

負載平衡器與子網路放置

ALB 在 L7 運作，終止 HTTP/HTTPS，提供主機/路徑/標頭路由、HTTP/2、WebSockets，並整合 WAF/Cognito/OIDC。NLB 在 L4 運作，保留客戶端 IP，支援靜態 IP 和 TLS passthrough、PrivateLink，並能維持每秒數百萬個連線。Gateway Load Balancer 將第三方設備（如防火牆、IDS）插入流量路徑中。

子網路的放置是架構最常出錯的地方。一個面向網際網路的 ALB 必須附加到公有子網路——也就是有 0.0.0.0/0 路由指向 Internet Gateway 的子網路——在目標所在的每個 AZ 中都需要一個。目標本身則應留在私有子網路中。如果 ALB 被放置在私有子網路，或者「公有」子網路缺少指向 IGW 的預設路由，客戶端會遇到連線逾時。目標要能被連線，需要目標的安全群組在目標連接埠上，允許來自 ALB 安全群組的傳入流量；在同一個 VPC 內的 ALB 和目標之間不需要 NAT。

Client → IGW → ALB (public subnets, SG: allow 443 from 0.0.0.0/0)
              → Targets (private subnets, SG: allow 8080 from ALB-SG)

在 ASG 上啟用 ELB 健康狀態檢查，這樣不健康的目標會被替換，而不僅僅是取消註冊。跨區負載平衡（ALB 預設啟用，NLB 可選用）能均勻分配請求，無論每個 AZ 中的執行個體數量如何。Route 53 必須透過別名記錄 (alias record)（或跨多個 ALB 的加權/延遲政策）解析到 ALB——絕不要將 Route 53 指向單一 EC2 的 IP，因為故障的執行個體會持續接收流量直到 TTL 到期，而 ASG 替換的新執行個體會有不同的 IP。

購買模型與混合執行個體叢集

購買模型的選擇是降低 EC2 支出的最大槓桿，這與架構模式無關。

合理的策略是：將基準負載放在 Reserved Instances 或 Savings Plan 上，突發負載使用 On-Demand，容錯工作則使用 Spot。在 ASG 中，這會以混合執行個體政策來表示：

MixedInstancesPolicy:
  LaunchTemplate:
    LaunchTemplateSpecification:
      LaunchTemplateId: lt-0abc123
      Version: $Latest
    Overrides:
      - InstanceType: m5.large
      - InstanceType: m5a.large
      - InstanceType: m6i.large
      - InstanceType: m6a.large
  InstancesDistribution:
    OnDemandBaseCapacity: 4          # covered by Savings Plan
    OnDemandPercentageAboveBaseCapacity: 20
    SpotAllocationStrategy: price-capacity-optimized

多樣化執行個體類型可以加深 Spot 集區並減少關聯性中斷。price-capacity-optimized (或 capacity-optimized) 會在價格與集區深度之間取得平衡，使執行個體較不易被收回。

Spot 適用於無狀態、可設定檢查點、可重試或水平冗餘的工作負載：例如 ALB 後方的 Web workers、具備自動重試功能的 Batch 任務、Spark executors、CI runners。它不適合做為關鍵的全時服務、有狀態的主資料庫或沒有復原路徑的 leader 節點的唯一容量——兩分鐘的通知無法保證安全關機，而特定執行個體類型的關聯性全叢集回收是一種真實的故障模式。當需求明確指出「不得中斷」時，Spot 就不符合資格。

反過來的陷阱是將 RI 或 Savings Plans 應用於真正變動的工作負載：無論是否使用，您都需支付每小時的承諾費用，因此在 168 小時的承諾下，每週運行 40 小時的工作負載會浪費 76% 的預留。當考量的重點是容量本身——而非價格——（例如事件驅動的突增、災難復原），請使用 On-Demand Capacity Reservation：這是在 On-Demand 費率下，一個純粹限定於 AZ 範圍的保證，可與 Savings Plan 結合以獲得折扣。

無伺服器運算：Lambda 與 Fargate

無伺服器將容量管理的責任轉移到平台。Lambda 適合事件驅動、短期的工作：例如 S3 ObjectCreated 觸發器、DynamoDB Streams、低流量的 SQS 消費者、API Gateway 後端、以及膠水邏輯 (glue logic)。記憶體（128 MB – 10,240 MB）會按比例配置 CPU，因此向上調整記憶體通常能透過縮短執行時間來降低成本。硬性限制定義了其適用範圍：最長執行 15 分鐘、10 GB 記憶體、10 GB /tmp 空間、250 MB 未壓縮的部署套件（或透過容器映像檔達 10 GB）、6 MB 同步請求的 payload。使用 Lambda 進行 30 分鐘的影片轉檔、數小時的 ETL 或 GPU 訓練在架構上是錯誤的——函式會在工作中逾時，而重試邏輯只會加倍浪費。對於延遲敏感的路徑，可使用 Provisioned Concurrency 來緩解冷啟動和 VPC 附加 ENI 的初始化時間。

Fargate 無需管理 EC2 主機即可運行容器。當任務超過 15 分鐘、需要自訂執行環境，或適合 ECS/EKS 的編排但團隊不想管理容量時，Fargate 是正確的選擇。Fargate 的每 vCPU-小時成本比 EC2 Spot 昂貴，因此當穩定狀態的使用率高且可預測時，在 ECS 上使用帶有 Spot 的混合執行個體 ASG 會更便宜。對於突發或不可預測的流量，Fargate 的按秒計費則更具優勢。

對於跨多個 Lambda 的編排，Step Functions 優於透過 SNS/SQS 進行串連，因為它提供視覺化的執行歷史、重試語意、集中的錯誤處理和持久的狀態。Standard workflows 按狀態轉換計費，最長可運行一年；Express workflows 則針對高流量、短時間的事件處理進行了優化。

對於需要將成千上萬個參數化的容器化任務進行扇出 (fan-out) 的場景——例如基因組學、蒙地卡羅模擬、ETL——AWS Batch 會處理佇列、相依性解析、重試，並在受管理的 EC2、Spot 或 Fargate 上進行資源配置。任務會參考一個任務定義（包含容器 + vCPU/記憶體 + IAM 角色），而 Batch 會將它們以箱式打包 (bin-pack) 的方式部署到大小適當的執行個體上。Step Functions 經常在單一狀態機中編排 Batch、Lambda 和 ECS。

Elastic Beanstalk

Beanstalk 是一個受管理的 PaaS，它會根據應用程式套件來配置 ALB、ASG、EC2 執行個體，以及可選的 RDS。它支援滾動式 (rolling)、帶有額外批次的滾動式 (rolling-with-additional-batch)、不可變 (immutable) 和藍/綠 (blue/green) 部署，並與 CloudWatch 整合。擴展政策會以環境選項（指標、閾值、最小/最大值）的形式公開。由於 Beanstalk 預設使用可突增的執行個體類型，啟用 T-unlimited mode 是解決短暫 CPU 飽和問題的低成本方法。排程擴展操作可以像其他 ASG 一樣附加到由 Beanstalk 管理的 ASG 上。當團隊希望擁有標準的 Web 應用程式拓撲，而不想手動編寫 CloudFormation，且滾動式更新和版本化套件符合發布節奏時，應選擇 Beanstalk。

使用 Systems Manager 進行機群管理

SSH 和堡壘機的模式既脆弱，保護成本又高。AWS Systems Manager 可取代這些模式。只需 SSM Agent (已預先安裝在 Amazon Linux 2、Ubuntu、Windows 上) 加上一個授予 AmazonSSMManagedInstanceCore 權限的執行個體設定檔即可。

• Run Command 可在標記的機群上執行 shell/PowerShell，並提供整合的輸出。
• Session Manager 透過 AWS API 開啟互動式 shell — 無需輸入的 22 連接埠、無需堡壘機、完整的 IAM 驗證，且會談階段可記錄到 S3 或 CloudWatch Logs。
• Patch Manager 使用維護時段，依排程套用作業系統補丁。

aws ssm send-command \
  --targets Key=tag:Env,Values=prod \
  --document-name AWS-RunShellScript \
  --parameters 'commands=["yum -y update"]'

排程啟動/停止自動化

對於非生產環境中、必須在營業時間外關閉的 EC2 和 RDS，低維護成本的模式是 EventBridge Scheduler → Lambda。一條 cron 規則 (cron(0 19 ? * MON-FRI *)) 叫用一個 Lambda 來停止被標記的資源；另一條在 07:00 的規則則會啟動它們。

import boto3
ec2 = boto3.client('ec2'); rds = boto3.client('rds')

def handler(event, _):
    action = event['action']  # 'start' or 'stop'
    ids = [i['InstanceId'] for r in ec2.describe_instances(
        Filters=[{'Name':'tag:AutoStop','Values':['true']}]
    )['Reservations'] for i in r['Instances']]
    getattr(ec2, f'{action}_instances')(InstanceIds=ids)
    for db in rds.describe_db_instances()['DBInstances']:
        if any(t['Key']=='AutoStop' and t['Value']=='true' for t in db['TagList']):
            getattr(rds, f'{action}_db_instance')(DBInstanceIdentifier=db['DBInstanceIdentifier'])

這是無伺服器架構，沒有需要修補的機群，並可依標籤擴展。AWS Instance Scheduler 解決方案的作用相同。一個細節：已停止的 RDS 執行個體會在七天後自動啟動，因此停止排程必須週期性地執行以再次停止它。若再結合 ASG 的排程動作在週末將容量降至零，閒置時間的成本將趨近於零。

擴展運算相關的網路陷阱

NAT Gateway 的放置位置。 一個 NAT gateway 存在於單一 AZ 中。若一個橫跨三個 AZ 的機群，將所有輸出流量都路由到 us-east-1a 的單一 NAT，則來自 us-east-1b/us-east-1c 的每個封包都需支付跨 AZ 傳輸費用，並且當 us-east-1a 效能降級時，會完全失去輸出流量。正確的模式是每個 AZ 一個 NAT gateway，且每個私有子網路的路由表都指向其所在 AZ 的 NAT。這能將流量本地化，並移除單一 AZ 的故障模式。

NAT 執行個體。 隨著機群增長，單一基於 EC2 的 NAT 會成為頻寬和 PPS 的瓶頸，並且是個單點故障 (SPOF)。受管的 NAT Gateways 每個可擴展至 100 Gbps。對於 AWS 服務流量，VPC 端點 (Gateway 用於 S3/DynamoDB，Interface 用於其他服務) 可完全繞過 NAT，從而降低成本並消除擴展事件期間的飽和風險。

常見的設計陷阱

• 單一 AZ 的 ASG 無法在 AZ 中斷時倖存 — 務必掛載至少兩個 AZ 的子網路 (對於仲裁系統則為三個)，並保持 MinSize ≥ 2。
• 假設每個工作負載都能水平擴展。 持有狀態、單一寫入者或不可叢集授權的應用程式在 ASG 下會變得更糟。應先使用自動復原或進行重構。
• 對可預測的高峰進行反應式擴展 會產生「最初 2-3 小時反應遲緩」的症狀。應使用排程或預測性擴展來預熱。
• 當 CPU 不是瓶頸時，卻依 CPU 進行擴展。 應發佈一個能反映真正瓶頸的指標 — 例如佇列深度、回應時間、連線計數。
• 簡易擴展和啟動組態是舊版功能 — 應優先使用目標追蹤和啟動範本。
• 在 HTTP 應用程式上僅使用 TCP 健康狀態檢查 會讓故障的執行個體留在輪替中。應使用 HTTP 檢查 (透過 ALB，或 NLB 的 HTTP 模式檢查)。
• 將 Spot 用於有狀態或不可中斷的工作負載 — Spot 要求工作單元是可設定檢查點且可替換的。
• 在真正變動的工作負載上使用 Reserved Instances 或 Savings Plans — 未使用的承諾用量是純粹的浪費；應改用適當調整規模和 Spot 來降低成本。
• 將 Route 53 指向個別 EC2 的 IP — 應路由到 ALB 別名，這樣 DNS 才能反映機群的變動。
• 將執行個體儲存體視為持久性儲存 — 資料在停止、終止或主機故障時會消失。
• 忽略快照還原或 AMI 啟動後的延遲載入延遲 — 應在目標 AZ 中啟用 Fast Snapshot Restore。

所有領域 · 容器與編排 →

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

瀏覽 Amazon →