在雲端運維與監控的世界裡，CloudWatch Logs 是 AWS 上不可或缺的工具。
它不僅能協助你收集與儲存系統日誌，還能針對錯誤或異常自動發出警示。
而「日誌群組（Log Group）」正是這套系統中的核心概念之一。
本篇文章將帶你一步步認識什麼是 CloudWatch 的日誌群組、它的用途、如何建立與管理，並以實際操作與情境應用作結，讓你從 0 到 1 熟悉這個重要功能。
什麼是 CloudWatch Logs？
CloudWatch Logs 是 AWS 提供的雲端日誌收集與監控服務，屬於 CloudWatch 系列功能中的一部分。
它的主要目的是幫助使用者集中管理、儲存、查詢與分析各種系統與應用的日誌資料，無論是開發、測試或正式環境都能派上用場。
在傳統架構中，我們可能需要登入每台伺服器，手動查看 /var/log 資料夾內的 log 檔案。
但在 AWS 雲端環境中，透過 CloudWatch Logs，就能將所有日誌集中在同一個平台上，並進行統一管理。
CloudWatch Logs 的核心功能
📥 收集來自多個 AWS 服務的日誌
CloudWatch Logs 可自動整合 AWS 上的多種服務，包含但不限於：
- EC2：透過 CloudWatch Agent 將系統或應用日誌上傳
- Lambda：每次執行都會產生日誌並自動傳送到對應的 Log Group
- API Gateway：可將存取與錯誤日誌匯入 CloudWatch
- VPC Flow Logs：記錄網路流量資訊
- RDS Logs、CloudTrail、ECS 等其他服務
👉 不管資料來自哪裡，CloudWatch Logs 都能集中收集。
💾 儲存與查詢日誌資料
所有上傳到 CloudWatch 的日誌會被存放在「Log Group」中。你可以：
- 使用時間範圍搜尋
- 關鍵字過濾（如搜尋
ERROR、user_id=123） - 依不同的服務或實例分類日誌資料（Log Stream）
🔍 查詢操作可以透過 AWS Console 介面完成，也能透過 CLI、API、SDK 自動化處理。
🚨 設定條件式警示（Alarm）
你可以對特定日誌設定Metric Filter（篩選器），當內容符合某條件時（例如出現 “OutOfMemory” 或 HTTP 狀態碼 500），就能觸發：
- SNS 通知（例如寄 email、發簡訊）
- Lambda 自動處理
- 自訂警示儀表板顯示
這使得 CloudWatch Logs 不僅是「被動收集」，更能主動協助偵測與回應異常狀況。
為什麼要使用 CloudWatch Logs？
使用 CloudWatch Logs 的三大優勢：
日誌群組（Log Group）是什麼？
在 CloudWatch Logs 的架構中，Log Group（日誌群組） 是組織與管理日誌的核心單位，可以幫助你釐清「這些日誌是從哪個應用或模組來的」，並進一步控管儲存時間與權限。
每一個 Log Group 都代表一個邏輯上獨立的日誌集合，底下再細分為多個 Log Stream（日誌串流）。
Log Group 是什麼？
Log Group 就像是一個「分類資料夾」，你可以針對不同的服務、應用模組或環境（如開發、測試、正式）建立獨立的群組。
例如：
/myapp/dev/myapp/prod/aws/lambda/my-function/ecs/web-service
每個 Log Group 都具有以下特性：
Log Stream 是什麼？
Log Stream 是 Log Group 底下的實際資料來源，也就是一段段的日誌紀錄。
每個 Log Stream 通常對應一個具體執行來源，例如：
- 一個 EC2 實例（依實例 ID 命名）
- 一次 Lambda 執行（會產生一個新的 stream）
- 一個 ECS container 執行單元
- 某個 log agent 傳入的檔案資料
👉 當應用程式開始寫入日誌時，CloudWatch 會自動為該來源建立或更新對應的 Log Stream。
✅ 簡單比喻（讓你秒懂）
範例情境：開發者如何使用 Log Group？
假設你是一位開發者，正在開發一個線上商城 Web 應用，部署在 AWS 上，你可能會建立以下 Log Group 結構：
/shop-app/dev：用來接收開發環境的應用日誌/shop-app/prod：正式環境的主要 Log Group/aws/lambda/payment-handler：處理付款的 Lambda 函式日誌/ecs/shop-frontend：前端服務的容器日誌/ecs/shop-backend：後端 API 的容器日誌
每個 Log Group 下會隨著執行實例不同自動建立 Log Stream，例如：
/shop-app/prodi-1234567890abcdef0（EC2）i-9876543210abcdef1（另一台 EC2）/aws/lambda/payment-handler2025/06/05/[$LATEST]abcdef1234567890...
📌 為什麼要善用 Log Group？
🧠 小提醒：命名策略建議
為了讓日誌管理更清晰，建議使用以下命名格式：
/應用程式名稱/環境/模組（可選）例如：
/myapp/dev/myapp/prod/payment/myapp/prod/authentication
這樣不僅便於搜尋與維護，也有助於日後自動化清理、警示設定與 IAM 權限管理。
如何建立與管理日誌群組（Log Group）？
CloudWatch 的日誌群組（Log Group）雖然看似只是一個「資料夾」，但它的建立與設定，攸關後續的資料收集效率、儲存成本、監控管理與警示運作。
AWS 提供了三種主要方式來建立與管理 Log Group：
- 透過 AWS 管理控制台（Console）
- 使用 AWS CLI（指令列介面）
- 透過 SDK 自動化（如 Python boto3） — 本篇先聚焦前兩者，適合手動操作與日常維運使用。
方法一：使用 AWS Console 建立 Log Group
這是最適合初學者的方式，透過圖形化介面操作簡單直觀。
- 登入 AWS 管理控制台（https://console.aws.amazon.com/）
- 在服務搜尋欄輸入 CloudWatch 並點擊進入
- 左側選單中選擇「Logs > Log groups」
- 點擊右上角的「Create log group」按鈕
- 在「Log group name」欄位中輸入名稱，例如：
/my-app/production⛳ 建議使用階層式命名，有助於分類與搜尋（例如 /應用/環境）
- 選擇日誌的保留天數（Retention），例如「30 天」、「1 年」，或選擇「永遠保留」
- 設定保留天數有助於控管儲存成本與資安法規遵循
- 點擊「Create」，完成建立！
🎉 恭喜！你已成功建立一個 Log Group，可以開始接收日誌資料。
使用 AWS CLI 建立 Log Group
若你習慣在本地或遠端機器上進行部署與自動化，使用 AWS CLI 是更快速且彈性的方式。
📌 前置條件：
- 安裝並設定好 AWS CLI（含
aws configure完成認證與預設區域） - 具備對 CloudWatch Logs 的 IAM 權限（至少要有
logs:CreateLogGroup與logs:PutRetentionPolicy）
🔧 建立 Log Group 指令：
aws logs create-log-group \
--log-group-name /my-app/production🗓️ 指定保留天數：
aws logs put-retention-policy \
--log-group-name /my-app/production \
--retention-in-days 30🧠 可接受的
--retention-in-days數值有：1、3、5、7、14、30、60、90、120、150、180、365、400、545、731、1827、3653 等
🧽 移除保留設定（改為永遠保留）：
aws logs delete-retention-policy \
--log-group-name /my-app/productionLog Group 管理建議：打造穩定、可控的日誌架構
建立 Log Group 僅是第一步，真正的挑戰是「如何長期維運與有效管理」。
若未妥善規劃命名、保留策略、權限控制與清理機制，隨著日誌資料量暴增，你可能會遇到以下問題：
- 找不到正確的日誌來源（命名混亂）
- 不必要的儲存費用增加（資料保留過長）
- 權限濫用造成資安風險（誰都能建立或刪除）
- 系統中堆積了過時、不再使用的 Log Group
為避免這些問題，我們整理出四個核心管理面向，並附上具體建議如下：
命名規範：讓日誌架構有條理、易搜尋
建議命名格式：/服務名稱/環境別/模組（可選）
範例：
/shop-app/dev/shop-app/prod/payment/internal-tools/staging/auth
這樣命名有幾個好處：
💡 命名注意事項：
- 僅接受字母、數字、斜線
/、底線_、破折號- - 避免使用相同名稱但不同大小寫（AWS 名稱是區分大小寫的）
保留設定：控制成本、遵守法規、避免資料膨脹
CloudWatch Logs 支援自訂保留天數，這是控制儲存空間與成本的關鍵設定。
建議做法：
❗ 預設情況下，Log Group 不會自動刪除日誌，會無限制地永久儲存，可能導致不必要的費用。
🧰 CLI 設定保留天數範例：
aws logs put-retention-policy \
--log-group-name /shop-app/prod \
--retention-in-days 30IAM 權限控管：保障安全、避免誤操作
CloudWatch Log Group 的建立、刪除與讀寫，應限制在特定角色範圍內。
建議策略：
🧩 範例 IAM Policy（僅能寫入某個群組）：
{
"Effect": "Allow",
"Action": "logs:PutLogEvents",
"Resource": "arn:aws:logs:ap-northeast-1:123456789012:log-group:/shop-app/prod:*"
}清理機制：定期審查與移除不再使用的 Log Group
若專案已下線或環境已無人使用，應該：
- 停止該 Log Group 的寫入來源（如停止 Lambda function）
- 主動刪除 Log Group，避免資源殘留與儲存累積
✅ 建議做法：
- 每季度或每半年，安排日誌群組檢查流程
- 針對沒有新資料寫入超過 30 天的群組進行評估是否可移除
- 使用腳本或 AWS SDK 自動化列出與分析 Log Group 活躍狀況
📌 CLI 查詢所有 Log Group 清單：
aws logs describe-log-groups可加上 --query 參數或結合 lastIngestionTime 篩選出未使用的群組。
結語：掌握 Log Group 是邁向監控自動化的第一步
CloudWatch Logs 的日誌群組看似簡單，但卻是打造自動化、可觀察系統的起點。
不論是要追錯、追蹤行為、製作儀表板或設警示，你都離不開它。
只要記住三個原則：
- 日誌分類要清楚（Log Group 分清楚）
- 資料保存要合理（避免無限累積）
- 權限與命名要一致（方便維運與管理）
學會 Log Group 的操作與設計，就能讓你的 AWS 雲端應用更穩定、更透明、更安全！