AWS re:Invent 2026 EC2 Mac 成本怎麼選

AWS re:Invent 2026 EC2 Mac 成本怎麼選，先看你的使用時間：持續高負載、深度使用 AWS 網路與自動化的團隊，優先評估 EC2 Mac；短期專案、低利用率或需要快速交付的團隊，應把雲端 Mac 租賃放進同一張成本表比較。本週先記錄每次構建的準備、執行、等待、清理和釋放時間，不要只抄 EC2 Mac 的標示單價。

正在估算 iOS CI 月度算力成本的團隊，適合從這裡開始。
如果你要臨時增加 Xcode 構建節點，或已使用 AWS 卻不確定 Mac 主機的完整成本，也可以直接套用下方公式。

最後更新於 2026 年 7 月 29 日。 AWS re:Invent 2026 已確認於 2026 年 11 月 30 日至 12 月 4 日 在拉斯維加斯舉行；本文資料核實自 AWS 活動頁、EC2 Mac 文件、官方定價頁與 EC2 Mac 常見問題。主題演講細節及新的 Mac 實例目前尚未公布，不把傳聞當作規格或價格依據。

re:Invent 2026 的已知邊界

AWS re:Invent 2026 的官方活動日期已公布，但 AWS 尚未確認會否推出新的 Mac 實例、調整區域供應，或改變 EC2 Mac 的計費規則。你可以先參考 AWS re:Invent 2026 官方活動頁，但不要因為會議即將舉行，就預先把未公布的硬體或折扣寫進預算。

目前可確認的 EC2 Mac 規則包括：

Amazon EC2 Mac 的計費單位是 Dedicated Host，不是一般虛擬機器執行個體。
Mac 主機只能以裸機方式使用。
On-Demand EC2 Mac Dedicated Host 的最短配置與計費週期是 24 小時。
每個 Dedicated Host 一次只能執行一個 Mac 執行個體。
EC2 Mac 不提供 Spot Instances；節省成本要另外研究 Savings Plans 或其他長期承諾方案。
停止或終止 Mac 執行個體後，底層主機仍可能需要執行清理流程，不能立即重新配置。

以上規則可在 Amazon EC2 Mac 官方文件、EC2 Mac FAQ 和 Dedicated Host 官方定價頁交叉核對。

這代表一件重要的事：你不能拿「實際編譯了幾分鐘」直接乘上每小時價格。真正需要計算的是從配置主機到完成釋放之間的完整占用週期。

EC2 Mac 與雲端 Mac 租賃的成本對照

先用下面這張表判斷方向。它不是價格表，而是避免你把不同成本模型混在一起。

決策維度	Amazon EC2 Mac	雲端 Mac 租賃
計費核心	Dedicated Host 的占用時間、儲存、網路及相關 AWS 服務	租賃週期、交付方式、使用權限及額外服務
最適合	長期、持續、高利用率的 iOS CI 或測試工作負載	短期專案、發布衝刺、低頻構建及臨時節點
AWS 整合	適合接入既有 VPC、IAM、日誌、儲存及自動化流程	需要確認是否能以 SSH、遠端桌面或 CI Runner 接入現有流程
閒置風險	24 小時最低占用會放大低頻任務成本	租期較短，但長租未使用時仍會產生固定成本
運維責任	你要負責映像檔、Xcode、Runner、磁碟及故障處理	你要確認交付後的權限、重建流程、支援範圍及資料清理方式
交付速度	受容量、區域、主機配置及自動化成熟度影響	通常更適合快速增加節點，但要先驗證環境是否符合要求
回收方式	需停止執行個體、等待清理，再釋放 Dedicated Host	依租賃商的交付與退租流程執行，合約條件要先看清楚

EC2 Mac 和租用雲端 Mac 哪個便宜？
沒有脫離工作負載的固定答案。若你每天都有大量構建，且現有 AWS 網路、權限與日誌系統已經成熟，EC2 Mac 可能省下跨平台整合和資料搬運成本。若每週只有零星構建，24 小時最低占用、等待配置及閒置時間可能令 EC2 Mac 失去價格優勢。

計費單位與完整占用週期

EC2 Mac 成本應該怎麼計算？
先不要從價格頁抄一個小時單價。你應該把一次工作拆成以下六段：

主機配置時間：Dedicated Host 從申請到可用的等待時間。
環境準備時間：啟動 macOS、安裝或驗證 Xcode、拉取依賴和設定憑證。
實際構建時間：編譯、單元測試、UI 測試、封裝及簽署。
佇列與等待時間：Runner 等待、依賴下載、測試裝置連線或人工審批。
清理時間：刪除暫存檔、清理 DerivedData、回收磁碟與匯出日誌。
釋放或重建時間：停止執行個體、等待清理流程，再釋放主機或準備下一次使用。

