這篇整理在雲端租用主機之前就要決定的幾個費用上的值，以及它們怎麼從同一組輸入推出來。各節依序是：費用在什麼時間點開始產生，以及免費額度以整個資源判定時超出的是多少；各種費用訊號（資源的用量計數、帳務明細、預算通知、扣款）各自落後多久；由停止延遲與配額允許的最大花費速度，推出防護機制觸發之後到費用停止之前最多再花的金額；扣款的信用卡或帳戶要留多大的額度；平台上的上限分成擋下建立、停止用量與只發通知三種，各自要決定的值怎麼算；停損要停到哪一層、由誰執行；最後把這些值依推算的先後整理成一張依賴表。依基線偵測費用突增的異常告警讀的也是帳務資料，延遲不少於帳務明細，它的設計在 成本監控與告警。各家機制以 Oracle Cloud、Google Cloud 與 AWS 為例，出處與讀取日期寫在句子裡。帳單由哪些維度組成在 計費模式理解；預知的大流量要擴容多少、編多少預算，在 預知的大流量要加多大、編多少預算：從業務預估到擴容規格與費用區間的換算鏈、給決策者與會計的數字，以及每次活動之後的校準，這裡不重寫。

這幾個值放在租用之前決定，理由在決定時的處境。租用之前，決定的人可以不受時間壓力，從計畫推出它們；等到費用失控時才決定，決定的人要在帳務明細落後、費用持續累積的情況下選處置，選得越久花得越多。

費用在什麼時間點開始產生

雲端的費用依它跟資源的關係分成兩種，兩種開始計費的時點不同：

• 跟著資源存在計費：主機與磁碟這類資源，從建立成功的那一刻開始計費，跟有沒有人在用無關；保留的公開 IP 依業者，有些在沒有附在執行中的主機上時另外計費。主機停止之後運算費用是否停止依機型而定（Oracle Cloud 的 Dense I/O、HPC 與多數 GPU 機型停止後照常計費，要終止才停，見 Resource Billing for Stopped Instances，2026-10-27 讀），磁碟照常計費；各種暫停方式各自留下哪些計費的資源，見 服務暫停與恢復上線：只停服務、停止主機、終止主機到全部刪除各自保留的資源，暫停期間仍計費與仍被指向的資源，恢復前要查的漂移與恢復的順序〈暫停期間仍在計費的資源〉。
• 跟著用量計費：出站流量、API 呼叫次數、函式的執行時間，費用跟用量成正比，用量增加的速度決定費用增加的速度。

免費額度讓「開始計費」多了一個判定：一個資源建立時算不算在免費額度裡，而判定的單位決定了超出時多付的是多少。Oracle Cloud 的區塊儲存是以整顆磁碟判定：2026-10-27 在一個付費帳戶上，開機磁碟合計已經用掉免費額度 200 GB 裡的 141 GB 時，再建一顆 60 GB 的開機磁碟，免費額度的用量停在 141、全部磁碟的合計變成 201，那一顆整顆沒有算進免費額度，而不是只有超出的 1 GB 在額度外（額度用量的實測與帳務明細上的項目，見 Oracle Cloud 私有子網路 Ubuntu 主機的實測紀錄：套件來源的出站（NAT gateway、路由與 NSG）、序列主控台的連線，以及被回收之後的重建〈費用與額度：A1、開機磁碟與區塊儲存額度、出站流量與 NAT gateway〉）。所以「還剩多少免費額度」要拿下一個資源的大小去比，不能拿超出的量去估費用。各家免費額度的範圍與試用結束後的處置，見 雲端免費額度與小型主機的收費比較：試用金與固定額度、計費單位、區域限制、試用結束後的處置、出站流量與查價項目。

費用訊號的延遲：從資源建立到扣款

一筆費用從發生到有人收到通知、再到從信用卡扣走，中間經過幾種訊號，每一種落後的時間不同。依出現的先後：

