初學者指南：認識 AWS CloudWatch 日誌群組（Log Groups）

更新日期： 2025 年 6 月 10 日

在雲端運維與監控的世界裡，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/prod
• i-1234567890abcdef0（EC2）
• i-9876543210abcdef1（另一台 EC2）
• /aws/lambda/payment-handler
• 2025/06/05/[$LATEST]abcdef1234567890...

📌 為什麼要善用 Log Group？

🧠 小提醒：命名策略建議

為了讓日誌管理更清晰，建議使用以下命名格式：

/應用程式名稱/環境/模組（可選）

例如：

• /myapp/dev
• /myapp/prod/payment
• /myapp/prod/authentication

這樣不僅便於搜尋與維護，也有助於日後自動化清理、警示設定與 IAM 權限管理。

如何建立與管理日誌群組（Log Group）？

CloudWatch 的日誌群組（Log Group）雖然看似只是一個「資料夾」，但它的建立與設定，攸關後續的資料收集效率、儲存成本、監控管理與警示運作。

AWS 提供了三種主要方式來建立與管理 Log Group：

1. 透過 AWS 管理控制台（Console）
2. 使用 AWS CLI（指令列介面）
3. 透過 SDK 自動化（如 Python boto3） — 本篇先聚焦前兩者，適合手動操作與日常維運使用。

方法一：使用 AWS Console 建立 Log Group

這是最適合初學者的方式，透過圖形化介面操作簡單直觀。

1. 登入 AWS 管理控制台（https://console.aws.amazon.com/）
2. 在服務搜尋欄輸入 CloudWatch 並點擊進入
3. 左側選單中選擇「Logs > Log groups」
4. 點擊右上角的「Create log group」按鈕
5. 在「Log group name」欄位中輸入名稱，例如：

   /my-app/production

⛳ 建議使用階層式命名，有助於分類與搜尋（例如 /應用/環境）

6. 選擇日誌的保留天數（Retention），例如「30 天」、「1 年」，或選擇「永遠保留」
   • 設定保留天數有助於控管儲存成本與資安法規遵循

7. 點擊「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/production

Log 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 30

IAM 權限控管：保障安全、避免誤操作

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 的日誌群組看似簡單，但卻是打造自動化、可觀察系統的起點。

不論是要追錯、追蹤行為、製作儀表板或設警示，你都離不開它。

只要記住三個原則：

1. 日誌分類要清楚（Log Group 分清楚）
2. 資料保存要合理（避免無限累積）
3. 權限與命名要一致（方便維運與管理）

學會 Log Group 的操作與設計，就能讓你的 AWS 雲端應用更穩定、更透明、更安全！