AWS上MongoDB备份管理最优方案及适用服务选型咨询

核心架构选型（完全满足5小时运行时长要求） #

业内针对小时级的离线备份任务，普遍采用无服务器调度+按需计算载体+CloudWatch可观测的成熟架构，用到的AWS服务如下：

• 定时调度层：用 Amazon EventBridge Scheduler 替代原有Jenkins的定时触发能力，支持原生cron表达式配置，你可以直接复用原来的备份触发规则，无需额外适配
• 任务执行层：Lambda最长仅支持15分钟运行时长完全不适用，你可以二选一：
  • 优先选ECS Fargate：完全无服务器的容器运行环境，无最长运行时间限制，你只需要把原有的备份脚本打包成Docker镜像上传到ECR即可直接调度，不用维护任何底层服务器，按实际CPU、内存使用时长付费
  • 成本敏感选AWS Batch：支持自动调度EC2 Spot实例运行备份任务，Spot实例价格仅为按需实例的30%，离线备份任务可容错中断的特性完美适配Spot的使用场景，能大幅降低运行成本
• 存储层：直接沿用你当前的S3存储即可，可额外配置生命周期规则，超过30天的历史备份自动下沉到S3 Glacier Flexible Retrieval，存储成本可以降低90%以上
• 超时告警层：直接用 Amazon CloudWatch Alarms 实现，不管用ECS还是AWS Batch，任务运行时长的指标都会默认自动上报到CloudWatch，你只需设置对应指标的阈值（比如预设5.5小时），触发阈值后通过SNS推送告警到邮件、短信、内部办公群即可，还可以配置告警联动自动终止超时任务，避免资源空跑浪费

可选优化配置 #

• 如果你的MongoDB是托管版MongoDB Atlas，可以直接开启Atlas的AWS区域自动备份功能，备份文件自动落S3，自带超时、备份失败告警，无需自行搭建任务链路，运维成本最低
• 大体积库备份可以搭配MongoDB增量备份能力，降低全量备份的频次，进一步缩短单次任务运行时长
• 可在备份流程末尾添加校验步骤，将备份文件的哈希值存入DynamoDB，定期自动校验备份可用性，避免备份文件损坏无法用于恢复的问题

不同场景选型建议 #

• 备份脚本已容器化、不想做额外运维：选 ECS Fargate + EventBridge + CloudWatch 方案
• 追求极致成本、可以容忍备份任务偶发中断：选 AWS Batch + Spot实例 + EventBridge + CloudWatch 方案
• 已有运维成熟的EC2集群：直接用Systems Manager Run Command定时触发EC2上的备份脚本，无需引入新服务组件

内容的提问来源于stack exchange，提问作者Bernana