跨 AZ，而不是跨 Region。
跨 AZ 像是同一個城市不同區之間搬貨，路很短但次數很多，帳單照樣會長。
1) 為什麼跨 AZ / 跨 Region 會花錢？它花的不是距離，是「邊界」
你不需要背費率，記住一個概念就好：AWS 的計費常常不是看「遠不遠」，而是看「有沒有跨到某個邊界」。 AZ 是邊界、Region 更是邊界。你跨過去，AWS 就開始把它當成一種有成本的資源行為。
這也是為什麼跨 AZ 特別容易被忽略：大家很自然會把 Multi-AZ 當成預設做法，
但如果你的服務之間聊天太頻繁、資料太大、或是路徑沒控好，就會變成一條長期滴水的成本管線。
2) 最常見的跨 AZ 成本來源（很多團隊都是這幾個）
（A）App 與資料層不在同一個 AZ：你以為只是 HA，結果是天天跨區聊天
很多架構是這樣長出來的：App 做多 AZ、資料庫也做多 AZ，然後流量由 LB 分配。 如果你的連線與資料存取習慣讓 App 常常打到「不在同一個 AZ 的那邊」，跨 AZ 就會一直發生。 它不會爆炸式成長，但它會在你不注意的時候把月成本往上推。
（B）東西放在多個 AZ，但你沒有控制「就近性」
很多服務其實可以做到就近存取（或至少減少跨 AZ），但實務上你可能沒有設計這段： 例如某些 worker 不分 AZ 拉資料、cache 沒做 locality、或是服務 discovery 讓連線亂飄。 結果就是：你的架構明明看起來很 HA，但流量路徑很「隨緣」。
（C）內部大量資料交換：log、metrics、事件、同步
這是比較容易被忽略的一種：大家盯著業務流量，但真正的大頭可能是內部資料交換。 例如某個 pipeline 把東西從 A 傳到 B、再傳到 C；或 log/metrics 的集中收集跨了 AZ。 當你把系統拆得越細，這類「內部搬運」越容易變多。
3) 跨 Region：通常不是「壞事」，但要知道你在付什麼代價
跨區做備援、做複寫、做資料同步，本來就是合理的工程選擇。 問題是：你可能沒有把「同步的範圍」跟「同步的頻率」想清楚。 你如果把所有資料都當成必須跨區複寫、而且還是近乎即時，那成本自然不會客氣。
- 跨區複寫：資料量越大、頻率越高，成本越像固定支出。
- 跨區分析/ETL：如果每天搬一份全量資料，通常很快就會被帳單教育。
- 跨區服務相依：一邊在 A、一邊在 B，請求一來一回就變成長期跨區聊天。
4) 第一輪排查：先用「路徑」思考，不要先用「服務名」思考
很多人排查時會先看 Cost Explorer 的服務分類，然後卡住：看到了 Data Transfer，但不知道下一步。 我覺得更好用的做法是先用「路徑」想： 哪一段流量在跨邊界？跨的是 AZ 還是 Region？為什麼要跨？
- 最近有沒有做 Multi-AZ 調整、或把某些服務拆到不同 AZ？
- App ↔ DB/Cache 的存取路徑是否「就近」？還是隨機打到另一個 AZ？
- 是否有大量內部搬運（log/metrics/pipeline）跨了 AZ？
- 跨區同步/複寫是否全量、是否過於頻繁？
- 是否有跨區服務相依（A 區的服務不停打 B 區的 API）？
5) 常見誤判：省錢不是把 HA 拿掉
最常見的「過度反應」是：看到跨 AZ 成本就想把所有東西塞回單一 AZ。 這樣短期可能省到錢，但你其實是把可用性風險放大。 更務實的做法通常是：保留 HA，但把路徑變乾淨，讓跨 AZ 只在「必要」時才發生。
6) 下一步：降費方向（你可以先從最不痛的開始）
- 先找出最大頭路徑：到底是 App↔DB、還是內部 pipeline、還是跨區同步？先抓出來才有下手點。
- 把就近性做出來：能就近就近，能留在同 AZ 就留在同 AZ，至少把「隨緣跨 AZ」拿掉。
- 跨區同步先做稀疏化：先把頻率與範圍縮小（不要每天全量、不要每分鐘全量），通常立刻有感。
- 把內部搬運當成要管理的資源：log/metrics/pipeline 有時候才是大頭，別只盯業務流量。