19 ms·

AWS Lambda Edge changes duration billing granularity from 50ms down to 1ms

258 points by mpweiher 6y ago

deleted 6y ago
[deleted]
nrmitchi 6y ago
> This will lower the price for most Lambda@Edge functions Isn't this guaranteed to lower the price for *all* Lambda@Edge functions? What is the case where it wouldn't result is a <= cost?
- cthalupa 6y ago
  If the function still runs in a time evenly divisible by 50ms, the price will remain the same.
  - happytoexplain 6y ago
    More specifically, if it stops anywhere between 49ms and 50ms in each 50ms chunk. So the price would be the same in 2% of executions, I suppose. Edit: Assuming even distribution of run times within each 50ms chunk - I guess maybe that's a bad assumption.
    - paxys 6y ago
      That assumes the runtime is evenly distributed, which is probably not the case. But still yeah, there will be some functions that end exactly in multiples of 50ms.
  - nrmitchi 6y ago
    Ya, you're right. I interpretted the statement as "for some use cases the price might go up", which was a poor interpretation.
  - tclancy 6y ago
    Shout out to the person running `sleep(0.005)` just to make the point.
- paxys 6y ago
  Normally such announcements are coupled with an increase in per-unit price. Not sure if that is the case here though.
  - jen20 6y ago
    > Normally such announcements are coupled with an increase in per-unit price. Are there any examples of AWS ever having done this? Personally I don't recall any, but would be interested to know!
    - lostcolony 6y ago
      Yeah; citation needed. I've never seen an instance of a price increase. I can find multiple forums of people claiming Amazon has never increased prices. The only instance I can find of any cloud provider increasing prices was once in 2015 when Microsoft did in Europe...and while that led to a flurry of "cloud providers are going to increase prices" blog posts and things, calmer heads noted the exchange rates as the likely reason (and, certainly, the claims that prices would increase across the board never came to pass).
      - watermelon0 6y ago
        I remember Google starting to charge for managed Kubernetes clusters a year or two ago, I think the cost went from 0 to 75$ per month.
        temp667 6y ago
        Google has raised prices on all sorts of things - I think AWS is one with rep for not raising prices. Maps API's I think went up pretty big time on google side.
        akiselev 6y ago
        > Maps API's I think went up pretty big time on google side. There were even several posts on HN around that time period of personal projects (maybe even companies) going under because of the price change.
logicslave 6y ago
AWS further squeezing out the competition
jacurtis 6y ago
This is awesome news. I would expect that we would probably see normal Lambda functions eventually follow suit to the 1ms pricing model, or at the very least, something like 10ms incremenets. For those who aren't super familiar with AWS, this announcement only covers "Lamda@Edge", this isn't the "normal" Lamda serverless function service. These are Lamda functions running at AWS Edge Locations, which are hundreds of CDN endpoints around the world. Lamda@Edge have various restrictions on what they can do, compared to the main Lambda service. They can only be triggered by CloudFront (AWS' CDN service). You could think of them as a "lite" version of Lambda. They are generally used for basic tasks like renaming/manipulating HTTP headers coming into the CDN. So they tend to run in just a few milliseconds. Normal Lambda are currently billed in 100ms increments. But it would be great to see this come down. I run a few Lambda functions that take < 10ms to run and it would be nice to be able to get 10x the invocations than I am getting on them now because I have to pay the 100ms rate for a 10ms invocation. Granted its all so cheap, even at scale, that its hard to complain too much.
- stickydink 6y ago
  I think that changed a while ago - regular lambda functions being billed per millisecond? This is Lambda@Edge catching up.
- dastbe 6y ago
  > Normal Lambda are currently billed in 100ms increments. Lambda actually reduced their billing granularity to 1ms at Re:invent 2020. if anything, Lambda Edge is trailing :).
- byefruit 6y ago
  https://aws.amazon.com/blogs/aws/new-for-aws-lambda-1ms-billing-granularity-adds-cost-savings/ https://aws.amazon.com/blogs/aws/new-for-aws-lambda-1ms-bill... Been 1ms for a few months now. =)
- maddyboo 6y ago
  So Lambda@Edge is basically the equivalent of Cloudflare workers?
