Amazon DVA-C02: Amazon API Gateway 与应用集成 — 学习指南

By Laurynas Brazys · 28 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

属于 AWS Developer Associate DVA-C02 — 学习指南. 使用经过验证的答案练习： Amazon 考试中心, 或参加限时模拟考试： ExamRoll.io.

使用 API Gateway (REST, HTTP, WebSocket) 设计 API 及其集成

设计始于选择合适的 API 类型：REST API (API Gateway REST) 提供精细的阶段级功能，例如按阶段缓存和复杂的映射模板；HTTP API (API Gateway v2) 为常见的代理模式和原生 JWT/OIDC 授权方提供更低的延迟和成本；WebSocket API 提供持久的客户端-服务器通道，具有路由键（$connect、$disconnect、$default），并且需要使用 API Gateway Management API (PostToConnection) 来发送消息。在构建集成时，对于简单的请求/响应，优先选择 AWS_PROXY/Lambda 代理（使用 aws apigateway put-integration –type AWS_PROXY，或者对于 v2 版本，在 ApiGatewayV2Client 上使用 CreateIntegration），并为私有 HTTP 后端选择 HTTP 或 VPC Link。对于高吞吐量后端，请使用 NLB + VPC Link。模拟集成（put-integration –type MOCK）和集成响应模板让前端团队可以在后端未就绪时开始工作。当使用 CloudFront 作为 API 的前端时，应使用区域 API 端点作为源，并将“源协议策略”(Origin Protocol Policy) 设置为“仅 HTTPS”(HTTPS-only)；边缘优化的 REST API 本身就已经位于 CloudFront 之后。常见的陷阱包括 API 和 Lambda 之间的负载格式版本不匹配（v1.0 vs 2.0）、忘记授予 apigateway.amazonaws.com 调用 Lambda 的权限（使用 aws lambda add-permission –principal apigateway.amazonaws.com 添加权限），以及导致浏览器阻塞的 CORS 配置错误。

安全与授权模式 (Cognito, IAM, 自定义授权方)

安全模式应与客户端类型和访问模型相匹配：对于 HTTP API，使用 Amazon Cognito User Pools 或外部 OIDC 提供商，并将其配置为 JWT 授权方（在 apigatewayv2 中使用 CreateAuthorizer，并将 identitySource 设置为 $request.header.Authorization）；或者，对于基于会话的用户访问，使用 REST API 的 Cognito Authorizers。对于服务到服务或管理 API，优先选择 IAM 授权 (SigV4)，并在阶段和方法上使用范围严格的 IAM 资源策略。Lambda（自定义）授权方在实现定制化认证规则方面提供了最大的灵活性，但请记住它们会增加延迟和故障模式——应通过 TTL 缓存授权方响应以减少冷启动，并避免抛出向客户端返回 500 的错误。通过使用计划和 API 密钥（aws apigateway create-usage-plan 和 create-api-key）并结合限制配额来防止滥用。确保 IAM 权限正确：授予 API Gateway 调用 Lambda 的权限（aws lambda add-permission），并将 Lambda 执行角色限制为最小权限。开发人员的常见疏忽包括：忘记为 JWT 授权方启用令牌提取、授权方超时影响整体 API 延迟，以及 CloudFront 转发了可能无意中绕过缓存或泄露用户数据的标头/Cookie。

阶段管理、版本控制、缓存和金丝雀部署

将阶段视作独立的运行时环境：部署是快照（aws apigateway create-deployment 或 apigatewayv2 create-deployment），而阶段则映射到这些快照。使用阶段变量，或者最好是使用 Lambda 别名，在不同版本之间路由流量；可以原子化地切换别名（UpdateAlias），或使用 API Gateway 的阶段金丝雀设置进行逐步发布。对于 REST API，在阶段级别启用缓存（使用 aws apigateway update-stage 并通过 patch-operations 设置 cacheClusterEnabled 和 cacheClusterSize），并在方法设置中控制 TTL 和缓存键参数；HTTP API 目前没有内置缓存，因此需要使用 CloudFront 或应用程序级缓存。在部署时或当底层数据发生变化时，应清除缓存；仅依赖 TTL 可能会返回陈旧数据。版本控制模式：在路径中使用语义化的 API 版本控制（/v1/…），或依赖阶段化部署实现蓝/绿发布流程。常见的陷阱包括：假设阶段变量是安全的（拥有控制台访问权限的开发人员可以看到它们）、错误配置缓存键（忘记包含授权标头或查询参数），以及模式变更的部署未与客户端兼容性进行协调。

