Patrones de diseño de Amazon API Gateway - Criterios de selección entre REST API y HTTP API

Clarificamos los criterios de selección entre HTTP API y REST API, y presentamos patrones de autenticación con Cognito y Lambda Authorizer, así como métodos prácticos de diseño de throttling.

Unos 9 min de lecturaÚltima actualización: 2026-10-29

Criterios de selección entre REST API y HTTP API

API Gateway ofrece dos tipos: REST API y HTTP API. HTTP API es el tipo publicado en versión preliminar en diciembre de 2019 y con disponibilidad general desde marzo de 2020, que cubre las funciones principales de REST API con un precio hasta un 71% más económico y menor latencia. Si el uso principal es proxy hacia funciones Lambda o endpoints HTTP, se debe elegir HTTP API. Los casos en que se debe elegir REST API son: publicación de API para terceros con claves API y planes de uso, transformación de solicitudes/respuestas (plantillas de mapeo), integración con WAF, endpoints optimizados para edge, y cuando se necesita la función de validación de solicitudes. Para nuevos proyectos, se recomienda el enfoque de usar HTTP API como predeterminado y considerar REST API solo cuando se necesiten funciones que HTTP API no tiene.

Patrones de autenticación y autorización

API Gateway soporta múltiples métodos de autenticación, pero los tipos de autorizador disponibles difieren entre REST API y HTTP API (a fecha de agosto de 2026). El autorizador de Cognito User Pool (COGNITO_USER_POOLS) es un método exclusivo de REST API en el que API Gateway valida automáticamente los tokens JWT emitidos por Cognito. Como no es necesario implementar la lógica de validación de tokens por cuenta propia, resulta fácil de introducir en configuraciones que usan Cognito. HTTP API no dispone de este autorizador; en su lugar se utiliza el autorizador JWT. El autorizador JWT es un método que valida los JWT siguiendo el marco de OpenID Connect (OIDC) y OAuth 2.0, especificando el emisor (issuer) y la audiencia (audience). Dado que se puede indicar un Cognito User Pool como issuer, también es posible autenticar con Cognito en HTTP API, pero tenga en cuenta que el tipo de autorizador a configurar es distinto. El autorizador JWT verifica la firma con las claves públicas obtenidas del jwks_uri del issuer (solo se admiten algoritmos de la familia RSA) y evalúa claims como iss, aud y exp. Si se configuran ámbitos (scopes) de autorización por ruta, también es posible controlar el acceso según los scopes incluidos en el token. El Lambda Authorizer es un método que implementa lógica de autenticación personalizada en una función Lambda. Se utiliza cuando se necesita lógica de autorización flexible como formatos de token propios, integración con IdP externos o control basado en direcciones IP. Los resultados del Lambda Authorizer se pueden cachear, y configurando un TTL se reduce la ejecución duplicada de solicitudes de autenticación. La autenticación IAM es un método que autentica solicitudes con firma SigV4 de AWS, adecuado para comunicación interna entre servicios de AWS.

Throttling y planes de uso

El throttling de API Gateway se implementa con el algoritmo de token bucket. El límite predeterminado a nivel de cuenta es de 10,000 solicitudes/segundo por región, con un burst de 5,000 solicitudes. Se pueden configurar límites más granulares a nivel de stage y método, previniendo que un endpoint específico sobrecargue el backend. Los planes de uso son una función exclusiva de REST API que permite configurar límites de solicitudes diarios/mensuales y tasas de throttling por clave API. Al publicar API para socios externos, se pueden aplicar diferentes límites de tasa por socio. Se recomienda que los clientes que reciban respuestas 429 Too Many Requests implementen reintentos con backoff exponencial.

Precios de API Gateway

HTTP API cuesta aproximadamente 1.00 USD por millón de solicitudes, aproximadamente un 71% más barato que los 3.50 USD de REST API (a fecha de agosto de 2026). WebSocket API cuesta aproximadamente 1.00 USD por millón de mensajes más un cargo por tiempo de conexión (aproximadamente 0.25 USD por millón de minutos). Habilitar la caché de REST API genera un cargo por hora según el tamaño de la memoria caché (aproximadamente 0.02 USD/hora para 0.5 GB). Configurar adecuadamente el TTL de caché del Lambda Authorizer para reducir el número de invocaciones Lambda de autenticación también es eficaz para la optimización de costos. La antigua capa gratuita de 12 meses de las cuentas creadas antes del 15 de julio de 2025 incluía 1 millón de solicitudes al mes para HTTP API y REST API respectivamente. A las cuentas nuevas creadas a partir de esa fecha les corresponde el plan gratuito basado en créditos de hasta 200 USD (consulte el sitio oficial de AWS para conocer las condiciones más recientes).

Tipos de integración y conexión con el backend

API Gateway puede encaminar las solicitudes hacia diversos backends. La integración de proxy, que pasa la solicitud tal cual a una función Lambda, es sencilla y la más común. También existen integraciones que reenvían a servicios HTTP existentes y mecanismos para conectarse a servicios privados dentro de una VPC. Si utiliza integraciones que llaman directamente a algunos servicios de AWS sin pasar por un backend, puede prescindir de Lambda en los procesos sencillos y contener el costo y la latencia. Al diseñar qué colocar detrás de la API que publica y cómo conectarlo, puede mantener la configuración sencilla y ofrecer a la vez las funciones necesarias. Elija el tipo de integración adecuado según los requisitos.

