AWS Lambda Edge changes duration billing granularity from 50ms down to 1ms | Hacker News Reader

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

aws.amazon.com

258 pointsmpweiher103 comments

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.

I think that changed a while ago - regular lambda functions being billed per millisecond? This is Lambda@Edge catching up.

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

https://aws.amazon.com/blogs/aws/new-for-aws-lambda-1ms-bill...

Been 1ms for a few months now. =)

So Lambda@Edge is basically the equivalent of Cloudflare workers?

Or cloudflare workers are basically the equity of Lambda@Edge since it predates workers

Workers is wayyyy cheaper if you don't call into on other Intra AZ AWS deps: https://medium.com/@zackbloom/serverless-pricing-and-costs-a...

For instance, Cloudflare throws in fair-use bandwidth and its cache for free, while there's also no need to setup an API Gateway to serve http reqs (if forwarding http is all you're doing with apigw).

Sounds like it. Which in turn is similar to Akamai EdgeWorker (Akamai's JavaScript-at-the-edge)

Regular Lambdas use 1ms billing since 1st December of last year. https://aws.amazon.com/blogs/aws/new-for-aws-lambda-1ms-bill...

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

What would you propose? Yet another AWS service for the specific use case?

Config of some sort maybe? If you can do it in nginx, seems like it should be possible without invoking a lambda.

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.

> 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

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.

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.

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.

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.

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.

I use Lambda@Edge to conditionally serve brotli compressed .js files based on the Accept request header from an S3 bucket.

Cloudfront now has native brotli support

That’s good to know, thanks!

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

Can I ask how you're injecting dynamic content in served html files? My understanding was that lambda@edge functions could not modify the origin response body.

> When you’re working with the HTTP response, Lambda@Edge does not expose the body that is returned by the origin server to the origin-response trigger. You can generate a static content body by setting it to the desired value, or remove the body inside the function by setting the value to be empty. If you don’t update the body field in your function, the original body returned by the origin server is returned back to viewer.

https://docs.aws.amazon.com/AmazonCloudFront/latest/Develope...

It sounds to me like they might be creating the response from scratch rather than modifying an existing one. And since they’re talking about serving data from s3, maybe it’s just a nicely formatted version of aws s3 ls?

We use S3.getObject to fetch it and create a custom response.

Isn't it expensive in terms of egress?

I'm not sure what you're specifically referring to by egress, but data transfer from S3/EC2/ELB etc to CloudFront is free:

> If you are using an AWS origin, effective December 1, 2014, data transferred from origin to edge locations (Amazon CloudFront "origin fetches") will be free of charge.

And in general data out from CloudFront ($0.085 to $0.02 in NA & EU) is cheaper than data out from S3 ($0.09 to $0.05 in us-east-2). For the lambda@Edge portion it's $0.60 per 1 million requests while the CloudFront requests are $0.75 to $1.00 per 1 million requests.

Those are public on demand rates and any customers with significant or consistent usage should definitely contact AWS for lower committed/custom prices.

Edit: Disclaimer I'm a principal at AWS, and in the past spent significant time working on CloudFront & Lambda@Edge, but all of the above is public information.

> 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

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.

If you have stuff in a global CDN, wouldn't you want a global compute system too? This is literally what lambda@edge is for

It's funny our team literally just last week did something like this at ___ BigCorp. We need to verify a JWT signature from a new 3rd party provider and then append a secure auth token that is accepted by the backend service. Couldn't this just be done in the backend service? Why yes it definitely could. But apparently there are rigid security policies in place, and this stuff appears to have been carved in stone and approved by SOC2 auditors and lawyers and regulators or whatever and they have agreed that the backend gateway would use X specific formats for authentication and nobody can make any exceptions. So instead our team is spinning up an ad-hoc lambda function attached to cloudfront which will use none of our usual tooling & frameworks and have zero visibility for our security teams and be full of whatever soon to be out of date 3rd party js dependencies we need, all in the name of security so that we can pretend that the API we're communicating with is using our approved auth token format when they aren't. Just another day at a big company, really.

I mean a less cynical reading is that this is like nginx handling https->wsgi for your Python application. You can deal with a unification of your auth stack and not have application development be disrupted

I would not call it cynical. Rather naming things for what they are.

Oh hi. I see you work for one of my clients.

Interesting, and that actually makes (some sort of) sense. Thanks..!

We use Lambda@Edge so we can access Cloudfront’s true client IP value as well as geo data and pass it on to the origin

But cloudfront already sends that original ip back in a standard header.

Yeah and you can ask Cloudfront to add some geodata as well (with headers such as CloudFront-Viewer-Country, etc)

It's especially useful for doing things during the Origin Request phase, which happens prior to the request from the CDN to the Origin.

In that phase you can change anything about the request itself, or the origin it will connect to. But the function only needs to run when there's a cache miss.

I have an application that needs to select an origin based on the request path (too many to use CloudFront cache behaviours), with a cache miss rate of less than 1%. It's a tiny amount of additional latency for cache misses, and a very small proportion of our CDN costs per month.

Varnish Cache with VCL allows you to create custom edge logic for things like header manipulation or backend selection.

Are you suggesting I build and maintain my own global CDN with 200+ edge locations? Thank you, but no thank you.

I think so, as an alternative to all this AWS magic you could totally deploy <insert open source software name> on 200+ newly deployed instances, colo servers, or whatever you like!

I caught it too. I get downvoted a lot for not following rules and I don’t really care this was hilarious

cloud magic has shown us that “one day” we will need to scale up to an extreme count of “instances” and that suboptimal solutions can be negated with horizontal scaling.

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 .

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

Why not just include the sqlite DB as part of your lambda deployment package?

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

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.

AWS Lambdas can run up to 15 minutes actually

Lambda functions running @Edge have different limits compared to vanilla AWS Lambda. You get 30 seconds to respond if it's on a cache miss (Origin Request/Response), or 5 seconds if it's on a cache hit (Viewer Request/Response): https://docs.aws.amazon.com/AmazonCloudFront/latest/Develope...

Lambda (at least the non-@edge version) comes with 512MiB of /tmp directory storage

And "The same Lambda execution environment may be reused by multiple Lambda invocations to optimize performance. The /tmp area is preserved for the lifetime of the execution environment and provides a transient cache for data between invocations. Each time a new execution environment is created, this area is deleted."

https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-...

https://aws.amazon.com/blogs/compute/choosing-between-aws-la...

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.

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.

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.

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.

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.

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.

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

> ... find their approach much more flexible vs lambda@edge being possibly triggered four times at edge part of a request life cycle.

The lamda@edge function is executed only once but you decide when - before or after the cache and either on the request or response.

So if I want to hook into each 4 parts of the lifecycle, I configure that and it gets executed once?

Can I maintain state between inbound request->origin request->origin response->inbound response?

My understanding was you can’t and it got called 4 times with different events, workers solves this by you being responsible for making the origin request (there is a simple mode where it does it for you to) with promises to manage origin response and inbound response logic.. I thought lambda@edge didn’t work like that?

For each lambda function you specify which one of the 4 places it is called. So effectively be 4 different lambda functions, triggered independently (they could ofcourse share code).

If you wanted to maintain state then I'd guess the easiest (only?) way is for the function to add headers to the HTTP request/response as it passed through.

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!

Whoa didn’t know this was possible. What’s the overhead and average execution time?

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

There's a fastboot meeting next week that should be good as well https://www.eventbrite.com/e/ember-fastboot-ssr-beyond-ticke...

00:30am UK time, no love for European emberistas :(

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

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/ma... . Also, looking at your profile, is https://sqwok.im using that approach ? Thanks.

I'm not using the fastboot-app-server, which currently uses express and requires you to have that set up for your app, but it's the most common path. Using lambda@edge is slightly different in that I'm relying on the cdn to render the page once and then cache it for subsequent requests w/o requiring a node server.

Yep Sqwok is rendered with fastboot (mostly used for the post page seo/rich preview) Feel free to ping me @guac or ask a question and I'll respond, and also there is a fastboot meeting next week that I'll be at and it should be interesting! The fastboot team has been working on some really cool stuff.

https://www.eventbrite.com/e/ember-fastboot-ssr-beyond-ticke...

Interesting, thanks. I've signed up for the meeting so cross-fingers I'll be there.

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

If the function still runs in a time evenly divisible by 50ms, the price will remain the same.

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.

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.

Ya, you're right. I interpretted the statement as "for some use cases the price might go up", which was a poor interpretation.

Shout out to the person running `sleep(0.005)` just to make the point.

Normally such announcements are coupled with an increase in per-unit price. Not sure if that is the case here though.

> 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!

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

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.

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.

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

Yeah - here's some coverage.

https://geoawesomeness.com/developers-up-in-arms-over-google...

That plus shutdowns of things - google is not most stable

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.

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

Thanks - that's a good example!

I'm sure they made up for it charging data transfer x100.

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.

Why would AWS want to raise prices when it is already the most expensive major public cloud provider?

Given how brutally expensive AWS is, I'd say that day is long past.

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.

> At worst, they just don't lower prices as quickly as Moore's law decreases their costs.

From a financial perspective, isn't this basically raising prices over time?

No, just increasing gross profit over time.

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

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

AWS further squeezing out the competition

Reply on news.ycombinator.com