AWS 日誌保留管理：S3 生命週期規則與 Terraform 最佳實踐

雲端成本在不知不覺中成長的最簡單方法之一就是日誌保留。許多組織都明白收集日誌的重要性，但很少有組織了解如何優化和使用從日誌中獲取的數據，更少有人明白這些日誌應該保留多長時間。了解貴公司存取這些日誌的頻率以及您目前的儲存策略是否仍然符合業務需求非常重要。

在與客戶一起審查我們的日誌記錄策略時，我們發現了一個共同的模式：日誌保留的時間過長，儲存成本持續成長，並且不同環境中沒有標準化的生命週期策略。

為了解決這個問題，我們制定了正式的日誌保留策略，並得到了 Amazon S3 生命週期管理和基礎設施即程式碼 (IaC) 的支援。結果是，日誌管理方法更加一致，儲存成本降低，保留策略也更符合營運和合規要求。

從目標入手，而不是從儲存類別入手

企業犯的最大錯誤之一就是從科技著手，而不是從業務需求著手。

許多客戶保留策略都是圍繞著「如果…會怎樣」的情景制定的：

• 如果我們需要兩年前的日誌怎麼辦？
• 如果調查需要12個月前的歷史資料怎麼辦？
• 如果有人索取我們已經沒有的紀錄怎麼辦？

雖然這些問題合情合理，但它們往往會導致無限期地保留所有內容。

相反，不妨先從幾個簡單的問題開始：

• 這些日誌的實際用途是什麼？
• 它們多久會被造訪一次？
• 當這些數據被獲取時，它們能提供哪些商業價值？
• 是否存在規定資料保留期限的合規性要求？
• 誰擁有日誌保留的決定權？
• 如何在不犧牲任何條件的前提下降低儲存成本？

雖然這種情況因公司而異，但在許多情況下，團隊發現幾個月前的日誌很少被訪問，提供的營運價值有限。它們的存在是為了提供保障，但不知不覺中，你會發現數以TB計的無用數據，它們不僅佔用空間，還造成了許多不必要的負擔和雜亂。

最終目標應該是保留日誌足夠長的時間，以支援調查、故障排除、合規性和審計，同時避免不必要的儲存成本。

不同的環境有不同的需求

並非所有環境都需要相同的保留期限。

生產日誌通常用於支援稽核、事件回應和安全調查。開發日誌通常用於短期調試，通常可以保留較短的時間。

我們的客戶留存策略是圍繞著特定環境的需求而製定的。以下是一個範例，展示了它的外觀。

生產

保留期限： 12 個月

生產日誌需要最長的保留期限，因為它們支援：

• 安全調查
• 事件回應
• 合規和審計要求
• 歷史營運分析

生命週期策略：

• 第0-30天：S3標準
• 第 31–90 天：S3 標準-IA
• 第 91–365 天：S3 冰川靈活回收
• 12個月後刪除

品質保證

保留期限： 90天

QA日誌主要用於：

• 發布驗證
• 迴歸分析
• 歷史故障排除

生命週期策略：

• 第 0–60 天：S3 標準-IA
• 90天後刪除

發展

保留期限： 30天

開發日誌主要用於：

• 應用程式偵錯
• 故障排除
• 發展支持

生命週期策略：

• 第 0–30 天：S3 標準-IA
• 30天後刪除

透過針對每個環境客製化保留策略，我們避免了在不需要的地方應用昂貴的生產級保留要求。

選擇合適的 S3 儲存類別

Amazon S3 提供多種儲存類別，每種類別都針對不同的存取模式而設計。

最關鍵的教訓是，儲存類別的選擇應該基於實際使用情況，而不是基於假設。

一些值得思考的問題：

• 日誌的存取頻率如何？
• 是否存在某些比其他木材更有價值的情況？
• 我們目前的S3儲存桶是如何設定的？
• 第一個月之後就很少人造訪了嗎？
• 必須盡快取回它們？
• 檢索成本是否可以接受？

就我們的使用場景而言：

S3 標準

用於需要立即存取的新生產日誌。

S3 標準-IA

當仍偶爾存取日誌，但不再需要標準的緊迫性時，可以使用此方法。

S3冰川靈活回收

用於長期存檔，訪問頻率較低，但如有需要仍可檢索。

AWS 提供了所有可用 S3 儲存類別及其優缺點的完整分類，詳情請見此處：
https://aws.amazon.com/s3/storage-classes/

基礎設施即程式碼讓治理更輕鬆

只有始終如一地執行保留政策，該政策才有價值。

我們沒有手動跨環境配置生命週期規則，而是使用 Terraform 實現了生命週期策略。

這帶來了以下幾個好處：

• 可重複使用的生命週期配置
• 版本控制變更
• 透過拉取請求進行同儕評審
• 跨環境的一致部署
• 降低配置漂移的風險

基礎架構即程式碼將資料保留管理從一次性配置工作轉變為可重複的操作流程。

避免犯錯

生命週期策略可自動執行刪除和儲存轉換。這使它們威力強大，但也具有潛在的危險性。

啟用自動到期和轉換功能之前：

• 啟用 S3 儲存桶版本控制
• 在非生產環境中驗證生命週期規則
• 確認過渡時間計算結果。
• 測試對象過期行為
• 驗證檢索工作流程
• 確保瞄準正確的桶

版本控制提供了一層額外的保護，防止意外刪除或生命週期規則配置錯誤。

生產前測試

我們在正式推出前就建立了一個簡單的驗證流程：

1. 建立一個專用的開發儲存桶。
2. 將開發日誌歸檔到儲存桶中。
3. 執行已提出的生命週期策略。
4. 驗證儲存類別轉換。
5. 驗證過期行為。
6. 記錄結果。
7. 在繼續進行其他開發工作之前，請先獲得批准。
8. 晉升到更高階層的環境

這種方法使我們能夠及早發現配置問題，同時將風險降至最低。

治理至關重要

日誌保留不應由單一工程師負責。

成功的客戶保留政策需要以下各方的合作：

• DevOps團隊
• 安全團隊
• 合規團隊
• 基礎設施領導力

明確的所有權有助於確保資料保留期限隨著系統的演變而始終與業務和監管要求保持一致。

最後想說的話

最有效的日誌保留策略不一定是保留日誌時間最長的策略。

它起到平衡作用：

• 成本
• 遵守
• 安全
• 營運可見性
• 簡單

組織保留資料通常是出於對未來潛在需求的假設，而不是出於實際的業務需求。透過了解日誌的使用方式，使保留期限與特定環境的需求保持一致，利用適當的 S3 儲存類別和儲存轉換，並透過 IaC 實施策略，團隊可以大幅降低儲存成本，同時保持他們實際需要的可見性。

最重要的是，要記住每個組織都是不同的。這裡描述的生命週期策略在我們這裡效果很好，但是保留期限、儲存類別和歸檔時間表應該始終由您自己的營運要求和合規義務驅動。

作者

喜歡你聽到的內容嗎？對什麼更適合自己有疑問嗎？我們很樂意與您交流！聯絡我們

部落格