賬單漲了先別改任何東西。用 Cost Explorer 按服務、再按用量型別兩級下鑽定位真兇，再對照七類反直覺的持續計費：免費額度用盡、實例終止後殘留的卷與快照、被禁用區域裡的資源，以及關賬號後仍在計費的承諾。
賬單上個月 520，這個月預估 780。沒有主動擴容，沒有大版本釋出，CPU 利用率正常，應用也健康——這種賬單是最容易查錯方向的。
最常見的反應是「先把實例降配」。但官方文件和實際案例都指向同一個結論：你最初懷疑的資源，往往不是真兇。 漲得最兇的常常是資料流轉，以及那些你以為早就刪掉了的資源。
這篇講的是定位流程，不是省錢清單——省錢的做法見 AWS 賬單看不懂？6 個可執行做法。
排查第一原則：先別改任何東西
成本排查的第一條規則很反直覺：在弄清楚錢花在哪之前，不要最佳化。
- 不要急著終止實例、降配、刪快照、摘掉 NAT 閘道器、關掉日誌——這些動作可能省錢，也可能把生產搞掛。
- 排查的目標是先定位，不是先省錢。順序反了，你可能刪掉一個還在用的資源，而真實原因繼續漲。
- 賬單本身不會騙人，它只是沒告訴你為什麼。這一篇就是把這個「為什麼」拆出來。
⛔ 先定位、後動手，這不是謹慎，是因為很多意外扣費在「刪掉某個東西」之後才真正開始——比如實例被終止了，但它掛的磁碟還在，賬單裡的那一項從此變成「沒人認得出來的費用」。
第一步：把位置釘死（兩級分組）
開啟 Cost Explorer，而不是賬單摘要頁。區別很關鍵：摘要頁告訴你「多少」，Cost Explorer 告訴你「為什麼」。
按順序做三件事：
- 按服務分組：立刻能看出漲幅來自 EC2、S3、資料傳輸，還是完全沒想到的某個服務。
- 把日期範圍收窄：縮到暴漲開始的那幾天，能確定它是從哪天開始的，而不只是「漲了」。
- 再按用量型別分組：這一步才真正把「服務級」細化到「具體是什麼在計費」，也是本篇第二步的內容。
一個典型的對比結果長這樣（數字是示例，用於說明結構）：
| 服務 | 上月 | 本月 | 變化 |
|---|---|---|---|
| EC2 | $125 | $132 | +$7 |
| RDS | $91 | $94 | +$3 |
| S3 | $18 | $21 | +$3 |
| 資料傳輸 | $61 | $168 | +$107 |
| NAT 閘道器 | $32 | $96 | +$64 |
| 其他 | $45 | $48 | +$3 |
這一步的結論經常是：你懷疑的那個服務幾乎沒動，漲的是流量。EC2 只漲了 7 塊錢——那麼「降配實例」這個方向，從一開始就是錯的。
第二步：按用量型別細分，這一步才看得出真兇
服務級分組只能到「EC2 漲了」。把分組維度從「服務」換成「用量型別」，才會出現這類條目：
- DataTransfer-Out-Bytes —— 出網流量，按 GB 計費。
- DataTransfer-Regional-Bytes —— 跨可用區或跨區域的流量。
- NatGateway-Bytes —— NAT 閘道器處理的資料量。
- NatGateway-Hours —— NAT 閘道器存在的小時數。
看到這裡，問題就從「賬單問題」變成了「架構問題」：是什麼在往這些通道裡灌流量？ 可能的答案包括：一個後臺任務在定時拉大資料集、部署流程在反覆拉容器映象、某個服務把本該內網呼叫的流量繞到了 NAT 閘道器出公網。
到這裡才是去看 CloudWatch 網路指標的時候，必要時再上 VPC Flow Logs 定位到具體資源。要提醒的是：NAT 閘道器按處理量計費，不只是按小時——它「在跑」這件事本身很便宜，它「處理了多少流量」才是賬單來源。以官方定價頁為準。這些計費邊界的完整拆解（一共有六個，以及每一條怎麼省）見 AWS 流量費為什麼這麼貴。
七類「反直覺的持續計費」
以下七類是官方文件專門列出、且實際最高頻的意外費用來源。共同點是：它們都不像「在執行的東西」，但都在計費。
| 類別 | 為什麼會一直扣錢 | 怎麼確認 |
|---|---|---|
| 1. 免費套餐額度用盡 | 額度用完（或到期）後自動轉為按需計費，賬號不會因此關閉，也不會提醒你 | 官方免費套餐頁可看當前與預估用量 |
| 2. 實例終止後殘留的磁碟 | 儲存卷不隨實例消失——你終止了實例，卷還原封不動地留著並繼續計費 | 去 EBS 控制檯直接看有沒有「未掛載」的卷 |
| 3. 快照 | 快照是獨立資源，長期留存並逐個累積，很容易忘記 | 按建立時間排序看最老的快照 |
| 4. 被禁用區域裡的資源 | 關掉區域不等於刪掉資源：資源繼續計費，但你已經訪問不到它了 | 禁用區域前先把該區域資源全部終止 |
| 5. 服務間互相建立的資源 | 有些服務會替你在別的服務裡建立資源（例如託管服務背後的實例、卷、日誌組） | 按服務分組時留意你沒主動開過的服務 |
| 6. 閒置的負載均衡器與 NAT 閘道器 | 它們按存在計費（小時費），即使沒有流量；NAT 閘道器還疊加按處理量計費 | 檢查沒有後端或長期零流量的實例 |
| 7. 公共 IPv4 地址 | 官方文件把地址類資源單列為意外費用來源；這類計費規則近年有調整 | 以官方定價頁為準，不要用舊文章的數字 |
一個 5 分鐘的自檢動作：把上面第 2、3、6 條對應的控制檯各開一遍，按「最老/最久未使用」排序。這三處是「孤兒資源」最集中的地方，而且清掉它們不會影響任何在跑的東西——這是少數可以放心先動手的地方。
關賬號不等於停止計費
這是七類之外單獨值得講的一類，因為它的觸發動作很明確：你關了賬號，賬單卻沒停。
官方文件寫得很清楚，賬號關閉後仍可能收到賬單，原因包括：
- 關閉當月已產生的用量，會在下個賬期正常出賬。
- 仍在生效的預留實例：會繼續計費，直到預留期結束。
- 仍在生效的節省計劃：會繼續計費，直到計劃期結束。
- Marketplace 訂閱不會隨賬號關閉自動取消：需要先終止該訂閱下的所有軟體實例，再去訂閱管理頁取消。
另外，賬號關閉後的一段時間內你仍然可以登入進去檢視還活著的資源、歷史賬單並付款。
⛔ 所以「專案結束就關賬號」這個動作，前提是賬號裡沒有未到期的承諾。 關之前先確認：有沒有還沒到期的預留實例或節省計劃。承諾類折扣各家規則不同（有的鎖規格、有的承諾金額），橫向對比見 五家雲廠商折扣機制對比；節省計劃的退貨與到期規則見 AWS 節省計劃怎麼買。
為什麼這些資源會一直在扣錢
上面七類看似互不相關，其實共享同一個心智模型——換掉它，很多「莫名」的賬單立刻就有解釋了：
AWS 是按「資源存在」收費，不是按「資源在幹活」收費。 本地的檔案放著不花錢，雲上的一個卷、一個地址、一個負載均衡器——只要存在，就在計費。
所以正確的自檢問句不是「它還在跑嗎」，而是「它還在嗎」。這個差別決定了你會不會去檢查那些「早就沒用了但我以為會自動消失」的東西。
順著這個模型，賬單增長通常只有三種成因：用量自然增長（請求量、流量、儲存慢慢累積）、某個資源被自動建立或遺忘（就是上面七類）、以及單價跳變（額度用盡、承諾到期）——排查時先分清是哪一種，方向就定了。
提前被告知：三個能自動預警的設定
排查是被動的。下面三件事加起來十幾分鐘，但它把「月底才發現」變成「幾天內就知道」——這也是賬單管理真正的分界線：
| 設定 | 作用 | 為什麼值得開 |
|---|---|---|
| AWS Budgets（預算） | 對成本或用量設閾值，按 50% / 80% / 100% 這類百分比分級告警 | 把「月底看一眼」變成「越線就收到通知」 |
| 成本異常檢測 | 自動學習你的用量模式，檢測到異常時告警，並提供根本原因分析（可按服務、賬號、用量型別、區域等維度看） | 固定閾值抓不住「沒有規律的突增」，機器學習的方式更擅長這個 |
| 賬單告警（估算費用） | 對「預估費用」設告警，在明細還沒算出來之前就預警 | 作為預算告警之外的一層早期預警 |
還有一件常被跳過但同樣重要的事：給資源打標籤（專案 / 環境 / 負責人）。沒有標籤的資源在賬單裡是隱形的——漲了你也無法歸因到哪個團隊、哪個環境。這件事的成本很低，收益是「以後每次排查都能直接定位」。
這三件事和成本最佳化本身是兩回事：它們不省錢，它們讓你早知道。 在這個基礎上再談節省計劃、預留實例這類承諾類折扣，才有穩定的基線可以判斷（見 AWS 節省計劃怎麼買）。另外要分清一層關係：官方折扣降低的是賬單上的單價，透過渠道結算降低的是你實際支付的金額，兩者作用在不同位置——見 AWS 折扣與代理定價。
常見問題
我什麼都沒做，賬單為什麼會漲？
先分清三種成因：用量自然增長（請求量、流量、儲存累積，最容易被忽略）、資源被自動建立或遺忘（上面七類）、單價跳變（免費額度用盡、承諾到期、計費規則調整）。三者的排查路徑完全不同——第一種要做架構最佳化，第二種要清資源，第三種要重新算價格。
一定要等出賬才能看到費用嗎？
不用。Cost Explorer 的資料是接近實時的（會有一定延遲），所以當月就能看到趨勢，不用等到賬單出來。這也正是「賬單出了才發現」這個被動模式可以改掉的原因——配合異常檢測，多數突增能在幾天內被識別。
已經產生了意外費用，能申請減免嗎？
官方文件明確說明可以對賬單提出詢問、並可聯絡支援處理。但要清醒地看待結果：申訴不等於減免，能否調整取決於具體情況與政策，以官方渠道的答覆為準。與其事後申訴，不如把上面三個告警開起來。
實例我已經刪了，為什麼還在扣錢？
因為卷、快照、地址、負載均衡器這些是獨立資源，不隨實例一起消失。這是最常見的誤解來源。去對應控制檯按「未掛載 / 最久未使用」排序找一遍，通常幾分鐘就能定位。
怎麼防止以後再發生？
三步：開預算與異常告警（早知道）、給資源打標籤（能歸因）、每月做一次孤兒資源巡檢（卷、快照、地址、閒置負載均衡器各看一遍）。這三件事都不省錢，但它們把「每月被賬單擊中一次」變成「異常幾天內被處理掉」。