這篇整理事先知道會有大流量（行銷活動、檔期、上架、直播）時，容量規劃的規格與預算怎麼從同一份業務預估推出來。各節依序是：決策者問「要加多大」與會計問「要多少預算」各自要的是什麼；從業務預估到峰值請求量、再到各層要開幾台的換算鏈，每一個換算係數從哪裡來、預估的誤差怎麼用三點估計帶著走；從台數到費用區間的算法，包括擴容的計費時數、計費模式、跟著用量計費的項目與付款時點；給決策者的選項要附哪些數字、各自適合什麼條件；以及每次活動之後怎麼校準換算係數、沒有歷史資料時怎麼起步。峰值的形狀與倍率階梯在 峰值估算，計費模式與單位請求成本在 成本模型，活動前的準備時程、預先擴容的做法與值班在 9.11 高峰事件準備，這裡不重寫。

決策者與會計各自要的數字：規格與風險、金額期間與付款時點

事先知道的大流量，在活動之前通常會被問兩個問題，兩個問題要的數字不同：

• 決策者問要加多大：要的是規格與風險，也就是加到多少台、多大的資料庫，以及不加或少加時會發生什麼（回應變慢、排隊、下單失敗的比例），才能在幾個選項之間選。
• 會計問要多少預算：要的是金額、期間與付款時點，也就是費用落在哪幾個月、哪一筆是一次性的、哪一筆是每月經常性的、什麼時候從信用卡或帳戶扣走，才能編進預算、確認付得出來。

規格與預算各估一次時，決策者核准的規格與會計核准的金額會對不上：活動前一週才發現預算買不到核准的規格，或預算編了、規格卻不是照那個預算規劃的。同一份業務預估推出來的兩份數字，改一個假設（例如預估人數加倍）時會一起變，也一起被看到，所以兩份數字從同一份預估推。預算先定下來的情形，同一條換算鏈倒過來算：從預算推出買得到的台數，再推出能服務的峰值，超出的部分交給下面〈給決策者的選項〉裡的降級或等候室。

從業務預估到台數：換算鏈、換算係數的來源與三點估計

業務預估是活動負責人給得出來的數字：預計多少人來、集中在哪個時段。台數是工程要準備的數字：每一層要開幾台。兩者之間是一條換算鏈，前三步各用一個換算係數乘或除，第四步把台數對到機型與規格，上一步的輸出是下一步的輸入：

1. 業務預估 → 峰值時段的使用者數：預計來的人數，乘上集中在峰值時段的比例（下文稱集中比例）。預計人數要包含平常在同一時段就會來的訪客；不包含時，把平常同一時段的請求量加到第二步的結果上。集中比例依活動的形式差很多（限量搶購集中在開賣的頭幾分鐘、全館折扣分散在整天），要從同類活動的歷史量；峰值的形狀在 峰值估算。
2. 使用者數 → 到源站的峰值請求量：乘上每個使用者在峰值時段發出的請求數（下文稱每人請求數），再乘上到源站的比例（1 減去 CDN 的命中率），再除以峰值時段的秒數，得到源站每秒要處理的請求數。每人請求數從平常的流量模型量（流量模型建立）；活動期間的行為可能跟平常不同，例如延遲上升時使用者重新整理、客戶端重試，每人請求數會跟著變大。
3. 峰值請求量 → 各層的台數：除以一台在目標利用率下的每秒處理量，結果無條件進位成整數台。一台的處理量從壓力測試量（壓力測試工具與方法）；目標利用率指膝點處理量的比例（不是 CPU 使用率），設在膝點以下，留出的那段餘裕吸收秒級的波動與故障（峰值估算〈安全係數的數學根據在飽和曲線〉）。故障的單位常是一個可用區：部署在 N 個可用區、要承受掉一個時，剩下的主機會吃到原本 N ÷（N－1）倍的量，目標利用率要再壓低到這個比例以下。目標利用率每一層不同：資料庫這類有狀態、有鎖競爭的元件膝點來得早，它的目標利用率要取得比無狀態的應用伺服器低（各類元件留多少的討論在 9.6 容量規劃模型〈Headroom budget 設計〉，概念見 Headroom Budget 卡）。資料庫、快取、第三方 API 這些不一定能水平加台的層，要再乘上每個請求觸發幾次查詢或呼叫，並對照它們的上限；從延遲目標往下反推各層的方法在〈峰值估算〉的〈從業務指標反推各層峰值〉。
4. 台數 → 規格：台數、機型、資料庫規格、頻寬。

