亚马逊云12个月免费号 亚马逊云 AWS 账号操作日志留存

别等审计来了才翻垃圾桶：AWS账号操作日志留存实操手记

上个月，客户安全团队凌晨三点发来截图：「请立刻提供过去90天所有ec2:RunInstances调用记录，审计组明早八点要上会」。运维小哥揉着红眼泡翻CloudTrail控制台——发现日志只存了7天，且没开多区域跟踪。他默默点了杯冰美式，然后开始重装系统（误），其实是连夜补日志管道。这故事不是段子，是无数AWS账户的真实日常。

一、CloudTrail不是开了就完事——它是个「半成品」

AWS默认给你一个叫aws-cloudtrail-logs-xxx的S3桶？别谢，那只是个空盒子。CloudTrail本身不存日志，它只负责「打报告」，而报告扔哪儿、怎么锁、谁准看、存多久——全靠你手动填坑。

新手常犯三错：

• 亚马逊云12个月免费号 只开单区域跟踪：EC2在us-east-1启动，但RDS在ap-southeast-1删库，日志分散两地，查起来像玩密室逃脱；
• 日志加密选了KMS但没授权：日志写进S3后秒变乱码，CloudTrail报错「AccessDeniedException」，其实只是KMS密钥策略里漏写了cloudtrail.amazonaws.com的服务角色；
• 把日志桶设成公开可读：某次误操作让arn:aws:s3:::my-ct-logs/*对Everyone开放，审计还没来，黑客先来巡检了。

正确姿势：创建跟踪时勾选「所有区域」+「日志文件验证」+「启用日志加密」；S3桶策略必须显式拒绝非授权主体，且Principal只允许CloudTrail服务和你的审计IAM角色。

二、S3不是保险柜，是带定时器的抽屉

日志存进S3只是起点。真正的挑战是：如何让1TB日志不烧穿预算，又不让合规官拍桌子？

我们用过最野的方案：分层生命周期策略。

• Standard（0-30天）：热数据，随时查；
• Intelligent-Tiering（31-90天）：自动降冷，省35%费用；
• Glacier Deep Archive（91-7年）：合规存档，$0.00099/GB/月，比买硬盘还便宜；
• Expiration（7年后）：自动删除，不留法律尾巴。

重点提醒：Deep Archive恢复需12小时，别指望它救火。我们曾为查一条API调用，提前两天发起取回请求——结果发现日志路径写错，重来一遍时，审计组已撤会。

还有个隐藏开关：启用S3 Object Lock。这不是防删，是防「被删」。开启合规模式（Compliance Mode）后，连root用户都得等保留期满才能删——哪怕CEO亲自打电话让你删，你也只能回：「老板，AWS说不行」。

三、查日志别只盯着控制台——CLI和Athena才是亲儿子

控制台查日志？适合找最近1小时的StopInstances。想查「上周三下午谁把生产RDS快照删了」？Ctrl+F是玄学，命令行才是科学。

示例：用CLI快速定位删快照操作

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=DeleteDBSnapshot \
  --start-time $(date -d '7 days ago' +%Y-%m-%dT%H:%M:%SZ) \
  --max-results 50

但当数据量超百万行，CLI就卡成PPT。这时候，上Athena建模：

1. 在S3中创建分区表，按year=2024/month=06/day=15结构组织；
2. 用CREATE EXTERNAL TABLE定义schema，重点加eventTime和userIdentity.arn字段；
3. 写SQL：「找出所有eventSource=rds.amazonaws.com且errorCode IS NOT NULL的操作」——5秒出结果，比翻日志文件快200倍。

血泪教训：别用SELECT *扫全表！我们曾因没加PARTITION过滤，一次查询烧掉$87，财务部发来灵魂质问邮件。

四、合规不是贴纸，是嵌进流程里的钉子

GDPR要求日志留存至少6个月，等保2.0要求180天，金融行业动辄7年。但更狠的是：日志必须不可篡改、可验证、可溯源。

CloudTrail的log file validation功能就是干这个的。它每小时生成一个哈希链文件（digest），每个日志文件都有数字签名。验证脚本跑起来长这样：

aws cloudtrail validate-logs \
  --trail-arn arn:aws:cloudtrail:us-east-1:123456789012:trail/MyTrail \
  --start-time $(date -d '30 days ago' +%s)

返回Valid才敢签字交差。有次验证失败，排查3小时发现是S3桶策略里漏了s3:GetObjectVersion权限——日志能读，但哈希文件版本读不了，验证直接跪。

最后补一刀：给审计账号开只读权限，但禁用cloudtrail:DeleteTrail和s3:DeleteObject——权限最小化，不是客气，是底线。

五、那些没人告诉你的坑，都在凌晨三点发光

坑1：日志延迟不是Bug，是设计
CloudTrail日志从事件发生到S3可达，平均延迟2-15分钟。别在CI/CD流水线里写「调用API后立刻查日志确认」——你会收获一堆False Negative。

坑2：跨区域跟踪≠自动同步
开了「所有区域」，但新区域的日志不会自动推送到旧桶。必须在每个区域单独创建跟踪，或统一指向一个全局S3桶（记得配好跨区域复制）。

坑3：Lambda调用日志藏得深
如果用Lambda做自动化运维，它的Invoke日志在CloudTrail里，但函数内部执行细节在CloudWatch Logs。想关联分析？得用requestId手工串起来——或者，干脆把Lambda日志也推到S3，用Athena一起查。

坑4：Root用户日志是幽灵
Root账号操作不会出现在普通跟踪里，必须开「组织级跟踪」（Organization Trail）并绑定管理账户。否则，有人用Root密钥删了整个VPC，你查遍所有跟踪都找不到记录。

结语：日志不是备忘录，是你账户的呼吸记录仪

留日志不是应付检查，是给自己装黑匣子。下次半夜收到告警，你能3分钟定位是谁、在哪、干了啥；审计来了，你不用现搭管道、现写SQL、现求KMS解密；甚至某天发现异常活动，翻日志能直接锁定时间线——这才是技术人的底气。

记住：最好的日志方案，不是最贵的，而是你敢在凌晨三点闭着眼睛重启它，第二天依然能查出谁改了安全组规则。