如何釋放 AWS EC2 Mac Dedicated Host？2026 檢查清單

症狀：Mac EC2 執行個體已終止，但 Dedicated Host 仍顯示已配置，主機清理和費用狀態不明。
最快解法：先保存需要的建置產物與日誌，再依 AWS 流程停止或終止執行個體；確認最低分配週期與釋放資格後釋放 Dedicated Host，最後核對主機狀態。

這篇適合準備關閉臨時 AWS EC2 Mac 建置環境的 CI 工程師，逐項檢查執行個體與 Dedicated Host 的收尾工作。
負責保存建置產物、快取及日誌的開發團隊成員，也可用下列步驟確認哪些資料必須先匯出。
若您負責後續 macOS 建置環境選型，可依工作是否需要持續運作，判斷要保留自管主機或改用其他方案。

先分清楚：停止、終止與釋放是不同狀態

AWS EC2 Mac 使用 Dedicated Host。停止或終止執行個體，不代表 Dedicated Host 已釋放；若只處理執行個體，主機仍可能保持配置。結束 AWS EC2 Mac 使用時，請分別驗收執行個體狀態、資料保存情況及 Dedicated Host 狀態，而不要只看 CI 任務是否已結束。AWS 說明 EC2 Mac 與 Dedicated Host 的使用要求。

收尾情境	執行個體處理	Dedicated Host 檢查重點
CI 暫停，稍後還要繼續使用	視需要停止執行個體	主機是否仍配置、後續是否仍需該環境
CI 已結束，但要保留環境	可先停止；確認資料與恢復方式	停止不等於釋放，確認主機仍在使用或配置的狀態
主機不再需要	保存資料後終止執行個體	確認沒有關聯執行個體，再按 AWS 流程釋放
釋放操作完成	確認相關執行個體已處理	核對 Dedicated Host 狀態及帳單記錄

AWS 說明了 EC2 執行個體終止後的資源處理方式；EBS 磁碟是否隨終止刪除，取決於磁碟設定，不能把「執行個體已終止」當成資料已備份或磁碟已妥善處理。查看 EC2 終止時的資源處理規則。

第一步：CI 收尾前先確認沒有工作仍在使用主機

先檢查 CI 佇列、執行中的工作與排程。確認沒有待執行或正在執行的流程依賴該 Mac 主機，再停用會派送新工作的設定。若只看到目前沒有建置在跑，卻沒有檢查佇列與排程，下一個工作仍可能在清理期間被派送，造成建置失敗或產物不完整。

我們建議把結束主機使用拆成兩個時間點：先停止派送新工作，再確認既有工作完成並收集結果。若團隊仍有待驗收的簽署或測試流程，先保留環境，待責任人確認後才進入終止步驟。

第二步：釋放前應保存哪些建置資料？

先列出不可輕易重建的資料，再決定保存方式。建置產物、測試報告、CI 日誌、故障診斷資訊，以及簽署所需的憑證或金鑰資料，應分別確認保存位置、存取權限與復原方式。簽署私密資料屬敏感資訊，不要為了方便而放入一般建置封存檔。

快取通常可以重新產生，但仍要確認重建成本與來源可用性；不要把「可重建」直接等同於「不必檢查」。若資料位於 EBS 磁碟，請先確認終止時的刪除設定；需要保留磁碟內容時，可依實際配置選擇保留磁碟或建立快照。AWS 說明如何在終止後保留 EBS 磁碟，並提供建立 EBS 快照的操作文件。

清理前至少核對以下項目：

建置包與測試結果已上傳至團隊指定的保存位置，並能由負責人讀取。
日誌與診斷資料已留存，足以追查未完成或失敗的建置。
快取已分類：哪些可以重新下載或產生，哪些仍依賴本機狀態。
簽署材料與機密已依團隊的安全流程保存，且沒有混入一般產物。
EBS 磁碟的保留或刪除方式，與資料保存要求一致。

第三步：停止或終止執行個體，依目標選擇

若只是暫停建置、之後仍會復用環境，停止執行個體可以保留環境；若工作已結束且不再需要該執行個體，則在資料保存完成後終止。兩者的目的不同，應先由 CI 負責人確認是否需要恢復原有環境，再執行操作。

