亚马逊云新加坡账号 AWS亚马逊云服务器自动快照策略

亚马逊aws / 2026-04-25 16:13:05

别再手动点‘创建快照’了，你的EBS卷正在偷偷破产

凌晨三点，你被钉钉消息惊醒——账户余额只剩$23.71。不是黑客攻击，也不是API密钥泄露，而是你上周给三台生产环境EC2配的EBS卷，每天自动生成快照，连续30天没清理，快照数量飙到417个，账单像雪球滚下珠峰。更讽刺的是，其中389个快照根本没人看过，连命名都写着‘test-20240415-legacy-bak’——谁还记得这是哪次测试留下的？

快照不是保险柜，是会生崽的母猪

AWS官方文档里把EBS快照描述得温良恭俭让：「增量式、高效、跨可用区冗余」。但没人告诉你，它还有个隐藏属性：极强繁殖力。每当你手动点一次「Create Snapshot」，系统不仅存下当前数据，还悄悄记下所有已存在快照的差异块。这本是技术亮点，可一旦脱离管控，快照就变成快照的爹、快照的爷、快照的太爷爷……最后你面对的不是备份，是一整个快照宗族谱。

先破个幻觉：快照免费？错！它按实际存储量计费

新手常踩的坑：以为「快照不占EBS配额」就等于「不花钱」。真相是——快照存在S3底层，按实际占用空间收费，且不随源卷删除而自动消失。你删掉一台EC2，它的100GB EBS卷没了，但之前生成的20个快照还在默默吃钱，尤其当它们包含大量重复数据块时，账单照样按去重前体积算（AWS按压缩后大小计费，但跨快照去重逻辑复杂，实测中常有偏差）。我们曾审计过一个客户环境：源卷总容量才1.2TB，快照合计占用却达4.7TB——相当于养了四头数据肥猪。

Data Lifecycle Manager：AWS亲儿子，但得教会它认爹

别挣扎了，手动管理快照=给运维生涯装倒计时。AWS早备好了正统解法：Data Lifecycle Manager（DLM）。它不像Lambda+CloudWatch组合那样需要写代码、设权限、调重试，而是开箱即用的图形化策略引擎——前提是，你得让它听懂人话。

第一步：给资源贴上‘身份证’，否则DLM当场失明

DLM不认实例ID，不看卷名，只认标签（Tag）。你必须提前给要保护的EBS卷打上指定键值对，比如：BackupPolicy=Production 或 Environment=Staging。漏打一个标签？DLM视而不见。打错大小写？它当没看见。我们见过最绝的案例：运维小哥坚持用backup-policy=prod（带连字符+小写），而DLM策略里写的是BackupPolicy=prod（驼峰+大写）——整整三个月，生产库零快照，直到主库硬盘物理损坏那天，他才在日志里看到一行温柔提示：「No volumes matched the specified tags」。

第二步：定义生命周期——不是‘保留7天’，而是‘保留最近3个+最长30天’

DLM策略的核心是两组数字：创建频率 和 保留规则。别再写‘每天1个，保留7天’这种朴素方案。实战推荐组合：

高频卷（如数据库主盘）：每4小时创建1个，保留最近12个 + 所有30天内的快照；
低频卷（如静态网站盘）：每天1个，保留最近7个 + 所有90天内的快照；
关键卷（如财务系统）：每周日02:00创建，保留最近4个周快照 + 所有180天内快照，并开启跨区域复制到us-west-2。

注意！「保留最近N个」和「保留M天内」是同时生效的交集逻辑。比如设「保留最近5个+30天内」，若某卷过去30天只生成3个快照，则全留；若生成12个，则只留最新的5个，哪怕第6个是29天前的——DLM不讲情面。

第三步：跨区域复制？先检查KMS密钥权限

想把快照同步到另一个区域防灾？恭喜，你触发了AWS最隐蔽的权限地雷。DLM跨区复制要求：源区域KMS密钥必须显式授权目标区域的DLM服务角色。默认情况下，KMS密钥策略只允许本区域EC2使用。你得手动编辑密钥策略，加上类似这样的语句：

{
  "Sid": "Allow DLM cross-region copy",
  "Effect": "Allow",
  "Principal": {
    "Service": "dlm.amazonaws.com"
  },
  "Action": [
    "kms:Decrypt",
    "kms:DescribeKey",
    "kms:GenerateDataKey"
  ],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:ViaService": "ec2.us-west-2.amazonaws.com"
    }
  }
}

漏掉kms:Decrypt？复制失败。Condition里区域写错？失败。大小写写成US-WEST-2？还是失败。我们团队内部流传一句话：“DLM跨区失败十次，九次半在KMS，剩下半次在标签拼写。”

逃不开的硬核补丁：用CLI批量救火

等DLM策略生效要等1小时，而你此刻正面对400+孤儿快照。别慌，AWS CLI三行命令清场：

# 查出所有未关联卷、超过60天的快照
aws ec2 describe-snapshots --owner-ids self --query 'Snapshots[?not_null(Description) && contains(Description, `auto`) && Age > `60`].[SnapshotId]' --output text

# 批量删除（加--dry-run先预览）
aws ec2 delete-snapshot --snapshot-id snap-0a1b2c3d4e5f67890 --dry-run

# 真删（建议分批，每次≤50个）
for id in $(cat old-snapshots.txt); do 
  aws ec2 delete-snapshot --snapshot-id $id 2>/dev/null && echo "✅ $id deleted" || echo "❌ $id failed";
  sleep 0.5
done

亚马逊云新加坡账号 重点提醒：删除快照不释放空间，但阻止后续计费增长。已产生的费用仍会计入本月账单，但明天起就不再新增——就像关掉漏水的水龙头，地板上的水还得拖，但不会再漫出来。

终极省钱心法：三句口诀，背熟不踩坑

标签即法律：DLM策略不认人，只认Tag。所有要进策略的卷，上线前必须打标，CI/CD流水线里加一道aws ec2 create-tags校验；
保留非叠加，是取交集：「最近5个」和「30天内」不是加法，是AND逻辑。想留够时间纵深，就拉长天数；想保操作弹性，就增加数量；
快照≠可启动镜像：别指望快照直接Launch新实例。EBS快照只能恢复为新卷，挂载后需手动配置启动项。真要一键复原，请用AMI——那是另一套体系。

最后送一句老运维的肺腑之言：自动化不是为了偷懒，而是把重复劳动压缩成一行策略，好让你腾出手来，盯着那个真正该盯的地方——业务日志里的异常峰值，而不是账单邮件里的红色感叹号。