AWS CodeBuild macOS 預留容量要幾台？2026 企業成本模型
📋 本文目錄
症狀：構建並不頻繁，但帳單仍按預留節點持續產生。
最快解法：不要按開發者人數買容量，先用峰值到達率、單次占用時間、可接受排隊時間與故障冗餘計算保底節點。
這套判斷適合正在為 AWS CodeBuild macOS 預留機群申請預算、又需要解釋節點數量與費用依據的企業 IT 或 FinOps 負責人。若你管理多個 iOS 專案，或正在比較固定預留容量、彈性遠端 Mac 與混合方案，本文也能用作季度容量檢視表。
先分清預留容量與實際構建需求
AWS CodeBuild macOS 使用預留容量機群；截至目前的官方文件，常規按需機群並不支援 macOS。預留節點在設定期間會持續產生費用，而且 macOS 執行個體存在最低使用時段要求。因此，「每天實際用了多少分鐘」不能直接等同於「應付多少費用」。詳細計費規則應以 AWS CodeBuild 官方定價頁 為準。
預留 Fleet 的容量，首先決定同一時間可以並行處理多少構建。它不是開發者人數的替代指標，而是以下四個輸入的結果：
| 容量輸入 | 你要從 CI 紀錄取得的資料 | 對節點數量的影響 |
|---|---|---|
| 到達率 | 各時段進入佇列的構建數量 | 決定峰值並行需求 |
| 占用時間 | 從開始執行到釋放節點的時間 | 決定每台節點的吞吐量 |
| 排隊目標 | 可接受的最長等待時間 | 目標越嚴格，保底容量越高 |
| 重跑與故障 | 失敗重跑、節點不可用與維護紀錄 | 決定是否需要額外冗餘 |
以一個時間窗為單位，可以先用變數估算常態保底容量：
常態工作量 W = 構建到達率 λ × 平均占用時間 t
保底節點 N_base = ceil(W ÷ 目標利用率 u) + 故障冗餘 R
這不是 AWS 的計費公式，而是你的容量規劃模型。λ 應取自 CI 歷史紀錄，t 應包含拉取依賴、編譯、測試、簽名與上傳；u 和 R 則要由排隊目標及維護政策決定。Fleet 容量與並行構建的關係，請對照 AWS 預留容量 Fleet 屬性文件。
平均利用率不能掩蓋固定時段的壅塞。例如全天平均看似寬鬆，但每日發布前集中湧入的 PR、回歸測試與簽名工作，仍可能讓佇列快速拉長。你應把工作日拆成日常時段、夜間回歸時段和發布時段，而不是只用月度平均數。
日常構建與發布峰值：固定節點還是彈性擴容？
日常 iOS CI/CD 通常由 PR 驗證、合併後測試與夜間回歸組成。它們的併發特徵不同：PR 可能短時間集中，夜間回歸則可能形成較長且可預測的工作窗。先將任務依到達時間和占用時間分組，再判斷哪一組真正要求常駐容量。
發布流程必須另外計算。TestFlight、正式發布、歸檔、簽名和上傳可能在同一時間競爭節點；若你只用日常 PR 的平均值規劃，正式發布時便會把風險轉化成排隊或重試。
| 處理發布峰值的方法 | 適合的負載 | 隱性成本與風險 | 判斷分數 |
|---|---|---|---|
| 長期增加預留節點 | 峰值頻繁且每次都要求即時處理 | 非峰值時段持續付費，空閒容量增加 | 2/5 |
| 提前調整預留機群 | 發布窗口固定、可預先排程 | 需要變更流程、驗證容量與回復原狀 | 3/5 |
| 使用外部彈性遠端 Mac | 峰值低頻、時間集中或專案數波動 | 需驗證 Xcode、簽名、網路與交付時間 | 4/5 |
| 混合容量 | 日常穩定、發布存在短時尖峰 | 需要維護兩套權限、日誌及故障處理 | 5/5 |
這裡的分數是決策排序，不是效能測試或節省比例。若發布高峰只偶爾出現，長期保留節點往往把短時成本變成整段週期的固定成本；若峰值頻繁且排隊會直接影響商業發布，則預留容量的可預測性更重要。
AWS CodeBuild 的專案環境、計算類型與其他設定，應按照 官方專案環境設定文件 逐項核對，不要把可配置項目誤當成自動彈性擴容能力。
發布高峰應增加節點，還是用遠端 Mac？
若發布任務每個週期都會在相近時間到達，而且排隊超過目標會阻塞正式交付，先保留能覆蓋日常加發布最低容量的節點。若發布日期不固定、專案數量快速變動，則先做遠端 Mac PoC，把真實構建、簽名和上傳流程跑完，再決定是否採用混合容量。
決策條件可以直接寫入採購審批：
- 若日常併發長期穩定，且保留容量的利用率符合你的財務門檻，則選擇最小預留機群。
- 若主要排隊只出現在低頻發布窗口，則先比較預留節點調整與遠端 Mac 彈性擴容。
- 若構建包含生產簽名、私網依賴或嚴格權限，則先建立獨立可信池，不要為了提高利用率直接共用普通驗證節點。
- 若單一節點故障會使交付完全中斷，則把備援節點、跨方案災備或可快速交付的遠端 Mac 納入成本。
- 若連續一個檢視週期都無法取得可靠的佇列與占用紀錄，則暫緩擴容，先補齊可觀測性。
多個 iOS 專案共享 Fleet：利用率與污染風險要一起算
共享 Fleet 可以把不同專案的閒置時間填補起來，但工作目錄清理不代表全域狀態已經隔離。Keychain、快取、憑證、環境變數、工具鏈版本和殘留程序，都可能影響下一個構建。這也是「多個 iOS 專案能否共用同一個 CodeBuild Mac Fleet」不能只用平均利用率回答的原因。
你可以先把專案分成三類：
- 普通驗證專案：沒有生產憑證，只執行測試或非正式打包，可在嚴格清理後共用。
- 受控發布專案：涉及 TestFlight、正式簽名或發布憑證，應限制可執行的專案與角色。
- 高敏感專案：涉及私網服務、客戶資料或特殊合規要求，應評估專用容量池。
共享後的成本不只包括節點費用，還要加上清理腳本維護、權限審計、失敗調查、快取策略和污染事故的恢復時間。若共享帶來的故障影響會拖慢多個專案，名義上的高利用率可能並不是真正的低 TCO。
IAM 權限應以最小必要權限設計，並把建立專案、修改環境和讀取憑證的角色分開；可參考 CodeBuild IAM 身分型存取控制文件。私網依賴也要確認代理、VPC 和出站限制，不能只因為節點能啟動便視為構建環境完整可用。
注意：清理工作目錄不是完整隔離證據。你至少要用一次成功構建、一次失敗重跑和一次憑證撤銷測試，驗證節點是否真的能回到可交付狀態。
私網依賴與生產簽名：把可信發布池獨立出來
VPC 連線、內部套件庫、Secrets Manager、簽名憑證和正式上傳權限，會讓「所有任務共用一個 Fleet」變成高風險選項。普通驗證池可以追求較高利用率，但可信發布池應優先考慮權限邊界、日誌完整性和故障回復。
建議分別計算兩個容量：
驗證池最低容量 = 驗證尖峰工作量 ÷ 目標利用率 + 驗證池冗餘
發布池最低容量 = 同時發布任務數 + 發布池冗餘
這兩個公式的變數必須取自你的歸檔、簽名、上傳、權限撤銷和失敗重跑紀錄。不要用開發者人數替代，也不要把普通測試的短占用時間套用到正式發布。CodeBuild 的可用執行環境會隨區域和運行時而異，應以 官方可用執行時清單 核對版本與映像邊界。
如果需要私網存取，還要將代理限制與出站路徑納入驗收；AWS 托管代理文件 可用來核對代理模式的限制。當發布池不能安全地接收不可信任構建時，寧可犧牲部分利用率，也不要讓隔離成本在事故後才出現。
災備與區域限制：不要只為成功構建付費
容量模型常漏掉三項時間：主機啟動等待、節點不可用期間，以及恢復演練耗時。這些時間不一定出現在成功構建的平均值中，卻會直接影響發布窗口是否能守住。
你要從企業紀錄確認：
- 節點進入不可用狀態後，多久能恢復構建；
- 維護時是否仍能保留最低交付能力；
- 目標區域是否支援所需的 macOS Fleet 與執行環境；
- 重新簽名、重新上傳和權限撤銷是否需要人工介入；
- 單一節點故障時，剩餘容量能否維持你的排隊目標。
AWS 也會在文件中區分 Fleet、區域與計算類型；請以 Fleet 區域與計算類型說明 作為區域核對依據。單節點機群無法同時滿足維護和持續交付時，你需要在備用節點、跨方案災備和遠端 Mac 之間作選擇，而不是把故障機率當成零。
若你正在比較實體 Mac 方案，可先參考 Mac mini 成本與價格計算方法，但不要把硬體價格直接代入 AWS CodeBuild 模型。兩者的運維、人力、交付方式和故障責任不同，應分開列項。
用場景矩陣決定預留、替代或混合容量
完成一個月的構建紀錄整理後，你可以按以下矩陣作初步結論：
| 負載場景 | 主要觀察 | 容量建議 | 否決條件 |
|---|---|---|---|
| 日常 PR 與回歸 | 到達率穩定、占用時間可預測 | 保留最小預留機群 | 排隊集中超過目標 |
| 版本發布 | 峰值短而集中 | 預留加彈性容量 | 生產簽名無法隔離 |
| 多專案共享 | 任務可信等級接近 | 共享驗證池 | 清理或審計無法證明 |
| 私網與正式簽名 | 權限、VPC、憑證受控 | 建立獨立發布池 | 單一故障會中斷交付 |
| 低頻或波動負載 | 大量空閒、峰谷明顯 | 先做遠端 Mac PoC | 需要固定實體介面或長期滿載 |
季度複核至少應由四個觸發器啟動：排隊目標失守、空閒率持續偏高、專案隔離要求改變，以及 Xcode 或構建映像升級。不要只在帳單上升時才檢查，因為低利用率和發布風險可能同時存在。
如果你的 AWS CodeBuild macOS 預留容量大部分時間閒置，固定機群的缺點是持續計費、容量難以按週期收縮，以及峰值之外仍需負擔維護和權限治理。遠端 Mac 方案則可能在區域、連線方式、簽名隔離和交付時間上有不同限制，不能只看租用單價。MacDate 的 遠端 Mac 裸機方案與週期租用資訊 可作為 PoC 的對照入口；你仍應用自己的 Xcode、簽名和恢復紀錄驗證，而不是直接假設能取代整個 Fleet。
因此，穩定且高利用率的負載適合保留最小預留機群；低頻負載應重新比較按週期租用遠端 Mac；峰谷明顯的團隊則先驗證混合容量。最有效的下一步，是先匯出一個月的 CodeBuild 佇列、占用、重跑與簽名紀錄，代入上述場景表，再決定是否進入 MacDate 遠端 Mac 容量驗收流程。