AWS环境下用API Gateway替代ALB实现mTLS认证及粘性会话方案咨询

问题1：API Gateway是否可替代ALB实现负载均衡/防火墙功能并支持mTLS？ #

该说法是正确的。API Gateway完全可以承担HTTP/HTTPS流量的负载转发、访问控制（类似防火墙）功能，同时支持原生mTLS认证：你只需在API Gateway的自定义域名配置中启用mTLS，上传用于验证客户端身份的CA证书，即可把认证环节从EC2实例转移到网关层面，无需后端再处理证书验证逻辑。

问题2：如何实现API Gateway不支持的粘性会话？ #

你提出的思路是可行的，具体落地可以按以下步骤操作：

• 客户端首次请求API Gateway时，网关随机转发请求到任意EC2实例
• 首次处理请求的EC2实例在响应中返回自身唯一标识（比如实例私有IP、自定义实例ID），并引导客户端将该标识存储在本地（Cookie、localStorage或自定义请求头均可）
• 后续客户端请求时，在请求中携带该实例标识；API Gateway通过预设的路由规则（识别请求头、路径参数或查询参数），将流量直接转发到对应标识的EC2实例

需要注意：这种方式需要修改客户端和后端逻辑，且当EC2实例扩缩容时，需同步更新API Gateway的路由映射关系，更适合实例数量相对稳定的场景。

问题3：API Gateway的其他缺点及更优解决方案？ #

API Gateway的其他缺点

• 路由配置复杂度高：相比ALB简单的转发规则，API Gateway的路由、集成配置更繁琐，精细流量控制的学习成本更高
• 链路排查难度大：流量经过网关转发后，后端问题排查需要跨网关、EC2两层日志分析，链路追踪复杂度提升
• 功能冗余：API Gateway自带限流、缓存、API文档等API管理功能，若仅需负载均衡和mTLS，这些冗余功能会增加维护成本
• 低延迟场景适配差：虽然集成EC2无Lambda冷启动问题，但API Gateway自身偶尔会有初始化延迟，对延迟敏感的业务可能有影响

更优替代方案

• ALB + WAF + 自定义认证Lambda：无需替换现有ALB架构，通过WAF拦截请求并调用Lambda验证客户端证书有效性，验证通过后再转发到ALB，既保留ALB的粘性会话功能，又实现mTLS认证效果，成本远低于API Gateway
• NLB + 后端mTLS：NLB支持转发TLS流量到EC2，同时支持基于源IP的粘性会话；你只需在EC2层面配置mTLS认证，适合需要高吞吐量、低延迟的场景
• App Runner（若应用可容器化）：完全托管的服务，原生支持mTLS和会话粘性，自动管理负载均衡与实例扩缩容，运维成本极低

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