官方出處（2026-10-27 讀）：Oracle Cloud 的 Cost Analysis 與 Budgets；Google Cloud 的 Analyze billing data and cost trends with Reports 與 Create, edit, or delete budgets and budget alerts；AWS 的 Analyzing your costs and usage with AWS Cost Explorer 與 Managing your costs with AWS Budgets。Google Cloud 預算通知的實測間隔，在 GCP 預算警示與停損開關的實測紀錄：建預算、Pub/Sub 主題、服務帳號、函式與觸發器、兩段驗收、心跳監看與停用後的恢復。

這張表的讀法是：越晚出現的訊號越接近實際的金額。用量計數沒有金額，但它是這幾種訊號裡唯一幾乎即時的；它只涵蓋跟著資源存在計費的那幾項（資源的數量與容量），跟著用量計費的出站流量、API 呼叫仍要等帳務明細。帳務明細與預算通知有金額，代價是落後數小時到兩天。所以「現在有沒有資源或用量超出計畫」看用量計數，「實際花了多少」看帳務明細，兩件事用不同的訊號判斷。

停止之前的最大超支：配額、訊號延遲與處置延遲

費用失控指的是費用以超出計畫的速度增加，而增加的部分在人或程式停止它之前持續累積。防護機制的觸發條件（預算門檻、用量超過計畫量）成立之後，費用不會當場停止，觸發條件成立到費用停止之間還會再花一段，這一段的金額由兩個量決定：

• 最大花費速度：最壞情況下每小時花多少，計畫內與超出計畫的部分都算在內，因為延遲期間兩者都在累積。跟著資源存在計費的那一部分由平台上「能開多少資源」決定，也就是配額允許的量乘上每單位每小時的價格。拿到外洩憑證的人可以直接建資源，不經過自動擴縮，所以這裡要用配額，不能用自動擴縮的最大台數；自動擴縮的上限限得住的是服務自己出錯的那一類失控，它是跟著資源存在計費那一部分的單月上限，理由在 成本模型〈Autoscaler 的 max 是財務斷路器〉。跟著用量計費的那一部分（出站流量、API 呼叫、函式執行）要分開看。API 呼叫與函式執行在部分服務上有平台的上限：請求速率的配額、函式的並行上限、Cloud Run 這類服務的最大執行個體數，例如 Google Cloud 可以把 API 配額調到預設值以下（View and manage quotas，2026-10-27 讀，不是每個服務都支援）；它們跟配額一樣是超過就拒絕，沒有延遲。出站流量多半沒有這種平台上限（推論），限住它的做法是應用層的速率限制，或改用含流量的計價方式（每月固定的免費出站量、含流量的主機方案、前面放 CDN，各家出站流量的額度見 雲端免費額度與小型主機的收費比較：試用金與固定額度、計費單位、區域限制、試用結束後的處置、出站流量與查價項目〈出站流量與閒置回收〉）；兩者都沒有時，這一部分的最壞情況沒有上限，只能靠偵測，而且用量計數偵測不到它，要等帳務明細。
• 停止延遲：偵測延遲加上處置延遲，從觸發條件實際成立的那一刻起算。偵測延遲是從觸發條件成立到偵測的訊號出現：用預算通知偵測時，是帳務明細落後的時間再加上預算的評估週期；用用量計數偵測時，是查詢的間隔加上用量計數本身落後的幾分鐘。處置延遲是從那個訊號出現到費用停止：執行處置的人或程式多久動作，加上動作之後資源多久停止計費（計費的最小單位依業者與資源而不同，要查各家的價目說明）。由人執行時，人判斷與處理的時間就算在處置延遲裡。

