Compare / AWS Lambda
The AWS Lambda alternative that never times out
AWS Lambda is excellent at short, spiky, event-driven work and stops being excellent the moment the job takes longer than 15 minutes, needs a warm process, or wants a real filesystem. Lizard runs the same code as a long-lived process in its own container, with no invocation to end and no per-request charge.
Why developers look for a AWS Lambda alternative
Fifteen minutes is a hard ceiling
A Lambda invocation is terminated at 900 seconds. Video transcoding, large imports, model inference, and long ETL jobs all get split into a state machine to work around a limit that a process does not have.
Cold starts are structural
A function that has not run recently pays initialisation on the next request. Provisioned concurrency fixes it by paying for a warm instance — at which point you are paying for a server without getting one.
Nothing survives between invocations
Warm state survives only inside one execution environment, and only until it is recycled — you cannot count on a cache or a pool being there. Each concurrent environment opens its own database connections, which is why RDS Proxy exists.
Always-warm gets expensive
A 1 GB function running continuously is about $43.80 a month of duration charges before requests. On Lizard the same 1 GB is about $10 a month of memory, plus CPU only while the process works — cents a month for a warm service that mostly waits.
Lizard vs AWS Lambda
Every figure read off AWS Lambda’s published pricing and our own. Last verified: 27 August 2026.
| Compared by | Lizard | AWS Lambda |
|---|---|---|
| Maximum run time | None — the process stays up | 15 minutes per invocation |
| Memory ceiling | Scale to what the plan allows, up to 40 GB on Pro | 10 GB on default compute; 32 GB and 16 vCPUs on Managed Instances |
| Cold starts | None — the process is already running | On first request, unless you pay for provisioned concurrency |
| Filesystem | Full read-write root | /tmp, 512 MB to 10 GB — plus EFS or S3 Files mounted read-write under /mnt |
| Compute price | $0.0278 per vCPU-hour, $0.0139 per GB-hour, on measured use | $0.0000166667 per GB-second on x86, $0.0000133334 on Arm (us-east-1) |
| Requests | Not billed | $0.20 per million |
| Always-warm 1 GB workload | About $15 a month at 1 GB and 0.25 vCPU average | About $43.80 a month of duration, before requests |
| Free tier | $5 of credit, no card | 1 million requests and 400,000 GB-seconds a month |
| WebSockets and streaming | Ordinary long-lived connections | Response streaming direct from function URLs; WebSockets need API Gateway, billed per message and per connection-minute |
| Database connections | One pool, in one process | One per concurrent invocation — RDS Proxy is the usual fix |
When AWS Lambda is the better choice
Genuinely spiky, event-driven work: an S3 trigger, a Kinesis consumer, a cron that runs for four seconds a day, a webhook receiver that is idle 23 hours out of 24. Lambda scales to zero for real, the free tier of 1 million requests and 400,000 GB-seconds covers a lot, and the integration with the rest of AWS is something no third party matches. For that shape, a server you keep running is the wrong tool.
Moving from AWS Lambda
No Dockerfile required — lizardpack detects the stack and writes one on the build node. If your repo already has a Dockerfile, it is used as it stands.
Frequently asked questions
It depends on why you are leaving. For work that outgrew the 15-minute limit or needs a warm process, a platform that runs containers — Lizard, Railway, Render, or AWS Fargate. For staying serverless with fewer limits, Google Cloud Run. For edge-shaped request handling, Cloudflare Workers.
Usually because the function is effectively always running, or because provisioned concurrency is on. Duration is billed per GB-second, so a 1 GB function that never idles costs about $43.80 a month before the $0.20 per million requests — and at that point you are paying continuously for something billed as if it were occasional.
Inside AWS: Lambda MicroVMs run a single job up to 8 hours, on their own API, ARM64 only, in five regions. Durable functions span up to a year for multi-step work, but each invocation is still capped at 15 minutes, so you split the job into checkpointed steps. Otherwise Step Functions, Fargate, or EC2. Outside AWS, you run it as an ordinary process: on Lizard a worker service has no time limit and no HTTP port, so a long import or a transcode job just runs to completion.
Yes. Wrap the handler in a small HTTP server or a worker loop, then run lizard up — lizardpack detects Node, Python, Go, Java, Ruby, or Rust and writes the Dockerfile. What changes is the shape: one process handling many requests instead of many invocations handling one each, which usually simplifies the connection pooling and the caching.
No. Lizard bills measured CPU, memory, and disk by the second, plus egress past the plan allowance at $0.05 per GB and object storage at $0.015 per GB-month — and nothing per request or per invocation. The trade is that a service bills every second it is up, where a Lambda that nobody calls costs nothing.
Build with AI. Ship with Lizard.
You don't need a platform team to go live. Your whole cloud, one CLI command away.
No credit card required