记一次 S3 Bucket 流量异常调研及调用优化

date
Dec 10, 2024
slug
s3-bucket-traffic-analysis-and-improvement
status
Published
tags
AWS
S3
Tech
Blog
type
Post
author
summary
对S3 Bucket流量异常的调研显示该项目的调用量过大，需寻找减少调用的机会。通过SQL查询监控特定Bucket的请求事件，分析事件数量以优化调用。
事情的起因是马老师通过日常巡检发现我的一个 S3 bucket 账单有异常，在没有业务变动的情况下，费用激增，需要查一下是否存在问题。
马老师： 看监控这个项目对S3的调用量太大了 有机会减少一些么？ 波动比较大，感觉你这个项目虽然调用，但量不应该这么大。
 
为了更精确地定位问题，马老师开了 CloudTail Logs，这东西可方便了，于是我们通过 CloudWatch Logs Insights 直接从 CloudTrail Logs 里捞日志。
 
扩展阅读：
AWS CloudTrail 是什么
AWS CloudTrail 是亚马逊云计算服务（AWS）提供的一项审计、合规和操作可见性服务，用于记录与您的 AWS 账户关联的所有 API 调用和相关事件。简单来说，CloudTrail 会自动记录在 AWS 环境中发生的所有 API 请求（包括通过控制台、CLI、SDKs、以及其他 AWS 服务间的交互），并将这些日志文件安全地存储在 Amazon S3 中。
通过使用 CloudTrail，您可以实现对环境中资源变更以及用户行为的全面可视化与审计追踪，从而帮助满足合规性要求、快速发现安全事件、进行问题排查以及持续优化基础架构的运营和安全状况。

什么时候会用到

  1. 安全合规与审计：
      2. 您需要定期审核和记录资源调用情况，以满足监管合规或内部审查需求。CloudTrail 可以提供完整的访问和操作历史记录，满足诸如 PCI-DSS、ISO 27001 等多种合规标准的要求。
  1. 故障诊断与问题排查：
      2. 当您遇到系统故障、访问异常或资源配置问题时，可以通过查询 CloudTrail 日志快速确定问题发生的时间、调用者、操作类型以及调用结果。
  1. 安全事件响应：
      2. 若检测到潜在的安全问题，如来自可疑 IP 的访问或对敏感资源的不正常调用，CloudTrail 日志为安全团队提供事件发生前后完整的操作历史，便于溯源和采取措施。
  1. 内部操作透明度：
      2. 大型团队或企业中，不同部门和用户可能共享同一 AWS 账户。借助 CloudTrail，管理员可以清晰了解各个用户的操作行为，提高管理透明度和安全性。

最佳实践

  1. 在所有区域启用 CloudTrail：
      2. 默认情况下开启对所有区域（All Regions）的日志记录，以确保不遗漏可能发生在非主要区域的活动。
  1. 将日志安全地存储与归档：
      2. 使用 Amazon S3 存储 CloudTrail 日志，同时配合 S3 存储生命周期管理，将旧日志归档至低成本存储层（如 S3 Glacier），实现长期保留和成本优化。
  1. 开启日志加密与完整性验证：
      2. 对 S3 存储桶启用服务器端加密（SSE）以及使用 CloudTrail 提供的日志文件校验（Integrity Validation），确保日志数据的保密性与完整性。
  1. 与 Amazon CloudWatch 和 Amazon EventBridge 集成：
      2. 将 CloudTrail 与 CloudWatch Logs、EventBridge 整合，以便实时监控和告警。例如，设置对敏感操作（如删除关键资源或更改 IAM 政策）的告警通知，以便及时采取应对措施。
  1. 细粒度权限控制与隔离：
      2. 使用 IAM 策略限制对 CloudTrail 配置的访问和修改权限，确保只有授权用户才能创建、修改或停止 CloudTrail Trails。
  1. 定期审查日志与设置：
      2. 定期回顾 CloudTrail 的配置（例如审核您所记录的事件类型、日志保存时间策略），并根据最新的合规和安全要求进行调整。
AWS CloudWatch Logs Insights 是什么
Amazon CloudWatch Logs Insights 是 AWS 提供的一项交互式、可扩展且高性能的日志分析解决方案。它让您能够快速、动态地查询和分析存储在 AWS CloudWatch Logs 中的日志数据。通过使用类似 SQL 的查询语法，Logs Insights 可以在数秒内就返回查询结果，从而帮助您针对大量且复杂的日志数据进行实时分析和故障排查。
相比传统的日志处理方式（如下载日志文件本地分析或借助其他工具进行繁琐处理），CloudWatch Logs Insights 大大简化了流程。它内置了高度优化的查询引擎以及可视化工具，能让用户在浏览器中直接获得直观可视化的查询结果和统计数据。