預估本身的誤差，這篇從目標利用率拆出來另外處理。〈峰值估算〉與 9.6 把預估誤差也算進膝點以下的那段餘裕（9.6 的〈Headroom budget 設計〉把預測的誤差列為 headroom 要涵蓋的第一項）；這篇改用下面的三點估計把它帶著走，所以目標利用率留下的餘裕只涵蓋秒級的波動與故障，用 9.6 的比例時要先扣掉預測誤差那一份，不重複算兩次。

換算鏈裡誤差最大的是集中比例與每人請求數：每台處理量是壓測量的，相對可靠；集中比例與每人請求數在沒辦過同類活動時是估的。這兩個係數各取三個值，保守（偏高）、預期、樂觀（偏低），高的配高的、低的配低的，整條鏈跑三次，得到峰值請求量的三點估計（Peak Forecast 卡寫的最壞、預期、最好三點）；活動負責人對預計人數也沒把握時，人數一樣取三個值配進去。保守那一點是每個係數同時取偏高值的組合，不是機率上的某個分位數：兩個係數彼此獨立時，同時偏高的機率比各自偏高低，保守點會偏寬；兩者正相關時（越集中的活動，使用者越會重新整理）就不會。搶購機器人、重試風暴與預料之外的爆紅會超過保守點，這要靠下面選項裡的回退方式處理。三點離預期要拉多寬，看同類活動的歷史：有幾次的歷史時，取歷史上實際值與預估值的偏差範圍；只有一兩次、或沒有歷史時，一次活動只是一個樣本，偏差範圍不可靠，要取得更寬（下面〈每次活動之後的校準，以及沒有歷史資料時的起步〉）。

示例（數字都是為了說明換算而設的）：預計 20 萬人來（已含平常同一時段的訪客），峰值時段是開賣的頭 10 分鐘（600 秒），不放 CDN、請求全部到源站。集中比例取 20%、30%、40%，每人請求數取 20、30、40。壓測量到一台應用伺服器在延遲開始上升時（膝點）約 420 請求/秒，目標利用率取 60%，約 252，取整成 250。

資料庫假設每個請求平均觸發 1 次查詢，壓測時 4,000 次/秒延遲開始上升，目標利用率取比應用層低的 50%，可以處理 2,000 次/秒，預期的 3,000 已經超過。實際要先從流量模型拆出讀與寫各佔多少：讀的部分用讀取副本或快取吸收，寫的部分要靠佇列非同步處理（Queue 緩衝）或更大的主資料庫。這次的瓶頸在資料庫，所以下面各個選項都要寫出資料庫那一層怎麼處理。

這條鏈的價值在每一步都看得到換算係數從哪裡來。決策者問「為什麼是 22 台」時，答案是一串可以逐項檢查的乘除，而且看得到保守那一點是哪幾個係數取了偏高的值。

從台數到預算：計費時數、計費模式、跟著用量計費的項目與付款時點

台數換成金額要決定幾件事：加開的資源計費多少小時、單價用哪一種計費模式，以及不跟著台數走的費用。給會計的是增量，也就是活動期間比平常多出來的費用，平常的費用已經在每月的預算裡：

