[HN Gopher] AWS Lambda Edge changes duration billing granularity...
___________________________________________________________________
AWS Lambda Edge changes duration billing granularity from 50ms down
to 1ms
Author : mpweiher
Score : 135 points
Date : 2021-04-09 15:58 UTC (7 hours ago)
(HTM) web link (aws.amazon.com)
(TXT) w3m dump (aws.amazon.com)
| isoprophlex wrote:
| > 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!)
| gehen88 wrote:
| We use Lambda@Edge to build our own CDN on top of S3 with
| authentication, so our customers have reliable, fast and secure
| data access. We use a bunch of edge lambdas which serve
| thousands of requests each minute, so I suspect we'll see a
| nice cost reduction with this.
|
| Some of the stuff we do: - rewrite urls - auth and permissions
| check - serve index.html on directory indexes - inject dynamic
| content in served html files - add CORS headers
| ts330 wrote:
| basic manipulation in CF is an absolute pita - so much overhead
| for simple things like clobbering a header value.
|
| but by allowing JS/whatever, it gives you an infinite landscape
| to work with the values in a language that a wide range of
| people grok.
|
| it's just a matter of getting a decent deployment setup so you
| can rinse and repeat easily.
|
| but i agree, it's a freaking jack hammer where most people need
| a small tack hammer.
| diroussel wrote:
| In AWS on the whole if there is any type of extension mechanism
| it's done via a lambda. Anything that needs an eval(), that is
| more than a regexp, is done via lambda.
|
| This makes lambda's the glue of AWS. The input events are small
| json values, and the outputs are json values, and you can
| (mostly) use any language you want.
| [deleted]
| turtlebits wrote:
| What would you propose? Yet another AWS service for the
| specific use case?
| hamandcheese wrote:
| Config of some sort maybe? If you can do it in nginx, seems
| like it should be possible without invoking a lambda.
| njitbew wrote:
| 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 wrote:
| > 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
| TheCoelacanth wrote:
| If you want a full-fledged reverse proxy, then you can run
| a full-fledged reverse proxy.
|
| Cloudfront is a CDN, it's not intended to be a replacement
| for nginx.
| luhn wrote:
| CloudFront should let you configure header injection for
| responses. Just a simple list of key-value pairs. I've seen
| it requested before, it's a feature a lot of people want.
| leesalminen wrote:
| I use Lambda@Edge to conditionally serve brotli compressed .js
| files based on the Accept request header from an S3 bucket.
| aeyes wrote:
| > These are executed as aws lambdas
|
| These are executed. Lambda is just a brand name. We did this 15
| years ago on hardware load balancers, proxy servers, cache
| servers etc
| jeffasinger wrote:
| Essentially this is a way to lets you push all of the weird
| feature requests your customers might have off into one place.
|
| From a customer point of view, maybe you need to rewrite the
| path based on the contents of a cookie, or maybe you want to
| shed certain types of requests in high load scenarios, or maybe
| there's a buggy upstream application that sends bad cache-
| control headers, or ...
|
| If the goal is to let the customer specify infinitely complex
| logic at the edge, a programming language is a good way to do
| that. Function As A Service is a good billing model for lots of
| invocations of short, small functions across the customers
| choice of language.
| thayne wrote:
| The unfortunate side effect is that Lambda@Edge at least adds
| quite a bit of latency that a simpler but less powerful rules
| based system for header manipulation probably wouldn't.
|
| We experimented with using Lambda@Edge for manipulating a
| header, but the added latency just wasn't worth it, and we
| had to come up with a different solution. That was years ago
| though, so maybe it is better now.
| nrmitchi wrote:
| > 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?
| paxys wrote:
| Normally such announcements are coupled with an increase in
| per-unit price. Not sure if that is the case here though.
| jen20 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| _> 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.
| temp667 wrote:
| Yeah - here's some coverage.
|
| https://geoawesomeness.com/developers-up-in-arms-over-
| google...
|
| That plus shutdowns of things - google is not most stable
| lostcolony wrote:
| That's fair, though I'd consider APIs to be a different
| beast than a cloud IaaS sort of thing. Maybe that's the
| distinction worth making, IaaS vs SaaS or similar. But
| fair point either way.
| ignoramous wrote:
| AWS has admitted under-pricing S3. A new bill item, # of
| requests served, was added _after_ launch.
|
| > _... When we launched S3, we were charging only for data
| transfer and data storage. It turned out that we had quite
| a few customers who were storing millions and millions of
| thumbnails of products they were selling on eBay. There was
| not much storage because these thumbnails were really
| small, and there wasn 't much data transfer either, but
| there were enormous numbers of requests. It made us learn,
| for example, when you design interfaces, and definitely
| those you charge for, you want to charge for what is
| driving your own cost. One of the costs that we didn't
| anticipate was the number of requests, and request
| handling. We added this later to the payment model in S3,
| but it was clearly something we didn't anticipate. Services
| that came after S3 have been able to learn the lessons from
| S3 itself._
|
| Ref:
| https://m-cacm.acm.org/magazines/2021/3/250706-a-second-
| conv...
| jen20 wrote:
| Thanks - that's a good example!
| sigstoat wrote:
| i wish someone would make a financial derivative of cloud
| provider pricing. i'd like to make money off of all of these
| folks who are convinced AWS is going to raise prices, any day
| now.
| starfallg wrote:
| Why would AWS want to raise prices when it is already the
| most expensive major public cloud provider?
| jjav wrote:
| Given how brutally expensive AWS is, I'd say that day is
| long past.
| TheCoelacanth wrote:
| AWS is quite expensive, but I don't think they actually
| raise prices much if ever. At worst, they just don't
| lower prices as quickly as Moore's law decreases their
| costs.
| cthalupa wrote:
| If the function still runs in a time evenly divisible by 50ms,
| the price will remain the same.
| tclancy wrote:
| Shout out to the person running `sleep(0.005)` just to make
| the point.
| happytoexplain wrote:
| 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 wrote:
| 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 wrote:
| Ya, you're right. I interpretted the statement as "for some
| use cases the price might go up", which was a poor
| interpretation.
| manishsharan wrote:
| 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 wrote:
| 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
| ignoramous wrote:
| We replicate sharded, versioned, csv-files on-demand from S3 to
| Cloudflare edge for code run by workers.dev.
|
| Cache invalidation is tricky. Avoid it by ttl-expiring caches
| as frequently as budget allows. We, instead, employ a (probably
| over-engineered) hand-rolled set-reconciliation algorithm to
| match our read/write patterns.
| jedberg wrote:
| Why not just include the sqlite DB as part of your lambda
| deployment package?
| diroussel wrote:
| 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/Develope...
| [deleted]
| jedberg wrote:
| 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.
| recuter wrote:
| I'm playing around with just that.
|
| Regular Lambda (not edge) are just container images up to 10
| GB in size.
|
| There's also the layers thing. A function can use up to five
| layers at a time. The total unzipped size of the function and
| all layers can't exceed the unzipped deployment package size
| limit of 250 MB. Can update separately from the container,
| almost as fast as a regular fs.
|
| And finally it has access to EFS which is faster than S3.
| Shadonototro wrote:
| 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 wrote:
| This reads like an incantation. For what, I don't know, but I
| fear it may unleash Cold Fusion upon us all.
| Shadonototro wrote:
| 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 wrote:
| 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 wrote:
| They can't profit from the duration billing change, lost
| opportunity to save money is the same as being more
| expensive
| hobs wrote:
| 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.
| holler wrote:
| This is great news! I'm using lambda@edge to server-side render
| an ember.js app using Fastboot (http://ember-fastboot.com/), and
| lowering the cost is a real big win!
| [deleted]
| jacurtis wrote:
| 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.
| maddyboo wrote:
| So Lambda@Edge is basically the equivalent of Cloudflare
| workers?
| rstupek wrote:
| Or cloudflare workers are basically the equity of Lambda@Edge
| since it predates workers
| njitbew wrote:
| Sounds like it. Which in turn is similar to Akamai EdgeWorker
| (Akamai's JavaScript-at-the-edge)
| damsta wrote:
| Regular Lambdas use 1ms billing since 1st December of last
| year. https://aws.amazon.com/blogs/aws/new-for-aws-lambda-1ms-
| bill...
| stickydink wrote:
| I think that changed a while ago - regular lambda functions
| being billed per millisecond? This is Lambda@Edge catching up.
| dastbe wrote:
| > 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 wrote:
| https://aws.amazon.com/blogs/aws/new-for-aws-lambda-1ms-bill...
|
| Been 1ms for a few months now. =)
| logicslave wrote:
| AWS further squeezing out the competition
___________________________________________________________________
(page generated 2021-04-09 23:00 UTC)