Modelo mental
API Gateway es un portero, no un servidor. No ejecuta tu código: recibe la petición, decide si pasa, la cuenta, y se la entrega a otro. Todo lo que hace cabe en cuatro verbos —autorizar, limitar, transformar, enrutar— y todo lo que te va a doler viene de olvidar el quinto que no hace: esperar mucho rato.
Dos productos, un nombre
Lo primero que hay que resolver es cuál de los dos vas a usar, porque no son versiones de lo mismo:
| HTTP API | REST API | |
|---|---|---|
| Precio | del orden de 1/3 | referencia |
| Latencia añadida | menor | mayor |
| Caché de respuestas | no | sí |
| Planes de uso y claves | no | sí |
| Mapping templates (VTL) | no | sí |
| Validación de peticiones | no | sí |
| WAF | no | sí |
La regla práctica: empieza por HTTP API. Si tu API está delante de unas Lambdas y usa JWT o IAM para autorizar, HTTP API hace exactamente lo mismo por una fracción del precio. Cambia a REST cuando necesites una de esas casillas de la derecha, no antes — y sabiendo que la estás pagando en cada petición durante toda la vida del sistema.
Los 29 segundos son un límite de diseño, no de configuración
El timeout de integración por defecto son 29 segundos. Se puede subir, pero solo en APIs regionales y privadas; en las edge-optimized es un muro.
Más importante que el número es lo que implica: si tu operación puede tardar
más, no la arregles subiendo el timeout. Una petición HTTP que tarda un minuto
es mala arquitectura aunque el timeout lo permita — el cliente reintenta, el
móvil pierde la conexión, el balanceador de en medio se cansa. Lo que quieres es
responder 202 Accepted con un identificador, hacer el trabajo por detrás y
avisar por WebSocket, por polling o por evento.
El cupo es compartido
Los 10 000 RPS por defecto son de la cuenta y de la región, sumando todas tus APIs REST, HTTP y WebSocket. Y en catorce regiones —Ciudad del Cabo, Milán, Yakarta, Zúrich, Tel Aviv, Calgary, México y siete más— el valor por defecto es 2 500, la cuarta parte.
La consecuencia es la misma que en Lambda con la concurrencia: un endpoint interno mal diseñado, o un job que golpea tu propia API en bucle, puede dejar sin cupo a producción. Por eso el throttling por etapa y por método no es una optimización, es aislamiento.
Cómo te factura
Por petición, y la diferencia entre los dos productos es el número que más mueve la factura:
| Concepto | Precio aproximado |
|---|---|
| HTTP API | ~1,00 USD / millón |
| REST API | ~3,50 USD / millón |
| Caché de respuestas (solo REST) | por hora y por tamaño de caché |
| Transferencia de datos | aparte |
Es decir: REST cuesta del orden de 3,5 veces lo mismo. En una API con 100 millones de peticiones al mes eso son cientos de dólares mensuales de diferencia por unas funciones que quizá no usas.
La caché de REST se paga por hora exista tráfico o no, igual que la concurrencia aprovisionada de Lambda: un coste fijo dentro de un servicio que compraste por ser variable.
Cuándo NO usarlo
- Sirves contenido estático. CloudFront delante de S3 es más rápido y mucho más barato. API Gateway está para APIs.
- La operación pasa de 29 segundos. Devuelve
202y avisa por otro canal. - Solo una función y sin autorización compleja. Una Lambda Function URL te da un endpoint HTTPS sin API Gateway en medio, sin su coste y sin su latencia.
- Tu llamador es tu propio backend dentro de AWS. Si nadie de fuera de tu cuenta va a llamar, invocar la Lambda directamente evita un salto, un coste y un modo de fallo.
- Volumen muy alto y ya tienes VPC. A partir de cierto tráfico un ALB con destino Lambda sale más barato, a cambio de perder claves, planes de uso y autorizadores.
Errores comunes
Elegir REST API por inercia. Es lo que aparece primero en la consola y en la mitad de los tutoriales. Si no vas a usar caché, planes de uso, VTL ni WAF, estás pagando 3,5 veces de más para siempre.
Confundir el límite de payload con el límite real. API Gateway admite 10 MB, pero una Lambda síncrona admite 6 MB. El techo efectivo es el menor de los dos, y el error que ves menciona a Lambda, no a la puerta.
No poner throttling por etapa ni por método. Sin ellos, cualquier consumidor puede llevarse el cupo de la cuenta entera.
Autorizadores Lambda sin caché. Cada petición se convierte en dos invocaciones. Con el TTL del autorizador bien puesto, la segunda desaparece para la mayoría del tráfico. Y recuerda que su resultado no puede pasar de 8 KB.
Olvidar desplegar la etapa. En REST API los cambios no existen hasta que
haces un CreateDeployment. Y ese CreateDeployment está limitado a una
petición cada 5 segundos por cuenta, cosa que descubren los pipelines que
despliegan muchas APIs a la vez.
Meter lógica en mapping templates. VTL solo existe en REST API, no se puede probar en local con comodidad y no aparece en ninguna traza. Cada línea de VTL es lógica de negocio escondida donde nadie la busca.
Suponer que tu región va a 10 000 RPS. En catorce regiones el valor por defecto es 2 500, y el burst 1 250 — y ese burst no se puede pedir: lo fija AWS a partir del RPS de tu cuenta.
Fuentes
Todas las cuotas —payload, timeout de integración, throttle y burst por región,
recursos y rutas, etapas, cabeceras, autorizadores, caché, WebSocket y
CreateDeployment—, y qué se puede ampliar y qué no:
Amazon API Gateway endpoints and quotas
y Amazon API Gateway quotas.
Límite de payload síncrono de Lambda:
Lambda quotas.
Los importes proceden de la página de precios de AWS, que se renderiza
dinámicamente y no pudo citarse literalmente: trátalos como orden de magnitud.