在AWS上运行Tweepy推文采集脚本的最优服务选型咨询

结论先行：你完全不用局限于EC2，首选用无服务器容器服务ECS Fargate，成本更低、运维工作量更小 #

你可以根据自己的运维习惯选择以下方案，优先级从高到低排列：

• 首选方案：Amazon ECS + Fargate
  你只需要把现有Python脚本打包成极简的Docker镜像（只需要基础Python镜像 + 安装Tweepy、AWS SDK依赖即可），上传到ECR镜像仓库，在ECS上配置长期运行的Fargate任务即可：
  • 完全不用管理底层服务器，AWS自动负责实例运维、安全补丁更新
  • 支持配置自动重启策略，脚本异常退出后会自动拉起，保证采集连续性
  • 你的脚本资源要求极低，完全可以配置最小规格的Fargate资源（0.25vCPU + 0.5G内存），每月成本只有几美元，远低于长期运行独立EC2的成本
  • 内置支持AWS服务权限配置，直接给任务角色开通Firehose写入权限即可，不需要手动配置AKSK
• 次选方案：轻量EC2实例
  如果不想做容器打包，可以选择符合免费 tier 资格的t2.micro/t3.micro实例：
  • 满足免费使用条件的情况下，前12个月可以零成本运行
  • 你需要自行配置Python运行环境、设置进程守护（比如用systemd、supervisor保证脚本异常重启）、定期给实例打系统安全补丁

关于Lambda的适用性：你当前是流式采集场景，需要保持和Twitter API的长连接持续运行，Lambda最大运行时长只有15分钟，确实没办法支持这种长驻进程的场景，不用考虑。

现有数据流适配说明 #

不管选上面哪种方案，你的原有脚本逻辑基本不需要修改，只需要引入AWS Python SDK boto3，调用put_record/put_record_batch接口把采集到的推文写入Firehose流即可，后续的数据库投递逻辑完全不变。

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