使用场景

  1. 故障排查和性能分析：
      2. 当您的应用或服务出现故障、性能下降或异常行为时，可以使用 Logs Insights 对日志进行快速查询与分析，帮助您及时定位问题的根源。
  1. 实时运维监控：
      2. Logs Insights 查询可以与 CloudWatch Dashboards 整合，将查询结果图形化地展示出来，帮助运维人员实时观察系统关键指标变化，提升日常运营的可见性与反应速度。
  1. 大规模日志数据检索与聚合：
      2. 对于分布式应用、大型微服务架构或拥有大量日志数据的企业而言，Logs Insights 能够轻松对海量日志数据进行指标聚合与统计分析，辅助制定决策和优化架构。
  1. 安全审计与合规性分析：
      2. 使用 Logs Insights 查询安全相关日志（如来自 CloudTrail、VPC Flow Logs、AWS WAF Logs），从而快速检测异常访问模式、潜在攻击尝试或配置不当问题，满足安全和审计需求。

功能特点

  1. 类 SQL 查询语法：
      2. 使用专门定制的查询语言（CloudWatch Logs Insights Query Language），易于理解和使用。查询中可进行过滤（filter）、统计（stats）、分组（fields）、排序（sort）、限制（limit）等常见操作。
  1. 可视化：
      2. 查询结果支持以表格和图表形式显示，帮助您更直观地理解数据分布与趋势变化。
  1. 自动完成功能：
      2. 在查询编辑器中，会对可用的字段、函数和语法进行自动完成建议，降低查询构建的难度。
  1. 高性能与可扩展性：
      2. Logs Insights 针对海量日志数据进行了优化，无需进行复杂的预处理，也能快速返回查询结果。

相关参考资料

最佳实践

  1. 预先规划日志字段结构：
      2. 虽然 Logs Insights 能查询任意原生日志文本，但通过对日志进行结构化（JSON 格式或使用可解析的 key-value 对）可以大大提升查询效率和易用性。
  1. 创建常用查询模板：
      2. 对于经常执行的查询，将其保存为“Favorite Queries”或在外部文档中留存模板。这样在排障或分析时可以一键执行常见分析查询，而无需重复编写。
  1. 合理使用过滤与分组：
      2. 在查询中尽可能先使用 filter 来精简日志数据范围，随后使用 stats、fields、sort 等子句进行汇总分析。先过滤后聚合可以提升查询性能和降低查询成本。
  1. 分片与分层日志策略：
      2. 针对不同类型的日志（应用日志、访问日志、安全日志）使用不同的 Log Group 并结合良好的命名规范。这样在查询时能够快速锁定日志位置和类型。
  1. 搭配 CloudWatch Dashboard 使用：
      2. 将常用查询的结果面板嵌入到 CloudWatch Dashboards 中，对关键指标进行可视化追踪与告警，有助于快速发现异常趋势和问题。
  1. 持续优化与成本管理：
      2. Logs Insights 查询基于查询的数据量计费。通过缩小查询时间范围、优化查询条件以及删除不必要的日志数据存储，可以控制成本。
通过合理使用和持续优化，Amazon CloudWatch Logs Insights 能够为您的运营与监控工作带来强大的日志分析能力，加速问题定位、增强决策支撑并降低整体运维复杂度。
 
先用 Logs Insights 语句统计一下产生最多的 10 个 event
因为 12.09 才开启 CloudTrail 统计，所以圈定时间范围为：
2024-12-10T 00:00:00 ~ 2024-12-12T23:59:59
得出结果：
notion image
 
从结果可以看出 S3 的 PutObject 和 ListObjects 断崖领先，接下来看一下是什么业务和场景产生了这么多操作。

PutObject

notion image
从结果上看 99% 的 PutObject 都产生在了 restaurant/offline_payment ，查看对应的 S3 地址后发现碎片化地写入了大量的 error 数据和疑似脏数据，从 userAgent 可以看出这是来自一个后端 go 服务，整理一下上下文，直接丢给对应负责人继续查。
 

ListObjects

接下来查 ListObjects 异常
 
结果：
notion image
 
直接从输出结果的 ARN 定位到了是我负责的一个 Lambda 服务，阅读代码后发现代码中有循环调用 ListObjects 来扫文件目录的代码，并且没加缓存，问题先查到这，随后进行重构改造。
 

GetObject 出站流量

最后再来查一下我的 S3 bucket 出站流量是否异常，该加缓存的是否加了
 
我们先看一下该 bucket 的出站总流量
结果为：
totalBytes：58455843270
 
再看一下一级 prefix 和具体到文件的流量 top 10
 
Prefix Level 1
 
notion image
从结果发现 brandImgs 输出了 43744345963 的流量，占总流量的 74%，而 brandImgs 所对应的业务是应该有 CDN 的
 
通过反复调整 Query 语句最终发现 cafeterias/cafeteria-top-banner-default.png 贡献了 43744240576 的流量，那么继续查一下调用方都有哪些
 
 
notion image
 
资源没有配置对应的 HTTP Cache-Header 导致没有被缓存
 
 
 
 

© Chaoran Sun 2024 - 2026