防護機制的觸發條件有兩種：花費達到某個金額（下文稱觸發處置的門檻，由預算通知偵測），或用量超過計畫量（由用量計數偵測）。最大花費速度乘上停止延遲，下文稱為停止之前的最大超支：觸發條件成立之後，到費用停止之前最多再花的金額。一個月最壞的總花費由三段相加：觸發條件成立之前花的錢，加上停止之前的最大超支，再加上停止之後仍在累積的計畫內花費（處置停掉全部花費時是 0）。觸發條件是金額門檻時，第一段不超過門檻本身；觸發條件是用量超過計畫量時，第一段不超過計畫內每月的花費（推論）。後面的門檻與信用卡額度都從這個三段的和推出來。

這三段只算得到按時間累積的費用。另有兩類費用不是速度乘上時間，停損的任何一層都停不掉，要另外加進最壞的總花費：一是一次性的購買，例如預留執行個體（AWS 的 Reserved Instances 選全額預付時在期初付清、買了不能取消，見 Reserved Instances for Amazon EC2 overview〈Payment options〉，2026-10-27 讀）、Marketplace 訂閱、網域註冊，拿到憑證的人一個呼叫就能買下，配額擋不住；二是承諾用量（Savings Plans、承諾使用折扣、按月付的預留執行個體），合約期間每月照扣。一次性購買的上限由權限決定：用 IAM 或 SCP 拒絕這幾類購買動作，它就跟配額一樣沒有延遲；沒有拒絕時，它的上限是權限允許的購買金額。承諾用量是計畫內就知道的固定金額，算進「停止之後仍在累積的計畫內花費」。

示例：偵測靠預算通知，偵測延遲取〈費用訊號的延遲：從資源建立到扣款〉那張表裡 Oracle Cloud 文件寫的上限，帳務明細最多落後 48 小時、預算每 24 小時評估一次，假設兩者直接相加；處置由人執行，收到通知到處理完要 12 小時；最大花費速度每小時 5 美元。12 小時與 5 美元是為了說明算法而設的，不是任何業者的數字。停止延遲最長約 48 ＋ 24 ＋ 12 ＝ 84 小時，停止之前的最大超支約 5 × 84 ＝ 420 美元。同樣是多開資源造成的失控，改成看用量計數、由程式停止資源，假設每 10 分鐘查一次、用量計數落後約 5 分鐘、程式約 5 分鐘內停止、停止之後在 1 小時內不再計費，停止延遲最長約 1 小時 20 分，停止之前的最大超支約 5 × 1.33 ≈ 7 美元。出站流量造成的失控，用量計數偵測不到，偵測仍要靠預算通知；假設應用層的速率限制把它限在每小時 5 美元以內，處置由人執行時仍是 420 美元，改由預算通知觸發的程式處置時約 5 ×（48 ＋ 24）＝ 360 美元。

停止之前的最大超支是後面每一個值的輸入。依它算出的觸發處置的門檻（下面〈平台上的上限：擋下建立、停止用量與只發通知〉的算法），如果比計畫內每月的花費還小，正常使用就會觸發處置；這時要回頭降低兩個量之一：收緊配額讓最大花費速度變小，或縮短停止延遲，也就是改用落後較少的訊號偵測、改由程式處置。反過來說，下文的能接受的停止延遲，指的是每月能接受的上限、配額與計畫內花費都給定時，算出來的門檻不會落到計畫內花費以下所允許的最長停止延遲。

失控的來源分成兩類，兩類的花費速度與處置不同。服務自己出錯（無限重試、遞迴觸發、擴縮上限設太高）時，修好程式費用就停。資源被別人濫用（外洩的 API 金鑰、被入侵的主機拿去挖礦）時，濫用者可以把配額允許的量用滿，最壞情況下花費速度直接到最大花費速度（推論）；處置要先撤銷外洩的憑證、停掉被入侵的資源，再處理費用，只停資源不撤銷憑證，濫用者可以再建一份。兩類的細節與 Google Cloud 上的例子在 GCP 上的雲端費用失控防護：預算警示、強制執行支出上限與自動停用帳單的作用範圍、反應時間與判斷〈費用失控的來源與反應時間〉。