isoprophlex 6y ago
> Lightweight functions such as header manipulations or URL rewrites tend to have a short duration I'm not knowledgeable AT ALL in this area, having never used or first-hand seen these FAAS things. But header manipulation? Really... These are executed as aws lambdas?! I don't get why you'd ever need to do this. (Not being facetious, honest puzzlement!)
- turtlebits 6y ago
  What would you propose? Yet another AWS service for the specific use case?
  - hamandcheese 6y ago
    Config of some sort maybe? If you can do it in nginx, seems like it should be possible without invoking a lambda.
    - njitbew 6y ago
      I don't understand what nginx has to do with this. nginx's language is just that: a language. If Lambda@Edge would support nginx language, you would still be invoking a lambda. But I'd must rather write some header rewriting code in, say, JavaScript than nginx's language. Then why a (Turing-complete) programming language and not a config language? Simple: because a programming language gives you infinite more power than what any config system could ever provide. E.g. I could compare the origin IP, determine the country, and change the response based on that. And there are plenty of use cases like this which you cannot express in a config language.
      - jfrunyon 6y ago
        > E.g. I could compare the origin IP, determine the country, and change the response based on that. And there are plenty of use cases like this which you cannot express in a config language. Well, you can do that in plenty of "config languages", including nginx[1]. The reason Lambda exists is that it's good for Amazon, because they can push all the costs of the logic back onto the customer. (It could also be good for the customer, in that whatever configuration Amazon might otherwise support could be limited.) [1] http://nginx.org/en/docs/http/ngx_http_geoip_module.html http://nginx.org/en/docs/http/ngx_http_geoip_module.html
Shadonototro 6y ago
not good for JIT'd languages haha, oust dotnet and JS bloat! Oracle was silent, but at least they invested in the right tech with GraalVM and their AOT compiler, as usual, Microsoft missed their chance
- tclancy 6y ago
  This reads like an incantation. For what, I don't know, but I fear it may unleash Cold Fusion upon us all.
  - hobs 6y ago
    Just In Time needs time to warm up and so you'd assume would cost more to boot up and do work and shut down, Ahead Of Time does it... ahead of time.
  - Shadonototro 6y ago
    My comment was flagged because people on hackernews doesn't know what is the definition of a JIT'd language? Or because i am spot on and some people got offended?
    - macintux 6y ago
      Or because it’s irrelevant. JIT languages are not going to be more expensive as a result of this; your cost can only go down, or stay the same.
      - Shadonototro 6y ago
        They can't profit from the duration billing change, lost opportunity to save money is the same as being more expensive
    - tclancy 6y ago
      We all knew what you said. It got flagged because it was not Just In Time.
    - 6y ago
manishsharan 6y ago
Has anyone replicated a sqllite db to Cloudfront cache and used that as an input to their Lambda@Edge ? I have been thinking about this for a while as it would avoid having cloudfront making a origin call to the backend server for db reads on data that does not change frequently. I am trying to figure out why this is a bad idea .
- snissn 6y ago
  do it! Years ago my team messed around with using lambdas to pull/push data from sqlite into s3 and it worked pretty well for certain regime sizes and workloads! Then we partitioned the data to filter out the slow zones into more robust/long running things like a job queue and postgres
- jedberg 6y ago
  Why not just include the sqlite DB as part of your lambda deployment package?
  - diroussel 6y ago
    As long as you can fit it in your 1MB zip file, for viewer-request events. For origin-requests you get 50MB. See https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-limits.html#limits-lambda-at-edge https://docs.aws.amazon.com/AmazonCloudFront/latest/Develope...
    - deleted 6y ago
      [deleted]
    - jedberg 6y ago
      You only have five seconds to process the entire request. If your lambda has to make a request to download a sqlite database every time, and the process it, it probably needs to be small enough to fit into 1MB anyway.
      - freemium413 6y ago
