如何自动删除重建AWS Transfer Family服务实现按需降本

核心结论 #

完全可以通过自动化方式实现Transfer Family服务器的定时创建、到期删除，完全匹配你每周1次、每次1-2小时的使用需求，后续调整为每日运行仅需修改调度规则即可，整体成本仅为24/7运行的1%~5%，没有额外的资源开销。

注意：AWS Transfer Family没有“停机不计费”的状态，官方明确只有删除服务器才会终止对应计费项，所有尝试“停服不删”的操作都会持续产生费用，不要在这上面浪费时间。

前置准备：固化配置避免重复劳动 #

每次删建服务器不需要重新手动配置所有参数，提前把固定配置抽离留存即可：

• 将sFTP用户的SSH公钥、关联的IAM角色（需包含目标S3桶的读写权限、Transfer服务信任策略）、安全组规则、VPC子网信息、日志投递配置、S3挂载路径等固定参数，直接写入基础设施模板或者存在SSM参数存储中
• 底层网络资源（VPC端点、安全组、子网、IAM角色、S3桶）不需要随服务器删除，重建Transfer服务器时直接关联已有资源即可，整个创建过程仅需1~3分钟
• 给所有自动创建的Transfer服务器统一打上自定义标签，比如ScheduleSFTP=AutoDelete，后续销毁时仅匹配带该标签的资源，避免误删其他生产环境的Transfer资源

具体实现逻辑 #

自动化脚本 #

直接用AWS CLI或者Python boto3写逻辑即可，不需要复杂的依赖，核心分两个流程：

1. 创建流程（运行窗口开始前5分钟触发）
   执行步骤：
   • 调用create_server接口，传入提前留存的固定配置，创建SFTP协议的Transfer服务器
   • 轮询服务器状态，待状态变为ONLINE后，调用create_user接口创建预设的sFTP用户，关联S3访问权限和主目录
   • 将新生成的服务器访问地址、登录信息推送到你常用的通知渠道即可
     核心创建命令参考：

   # 创建SFTP服务器
   aws transfer create-server \
     --protocols SFTP \
     --identity-provider-type SERVICE_MANAGED \
     --endpoint-type VPC \
     --endpoint-details VpcId=vpc-替换成你的VPCID,SecurityGroupIds=sg-替换成你的安全组ID,SubnetIds=subnet-替换成你的子网ID \
     --logging-role arn:aws:iam::替换成你的账号ID:role/替换成你的Transfer日志角色名 \
     --tags Key=ScheduleSFTP,Value=AutoDelete
   

2. 删除流程（运行窗口结束时触发）
   执行步骤：
   • 列出当前账号下所有Transfer服务器，过滤出带ScheduleSFTP=AutoDelete标签的目标服务器
   • 调用delete_server接口删除对应服务器，计费即刻终止
     核心删除命令参考：

   # 筛选匹配标签的待删除服务器ID
   TARGET_SERVER=$(aws transfer list-servers --query "Servers[?Tags[?Key=='ScheduleSFTP' && Value=='AutoDelete']].ServerId" --output text)
   # 执行删除
   aws transfer delete-server --server-id $TARGET_SERVER
   

定时调度 #

不需要单独维护服务器跑脚本，直接用AWS原生服务实现调度即可：

• 把上述创建、删除逻辑打包成Lambda函数，分配对应操作Transfer、IAM、S3的最小权限
• 用EventBridge配置两条定时规则：
  • 启动规则：按你的使用周期配置cron表达式，比如每周一8:00触发创建Lambda，后续调整为每日运行只需要修改cron周期
  • 销毁规则：配置为每次启动后2小时触发删除Lambda，或者直接按窗口结束时间配置cron，比如每周一10:00触发销毁
• 额外加一条异常告警：如果到了销毁时间点服务器未被成功删除，直接推送告警通知，避免遗忘产生额外账单

额外优化建议 #

• 不要把服务器端点类型选公网类型，优先选VPC内网端点，安全组只放信任的IP段访问，降低暴露风险
• 如果sFTP仅用于文件上传，可以给sFTP用户配置最小S3权限，仅开放指定上传路径的写权限，避免权限过大
• 如果后续使用频率提升到每天数小时，这个方案依然适用，只需要调整调度的时间窗口即可，不需要改动核心逻辑

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