這個案例的核心責任是提供「極端可預期峰值」的容量設計參考點。Prime Day 是 Amazon 每年最大的單一行銷事件、發生時間提前數月公告、所有相依服務都能進入準備階段、是最接近「教科書版本的容量規劃」的真實場景。

觀察

2025 年 Prime Day 期間 AWS 主要服務的峰值數字（引自 AWS News Blog）：

服務峰值年增率
Amazon SQS1.66 億訊息 / 秒（新紀錄）-
AWS Lambda每日 1.7 兆次呼叫-
Amazon API Gateway1 兆次內部請求+30%
Amazon DynamoDB1.51 億 RPS、毫秒級回應-
Amazon ElastiCache每日 1.5 quadrillion 請求-
Amazon CloudFront3 兆次 HTTP 請求+43%
Amazon Kinesis Streams8.07 億 records / 秒峰值-
Amazon EBS20.3 兆次 I/O-
Amazon Aurora5000 億次 transaction-
Amazon SageMaker AI6260 億次推論請求-
Amazon ECS on Fargate每日 1840 萬個 task+77%
AWS FIS（混沌實驗）6800+ 次彈性測試8 倍於 2024

基礎設施層面：AWS Graviton 處理器承擔超過 40% 的 EC2 compute、部署超過 87,000 顆 Inferentia / Trainium AI 晶片、AWS Outposts 對機器人下達 5.24 億條指令（年增 160%）。

判讀

Prime Day 是「可預期極端峰值」的標竿。它的容量問題不是「會不會撐住」、而是「準備到什麼程度才划算」。對應主章問題節點：

  1. Capacity Planning（9.6）：年度活動的容量計算可以用歷史 baseline × 預期成長 × headroom 三項相乘、但 Prime Day 規模下、每一項的不確定性放大都會變成數百萬美金成本差異。Amazon 公開的年增率（API Gateway +30%、CloudFront +43%、ECS on Fargate +77%）顯示連 Amazon 自己每年的成長預測都不能直線外推。
  2. Performance Observability（9.8）：DynamoDB 「1.51 億 RPS、毫秒級回應」這種敘述同時包含吞吐與延遲、是 production-grade 容量地圖的最小單位。只說吞吐不說延伸分布、容量資訊不完整。
  3. Improvement Loop（9.9）：FIS 混沌實驗 8 倍於 2024 顯示 Amazon 把「在 Prime Day 之前主動製造失敗」當成必修課、不是事後檢討。這層投資跟容量規劃同等重要。

策略

這個案例可以抽出三個跨平台可重用的工程做法。

  1. 把可預期峰值寫進服務級 SLO：Prime Day 在 SQS / Lambda / DynamoDB / Aurora 都建立了內部 SLO baseline、平日跑在 baseline 之下、峰值是擴張到「設計容量」而不是「實驗容量」。這跟 9.12 SLO 與 Performance Budget 直接對齊。
  2. pre-scaling + scheduled capacity：CloudFront 43%、API Gateway 30% 的年增率都是 提前算進 容量計畫、不是當天 reactive 擴容。對應 EC2 Auto Scaling 的 predictive / scheduled scaling 模式。
  3. 事前主動製造失敗、不靠當天 reactive：FIS 8x 成長代表「在 Prime Day 之前 6800 次 chaos test」、把驗證成本前置到容量規劃階段。這條跟 06.4 Chaos Testing 形成閉環 — 06 講失敗模式驗證、09 講容量地圖、兩者在 Prime Day 級別的事件上必須一起做。

跨平台等效：GCP 的 Compute Engine MIG + Predictive Autoscaler、Azure 的 VM Scale Sets + Predictive Autoscale、Kubernetes 生態的 KEDA + Karpenter 都可以實作同樣的 pre-scaling 策略。差異是 vendor 整合度、不是工程概念。

下一步路由

引用源