跨 AZ、走 NAT Gateway 出網、跨區複寫、
或者某個服務在你不注意的地方「把資料搬來搬去」。
流量費的特色是：少量看不出來，一放大就很可怕。
1) 什麼是 Data Transfer？為什麼它特別容易變成「看不到的成本」
AWS 的流量費本質上就是「資料移動」的費用：資料從哪裡到哪裡、經過什麼邊界、用了什麼路徑。 你不需要背一堆費率表，但你要抓住一個直覺：只要跨出某個界線，就可能開始算錢。
真正讓人痛的是，流量費通常不是你手動開的，而是你的架構在正常運作時自然產生： 比如服務變熱、用量上升、log 變多、複寫頻率變高——你只會看到「系統變忙」，不會直覺想到「資料搬運變貴」。
2) 最常見的踩雷路徑（你可以先對照自己有沒有）
（A）跨 AZ：你以為都在同一個 Region 就免費
很多人把服務拆成多個 AZ 是為了高可用，但如果你的流量路徑設計得不乾淨， 例如：App 在 AZ-A、DB/Cache 在 AZ-B，請求一來一回就一直在跨 AZ。 平常流量小時你不會在意，一旦 QPS 上來，跨 AZ 成本就會「像水龍頭沒關緊」那樣持續滴。
（B）NAT Gateway 出網：你以為只是「讓 private subnet 上網」
NAT Gateway 通常是成本黑洞前幾名。原因很簡單：只要你的 private subnet 裡有東西需要出網， 例如拉更新、打外部 API、上傳到外部 endpoint、甚至某些 SDK 預設走公網路徑， 都可能一直從 NAT 出去。當你看到費用暴增，NAT 是第一個該懷疑的點。
（C）跨 Region：備援、複寫、資料同步
跨區複寫很合理，但它就是在「搬資料」。常見像： 物件儲存做跨區複寫、資料庫做跨區備援、甚至你自己寫的 batch job 每晚同步一次。 單次不貴，累積起來很可觀，尤其是資料量本來就大的團隊。
（D）你以為是「服務費」，其實是「資料搬運費」
這是最容易被忽略的：你看帳單看到某項服務費用上升，直覺以為是那個服務本身變貴， 但很多時候它的「周邊流量」才是重點。例如：log/metrics 大量外送、資料被多個服務讀取、跨網段拉取資源等。
3) 第一輪排查：不用把帳單看完，也能先縮小範圍
你可以先做一個很實際的動作：把自己從「我看不懂帳單」的焦慮，拉回到「我先找到哪條管子在漏水」。 第一輪排查的目標不是找出百分之百原因，而是把可疑範圍縮到你可以動手的程度。
- 帳單暴增的那幾天，有沒有剛上新功能/改網路/改部署策略？（尤其是跨 AZ 或新增 NAT）
- 近期流量是否明顯變多？（新客戶、新爬蟲、API 被打爆、或某個 job 卡住一直重試）
- 有沒有做跨區：備援、同步、複寫、或把資料送到別的區域做分析？
- private subnet 裡的東西是否大量出網？（容器拉 image、package update、打第三方 API）
4) 常見誤判（False positives）：不要一看到「流量」就亂砍
我看過不少團隊的第一反應是：「那我把跨 AZ 關掉、把東西都塞到同一個 AZ 好了」。 這樣做短期可能省錢，但你是在拿可用性換成本，代價可能更大。 更好的做法是先判斷：這筆流量是「必要的系統行為」還是「可以改善的路徑」。
- 必要的：像是你真的需要跨 AZ HA、真的需要跨區備援，那就應該想的是「怎麼更有效率地搬」。
- 可改善的：例如服務位置放錯、NAT 走太多、某個 job 沒設上限一直重試、log 外送沒有節制。
5) 下一步（What to do next）：把「可能原因」變成「可執行動作」
你可以把流量費的處理分成兩段：先找到大頭，再做架構上的微調。大多數情況不用大改， 常常是一兩個路徑修正、或把某些行為「從公網搬回私網」就能明顯下降。
- 優先順序 1：先確認有沒有
NAT Gateway相關的大量出網（通常最容易省）。 - 優先順序 2：釐清跨 AZ 的主要流量來源（是 App ↔ DB？還是某個 internal service？）。
- 優先順序 3：跨區同步/複寫是否過度（頻率太高、或同步了不必要的資料）。