50 million Lambda invocations per month costs about $18.50. That number surprised me the first time I ran the math, because I expected Lambda to win on price at that scale. Railway at $25/month fixed is more expensive in pure dollar terms, but the story is more complicated once you factor in cold starts, memory tuning, and the operational overhead of staying inside Lambda’s billing model.
This article breaks down exactly what each one costs at different request volumes, where the pricing cliffs are, and which one I’d actually pick depending on the workload type.
AWS Lambda charges on three axes: requests, compute duration (GB-seconds), and any data transfer out of AWS. The free tier covers 1 million requests and 400,000 GB-seconds per month, permanently, not just for the first 12 months.
Current Lambda pricing (us-east-1, as of 2024):
A typical API endpoint function running at 128 MB memory with an average duration of 200ms burns through 0.025 GB-seconds per invocation. At 50 million monthly invocations:
Requests cost: (50M - 1M free) x $0.20 / 1M = $9.80
Compute cost: 50M x 0.025 GB-s x $0.0000166667 = $20.83
Free tier compute offset: 400,000 GB-s x $0.0000166667 = $6.67 credit
Net compute: $20.83 - $6.67 = $14.16
Total Lambda cost: $9.80 + $14.16 = ~$23.96
Wait, that’s higher than the $18.50 I mentioned. The difference is memory configuration. If you tune your function down to 128 MB and your workload genuinely fits, you can hit the lower number. But most real API functions I’ve deployed run at 256 MB minimum, and many run at 512 MB. At 256 MB and 200ms average duration, the compute bill doubles compared to 128 MB.
The point here is that Lambda pricing is sensitive to memory allocation in ways that aren’t obvious until you’re staring at a bill. I’ve watched Lambda costs jump 40% because a developer bumped a function from 256 MB to 512 MB for performance without checking the billing impact.
Use the AWS Free Tier Calculator to model your specific memory/duration combination before committing to an architecture.
Lambda doesn’t charge you extra for cold starts. But cold starts cost you indirectly in ways that matter for production workloads.
A cold start on a Node.js Lambda function adds 200ms to 500ms of latency. On a Java function with a large dependency tree, I’ve seen cold starts exceeding 3 seconds on the first invocation after a quiet period. That latency degrades user experience, which can affect conversion rates on commercial APIs.
The workarounds all cost money:
Provisioned Concurrency: AWS will pre-warm Lambda instances so cold starts don’t happen. Current pricing is $0.000064646 per GB-second of provisioned concurrency. If you provision 10 concurrent instances at 256 MB for a full month:
10 instances x 0.25 GB x 2,592,000 seconds/month x $0.000064646 = ~$419/month
That is not a typo. Provisioned concurrency is expensive for anything beyond minimal concurrency levels. I’ve seen teams spend more on provisioned concurrency than on actual Lambda execution costs.
Scheduled warmup pings: You can hit your functions on a CloudWatch Events schedule to keep them warm. This works at low concurrency but doesn’t scale to multi-instance warmup, and it adds invocation costs and complexity.
Cold starts are why teams with latency-sensitive workloads often end up paying more than the raw Lambda pricing suggests.
Railway operates on a different model entirely. The Hobby plan costs $5/month and covers small personal projects. The Pro plan runs $20/month and gives you:
For practical purposes, a small API service running on Railway Pro with 0.5 vCPU and 512 MB RAM costs about:
vCPU: 0.5 x $0.000463 x 43,200 min/month = $10.00
RAM: 0.5 GB x $0.000231 x 43,200 min/month = $4.99
Base plan: $20/month
Less included credit: -$10
Total: ~$24.99/month
That service runs 24/7. It handles whatever request volume you throw at it within the CPU constraint. 500,000 requests or 5 million requests, the bill stays roughly the same as long as you’re not CPU-bound.
This is the Railway value proposition: predictable billing, no per-request overhead, no cold starts because your container is always running.
Here’s how Lambda (at 256 MB, 200ms average duration) compares to Railway Pro for typical API workloads:
| Monthly Requests | Lambda Cost (est.) | Railway Pro Cost | Notes |
|---|---|---|---|
| 100,000 | $0.00 | $24.99 | Lambda free tier covers this entirely |
| 500,000 | $0.00 | $24.99 | Still inside Lambda free tier |
| 1,000,000 | $0.84 | $24.99 | Lambda free tier exhausted |
| 5,000,000 | $4.17 | $24.99 | Lambda clearly cheaper |
| 10,000,000 | $8.34 | $24.99 | Lambda still ahead |
| 50,000,000 | $41.70 | $24.99 | Railway crosses below Lambda |
| 100,000,000 | $83.40 | ~$45-60 | Railway still cheaper at scale |
At the 50 million requests/month mark, Railway wins on cost for steady, consistent traffic. Lambda wins hard at low-to-medium volumes, especially if you’re inside the free tier.
The crossover point depends heavily on your Lambda memory and duration configuration. Leaner functions push the crossover higher. Heavy functions (512 MB, 500ms+) push it lower.
For a more detailed comparison across hosting platforms, the hosting calculator lets you plug in your actual numbers.
Lambda is genuinely excellent for spiky, unpredictable workloads. If your API gets hit 10,000 times in two minutes twice a day and sits idle the rest of the time, Lambda scales to zero and you pay almost nothing. Railway keeps your container running at full cost whether traffic is flowing or not.
I ran a webhook processing service for a client that received bursts of 50,000 events during business hours, then nothing overnight. Lambda cost them about $8/month. Equivalent Railway capacity would have been $25-30/month. Lambda was the right call.
But I’ve also worked on an API that received steady traffic from a mobile app, roughly 2 million requests per day spread across all hours. Lambda costs at 256 MB and 300ms average duration ran to about $75/month. Moving that to Railway with a properly sized container brought the bill to $35/month and eliminated the cold start latency complaints from mobile clients.
The operational calculus is real too. Lambda requires IAM role management, VPC configuration for database access, layer management for dependencies, and careful attention to timeout and memory settings. Railway deploys from a Dockerfile or Nixpacks detection. The configuration surface is smaller.
Lambda is the right choice when:
Railway makes more sense when:
For most new projects starting with under 1 million requests per month, Lambda costs nothing and you should use it. The free tier is real, permanent, and covers a lot of ground.
Once you’re planning for 20 million requests per month or more with consistent traffic, run the actual numbers using your memory and duration configuration. At that point, Railway’s predictable billing often comes out ahead and you stop managing Lambda configuration drift.
I would not use Lambda for anything with strict P99 latency requirements unless I was prepared to spend on provisioned concurrency. Cold starts are a real problem in production for latency-sensitive workloads, and the workarounds add cost and complexity.
If you’re evaluating Railway for your next project, the Pro plan starts at $20/month with $10 of included compute credit. That pricing is published at railway.com/pricing and covers most small-to-medium production workloads without per-request surprises.
The right answer is not tribal loyalty to either platform. It’s running the actual numbers for your workload pattern. Use the hosting calculator and the AWS Free Tier Calculator to build your model before you commit.