Servicio managed de AWS para crear, publicar y gestionar APIs REST, HTTP y WebSocket que actúan como puerta de entrada a funciones Lambda y otros servicios backend.
AWS API Gateway es un servicio completamente administrado que facilita la creación, publicación y gestión de APIs a cualquier escala. Actúa como la puerta de entrada entre aplicaciones cliente y servicios backend, manejando automáticamente tareas críticas como autenticación, autorización, throttling, caching y monitoreo.
El servicio elimina la complejidad operacional de construir y mantener tu propia infraestructura de API. Con integración nativa a AWS Lambda, permite crear arquitecturas serverless completas donde el código se ejecuta solo cuando es necesario, sin gestionar servidores.
API Gateway soporta tres tipos de API: REST APIs para servicios web tradicionales con features completas, HTTP APIs para casos de uso simples con menor latencia y costo, y WebSocket APIs para comunicación bidireccional en tiempo real.
| Característica | HTTP API (v2) | REST API (v1) |
|---|---|---|
| Precio | $1.00 por millón de requests | $3.50 por millón de requests |
| Latencia | ~71ms promedio | ~90ms promedio |
| Autorización | JWT, Lambda, IAM | JWT, Lambda, IAM, Cognito, API Keys |
| Transformación de datos | Limitada | Completa con VTL |
| Validación de requests | Básica | Completa con JSON Schema |
| Caching | No | Sí |
| Canary deployments | No | Sí |
| Usage plans | No | Sí |
| SDK generation | No | Sí |
| Casos de uso | APIs simples, proxy a Lambda | APIs complejas, transformaciones |
# API Gateway HTTP API con Lambda
resource "aws_apigatewayv2_api" "main" {
name = "user-api"
protocol_type = "HTTP"
cors_configuration {
allow_credentials = false
allow_headers = ["content-type", "x-amz-date", "authorization"]
allow_methods = ["GET", "POST", "PUT", "DELETE"]
allow_origins = ["https://app.example.com"]
max_age = 86400
}
}
resource "aws_apigatewayv2_integration" "lambda" {
api_id = aws_apigatewayv2_api.main.id
integration_type = "AWS_PROXY"
connection_type = "INTERNET"
description = "Lambda proxy integration"
integration_method = "POST"
integration_uri = aws_lambda_function.user_handler.invoke_arn
passthrough_behavior = "WHEN_NO_MATCH"
}
resource "aws_apigatewayv2_route" "users" {
api_id = aws_apigatewayv2_api.main.id
route_key = "GET /users/{id}"
target = "integrations/${aws_apigatewayv2_integration.lambda.id}"
authorization_type = "JWT"
authorizer_id = aws_apigatewayv2_authorizer.jwt.id
}
resource "aws_apigatewayv2_stage" "prod" {
api_id = aws_apigatewayv2_api.main.id
name = "prod"
auto_deploy = true
default_route_settings {
throttling_rate_limit = 1000
throttling_burst_limit = 2000
}
}API Gateway soporta múltiples patrones de integración según las necesidades arquitectónicas:
Lambda Proxy Integration: El patrón más común para arquitecturas serverless. API Gateway envía todo el request HTTP como evento JSON a Lambda, que debe devolver una respuesta HTTP estructurada. Ideal para lógica de negocio compleja.
VPC Link a Application Load Balancer: Para integrar con servicios corriendo en AWS ECS o EC2 dentro de una VPC privada. API Gateway se conecta a través de un VPC Link a un ALB interno, permitiendo arquitecturas híbridas.
HTTP Proxy: Reenvía requests directamente a endpoints HTTP externos con transformaciones mínimas. Útil para agregar autenticación o throttling a APIs existentes.
Mock Integrations: Respuestas estáticas configuradas directamente en API Gateway, útiles para testing, documentación interactiva o endpoints de health check.
| Método | Casos de uso | Complejidad | Costo |
|---|---|---|---|
| IAM | APIs internas, servicios AWS | Media | Incluido |
| Cognito User Pools | Aplicaciones web/móvil con usuarios | Baja | $0.0055/MAU |
| Lambda Authorizer | Lógica de autorización custom | Alta | Costo de Lambda |
| JWT | Tokens de terceros (Auth0, Okta) | Media | Incluido |
Decisión: Usa IAM para APIs internas, Cognito para aplicaciones con usuarios finales, JWT para integración con proveedores externos, y Lambda Authorizer solo cuando necesites lógica de autorización compleja.
API Gateway proporciona observabilidad completa a través de múltiples servicios AWS:
CloudWatch Metrics: Métricas automáticas como latencia, error rate, y request count por stage y método. Incluye métricas de throttling y autorización fallida para debugging.
X-Ray Tracing: Tracing distribuido que muestra el flujo completo desde API Gateway hasta Lambda y otros servicios AWS. Esencial para identificar cuellos de botella en arquitecturas complejas.
Access Logging: Logs detallados de cada request con información como IP del cliente, user agent, latencia, y response code. Se pueden enviar a CloudWatch Logs o S3 para análisis posterior.
resource "aws_apigatewayv2_domain_name" "api" {
domain_name = "api.example.com"
domain_name_configuration {
certificate_arn = aws_acm_certificate.api.arn
endpoint_type = "REGIONAL"
security_policy = "TLS_1_2"
}
}
resource "aws_apigatewayv2_api_mapping" "main" {
api_id = aws_apigatewayv2_api.main.id
domain_name = aws_apigatewayv2_domain_name.api.id
stage = aws_apigatewayv2_stage.prod.name
}API Gateway implementa throttling a múltiples niveles: account-level (10,000 RPS por región por defecto), stage-level, y method-level. Los límites se pueden configurar independientemente, y el servicio devuelve HTTP 429 cuando se exceden.
Para aplicaciones con tráfico variable, considera configurar burst limits que permiten picos temporales. Usage Plans permiten crear diferentes niveles de servicio con quotas diarias/mensuales para diferentes tipos de clientes.
API Gateway elimina meses de desarrollo de infraestructura que típicamente requiere construir una capa de entrada HTTP robusta. Con features como autorización integrada, throttling automático, y observabilidad nativa, permite que equipos de ingeniería se enfoquen en lógica de negocio en lugar de plumbing.
La diferencia de precio entre HTTP API ($1/millón) y REST API ($3.50/millón) puede ser significativa a escala, pero REST API ofrece features como caching y transformaciones que pueden reducir costos downstream. La decisión correcta depende del volumen de tráfico y complejidad de transformaciones requeridas.
Servicio de cómputo serverless de AWS que ejecuta código en respuesta a eventos sin necesidad de aprovisionar ni administrar servidores, escalando automáticamente desde cero hasta miles de ejecuciones concurrentes.
Modelo de computación en la nube donde el proveedor gestiona la infraestructura automáticamente, permitiendo ejecutar código sin aprovisionar ni administrar servidores, pagando solo por el uso real.
Principios y prácticas para diseñar interfaces de programación claras, consistentes y evolucionables que faciliten la integración entre sistemas.
Diseño de arquitectura para escalar un segundo cerebro personal a un sistema de producción con AWS serverless — desde el prototipo actual hasta casos de uso especializados en legal, investigación y comunidad.
Colección de 13 módulos Terraform publicados en el Terraform Registry para desplegar arquitecturas serverless en AWS, con 12 ejemplos que cubren desde ECS básico hasta CRUD full-stack con DynamoDB y AgentCore con MCP.
Backend serverless de producción para un grafo de conocimiento personal — DynamoDB, Lambda, Bedrock, MCP, Step Functions. La implementación de la arquitectura descrita en el ensayo «Del prototipo a producción».
GitHub App serverless que auto-aprueba pull requests después de que CI pasa, con revisión de código opcional vía Amazon Bedrock. Cinco repositorios: app TypeScript/Probot, módulo Terraform AWS (Lambda + API Gateway + Secrets Manager + SQS DLQ), módulo Terraform GitHub (webhooks), infra de despliegue y repo de pruebas.
Patrón que proporciona un punto de entrada único para múltiples microservicios, manejando routing, autenticación, rate limiting y agregación de respuestas.