雲端主機規格怎麼選？用網站流量與應用類型估算 vCPU、記憶體與儲存

選規格最務實的方法，是先用保守的中等規格上線，再用監控數據往上或往下調整，而不是一開始就憑感覺選最大或最小的方案。雲端的好處就是可以事後調整規格，所以第一步的目標是「不要差太多」，而不是「一次選到完美」。本文提供一套估算方式：先判斷應用類型，再用流量估算負載，最後用壓力測試與監控驗證。

一、先認識四個規格參數

參數	意義	不足時的症狀
vCPU	虛擬處理器數量，決定可同時運算的工作量	回應變慢、CPU 使用率長時間接近滿載
記憶體	程式與快取可用的空間	程序被終止、頻繁使用交換空間導致變慢
儲存容量	系統與資料可用空間	磁碟滿載導致服務停止、無法寫入日誌
儲存效能與網路	讀寫速度、網路頻寬	資料庫查詢慢、下載速度被限制

不同業者的 vCPU 定義與效能不完全相同，同樣是「2 vCPU」，實際表現可能有差異；有些方案是共享 CPU，只在短時間內允許爆發，長時間高負載會被限制。要承受持續負載的服務，請選擇獨佔或有效能保證的規格。

二、依應用類型抓起點

個人網站與部落格（靜態或使用快取）：1 到 2 vCPU、1 到 2 GB 記憶體通常足夠，重點是搭配快取或內容傳遞網路。
使用內容管理系統的企業網站：2 vCPU、4 GB 記憶體是常見起點，因為資料庫與應用程式可能同機運行。
API 與後端服務：看每秒請求數與每個請求的運算量，運算密集的需要更多 vCPU；快取較多的需要更多記憶體。
關聯式資料庫：記憶體最重要，因為快取大小直接影響查詢速度；同時要選擇效能足夠的磁碟。
批次與資料處理：以工作完成時間為準，可以選較大的規格短時間完成，再關機，總費用不一定更高。
容器與微服務：先估算每個容器的資源需求，再算總和並預留餘裕。

以上是常見的起點，不是保證；實際需求取決於程式碼效率、資料量與使用模式。

三、用流量估算負載

可以用下面的粗略公式：

尖峰每秒請求數 ≈ 每日請求數 ÷ 86,400 × 尖峰倍數

示意計算（數字純屬舉例）：每日 200,000 個請求，尖峰倍數取 10（尖峰時段流量是平均值的十倍），則尖峰約為 200,000 ÷ 86,400 × 10 ≈ 23 個請求每秒。如果單一請求在一個 vCPU 上平均耗時 50 毫秒，一個 vCPU 理論上每秒可處理約 20 個請求，那麼需要至少 2 個 vCPU，再預留 30% 到 50% 餘裕，約 3 個 vCPU。

這種估算有很多假設，例如請求耗時與快取命中率，所以只能當作起點，之後必須用壓力測試驗證。

四、記憶體與儲存的估算

記憶體可以拆成：作業系統基本占用、應用程式執行環境、資料庫快取、其他服務。把每一項列出來，加起來之後保留約 20% 到 30% 的空間。例如作業系統 0.5 GB、應用程式 1 GB、資料庫快取 2 GB，合計 3.5 GB，加上餘裕，選 4 到 6 GB 的規格較為安全。

儲存容量則是：目前資料量 + 預估一年成長量 + 日誌 + 暫存檔 + 備份檔。許多雲端磁碟可以線上擴大容量，但縮小通常很難，所以初期可以保守，再依用量擴充。需要設定自動清理日誌與暫存檔，避免意外填滿磁碟。

五、用壓力測試與監控驗證

在測試環境用壓測工具模擬預期的尖峰流量，記錄 CPU、記憶體、磁碟與回應時間。
找出第一個到達瓶頸的資源，那就是升級的重點。
上線後觀察至少兩週的監控數據，包含平日與假日、活動與一般時段。
若 CPU 長期低於 20% 且記憶體使用不到一半，可以考慮降級；若尖峰常超過 80%，需要擴充或加入快取、負載平衡。

調整規格前，先用雲端主機每月費用試算比較升級後的費用差距，也要確認升級是否需要重啟與停機時間。

六、垂直擴充與水平擴充

垂直擴充是換更大的主機，簡單但有上限，也常需要短暫停機；水平擴充是增加主機數量並用負載平衡器分流，彈性高也提高可用性，但應用程式必須是無狀態的，並且要處理工作階段與資料共享。小型專案通常先垂直擴充，成長到一定規模後，再設計水平擴充。