• 計費時數：加開的資源從加開那一刻開始計費，到縮回為止。活動開始之前要提前多久加開（下文稱預先擴容，pre-scaling），有兩種起點：只依預熱（快取與連線先熱起來，快取的部分見 Cache Warmup；9.11 高峰事件準備〈Pre-scaling 策略〉寫的是 30 分鐘到 2 小時）與加開之後驗證規格的時間決定時，是活動前幾小時；照 9.11〈T-90 → T-0 準備時程〉在活動前兩天開始預先擴容時，計費時數從兩天前起算，換到的是更早發現開不出機器或規格不對、還有時間處理。配額申請、正式的壓測這些前置工作要提早好幾週排，它們不算在加開資源的計費時數裡。活動結束之後也不會當場縮回：要確認每秒請求數回到平常的水準、並維持一段時間；流量有日週期，觀察到隔天同一時段，才看得到是否有回流的使用者，所以示例取一個完整的日週期。增量費用＝加開的台數 × 單價 × 計費時數，加開的台數＝所需台數－平常的台數，所需台數不超過平常的台數時不加開。
• 預先擴容還是交給自動擴縮：峰值爬升得比自動擴縮的反應時間（指標取樣、開機、通過健康檢查，通常要幾分鐘，推論，各家沒有逐一查）還快時，例如開賣頭幾分鐘就爆量，容量要預先加開到峰值，自動擴縮只能吸收活動中段的變化。預先加開可以手動調高台數，也可以用排程擴縮（Scheduled Scaling）在指定的時間把自動擴縮的最小台數調高、活動結束後再調回，計費時數照排程的起訖時間算。預先加開時主機費用是固定的；交給自動擴縮時，主機費用是各時段的加開台數 × 單價 × 時數加總起來，上限是全程開滿保守點的台數，下限取決於擴縮的最小台數與預熱期間開了幾台。
• 計費模式：活動只有幾天，加開的部分照隨用隨付（on-demand）計。折扣型的預留（reserved instance、savings plan、承諾使用折扣 committed use discount）是一年起跳的承諾，只適合平常就用得到的基準負載（成本模型〈三種計費模式的最佳組合〉；savings plan 這類承諾模式在 計費模式理解〈承諾模式：用彈性換折扣〉）；為了一次活動買它，活動之後用不滿的部分照樣每月付。可被收回的執行個體（spot）單價低，但峰值正是那種機型最搶手、最可能被收回的時候，被收回時正好補不回來，所以不用在活動的服務容量上；它適合用在活動前產生壓測流量。
• 容量預留：它買的是「當天開得出機器」的保證，不是折扣，跟折扣型的預留是兩回事。預留期間不論有沒有用都照單價計費，所以它是計費時數的另一個起點：從建立預留那一刻算起，不是從加開那一刻。活動當天在那個可用區可能開不出機器時才需要它。例如 AWS 立即生效的容量預留（On-Demand Capacity Reservations）沒有承諾期、可以隨時取消，沒有折扣，算進隨用隨付執行個體的配額；未來日期生效的那一種有承諾期，取消可能收費（Reserve compute capacity with EC2 On-Demand Capacity Reservations，2026-10-27 讀）。各家預留容量的欄位名稱見 機型與映像檔：CPU 架構、核心與記憶體、計費模式與作業系統〈各家的欄位名稱：機型、可被收回、預留容量與映像檔〉。
• 資料庫那一層：加讀取副本照同一條式子算（加開的副本數 × 單價 × 計費時數）。垂直升級主資料庫不一樣：有些業者改規格要停機，升級與降回都要排在可以停機的時段，降回常常排在活動之後很久，計費時數從升級算到降回；儲存空間加上去之後通常縮不回來（例如 Amazon RDS 的文件寫「You can’t deallocate space」，Increasing DB instance storage capacity，2026-10-27 讀），要算成之後每月的經常性費用，給會計時跟一次性的費用分開列。
• 跟著用量計費的項目：出站流量＝活動期間的總請求數 × 平均回應大小 × 每 GB 單價，放 CDN 時分成 CDN 回應的那一段（照 CDN 的計價）與回源的那一段（依業者可能另外計費，推論，各家沒有逐一查）。它跟主機費用誰大取決於回應大小：平均回應到 MB 級（圖片、影片多的頁面）時，出站流量可能比主機費用還高。按請求計價的託管服務與 serverless（函式、API 閘道、按請求計費的資料庫）沒有台數，費用＝請求數 × 單價，三點估計直接影響的是金額；它們另有自己的爬升限制與帳號配額，要先查。另外還有按次計費的第三方 API（簡訊、金流、地圖）、負載平衡器依流量與連線數的計費、跨可用區的流量，以及私有子網路經由 NAT 閘道呼叫外部服務的處理費（這三項依業者，推論，單價沒有查），還有記錄與監控的資料量（流量變大時 log 也跟著變大）。
• 活動本身的準備費用：壓測本身也要開資源與產生流量，這筆費用在活動之前就發生。值班與待命的人力＝人數 × 時數 × 費率，時數含預先擴容與活動之後的觀察期；有夜間或假日值班時，這一項常常比雲端費用高。

