Python3含无限循环的项目迁移至AWS的实现方案咨询

Lambda确实不适合运行无限循环常驻进程，仅适合短时长事件触发类任务，你当前的两个常驻脚本不建议直接用Lambda部署

方案1：低改造成本方案（几乎无需修改现有代码） #

• 核心采用EC2 + RDS 或 ECS + RDS架构，可直接平移现有逻辑：
  • 数据库直接迁移至AWS RDS for MySQL，无需修改现有数据库读写逻辑
  • 若选择EC2部署：申请一台轻量规格EC2实例（如t2.micro），将两个Python脚本上传后配置为systemd守护进程，实现开机自启、崩溃自动重启即可。若目标API有固定出口IP要求，可给EC2绑定弹性公网IP，兼容现有代码中的代理配置
  • 若选择ECS部署：将两个脚本打包为Docker镜像，用ECS Fargate部署常驻任务，无需维护服务器，运维成本比EC2更低
• 成本说明：t2.micro符合AWS免费套餐资格，新用户前12个月可免费使用，最小规格RDS每月成本仅几美元，远低于长期运行无限循环Lambda的成本

方案2：云原生优化方案（改造成本中等，可用性更高，按需计费更灵活） #

适配daemon.py高频请求逻辑 #

将原有无限循环改造为 EventBridge 定时触发 + Lambda 架构：

• 用Amazon EventBridge配置定时规则，最高可设置1分钟触发60次（即每秒1次），如果需要更高请求频率，可配置为每1分钟触发1次Lambda，单次Lambda内部循环执行任务14分钟后主动退出，刚好避开Lambda最长15分钟的运行时长限制
• Lambda仅保留请求目标API、写入RDS的核心逻辑，按实际调用次数和执行时长计费，高频场景下成本也极低

适配ship.py数据变动监听逻辑 #

将原有无限循环监听改造为RDS事件触发 + Lambda 架构：

• 开启RDS的Binlog日志，通过AWS DMS或RDS触发器监听数据库的写入/更新事件，一旦检测到数据变更直接触发Lambda执行请求目标API的逻辑
• 无需常驻进程监听，仅在数据变更时产生调用成本，比手动写循环监听更稳定，不会漏过变更事件

选型建议 #

• 若仅临时运行、不想修改现有代码，直接选择方案1，1天内即可完成迁移上线
• 若需要长期稳定运行、希望降低运维成本（无需自行维护服务器系统更新、进程监控），选择方案2，仅需去掉两个脚本的while True外层逻辑，适配Lambda的入参规范即可完成改造

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