CloudWatch 是什麼？為何會成為隱性成本來源？
CloudWatch 是 AWS 提供的監控與日誌服務，用來收集系統指標與應用程式日誌，協助企業進行監控與問題排查。簡單來說，它負責記錄雲端系統的運作狀況。在進行雲端成本優化時，企業通常會優先檢查主機、資料庫或流量費用，卻很少注意到 CloudWatch 中儲存的日誌。當日誌沒有設定保留期限時，就可能成為長期累積的隱性支出。
為什麼這筆成本容易被忽略？
- 日誌是系統正常運作的一部分，看起來「理所當然」
- 單價不高，不容易引起警覺
- 成本不是一次暴增，而是隨時間慢慢累積
隱性成本如何累計
多數 AWS 服務在建立時，會自動產生 Log Group，且預設保留期限為「永不過期」。這代表即使環境已不存在，日誌仍然持續儲存並產生成本。如下圖所示，畫面是以 RDS 為例，可以看到多個與 RDS 相關的 Log Groups，其保留期限皆為「永不過期」。這些日誌多半來自過去建立的測試或實驗環境，雖然 RDS 實例在測試結束後已經刪除，但對應的日誌群組仍然保留下來。
那麼可以怎麼做？
保留期限是「永不過期」，建議改為 30 天。這是一個簡單、低風險的成本優化動作。不用擔心會影響系統運作。保留期限只會清除超過天數的舊日誌內容（Log Event），不會刪除整個 Log Group，也不會影響服務本身。
如下圖所示，保留期限已調整為「1 個月」，代表系統只保留最近 30 天的日誌資料。如果公司有稽核或資料保存需求，也可以先將日誌匯出到其他儲存空間，再設定保留期限，兼顧合規與成本控管。
想了解 AWS 其他的節費方式可以參考：AWS 資料傳輸費用怎麼算？一篇搞懂定價與節費策略與AWS折扣全攻略：從EC2到全平台的成本節省方案
實際算給你看 CloudWatch Logs 如何計費？
CloudWatch Logs 看起來「昂貴」，其實問題不在單價，而在於資金使用效率。當日誌沒有設定保留策略，資料會隨時間不斷累積，你付的並不是必要成本，而是長期閒置的儲存費用。
CloudWatch Logs 主要包含三種費用，以亞太（新加坡）ap-southeast-1 當作參考標準：
1️⃣ 日誌寫入（Ingestion）
- 標準寫入：約 USD 0.7 / GB
- 不頻繁存取：約 USD 0.35 / GB
2️⃣ 日誌儲存（Storage）
- 約 USD 0.03 / GB / 月
3️⃣ 日誌查詢（Logs Insights）
- 約 USD 0.07 / GB
乍看之下，儲存單價不高，但真正的問題在於——日誌會「線性成長📈 」。但假設每天產生 100MB（0.1GB）日誌，每天 100MB 日誌，三年後的當月費用比較：
| 費用類型 | 永不過期方案（36 個月後當月費用） | 30天過期方案（36 個月當月費用） | 費用差異 |
|---|---|---|---|
| 寫入費 | 3GB × $0.70 = $2.10 | 3GB × $0.70 = $2.10 | ✅ 寫入量相同，因此費用不變 |
| 儲存費 | 108GB（3年累積） × $0.03 = $3.24 | 3GB（固定保留） × $0.03 = $0.09 | ⬆ 永不過期持續累積，差 105GB 費用差了$3.15 |
| 總費用 | $5.34 | $2.19 | 兩個方案差 $3.15（大約 59%） |
當系統規模變大、實例變多時，每天產生 5～10GB 日誌其實很常見。如果日誌設定為永不過期，這些資料會不斷累積，成本就像滾雪球一樣越滾越大。
注意：
寫入費其實一樣，真正拉開差距的是「儲存費」。
勤英科技的觀點：從企業營運場景出發
在多數企業的日常營運中，查看日誌通常發生在幾種情境：新功能上線前的測試驗證、例行性的系統巡檢、系統升級或修補時的相容性確認，以及突發故障時的問題排查。這些情境有一個共通點——幾乎都只會查看近期的日誌資料。
例如：
- 功能測試時，通常只會關注這幾天或這幾週的紀錄
- 日常巡檢，多半查看最近的異常或錯誤訊息
- 發生故障時，會回溯問題發生前後的時間區段
- 升級或修補系統時，也只會確認近期是否出現相依問題
在持續運作的系統中，日誌每天不斷產生、往前累積。時間越久的資料，被查閱的機會就越低，半年甚至一年前的日誌幾乎不會再被使用。但若設定為「永不過期」，這些舊資料仍會持續保留並計費。為低使用價值的歷史資料長期付費，正是「永不過期」成本偏高的真正原因。
若企業不確定目前的日誌設定與成本影響，勤英科技作為 AWS 認證代理商提供「雲端雙效健檢」服務，協助企業全面盤點雲端資源使用狀況，不僅找出日誌、儲存與流量等潛在成本浪費，同時檢視資安設定與風險暴露情形。透過成本優化與資安強化的雙重檢視，讓企業在控制雲端支出的同時，也確保系統安全與合規。