holler 6y ago
This is great news! I'm using lambda@edge to server-side render an ember.js app using Fastboot (http://ember-fastboot.com/ http://ember-fastboot.com/), and lowering the cost is a real big win!
- atonse 6y ago
  Whoa didn’t know this was possible. What’s the overhead and average execution time?
  - holler 6y ago
    There's some set up required and you have to essentially handle how to route the request, handle static files, compression, etc, but it's not _too_ bad. I've been meaning to do a write up on it and probably should, but feel free to check it out in action at the site I'm developing https://sqwok.im https://sqwok.im There's a fastboot meeting next week that should be good as well https://www.eventbrite.com/e/ember-fastboot-ssr-beyond-tickets-144468965565 https://www.eventbrite.com/e/ember-fastboot-ssr-beyond-ticke...
    - HatchedLake721 6y ago
      00:30am UK time, no love for European emberistas :(
      - holler 6y ago
        ah darn! well I'm sure they'll have a recap video! or let me know if you have any questions you'd like to ask, or ask in the fastboot chan on discord, or sqwok :D
- glaucon 6y ago
  This is interesting. I use ember but never fastboot. I've been looking at the deployment doco within the fastboot site. Is this along the lines of what you're using ? https://github.com/ember-fastboot/ember-cli-fastboot/tree/master/packages/fastboot-app-server https://github.com/ember-fastboot/ember-cli-fastboot/tree/ma... . Also, looking at your profile, is https://sqwok.im https://sqwok.im using that approach ? Thanks.
ta20200710 6y ago
Did lambda@edge finally move lambda function execution to the edge cloudfront POPs? For years it actually ran them in the closest AWS region.
nhoughto 6y ago
Interesting, we’re just about to put cloudflare workers in prod and find their approach much more flexible vs lambda@edge being possibly triggered four times at edge part of a request life cycle. But this could significantly reduce cost if your execution time is low. How likely are you to see 1ms execution times for this stuff tho? Super simple logic should be that low I guess.. They must have a very mature execution environment to be able to offer this (if 1ms execution is achievable), cf workers have a whole set to logic to average out cpu spikes so you don’t randomly hit the 50ms limit, bc their execution of your code isn’t that deterministic I suppose.
- mcpherrinm 6y ago
  I don't think it's about getting 1ms execution time: It's more like having 300ms vs 301ms execution time be very similar in cost (or however the rounding worked). The firecracker microvm says startup time is under 125ms, but I have not personally done any benchmarking, though my employer does use firecracker for hosting our CI builders.
  - nhoughto 6y ago
    Ah yeah makes sense. Really interesting that cf workers limit you to 50ms cpu time rather than wallclock time, makes lots of send-then-wait scenarios possible/way cheaper.
    - qwtel 6y ago
      actually there appears to be a limit to this. i’ve never been able to perform more than ~50 http requests per invocation, leading me to believe that they are “billed” with 1ms cpu time.
      - nhoughto 6y ago
        Yeah it’s not _just_ 50ms cpu, there are other constraints like 50 sub requests, 6 open connections etc. Still faaairly generous, good luck getting 50 sub requests done in 50ms if you had to measure against wallclock =)
urda 6y ago
Time to get to work on that link shortener I've been wanting to build ha ha.

258 points by mpweiher 6y ago

deleted 6y ago

[deleted]

> This will lower the price for most Lambda@Edge functions Isn't this guaranteed to lower the price for *all* Lambda@Edge functions? What is the case where it wouldn't result is a <= cost?

cthalupa 6y ago
If the function still runs in a time evenly divisible by 50ms, the price will remain the same.
- happytoexplain 6y ago
  More specifically, if it stops anywhere between 49ms and 50ms in each 50ms chunk. So the price would be the same in 2% of executions, I suppose. Edit: Assuming even distribution of run times within each 50ms chunk - I guess maybe that's a bad assumption.
  - paxys 6y ago
    That assumes the runtime is evenly distributed, which is probably not the case. But still yeah, there will be some functions that end exactly in multiples of 50ms.
- nrmitchi 6y ago
  Ya, you're right. I interpretted the statement as "for some use cases the price might go up", which was a poor interpretation.
- tclancy 6y ago
  Shout out to the person running `sleep(0.005)` just to make the point.
paxys 6y ago
Normally such announcements are coupled with an increase in per-unit price. Not sure if that is the case here though.
- jen20 6y ago
  > Normally such announcements are coupled with an increase in per-unit price. Are there any examples of AWS ever having done this? Personally I don't recall any, but would be interested to know!
  - lostcolony 6y ago
    Yeah; citation needed. I've never seen an instance of a price increase. I can find multiple forums of people claiming Amazon has never increased prices. The only instance I can find of any cloud provider increasing prices was once in 2015 when Microsoft did in Europe...and while that led to a flurry of "cloud providers are going to increase prices" blog posts and things, calmer heads noted the exchange rates as the likely reason (and, certainly, the claims that prices would increase across the board never came to pass).
    - watermelon0 6y ago
      I remember Google starting to charge for managed Kubernetes clusters a year or two ago, I think the cost went from 0 to 75$ per month.
      - temp667 6y ago
        Google has raised prices on all sorts of things - I think AWS is one with rep for not raising prices. Maps API's I think went up pretty big time on google side.
        akiselev 6y ago
        > Maps API's I think went up pretty big time on google side. There were even several posts on HN around that time period of personal projects (maybe even companies) going under because of the price change.

