ALB路由在ECS夜间停机时返回维护提示的实现方案咨询

针对你遇到的夜间停机返回503、想要自定义维护提示的需求，以下是几个在ALB/目标组层面实现的方案：

方案1：基于目标组健康状态的ALB规则分支（推荐） #

这是最直接的原生方案，无需额外资源，完全依赖ALB的规则逻辑：

• 编辑现有ALB规则，将单一的「转发到目标组」动作，修改为**「基于目标组健康状态的分支动作」**
• 设置分支逻辑：
  • 当目标组 my-dev-nginx-tg 存在健康实例时，保持转发到该目标组
  • 当目标组所有实例都不健康（夜间停机状态），执行「返回固定响应」动作：
    • 状态码选 503（符合服务不可用的语义）
    • 响应体填写 it's maintanance time
    • Content-Type 设置为 text/plain 或 text/html（若需要美化提示可使用HTML）
• 关键前提：确保目标组的健康检查配置正确，停机后的实例会被ALB标记为「不健康」，这样分支逻辑才能触发。

方案2：定时切换ALB规则优先级 #

适合有固定维护时段的场景，通过定时任务自动切换规则生效顺序：

• 提前创建一条新的ALB规则：匹配条件同样是「HTTP Host Header is example.com」，动作设置为「返回固定响应」（内容同方案1）
• 利用AWS Lambda + CloudWatch Events 定时执行：
  • 白天：将这条维护规则的优先级调低（或直接禁用），让原有的转发规则优先匹配
  • 夜间：将维护规则的优先级调高（或启用），让请求直接命中这条规则返回提示
• 优缺点：灵活控制时间，但需要额外配置Lambda和定时任务，增加少量运维成本。

方案3：目标组配置备用目标 #

通过目标组的备用机制，在主目标组失效时转发到备用服务：

• 搭建一个低成本的备用服务（比如用1台t2.micro EC2跑Nginx，专门返回维护提示页面），创建对应的备用目标组
• 在 my-dev-nginx-tg 的配置中，设置「备用目标组」为刚才创建的备用组
• 当主目标组所有实例不健康时，ALB会自动将请求转发到备用目标组，返回自定义提示
• 优缺点：复用现有ALB规则，但需要维护额外的备用服务，虽然成本低，但有资源占用。

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