[HN Gopher] AWS Lambda Function URLs: Built-In HTTPS Endpoints f...
___________________________________________________________________
AWS Lambda Function URLs: Built-In HTTPS Endpoints for Lambda
Author : vvoyer
Score : 138 points
Date : 2022-04-06 21:07 UTC (1 hours ago)
(HTM) web link (aws.amazon.com)
(TXT) w3m dump (aws.amazon.com)
| ankit70 wrote:
| How is it different than cloudflare workers?
| ignoramous wrote:
| Cloudflare Workers is head and shoulders above AWS CloudFront
| Functions and Lambda@Edge [0], if you can fit your workloads in
| 50ms (CPU time) or 30ms (IO time). Workers is wayy cheaper,
| wayy faster [1].
|
| Workers has 1MB script size limit (post compression), so that's
| there, too, and can run WASM or JS workloads (which CloudFront
| Functions can't, but Lambda@Edge can).
|
| As for AWS Lambda Function URLs: Well, it isn't comparable to
| Workers at all. But if my use case fits Workers, then that's
| what I'd would prefer. In fact, I've gone many lengths to make
| my workload fit Workers. Deno Deploy is another viable
| alternative.
|
| [0]
| https://docs.aws.amazon.com/AmazonCloudFront/latest/Develope...
|
| [1] dated, but relevant:
| https://medium.com/@zackbloom/serverless-pricing-and-costs-a...
| vlovich123 wrote:
| Just some small corrections. I think you mean 30s of CPU time
| for unbound workers? Time spent waiting for i/o can be
| "infinite". I think maybe you're referring to billing where
| we bill on wall clock time for unbound workers (vs CPU time
| for bundled workers). For proxied requests, billing even
| stops once you hand back the Response object.
|
| If you need more than 1MB of script size, please reach out to
| Cloudflare support.
| wnevets wrote:
| finally. Having to setup a gateway is so cumbersome.
| scoot wrote:
| Claudia.js is an absolute godsend when it comes to writing and
| deploying Lambda functions. Can't recommend it highly enough:
| https://www.claudiajs.com/
| petercooper wrote:
| Very pleased by this addition! :-) Note that it creates special
| .on.aws URLs so if you want to use your own domain to future
| proof the endpoint (against linkrot if you ever leave AWS, say)
| you'll want to set up a redirect/proxy for yourself (whereas API
| Gateway does custom domains).
|
| Also an interesting note from the docs about how said URL is
| generated: _" Because this process is deterministic, it may be
| possible for anyone to retrieve your account ID from the <url-
| id>."_ I don't know how much of a problem this could be, but it's
| worth being aware of.
| spyspy wrote:
| I believe this is why GCP added random hashes to their Cloud
| Run URLs whereas AppeEngine gave you a deterministic one e.g.
| https://{serviceID}-dot-{projectID}.appspot.com
| alexhf wrote:
| In my opinion, AWS account IDs are not sensitive information.
| chc wrote:
| Yeah, account IDs aren't actually publicly listed, but should
| be treated as such. No part of your security should rest on
| an AWS account ID staying secret.
| sorry_outta_gas wrote:
| they are useful for social engineering and phishing
| euph0ria wrote:
| Is it possible to front this with your own domain using a CNAME
| or are the function URLs dynamically genrerated on each
| commit/upload/build?
| aeyes wrote:
| You can't use your own domain/certificate. If you CNAME it the
| cert will be invalid.
| JoshTriplett wrote:
| It sounds like you can get a stable URL for a function, but
| it'll still be a Lambda URL.
|
| I'd love to use this with a custom domain, without having to
| use an API Gateway.
| nl wrote:
| How is it that my UX looks completely different to the blog post?
|
| I don't have advanced settings. Instead I have to go
| "Configuration->Function URL" to find this.
| epolanski wrote:
| I'm confused, the whole news is that you can directly call
| lambdas without having to go through API gateway, like you do on
| cloudflare?
| justin_oaks wrote:
| Yes, that's the whole news. It's exciting to those of us who
| had to live without that feature until now.
| pojzon wrote:
| Are those function urls backed by WAF and AWS Shield ?
|
| If not -> get prepared for huge bill of ddosed function
| invocations.
|
| I hope we can at least attach something to those urls.
| zozbot234 wrote:
| AWS Lambda has now gone full PHP. Never go full PHP.
| mnapoli wrote:
| Last step: https://bref.sh
| joeframbach wrote:
| Not sure I understand what you mean, can you elaborate?
| russtrotter wrote:
| Reference to the movie quote in "Tropic Thunder" from Robert
| Downey Jr.s character.
| supahfly_remix wrote:
| Is this similar to a cgi-bin script?
| tyingq wrote:
| Closer to fastcgi, but yes.
| cobertos wrote:
| Now if only you could add an EIP to a lambda function without a
| VPC NAT and the $20/mo minimum that comes with it.
| azth wrote:
| Can anyone using lambda at scale pitch in regarding costs? It
| seems companies are using it to build pipelines which could be
| much cheaper by writing full services as opposed to small
| functions that you pay for per invocation.
| rmbyrro wrote:
| Doesn't have a universal answer.
|
| Lambda doesn't charge for idle time or capacity, for example.
| Depending on your usage patterns and availability requirements,
| you may have a high cost in idle waste when using servers.
|
| But I think where Lambda really shines is removing time from
| infra setup, maintenance, etc. These are _hidden_ costs and,
| even when accounted for, frequently underestimated.
|
| If you need even a part time DevOps or SRE engineer to make
| sure you'll keep things running smooth or will recover fast
| from a disaster, their salary alone already pays for shitloads
| of Lambda invocation and compute time.
| jjtheblunt wrote:
| > already pays for
|
| huge understatement even as written :)
| scrose wrote:
| Don't you need an SRE or Devops focused person regardless?
|
| You still need a way to test and deploy the code your
| pushing. You also need to set up logging and networking that
| ties it into the rest of your systems
| xsmasher wrote:
| I use lambdas for nearly everything at a games startup. The
| "Serverless framework" - https://www.serverless.com - has
| built-in concepts of dev/stage/prod and routing from URLs
| -> function etc. Logging goes to cloudfront but you could
| use any login library you wanted inside your functions.
|
| We don't have an operations team, so each dev deploys their
| own services; this framework gives them all a consistent
| interface so we know how to test or deploy someone else's
| code.
|
| Advantages from my POV: * zero or
| simplified ops; no load balancer setup etc. * we
| don't pay for idle hardware * scales well by default
| (built with parallelism in mind)
|
| If a certain game spikes in popularity then it COULD become
| expensive - but IMO that's better default behavior than a
| server falling over.
| Richard_Grant wrote:
| Xsmasher,
|
| Would you be interested in sharing your Serverless Story
| with our Serverless community? We are looking for guest
| blog contributors, community call showcases and case-
| studies.
|
| Please fill out the form in the link below and I will
| follow up with you! https://formfacade.com/public/1122520
| 76977537904120/all/form...
|
| Cheers!
| uuyi wrote:
| Remember you don't pay for invocations. You pay for memory,
| latency and traffic.
|
| That constrains how you build architectures with lambda.
| Anything bloated or written in low efficiency languages, or
| does any amount of compute or latent network traffic will burn
| you. That includes dealing with slow clients and synchronous
| APIs.
|
| As for rules, there aren't really any catch-all ones. We build
| out on Kubernetes now though as that's portable. The lambda
| developer story is quite horrible and that's where our cost is.
| 015a wrote:
| I'm fairly certain you do pay per invocation; $0.20/million.
| Its not the bulk of the cost for sure but its non-zero
| nonetheless.
| uuyi wrote:
| Yes that's the point. The marketing points to that as the
| big cost but it's insignificant compared to the real cost
| which is running workloads on it that aren't optimised for
| price first. Which is probably most of them from
| experience.
|
| Then again that's how Bezos rolls.
| killingtime74 wrote:
| You can always start with a lambda then move to its own service
| if costs justify. Develop as a Docker and there's minimal if
| any conversion work
| renewiltord wrote:
| If you use the Go runtime, you can also trivially wrap in a
| Docker later and your iteration will be faster.
| itisit wrote:
| It's best to do the math in advance, but not everyone is
| willing to put in the time required for a proper business case.
| ddoolin wrote:
| It all depends. Cost-wise, Lambda is the only real option for
| running tens of thousands of Monte Carlo-style simulations at
| once (which require high performance for a very short execution
| time). Containers are too slow to scale up for our target time,
| and if using regular instances, they'd need to be always-on
| which costs a ton for the performance tier we'd need.
|
| With Rust on Lambda we found a good mix of start time and
| parallelism of each that made it much cheaper and faster.
|
| EDIT: The workload times are only somewhat predictable so even
| doing something like scheduled scaling is a half-solution.
| semi-extrinsic wrote:
| You're doing whatnow??
|
| This may come off as arrogant, but it sounds like something
| that could be rewritten in Fortran to run on an old laptop
| with similar execution time.
| thamer wrote:
| An engineering blog from the BBC published an update a few days
| ago on their migration to a serverless architecture, titled
| "BBC Online - A year with serverless": https://medium.com/bbc-
| design-engineering/bbc-online-a-year-...
|
| They report 3.3B function invocations for 2.3B requests served,
| a total of 61,000 hours of execution time and 1,500 concurrent
| executions at peak.
|
| Using calculator.aws, simply entering the number of requests at
| 67ms each (61k hours/3.3B invocations) with 128 MB of memory
| each costs only $1,107.
|
| Then of course there's bandwidth, databases, file storage, and
| a lot more... but 3.3B lambda executions for $1.1k is really
| cheap. Not to mention that a client like the BBC would benefit
| from negotiated pricing with significant discounts. Even
| without discounts, serverless is often pretty cheap.
| outsb wrote:
| The CPU throttling of the lower memory settings is often
| easily visible in a user-facing request, even simple requests
| just doing some DB IO. I rarely use less than 1024mb for
| anything
|
| edit: the BBC review is horrifying:
|
| > The page takes around 500ms to render and be delivered to
| the audience. In that timeframe we invoke around 30
| functions. Around 150ms is spent running React to render the
| content to HTML
|
| > we aim to personalise almost every page in some way --
| making it relevant for every user on every request
|
| Good luck making perf numbers with all those cold cached
| personalized pages
| recuter wrote:
| You can certainly run a web server capable of 1,500
| concurrent connections for under $100/mo.
|
| Run it on Linode or something, they'll throw in 10TB of
| bandwidth which probably covers it.
|
| Most of the serving is done by the CDN..
| renewiltord wrote:
| Right, but once you're in the territory of "everything for
| $100" or "everything for $1000", they're both the same so
| you want the thing with the organizational efficiencies of
| independent deploys and permissioning, resilience and
| scaling, high availability etc.
| recuter wrote:
| Two $60 Linodes in different data centers are highly
| availablish considering each one could easily do x10
| those numbers. The thing in the link sits behind a CDN.
|
| Certain kinds of organizational efficiencies frequently
| lead to "I'm bored lets use the new hotness that would
| look good on my resume for the next job", hence lambda.
|
| Actually you don't need anything at all, this is a job
| completely for the CDN which has enough features they
| aren't using to do the same thing for no additional cost.
| renewiltord wrote:
| Hmm, I don't think that's the primary motivation. But the
| NomadList guy runs everything on one VPS and he makes
| $2m/yr so more power to you guys. I wouldn't do it
| because I'd want to be able to scale the team and keep
| their velocity high and I think clearer process-impact
| boundaries help.
|
| For what's it worth, I've worked in Ad Tech at 2 m qps
| and now in HFT so I'm not averse to efficiency, but org
| efficiency is (in my experience) very important if you're
| scaling the company to the $100+ m revenue range.
| recuter wrote:
| I think if you're scaling the company to the $100+ m
| revenue range you'll be able to find a team that can
| handle either VPS, Lambdas, both or whatever else is
| required.
|
| It really depends on what it is that you're actually, you
| know, doing.
| throwaway2016a wrote:
| I use Lambda heavily, especially in new projects that haven't
| been proven yet. The cost savings are significant for two
| reasons:
|
| - Easier to maintain so less hours spent handling things like
| deployment and autoscaling. Payroll is likely the company's top
| expense so this is not insignificant.
|
| - If the traffic is sporadic or unpredictable you have 100%
| efficient resource utilization, which is very difficult with
| traditional servers.
|
| I have some microservices that would cost $10 per AZ /
| datacenter per month (so at least three to have High
| Availability) that cost effectively $0 per month on lambda.
|
| At scale, it depends on how consistent your load is. If it is
| highly consistent a server may make sense. But even for high
| traffic apps the cost can be lower or -- if it is higher -- so
| negligibly higher that the saved maintenance cost pays for it.
|
| I have many projects on Lambda, but for example: I run an
| entire small-startup of mine for < $1 per month and have high
| availability. The number of hours I would need to spend to get
| the cost that low would be way too expensive.
| htunnicliff wrote:
| Care to share more about your small startup?
| throwaway2016a wrote:
| Well, I'd love to share specifics but I've kept
| "throwaway2016a" anonymous for 6 years so gonna keep it
| that way :).
|
| But some general info:
|
| - API based product
|
| - Frontend using Next.js hosted on S3 behind CloudFront
| with some CloudFront Edge functions
|
| - Gets a few hundred thousand API calls a month
|
| - I wrote my non-edge Lambdas in Go. I found it to be much
| faster cold start times (about 100ms for me) and much
| faster runtime (< 10ms) than Node. The Edge functions are
| Node though because Edge on AWS only supports the Node.js
| runtime.
|
| - I use DynamoDB for my database.
|
| You get billed for what you use on Lambda and on average a
| single API call bills me for 8 - 12ms each. Plus the cost
| of API gateway. Actual response time is higher since SSL
| negotiation and API Gateway adds overhead but it's usually
| < 80 - 100ms which is within my SLA.
|
| But could scale up to a few million API calls a month
| without much added cost... about 20 - 30 million API calls
| per month before I hit the cost of the (minimum) 3 servers
| + load balancer I would need to do High Availability using
| servers.
| cbsmith wrote:
| > If the traffic is sporadic or unpredictable you have 100%
| efficient resource utilization, which is very difficult with
| traditional servers.
|
| "100% efficient resource utilization" is a bit over stating
| it, but it sure is a lot easier to ensure you don't over
| provision.
| throwaway2016a wrote:
| Very fair point. You probably won't be saturating your
| lambda RAM and CPU.
|
| But the granularity is much finer with Lambda so you're
| closer to full efficiency. No having a server with Gigs of
| RAM and multi-cores sitting around for hours a day with 10%
| utilization.
| oblio wrote:
| > If it is highly consistent a server may make sense.
|
| I'd argue that you should just package and deploy your Lambda
| as a Docker image and when you need consistency head over to
| Fargate. It's costs are reasonably comparable with EC2 and
| you get rid of most Lambda limitations.
| throwaway2016a wrote:
| Very good point that the Lambda code can be written in such
| a way that it can run from both Docker and Lambda.
|
| But I'm not a fan of Fargate. I find it easier to use
| vanilla EC2, and it's cheaper than Fargate. But I'm also
| very comfortable with EC2 and Fargate takes care of a lot
| of the ops stuff so to each their own.
|
| What I didn't mention too is Lambda has "Reserved
| Concurrency" pricing which for extremely consistent
| workloads lowers the gap... I've never had a product with
| that consistent a workload though.
| discodave wrote:
| I've never seen (healthy) fleets with _average_ CPU utilization
| above 70-80%. That includes several-thousand machine fleets
| when I worked at Amazon. Most things I 've seen in my career
| have 10-20% utilization at best. The Lambda "premium" over EC2
| is only like 30-50%, so unless your workload is super
| consistent/predictable, and your code/hardware is well
| optimized, then Lambda will likely win on price. This is even
| more true now that you don't have to pay for API Gateway.
| buzzdenver wrote:
| This is relevant for CPU bound loads. Lots of lambdas do
| networking stuff where 90+% of the time is waiting for an
| HTTP download.
| recuter wrote:
| I have. AdTech frequently runs close to 100%. Cryptomining
| style.
|
| I'm not sure I agree, why Lambda and not AWS spot instances?
| Or heaven forbid, one beefy server / office warmer.
|
| Lambda doesn't win on price it wins on flexibility.
| recuter wrote:
| Well enterprises that build pipelines often end up with Rube
| Goldberg type horrors regardless, and Lambda is more easy and
| fun to prototype with than say, Spark. If you know someone like
| that wait until they click around and find "step functions".
|
| There are more legit use cases. Lets say you are in charge of
| Eurovision.
|
| You spike from 0 to xxx,xxx of votes on an irregular basis
| during a few nights a year.
|
| You run an auction or ticket sales website of some sort.
|
| Your blog gets 3 clicks a month except for when you actually
| post something and it briefly gets noticed by HN.
| StratusBen wrote:
| We aren't a company that uses Lambda at scale but we have
| exposure to a few thousand AWS customers' cloud costs and I
| definitely say that the customers who are all-in using Lambda
| are saving a lot of money relative to their container/EC2
| counterparts. That being said, I see _very_ few companies "all
| in" on Lambda these days at an organizational level. It's still
| the exception - I think you need to be very intentional with
| its use at an organizational level architecture wise...but I
| see a lot of companies with sprinkles of Lambda usage here and
| there.
|
| Source/Disclosure: I am Co-Founder and CEO at
| https://www.vantage.sh/ - a cloud cost platform tracking in the
| hundreds of millions of dollars of annualized cloud spend.
| cameronh90 wrote:
| Off topic/feedback: I like the look of your service and it's
| something I've been thinking about looking into recently. I
| have even used the EC2 instance type list a ton without ever
| realising that it was attached to your site.
|
| However, I'm afraid that I sadly would not touch your
| service, because SSO is only on your enterprise plan. I hope
| that eventually you might consider putting SSO on one of the
| priced tiers.
|
| (https://sso.tax/ approximates my opinion)
| StratusBen wrote:
| Thanks for that feedback.
|
| I've mentioned this publicly before on HN: we are happy to
| offer anyone SAML SSO even if you fit into our Pro/Business
| tiers. We have configured "Enterprise" tiers for folks
| below $200/month and it is no sweat on our end. It just
| takes some pre-provisioning on our end that usually comes
| with more direct engagements with Enterprise customers.
|
| Anecdotally, typically _very_ few customers in the self-
| service tiers make mention of this. It's something we need
| to message better on our marketing site but for onlookers
| here, know the option is available to you.
| rmbyrro wrote:
| Amazing, now I don't have to pay API Gateway to do just an HTTP
| routing.
| k__ wrote:
| As far as I know, you can call the Lambda via the AWS SDK.
| throwaway2016a wrote:
| You can but that has security + protocol implications and is
| not as useful for general web consumers. This seems better
| IMHO.
| nhoughto wrote:
| Yeah you need an aws iam identity to call lambda invoke,
| for public consumer this is better.
___________________________________________________________________
(page generated 2022-04-06 23:00 UTC)