示例（接換算鏈示例的數字，單價、平均回應大小與預熱驗證的時數都是為了說明而設的）：平常開 4 台應用伺服器，每台每小時 0.2 美元；提前 6 小時加開（預熱 2 小時加上驗證 4 小時）、活動 24 小時、觀察 24 小時，計費時數 54 小時；出站流量每 GB 0.08 美元，平均回應 50 KB。

出站流量那兩欄用的是全天每人請求數：示例借用峰值時段的 20、30、40，等於假設全天的 20 萬人每人都發出那麼多請求（不論是不是在峰值時段來的）；全天每人請求數本身是另一個要量的係數。這兩欄是活動當天的總量，給會計的增量要扣掉平常一天的出站流量。平均回應大小從存取紀錄（access log）的回應位元組數或 CDN 的報表量；出站流量的單價與每月的免費量查業者價目表的出站（data transfer out）那一項。改成在活動前兩天開始預先擴容時，計費時數變成 48 ＋ 24 ＋ 24 ＝ 96 小時，比示例多 42 小時，保守那一列的主機增量變成 18 × 0.2 × 96 ≈ 346 美元。

給會計的預算是選定選項（下一節）之後的數字：主機費用依選定的做法取固定值（預先加開）或區間（交給自動擴縮），加上資料庫那一層、跟著用量走的項目的區間，並寫出區間從哪幾個係數來。預算編在哪一點有兩種做法：編在保守那一點，活動中不必再核准，代價是編多了的部分要在活動之後退回或留用；編在預期那一點，並寫明超過時由誰核准追加，代價是超出時要有人在活動中當天核准。追加預算的流程跟不上活動時，編在預期那一點的代價是峰值超出時沒有人能及時核准，服務只能停在預算內的規格，或在沒有核准的狀態下超支。

金額還要對齊三件事。一是付款時點：隨用隨付的帳戶多半是月結後付，下個月初扣上個月的費用，預算的月份與扣款的月份差一個月，跨月的活動分在兩期扣；Google Cloud 的門檻扣款帳戶例外，活動中費用暴增、餘額達到付款門檻時就會扣款。二是幣別與稅：雲端多半以美元計價，預算以本地幣別編，扣款金額還會受匯率、稅金與信用卡海外交易手續費影響，給會計的數字要寫出匯率的假設與是否含稅。三是臨時加開資源對停損機制的影響：加開資源要先調高配額，最大花費速度跟著變大，停止之前的最大超支、觸發處置的門檻與信用卡額度都要依新的值重算，否則活動當天正常的流量就會觸發停損（花費超過門檻時，由程式或人停止資源）。這三件事的推算與各家的出處在 租用雲端主機之前的費用規劃：費用訊號的延遲、停止之前的最大超支、扣款的信用卡額度、配額與預算門檻的計算，以及停損停到哪一層。

給決策者的選項：規格、費用區間、不足時的後果、回退方式與適合的條件

決策者要的是選擇，所以給的是幾個選項，每個選項附同一組數字：規格（含瓶頸那一層）、費用區間、容量不足時會發生什麼、活動中發現不夠時能怎麼補，以及這個選項適合什麼條件。「不足時的後果」分兩個門檻寫成可以觀察的結果：峰值超過目標利用率下的處理量時，秒級的尖峰開始讓延遲超過目標；超過膝點時，延遲與逾時明顯上升，逾時的比例用壓測量。以上面的示例（各選項的資料庫處置費用記為 <資料庫處置的增量>，出站流量 16 到 32 美元的當天總量各選項都一樣）：

