GCP帳號充值方案 GCP項目Project刪除與重建流程：徹底清理垃圾資源免受持續扣費

第一章：為什麼「刪除專案」不等於「停止扣費」

很多人第一次接觸雲端的時候，直覺會是：專案刪掉了，資源就沒了，帳單也就停了。但在 GCP（Google Cloud Platform）上，現實通常更複雜。你可能已經把 Compute Engine 實例停掉、甚至刪掉整個專案，卻仍然在帳單或費用報表上看到支出。原因往往不是「付費系統壞了」，而是你沒有把所有可能的成本來源走完。

常見的情況包括：

• 刪除順序錯誤：某些資源需要先解除依賴（例如快照、映像、磁碟或防火牆規則），否則它們可能以不同形態留下，造成持續計費。
• 資源未真正刪除：控制台顯示「刪除中」或「已停止」，但實際上仍在清理佇列中。費用可能會以另一個計費單位持續出現一段時間。
• 賬單與專案關聯層級不同：你以為在某個專案刪了，但成本其實可能來自共享 VPC、連結的訂閱、或上層結構中的設定（例如某些服務在歸屬上不是你直覺的那個專案）。
• 欠缺最後驗證：刪除完就撤退，沒有回查「計費報表」或資源清單。結果是垃圾資源清了，但你沒證明；或清理漏了一小塊，後續仍產生微量扣費。

因此，所謂「刪除與重建」的流程，關鍵不是一鍵操作，而是建立一套可重複、可驗證、能排除依賴的步驟。本文以「徹底清理垃圾資源免受持續扣費」為目標，提供從事前盤點到重建回填的完整路徑。

第二章：刪除前的準備——先看成本來源，再動手清資源

真正有效的清理，不是盲刪，而是先弄清楚「錢到底花在哪裡」。否則你可能刪掉了一堆不相關的東西，卻漏掉真正產生費用的資源。

2.1 建立專案刪除前的基線資料（Baseline）

在執行刪除前，先把你目前的環境「記錄下來」，目的不是備份所有內容，而是確保你重建時能快速回到一致狀態，並且有依據判斷哪些資源確實被清理。

• 列出本專案的重要服務：Compute Engine、GKE、Cloud Storage、Cloud SQL、BigQuery、Pub/Sub、Load Balancing、VPC 與子網等。
• 記錄每個服務的主要資源：例如磁碟大小、快照數量、匯入的資料集、儲存桶類型與存儲量、排程任務與觸發器等。
• 如果你有 Infrastructure as Code（Terraform、Deployment Manager 或類似工具），先確認其狀態檔或版本記錄。
• 保存必要的網路配置：VPC、子網 CIDR、路由、防火牆規則與 NAT/Router 相關設定。

這些資料在你「重建」時會非常省時間；同時在你「清理」時也能用來對照：刪除後是否仍存在某些配置或依賴。

2.2 用費用報表定位「真正的扣費項」

在刪除資源前，先回到費用管理視角，把你最近 7 天或 30 天的支出拉出來。把支出按產品/服務、帳單分項、用量指標排序，通常你會很快看到哪一項在吃錢。

你要特別關注幾類容易被忽略的成本：

• 持久性儲存：磁碟、快照、影像、Cloud Storage 以及其存放類別（尤其是冷/歸檔類）。
• 資料查詢：BigQuery 的查詢成本或儲存成本（不一定會隨著你停止應用就消失）。
• 網路元件：NAT、Load Balancing、或特定的 egress/流量成本在某些情況下會不小心持續出現。
• 托管服務：例如 Cloud SQL 的備份、持久化連接或某些保留資源。
• 任務與排程：即使主要服務停掉，如果仍有排程任務或事件觸發器存在，也可能產生計費。

你不需要把所有費用項理解得完全深入，但至少要能指出「哪個服務在花錢」。這一步決定你後續刪除的優先順序。

GCP帳號充值方案 2.3 確認是否存在共享或跨專案依賴

在實務中，最容易出現的坑是：你以為某個東西屬於你的專案，但它其實在更上層的網路或共享架構裡由其他專案管理。常見例子：

• 共享 VPC：子網屬於服務專案，但宿主在 host 專案。
• 某些 IAM 角色授予與資源策略：雖不直接扣費，但會影響你刪除權限，導致刪除卡住或被迫手動處理。
• 資料集或儲存位置：資源可能被複製或同步到其他專案或區域。

