Costos ocultos serverless: donde va tu plata
En pocas palabras: La primera factura grande de serverless casi nunca explota por el compute de la función, sino por lo que la rodea: NAT Gateway (~USD 0,045/h fijos), logs de CloudWatch por GB ingerido, salida de datos a ~USD 0,09/GB y servicios managed metered.
Tu factura de serverless casi nunca explota por el compute. En agosto de 2026, el patrón se repite: pagás centavos de Lambda y después aparecen cargos por NAT Gateway, transferencia de datos, ingesta de logs y servicios managed que llamás sin darte cuenta. Los costos ocultos serverless viven en todo lo que rodea a la función, no en los milisegundos que corre.
En 30 segundos
- El compute de Lambda (GB-segundos) suele ser la parte más chica de la factura; el resto son servicios metered alrededor de la función.
- El NAT Gateway cobra por hora (~USD 0,045/h) más por GB procesado (~USD 0,045/GB): una función en VPC que sale a internet paga fijo aunque no la uses.
- CloudWatch Logs cobra por GB ingerido, no por almacenado: 10 GB de logs al mes son ~USD 5 que no figuran en el compute.
- La salida de datos a internet cuesta ~USD 0,09/GB y el tráfico cross-AZ ~USD 0,01/GB: dos líneas que crecen calladas.
- DynamoDB on-demand puede costar varias veces más que provisioned para el mismo volumen si no dimensionás bien.
El costo oculto serverless es todo cargo de una arquitectura sin servidores que no proviene del tiempo de cómputo de la función, sino de servicios metered asociados: NAT Gateway, transferencia de datos, ingesta de logs y bases de datos managed como DynamoDB o RDS. “Serverless” describe un modelo de facturación, no un límite de infraestructura, y cada servicio que toca tu función se cobra por su cuenta.
¿Por qué mi factura serverless es más alta que el compute que usé?
Porque una sola request no toca un solo medidor. Toca varios, y cada uno factura aparte. Según el análisis publicado en dev.to, una request típica puede pasar por API Gateway (por request más datos), la Lambda (GB-segundos más invocación), CloudWatch Logs (por GB ingerido y almacenado), un NAT Gateway si la función está en VPC, DynamoDB o RDS, y encima la transferencia de salida hacia el cliente.
Ponele que mirás el dashboard y ves USD 10 de Lambda. Tranquilo. Después llega el statement y son USD 57. ¿Qué pasó? Los otros medidores. El error de cálculo no está en cuánto corre tu código, está en asumir que la función es el centro de costo cuando es apenas una parada en el camino.
La categoría es la misma en AWS, GCP y Azure a finales de 2026. Cambia el nombre del servicio, no la lógica de que cada pieza tiene su propio ticket.
API Gateway y Lambda: los sospechosos obvios cuestan menos de lo que creés
Los dos servicios que todo el mundo mira primero suelen ser la parte más chica. API Gateway cobra por invocación más datos transferidos, y Lambda cobra GB-segundos más un cargo por invocación. Para 10 millones de requests al mes, la combinación de ambos ronda los USD 10-15, según las tarifas públicas de AWS vigentes en 2026. Te puede servir nuestra cobertura de hosting gratuito, aunque Vercel parezca gratis al inicio.
Eso sí: es el piso, no el techo. El problema aparece cuando la función que cuesta centavos dispara servicios que cuestan dólares. Optimizar la memoria de Lambda al gramo mientras ignorás el NAT Gateway es como cambiar la lamparita mientras el aire acondicionado queda prendido todo el mes.
¿Por qué el NAT Gateway hace cara tu VPC?
El NAT Gateway es de los costos ocultos serverless que más sorprende. Si tu función vive dentro de una VPC y necesita salir a internet (una API externa, un webhook, un servicio de terceros), pasa por un NAT Gateway. Y ese aparato cobra doble: ~USD 0,045 por hora que existe, más ~USD 0,045 por cada GB que procesa.
Hagamos la cuenta. El cargo por hora solo, corriendo 24/7, ya son unos USD 32 al mes antes de mover un byte. Sumale 10 GB por día de tráfico y estás cerca de USD 45-50 mensuales por un componente que ni aparece como “función” en tu cabeza. Es idle-but-provisioned en estado puro: pagás por tenerlo, lo uses o no.
¿La salida? Para servicios de AWS (S3, DynamoDB, SQS), usá VPC Endpoints en vez de rutear todo por el NAT. El tráfico interno evita el gateway y te ahorrás el cargo por GB. No es magia, es leer bien por dónde sale cada llamada.
CloudWatch Logs: la ingesta que no ves venir
CloudWatch Logs cobra por GB ingerido, y ese cargo no está incluido en el compute de Lambda. Cada línea que logeás cuesta al entrar, además de lo que después pagás por guardarla. Una función que escribe 1 MB por invocación, multiplicada por 10 millones de invocaciones al mes, te deja unos 10 GB de ingesta que aparecen como una línea separada en la factura. En nuestra guía de configurar infraestructura DNS propia profundizamos sobre esto.
Acá viene lo bueno: el logging verboso “por las dudas” es plata tirada. Bajá el nivel de log en producción, sacá los console.log de debug que quedaron colgados, y configurá retention policies para no acumular meses de logs que nadie va a leer. Un log que ingresás y borrás a los 7 días cuesta bastante menos que uno que guardás para siempre.
Transferencia de datos: la plata que sale de la nube
La transferencia de datos es el cargo silencioso por excelencia. Los datos que salen de AWS hacia internet cuestan alrededor de USD 0,09/GB. El tráfico entre zonas de disponibilidad (cross-AZ) cuesta ~USD 0,01/GB. Y la replicación entre regiones suma otro tanto. Ninguno grita, todos crecen.
El detalle que se escapa: datos entre servicios de AWS que no salen a internet a veces son gratis y a veces se cobran, según crucen o no de AZ. Si tu Lambda responde payloads grandes directo al cliente sin un CDN adelante, cada respuesta paga salida. Meter una capa de cache o CDN entre la función y el usuario baja esa línea de forma directa.
DynamoDB, RDS y managed services: metering por operación
Cada servicio managed tiene su propia métrica, y ahí es donde la factura se descontrola sin ruido. DynamoDB en modo on-demand cobra por read/write units y puede salir mucho más caro que provisioned para volúmenes predecibles. El costo en on-demand escala con cada operación, mientras que en provisioned, si el patrón de tráfico es estable, pagás una fracción.
RDS es otra historia: cobra por hora de instancia más storage más transferencia, prendido esté o no procesando queries. Subís la base, la conectás a tu Lambda, funciona bárbaro en las pruebas, la dejás corriendo, y a fin de mes te das cuenta de que la instancia estuvo cobrando 24/7 aunque el tráfico real fueran dos horas al día. La “elasticidad” del serverless no se contagia sola a los servicios que le colgás al lado. Ya lo cubrimos antes en en tu estrategia de CI/CD.
Tabla: dónde va realmente la plata en un stack serverless
| Servicio | Cómo cobra | Ejemplo mensual estimado | Cómo reducirlo |
|---|---|---|---|
| Lambda + API Gateway | GB-segundos + invocación + datos | ~USD 10-15 (10M requests) | Ajustar memoria, batch de requests |
| NAT Gateway | ~USD 0,045/h + ~USD 0,045/GB | ~USD 45-50 (10 GB/día) | VPC Endpoints para servicios AWS |
| CloudWatch Logs | Por GB ingerido + almacenado | ~USD 5 (10 GB ingesta) | Bajar log level, retention policies |
| Transferencia a internet | ~USD 0,09/GB salida | Variable según payloads | CDN/cache adelante de Lambda |
| DynamoDB on-demand | Por read/write units | Variable según read/write units | Pasar a provisioned si el patrón es estable |
Los números son estimaciones ilustrativas con tarifas públicas de AWS a 2026: tu factura depende del patrón real de tráfico, la región y el diseño. Verificá siempre con la calculadora oficial antes de presupuestar.
¿Cómo presupuestar serverless antes de que sea tarde?
El presupuesto sale de estimar el flujo, no de adivinar el compute. La secuencia es simple: calculá invocaciones esperadas, multiplicá por el tamaño de payload de request y response, sumá los logs que vas a generar, y agregá NAT más transferencia de datos. Recién ahí tenés un número que se parece a la factura real.
La AWS Pricing Calculator te deja modelar cada servicio por separado. Herramientas como CloudZero ayudan a mapear costos por función o proyecto. Y ojo con el free tier: es generoso al arrancar, pero cuando se termina, los cargos que estaban en cero aparecen de golpe. Si armás infraestructura web o cloud para un proyecto propio, conviene también mirar opciones de hosting predecibles como donweb.com, donde el costo no depende de cuántos medidores se prendan por request.
¿Cómo monitorear costos serverless para no llevarte sorpresas?
El monitoreo arranca antes de la primera factura, no después. Configurá un CloudWatch Billing Alarm y activá AWS Cost Anomaly Detection para que te avise cuando algo se dispara solo. Etiquetá (tagging) cada recurso por función o proyecto para saber quién gasta qué.
Un setup razonable: alerta si la factura sube más del 20% respecto al promedio de los últimos 30 días. En las primeras semanas de un proyecto nuevo, revisar el gasto todos los días es práctica recomendada. Esperar al resumen de fin de mes es enterarte del incendio cuando ya no hay nada que apagar.
Qué está confirmado y qué depende de tu caso
- Confirmado: el compute de Lambda es una fracción de la factura total en la mayoría de los stacks serverless, según el análisis de dev.to.
- Confirmado: NAT Gateway, CloudWatch Logs y transferencia de datos son cargos independientes del tiempo de cómputo.
- Confirmado: las categorías de costo aplican igual en AWS, GCP y Azure en agosto de 2026.
- Depende: los montos exactos (los USD 57 de ejemplo) varían con tu tráfico, región y diseño. Son ilustrativos, no una promesa.
- Depende: si on-demand o provisioned te conviene más se define por qué tan predecible es tu carga.
Errores comunes con los costos serverless
- Optimizar solo la Lambda. Ajustás memoria al detalle y dejás el NAT Gateway cobrando fijo. Mirá primero los cargos que corren 24/7.
- Loguear todo “por si acaso”. El logging verboso en producción se paga por GB ingerido. Bajá el nivel y poné retention.
- Poner la función en VPC sin necesidad. Si no necesita recursos privados, sacala de la VPC y te evitás el NAT. Si la necesita, usá VPC Endpoints.
- Usar DynamoDB on-demand con tráfico estable. On-demand es cómodo para cargas impredecibles; para volumen constante, provisioned suele salir varias veces más barato.
- Esperar la factura para monitorear. Sin alarmas ni anomaly detection, te enterás cuando ya pagaste.
Preguntas Frecuentes
¿Por qué mi factura serverless es tan cara si uso poco compute?
Porque el compute de Lambda suele ser la parte más chica del total. El resto son servicios metered que la función usa sin que los cuentes como costo: NAT Gateway, ingesta de logs en CloudWatch, transferencia de datos y bases managed. Cada uno factura por separado. Más contexto en al elegir herramientas de deployment.
¿Cuáles son los costos ocultos de AWS Lambda?
Los principales son NAT Gateway (~USD 0,045/h más ~USD 0,045/GB), CloudWatch Logs por GB ingerido, transferencia de datos a internet (~USD 0,09/GB) y cross-AZ (~USD 0,01/GB), más DynamoDB o RDS. Ninguno figura como tiempo de cómputo de la función.
¿Cómo evito facturas sorpresa en serverless?
Configurá un CloudWatch Billing Alarm y AWS Cost Anomaly Detection antes de la primera factura, con una alerta si el gasto sube más del 20% respecto al promedio de 30 días. Etiquetá recursos por proyecto y revisá el costo a diario las primeras semanas.
¿DynamoDB on-demand o provisioned es más barato?
Provisioned suele ser más barato para tráfico estable y predecible: on-demand puede costar varias veces más para el mismo volumen. On-demand conviene cuando la carga es irregular o no la podés estimar.
¿Cómo reduzco el costo del NAT Gateway?
Usá VPC Endpoints para que las llamadas a servicios de AWS (S3, DynamoDB, SQS) no pasen por el NAT y te ahorres el cargo por GB. Si la función no necesita recursos privados de la VPC, sacala de la VPC directamente y eliminás el cargo por hora.
Conclusión
El serverless no es caro por diseño, es caro por sorpresa. La factura duele cuando tratás a la función como el único centro de costo y te olvidás del fan de servicios metered que tiene alrededor. Lo que cambió en 2026 no es la tecnología, es que ya hay suficientes historias de facturas sorpresa como para saber dónde mirar: NAT Gateway, transferencia de datos, ingesta de logs y bases managed.
Qué hacer, concreto: estimá el flujo completo antes de desplegar, prendé alertas de costo desde el día uno, sacá logs de debug de producción, y revisá si DynamoDB y RDS están en el modo correcto para tu tráfico. Tres líneas de la factura que hoy no mirás probablemente sean las que más pesan el mes que viene.
Fuentes
- The Hidden Costs of Serverless (dev.to) – análisis original sobre dónde va la plata en un stack serverless (agosto 2026)
- CloudZero – desglose del pricing de AWS Lambda y servicios asociados
- Patotski – la trampa de costo del NAT Gateway en VPC
- ByteIota – FinOps y costos ocultos de serverless en 2026
- Mentor Guadiana – costos reales de un stack en Vercel