• 依保守那一點預先加開（應用伺服器 22 台，主機增量約 194 美元，加上資料庫處理到每秒 5,333 次查詢的費用）：兩個門檻是每秒 5,500 與約 9,200（22 × 420），峰值落在保守點以內時不必降級。預估準確時多出的容量沒用到，多付的是保守與預期之間的那一段。前提是配額已經核准到 22 台，資料庫那一層也在活動前處理好。適合下單失敗的營收損失與商譽代價遠高於多付的雲端費用時。
• 依預期那一點加開，超出的流量用降級處理（12 台，約 86 美元，加上資料庫處理到每秒 3,000 次的費用）：兩個門檻是每秒 3,000 與約 5,040（12 × 420）。峰值超過 3,000 時，關掉推薦、延後寄信，把核心交易維持在延遲目標內；觸發點設在目標利用率對應的處理量、不設在膝點，是讓降級在延遲開始上升之前就生效，目標利用率到膝點之間的那段餘裕除了吸收秒級的波動與故障，也留給降級開關生效的時間。峰值到保守點的 5,333 時，降級至少要卸掉約 6% 的請求才不會超過膝點，要卸掉約 44% 才回到觸發點；降級能卸掉多少，要在活動前量。雲端費用較低，但降級本身也有成本：用到被關掉功能的使用者看不到推薦、晚收到信，流失的轉換與客訴要算進去（9.7 成本邊界與 efficiency〈降級的成本邊界〉）。降級要先決定犧牲哪些功能、保住哪些（請求依優先等級卸除的做法在 9.15 無預警瞬時大流量：流量來源辨識、擴展緩衝、請求優先等級、准入控制、體積型攻擊與退路〈負載卸除與限流的分工、請求的優先等級〉），並在活動前演練過（9.11 的〈Game day 演練〉）：沒有事先定好順序的系統，超載時所有功能會一起逾時或失敗。適合核心交易與周邊功能能拆開、降級演練過的時候。
• 不加，超過容量的使用者進等候室（維持 4 台，主機增量 0，加上等候室的費用）：兩個門檻是每秒 1,000 與約 1,680（4 × 420），等候室依每秒 1,000 的容量分批放行（9.15 無預警瞬時大流量：流量來源辨識、擴展緩衝、請求優先等級、准入控制、體積型攻擊與退路〈准入控制：虛擬等候室（virtual waiting room）、waitlist 與事前註冊〉）。每秒 1,000 在資料庫的 2,000 以內，資料庫那一層不必處理。等候室本身是一項服務：用現成的要付方案費（例如 Cloudflare 的 Waiting Room 只在 Business 與 Enterprise 方案提供，Plans，2026-10-27 讀），自建要開發與壓測的工時。適合流量的商業價值不高、活動可以分批開放，而且等候室事前已經建好、演練過的情形；代價是排隊的使用者有一部分會離開。
• 改活動本身的形式，降低換算鏈的係數：事前登記、抽籤、分時段開賣可以降低集中比例，把落地頁做成 CDN 可快取的靜態頁可以降低到源站的比例。改的是業務端，費用多半比加機器低，代價是活動的形式要跟活動負責人談，有時會降低活動的效果。它可以跟前三個選項並用，先降係數再重跑一次換算鏈。

「回退方式」寫活動中發現不夠時要多久補得上：自動擴縮還有多少空間、手動加台要多久、配額還能不能再調；配額申請被拒或來不及核准時，加開的台數停在已核准的配額，依保守那一點加開的選項到不了；已核准的台數低於預期點時，依預期加開也到不了，超出的部分交給降級（能卸掉多少要在活動前量）、等候室與改活動形式。也要寫活動取消或延期時哪些費用已經發生：預先擴容與容量預留從開始那一刻計費，壓測與預付的第三方點數（例如簡訊）多半拿不回來。

