Amazon API Gateway 详解：部署模式、权衡与使用场景

Amazon API Gateway 是 AWS 用于发布、保护、监控和运营 REST、HTTP 与 WebSocket API 的托管服务。它让团队无需配置和维护网关服务器，但不会消除架构决策。你仍然需要选择 API 类型、公网或私网暴露方式、集成类型、身份模型、限流目标、可观测性、配额和应用侧授权。

应从能够满足硬性要求的最小 API 类型开始。HTTP API 适合许多直接的 Lambda 或 HTTP 代理场景；REST API 提供更广泛的 API 管理能力；WebSocket API 用于有状态的双向消息。正确选择取决于所需行为，而不是应用架构图上是否写着“REST”。

核心要点

• REST API、HTTP API 与 WebSocket API 是能力和运维契约不同的产品。
• 托管基础设施减少服务器运维，但配额、限流、安全、日志与成本责任依然存在。
• 集成方式和端点暴露应一起选择；后端位于私网并不自动意味着公开 API 也是私有的。
• 把限流视为保护目标，而不是精确配额或下游容量控制的替代品。
• 在形成统一标准前，用一个代表性路由验证完整的身份、转换、超时与失败路径。

理解服务边界

AWS 服务概览把 API Gateway 描述为用于创建、发布、维护、监控和保护 REST、HTTP 与 WebSocket API 的服务。托管数据面接收客户端流量，再调用 AWS Lambda、HTTP 端点或 AWS 服务集成等已配置后端。

AWS 负责运营 API Gateway 集群，你的团队仍然负责：

• API 路由、Stage、Deployment 与自定义域名；
• 授权，以及对声明或请求上下文的信任；
• 请求与响应转换；
• 后端权限、幂等性、超时与扩缩容；
• 日志、指标、告警、留存与敏感数据处理；
• 客户端重试行为和兼容性；
• 服务配额及其对应的容量规划；
• 基础设施即代码的审查、提升与回滚。

API Gateway 授权不等于应用对象级授权。拥有账户、订单或文档状态的服务仍必须验证调用者能否操作具体对象。

选择 API 类型

HTTP API

如果你需要一个复杂度较低的 HTTP 入口，并且其支持的集成与授权方式能够满足需求，可以选择 HTTP API。HTTP API 支持路由级限流目标以及常见的 Lambda 或 HTTP 代理模式，但它并不是涵盖所有 REST API 功能的简单“新版”。

REST API

如果需要官方 REST API 与 HTTP API 对比中只由 REST API 提供的能力，应选择 REST API，例如 API Key、按客户端限流与 Usage Plan、请求验证、AWS WAF 集成或私有 API 端点。REST API 还提供边缘优化端点选项，以及更广泛的转换和管理能力。

API Key 用于识别 Usage Plan Consumer，并不是强健的终端用户身份认证。身份认证与授权仍需单独设计。

WebSocket API

如果客户端与后端需要在建立连接后进行长期双向消息通信，可选择 WebSocket API。应建模 $connect、$disconnect 和应用路由，并规划连接认证、空闲行为、连接配额、状态存储和消息重试。WebSocket 连接本身不会让后端工作流具备可靠或“恰好一次”语义。

选择集成与网络路径

针对 REST API，AWS 在集成指南中记录了 Lambda、HTTP、AWS 服务与 Mock 集成。代理集成会把较完整的请求信封传给后端；非代理集成可以映射方法请求与响应。HTTP API 则有自己的集成集合和 Payload 版本。

为每个路由绘制完整路径：

1flowchart LR
2    C[客户端] --> E[API Gateway 端点]
3    E --> Z[Authorizer 与路由策略]
4    Z --> M[映射或代理契约]
5    M --> B[Lambda、HTTP 服务或 AWS 服务]
6    B --> E
7    E --> C

明确后端是通过公网、Lambda 调用、直接 AWS 服务集成还是 VPC 连接访问。如果网关是安全边界，应限制后端权限，防止客户端绕过网关直接访问。对 Lambda 使用资源策略和最小权限执行角色；对于 HTTP 源站，在适用时使用网络控制或经过认证的源站请求。

设计身份与授权

根据 API 类型和客户端模型，在 IAM 授权、受支持的 JWT 或 Cognito Authorizer、Lambda Authorizer 与资源策略之间选择，然后明确：

