Amazon API Gateway 设计模式 - REST API 与 HTTP API 的选型标准
明确 HTTP API 与 REST API 的选型标准，介绍 Cognito 和 Lambda Authorizer 的认证模式以及限流设计的实践方法。
REST API 与 HTTP API 的选型标准
API Gateway 提供 REST API 和 HTTP API 两种类型。HTTP API 于 2019 年 12 月以预览版发布，并于 2020 年 3 月正式发布，覆盖了 REST API 的主要功能，同时价格最多便宜 71%，延迟也更低。如果主要用途是代理 Lambda 函数或 HTTP 端点，应选择 HTTP API。需要选择 REST API 的场景包括：通过 API 密钥和使用量计划向第三方公开 API、请求/响应转换（映射模板）、与 WAF 集成、边缘优化端点、请求验证功能。新项目建议默认使用 HTTP API，仅在需要 HTTP API 不具备的功能时才考虑 REST API。
认证与授权模式
API Gateway 支持多种认证方式，但可用的 Authorizer 类型在 REST API 与 HTTP API 之间有所不同（截至 2026 年 8 月）。Cognito 用户池 Authorizer（COGNITO_USER_POOLS）是 REST API 特有的方式，由 API Gateway 自动验证 Cognito 签发的 JWT 令牌。由于无需自行实现令牌验证逻辑，在使用 Cognito 的架构中易于引入。HTTP API 没有这种 Authorizer，而是使用 JWT Authorizer。JWT Authorizer 遵循 OpenID Connect（OIDC）和 OAuth 2.0 的框架，通过指定签发者（issuer）和受众（audience）来验证 JWT。由于 issuer 也可以指定为 Cognito 用户池，在 HTTP API 中同样可以实现基于 Cognito 的认证，但请注意需要配置的 Authorizer 类型不同。JWT Authorizer 使用从 issuer 的 jwks_uri 获取的公钥验证签名（仅支持 RSA 系列算法），并评估 iss、aud、exp 等声明。若按路由设置授权范围（scope），还可以基于令牌中包含的 scope 进行访问控制。Lambda Authorizer 是通过 Lambda 函数实现自定义认证逻辑的方式，适用于自定义令牌格式、与外部 IdP 集成、基于 IP 地址的控制等需要灵活授权逻辑的场景。Lambda Authorizer 的结果可缓存，设置 TTL 可减少重复的认证请求。IAM 认证使用 AWS SigV4 签名验证请求，适用于 AWS 服务间的内部通信。
限流与使用量计划
API Gateway 的限流基于令牌桶算法实现。账户级别的默认上限为每区域 10,000 请求/秒，突发为 5,000 请求。可在阶段级别和方法级别设置更细粒度的限制，防止特定端点使后端过载。使用量计划是 REST API 特有的功能，可为每个 API 密钥设置每日和每月的请求上限及限流速率。向外部合作伙伴公开 API 时，可为不同合作伙伴应用不同的速率限制。收到 429 Too Many Requests 响应的客户端，建议实现指数退避重试。
API Gateway 定价
HTTP API 每百万请求约 1.00 美元，与 REST API 的 3.50 美元相比便宜约 71%（截至 2026 年 8 月）。WebSocket API 每百万消息约 1.00 美元，加上连接时间计费（每百万分钟约 0.25 美元）。启用 REST API 缓存后，按缓存内存大小按时计费（0.5 GB 约 0.02 美元/小时）。合理设置 Lambda Authorizer 的缓存 TTL，减少认证请求的 Lambda 调用次数，也是成本优化的有效手段。对于 2025 年 7 月 15 日前创建的旧账户，12 个月免费套餐中 HTTP API 和 REST API 各包含每月 100 万请求；此后创建的新账户适用额度制免费计划（最多 200 美元），最新条件请以 AWS 官方网站为准。
集成类型与后端连接
API Gateway 可以将请求转接到各种后端。将请求原样传递给 Lambda 函数的代理集成简单易用，也最为常见。还有转发到现有 HTTP 服务的集成，以及连接到 VPC 内私有服务的机制。如果使用不经过后端、直接调用部分 AWS 服务的集成，在简单的处理中可以省去 Lambda，从而控制成本和延迟。通过设计在公开的 API 背后放置什么以及如何连接，可以在保持架构简洁的同时提供所需的功能。根据需求选择合适的集成类型。
请求与响应的处理
API Gateway 具备对请求和响应进行加工的功能。通过验证输入格式是否正确，在不正确的请求到达后端之前将其拒绝，可以避免无谓的处理和负载。还可以转换请求和响应的结构，整理成客户端和后端各自都易于处理的形式。由此，可以在不改变后端规格的情况下，调整对外公开的 API 的形式。在入口处进行验证和转换，可以在保护后端实现的同时，为使用者提供易用且一致的 API。
基于 WebSocket 的实时通信
通常的 API 以响应客户端请求的单向交互为基本形式。另一方面，如果希望从服务器随时向客户端推送（push）数据，需要双向实时通信，可以构建支持 WebSocket 的 API。适用于聊天、通知、实时更新显示等用途。可以针对连接的建立与断开、消息的接收等每个事件定义处理，并从服务器端主动向连接中的客户端发送消息。根据用途区分使用请求响应型和实时型，可以满足多种应用程序的通信需求。
监控、缓存与运维
在 API 的运维中，需要监控请求数、错误率和延迟，以便能够发现异常。记录访问日志后，可以追踪发生了哪些调用，有助于调查问题。对于频繁返回相同结果的端点，可以使用缓存响应的功能，降低后端的负载和延迟。还可以使用阶段区分开发和生产环境，并进行以部分流量试用新版本的金丝雀发布。通过组合监控、缓存和分阶段发布，可以提供能够稳定运行的 API。
总结
API Gateway 作为无服务器架构的入口，在 API 层统一管理认证、限流和监控。以 HTTP API 作为默认选择，在需要企业级功能时选择 REST API，通过这一判断标准可以优化成本和延迟。
参考资料（AWS 官方）
本页的第一手信息来源是 AWS 官方网站及官方文档。最新的规格与价格请以下列官方页面为准。
如本页内容与官方文档不一致，请以官方文档为准。