Comparar / AWS Lambda
La alternativa a AWS Lambda que nunca agota el tiempo
AWS Lambda es excelente para trabajo corto, irregular y guiado por eventos, y deja de ser excelente en cuanto el trabajo dura más de 15 minutos, necesita un proceso caliente o quiere un sistema de archivos real. Lizard ejecuta el mismo código como un proceso de larga vida en su propio contenedor, sin ninguna invocación que terminar y sin cargo por solicitud.
Por qué los desarrolladores buscan una alternativa a AWS Lambda
Quince minutos es un límite estricto
Una invocación de Lambda se termina a los 900 segundos. La transcodificación de vídeo, las importaciones grandes, la inferencia de modelos y los trabajos ETL largos se dividen en una máquina de estados para esquivar un límite que un proceso no tiene.
Los cold starts son estructurales
Una función que no se ha ejecutado recientemente paga la inicialización en la siguiente solicitud. La concurrencia aprovisionada lo corrige pagando por una instancia caliente — momento en el que estás pagando por un servidor sin obtenerlo.
Nada sobrevive entre invocaciones
El estado caliente sobrevive solo dentro de un entorno de ejecución, y solo hasta que se recicla — no puedes contar con que una caché o un pool estén ahí. Cada entorno concurrente abre sus propias conexiones a la base de datos, y por eso existe RDS Proxy.
Mantenerlo siempre caliente sale caro
Una función de 1 GB ejecutándose continuamente cuesta unos $43.80 al mes en cargos por duración antes de las solicitudes. En Lizard, ese mismo 1 GB cuesta unos $10 al mes de memoria, más CPU solo mientras el proceso trabaja — centavos al mes por un servicio caliente que en su mayor parte espera.
Lizard vs AWS Lambda
Cada cifra tomada de los precios publicados de AWS Lambday de los nuestros. Última verificación: 27 August 2026.
| Comparado por | Lizard | AWS Lambda |
|---|---|---|
| Tiempo máximo de ejecución | Ninguno — el proceso sigue en marcha | 15 minutos por invocación |
| Límite de memoria | Escala a lo que permita el plan, hasta 40 GB en Pro | 10 GB en cómputo predeterminado; 32 GB y 16 vCPU en Managed Instances |
| Cold starts | Ninguno — el proceso ya está en ejecución | En la primera solicitud, a menos que pagues por concurrencia aprovisionada |
| Sistema de archivos | Raíz completa de lectura y escritura | /tmp, 512 MB to 10 GB — plus EFS or S3 Files mounted read-write under /mnt |
| Precio de cómputo | $0.0250128 por vCPU-hora, $0.0125064 por GB-hora, según el uso medido | $0.0000166667 por GB-segundo en x86, $0.0000133334 en Arm (us-east-1) |
| Solicitudes | No se factura | $0.20 por millón |
| Carga de trabajo siempre caliente de 1 GB | Unos $15 al mes con 1 GB y 0.25 vCPU de media | Unos $43.80 al mes, antes de las solicitudes |
| Nivel gratuito | Crédito de prueba de $10, válido durante 31 días | 1 millón de solicitudes y 400.000 GB-segundos al mes |
| WebSockets y streaming | Conexiones normales de larga duración | Streaming de respuesta directo desde las URL de función; WebSockets necesitan API Gateway, facturado por mensaje y por minuto de conexión |
| Conexiones a la base de datos | Un pool, en un proceso | Una por invocación concurrente — RDS Proxy es la solución habitual |
Cuándo AWS Lambda es la mejor opción
Trabajo realmente irregular y orientado a eventos: un trigger de S3, un consumidor de Kinesis, un cron que se ejecuta cuatro segundos al día, un receptor de webhooks que está inactivo 23 de cada 24 horas. Lambda de verdad escala a cero, el nivel gratuito de 1 millón de solicitudes y 400.000 GB-segundos cubre mucho, y la integración con el resto de AWS es algo que ningún tercero iguala. Para ese caso, un servidor que mantienes en ejecución es la herramienta equivocada.
Migrar desde AWS Lambda
No se necesita Dockerfile — lizardpack detecta el stack y escribe uno en el nodo de compilación. Si tu repositorio ya tiene un Dockerfile, se usa tal cual.
Preguntas frecuentes
Depende de por qué te vas. Para trabajo que superó el límite de 15 minutos o necesita un proceso caliente, una plataforma que ejecute contenedores — Lizard, Railway, Render o AWS Fargate. Para seguir con serverless con menos límites, Google Cloud Run. Para manejo de solicitudes con forma de edge, Cloudflare Workers.
Normalmente porque la función está en práctica siempre en ejecución, o porque la concurrencia aprovisionada está activada. La duración se factura por GB-segundo, así que una función de 1 GB que nunca queda inactiva cuesta unos $43.80 al mes antes de los $0.20 por millón de solicitudes — y en ese punto estás pagando de forma continua por algo facturado como si fuera ocasional.
Dentro de AWS: las MicroVMs de Lambda ejecutan un solo trabajo hasta 8 horas, en su propia API, solo ARM64, en cinco regiones. Las funciones durables pueden abarcar hasta un año para trabajo de varios pasos, pero cada invocación sigue limitada a 15 minutos, así que divides el trabajo en pasos con checkpoints. Si no, Step Functions, Fargate o EC2. Fuera de AWS, lo ejecutas como un proceso normal: en Lizard un servicio worker no tiene límite de tiempo ni puerto HTTP, así que una importación larga o un trabajo de transcodificación simplemente se ejecuta hasta completarse.
Sí. Envuelve el handler en un pequeño servidor HTTP o en un bucle worker, luego ejecuta lizard up — lizardpack detecta Node, Python, Go, Java, Ruby o Rust y escribe el Dockerfile. Lo que cambia es la forma: un proceso que maneja muchas solicitudes en lugar de muchas invocaciones que manejan una cada una, lo que normalmente simplifica el pooling de conexiones y la caché.
No. Lizard factura CPU, memoria y disco medidos por segundo, más egreso desde el primer byte a $0.045 por GB y almacenamiento de objetos a $0.0135 por GB-mes — y nada por solicitud ni por invocación. La diferencia es que un servicio factura cada segundo que está activo, mientras que una Lambda a la que nadie llama no cuesta nada.
Construye con IA. Publica con Lizard.
No necesitas un equipo de plataforma para salir a producción. Toda tu nube, a un comando de CLI de distancia.
- Espacios de trabajo
- —
- Servicios
- —
- Add-ons
- —
- Despliegues
- —