扣款的信用卡或帳戶要留多大的額度

這一節講的是用信用卡付款的隨用隨付帳戶；先預付或簽約付款的方案（例如 Oracle Cloud 的 Universal Credits）用發票付款，扣款與額度照合約，預付的金額也會像抵免一樣讓帳務上的淨額偏低。扣款的時點決定了信用卡一次要付多少。三家的扣款方式有兩種：

• 月結後付：帳單週期結束之後，一次扣整個週期的費用。Oracle Cloud 的 Pay As You Go 依上個月的實際用量出帳，信用卡付款「立即到期」（原文「When you pay by credit card, the payment term is immediate」，Understanding Your Invoice）；AWS 在每月初扣預設付款方式（Making payments）；Google Cloud 的每月週期帳戶在每月 2 日扣上個月的費用（出處同下一項）。
• 門檻扣款：Google Cloud 的門檻週期帳戶，每月 1 日扣款，餘額達到付款門檻時也會扣。門檻由 Google 指定，使用者不能自己改，帳戶狀態良好時觸發一次之後會自動調高；費用累積很快時，實際扣的金額可能超過門檻（Find out your Cloud Billing account type and charging cycle）。

以上都是 2026-10-27 讀的。另外，註冊與升級時會有一筆暫時的預先授權：Oracle Cloud 註冊 Free Tier 時授權 1 美元、升級時授權 100 美元，Oracle 端立即撤銷，銀行多久退回由銀行決定；AWS 新註冊流程的驗證暫扣 1 美元、3 到 5 天（Managing Account Upgrades and Payment Method、Sign up for AWS (new)，2026-10-27 讀）。可用額度低於這筆授權金額的卡片，在註冊或升級時就會被拒（從授權的機制推論）。

一個帳單週期最壞的總花費，是〈停止之前的最大超支：配額、訊號延遲與處置延遲〉那三段的和，再加上沒有被權限擋下的一次性購買；〈平台上的上限：擋下建立、停止用量與只發通知〉裡觸發處置的門檻，就是照「這個和等於每月能接受的上限」設的。所以門檻照那個算法設好時，一期雲端費用的上限是每月能接受的上限，信用卡要容得下的是：

• 一期雲端費用：每月能接受的上限，再乘上不在預算金額裡的比例項目，例如稅金（Google Cloud 寫預算門檻的計算含稅金，見 Create, edit, or delete budgets and budget alerts，2026-10-27 讀；其他兩家的預算是否含稅沒有查）、隨花費比例收費的支援方案；刷外幣時再加匯率與發卡行的海外交易手續費。
• 同時掛在卡上的期數：信用卡的可用額度要等繳款之後才恢復。雲端在月初扣上個月的費用，而信用卡的繳款日如果落在下一次雲端扣款之後，下一期扣款時上一期還沒繳，額度要容得下兩期（從信用卡繳款的機制推論，各發卡行的規則不同）。門檻扣款的帳戶一個月可能扣好幾次，要把落在同一個信用卡帳期裡的扣款加起來算。
• 其他：同一張卡的其他支出，以及一段給估錯的餘裕（最大花費速度或停止延遲比假設的大）。

門檻沒有設、或設得比算出來的高時，一個月最壞的總花費就沒有上限，信用卡額度也就算不出來。另外，月結後付的「一個月扣一次」有例外：AWS 的客戶合約寫懷疑帳號遭到詐欺使用時可以提前出帳（§3.1），而濫用正是要防的那一種失控；預留執行個體這類一次性購買在購買時就產生費用（扣款的時點沒有查）。

