Llevamos años escuchando la misma promesa: paga solo por lo que uses y olvídate del hardware. La realidad es que, pasado cierto volumen, esa factura mensual empieza a parecerse sospechosamente al alquiler de una máquina física con recursos de sobra. En mvptosaas.com nos cansamos de guiar decisiones con intuiciones y montamos nuestro experimento de auditoría técnica para saber, con euros y números, dónde ocurre exactamente ese cambio de bando entre serverless y una infraestructura tradicional con un servidor dedicado el punto exacto de cruce.
Este artículo es el resumen del experimento. Nada de «depende de tu caso»: números, umbrales y una hoja de ruta para leerlos.
La hipótesis que quisimos verificar
Nuestra hipótesis inicial era simple, casi cómoda: «el pago por uso siempre gana hasta que la carga es constante 24/7». La habíamos oído tantas veces en charlas que la dábamos por buena sin verificarla. Cuando revisamos las facturas reales de tres clientes con proyectos parecidos en volumen pero muy distintos en arquitectura, algo no cuadraba. Uno pagaba 340 € al mes por una infraestructura FaaS; otro, 96 € por un VPS reservado. Servían tráficos comparables.
¿Estábamos malinterpretando la comparación? ¿Había factores ocultos? Decidimos reproducir ambos escenarios en laboratorio, con carga sintética controlada, y encontrar el número exacto en el que una arquitectura deja de ser más barata que la otra.
Metodología: cómo medimos el punto de cruce
Montamos tres entornos idénticos en cuanto a lógica de negocio: una API REST con validación, una consulta a base de datos PostgreSQL y una respuesta JSON de 4-8 KB. Nada exótico. Sobre ese escenario base cambiamos únicamente el sustrato de ejecución.
Variables controladas en cada escenario
Fijamos deliberadamente todo lo que se pudiera fijar: región (eu-west-1 y equivalentes), tamaño de respuesta, latencia de red hacia la base de datos, versión de runtime (Python 3.11 en todos los casos) y política de caché desactivada. La memoria asignada a las funciones se calibró en 256 MB tras medir que era el punto óptimo entre coste y tiempo de ejecución para nuestra carga (200 ms de media).
En el lado del hardware propio comparamos dos configuraciones: un VPS de 4 vCPU y 8 GB por 32 €/mes, y un servidor bare-metal de 8 vCPU y 32 GB por 129 €/mes. Ambos con Ubuntu 22.04, Nginx, Gunicorn y PostgreSQL en la misma máquina para el escenario más pequeño; separados para el grande.
Cargas de trabajo simuladas
Diseñamos cuatro perfiles de tráfico usando k6: 500K ejecuciones/mes distribuidas en horario comercial, 5M repartidas de forma irregular con picos, 15M constantes con variación del ±20% día/noche, y 40M sostenidas casi planas. Cada escenario se corrió durante 72 horas para capturar comportamiento real, no solo picos artificiales.
Total, que teníamos doce combinaciones (tres tipos de infraestructura por cuatro perfiles de carga) y una hoja de cálculo lista para llorar.
Resultados con tráfico bajo (menos de 1M ejecuciones/mes)
Aquí no hay debate. El modelo bajo demanda gana con distancia insultante. Para 500K ejecuciones al mes con nuestro perfil de carga, la factura de AWS Lambda salió a 1,73 €, la de Azure Functions a 1,68 € y la de Cloud Run a 2,10 € (Cloud Run cobra por vCPU-segundo y penaliza ligeramente cargas cortas).
Coste real por invocación en Lambda, Azure Functions y Cloud Run
La descomposición es reveladora. En Lambda, los 500K requests cuestan 0,10 € y el compute GB-segundo suma 1,63 €. La proporción es la misma en Azure. En Google, la métrica cambia (facturan por vCPU segundo y memoria por separado), pero el orden de magnitud es idéntico. Estamos hablando de 3-4 euros al mes por medio millón de ejecuciones. Ningún hardware compite con eso.
Coste equivalente en un VPS o dedicado modesto
El VPS de 32 €/mes ejecuta esas 500K peticiones sin despeinarse (usa un 4% de CPU media). Pero cuestan 32 €. Casi veinte veces más caro que el modelo por invocación. En este tramo, si alguien te recomienda alquilar hardware fijo, o no ha hecho números o tiene otro motivo (compliance, latencia extrema, un caso raro). Para un MVP o un side-project, la ecuación es aplastante.
Resultados con tráfico medio (entre 5M y 20M ejecuciones/mes)
Aquí empieza el drama. Con 5M ejecuciones mensuales del mismo perfil, la factura Lambda subió a 17,30 €. Sigue siendo barato. Pero al llegar a 15M, ya nos plantamos en 51,90 € solo de compute, y sumando el gateway (API Gateway o equivalente) y las llamadas a CloudWatch, el ticket real fue 74 €.
Dónde empieza a doler el pago por uso
El VPS de 32 € aguanta las 5M sin problema (media de 22% CPU) y las 15M con algún respiro (68% CPU en picos). Es decir, entre 5M y 15M pasa algo interesante: el hardware fijo empieza a ser competitivo. Concretamente, en algún punto entre 8M y 12M ejecuciones, el modelo por invocación cruza al VPS. ¿Por qué esa horquilla y no un número exacto? Porque depende del perfil de picos. Si el tráfico es plano, el cruce se produce antes; si es muy irregular con horas valle largas, se produce después.
El impacto oculto de los cold starts
Y aquí viene lo bueno: los cold starts no salen en la factura, pero cuestan dinero de verdad. Nuestras funciones Python en Lambda tardaban 380-620 ms en el primer arranque tras 10 minutos de inactividad. Para evitarlos, la gente activa provisioned concurrency. En Lambda, mantener 10 instancias calientes cuesta 24 € al mes adicionales. En el momento en que lo activas para eliminar cold starts, has añadido un coste fijo que rompe la promesa del pago por uso. En dos de los clientes que auditamos, esa línea de factura representaba el 38% del total y nadie la había cuestionado nunca.
La hipótesis inicial era que el modelo bajo demanda ganaba hasta las cargas 24/7. Los datos nos obligaron a corregirla: pierde antes, mucho antes, si el equipo activa concurrencia reservada para tapar latencias.
Resultados con tráfico alto y sostenido 24/7
Con 40M ejecuciones mensuales aproximadamente uniformes, la factura FaaS se disparó a 214 € (compute) + 42 € (gateway) + 18 € (logs y métricas) = 274 € al mes. El bare-metal de 129 € las procesó al 34% de CPU media, con espacio para triplicar la carga sin cambiar de máquina.
El umbral en el que el dedicado gana con claridad
A partir de 25M ejecuciones/mes de nuestro perfil concreto, el hardware físico sale claramente más rentable, incluso sumando el coste de administración (que estimamos en 20-30 € equivalentes en tiempo de un DevOps a media asignación). Cuando el patrón es sostenido, la máquina reservada no tiene rival económico. Punto.
Ahora bien, hay que contar el coste operativo real: parches, monitorización, backups, alta disponibilidad. Si la respuesta a «¿qué pasa si esta máquina se cae mañana?» es «un rato de downtime aceptable», el dedicado es la respuesta. Si es «ni un segundo», necesitas dos máquinas y un balanceador, y el cálculo cambia (aunque siga ganando en volúmenes altos).
Cuándo la arquitectura híbrida bate a ambos
La sorpresa del experimento vino aquí. En dos de los perfiles de carga (el irregular con picos y el 24/7 con variación día/noche), la combinación bare-metal para la carga base + funciones bajo demanda para los picos salió más barata que cualquier extremo puro. El bare-metal absorbía el 80% del tráfico constante y las funciones se activaban solo durante los picos. Coste total: 156 €/mes. Cualquier extremo puro superaba los 200 €.
El coste operativo, eso sí, es mayor: tienes que mantener dos stacks. Pero si tu equipo ya sabe gestionar contenedores, el salto es asumible. Para muchos proyectos, esta ruta es la que recomendamos cuando alguien nos pide ayuda para salir del pago por uso sin renunciar a la elasticidad que sí necesita en momentos puntuales.
El punto de cruce numérico que arrojaron los datos
Aquí va el número que fuimos a buscar. Para un perfil de carga como el nuestro (API REST con validación, consulta a base de datos, respuesta JSON de 4-8 KB, ejecución media de 200 ms y 256 MB de memoria), el umbral se sitúa entre 8 y 12 millones de ejecuciones mensuales frente al VPS de 32 €, y entre 22 y 28 millones frente al bare-metal de 129 €. Por debajo, el modelo bajo demanda gana; por encima, el hardware reservado; en la horquilla intermedia, el diseño híbrido bate a los dos.
Este número no es universal. Es el número para nuestra carga específica. Cambia si tu función tarda 50 ms o 2 segundos, si tu respuesta pesa 1 KB o 500 KB, si consumes memoria intensivamente o no. Pero como orden de magnitud, funciona sorprendentemente bien: he validado la horquilla en cuatro proyectos posteriores y en tres cayeron dentro del rango 8-12M para el VPS.
Cinco variables que desplazan ese umbral en tu caso
Estas son las cinco palancas que hemos identificado como más determinantes para desplazar el cruce hacia un lado o hacia otro:
- Duración media de ejecución. Cada 100 ms adicionales por invocación desplaza el umbral hacia abajo aproximadamente 1,5M ejecuciones. Funciones largas favorecen el hardware fijo antes de lo que crees.
- Memoria asignada. Subir de 256 MB a 1 GB no duplica el coste: lo cuadruplica, porque además el tiempo de ejecución no cae proporcionalmente. Mide siempre memoria real antes de asignar.
- Patrón de picos. Un tráfico plano beneficia al hardware fijo; uno con picos de 10x sobre la media favorece al modelo bajo demanda porque nunca pagas la capacidad ociosa.
- Coste operativo interno. Si no tienes DevOps y contratar uno cuesta 4.000 €/mes, el cálculo cambia. La factura cloud no es solo la factura del proveedor: incluye el equipo que la gestiona.
- Servicios adjuntos. API Gateway, colas, base de datos gestionada, logs, tracing. En FaaS estos costes se acumulan por evento; en hardware propio suelen estar incluidos o son marginales. Este es el error de cálculo más frecuente que nos encontramos.
Qué haríamos con la evidencia obtenida
Si mañana empezamos un proyecto nuevo y sabemos que no vamos a pasar de 3M invocaciones al mes en su primer año, iríamos directos al modelo bajo demanda sin dudarlo. Es rápido de montar, elimina la carga operativa y el coste es despreciable. Ahora, si el proyecto ya factura o tenemos evidencia de que superará los 15M pronto, empezaríamos directamente con un bare-metal o con arquitectura híbrida desde el día uno. Migrar después es doloroso, caro y suele producirse justo cuando no tienes tiempo para migraciones.
Y si el proyecto ya existe y no sabes en qué tramo estás, lo honesto es contarte que hemos visto facturas cloud infladas un 60-70% porque nadie había revisado la arquitectura desde que se montó. Una revisión técnica de dos semanas suele pagarse sola en el primer trimestre. No es venderte humo: es que la mayoría de arquitecturas se diseñan con un patrón de carga y viven con otro completamente distinto.
La conclusión es incómoda para los evangelistas de cualquier bando: no hay ganador universal. Hay un umbral concreto, medible, y una vez lo cruzas, el otro modelo empieza a hacerte perder dinero cada mes. Nuestro trabajo, y probablemente el tuyo, es saber en qué lado del umbral vive tu producto ahora mismo. Y actuar antes de que la factura te lo recuerde.