AWS 文件指出，Apple silicon Mac 的 scrubbing workflow 最長可能需要 4.5 小時；在清理完成前，不能重新啟動該 Mac 執行個體或在同一主機上啟動新的 Mac 工作。清理期間計費會暫停，但交付能力和下一次任務的等待時間仍然要放進風險評估。詳情可參考停止或終止 EC2 Mac 執行個體的官方說明。

建議使用這條公式：

text

每月完整成本
=
Dedicated Host 占用成本
+ 儲存成本
+ 網路傳輸成本
+ 日誌與備份成本
+ 憑證及安全工具成本
+ 運維工時成本
+ 閒置成本
+ 延期與故障的風險成本

其中：

text

Dedicated Host 占用成本
=
官方單價 × 實際配置及保留時間

text

運維工時成本
=
配置、升級、修復、清理、恢復所需工時 × 內部工時單價

填寫時不要用「本月成功構建次數」代替占用時間。更準確的記錄方式是：

text

一個 CI 工作的成本輸入
=
配置分鐘數
+ 準備分鐘數
+ 構建分鐘數
+ 等待分鐘數
+ 清理分鐘數
+ 釋放或恢復分鐘數

金額請直接從 EC2 Dedicated Host 定價頁和 AWS Pricing Calculator 重新輸入。區域、Mac 型號、計費模式或官方頁面更新後，原本的試算表都要重算，不要沿用舊文章或第三方報價。

閒置時間與低頻任務

低頻 iOS CI 最容易誤判。真正昂貴的部分，往往不是編譯速度，而是你為了幾次構建，讓資源在等待和維護階段保持可用。

常見閒置來源有四種：

PR 合併前，Runner 等待人工審批。
測試工作尚未開始，但 Xcode 和依賴已經準備完成。
發布日之前預留節點，實際沒有任務排入。
磁碟、憑證或 Runner 出錯後，主機暫停使用但沒有即時釋放。

短期 iOS 專案適合租 Mac 嗎？
如果專案只需要數週或一個發布週期，並且你無法確認每日利用率，先比較雲端 Mac 租賃通常更合理。租賃方案的價值不只是「每小時更便宜」，而是把主機配置、硬體採購、保固和部分環境準備轉成較容易預估的租期成本。

但租賃也不是自動更省。若你租用整月，卻只有發布前幾天使用，固定租期同樣會製造閒置成本。你要要求供應方說清楚：

租期是否可按日、按週或按月調整。
租期結束後資料如何清除。
是否可以保留或重建 macOS 環境。
SSH、遠端桌面、CI Runner 和簽署工具是否可正常使用。
故障時是否有替代節點和明確恢復時間。

如果你還在比較自購 Mac、雲端主機和租用方案，可以先閱讀 Apple 新機購買與 Cloud Mac 選擇建議，再把購買成本、折舊和管理時間補入同一張試算表。

運維工時與權限邊界

把運維工時列入成本，是 EC2 Mac 與雲端 Mac 租賃比較中最容易遺漏的一項。

EC2 Mac 由你負責的工作通常包括：

建立和更新 macOS 映像。
安裝 Xcode、Command Line Tools 及套件管理工具。
管理 Apple 開發者憑證與 provisioning profile。
修復 CI Runner、SSH 金鑰及權限。
清理 DerivedData、模擬器資料和暫存硬碟。
設定日誌、警報、備份及故障回復。
在 macOS 或 Xcode 更新後重新驗證整條 iOS CI 流程。

這些工作不一定會出現在 AWS 帳單，但會出現在 DevOps 或開發團隊的工時表中。

租賃方案則要把責任邊界寫清楚。你需要確認是「只提供一台可連線的 Mac」，還是包含基本環境交付、Runner 安裝、權限設定和重建支援。若供應方只交付硬體資源，Xcode、簽署、測試和 CI 故障仍然由你處理，成本不能只看租金。

建議你在驗收時勾選：

[ ] SSH 或指定遠端連線方式可用
[ ] macOS 版本符合目前 Xcode 要求
[ ] Xcode 可啟動並完成一次空白專案構建
[ ] CI Runner 可連線、排隊及回傳日誌
[ ] Git、套件來源及私有儲存庫可正常存取
[ ] Apple 簽署流程不會把長期憑證明文放在主機
[ ] 磁碟清理後仍有足夠空間完成下一次構建
[ ] 故障時有重建或替代節點方案
[ ] 租期結束後可以刪除專案資料和登入憑證

如果你正在用自動化工具建立 iOS 應用，也可以參考 Claude Code 製作 iOS App 的發布驗證清單，把「能否構建」與「能否安全交付」分開驗收。

AWS 整合與網路成本

