多区域ALB后对接SNS的Lambda双活架构健康检查咨询

SNS依赖的健康检查实现要点 #

别用公开示例里那种只返回环境变量预设值的浅健康检查，这种检查只能证明Lambda进程能启动，完全感知不到依赖故障、配置错误这类真实影响业务的问题。
对接SNS的场景下，没必要每次健康检查都往生产主题发dummy测试消息——既可能污染生产消息流，长期跑也会产生不必要的成本，可行的检测方式包括：

• 只读权限校验：健康检查逻辑里调用SNS的GetTopicAttributes接口，验证当前Lambda绑定的生产SNS主题是否存在、执行角色是否有对应发布权限、主题状态是否为可用。这个接口是只读操作，不会产生任何消息推送，调用开销极低，能覆盖90%以上的配置类、权限类故障。
• 连通性轻量校验：在同区域单独创建一个没有任何订阅者的SNS测试主题，健康检查时往这个测试主题发送1字节以内的测试消息，验证Lambda到SNS服务的网络连通性、端点可用性、VPC安全组/端点配置是否正常。这个操作不会影响生产消息流，单月产生的成本基本可以忽略。

额外注意：健康检查的总执行超时要比上层负载均衡/Route53配置的检查超时短1-2秒，不要在健康检查逻辑里塞无关的依赖校验，避免因为非核心依赖故障导致健康检查误报，把正常的节点切走。

两种Route53健康检查配置的差异与选型 #

方案1：ALB指向健康检查端点 + Route53别名记录开启Evaluate Target Health #

• 检查发起方：由同区域ALB的节点从内网发起健康检查请求，流量不经过公网。
• 故障判定粒度：ALB首先会在目标组级别做故障摘除，单个Lambda实例、单个可用区的故障会被ALB直接屏蔽，不会触发跨区域切流；只有当该ALB下所有后端Lambda目标都判定为不健康时，Route53才会把对应区域的别名记录标记为异常，将流量切到其他健康区域。
• 优势：检查链路稳定，不会因为公网波动产生误判，能减少不必要的跨区域流量绕行。

方案2：Route53 CNAME记录直接绑定健康检查端点 #

• 检查发起方：由Route53部署在全球的公网健康检查节点从公网发起请求，模拟普通公网用户的访问链路。
• 故障判定粒度：直接从公网视角判定整个区域的服务可达性，无法感知区域内部单实例、单可用区的局部故障，只要公网访问连续失败达到阈值，就会标记整个区域异常并切流。
• 劣势：公网链路波动、区域边缘节点故障都可能导致误判，检查准确率低于内网检查。

选型建议 #

如果每个区域已经部署ALB作为Lambda的流量入口，只选方案1即可，不需要同时配置两层健康检查：
ALB的内网健康检查准确率更高，先在区域内部消化局部故障，只有出现区域级大面积故障时才触发跨区切流，是多区域active/active架构的最优选择。两层健康检查同时配置反而会因为判定逻辑不一致出现调度冲突——比如公网临时波动时ALB侧后端完全健康，但Route53已经把区域标记为异常，导致不必要的跨区流量绕行。
如果没有部署ALB，是直接通过CNAME将域名指向Lambda Function URL/API Gateway公网端点，再选择方案2配置Route53公网健康检查即可。

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