Interesting: the german version (and other non-english versions, if I parse that correct) of the page still mentions rounding up to 100ms while the english version to 1ms.
Cache? Not yet translated? Different pricing model?
AWS Lambda pricing now per ms
231–240 of 291 posts
Re: AWS Lambda pricing now per ms
#232Earlier quoted context omitted.
> ...we really want you to be able to pay for what you use. Cloudflare Workers has the right pricing model. They only charge for CPU time and not wall time. They also do not charge for bandwidth. > Lots of sub 100ms workloads... AWS Lambda (or Lambda at Edge), as it stands, is 10x more expensive for sub 50ms workloads (Workers does allow upto 100ms for the 99.9th percentile) that can fit 128MB RAM. https://medium.com…
> They also do not charge for bandwidth. Is there fine print on this? Can I put 100TB / mo through their caching servers at the lowest $20 price tier?
Very high bandwidth usage for Cloudflare Workers workloads is not against ToS according to Cloudflare's CEO: https://news.ycombinator.com/item?id=20790857
Re: AWS Lambda pricing now per ms
#233I wonder if this change will push more people to consider rewriting code to more memory and CPU-efficient programming platforms, for example from java/c# to C or Rust?
Re: AWS Lambda pricing now per ms
#234Earlier quoted context omitted.
In the real world you don't import 5 seconds worth of dependencies into a lamdba, and a 5 second boot time for a longer-lived service is acceptable.
> In the real world you don't import 5 seconds worth of dependencies into a lamdba Laughs in data science . > a 5 second boot time for a longer-lived service is acceptable. Not every application can tolerate the occasional 5-second-long request. Just because Python can cold boot "hello world" 3 seconds faster than Go doesn't mean that's going to hold in the real world.
You're mixing arguments here. It's not the occasional 5-second long request, it's "the app doesn't start serving requests for 5 seconds".
Using data science tooling in a lambda seems iffy, especially ones that are not production ready. And good luck getting such libraries in go.
Python cold booting an interpreter 3 seconds faster than Go is a big deal, especially if your target execution time is <50ms and you've got a large volume of invocations, and are not being silly and importing ridiculously heavy dependencies into a lambda for no reason other than to make a strange point about Python being unsuitable for something nobody should be doing.
Re: AWS Lambda pricing now per ms
#235I wonder if this change will push more people to consider rewriting code to more memory and CPU-efficient programming platforms, for example from java/c# to C or Rust?
I thought you are limited in the languages they permit, the fastest of which being Go.
Re: AWS Lambda pricing now per ms
#236I find it annoying to have all these pricing per second, and now per millisecond. It's really hard for my mind to visualize what `$0.0000000021 per millisec` actually is.
Being billed by the millisecond does not mean that you should give a pricing per millisecond.
I prefer Digital Ocean or Heroku's approach of billing by the second, but giving the price per month. How on hell is `$0.0000000021 per millisec` better than `$5/month, billed by the millisecond`? If I know that my workload will be about 20% of a dedicated CPU, I know that I'll end up paying about $1 per month.
Re: AWS Lambda pricing now per ms
#237[deleted]
Re: AWS Lambda pricing now per ms
#238Anyone know why there's a hard limit of 15 minutes for Lambda (and 9 minutes for Google Cloud Functions)? Still seems really weird to me.
How long would you like it to be? Chris Munns - Lead of Dev Advocacy for Serverless@AWS
As long as possible. Our jobs usually finish well within the limit but the top 1% hit the limit.
One example we've been wrestling with is a merge operation. Usually it's merging about 1000 records which completes in a few seconds. But every once in a while someone kicks off a job that tries to merge 1,000,000 records and it times out.
We want the benefits of serverless (scale down to zero, up to infinity at the drop of a hat) but these edge cases mean we're having to evaluate other options.
An hour or two would be a good start; then it'd cover 99.9% of requests. With a few hours we could add more nines :)
Re: AWS Lambda pricing now per ms
#239I find it annoying to have all these pricing per second, and now per millisecond. It's really hard for my mind to visualize what `$0.0000000021 per millisec` actually is. Being billed by the millisecond does not mean that you should give a pricing per millisecond. I prefer Digital Ocean or Heroku's approach of billing by the second, but giving the price per month. How on hell is `$0.0000000021 per millisec` better th…
There is simply an enourmous amount of assumptions that would go into estimating anything else, because ms is the only correct metric. Lambda billing for a month? What on earth does that say? 10 invocations running 15 minutes? 90,000 invocations running 100ms? (Those two are equivalent btw).
If I know my function takes around ~35ms ballpark, and I will probably invoke it 5,000 times per day, then I can calculate my monthly: 0.0000000021 $/ms * 35ms * 5,000 * 30 = 0.011 $/month.
AWS usually shows a neat example of usecase and what the billing would be on their pricing pages.
Re: AWS Lambda pricing now per ms
#240Earlier quoted context omitted.
How long would you like it to be? Chris Munns - Lead of Dev Advocacy for Serverless@AWS
As long as possible. Our jobs usually finish well within the limit but the top 1% hit the limit. One example we've been wrestling with is a merge operation. Usually it's merging about 1000 records which completes in a few seconds. But every once in a while someone kicks off a job that tries to merge 1,000,000 records and it times out. We want the benefits of serverless (scale down to zero, up to infinity at the drop…
That sounds like you need a queue of some sort