額度不夠時，扣款失敗本身會停掉服務，而停的方式不是自己選的。Google Cloud 寫付款被拒時可能停止服務，自助帳戶可能整個被停權、連結的全部專案的全部服務都停，長期無效時資源可能被移除、移除之後救不回來（Resolve Cloud Billing issues）；AWS 的客戶合約寫違反付款義務時可以在通知之後立即停權（AWS Customer Agreement §4.1）；Oracle Cloud 的官方頁只寫了 Universal Credits 訂閱未付款時 tenancy 與全部資源停權，Pay As You Go 的處置沒有找到明文（Subscriptions and Payment Failure）。扣款失敗之後還有幾天可以補救，三家都沒有寫出天數：Google Cloud 的頁面沒有寫，AWS 合約寫的是通知之後可以立即停權（也就是不保證有寬限），Oracle Cloud 的 Pay As You Go 沒有找到。以上都是 2026-10-27 讀的。

所以把信用卡額度壓低、拿它當費用的上限，限住的只有「扣款這個動作」：超過額度的費用仍是欠款，帳號停權之後照樣要付，AWS 的合約還寫了逾期可以收月息 1.5%。付出的是兩件事。一是作用得晚：月結後付的帳戶要到帳單週期結束之後才扣款，失控的那一個月照樣累積到扣款那天。二是作用的方式粗：停權的範圍是整個帳單帳戶（Google Cloud 寫的是連結到那個帳單帳戶的全部專案），正式服務跟著停，資料可能被移除；把實驗拆到自己的專案而共用同一個帳單帳戶與同一張卡時，隔離不了這個範圍。額度刻意壓低的專用卡適合只放實驗資源的帳號，而且這個帳號要有自己的帳單帳戶與卡片，資料要能丟、或在業者之外另有一份；放正式服務的帳號，額度要留足，費用的上限交給〈平台上的上限：擋下建立、停止用量與只發通知〉的平台機制。

實驗帳號還有一個比壓低額度更嚴的做法：不升級的免費方案。AWS 的 Free account plan 不會產生費用，六個月後或抵免用完時帳號自動關閉；Oracle Cloud 不升級的 Free Tier 不會扣款；Google Cloud 的試用帳號不升級就不扣款。換到的是超支為 0，付出的是能用的服務受限、到期時帳號或付費資源被關閉，各家的處置見 雲端免費額度與小型主機的收費比較：試用金與固定額度、計費單位、區域限制、試用結束後的處置、出站流量與查價項目〈試用結束後帳號與資源的處置〉。

平台上的上限：擋下建立、停止用量與只發通知

平台上的上限依它在費用超過時做什麼，分成三種，三種的反應時間與副作用不同：

