AWS调度机制咨询：延迟发送邮件的Step Functions替代方案及相关疑问

除Step Functions外的可用调度方案 #

• EventBridge定时规则 + Lambda + 持久化存储：将所有待发送邮件的元数据（收件人、内容、预定发送时间等）存入DynamoDB或自建数据库，配置Amazon EventBridge按固定周期（如每小时、每天）触发Lambda函数，扫描库中已到达发送时间的任务，执行邮件发送逻辑。该方案无最长调度时长限制，跨天、跨月、跨年的延迟任务都可以支持，资源成本也相对更低。
• SQS延迟队列组合方案：仅适合最大延迟不超过15分钟的短周期场景，如果你有大量短延迟+少量长延迟的混合需求，可以搭配上面的数据库方案做分级处理：距离发送时间不足15分钟的任务直接推入SQS延迟队列自动触发发送，更长周期的任务先存入数据库，待临近发送时间再移入队列，减少定时扫描的资源消耗。
• 自托管调度工具：如果是私有部署场景，可以选用Airflow、Celery Beat等开源定时调度工具，自行维护任务元数据，调度时长可按需自定义，不受云服务配额限制。

Step Functions相关顾虑解答 #

• 关于最长等待时长限制：Step Functions的单个Wait状态确实存在最长1年的运行上限，如果你的延迟需求超过1年，可以拆分等待逻辑：每次设置Wait状态最长运行360天，运行结束后校验是否到达预定发送时间，未到达则重新进入下一个Wait状态，即可突破单步时长限制。
• 关于堆栈删除时的任务处理：如果你通过CloudFormation/CDK部署包含Step Functions的堆栈，删除堆栈时仅会删除状态机资源本身，已经启动的等待中执行实例不会被同步终止，会继续运行直到执行完成或超时。如果需要彻底清理任务，需要在删除堆栈前手动终止所有正在运行的Step Functions执行实例。

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