AWS 的流量費不是一項，而是按「走了哪條路」分成好幾種：出網、同區域跨可用區、跨區域，再加上路徑上的 NAT 閘道器。同一對機器在同一個可用區裡用私有 IP 免費，換成公有 IP 就要按 GB 雙向收費。
AWS 的流量費是最容易失控的一項——它不像實例那樣有明確的單價和數量，它是按「這批位元組走了哪條路」分別計費的。
所以你會看到很反直覺的現象：兩臺機器在同一個可用區裡，走私有地址互傳資料不花錢，走公有地址就要按 GB 付費——而這兩種走法的物理路徑可能完全一樣。
這篇把「到底有幾種流量在收費」拆開，再給每條邊界的省法。定位方法（怎麼在賬單裡找到是誰在傳）在 AWS 賬單突然變高怎麼排查 裡已詳細寫過，這裡不重複。
心智模型：按「路徑」收費，不按「距離」
一句話：AWS 收的是路徑費，不是距離費。同一批位元組，走私有 IP 穿過可用區內部是免費的，繞出去經過 NAT 閘道器就變成三層收費疊加。改成哪條路，比改傳輸量更有效。
理解這一點之後，很多「為什麼同一區域內傳資料還收費」的疑問就有答案了——不是因為在傳，是因為你把它放到了收費的那條路上。
六個計費邊界一覽
官方把跨網路位置的傳輸分成三類（出網 DTO、同區域跨可用區 DTAZ、跨區域 DTIR），再加上路徑上那幾個「中轉服務」自己的資料處理費，合起來是六個邊界：
| 邊界 | 什麼情況下觸發 | 計費方式 |
|---|---|---|
| 1 出網到網際網路（DTO） | 區域內的資源往公網發資料 | 按 GB，有月度免費額度 |
| 2 同區域跨可用區（DTAZ） | 同一區域內，兩個可用區之間傳資料 | 每個方向都計費 |
| 3 跨區域（DTIR） | 從一個區域傳到另一個區域 | 按 GB，只按源區域收費 |
| 4 NAT 閘道器 | 私有子網的流量經由 NAT 閘道器出去 | 資料處理費，雙向，疊加在上面幾項之上 |
| 5 Transit Gateway | 多個 VPC 之間經由中轉閘道器互連 | 資料處理費，即使是同區域流量 |
| 6 公有 IPv4 地址 | 用公有 / 彈性 IP 通訊（包括同一個 VPC 內部） | 每個方向都計費 |
注意第 4、5、6 條的共同點：它們不是「流量費」，而是「因為你走了這條路而產生的附加費」——這正是它們容易被漏掉的原因，因為賬單上它們往往散落在不同服務名下，看起來不像同一件事。
邊界一：出網到網際網路
這是最貴、也最廣為人知的一項：區域內的資源把資料發到公網，按 GB 計費，而且是分檔遞減的——用量越大單價越低。
官方定價頁上有一項很有用、但很少被提到的資訊：
- 每月有一定額度的免費出網流量，而且是跨所有 AWS 服務與區域聚合計算的（中國區域與 GovCloud 除外）——不是每個服務、每個區域各送一份。
- 計費只看源區域：資料從哪個區域流出去，就按那個區域的費率算，接收方所在區域不重複收一次。
- 出網用量特別大的企業可以向 AWS 單獨溝通費率——以官方渠道為準。
對做面向公網的服務的人來說，這一項的大頭通常是靜態資源與下載。所以下面第五節的省法裡，把這一項交給 CloudFront 是最直接的。
邊界二：同一區域內跨可用區（最反直覺的一條）
這條是本文最值得記住的一段，因為它違反大多數人的直覺：同一個區域內部，兩個可用區之間傳資料是要收費的，而且每個方向都收。
關鍵在於，官方文件對「什麼時候免費」的定義非常具體：
| 同一區域內的情形 | 是否收費 |
|---|---|
| 同一可用區內，用私有 IP 通訊 | 免費 |
| 同一可用區內，用公有 / 彈性 IP 通訊 | 收費（每個方向都計費） |
| 跨可用區（無論私有還是公有 IP） | 收費（每個方向都計費） |
| 同區域內，EC2 與 S3 / DynamoDB / SQS / ECR 等直接傳輸 | 免費 |
| 但路徑中經過 NAT 閘道器 / Transit Gateway / PrivateLink 端點 | 會產生這些服務自己的資料處理費 |
⛔ 第 1 行和第 2 行的對比是整篇最反直覺的地方：兩行描述的是同一對資源、同一個可用區，唯一區別是「用私有地址還是公有地址去連它」——走公有地址就要按 GB 雙向付費。這不是距離收費，是路徑收費。很多團隊習慣用公有端點連自己 VPC 內的資料庫或快取，憑空產生了這筆費用，而且沒有任何功能上的好處。
還有一條容易踩的：多可用區部署本身是官方推薦的高可用做法，但跨可用區的持續流量是要付費的。高可用的架構設計和流量成本之間，需要一個明確的取捨（見下面的省法二）。
順帶一個例外，值得記住：應用型與傳統型負載均衡器沒有跨可用區費用，但網路型負載均衡器對跨可用區到目標的流量是收費的——所以如果你的架構裡用了 NLB 並且開了跨區負載均衡，值得單獨確認一下這項。以官方定價頁為準。
邊界三：跨區域
跨區域傳輸比同區域跨可用區更貴，而且費率隨區域對的不同而變化。它最容易出問題的地方不在「偶爾傳一次」，而在持續複製：
- 跨區域資料庫複製：只要副本存在，複製流量就一直產生，而且是持續計費的。
- 跨區域物件儲存複製：同理，資料越多、更新越頻繁，費用越持續。
- 多區域主動架構：每兩個同步的區域之間都有一份流量。
這裡的判斷標準不是「要不要容災」，而是「這個業務真的需要跨區域切換嗎」。只想解決機房級故障的話，同區域多可用區通常就夠了，成本差一個量級。
另外，跨區域的流量同樣只按源區域計費（接收方不重複收），這個規則在估算時很有用：你只需要知道資料從哪兒出去。
邊界四到六：NAT 閘道器、Transit Gateway、公有 IPv4
這三個不是「流量單價」，而是路徑上的附加費，也是賬單裡最容易被忽略的部分——因為它們散落在不同的服務名下，看起來不像同一件事。
- NAT 閘道器：按處理的資料量收費，而且是雙向的——進去和出來都算。它最典型的浪費場景是：私有子網的機器去訪問 S3 或 DynamoDB，流量繞出 VPC 再繞回 AWS 網路，於是你同時付了 NAT 的處理費和出網費。而這件事有一個免費的解法（見省法一）。
- Transit Gateway：多個 VPC 互連時用它，但它有資料處理費，即使是同一個區域內的流量也要付。如果只是幾個 VPC 互連，直接的對等連線更便宜；中轉閘道器的價值在連線數量多到對等連線管不過來的時候。
- 公有 IPv4 地址：官方已明確所有公有 IPv4 地址都開始收費（2024 年 2 月起生效）。這一條對「順手給每臺機器掛個公網 IP」的習慣影響很大——很多機器根本不需要公網地址，它只需要能被負載均衡器訪問，或者在私有子網裡待著。
一個自查問句：這臺機器真的需要公網地址嗎？如果它只在私有子網裡接收內網流量，一個公有 IPv4 對它是純粹的額外成本。把「預設給公網 IP」改成「按需才給」，往往是這類費用最乾脆的減法。
五條能立刻落地的省法
按「改動成本 ÷ 省下來的錢」排序，前兩條通常不需要動架構：
- 給 S3 與 DynamoDB 建閘道器型 VPC 端點。 這是價效比最高的一條：它免費，卻能把「私有子網訪問 S3 走 NAT 閘道器」這個最典型的浪費直接消掉。做完之後，原本那批流量不再經過 NAT，也就不再產生 NAT 的處理費與出網費。
- 檢查應用是不是在用公有端點連同一個 VPC 內的資源。 資料庫、快取、內部服務——如果連線串裡寫的是公有地址或彈性 IP，把它換成私有 DNS 名稱。零成本、零風險，而且立刻生效（對應邊界二的第 2 行）。
- 靜態內容與 API 響應走 CloudFront。 三個好處疊加：從 S3 到 CloudFront 的傳輸是免費的、CloudFront 自己的出網費率低於直接出網、而且 CloudFront 每月有獨立的免費出網額度。但要注意前提：如果快取命中率低（快取規則配得不對、頻繁重新整理），源站回源流量照樣按原價產生——收益來自快取命中，不是來自接上 CloudFront 這個動作本身。
- 開啟壓縮。 文字類響應（JSON、HTML、JS）壓縮後通常能小 60%–80%，而所有按 GB 計的費率都會同比下降。這是配置改動，不是架構改動。
- 把頻繁互調的服務收進同一個可用區。 對每毫秒都在互相呼叫的服務（而不是偶爾調一次），讓它們盡量落在同一個可用區內，跨可用區只用於故障轉移而不是日常通訊。代價是可用性設計需要重新權衡——所以這條排在最後，因為它不是純賺。
還有一個前提性動作：先把標籤打全。沒有標籤的話，你會在賬單裡看到一筆流量費，卻不知道是哪個環境、哪個團隊產生的——省法再好也落不到具體物件上。上面五條都只針對流量；實例、磁碟、資料庫層面的做法見 AWS 賬單看不懂？6 個可執行做法。
常見問題
資料傳進 AWS 收費嗎？
不收費。入站（data ingress）是免費的，公網上的資源把資料傳進 AWS 不產生費用。所有收費項都在「出去」和「繞路」這兩件事上——記住這一點，很多猜測可以立刻排除。
同一個區域內的機器互相傳資料，為什麼會收費？
兩種情況：一是跨了可用區（每個方向都計費，這是官方明確的規則）；二是在同一個可用區裡但用了公有 / 彈性 IP 通訊——同一對資源換成私有 IP 就是免費的。這是最值得去程式碼裡查一遍的一條。
我已經有免費額度了，為什麼還在收錢？
因為免費額度只覆蓋出網到網際網路這一項，而且它是跨所有服務與區域聚合計算的（不是每個服務各送一份），中國區域與 GovCloud 還不適用。跨可用區、跨區域、NAT 閘道器處理費這些不佔用這個額度。
流量費佔賬單多少算正常？
行業觀察給出的區間大致是普通 Web 或 API 型負載 6%–12%，資料密集、多區域或流媒體類負載超過 20% 也不罕見（這類比例來自第三方調研，不是官方口徑，僅作量級參考）。如果你的佔比明顯高於同類負載，問題通常不在流量本身，而在路徑選錯了——回去看邊界二和邊界四。
怎麼查到底是哪個資源在傳？
兩步：先在 Cost Explorer 裡按用量型別分組（出網、跨可用區、NAT 處理量在賬單上是不同的條目），再用 VPC 流日誌定位到具體的資源與可用區組合。完整流程寫在 AWS 賬單突然變高怎麼排查 裡。
其他雲廠商也這樣收費嗎？
流量費是五家的共同成本項，但機制與減免方式各不相同——有的把出網額度打包進產品（比如輕量型產品通常自帶流量包），有的在渠道側能讓利。橫向對比見 五家雲廠商折扣機制對比；如果你只是想降低「實際支付的金額」而不改架構，那是另一個層面的事，見 AWS 折扣與代理定價。