• Token 签发者、Audience、签名算法、过期和时钟处理；
• 哪些声明会成为可信上下文；
• 路由和方法权限映射；
• 仍由应用负责的租户与对象授权；
• Authorizer 缓存键和撤销时效；
• 不泄露内部策略信息的错误响应。

不能因为某个公开请求头经过 API Gateway，就把它当作已验证身份。集成必须区分网关创建的上下文与调用方可控字段。

把限流视为目标

AWS 在 HTTP API 限流文档中说明，限流使用令牌桶模型，以尽力而为方式执行，应理解为目标而不是保证不会突破的上限。超额流量可能收到 429 Too Many Requests。

路由与 Stage 目标应低于经过验证的下游容量，并为共享的账户级限制保留空间；客户端应使用有上限且带抖动的重试。对稀缺的后端工作还要使用自身的并发与队列控制。网关限流无法撤销其他位置已经接受的工作，也不能保证按每个业务维度公平分配。

应检查目标区域和 API 类型的最新 API Gateway 配额。部分配额可以调整，另一些不能。不要在没有验证日期的长期架构文档中复制固定数字。

让配置可复现

通过基础设施即代码或导出定义管理 API，避免只在控制台中修改。AWS 记录了用于 API Gateway 特定集成与授权的 OpenAPI 扩展。这些扩展有助于复现，但也会让定义绑定到 AWS。

应在非生产 Stage 验证变更，比较已部署配置，运行契约测试，再提升不可变版本。密钥不能写入 OpenAPI 文档。路由、Authorizer、集成、映射、域名和 Stage 设置变更都要定义回滚方案。

观测完整请求

指标和结构化日志应能够区分：

• 网关拒绝、授权拒绝、限流、集成错误与后端错误；
• 网关延迟与集成延迟；
• 路由和 Stage，同时避免把个人数据写入指标维度；
• API Gateway、Authorizer、Lambda 或服务以及下游调用中的请求关联；
• Deployment 版本，使行为能够关联到具体变更。

如果格式设计不当，访问日志可能包含 Token、查询数据和标识符。应只允许必要字段，并使用留存控制、加密与受限访问。高流量成功数据可以按需采样，但错误和拒绝应保留可靠计数。

评估权衡

当团队希望获得 AWS 托管入口、受支持的 AWS 集成、按请求扩展能力，并减少网关集群运维时，Amazon API Gateway 很适合。若需求涉及不支持的协议、大量自定义数据面代码、跨云可移植性、可预测的高流量成本、异常大或长时间运行的消息，或者需要控制底层代理行为，就应谨慎评估并通过原型验证。

比较时要计算总运维成本，而不只是请求单价：还应包括数据传输、日志、Authorizer、Lambda、缓存、私网连接、可观测性、支持与工程人力。决策时使用官方计算器验证最新价格，不要依赖静态示例。

评估检查清单

• 哪种 API 类型以最小能力表面满足所有硬性需求？
• 端点是否按预期采用公网、区域、边缘优化或私有模式？
• 客户端能否绕过网关直接访问后端？
• 身份、路由授权与对象授权是否分离？
• 超时、载荷、连接和账户配额是否适合工作负载？
• 限流和客户端重试是否与下游容量匹配？
• 已部署配置能否比较、测试与回滚？
• 日志和指标能否区分网关、Authorizer、集成与后端故障？
• 是否使用代表性流量和可观测性配置建立成本模型？

总结

Amazon API Gateway 并不是一种通用网关模式。REST、HTTP 与 WebSocket API 提供不同的功能集合与约束。应选择能够满足需求的最小 API 类型，建模完整的集成与身份路径，规划配额和限流，并保留应用授权与可靠性控制。只有其余责任同样清晰时，托管基础设施的价值才能真正体现。

常见问题

HTTP API 是否始终优于 REST API？

不是。HTTP API 适合很多简单场景，而特定的管理、验证、WAF、Usage Plan 和私有端点能力仍需要 REST API。

使用 API Gateway 后是否不再需要负载和故障测试？

仍然需要。应使用代表性工作负载测试授权、集成超时、下游饱和、限流、重试、配额和可观测性。

API Gateway 能否取代应用授权？

它可以执行路由级策略并提供已验证身份上下文，但拥有领域数据的服务仍必须执行对象与工作流规则。

后续步骤

比较开源与商业网关的运维模型，设计安全的超时与重试行为，并建立 API 访问日志审计。