EC2 Mac 的主要優勢之一，是可以靠近你已經使用的 AWS 服務。若原始碼、套件快取、建置產物、日誌和身份管理都在 AWS 內，EC2 Mac 可以減少跨平台搬運和額外連線設計。

但這個優勢必須有實際使用情境，不能重複計價。

你可以分成兩類判斷：

值得計入 AWS 整合價值的情況

CI Runner 必須接入既有 VPC 或私有子網路。
建置產物需要直接寫入既有儲存服務。
團隊已使用 IAM、CloudTrail、集中式日誌及警報。
需要用既有自動化流程配置、停止和釋放主機。
安全政策要求建置資料留在既有雲端邊界內。

不應過度估值的情況

專案只需要短時間遠端使用一台 Mac。
原始碼和產物本身不在 AWS，仍要經由外部服務傳輸。
團隊沒有現成 VPC、身份、日誌或自動化管理能力。
為了「統一在 AWS」而額外建立大量網路、監控和權限設定。

對 iOS CI 而言，頻寬、套件下載、快取命中率和產物回傳都可能影響等待時間。你應記錄一次構建實際產生的輸入與輸出流量，再按區域和服務計價。不要把「使用 AWS」直接等同於「所有網路成本都值得支付」。

交付週期與延期風險

發布衝刺期間，便宜但不穩定的節點可能比稍貴但可快速恢復的方案更昂貴。

需要納入的風險至少有三項：

容量風險：需要 Mac 節點時，指定區域或型號未必立即可用。
配置風險：macOS、Xcode、憑證或 Runner 設定失敗，導致構建延遲。
恢復風險：主機停止後仍要等待清理；如果沒有備用節點，下一次任務會繼續排隊。

因此，請把下面的風險公式放進採購評估：

text

風險成本
=
預計受影響的工程師工時
+ 發布延誤損失
+ 臨時替代節點成本
+ 故障排查和重新驗證工時

如果你的團隊每月只有少量構建，但每次發布都不能等待，雲端 Mac 租賃的快速交付與替代節點能力，可能比單純比較小時價格更重要。

先試算，再決定方案

你可以在本週完成以下五步：

1. 記錄真實工作負載

連續記錄每次構建的配置、準備、編譯、測試、等待和釋放時間。不要只記錄 Xcode 顯示的構建時間。

2. 分離固定與變動成本

把 Dedicated Host、租期、儲存、網路、日誌和權限工具列為固定或變動項目。運維工時要另外列出，不要藏在「管理費」裡。

3. 核對 AWS 官方規則

至少重新確認 EC2 Mac 啟動流程、最短占用週期、可用區域、實例類型和現行價格。任何 re:Invent 公告、區域變化或定價更新，都應觸發重新試算。

4. 建立兩個相同週期的方案

用同一個月度工作量，比較 EC2 Mac 和雲端 Mac 租賃。不要拿 EC2 Mac 的小時價格對比租賃方案的月租；兩邊都要換算成完整占用週期。

5. 先做小規模驗證

如果利用率、交付速度或網路需求仍不明確，先使用小規模測試。測試目標不是找出一個看似最低的價格，而是量出構建等待、環境修復和釋放回收的真實時間。

最後可以用這個判斷：

持續高負載 + 已深度整合 AWS：優先評估 EC2 Mac。
短期專案 + 低利用率 + 需要快速交付：比較雲端 Mac 租賃。
利用率尚未確認：先做小規模試用，不要直接承諾長期主機或長租。
需要實體 USB、特殊測試裝置或固定本地環境：自購 Mac 仍可能更合適。
只需要臨時算力，且不想承擔主機維護：租賃方案通常更容易控制交付責任。

如果你目前使用的是一般雲端 Linux 或 Windows 伺服器，再透過額外方式補足 macOS 工作流，長期可能遇到環境不一致、簽署流程受限、遠端連線層增加和故障排查變長等問題。相較之下，Hashvps 的雲端 Mac 租賃更適合用來承接短期 iOS CI、發布衝刺和臨時測試節點；但對持續高負載、需要深度 AWS 私有網路整合的團隊，EC2 Mac 仍應保留在候選方案中。先把你的構建時長、閒置時間和運維工時填入公式，再依照雲端 Mac 租賃的驗收重點檢查交付品質，會比只看一個標示單價更接近真實成本。

re:Invent 2026 的已知邊界

EC2 Mac 與雲端 Mac 租賃的成本對照

計費單位與完整占用週期

閒置時間與低頻任務

運維工時與權限邊界

AWS 整合與網路成本

交付週期與延期風險

先試算，再決定方案

1. 記錄真實工作負載

2. 分離固定與變動成本

3. 核對 AWS 官方規則

4. 建立兩個相同週期的方案

5. 先做小規模驗證

為 iOS CI 預算選擇更靈活的 Mac 方案

獨享 Mac 雲端，物理原生 IP