• 擋下建立：配額（quota）限制的是能建多少資源，建立請求超過時直接被拒絕，費用根本不會開始。它不經過帳務資料，所以沒有延遲；代價是要擴充時得先改配額。Oracle Cloud 的 compartment quota 由管理員用 policy 設定，可以限制主機的核心數與區塊儲存的總量，超過時建立請求被拒，回 400（配額名稱與 policy 的寫法以 Quota Policy Syntax 為準，2026-10-27 讀）。2026-10-27 實跑時，A1 核心數的那一條被擋下時訊息寫出被超過的 quota 名稱與 policy；區塊儲存那一條回的 code 是 LimitExceeded、訊息寫成 service limit，而 Oracle 的錯誤代碼表把 LimitExceeded 定義成超過 Oracle 設定的 tenancy 上限；那時 total-storage-gb 的用量遠低於 tenancy 的上限，所以擋下建立的是 quota（指令與兩種回應的原文在 Oracle Cloud 私有子網路 Ubuntu 主機的實測紀錄：套件來源的出站（NAT gateway、路由與 NSG）、序列主控台的連線，以及被回收之後的重建〈費用與額度：A1、開機磁碟與區塊儲存額度、出站流量與 NAT gateway〉）。tenancy 與 compartment 是 Oracle Cloud 的帳號層級與資源分組，定義在 Oracle Cloud 的帳號結構與 home region：tenancy、Always Free 的範圍與主控台登入欄位〈Tenancy、home region、compartment 與 availability domain〉。AWS 的 Service Quotas 是 AWS 定義的資源上限，提供的是查詢與申請調高；要在 AWS 上限制能建多少，用 SCP 或下一項的 Budget actions。
• 停止用量：花費達到門檻時由平台或程式停止資源，反應多快取決於它讀的是帳務資料還是費用估算。讀帳務資料的，反應時間至少是〈費用訊號的延遲：從資源建立到扣款〉那張表裡帳務明細加預算通知的延遲：AWS 的 Budget actions（套用 IAM policy、SCP，或對指定的 EC2、RDS 執行個體執行動作），以及由預算通知觸發的自寫程式。讀費用估算的比帳務明細快、但不是即時，從達到上限到暫停之間多出來的用量照常計費：Google Cloud 的強制執行支出上限（spend cap budget）屬於這一種，它只涵蓋幾項 API 型的服務、不涵蓋 Compute Engine，暫停的是新用量，持續性資源照常計費（涵蓋的服務清單與延遲的說法在 GCP 上的雲端費用失控防護：預算警示、強制執行支出上限與自動停用帳單的作用範圍、反應時間與判斷〈強制執行支出上限：涵蓋的服務、範圍與暫停期間〉）。AWS 改版後的註冊流程分成 Free Plan 與 Paid Plan，Paid Plan 可以替每個 project（那個流程裡的資源分組）設每月的支出上限（spend limit），達到時暫停 project、停止資源，資料保留，90 天沒有處理就永久刪除；上限的最低值是 20 美元與 AWS 對這個 project 可能花費的保守估計兩者中較大的那個，它的延遲官方頁沒有寫（Create a spend limit in AWS Settings，2026-10-27 讀）。平台機制涵蓋不到的服務，要由預算通知觸發自己寫的程式去停。
• 只發通知：預算警示在花費達到通知的門檻時寄通知，不停止任何用量。Oracle Cloud 的預算官方稱為軟上限（soft limits），頁面描述的通知方式是 email；Google Cloud 寫只發通知的預算不會封頂。通知本身的延遲是〈費用訊號的延遲：從資源建立到扣款〉那張表裡帳務明細加預算通知的延遲，費用停在哪裡，再加上收到通知的人多快處理。

三種上限各自要決定的值：

