La promesa que se desinfla “Pagás solo por lo que usás”.
Esa frase vendió millones de arquitecturas serverless. Y en ciertos escenarios —procesamiento esporádico, tareas batch, picos impredecibles— es cierta.
El problema no es ese, el problema es que cuando tu API pasa de 10 mil a 10 millones de requests por mes, serverless deja de escalar económicamente de forma eficiente frente a alternativas que amortizan mejor el costo.
Y peor: cuando te das cuenta, ya es tarde. Tenés 20, 30, 50 funciones acopladas, observabilidad distribuida, y migrar ya no es trivial.
En este artículo no vamos a decir que serverless es malo. Vamos a mostrar cuándo deja de ser económico, por qué pasa, y en qué momento conviene repensar la arquitectura.
El error de comparar solo “compute”
La discusión típica se reduce a: “¿Lambda o EC2?”
Esa pregunta ya es incompleta, una arquitectura serverless real incluye múltiples componentes con costo independiente:
| Componente | Modelo de cobro | Lo que no se ve |
|---|---|---|
| Lambda | Por invocación + GB-segundo | Cold starts, retries, provisioned concurrency |
| API Gateway | Por request ($1–3.50 por millón) | Logging, caching, data transfer |
| Data Transfer | Por GB saliente ($0.09/GB) | Cross-AZ, NAT, inter-región |
| Observabilidad | CloudWatch Logs ($0.50/GB) | Logs verbose, métricas custom |
| Base de datos | DynamoDB/RDS | Requests, conexiones, capacidad |
Cuando sumás todo, el compute deja de ser el protagonista.
En muchos casos reales, Lambda puede representar solo una fracción del costo total, mientras que logging, transferencia de datos y API Gateway dominan la factura.
Los números: una API de 100.000 requests/día
Tomemos un escenario concreto y simple.
Escenario: API REST con 100.000 requests/día (3M/mes), respuesta promedio de 5KB, función Lambda de 512MB que corre 200ms por request.
Opción A: Serverless “puro” (Lambda + API Gateway HTTP)
| Concepto | Cálculo | Costo mensual |
|---|---|---|
| API Gateway HTTP | 3M × $1.00/M | $3.00 |
| Lambda (requests) | 3M × $0.20/M | $0.60 |
| Lambda (compute) | 3M × 0.2s × 0.5GB | $5.00 |
| Data Transfer Out | 15GB (dentro del free tier) | $0.00 |
| CloudWatch Logs | ~5GB | $2.50 |
| Total Serverless | ~$11.10/mes |
A esta escala, serverless es excelente. No hay discusión.
Opción B: 12 meses después — 10x crecimiento
La API crece a 1M requests/día (30M/mes). Aparecen múltiples endpoints, servicios que se llaman entre sí y despliegue multi-AZ.
| Concepto | Cálculo | Costo mensual |
|---|---|---|
| API Gateway HTTP | 30M × $1.00/M | $30.00 |
| Lambda (requests) | $6.00 | |
| Lambda (compute) | $50.00 | |
| Data Transfer Out | ~50GB billable | $4.50 |
| Cross-AZ | estimado | $10.00 |
| CloudWatch Logs | ~50GB | $25.00 |
| Total Serverless | ~$125.50/mes |
Todavía no es alarmante. Pero empieza a aparecer algo importante:
los costos “invisibles” empiezan a pesar más que el compute.
Opción C: el punto de inflexión — 10M requests/día
Ahora escalamos a 10M requests/día (300M/mes).
| Concepto | Cálculo | Costo mensual |
|---|---|---|
| API Gateway HTTP | $300.00 | |
| Lambda (requests) | $60.00 | |
| Lambda (compute) | $500.00 | |
| Data Transfer Out | 1.5TB | $135.00 |
| Cross-AZ | estimado | $100.00 |
| CloudWatch Logs | ~500GB (≈1.5–2KB/request) | $250.00 |
| Total Serverless | ~$1,345/mes |
Comparación con EC2
Asumiendo una API liviana y eficiente (por ejemplo, Go o Node sin lógica pesada), esta carga puede manejarse con 3–4 instancias.
| Concepto | Cálculo | Costo mensual |
|---|---|---|
| 4× EC2 m6i.large (Reserved) | $180.00 | |
| ALB | $25.00 | |
| Data Transfer Out | $135.00 | |
| CloudWatch básico | $15.00 | |
| Total EC2 | ~$355/mes |
Resultado: serverless puede costar ~3.8x más para una carga sostenida.
No porque escale mal técnicamente, sino porque no amortiza.
Los costos ocultos que nadie calcula
1. API Gateway: el elefante en la habitación
Si usás REST API (no HTTP API), el costo sube a $3.50 por millón de requests.
Muchos equipos pagan esa diferencia sin usar las features adicionales, y no termina ahí:
el logging de API Gateway puede costar más que el gateway en sí.
2. Data Transfer: la línea olvidada
AWS cobra ~$0.09/GB hacia internet.
Pero el costo más insidioso es el cross-AZ, cada llamada entre servicios en distintas zonas genera tráfico pago. En arquitecturas con microservicios, esto escala muy rápido.
En un caso real reportado, el 25% de la factura total era solo tráfico cross-AZ.
3. Observabilidad: logs que escalan con cada request
CloudWatch Logs cobra $0.50/GB, en serverless, cada ejecución genera logs.
300M requests/mes con ~2KB por request ⇒ 600GB ⇒ **$300/mes solo en logs**.
En EC2, logueás por instancia, en serverless, logueás por ejecución.
No es lo mismo.
4. Provisioned Concurrency: cuando serverless deja de serlo
Para evitar cold starts, muchos equipos activan Provisioned Concurrency, eso significa pagar por capacidad provisionada, no por uso.
En ese punto, estás pagando algo muy parecido a EC2… pero con más capas arriba.
El análisis que no hace nadie: TCO a 24 meses
La evidencia (incluyendo estudios académicos y casos reales) es consistente:
- Serverless gana en cargas impredecibles o esporádicas
- EC2 / contenedores ganan en cargas altas y sostenidas
A alta escala (por ejemplo, >1000 req/s), servicios como Lambda y API Gateway pueden ser significativamente más caros que correr contenedores o instancias dedicadas.
La pregunta correcta no es:
“¿Serverless o EC2?”
La pregunta es:
“¿En qué punto se cruzan los costos?”
La curva de crossover: ¿cuándo migrar?
Regla práctica basada en múltiples casos reales:
| Escenario | Serverless gana | Serverless pierde |
|---|---|---|
| Requests/día | < 500K | > 2M |
| Tráfico | Esporádico | Sostenido |
| Duración | < 1s | > 5s |
| Equipo | Sin DevOps | Con DevOps/SRE |
| Latencia | No crítica | <100ms consistente |
Otro indicador clave:
Si una función Lambda está utilizada gran parte del tiempo (por ejemplo, >60–70%), ya estás en zona donde conviene evaluar alternativas.
El framework de decisión
Antes de elegir serverless por default:
1. ¿Tu tráfico es predecible y creciente? Si sí, vas a pagar un costo marginal constante que no amortiza.
2. ¿Cuántos servicios se llaman entre sí? Cada hop suma costo (invocación + posible transferencia).
3. ¿Necesitás latencia consistente (<100ms)? Probablemente termines pagando Provisioned Concurrency.
4. ¿Tenés capacidad operativa? Si no hay equipo de infraestructura, serverless puede justificar su costo.
Conclusión: serverless es una herramienta, no una religión
Serverless no es “más caro” ni “más barato”, es:
- más barato para cargas esporádicas
- más caro para cargas sostenidas
El problema es otro:
serverless es excelente para empezar, pero peligroso para quedarse sin revisar costos.
La regla de oro:
- Empezá con serverless para validar.
- Medí a los 6–12 meses.
- Y migrá cuando deje de tener sentido económico.
El costo de migrar temprano es bajo, el costo de quedarse 18 meses después del punto de inflexión es alto — en dinero, complejidad y deuda técnica.
Fuentes y referencias
- Dash0. "AWS Lambda Cost Factors, Cost Comparisons and Optimization." 2026.
- Gatyas, Milan. "Compare The Cost of AWS Lambda, Fargate, and EC2." 2022.
- FourTheorem. "Why AWS Lambda Pricing Has to Change." 2021.
- Springer. "Understanding Cost Dynamics of Serverless Computing." 2024.
- Zuplo. "API Gateway Pricing Compared." 2026.
- Proud2beCloud. "AWS Data Transfer Costs." 2026.
- Roth, Deby. "Hidden cross-AZ costs." 2023.