Amazon DVA-C02: Amazon API Gateway e integración de aplicaciones — Guía de estudio
Forma parte de la AWS Developer Associate DVA-C02 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.
Diseño de API con API Gateway (REST, HTTP, WebSocket) e integraciones
El diseño comienza eligiendo el tipo de API adecuado: las API REST (API Gateway REST) ofrecen características detalladas a nivel de etapa, como caché por etapa y plantillas de mapeo sofisticadas; las API HTTP (API Gateway v2) proporcionan menor latencia y menor costo para patrones de proxy comunes y autorizadores JWT/OIDC nativos; las API WebSocket proporcionan canales cliente-servidor persistentes con claves de ruta ($connect, $disconnect, $default) y requieren la API de administración de API Gateway (PostToConnection) para enviar mensajes. Diseñe las integraciones prefiriendo el proxy AWS_PROXY/Lambda para solicitudes/respuestas simples (use aws apigateway put-integration --type AWS_PROXY o para v2 use CreateIntegration en ApiGatewayV2Client), y elija HTTP o VPC Link para backends HTTP privados. Para backends de alto rendimiento, use NLB + VPC Link. Las integraciones simuladas (put-integration --type MOCK) y las plantillas de respuesta de integración permiten a los equipos de frontend comenzar sin que el backend esté listo. Cuando use CloudFront como fachada para las API, utilice los endpoints de API regionales como orígenes y establezca la Origin Protocol Policy en HTTPS-only; las API REST optimizadas para la periferia (edge-optimized) ya se encuentran detrás de CloudFront. Los errores comunes incluyen el desajuste de las versiones de formato de payload entre la API y Lambda (v1.0 vs 2.0), olvidar otorgar permiso a apigateway.amazonaws.com para invocar Lambda (agregue el permiso con aws lambda add-permission --principal apigateway.amazonaws.com), y configuraciones incorrectas de CORS que bloquean los navegadores.
Patrones de seguridad y autorización (Cognito, IAM, autorizadores personalizados)
Los patrones de seguridad deben coincidir con los tipos de cliente y los modelos de acceso: use Amazon Cognito User Pools o un proveedor OIDC externo y conéctelos como autorizadores JWT para las API HTTP (CreateAuthorizer en apigatewayv2 con identitySource establecido en $request.header.Authorization), o use los autorizadores de Cognito para API REST para el acceso de usuarios basado en sesión. Para API de servicio a servicio o de administración, prefiera la autorización de IAM (SigV4) y políticas de recursos de IAM con un alcance estricto en las etapas y los métodos. Los autorizadores de Lambda (personalizados) ofrecen la máxima flexibilidad para implementar reglas de autenticación a medida, pero recuerde que añaden latencia y modos de fallo; almacene en caché las respuestas del autorizador con un TTL para reducir los arranques en frío y evite lanzar errores que devuelvan un 500 a los clientes. Protéjase contra el abuso con planes de uso y claves de API (aws apigateway create-usage-plan y create-api-key) combinados con cuotas de limitación de velocidad (throttling). Asegure los permisos de IAM correctos: otorgue a API Gateway permiso para invocar Lambda (aws lambda add-permission) y restrinja los roles de ejecución de Lambda al mínimo privilegio. Los descuidos comunes de los desarrolladores incluyen olvidar habilitar la extracción de tokens para los autorizadores JWT, tiempos de espera del autorizador que afectan la latencia general de la API, y el reenvío de encabezados/cookies por parte de CloudFront, lo que puede omitir inadvertidamente los cachés o filtrar datos de usuario.
Gestión de etapas, versionado, caché y despliegues canary
Trate las etapas como superficies de ejecución independientes: los despliegues son instantáneas (aws apigateway create-deployment o apigatewayv2 create-deployment), y las etapas se asignan a esas instantáneas. Use variables de etapa o, preferiblemente, alias de Lambda para enrutar el tráfico entre versiones; cambie los alias de forma atómica (UpdateAlias) o use la configuración canary de la etapa de API Gateway para un despliegue gradual. Para las API REST, habilite el almacenamiento en caché a nivel de etapa (aws apigateway update-stage con patch-operations para establecer cacheClusterEnabled y cacheClusterSize) y controle los parámetros de TTL y de clave de caché en la configuración del método; las API HTTP no tienen actualmente caché incorporado, por lo que debe usar CloudFront o cachés a nivel de aplicación. Invalide la caché al desplegar o cuando los datos subyacentes cambien; depender únicamente del TTL puede devolver datos obsoletos. Patrones de versionado: use el versionado semántico de API en la ruta (/v1/...) o confíe en los despliegues por etapas para flujos azul/verde. Los errores comunes incluyen asumir que las variables de etapa son seguras (son visibles para los desarrolladores con acceso a la consola), configurar incorrectamente las claves de caché (olvidando incluir el encabezado de autorización o los parámetros de consulta), y no coordinar el despliegue de los cambios de esquema con la compatibilidad del cliente.
Rendimiento, Observabilidad y Diagnósticos
Instrumentar las API de extremo a extremo: habilitar los logs de ejecución y los logs de acceso en API Gateway y producir JSON estructurado (variables $context) en CloudWatch Logs; habilitar X-Ray en API Gateway y Lambda (establecer tracingEnabled en el despliegue/etapa o usar el SDK: PutFunctionConcurrency/UpdateFunctionConfiguration con TracingConfig) para correlacionar trazas. Monitorear las métricas de API Gateway (Latency, IntegrationLatency, 4XX/5XX, CacheHitCount) y las métricas de Lambda (Duration, Throttles, ConcurrentExecutions) en CloudWatch; usar matemática de métricas para identificar dónde se acumula la latencia. Para WebSocket, rastrear el recuento de conexiones y los picos de errores 5XX de API Gateway. Los pasos para la solución de problemas incluyen comparar IntegrationLatency con Latency para ver si el backend o el gateway añaden sobrecarga, profundizar en los segmentos de X-Ray para detectar arranques en frío o ENI de VPC, y revisar los CloudWatch Logs en busca de errores en las plantillas de mapeo. Usar DLQs y destinos para fallos asíncronos de Lambda, y establecer concurrencia reservada o concurrencia aprovisionada para funciones críticas. Errores comunes de los desarrolladores: registrar PII sensible en las trazas (redactar en el origen o deshabilitar el muestreo de X-Ray para esos flujos), omitir certificados de proveedor para dominios personalizados (ACM regional vs. us-east-1 para edge), y depender de la limitación (throttling) predeterminada de la cuenta sin planes de uso para API públicas.
Problema Práctico: Escenario de Caso de Uso
Escenario: BrightCart opera un frontend de comercio electrónico regional en una aplicación de página única (SPA) alojada en S3/CloudFront y expone una API de pago (checkout) a través de API Gateway (API HTTP regional) que invoca funciones Lambda en una VPC y escribe los pedidos en DynamoDB. El entorno utiliza un pipeline de CI/CD que despliega versiones de Lambda a alias de producción y expone /checkout en una etapa (stage) de producción.
Desafío: Después del despliegue de una nueva funcionalidad, la latencia de la API de producción aumentó y algunas solicitudes de pago devuelven errores 502/504 de forma intermitente; los desarrolladores necesitan un mecanismo de reversión (rollback) seguro y diagnósticos inmediatos.
Enfoque Recomendado:
- Crear una reversión (rollback) del despliegue apuntando la etapa (stage) de la API de producción al despliegue anterior: usar
aws apigatewayv2 create-deployment --api-id <api> --description "rollback"y luegoaws apigatewayv2 update-stage --api-id <api> --stage-name prod --deployment-id <old-deploy-id>. - Desviar el tráfico de forma segura usando alias de Lambda: actualizar el alias
prodde Lambda a la versión anterior conaws lambda update-alias --function-name CheckoutFn --name prod --function-version <previous-version>y verificar el comportamiento. - Habilitar y recopilar diagnósticos: habilitar el rastreo de X-Ray para la API y Lambda (
aws apigatewayv2 update-stage --tracing-enabled trueyaws lambda update-function-configuration --function-name CheckoutFn --tracing-config Mode=Active) y activar los logs de acceso detallados ($context.requestTime,$context.integrationErrorMessage) en CloudWatch Logs. - Analizar métricas y trazas: comparar
IntegrationLatencyvs.Latencyde API Gateway en CloudWatch, examinar los segmentos de X-Ray para identificar arranques en frío de las ENI de la VPC, y verificar las limitaciones (throttles) de Lambda o las escrituras condicionales de DynamoDB; si la latencia de las ENI de la VPC es la causa raíz, considerar la concurrencia aprovisionada (aws lambda put-provisioned-concurrency-config) o migrar a Lambda con optimizaciones de endpoints de VPC.
Justificación: El redespliegue atómico de la etapa (stage) y los cambios de alias de Lambda proporcionan una reversión (rollback) rápida y de bajo riesgo sin cambios en el código. Habilitar X-Ray y los logs de acceso estructurados permite a los desarrolladores identificar con precisión si API Gateway, los arranques en frío de Lambda, la red de la VPC o las llamadas posteriores a DynamoDB están causando los errores, guiando hacia la mitigación correcta (concurrencia aprovisionada, aumento del throughput o correcciones de configuración).
← Serverless y AWS Lambda · Todos los dominios · Amazon DynamoDB y diseño NoSQL →
Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Aprueba tu examen →