AWS ALB配置规则指向S3键实现独立于应用的统一验证路径

实际场景与踩过的无效方案 #

• 现有资源现状：多台应用负载均衡器（ALB）分别承接不同业务应用的流量，后端覆盖ECS、Windows/Linux系统的EC2实例，所有绑定到这些ALB的域名，都需要对外提供统一的 /.well-known/... 路径的校验内容
• 方案刚性要求：所有逻辑必须和后端实际应用完全解耦，不能侵入现有业务的代码、配置，需要适配所有类型的后端服务，配置简单、长期维护成本低
• 已验证不可行的尝试：
  • 将所有验证文件存到公共S3桶，在ALB配置规则把 /.well-known/ 路径的请求301/302重定向到S3对应地址，由于发起校验的服务本身不会跟随重定向跳转，该方案完全无法满足校验要求
  • 已确认可行但配置复杂的方案：为ALB创建Lambda类型目标组，匹配到验证路径的请求直接转发给Lambda，由Lambda从S3拉取对应验证文件内容返回给客户端。该方案可以正常生效，但流程涉及创建Lambda函数、配置IAM权限、创建专属目标组、逐台调整ALB监听器规则等多步操作，链路太长，不符合简便易维护的预期

比Lambda方案更简便的替代实现 #

这个方案的响应效果和Lambda方案完全一致，没有重定向跳转问题，配置步骤精简70%以上，完全和后端业务解耦：

• 第一步：把所有需要对外提供的 /.well-known/ 验证文件统一上传到一个公共S3桶，开启桶的静态网站托管能力，配置桶策略仅允许静态网站托管端点读取对应路径的对象，不对整个桶放开公开权限
• 第二步：针对所有ALB，给监听器添加一条优先级最高的匹配规则：
  • 路径匹配条件：/.well-known/*
  • 动作设置：不使用重定向，而是通过IP类型目标组直接转发到S3静态网站托管的公开端点。ALB作为反向代理，会在服务端内部向S3发起请求拉取验证文件内容，再将内容以原域名的响应身份返回给校验客户端。客户端全程只和原域名的ALB通信，完全感知不到后端的转发逻辑，从根上避开了之前重定向方案的硬伤
• 第三步：后续新增、更新验证文件时，只需要往这个公共S3桶的对应路径上传文件即可，不需要调整任何ALB规则、后端应用配置

方案实际优势 #

• 零业务侵入：所有逻辑在ALB监听器层实现，完全不涉及后端ECS、EC2的应用配置、代码调整，不管后端是Windows还是Linux系统、跑什么架构的应用，规则都会统一生效
• 配置效率极高：不需要编写Lambda代码、不需要配置Lambda相关的IAM权限、不需要维护函数运行状态，只需要创建一次指向S3静态端点的目标组，所有ALB复用同一个目标组即可，单台ALB的规则配置耗时从十几分钟压缩到1分钟以内
• 长期维护成本极低：所有验证文件统一存放在S3，内容更新不需要逐台调整ALB配置，多ALB场景下可以通过基础设施代码批量同步规则，不会出现配置遗漏
• 兼容性完全达标：因为是ALB代理返回S3的内容，校验客户端收到的响应就是从自己请求的域名下返回的，不存在跨域、重定向跳转的问题，和之前验证过的Lambda方案的响应效果没有区别

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