日誌費用由攝取、儲存、分析三塊組成。而最要命的一點是：日誌類在建立日誌組時選，之後改不了——選了標準類再想換成低頻訪問類，只能重建。還有幾條官方給的省錢機制多數人不知道。
日誌費用是賬單裡最典型的「沒被設計的用量」：它隨功能增加而自然增長，卻不像實例那樣有人主動選規格、選付費方式。等你注意到它時，它往往已經是某個服務下面最大的一行。
這篇按「錢花在哪 → 哪個決定不可逆 → 官方給了哪些省錢機制」的順序講。日誌費用也常是賬單突然上漲的原因之一，定位方法見 AWS 賬單突然變高怎麼排查。
日誌費用由三塊組成：攝取、儲存、分析
理解這三個維度，後面所有省法都能歸類：
| 維度 | 按什麼計費 | 什麼時候產生 |
|---|---|---|
| 攝取（寫入） | 按寫入的資料量 | 應用和 AWS 服務往日誌組裡寫日誌時 |
| 儲存（留存） | 按儲存的資料量與時長 | 日誌留下來之後持續產生 |
| 分析（查詢） | 按掃描的資料量或會話時長 | 你用查詢工具檢索日誌時 |
這三塊的性質完全不同，所以省法也不同：攝取是「一次性」的，寫進去就寫進去了；儲存是「持續」的——官方部落格的原話是攝取只發生一次，但儲存費用會伴隨資料整個生命週期累積，合規場景下可能是數年；分析則是「你主動查才產生」。最容易失控的是中間那個，因為它在你什麼都不做的時候也在漲。
建立時就定死的那個選擇：日誌類
這是本文最值得記住的一條，也是官方文件裡明確寫著、但很多人在建日誌組時並不知道的一條：
⛔ 日誌類（Log Class）只能在建立日誌組時選擇，之後無法更改。 如果你當時隨手用了預設值，事後想換，只能新建一個日誌組——這意味著舊的日誌組也不會自動消失，你很可能兩邊都在付費。
兩種日誌類的取捨很直接：
| 日誌類 | 能用的功能 | 攝取成本 |
|---|---|---|
| Standard（標準） | 完整功能：指標篩選、訂閱篩選、欄位索引、實時跟蹤、嵌入指標等 | 基準價 |
| Infrequent Access（低頻訪問） | 功能較少 | 通常約為標準類的一半 |
官方部落格給的判斷方法很實用，照抄下來就是：
- 需要「資料一到就實時告警或處理」→ 選標準類。 這是標準類不可替代的地方。
- 資料主要是為了審計、合規而長期留存 → 選低頻訪問類。 官方明確說它適合大多數用例。
一個立刻能做的動作：把現有日誌組按「是否需要實時告警」過一遍。新建的日誌組從一開始就選對——這是零成本的。而對已有的日誌組，要提醒自己：改用另一類的代價是重建，所以先算清「省下的攝取費」和「重建帶來的麻煩」哪個大。具體單價以官方定價頁為準。
儲存會自動變便宜：智慧分層
儲存那一塊有一項不需要你配置的機制：智慧分層（Intelligent Tiering）。它按「你多久沒訪問過這些資料」自動把儲存分成三檔：
| 儲存檔位 | 觸發條件 |
|---|---|
| 標準層 | 最近 30 天內訪問過 |
| 低頻訪問層 | 31–90 天未訪問 |
| 歸檔即時訪問層 | 91 天以上未訪問 |
兩個細節值得單獨講，因為它們決定了這個機制到底有沒有用：
- 被訪問後會重新歸類並重置計時。 也就是說，你偶爾查一次某個日誌組，它的資料就會回到標準層重新開始計時。所以「例行去翻一下歷史日誌」這件事是有成本的——官方也建議不要頻繁訪問日誌。
- 它與日誌類是兩件不同的事，別混淆。 官方特別說明過：儲存檔位由訪問模式自動決定、對所有日誌組生效，與你在建立時選的日誌類無關。也就是說「日誌類選錯了」和「儲存檔位」是兩個獨立問題。
一個容易誤會的點：日誌的儲存費用不是按你看到的原始日誌量算的——儲存會按約 0.15 的壓縮比計費，也就是實際計費的 GB 明顯小於原始日誌量。所以從「我每天寫 10GB」直接推算儲存費會高估。
容易被忽略的三件事：壓縮比、保留策略、用量監控
這三件事都不花錢、也不需要改架構，但直接決定儲存那塊的賬單：
- 保留策略（Retention）決定儲存的終點。 它規定日誌留存多久，到期即永久刪除——這是唯一能真正「截斷」長期儲存成本的設定。不設保留策略，等於預設無限期留存。
- 監控寫入量，而不是隻看賬單。 官方建議在 CloudWatch 圖表或儀錶盤上觀察工作負載產生的日誌量，並明確給出了排查方向：先找出是哪個日誌組導致賬單突然增加。
- 從日誌本身降量。 官方給的第一條建議是「只記錄有業務價值的事件，並使用高效的日誌語法」——把日誌級別調對、去掉冗餘輸出，是直接減少攝取量的辦法。
⛔ 保留策略是最容易被「預設值」坑到的一項：如果不主動設定，日誌會一直留著並持續計費。而它恰恰是成本最佳化裡最容易見效、風險最低的一個動作——因為你通常並不需要三年前的除錯日誌。設定前唯一要確認的是：有沒有合規要求強制你留存更久。
VPC 流日誌：官方建議發往 S3
有一條官方給的、很具體的建議值得單獨拎出來：
如果你用 VPC 流日誌是為了審計和合規，官方建議把它發往 S3，而不是 CloudWatch。 反過來，如果你需要指標篩選、訂閱篩選、日誌查詢、貢獻者洞察這些實時分析功能，那才應該發往 CloudWatch。
這條建議的價值在於：VPC 流日誌是資料量最容易失控的一類日誌（它記錄網路流量），如果誤以為「日誌就該發 CloudWatch」，很可能在不知不覺中產生一大筆攝取與儲存費用。做選擇時先問一句：我要的是「事後審計」還是「實時分析」？ 前者去 S3，後者留 CloudWatch。流量本身的收費機制見 AWS 流量費為什麼這麼貴。
還有幾處容易漏掉的計費項
官方文件還列了幾項「不用就沒事、用了就計費」的功能。它們單項都不大，但疊加起來很常見：
| 計費項 | 觸發條件 |
|---|---|
| 日誌查詢 | 按掃描的資料量計費——查詢的時間範圍越長，掃描量越大 |
| 實時跟蹤 | 按會話時長計費，所以盡量縮短單次會話 |
| 貢獻者洞察規則 | 每月超過 1 條規則，或每月超過一定數量的匹配事件即計費 |
| 合成監控（Canary） | 每月執行超過一定次數即計費，且每次執行還會帶動其他服務產生費用 |
| 儀錶盤 | 免費方案只有有限數量的儀錶盤，超出即計費 |
| 容器洞察 | 按採集的指標與攝取的日誌資料計費 |
一個通用省法：查詢時把時間範圍設短。官方明確說，縮短查詢的時間範圍能減少掃描的資料量、從而降低分析費用。這個動作零成本，只是改變一下習慣。
常見問題
日誌已經寫進去了，還能少付儲存費嗎？
能，主要是三件事：設定保留策略（到期自動刪除，這是最直接的）、依賴智慧分層（長時間不訪問會自動降到更便宜的檔位）、以及避免為了「隨便看看」而頻繁查歷史日誌（訪問會把資料重新拉回標準層並重置計時）。
日誌類選錯了怎麼辦？
不能在原日誌組上改——官方說明它只能在建立時選擇。要換只能新建日誌組並把寫入切過去。所以先算一筆賬：新方案省下的攝取費，是否值得重建的麻煩。而新建日誌組時把它選對，是完全沒有成本的。
怎麼查出是哪個日誌組在花錢？
兩條路：一是用成本分析工具按服務篩選 CloudWatch、再把維度切成資源（注意用這種方式只能看最近一段時間的用量）；二是用成本與用量報告配合查詢工具，按資源 ID 聚合出「哪個日誌組的哪個計費項最貴」。後者更徹底，適合做一次性的大清理。整體排查思路見 AWS 賬單突然變高怎麼排查。
日誌存到別的地方會不會更便宜？
要分場景。官方明確建議：為審計與合規而採的 VPC 流日誌，發往 S3 更合適；而需要實時篩選、告警、檢索的場景，留在 CloudWatch 才用得上那些功能。也就是說這不是「哪個絕對便宜」的問題，而是「你到底要用它做什麼」的問題。
日誌費用算不算「折扣」能覆蓋的部分？
它屬於用量本身，所以降低它的方式主要是「少寫一點、少留一點、少查一點」，而不是靠折扣。不過節省計劃這類承諾折扣覆蓋的是計算類用量，不改變日誌這塊的計費邏輯——所以別指望用折扣來治日誌費用。折扣那一層能做什麼，見 AWS 優惠全覽；整體成本最佳化的做法見 AWS 賬單看不懂？6 個可執行做法；我們自己的渠道側做法見 AWS 折扣與代理定價，五家廠商的機制差異見 五家雲廠商折扣機制對比。