AWS ApiGatewayV2 HTTP API能否使用自定义授权Lambda？

我之前也碰到过类似的需求——AWS HTTP API确实只支持官方的JWT授权器，没法直接用自定义Lambda来验证非标准令牌，不过有几个靠谱的替代方案：

方案1：用Lambda@Edge + CloudFront前置验证 #

这是我最推荐的方案，能在请求到达HTTP API之前就完成令牌校验，不会浪费API的资源：

• 把你的HTTP API放到CloudFront分发后面，配置CloudFront的 origin 指向HTTP API的域名
• 在us-east-1区域创建Lambda@Edge函数（Lambda@Edge要求函数必须在这个区域创建），触发阶段选Viewer Request
• 在函数里编写逻辑：从请求头（比如Authorization）提取令牌，调用第三方服务完成验证
• 验证通过就直接转发请求到HTTP API；验证失败则返回401 Unauthorized或403 Forbidden响应

注意：Lambda@Edge有执行时间限制（最多5秒），要确保你的令牌验证逻辑足够高效。

方案2：用REST API做中间授权层 #

因为API Gateway V1（REST API）支持自定义Lambda授权器，我们可以把它作为HTTP API的前置网关：

• 创建一个REST API，配置自定义Lambda授权器，在授权器里实现你的非标准令牌验证逻辑
• 在REST API中设置集成目标为你的HTTP API，开启代理集成
• 让客户端请求这个REST API的端点，授权器验证通过后，请求会被代理到对应的HTTP API资源

这种方案的好处是不需要额外配置CloudFront，但会多一层API转发，可能带来轻微的延迟。

方案3：在HTTP API后端直接处理验证 #

如果前面两种方案的配置成本对你来说太高，也可以把验证逻辑放到HTTP API的后端服务里：

• 在后端服务的入口处（比如Lambda的handler函数开头、ECS服务的请求拦截器）提取请求中的令牌
• 调用第三方服务完成令牌验证，验证失败直接返回401响应
• 验证通过后再处理正常的业务逻辑

这个方案的缺点是：请求已经到达后端才做验证，会消耗后端资源；如果有多个后端服务，验证逻辑需要重复实现，维护成本较高。

你可以根据自己的架构复杂度、性能要求来选择最适合的方案，我自己用方案1解决过类似的非标准令牌验证需求，稳定性和性能都不错。

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