如果你沒有確認，刪除時就可能遇到：你刪不掉、或刪掉後仍有依賴存在，導致其他資源不能完成清理。

第三章：刪除資源的正確順序——先拆依賴，再清主體

刪除垃圾資源，核心在於「拆依賴」。很多你認為已停止的服務，仍可能被某些資源引用，例如：

• 磁碟或快照被映像依賴
• GKE 的節點或工作負載持續佔用某些持久化卷
• Load Balancing 的後端服務依賴 instance groups 或轉發規則
• Cloud SQL 的備份與備援策略在停止主機後仍存在

因此，建議採用「先關服務→再刪實體→再刪殘留快照與依賴→最後刪專案或項目」的順序。

GCP帳號充值方案 3.1 先停止流量入口與計費觸發

如果你的專案仍在對外提供服務，刪除前先把流量入口停掉能降低不必要的持續消耗。這一步也能避免在你清理過程中仍有自動化流程產生新資源。

• 關閉負載平衡（轉發規則、後端服務、健康檢查）。
• GCP帳號充值方案 若有 API Gateway 或外部觸發，先停掉或暫時停用觸發器。
• GCP帳號充值方案 如果有 Pub/Sub 佇列或訂閱，先停用消費與發布（否則事件可能持續推送，帶動下游服務運行）。

這些通常不一定是主要費用項，但它們可能讓清理變成「刪了又長出來」。

3.2 關閉或降級計費服務，再刪除計費單元

以下提供一個通用的拆解邏輯。實際仍要依你環境調整，但流程思維要一致：

• Compute Engine / GCE：先停機或刪除 VM；再處理持久磁碟（刪 VM 不一定代表刪磁碟）；最後刪快照與映像（如果存在）。
• GKE：先刪集群或至少關閉節點池；再檢查持久化磁碟（Persistent Volumes）與快照；確認工作負載不會再自動擴縮或重建。
• Cloud Storage：刪儲存桶或刪除特定物件；檢查版本管理與保留策略（例如 bucket retention policy、物件保留、分層儲存分類）。
• GCP帳號充值方案 Cloud SQL / 其他資料庫：先停止或刪除實例；確認備份與自動備份是否保留；再刪掉相關快照。
• BigQuery：刪資料集或表；同時確認是否啟用了儲存或查詢相關的計費（刪資料集通常最直接）。
• NAT / 路由 / 防火牆：在刪 VPC 或子網前先移除不必要的網路依賴，如 NAT Gateway、Router，否則可能造成刪除受限或清理延遲。

如果你反過來先刪網路，再刪 VM，可能會遇到刪不掉或卡住，因為資源依賴仍存在。

GCP帳號充值方案 3.3 清理「殘留」：快照、映像、映像套用、版本與保留策略

垃圾資源最常躲在「看起來不重要」的地方，例如：

• 快照：你刪了磁碟，卻忘了快照；或刪了 VM，快照仍在。
• 映像與映像系列：用於模板的映像常被忽略。
• GCP帳號充值方案 Cloud Storage 版本：如果開啟物件版本，刪物件不一定等於立刻停止佔用存儲。
• 保留策略：有些 retention policy 會讓刪除被延後。

這些殘留通常是小額但持續的，最容易讓人覺得「怎麼還扣費」。建議在刪除主要服務後，針對快照、映像、儲存桶版本與保留策略進行二次盤點。

3.4 最後再刪專案：用「不可逆性」換取確定性

當你完成上述步驟後，再刪除專案或關閉資源。此時專案被刪除更可能代表資源清理能走完流程。刪除後你仍要做最後驗證（下一章會講），因為成本可能仍在清理佇列裡反映一段時間。

第四章：刪除後的驗證——用三層檢查確保真的停了

刪除不是句點，驗證才是。你可以把驗證理解成三層：資源層、計費層、權限與回收層。

4.1 資源層：確認沒有剩餘的可計費單元

在刪除流程完成後（或刪除中一段時間後），回到資源清單做抽查：

• 是否仍有磁碟、快照、映像
• 是否仍有儲存桶（含版本/保留策略）
• 是否仍有資料集或表
• 是否仍有負載平衡元件

若你能找到殘留資源，就代表還沒清乾淨。此時不要急著重建或開始新部署，先把殘留處理掉。

4.2 計費層：用報表確認「費用已不再累積」