logicslave 6y ago

AWS further squeezing out the competition

jacurtis 6y ago

This is awesome news. I would expect that we would probably see normal Lambda functions eventually follow suit to the 1ms pricing model, or at the very least, something like 10ms incremenets. For those who aren't super familiar with AWS, this announcement only covers "Lamda@Edge", this isn't the "normal" Lamda serverless function service. These are Lamda functions running at AWS Edge Locations, which are hundreds of CDN endpoints around the world. Lamda@Edge have various restrictions on what they can do, compared to the main Lambda service. They can only be triggered by CloudFront (AWS' CDN service). You could think of them as a "lite" version of Lambda. They are generally used for basic tasks like renaming/manipulating HTTP headers coming into the CDN. So they tend to run in just a few milliseconds. Normal Lambda are currently billed in 100ms increments. But it would be great to see this come down. I run a few Lambda functions that take < 10ms to run and it would be nice to be able to get 10x the invocations than I am getting on them now because I have to pay the 100ms rate for a 10ms invocation. Granted its all so cheap, even at scale, that its hard to complain too much.

stickydink 6y ago
I think that changed a while ago - regular lambda functions being billed per millisecond? This is Lambda@Edge catching up.
dastbe 6y ago
> Normal Lambda are currently billed in 100ms increments. Lambda actually reduced their billing granularity to 1ms at Re:invent 2020. if anything, Lambda Edge is trailing :).
byefruit 6y ago
https://aws.amazon.com/blogs/aws/new-for-aws-lambda-1ms-billing-granularity-adds-cost-savings/ https://aws.amazon.com/blogs/aws/new-for-aws-lambda-1ms-bill... Been 1ms for a few months now. =)
maddyboo 6y ago
So Lambda@Edge is basically the equivalent of Cloudflare workers?

isoprophlex 6y ago

> Lightweight functions such as header manipulations or URL rewrites tend to have a short duration I'm not knowledgeable AT ALL in this area, having never used or first-hand seen these FAAS things. But header manipulation? Really... These are executed as aws lambdas?! I don't get why you'd ever need to do this. (Not being facetious, honest puzzlement!)

turtlebits 6y ago
What would you propose? Yet another AWS service for the specific use case?
- hamandcheese 6y ago
  Config of some sort maybe? If you can do it in nginx, seems like it should be possible without invoking a lambda.
  - njitbew 6y ago
    I don't understand what nginx has to do with this. nginx's language is just that: a language. If Lambda@Edge would support nginx language, you would still be invoking a lambda. But I'd must rather write some header rewriting code in, say, JavaScript than nginx's language. Then why a (Turing-complete) programming language and not a config language? Simple: because a programming language gives you infinite more power than what any config system could ever provide. E.g. I could compare the origin IP, determine the country, and change the response based on that. And there are plenty of use cases like this which you cannot express in a config language.
    - jfrunyon 6y ago
      > E.g. I could compare the origin IP, determine the country, and change the response based on that. And there are plenty of use cases like this which you cannot express in a config language. Well, you can do that in plenty of "config languages", including nginx[1]. The reason Lambda exists is that it's good for Amazon, because they can push all the costs of the logic back onto the customer. (It could also be good for the customer, in that whatever configuration Amazon might otherwise support could be limited.) [1] http://nginx.org/en/docs/http/ngx_http_geoip_module.html http://nginx.org/en/docs/http/ngx_http_geoip_module.html

Shadonototro 6y ago

not good for JIT'd languages haha, oust dotnet and JS bloat! Oracle was silent, but at least they invested in the right tech with GraalVM and their AOT compiler, as usual, Microsoft missed their chance

tclancy 6y ago
This reads like an incantation. For what, I don't know, but I fear it may unleash Cold Fusion upon us all.
- hobs 6y ago
  Just In Time needs time to warm up and so you'd assume would cost more to boot up and do work and shut down, Ahead Of Time does it... ahead of time.
- Shadonototro 6y ago
  My comment was flagged because people on hackernews doesn't know what is the definition of a JIT'd language? Or because i am spot on and some people got offended?
  - macintux 6y ago
    Or because it’s irrelevant. JIT languages are not going to be more expensive as a result of this; your cost can only go down, or stay the same.
    - Shadonototro 6y ago
      They can't profit from the duration billing change, lost opportunity to save money is the same as being more expensive
  - tclancy 6y ago
    We all knew what you said. It got flagged because it was not Just In Time.
  - 6y ago