決策者比較的是多付的費用，對上不足時的後果發生的機率與代價。不足時的代價可以估成：失敗或放棄的請求數 × 轉換率 × 客單價，再加上客訴與流失的使用者；比法在 成本模型〈過度與不足配置的經濟學〉。比期望值（代價乘上發生的機率）適合活動常辦、單次失敗可以承受的情形；比最壞情況適合一次失敗就會傷到商譽或違反合約、法規的情形。示例裡雲端費用只有數百美元，決策的金額多半落在人力與營收損失這兩項。

每次活動之後的校準，以及沒有歷史資料時的起步

換算鏈的準度來自校準：每次活動之後，把每一個換算係數的實際值記下來，跟事前的三點估計對照。〈峰值估算〉的〈用歷史倍率階梯推可預期峰值〉寫的是倍率與 headroom 的校準，9.11 的〈事後 retro〉寫的是活動後第七天回顧的時程；這裡加上的是換算鏈自己的係數：

• 集中比例：實際來了多少人、峰值時段佔了多少。
• 每人請求數：峰值時段實際的請求量除以峰值時段實際的使用者數。系統飽和或有等候室限流的時段，伺服器收到的是被服務的量，不是需求量，要用需求端的訊號還原（CDN 邊緣的請求數、等候室的排隊人數、被拒絕或逾時的次數）；因為延遲上升而重試、重新整理的請求要分開記，下次估算時才分得出需求本身與系統變慢造成的放大。
• 全天每人請求數：出站流量用的那一個，跟峰值時段的分開量。
• 每台處理量：活動中各層的實際利用率與延遲，對照壓測的數字；差很多時，代表壓測的情境跟真實的使用行為不一樣，下次壓測的情境要改。
• 單位請求成本：活動期間的實際增量費用除以請求量，拆成主機、資料庫、流量、第三方 API 各一項（單位請求成本的算法在 成本模型〈單位請求成本讓成本可歸因〉，費用怎麼歸因到各項在 成本監控與告警〈歸因是監控的地基〉）。帳務明細落後數小時到兩天，這一項要等活動之後幾天、帳務資料補齊再算，跟 9.11 的第七天回顧可以排在一起。

記下來的係數就是下一次活動換算鏈的輸入，也是平常評估「如果流量變成兩倍要多少錢」的依據。平常在單價或計費方式有變動時（業者調價、換機型世代、改用承諾方案），或至少在每次編下一期預算之前，用實際帳單重算一次單位請求成本；業務提出下一次活動的規模時，換算鏈直接拿最新的係數給出第一版的規格與預算。

沒有辦過同類活動、沒有歷史資料時，換算鏈裡最不確定的是集中比例與每人請求數。起步的做法有幾種，各自換到的依據與付出的代價不同：

• 拿相近的活動、公開案例或行銷端的數字當起點：換到一個有依據的初始值，代價是兩個活動的使用者行為不一定相同。拿來當起點的案例要先確認是同一類活動：限量搶購屬於開賣即爆、幾十分鐘結束的瞬間爆量，年度檔期屬於提前數月已知的可預期峰值，兩者的集中比例差很多（峰值估算 開頭的五種峰值形狀）。行銷端的漏斗數字也可以當依據，例如推播的發送數乘上開啟率，推播送出之後的幾分鐘是集中最高的時段。
• 先辦一次小規模的試辦（限量開賣、只對一部分使用者開放）：量到自己的集中比例與每人請求數，代價是要多辦一次、試辦本身的規模也要估。
• 把保守點的係數取得更偏高（三點的區間跟著變寬），並確保能在活動中補容量：自動擴縮與配額留有空間，活動中有人盯著，代價是規格與預算的區間變大。
• 壓測直接量「每台每秒能完成幾趟使用者旅程」：把瀏覽、加入購物車、結帳這一串請求當一個單位壓測，省掉每人請求數這個係數，代價是旅程的組成要先定義得夠接近真實。

這幾種常常一起用：用相近的案例或行銷端的數字估初始值，用試辦校正，剩下的誤差交給三點估計的保守那一點與活動中的補容量。