費用通常不是即時更新，你需要等待一定時間才能看到真正停止。建議你以「按天」或「最近幾天」的方式觀察，判斷是否仍在增加。

驗證的邏輯是：

• 如果資源層都清完了，但費用仍持續增長，代表仍有你沒找出的依賴或跨專案成本。
• 如果費用略有延遲但不再增加，通常是清理佇列或最後一次結算造成的短暫反映。

同時要注意：有些服務即使你刪了主體，仍可能因為資料仍在回收流程中而產生短期費用。這不一定是錯，但你要確定「不再累積」。

4.3 權限與回收層：確認沒有服務還在自動建立新資源

有些環境是半自動的：例如 CI/CD、排程作業、或監控告警觸發器可能仍在運行，只是它們用的是憑證或工作負載身份。刪了專案不一定能停止所有外部流程（尤其當外部流程指向其他目標時）。

因此你至少要檢查：

• 自動化管線是否仍在跑（例如發佈到其他環境、或仍指向舊專案但會重試）。
• 如果你重建，CI/CD 的憑證與目標專案是否正確切換。
• 告警或事件觸發是否依然存在（有些事件可能在其他專案，仍導致某些運行成本）。

你要確保的不是「沒有任何活動」，而是「沒有任何活動會在目標專案上產生成本」。

第五章：重建流程——把環境重建回來，但不要把垃圾再長出來

重建的最大風險不是技術失敗，而是把舊問題搬回來：殘留的配置、錯誤的計費策略、或本該刪掉的資源又被重新引用。

重建的思路應該是「先恢復必要，再回補進階」。這樣你能確認每一步都不會引入新費用。

5.1 建立重建清單：最小可用環境（MVP）

如果你只是要測試或恢復服務，先建 MVP：

• 網路：VPC、子網、必要的防火牆。
• 計算：最小數量的 VM 或 GKE 節點池。
• 儲存：必要的 Cloud Storage 桶（先不要啟用過多版本或歸檔，除非你需要）。
• 資料庫：先用小規模配置，避免重建後忘了調回。

每完成一段，立刻檢查計費報表。你不需要精確到每個秒級用量，但至少要知道「當下的新增費用是合理的」。

5.2 回填基線設定：成本控制優先

重建時特別要把成本控制設定放在前面，而不是最後再調。

• 關閉不需要的服務：啟用服務越多，越容易出現意外計費。
• 設定自動關停或配額：例如 VM 的自動停止、預警與配額。
• 保留策略有需求才開：Cloud Storage 的保留與版本通常會帶來長期成本。
• 備份策略要可控：資料庫的自動備份要評估頻率與保留天數。

這些設定一開始就做對，後面你就不需要「靠運氣」等垃圾消失。

5.3 部署方式：用狀態管理避免重複建立

如果你用 Terraform 或其他 IaC，重建時要確保狀態檔與資源映射是乾淨的。否則你可能在已刪資源後又「用舊狀態」錯誤重建，導致資源重複或殘留。

建議的做法：

• 確認工作目錄或狀態檔對應到正確的環境。
• 重建前先做一次計畫（plan），確認將建立哪些資源。
• 先部署網路與基礎資源，再部署應用；每步後都做快速驗證。

5.4 上線後的監控：讓成本問題早於扣費擴大被發現

重建不是只做到能跑就好。你需要監控來提前發現「不該存在的資源」或「異常流量」。在 GCP 中，常見的手段包括預算告警、監控指標與日志回溯。

關鍵是把告警設定在合理範圍，避免被噪音淹沒。若你曾經遇到持續扣費，請把告警門檻調到能在小額異常時就提醒你，而不是等到帳單變大。

第六章：排障指南——刪了還扣費時，你應該怎麼查

即使你照流程做了，仍可能在某些情況遇到「看似刪了但費用還在」。這章提供一套快速排障的思路，你可以在 30 分鐘內縮小範圍。

6.1 先判斷是「延遲結算」還是「真的仍有用量」

• 若費用在刪除後短時間內出現但不再增加，多半是結算延遲或清理流程帶來的最後反映。
• 若費用持續增加，就要繼續查，代表仍存在可計費資源或跨專案依賴。

你要看的不是總額，而是趨勢（是否持續累積）。

6.2 對照費用項目與資源清單：找缺口

把費用報表中「Top 服務」列出來，對照你剛刪除的資源清單。如果費用項出現但你確定資源刪光了，那通常是：