AWS 對 EC2 Mac 的停止與終止有專門流程。請按照EC2 Mac 停止或終止指引處理，不要假設一般 EC2 的操作結果可以直接套用到 Mac Dedicated Host。停止後仍須檢查執行個體與主機的關聯狀態；終止後也要確認 EBS 磁碟的實際處理結果，而不是只憑終止操作已送出就往下判定。

EC2 Mac Dedicated Host 何時可以釋放？

AWS 規定 Dedicated Host 有最低分配週期；EC2 Mac 的最低分配週期為 24 小時，並須符合主機釋放條件。AWS 的 EC2 Mac 文件與Dedicated Host 計費說明可用來核對週期和計費規則。請以目前官方文件及實際主機狀態為準，不要把執行個體已停止當成最低週期已滿或主機已可釋放。

遇到釋放不成功時，先檢查是否仍有關聯執行個體、主機是否仍處於使用或轉換中的狀態，以及最低分配週期是否已完成。若畫面或 API 回傳的狀態不符合預期，應依 AWS 的主機狀態說明分流處理，不要反覆送出操作來代替狀態確認。查看 Dedicated Host 監控與狀態說明。

第四步：執行釋放並驗證主機狀態

Dedicated Host 釋放前，再次確認所有相關執行個體已按預期處理，且必要資料已保存。接著依AWS Dedicated Host 釋放流程，使用控制台或官方 CLI/API 操作。若透過 CLI 執行，先查詢主機識別碼與狀態，再對正確的主機送出釋放要求；避免在多個建置環境共用帳戶時，僅憑名稱或舊紀錄選取目標。

釋放要求送出後，重新查詢 Dedicated Host 狀態，確認結果已進入 AWS 文件定義的已釋放狀態。操作回應成功只表示要求已接受，不應取代最終狀態核對。再查看帳單或成本記錄，確認該主機的資源費用不再繼續累計；帳單呈現可能有時間差，因此不能只依當下頁面沒有新費用，就推斷特定帳戶的最終帳單結果。AWS Dedicated Host 計費說明是核對計費規則的依據。

按狀態分流的決策條件

若 CI 仍有待執行工作或資料尚未完成保存，則先停止派送並完成留存；不要終止執行個體。
若短期內仍需原環境，則停止執行個體並確認 Dedicated Host 狀態；不要把停止當作釋放。
若工作已結束、資料已保存、沒有關聯執行個體且符合最低分配週期，則按 AWS 流程釋放 Dedicated Host。
若釋放要求被拒或主機狀態仍不明，則回查關聯執行個體、主機狀態與官方釋放條件；在主機狀態確認前，不要標記收尾完成。
若主機已顯示釋放，則再核對帳單記錄；如仍看到費用，依費用項目與時間範圍查明來源，不要直接歸因於已釋放的主機。

第五步：決定下一次 macOS CI 要採哪種方式

完成 Dedicated Host 釋放後，按建置頻率與運維責任評估下一步。自管 AWS 主機可以延續既有流程，適合需要自行管理 CI 環境、主機狀態與資料保存的團隊；代價是要處理主機生命週期、閒置時段與釋放驗收。遠端 Mac 則適合希望按需取得 macOS 環境、但不想長期維護自管主機的工作；仍須確認所需軟體、網路連線方式及使用週期是否符合團隊要求。

若工作只在版本發佈或特定測試階段間歇執行，應把閒置時的資源管理列入選型；若建置節點必須持續在線，則要評估持續運行的管理方式與整體成本。可先查看 MergeMac 的 Mac 使用方案及可用地點資訊，再比對工作流程和連線需求。需要實體介面或必須由團隊自行控制硬體的情況，遠端租用未必合適；而若只是定期執行 Apple 平台建置，保留一台長期配置的自管 Dedicated Host，也可能帶來閒置管理與收尾負擔。

結束 AWS 主機使用時，最容易漏掉的不是終止按鈕，而是資料是否保存、Dedicated Host 是否仍配置，以及費用是否已停止累計。若清理後仍有定期 macOS CI 需求，但不希望每次自行處理 Dedicated Host 的狀態與生命週期，可評估租用 MergeMac 的 Mac 作為後續建置環境；若有長期、高負載或實體介面需求，則先核對自管主機是否更符合運維條件。