Live data from Hacker News

AWS Lambda pricing now per ms

aws.amazon.com

161–170 of 291 posts

Re: AWS Lambda pricing now per ms

#161

Earlier quoted context omitted.

Lambdas are underpowered and often poor choices for compute-heavy workloads. Unless there's an urgency to processing infrequent videos, it might make more sense to backlog messages to the queue and use spot instances for draining the queue and processing videos, especially from a cost perspective. Though I acknowledge that this is a more complex setup.

I haven’t heard that lambdas are “underpowered” before, but I’m interested to learn more. Could you elaborate just a bit on why they are underpowered?

As was mentioned by qvrjuec in a sibling comment, hardware is limited. I seem to remember CPU speeds listed alongside available memory for AWS Lambdas, but the pricing page seems to just list memory now[0]. At the highest end, you're still limited to ~10.2GB of memory, which is considerably lower than what's available via EC2. And while I have no personal experience with the EC2 finer-grained pricing that was announced[1], it sounds like that approach may be a better approach to the described scenario above. We can nitpick on these architectural details, but my response was largely that there are other architectural alternatives that could be more ideal; especially in response to a comment that seems to dismiss the value of pricing at finer time intervals.

[0] https://aws.amazon.com/lambda/pricing/

[1] https://www.cnbc.com/2017/09/18/aws-starts-charging-for-ec2-...

Re: AWS Lambda pricing now per ms

#162

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.

How many people actually use lambda? Always came off as a gimmick to me.

Re: AWS Lambda pricing now per ms

#163
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…

Go binaries are pretty large compared to say, C.

Re: AWS Lambda pricing now per ms

#165
post #101
post #96

Earlier quoted context omitted.

To be clear, you're acknowledging Cloudflare has a much better pricing model but just not as many other services yet?

No to be clear I'm saying you are comparing things that are way more different than our friends at Cloudflare would like you to think. They aren't brought up in any of the convos I have with customers.

> No to be clear I'm saying you are comparing things that are way more different than our friends at Cloudflare would like you to think.

Care to expand on that? What exactly do you mean by "things are way more different"?

Re: AWS Lambda pricing now per ms

#166
post #33

Earlier quoted context omitted.

If a process takes that long, lambda would be a poor architectural choice.

Not necessarily. For low frequency workloads with reasonably long step times, Lambda can still make sense. (E.g. When videos appear in this S3 bucket, process them.) You might only drop videos in once a week, but when you do you want to run some code against them. There are plenty of distributed workflow reasons to run long running Lambdas infrequently rather than spinning up and down an EC2 instance.

If your process takes more than 10 seconds, the extra 100ms charge is pretty much noise.

Re: AWS Lambda pricing now per ms

#168
post #139

Earlier quoted context omitted.

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.

I would love to see this as well: having 96-vCPU Lambda instances (or instances that match the biggest C-family instance you have) would solve a lot of problems for me. The execution model of Lambda (start a runtime, handle requests, AWS handles pool management) feels much easier to use than managing a pool.

Someone from AWS once commented to me that "if you're ever having to manage a pool rather than letting us manage it, that's a gap in our services".

Re: AWS Lambda pricing now per ms

#169
post #134

Earlier quoted context omitted.

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).

How does that even work? Lambda seems like a challenge even with the entirety of the datacenter resources to work with. Running it in constrained edge environments with a VM per function seems like black magic.

The naming is a bit of a misnomer, today L@E doesn't run at the edge (in our PoPs) but when you deploy it copies to every region and then CloudFront routes you to the lowest latency region for your request.

Re: AWS Lambda pricing now per ms

#170

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.

How many people actually use lambda? Always came off as a gimmick to me.

Enough that in 2019 it was the most popular topic at re:Invent (our big user conference) and that today per our re:Invent announcement almost half of all new compute workloads in Amazon are based on it. Pretty heavily used across different industries and verticals.
Post reply on HN