Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AWS Lambda pricing now per ms

aws.amazon.com

Post reply on HN
Print view View original

131–140 of 291 posts

Re: AWS Lambda pricing now per ms

#131

Post by munns »

fitzoh wrote: post #126
throwaway894345 wrote: post #91

Earlier quoted context omitted.

Wow, I haven’t read yet, but I’m very curious if this affects the size limits on the lambdas. I’ve tried to build lambdas for a small Python use case, but by the time I imported pandas and a few other libraries I exceeded the 250 mb limit and migrated to ECS/Fargate, but the startup times were much longer.

https://twitter.com/chrismunns/status/1333825503464214530 Docker containers can be up to 10gb, traditional lambdas are still limited to 250mb.

Thats me. We've got some fun things we do behind the scenes to keep Lambda container image support snappy. SO yes, up to 10gb artifacts with container image support.

Re: AWS Lambda pricing now per ms

#132

Post by gen220 »

philosopher1234 wrote: post #34
tgv wrote: post #26

Earlier quoted context omitted.

I've got bad experiences with go startup (i.e., cold runs). They're much more expensive than I would have expected. If node can indeed run in 40ms (as https://news.ycombinator.com/item?id=25267211 says), then I'm surely going back to JS.

What is your experience? Go is an AOT compiled language so the only thing I could imagine you running into on startup is loading the binary into memory? Theres not a cold-start issue with Go, as its not an optimizing JIT. Edit: Bizarre. Seems like Go on lambda does actually have slower cold start than JS or Python. I wonder if its just that the binary is likely larger than the equivalent JS source code? https://level…

> The function did nothing except emit ‘hello world’.

A more realistic benchmark would be parsing a 1kb protobuf blob and printing some random key from it.

(this would require importing a non-stdlib parser)

Without knowing how it's implemented, my guess is that they're conserving python/v8 processes, so that they're not cold-starting the interpreter on each lambda execution.

You can't [1] do the same thing for a Go binary, so they have to invoke a binary, which might involve running some scans against it first.

This leads to some pretty counterintuitive conclusions! If you want minimal latency (in Lambda!!), you really should be using JS/Python, I guess.

[1]: OK. Maybe you could. Go has a runtime after all, although it's compiled into the binary! I have never heard of anybody doing this, but I'd love to read something about it. :)

Re: AWS Lambda pricing now per ms

#133

Post by jthomerson »

munns wrote: post #56
catchmeifyoucan wrote: post #2

For reference - Lambda functions used to billed at 100ms intervals. My Node.Js function usually only takes 37-40ms to run. So this is a pretty good advancement for cost savings.

Awesome! That was the idea here. Lots of sub 100ms workloads and we really want you to be able to pay for what you use. - Chris, Serverless@AWS

Chris, while I've seen the change in my accounts on regular Lambda, I don't yet see it on Lambda@Edge. I think Lambda@Edge is the place where we'd benefit from this change the most, because many L@E scenarios take single-digit milliseconds, and the cost of L@E is 3x regular Lambda.

Any word on whether we'll also see this change on L@E billing?

Re: AWS Lambda pricing now per ms

#134

Post by munns »

jthomerson wrote: post #133
munns wrote: post #56

Earlier quoted context omitted.

Awesome! That was the idea here. Lots of sub 100ms workloads and we really want you to be able to pay for what you use. - Chris, Serverless@AWS

Chris, while I've seen the change in my accounts on regular Lambda, I don't yet see it on Lambda@Edge. I think Lambda@Edge is the place where we'd benefit from this change the most, because many L@E scenarios take single-digit milliseconds, and the cost of L@E is 3x regular Lambda. Any word on whether we'll also see this change on L@E billing?

Yes, to be clear this change was just for Lambda. L@E is honestly a completely different service run by a different part of AWS that just happens to share parts of our core worker platform. I am not 100% aware of when they might adjust their own pricing on this, but also couldn't share any roadmap here (sorry).

Re: AWS Lambda pricing now per ms

#135

Post by groundthrower »

munns wrote: post #129
groundthrower wrote: post #127

Earlier quoted context omitted.

Hi, are there any plans on offering instances with more CPU cores than the maximum 2 as I guess you have today?

Yes, announced today you can go up to 10gb/6 vCPUs: https://aws.amazon.com/blogs/aws/new-for-aws-lambda-function...

Okay, nice. And if I would like like 32 vCpus? Having an application today that has a huge degree of parallelism, but utilizing an external cloud provider that offers dedicated machines with very affordable pricing. Would really like to use lambdas instead though.

Re: AWS Lambda pricing now per ms

#136

Post by jeffcarter »

staticassertion wrote: post #107
munns wrote: post #80

Earlier quoted context omitted.

Today, for a nonstop workload you might save money with Fargate or ECS.

Yeah, I'd be curious to see how much money we'd save with Fargate.

For raw compute, Fargate is ~1/2 the cost of Lambda. But you'd have to orchestrate the launch yourself. It could be worth it though depending on your workload

Re: AWS Lambda pricing now per ms

#137

Post by manigandham »

tejohnso wrote: post #121
ignoramous wrote: post #82

Earlier 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?

Not if you're actually taking up that much cache storage but bandwidth has plenty of examples of high usage on low tiers. They usually allow it as long as you're not affecting the rest of the network adversely since the lines are already paid for (which is the right approach IMO).

Re: AWS Lambda pricing now per ms

#139

Post by munns »

groundthrower wrote: post #135
munns wrote: post #129

Earlier quoted context omitted.

Yes, announced today you can go up to 10gb/6 vCPUs: https://aws.amazon.com/blogs/aws/new-for-aws-lambda-function...

Okay, nice. And if I would like like 32 vCpus? Having an application today that has a huge degree of parallelism, but utilizing an external cloud provider that offers dedicated machines with very affordable pricing. Would really like to use lambdas instead though.

Interesting. Not possible today. We'd still encourage paralyzation up through multiple concurrency of functions being executed.
Post reply on HN