七、常見錯誤

把「峰值」當成「日常」，買了長期閒置的大型主機。
只看 CPU，忽略記憶體與磁碟效能，結果資料庫成為瓶頸。
沒有設定磁碟容量警示，直到服務停止才發現。
把測試環境與正式環境用相同大型規格，增加不必要的費用。
沒有考慮資料庫與應用程式分機的網路延遲與跨區流量費。

八、一個完整的估算範例

以下是虛構的示意案例，說明如何把前面的步驟串起來。某家社群活動網站使用常見的網站框架與關聯式資料庫，預期每日 30,000 次瀏覽，每次瀏覽約產生 5 個後端請求（頁面、API、圖片處理等），活動報名期間流量會是平日的八倍。

每日請求數為 30,000 × 5 = 150,000。
平均每秒請求數為 150,000 ÷ 86,400，約 1.7；尖峰倍數取 8，則尖峰約 14 個請求每秒。
假設單一請求平均占用 CPU 80 毫秒，一個 vCPU 約處理 12 個請求每秒，因此尖峰需要約 1.2 個 vCPU，加上 50% 餘裕，取 2 個 vCPU。
記憶體：作業系統 0.5 GB、網站程式 1.5 GB、資料庫快取 2 GB，合計 4 GB，加餘裕後選 6 到 8 GB 之間的方案。
儲存：目前 20 GB，一年預估成長 30 GB，日誌與暫存 20 GB，合計約 70 GB，選 100 GB 並設定容量警示。

得出的起點是 2 vCPU、8 GB 記憶體、100 GB 磁碟。接著用壓測驗證，若尖峰 CPU 超過八成，就先加入快取或升級；若平日 CPU 低於兩成，則考慮降級。這個流程的價值，在於每個數字都有理由，日後調整時可以知道是哪個假設與現實不符。

九、規格與費用的取捨

規格不是愈高愈好。把規格提高一級，費用通常接近倍增，但效能不一定倍增，因為瓶頸可能在資料庫查詢、外部服務或程式碼本身。在加錢升級之前，先檢查：有沒有缺少索引的查詢、有沒有可以快取的重複運算、有沒有同步呼叫外部服務造成的等待。這些最佳化的成本常常遠低於升級規格，而且效果更持久。完成最佳化後再用雲端主機每月費用試算比較不同規格的費用，才是合理的順序。

十、雲端規格調整的實務提醒

調整規格時要注意幾件事：多數業者在變更虛擬主機規格時需要重新啟動，會有幾分鐘的停機，應選擇離峰時段並事先通知；變更規格後，原本綁定的固定 IP、磁碟與網路設定通常會保留，但還是要在變更前確認；若使用承諾方案，要先確認規格變更是否影響承諾的適用範圍。

另外，不同世代與不同架構的處理器，在價格與效能上差異很大。在同樣的 vCPU 與記憶體數量下，較新世代的類型通常有更好的效能價格比，值得在選型時比較。若你的軟體支援不同的處理器架構，也可以評估使用價格較低的架構，但要先測試相容性與效能，不要只看單價就決定。

十一、規格估算檢查清單

項目	要確認的事
應用類型	是運算密集、記憶體密集、還是輸入輸出密集
流量估算	平均與尖峰請求數，有沒有明確依據
資料量	目前與一年後的預估，以及成長速度
磁碟效能	資料庫與日誌是否需要較高的讀寫效能
餘裕	是否保留 30% 到 50% 的容量餘裕
監控	是否設定了 CPU、記憶體、磁碟與回應時間警示
調整計畫	達到哪個門檻時升級，誰負責，停機時間多久

把這張表填完，再去詢價或使用官方價格計算器，得到的報價會貼近實際需求，而不是憑感覺買來的規格。

常見問題

一開始應該選多大的規格？

選中等偏小的規格並設定監控，通常比選最大規格更合理，因為可以隨時升級，而多買的資源會持續計費。

記憶體不夠可以用交換空間代替嗎？

交換空間只能救急，效能會大幅下降，不適合長期使用。請增加記憶體或最佳化應用程式。

要不要先做壓力測試？

正式環境如果有明確服務水準要求，建議做。成本低的小網站，可以用上線後的監控逐步調整。

參考來源

Amazon Web Services — 執行個體類型與規格說明
Google Cloud — 機器類型與效能文件
Microsoft Azure — 虛擬機器大小文件