性能、可观测性与诊断

端到端检测 API：在 API Gateway 上启用执行日志和访问日志，并将结构化的 JSON（$context 变量）输出到 CloudWatch Logs；在 API Gateway 和 Lambda 上启用 X-Ray（在部署/阶段中设置 tracingEnabled 或使用 SDK：通过 TracingConfig 调用 PutFunctionConcurrency/UpdateFunctionConfiguration）以关联追踪。在 CloudWatch 中监控 API Gateway 指标（Latency、IntegrationLatency、4XX/5XX、CacheHitCount）和 Lambda 指标（Duration、Throttles、ConcurrentExecutions）；使用指标数学（metric math）来识别延迟累积的位置。对于 WebSocket，跟踪连接数和 API Gateway 5XX 错误激增的情况。故障排查步骤包括：比较 IntegrationLatency 与 Latency 以判断是后端还是网关增加了开销，深入分析 X-Ray 分段（segment）以查找冷启动或 VPC ENI 问题，以及检查 CloudWatch Logs 中的映射模板错误。对异步 Lambda 故障使用 DLQ 和目标（destinations），并为关键函数设置预留并发或预置并发。开发人员的常见陷阱：将敏感的 PII 记录到追踪中（在源头进行编辑脱敏或对这些流程禁用 X-Ray 采样），自定义域名缺少提供商证书（区域性 ACM 与用于边缘的 us-east-1 的区别），以及在没有为公共 API 设置使用计划的情况下依赖默认的账户节流。

实践问题：用例场景

场景：BrightCart 运行一个区域性的电子商务前端，该前端是一个托管在 S3/CloudFront 上的单页应用程序，并通过 API Gateway（区域性 HTTP API）暴露一个结账 API，该 API 调用 VPC 中的 Lambda 函数并将订单写入 DynamoDB。该环境使用 CI/CD 管道将 Lambda 版本部署到生产别名，并在生产阶段上暴露 /checkout 路径。

挑战：在最近一次功能发布后，生产 API 的延迟增加，并且一些结账请求间歇性地返回 502/504 错误；开发人员需要一个安全的回滚机制和即时的诊断方法。

推荐方法：

创建部署回滚，将生产 API 阶段指向前一个部署：使用 aws apigatewayv2 create-deployment --api-id <api> --description "rollback"，然后使用 aws apigatewayv2 update-stage --api-id <api> --stage-name prod --deployment-id <old-deploy-id>。
使用 Lambda 别名安全地转移流量：使用 aws lambda update-alias --function-name CheckoutFn --name prod --function-version <previous-version> 将 prod Lambda 别名更新到前一个版本，并验证其行为。
启用并收集诊断信息：为 API 和 Lambda 启用 X-Ray 追踪（aws apigatewayv2 update-stage --tracing-enabled true 和 aws lambda update-function-configuration --function-name CheckoutFn --tracing-config Mode=Active），并开启详细的访问日志（$context.requestTime, $context.integrationErrorMessage）到 CloudWatch Logs。
分析指标和追踪：在 CloudWatch 中比较 API Gateway 的 IntegrationLatency 与 Latency，检查 X-Ray 分段以识别 VPC ENI 冷启动，并检查 Lambda 节流或 DynamoDB 条件写入；如果 VPC ENI 延迟是根本原因，考虑使用预置并发（aws lambda put-provisioned-concurrency-config）或迁移到具有 VPC 端点优化的 Lambda。

原理：原子化的阶段重新部署和 Lambda 别名切换提供了快速、低风险的回滚，无需更改代码。启用 X-Ray 和结构化访问日志可以让开发人员精确定位问题是由 API Gateway、Lambda 冷启动、VPC 网络还是下游的 DynamoDB 调用引起的，从而指导正确的缓解措施（如预置并发、增加吞吐量或修复配置）。

← 无服务器与 AWS Lambda · 所有领域 · Amazon DynamoDB 与 NoSQL 设计 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →