AWS Lambda pricing now per ms • Hacker News Board

Re: AWS Lambda pricing now per ms

#271

Post by astral303 » Wed, Dec 02, 2020, 4:09 AM UTC

ignoramous wrote: post #82

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

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

That's because keeping track of request state is not free. Ask an edge router. If you have a request open, even though it's not doing CPU, that request has to be in a queue somewhere, tracked for a response that can be transmitted back.

I don't know the infra costs of operating lambda, but my guess is that it's far from CPU-dominated.

I would not be surprised if the Cloudflare pricing model is making a tradeoff to make CPU-bound workloads pay for more of the infra than the rest. It's a valid trade-off to make as a business offering, and it might be feasible given the mixture of workloads. Whether it's the right way is debatable. Whether this model can be tanked by an army of actors taking advantage of CPU-insensitive pricing remains to be seen, or is an acceptable risk that you can take (which you can observe and protect against).

Re: AWS Lambda pricing now per ms

#272

Post by digianarchist » Wed, Dec 02, 2020, 5:02 AM UTC

rajinikantham wrote: post #257

pistoriusp wrote: post #254

Earlier quoted context omitted.

Are 15 minute max execution times still the norm?

Yes. I didn't see anything about relaxing those limits today in the keynote. Once can hope and dream..

I saw the news around running container images as artifacts which is welcome. Still the 15 min limit restricts a lot of use cases.

https://aws.amazon.com/blogs/aws/new-for-aws-lambda-containe...

Re: AWS Lambda pricing now per ms

#273

Post by JJJollyjim » Wed, Dec 02, 2020, 5:11 AM UTC

brunoluiz wrote: post #18

I am curious to see if this will mean a shift to more efficient languages (Go or Rust) for Lambda services, as usually people default to JS

I just checked cloudwatch for my rust-based function, I'm now being billed 1ms :D

Re: AWS Lambda pricing now per ms

#274

Post by _rs » Wed, Dec 02, 2020, 5:32 AM UTC

staticassertion wrote: post #247

archgoon wrote: post #149

Earlier quoted context omitted.

Huh... that's the limit of lambda functions, are you doing some sort of work in 15 minute chunks?

Instead of processing 10 messages off of SQS per lambda we process 10, then start polling for more using the same lambda, and don't stop until the lambda is just about to die.

Forgive me if this is naive, but why not trigger a lambda for each message separately? I think they’ll automatically reuse lambdas instead of spinning down

Re: AWS Lambda pricing now per ms

#275

Post by [deleted] » Wed, Dec 02, 2020, 6:19 AM UTC

irrational wrote: post #175

cortesoft wrote: post #72

Earlier quoted context omitted.

Are you implying that they are trying to make money?

I'm implying that they are trying to undercut competition to drive them out of business so they can then raise prices across the board.

[deleted]

Re: AWS Lambda pricing now per ms

#276

Post by philosopher1234 » Wed, Dec 02, 2020, 6:19 AM UTC

Thaxll wrote: post #221

philosopher1234 wrote: post #34

Earlier quoted context omitted.

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 is not AOT compiled.

... yes it is?

Re: AWS Lambda pricing now per ms

#277

Post by ignoramous » Wed, Dec 02, 2020, 7:32 AM UTC

staticassertion wrote: post #245

acer4666 wrote: post #180

Earlier quoted context omitted.

This is pretty standard AWS marketing spiel. They make vague assertions of "ah but you're not considering the big picture...." with no details

If you want to compare two things that are different in a ton of ways, don't be mad when someone points it out.

It isn't about the products, it is about the pricing model in a similar market.

Second, for sub 50ms workloads [0], Workers is absolutely a superior solution to API Gateway + Lambda or Cloudfront + Lambda at Edge if the workloads can fit 128MB RAM and package/compile to 1MB JavaScript or WASM executables, in terms of cost, speed, latency, ease of development etc

[0] For Workers, 50ms is all CPU time and that is definitely not the case with Lambda which may even charge you for the time it takes to setup the runtime to run the code and time spent doing Network IO and bandwith and RAM and vCPUs and what not.

Re: AWS Lambda pricing now per ms

#278

Post by mcintyre1994 » Wed, Dec 02, 2020, 7:34 AM UTC

dodobirdlord wrote: post #260

yeldarb wrote: post #238

Earlier quoted context omitted.

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…

If your lambda function detects that it is going to hit the timeout you could have it launch a Fargate container to handle the long merge. Fargate is essentially a long-lived Lambda.

It’s also probably much easier to share code between those two implementations with the new container based lambdas :)

Re: AWS Lambda pricing now per ms

#279

Post by snypox » Wed, Dec 02, 2020, 9:01 AM UTC

digianarchist wrote: post #272

rajinikantham wrote: post #257

Earlier quoted context omitted.

Yes. I didn't see anything about relaxing those limits today in the keynote. Once can hope and dream..

I saw the news around running container images as artifacts which is welcome. Still the 15 min limit restricts a lot of use cases. https://aws.amazon.com/blogs/aws/new-for-aws-lambda-containe...

As far as I know, if you run for more than a few seconds Lambda’s cost will _really_ not worth it. One should prefer ECS or Batch.

Re: AWS Lambda pricing now per ms

#280

Post by snypox » Wed, Dec 02, 2020, 9:04 AM UTC

cordite wrote: post #251

This is great, AWS. A feature I'd really like next is secrets as environment variables like ECS. Retrieving SecretsManager secrets and SSM Secure Parameters in application code is messy and provides significant friction for developers on my team.

I’m confused. This is available already for more than a year (maybe 2).

https://docs.aws.amazon.com/AmazonECS/latest/developerguide/...