• 擋下建立：配額的值。配額設在平台允許的最大值時，最大花費速度裡跟著資源存在計費的那一部分就是那個最大值；配額等於計畫要用的量時，那一部分就等於計畫內的速度，多開資源造成的失控不會發生，剩下要防的是跟著用量計費的那一部分。代價是每次擴充都要先改配額，而這一步本身就是一次有人經手的審核。配額的值還要對照它的作用範圍：配額可能以可用網域（availability domain，區域裡的一個資料中心）、區域或專案為單位，設定的值套在每一個單位上，全區的實際上限是設定值乘上單位的個數。Oracle Cloud 主機核心數與區塊儲存的配額就是以可用網域為單位，設 4 在有三個可用網域的區域，等於全區合計 12（依 Quota Policy Syntax 的說明，沒有實跑）。容量上的配額也有兩種設法：設在計畫的合計，計畫外的資源一建就被拒；設在免費額度的上限（例如 Oracle Cloud 區塊儲存的 200 GB 是整個 tenancy 的合計，以可用網域為單位的配額要讓各單位加起來不超過 200），兩者之間可以臨時建磁碟、不必先改配額，代價是這段範圍裡建的磁碟不經審核。沒有自己設配額時，最大花費速度就用平台的預設上限算（Oracle Cloud 用 oci limits、AWS 用 Service Quotas 查得到）。
• 停止用量：觸發處置的門檻與涵蓋範圍。觸發處置的門檻＝每月能接受的上限－停止之前的最大超支－停止之後仍在累積的計畫內花費。處置停掉全部還在累積的花費時，最後一項是 0；處置只停失控的那一塊、計畫內的服務照常運作時，最後一項保守的取法是一整個月計畫內的花費（失控發生在月初的情形），承諾用量這類停不掉的固定費用也在這一項裡。示例（另設的一組數字，跟〈停止之前的最大超支：配額、訊號延遲與處置延遲〉的示例無關）：每月能接受的上限是 100 美元，停止之前的最大超支是 30 美元，處置停掉全部花費時，觸發處置的門檻設在 70 美元以下；只停失控的那一塊、計畫內每月 20 美元時，設在 50 美元以下。算出來的門檻要比計畫內每月的花費大，否則正常使用就會觸發；這個例子裡 50 大於 20，有空間。帳號有試用金或抵免時，預算比的金額可能是扣掉抵免之後的淨額（Google Cloud 的預算預設扣掉抵免與折扣，見 Create, edit, or delete budgets and budget alerts，2026-10-27 讀），門檻要等抵免用完才觸發，那段期間的失控吃掉的是抵免，帳務上看起來是 0；門檻要照抵免之前的金額設，Google Cloud 是在預算設定裡取消勾選抵免。涵蓋範圍要逐項對照計畫要開的資源；涵蓋不到的那幾項，由配額限制住最大花費速度，或接受只有通知。
• 只發通知：通知的門檻。程式自動處置之外再設一道通知，是讓人在程式動作之前先判斷要不要改用別的處置，所以通知要比觸發處置的門檻早「人判斷期間的超支」那麼多：通知門檻＝觸發處置的門檻－最大花費速度 × 人判斷要多久。這裡的人判斷時間發生在程式處置之前，不在處置延遲裡；沒有程式處置、由人執行的情形，人的時間已經算在處置延遲裡，通知門檻就是觸發處置的門檻。這條式子的前提是通知與處置讀同一種訊號；程式由用量計數觸發、通知走預算通知時，程式會比通知先動作。算出來的通知門檻比計畫內每月的花費還低時，正常使用每個月都會收到通知，要回頭縮短人判斷的時間或收緊配額。依預測花費（平台依目前的速度推估到期末）觸發的門檻通常比依實際花費的早，代價是一次性的大筆費用會讓預測暫時偏高、提早觸發（這兩點是推論）；Oracle Cloud、AWS 與 Google Cloud 的預算都有預測的選項，而 AWS 要大約 5 週的用量資料才產生預測，新帳號在那之前只能靠實際花費的門檻（AWS Budgets best practices，2026-10-27 讀），Google Cloud 自訂期間的預算也不能用預測門檻。

停損停到哪一層、由誰執行

停損的動作有好幾層，停得越徹底，費用越確定停止，對服務與資料的影響也越大。前四層沿用 服務暫停與恢復上線：只停服務、停止主機、終止主機到全部刪除各自保留的資源，暫停期間仍計費與仍被指向的資源，恢復前要查的漂移與恢復的順序 的分法，從輕到重：

• 只停服務：程序停掉，主機照常計費。
• 停止主機：多數機型的運算費用停止，磁碟照常計費（例外的機型見〈費用在什麼時間點開始產生〉）。
• 終止主機、保留磁碟與網路設定：主機的費用停止，保留的磁碟、IP、快照與網路元件照常計費。
• 全部刪除：連磁碟一起刪，跟著資源存在計費的費用停止，資料不在了，之後要從 repo 重建；仍在計費的備份、快照與網路元件見那一篇〈暫停期間仍在計費的資源〉。
• 帳單層：把專案從帳單帳戶解除連結（Google Cloud），整個專案的服務都停，資源可能被永久刪除，也不保證能恢復，見 GCP 上的雲端費用失控防護：預算警示、強制執行支出上限與自動停用帳單的作用範圍、反應時間與判斷〈由預算通知觸發的處置：解除帳單連結與只停止花錢的資源〉。

選哪一層，比的是兩種損失：多付的費用，以及服務停止、資料遺失的代價。後者由兩件事決定，一是停機影不影響使用者，二是資料能不能重建：

