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 实施策略，团队可以显著降低存储成本，同时保持他们实际需要的可见性。

最重要的是，要记住每个组织都是不同的。这里描述的生命周期策略在我们这里效果很好，但是保留期限、存储类别和归档时间表应该始终由您自己的运营要求和合规义务驱动。

作者

喜欢你听到的内容吗？对什么更适合自己有疑问吗？我们很乐意与您交流！联系我们