「AWS 省錢」攻略幾乎只講 EC2。但 RDS、S3、Lambda 與資料傳出各按不同邏輯打折，且常是更大的賬單項。按服務拆開講，每項給判斷方法。
如果你搜「AWS 怎麼省錢」，看到的幾乎都是同一套內容：預留實例（RI）、節省計劃（Savings Plans）、Spot 競價。這三樣確實有效——但它們都是 EC2 及其計算類服務的折扣手段。
問題在於：EC2 往往不是你賬單裡最大的那一項。 資料庫（RDS）、物件儲存（S3）、資料傳出（Data Transfer）在很多業務裡佔比更高，而且它們的計費邏輯與 EC2 完全不同——把 EC2 的省錢方法套上去，一點用都沒有。
這篇按服務拆開，每個都給判斷方法和可執行動作，而不是羅列折扣名稱。（五家廠商的機制橫向擺在一起看，差異會更清楚：五家雲廠商折扣機制對比。）
為什麼「AWS 省錢」的文章都在講 EC2
因為 EC2 是入口服務，也是最多人接觸的服務。寫文章的人預設讀者在用 EC2，而 EC2 的折扣模型又恰好最清晰：承諾換價格，三個選項（RI / Savings Plans / Spot）對應三種確定性。
但真實賬單不長這樣。一個典型的中型業務，賬單結構往往是：
| 服務 | 常見佔比區間 | 折扣機制 |
|---|---|---|
| EC2 計算 | 30%–50% | 預留實例 / 節省計劃 / Spot —— 承諾換價格 |
| RDS 資料庫 | 15%–35% | 預留實例（承諾換價格）；引擎與實例族決定空間 |
| S3 與儲存 | 5%–20% | 不是折扣，是儲存類與生命週期的選型問題 |
| 資料傳出 | 5%–25% | 結構性最佳化（架構/快取），幾乎沒有「折扣」可買 |
| 其他（Lambda、SQS、監控等） | 5%–15% | 部分可被計算類節省計劃覆蓋 |
先說結論：EC2 的折扣是「買承諾」，S3 是「選層級」，資料傳出是「改架構」。三件事的方法完全不同，把它們混在一起談是這類文章最大的誤導。
如果你已經按 EC2 的方式做過一輪最佳化（比如我們另一篇講的 AWS 賬單最佳化 6 個做法），那接下來該看的就是這四項。
RDS：資料庫的承諾折扣比 EC2 更容易買錯
RDS 支援預留實例，邏輯與 EC2 類似：承諾 1 年或 3 年，換取相對按需的折扣，預付比例越高折扣越深。但 RDS 買錯的代價比 EC2 更大，原因有兩個。
第一，資料庫的規格變化頻率往往比應用伺服器低。 應用可以隨時擴縮容，資料庫因為涉及資料遷移，通常會鎖得很死。這聽起來是好事（更容易預測），但也意味著一旦買錯規格，這一年都得揹著。
第二，RDS 的折扣繫結的是「實例族 + 區域 + 引擎」。 比如你承諾了 db.m5 系列在某個區域的 MySQL，那麼：升級到 db.m6g（Graviton）不在覆蓋範圍內、換引擎不在覆蓋範圍內、跨區域也不通用。這三點比 EC2 的 RI 限制更嚴。
最常見的買錯方式：為了拿折扣，直接按當前最大的那臺實例承諾一年。但資料庫的壓力往往來自特定時段（批次任務、月末結算），峰值不等於常態。按 p95 或日均佔用來承諾，而不是按峰值。
判斷方法：在 RDS 控制檯看一段足夠長的歷史（至少覆蓋一個完整業務週期），確認日常佔用和峰值的差距。如果差得遠，先做的是降配或讀寫分離，而不是買承諾。
S3：不是折扣，而是把物件放到該放的層級
S3 沒有「承諾換折扣」這一套。研究 S3 成本，99% 的收益來自儲存類選型和生命週期規則，而不是任何折扣。
S3 的定價邏輯是：訪問越不頻繁、取回越慢、可用性越低，單價越便宜。 所以核心問題是——你存的東西，實際被訪問的頻率到底是多少？
- 經常訪問的：留在標準儲存，不要動它。往低頻層放反而會因為取回費用而更貴。
- 一個月碰幾次的：低頻訪問層（Infrequent Access）通常就能省下一部分，代價是有最低儲存時長要求。
- 幾乎不碰但要保留的：歸檔層，單價低很多，但取回需要等待（分鐘到小時級），且取回有單獨費用。
- 不想自己判斷的：S3 有個「智慧分層」選項，它會根據實際訪問模式自動在層之間移動物件，省去人工分類。適合訪問模式不穩定、又不想維護規則的情況。
可執行動作：先開啟 S3 的儲存分析（Storage Class Analysis）或訪問日誌，看實際訪問分佈——不要按「感覺」分類。很多人把「重要」當成「常訪問」，把冷備資料留在標準層付了好幾年高價。
另一條常被忽略的：版本控制與未完成的分片上傳。開啟版本控制的桶裡，刪除操作不會真正釋放空間；中斷的 multipart upload 也會一直佔著容量計費。這兩項用生命週期規則清理，通常能立刻見效。
儲存類的完整選擇方法（含各層的最低儲存時長與取回費用對比）寫在 S3 儲存類怎麼選 這一頁。
Lambda 與 Fargate：無伺服器也能吃到承諾折扣
很多人以為「無伺服器」就沒有折扣可談——按呼叫付費，用多少算多少。這個理解只對了一半。
AWS 的計算類節省計劃（Compute Savings Plans） 覆蓋的不只是 EC2 實例，還包括 Lambda 和 Fargate。它的邏輯是：你承諾每小時一定的計算消費額，AWS 用折扣價抵扣你的計算用量——無論這些用量來自 EC2、Lambda 還是 Fargate。
這意味著兩件事：
- 如果你的 Lambda 用量穩定（比如固定的定時任務、穩定的 API 流量），它可以被計算類節省計劃覆蓋，從而拿到折扣。
- 更實用的是反過來：計算類節省計劃不鎖實例規格，所以它天然適合「一部分 EC2 + 一部分 Fargate + 一部分 Lambda」這種混合架構。用一個承諾覆蓋三種計算資源，比分別買三份承諾更不容易買錯。
判斷方法：看過去幾個月的 Lambda 與 Fargate 消費是否穩定。如果波動很大（比如只在促銷期跑批），不要為它買承諾；如果有一條穩定的基線（每天固定的任務量），那部分就可以納入承諾範圍。只承諾穩態基線，彈性部分繼續按量付費。
計算類與實例類節省計劃的差別、以及怎麼和預留實例配合，見 節省計劃與預留實例怎麼選。
資料傳輸：賬單裡最容易被忽略的一塊
資料傳出（Data Transfer Out）是 AWS 賬單裡最容易被低估的一項。原因是它沒有「折扣」可買——沒有預留，沒有承諾計劃，只能從架構上減少。
它的計費邏輯大致是：入站通常免費，出站按流量收費；同一區域內跨可用區有少量費用；跨區域傳輸更貴。 所以成本往往出現在這幾個地方：
- 把大量資料從物件儲存直接送到公網（圖片、影片、下載包）——這是最常見的成本來源。
- 跨可用區的高頻通訊：微服務之間如果沒做拓撲最佳化，跨 AZ 呼叫的流量費會隨呼叫量線性增長。
- 跨區域的備份與複製：容災方案設計得很完善，但複製流量本身在持續計費。
- NAT 閘道器的流量處理費：很多人只注意到實例費用，忽略了按流量計費的那部分。
可執行動作（這裡沒有「買折扣」的捷徑，只有三類結構性最佳化）：
- 能快取的就快取。 把靜態資源交給 CDN，重複請求不會重複回源——這一項通常就是最大的一筆。
- 把跨 AZ 的呼叫改成本地優先。 讓服務優先訪問同可用區的依賴，跨區只作為兜底。
- 能放一起的就放一起。 如果兩個服務之間流量很大，把它們放進同一區域（甚至同一可用區）比最佳化程式碼更有效。
為什麼說它最容易被忽略：EC2 和 RDS 的賬單是「看得見的大塊」，資料傳出是「很多小塊加起來」。而按量計費的特性決定了——你不主動最佳化它，它就會隨業務自然增長。
把三類折扣串起來用
看完上面四項，你會發現 AWS 的成本最佳化是三類完全不同的問題：
| 型別 | 涉及服務 | 手段 | 關鍵動作 |
|---|---|---|---|
| 承諾換價格 | EC2、RDS、Lambda、Fargate | 預留實例 / 節省計劃 | 只承諾穩態基線，別按峰值買；優先用計算類節省計劃覆蓋混合架構 |
| 選型換價格 | S3 與各類儲存 | 儲存類 + 生命週期規則 | 用訪問資料分類，不按「感覺」；順手清理舊版本與中斷的分片上傳 |
| 架構換價格 | 資料傳出、NAT、跨區通訊 | 快取 / 拓撲 / 就近訪問 | 沒有折扣可買，只能改架構；優先做 CDN 與同區優先 |
順序很重要：先做「架構」和「選型」（不需要承諾，隨時可做、無風險），再做「承諾」（一旦買了就是一年）。很多人順序反了——先急著買預留實例拿折扣，結果規格買錯，鎖住一年。
最後補充一點關於代理渠道的：上面講的全是「官方折扣」（AWS 直接給你的）。除此之外還有一條路是透過代理商開通與結算——它降低的是你的實際支付金額，與官方的預留實例、節省計劃不衝突，可以疊加。這部分邏輯寫在 AWS 折扣與代理定價 裡。
別忽略順序：代理折扣作用在你付給代理商的錢上，官方折扣作用在AWS 給你的賬單單價上。兩者在不同層面，所以可以同時享受——不是二選一。
常見問題
RDS 該買預留實例還是走節省計劃？
如果資料庫的實例族和區域在一年內確定不變，預留實例的折扣更深。但要注意 RDS 的預留繫結「實例族 + 區域 + 引擎」三項，任何一項要變，承諾就浪費了。如果存在升級到 Graviton 或換引擎的可能，先別買長期承諾，或者只承諾一個季度到半年的用量觀察。
S3 的智慧分層值得開嗎？
取決於你的訪問模式是否可預測。如果資料有明顯的冷熱分層（比如日誌三個月後基本不再訪問），手工配生命週期規則通常更省錢，因為你能精確控制。如果訪問模式不穩定、又沒人維護規則，智慧分層省心且不會虧——它有個小額的監控與自動化費用，資料量很大時才需要權衡。
資料傳出真的完全沒有折扣嗎？
沒有「承諾換折扣」這一類。但有兩個間接方向：一是用 CDN 把出站流量轉成 CDN 的回源流量，通常單價更低；二是部分服務之間的流量在特定條件下不計費（例如同一區域內透過私有網路訪問部分服務）。這兩條都需要按具體架構評估，不存在通用答案。
Lambda 的用量怎麼判斷該不該買承諾？
看基線，不看總量。把過去 3 個月的 Lambda 消費按天排列，找出每天都發生的最低那部分——那才是可以承諾的。只在特定日期跑的任務（月末結算、定時報表）不要納入承諾，它們用按量付費更划算。
這幾項最佳化，從哪一項開始價效比最高？
按「不需要承諾」優先：先清閒置資源和未掛載的磁碟 → 再看 S3 的儲存分佈與生命週期 → 然後看資料傳出的架構。前三項都不需要你做任何承諾，隨時可做、也無風險。等這些都做完，賬單項的構成清楚了，再去買預留實例和節省計劃——那時你知道該承諾多少。