• 資料可以重建、停機不影響使用者（實驗與開發環境）：停得徹底比較划算，程式可以在門檻觸發時直接刪除資源或解除帳單連結。
• 停機可以接受、資料不能丟：程式只停止花錢的資源（停止主機、縮減到零），保留磁碟與資料；之後要付的是磁碟的費用。
• 停機影響使用者（正式服務）：程式自動停止既有的資源會讓一筆異常的帳單變成一次停機，所以停止既有資源由人判斷；程式可以做的是不造成停機的那一種處置，也就是擋下新增：套用拒絕建立資源的 IAM policy 或 SCP（AWS 的 Budget actions 做得到）、調低自動擴縮的上限、撤銷或輪替外洩的金鑰。多開資源這一類失控的處置延遲因此縮到程式的反應時間；已經在跑的資源與出站流量這類用量，停止延遲仍要算人判斷的時間。沒有人能隨時處理時，處置延遲就是下一次有人看到通知的時間（例如隔天上班），配額要依這段時間的最大花費速度能承受的金額來設。

判斷的單位是一次停損會一起停掉的範圍（一個專案、compartment 或帳號），不是單一資源：一個範圍裡同時有實驗資源與正式服務時，照正式服務判。所以把容易失控的功能拆到自己的專案或 compartment，讓那一塊可以照較寬的規則獨立停止；拆出去之前要確認正式服務沒有共用那一塊的資源或憑證，例如同一把 API 金鑰，否則停掉那一塊時，正式服務裡用同一把金鑰的功能也一起停。Google Cloud 上用解除帳單連結與只停止花錢的資源兩種做法的範圍與實測，在 GCP 上的雲端費用失控防護：預算警示、強制執行支出上限與自動停用帳單的作用範圍、反應時間與判斷〈由預算通知觸發的處置：解除帳單連結與只停止花錢的資源〉。

這幾件事要在租用之前有答案：門檻觸發時通知誰、誰有權限停止哪一層、程式自動停止的範圍是哪些資源、停之前要不要先做快照或備份、恢復時由誰決定。通知送到一個沒人看的信箱，或有權限停止的人不在，處置延遲就沒有上限，停止之前的最大超支也跟著沒有上限。停損的程式平常不動作，所以它的驗收要用合成的觸發實際跑一次；Google Cloud 上的建置，以及分成「真實的預算通知送到主題」與「測試訊息觸發函式」兩段的驗收，在 GCP 預算警示與停損開關的實測紀錄：建預算、Pub/Sub 主題、服務帳號、函式與觸發器、兩段驗收、心跳監看與停用後的恢復。

租用之前要決定的值與它們的依賴

上面幾節的值互相依賴。推算的起點有幾類：由人直接決定的每月能接受的上限與能接受的停止延遲；由容量規劃推出來的資源規格；從價目表查到的單價；以及組織能做到的反應時間，也就是有人值班時，人處理或判斷一次要多久。由人還是由程式執行處置，是從能接受的停止延遲與人的反應時間推出來的。其餘的值都從這些起點推出來，依推算的先後：

租用之前推的值，有幾個是照文件或假設估的，例如帳務明細的延遲：Oracle Cloud 文件寫最多 48 小時，2026-10-27 實測的 usage API 大約落後 2 小時；AWS 的預測要大約 5 週的資料。所以第一個帳單週期跑完、量到實際的延遲之後，這張表要用實測值重算一次。預知的大流量要臨時加開資源時，也要重算：配額先調高，最大花費速度跟著變大，停止之前的最大超支、門檻與信用卡額度都要依新的值調整。擴容的規格與預算怎麼從業務預估推出來，在 預知的大流量要加多大、編多少預算：從業務預估到擴容規格與費用區間的換算鏈、給決策者與會計的數字，以及每次活動之後的校準；峰值的形狀與倍率在 峰值估算，計費模式與單位請求成本在 成本模型。