Procesamiento de solicitudes y respuestas

API Gateway dispone de funciones para procesar las solicitudes y las respuestas. Al validar si el formato de la entrada es correcto y rechazar las solicitudes no válidas antes de que lleguen al backend, puede evitar procesamiento y carga innecesarios. También puede transformar la estructura de las solicitudes y las respuestas para darles una forma fácil de manejar tanto para el cliente como para el backend. Así, puede ajustar la forma de la API que expone al exterior sin cambiar las especificaciones del backend. Al realizar la validación y la transformación en la entrada, puede proteger la implementación del backend y, al mismo tiempo, ofrecer a los usuarios una API coherente y fácil de usar.

Comunicación en tiempo real con WebSocket

Una API normal consiste básicamente en un intercambio unidireccional que responde a las solicitudes del cliente. En cambio, si desea enviar datos (push) del servidor al cliente en cualquier momento y necesita comunicación bidireccional en tiempo real, puede crear una API compatible con WebSocket. Resulta adecuada para usos como el chat, las notificaciones y la visualización de actualizaciones en directo. Puede definir el procesamiento de cada evento, como el establecimiento o el cierre de la conexión y la recepción de mensajes, y enviar mensajes de forma activa desde el servidor a los clientes conectados. Al elegir según el uso entre el tipo de solicitud y respuesta y el tipo en tiempo real, puede atender los requisitos de comunicación de muy diversas aplicaciones.

Monitoreo, caché y operación

En la operación de una API, supervise el número de solicitudes, la tasa de errores y la latencia para poder detectar anomalías. Si registra los logs de acceso, puede rastrear qué llamadas hubo y aprovecharlo para investigar problemas. En los endpoints que devuelven con frecuencia el mismo resultado, puede usar la función de caché de respuestas para reducir la carga del backend y la latencia. Con los stages puede separar desarrollo y producción, y también realizar lanzamientos canary que prueban una nueva versión con una parte del tráfico. Al combinar el monitoreo, la caché y los lanzamientos graduales, puede ofrecer una API que funcione de forma estable.

Resumen

API Gateway es un servicio que gestiona de forma centralizada la autenticación, el throttling y el monitoreo en la capa de API como punto de entrada de la arquitectura serverless. Teniendo el criterio de elegir HTTP API como opción predeterminada y seleccionar REST API cuando se necesiten funciones empresariales, se pueden optimizar los costos y la latencia.

Referencias (recursos oficiales de AWS)

Las fuentes primarias de esta página son el sitio web y la documentación oficiales de AWS. Consulta las páginas oficiales siguientes para conocer las especificaciones y los precios más recientes.

Si esta página y la documentación oficial difieren, prevalece la documentación oficial.

Patrones de integración de Amazon EFS con Lambda / ECS - Uso de sistemas de archivos compartidos en serverlessSe monta EFS en funciones Lambda y tareas de ECS para aprovechar un sistema de archivos compartido. Se presentan el diseño de los puntos de acceso y la optimización del rendimiento.Por qué el límite de 15 minutos de Lambda es de 15 minutos - La racionalidad oculta en las restricciones de diseño serverlessSe explican los valores actuales de los diversos límites serverless, como el tiempo máximo de ejecución de 15 minutos de Lambda, el límite de memoria de 10 GB y el payload de 6 MB, y cómo afectan al diseño de la arquitectura. El análisis parte de la perspectiva de la operación multi-tenant y del ciclo de vida del entorno de ejecución.La verdad sobre el cold start de Lambda y cómo elegir entre 3 estrategias de optimizaciónExplicamos el mecanismo por el cual ocurre el cold start de Lambda desde el ciclo de vida de Firecracker MicroVM, y comparamos técnicas de optimización en 3 ejes: SnapStart, Provisioned Concurrency y diseño de funciones, en términos de costo y restricciones.Desarrollo serverless con AWS Lambda - Diseño de funciones y uso de event sourcesExplicamos el diseño de funciones de Lambda, el mapeo de event sources, las contramedidas para cold start y el uso de Powertools.Detrás de las 1.000 ejecuciones simultáneas de Lambda - Cómo funcionan el warm pool de Firecracker y el worker managerSe explica el mecanismo con el que Lambda gestiona las micro VM dentro del límite predeterminado de 1.000 ejecuciones simultáneas. También se presentan la estrategia de reutilización mediante el warm pool, las decisiones de ubicación del worker manager y las optimizaciones internas que reducen la tasa de cold start.Construcción de APIs serverless - Infraestructura API escalable con Amazon API GatewayExplicamos cómo construir APIs serverless utilizando Amazon API Gateway y Lambda.Diseño de máquinas de estado - Orquestación de flujos de trabajo con Step FunctionsSe explican los métodos de diseño de máquinas de estado que aprovechan AWS Step Functions y se presentan los flujos de trabajo visuales, la gestión de errores y la orquestación de flujos de trabajo mediante la integración con Lambda.Orquestación de flujos de trabajo diseñada con AWS Step Functions - Cómo elegir entre Standard y ExpressSe aclaran los criterios para elegir entre los flujos de trabajo Standard y los flujos de trabajo Express, y se presentan la gestión de errores declarativa con Retry/Catch y el procesamiento en paralelo a gran escala con el mapa distribuido.