manishsharan 6y ago

Has anyone replicated a sqllite db to Cloudfront cache and used that as an input to their Lambda@Edge ? I have been thinking about this for a while as it would avoid having cloudfront making a origin call to the backend server for db reads on data that does not change frequently. I am trying to figure out why this is a bad idea .

snissn 6y ago
do it! Years ago my team messed around with using lambdas to pull/push data from sqlite into s3 and it worked pretty well for certain regime sizes and workloads! Then we partitioned the data to filter out the slow zones into more robust/long running things like a job queue and postgres
jedberg 6y ago
Why not just include the sqlite DB as part of your lambda deployment package?
- diroussel 6y ago
  As long as you can fit it in your 1MB zip file, for viewer-request events. For origin-requests you get 50MB. See https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-limits.html#limits-lambda-at-edge https://docs.aws.amazon.com/AmazonCloudFront/latest/Develope...
  - deleted 6y ago
    [deleted]
  - jedberg 6y ago
    You only have five seconds to process the entire request. If your lambda has to make a request to download a sqlite database every time, and the process it, it probably needs to be small enough to fit into 1MB anyway.
    - freemium413 6y ago

holler 6y ago

This is great news! I'm using lambda@edge to server-side render an ember.js app using Fastboot (http://ember-fastboot.com/ http://ember-fastboot.com/), and lowering the cost is a real big win!

atonse 6y ago
Whoa didn’t know this was possible. What’s the overhead and average execution time?
- holler 6y ago
  There's some set up required and you have to essentially handle how to route the request, handle static files, compression, etc, but it's not _too_ bad. I've been meaning to do a write up on it and probably should, but feel free to check it out in action at the site I'm developing https://sqwok.im https://sqwok.im There's a fastboot meeting next week that should be good as well https://www.eventbrite.com/e/ember-fastboot-ssr-beyond-tickets-144468965565 https://www.eventbrite.com/e/ember-fastboot-ssr-beyond-ticke...
  - HatchedLake721 6y ago
    00:30am UK time, no love for European emberistas :(
    - holler 6y ago
      ah darn! well I'm sure they'll have a recap video! or let me know if you have any questions you'd like to ask, or ask in the fastboot chan on discord, or sqwok :D
glaucon 6y ago
This is interesting. I use ember but never fastboot. I've been looking at the deployment doco within the fastboot site. Is this along the lines of what you're using ? https://github.com/ember-fastboot/ember-cli-fastboot/tree/master/packages/fastboot-app-server https://github.com/ember-fastboot/ember-cli-fastboot/tree/ma... . Also, looking at your profile, is https://sqwok.im https://sqwok.im using that approach ? Thanks.

ta20200710 6y ago

Did lambda@edge finally move lambda function execution to the edge cloudfront POPs? For years it actually ran them in the closest AWS region.

nhoughto 6y ago

Interesting, we’re just about to put cloudflare workers in prod and find their approach much more flexible vs lambda@edge being possibly triggered four times at edge part of a request life cycle. But this could significantly reduce cost if your execution time is low. How likely are you to see 1ms execution times for this stuff tho? Super simple logic should be that low I guess.. They must have a very mature execution environment to be able to offer this (if 1ms execution is achievable), cf workers have a whole set to logic to average out cpu spikes so you don’t randomly hit the 50ms limit, bc their execution of your code isn’t that deterministic I suppose.

mcpherrinm 6y ago
I don't think it's about getting 1ms execution time: It's more like having 300ms vs 301ms execution time be very similar in cost (or however the rounding worked). The firecracker microvm says startup time is under 125ms, but I have not personally done any benchmarking, though my employer does use firecracker for hosting our CI builders.
- nhoughto 6y ago
  Ah yeah makes sense. Really interesting that cf workers limit you to 50ms cpu time rather than wallclock time, makes lots of send-then-wait scenarios possible/way cheaper.
  - qwtel 6y ago
    actually there appears to be a limit to this. i’ve never been able to perform more than ~50 http requests per invocation, leading me to believe that they are “billed” with 1ms cpu time.
    - nhoughto 6y ago
      Yeah it’s not _just_ 50ms cpu, there are other constraints like 50 sub requests, 6 open connections etc. Still faaairly generous, good luck getting 50 sub requests done in 50ms if you had to measure against wallclock =)

urda 6y ago

Time to get to work on that link shortener I've been wanting to build ha ha.