• 資源不在這個專案（例如共享架構、其他目標）。
• 資源在別的狀態仍在計費（例如快照/版本/保留策略）。
• 自動化流程在背景又創建了新資源。

6.3 常見漏網之魚清單（務必二次檢查）

• Cloud Storage：未清空的桶、物件保留、版本未刪除。
• 快照：磁碟快照、資料庫備份、系統映像。
• BigQuery：資料集未刪或仍有表分區/快照。
• 網路：NAT Gateway、LB 元件、或不小心保留的路由。
• 排程：Cloud Scheduler、Dataflow 作業、或定時 Cloud Function。

你可以把這段當作「最後一輪掃描」的標準答案。

6.4 若卡在刪除權限或依賴，優先處理「刪除阻塞原因」

刪除可能被依賴或權限擋住。這時不要反覆嘗試一鍵刪，建議直接找到阻塞原因，例如：

• 資源仍被某個服務引用（例如後端服務依賴轉發規則或健康檢查）。
• 資源所有權/角色不足導致無法刪除。
• 保留策略導致刪除被延後。

處理順序是：先移除引用，再調整權限，最後處理保留策略。

第七章：一套可直接照做的「刪除與重建 SOP」

下面是一份你可以直接落地執行的 SOP（標準作業流程）。你不需要每次都完美，但至少要覆蓋每個階段的核心驗證。

7.1 刪除前（T-1 天到 T0）

• 拉取最近 7~30 天費用報表，標出 Top 服務與 Top 成本來源。
• 建立基線清單：重要資源、網路設定、資料位置、備份與快照數量。
• 檢查是否有共享 VPC 或跨專案依賴，確認刪除權限。
• 暫停或限制會持續創建資源的流程（CI/CD、排程、事件觸發）。

GCP帳號充值方案 7.2 清理資源（T0 到 T+N）

• 關閉入口：LB、對外服務、Pub/Sub 消費/發布。
• 刪除或停止計算主體：VM、GKE 集群/節點池、實例。
• 刪除持久性計費單元：磁碟、Persistent Disk、儲存桶物件或桶本身、SQL 備份與快照、BigQuery 資料集。
• 二次掃描快照/映像/版本與保留策略，確認沒有殘留。

7.3 刪除專案（T+N）

• 確定上述主要計費單元都清完後，再刪除專案。
• 保留必要的管理紀錄：刪除時間、申請人、環境目標。

7.4 刪除後驗證（T+N 到 T+N+幾天）

• 資源層抽查：是否仍存在磁碟/快照/儲存桶/資料集。
• GCP帳號充值方案 計費層驗證：費用是否停止累積；若僅延遲，確認趨勢轉為穩定或下降。
• 排除背景創建：檢查自動化流程是否仍指向目標專案或生產新資源。

7.5 重建（重建前必做）

• 先做 MVP：最小網路、最小計算、最小儲存與最小資料服務。
• 成本控制先行：保留策略、備份頻率、版本管理策略、配額與告警。
• 每完成一段部署就驗證費用趨勢，確保新增在可預期範圍。

第八章：把「徹底清理」做成習慣，而不是一次性行動

真正可怕的不是偶爾的垃圾資源，而是缺乏流程導致反覆發生。很多團隊第一次遇到持續扣費，是因為刪除步驟不完整；第二次遇到，是因為只記得「要刪專案」，卻忘了「要確認依賴、要清快照與版本、要看費用趨勢」。久而久之，成本管理會變成救火工作。

GCP帳號充值方案 把刪除與重建流程變成 SOP 的好處，是你不需要每次都重新思考。你只要照著清單走，就能更快定位問題、也更能解釋給同事或主管：為什麼你確定已清理乾淨、為什麼重建不會重複產生扣費。

當你掌握這套方法後，GCP 對你來說就不再是「刪了會不會又扣」的焦慮來源，而是可控的工程環境。刪除與重建的本質，是把雲資源當成可管理的生命周期：建立、使用、回收與驗證，都要有證據。

最後你要記住一句話：垃圾資源不會自己消失；成本只會對你「累積」，不會對你「抱歉」。 只要你按本文的順序盤點、拆依賴、清殘留、再做三層驗證，持續扣費的機率就會大幅下降。重建也會變得踏實，因為你是在一個乾淨、可預期的起點上重新開始。