Live data from Hacker News

AWS Lambda as a back end for a single-page app

lg.io

51–60 of 77 posts

Re: AWS Lambda as a back end for a single-page app

#51
post #39

"the future is now, and it's down because somebody used the secret key to drain the poster's bank account" To be sure, the author specifies that the IAM role being exposed here is only allowed to invoke the function. That's great for the security of the other resources on the account, but still allows a reasonably determined attacker to run up a Bill of Unusual Size quite rapidly. For instance, the rate limiter curre…

But the same is true of any backend. Once you know the endpoint being used by the frontend, you can blast the backend with requests and one of two things will happen: * You will take down the site (a DoS attack). * Or the victim has auto-scaling and you rack up their AWS charges. This is hardly a unique problem to Lambda.

The question is whether or not the cost per request is higher than if you were running something similar on EC2.

Re: AWS Lambda as a back end for a single-page app

#52

The real question here is still: why doesn't Amazon offer a GET interface to Lambda? It's so, so, so close. So almost. They offer POST (through a work-around with S3), why not GET? That is the real destination. With lambda serving GETs, we can remove the "for a single page app" from the title. AWS is so close to fulfilling the promise of its cloud: let developers worry about code.

This is the one thing I need to make them useful! This would make Lambda's so much easier to invoke, without needing to build custom code to put together an SQS message or similar.

Re: AWS Lambda as a back end for a single-page app

#53
post #50

Earlier quoted context omitted.

Doesn't this terminology come from power utilities where a kilowatt hour is kW.h. as in kilowatt × hour. Not kilowatt / hour. So why is a GB second, a GB / second and not GB × second?

It is a GB x second -- I've just seen it written more commonly as GB/s. I think we need a better abbrv for it... gBs?

Then it should be GB.s or GBs.

GB/s gives a different meaning. For example I could use 600 GB in the first second, then 400 GB in the second second. All together its 1000 GB.s, at an average of 500 GB/s for 2 seconds.

This is not perfect because kilowatt is a rate so kWh is a quantity. But GB is already a quantity. So a GB.s doesn't make sense either. It would need to be an equivalent memory rate usage × time in order to get memory quantity. Like avg GB/s × s.

Re: AWS Lambda as a back end for a single-page app

#54

> The future is now, and it's using AWS Lambda How is this different from what Azure Mobile Services and many others have been offering for the past 2 years? To me it seems the author is proclaiming Platform As A Service is entirely new (look, no spinning up AWS instances!) while this has been around for quite some time, just Amazon is getting into it more seriously recently.

Lambda is a focused, specialized service for running short-lived processes triggered by events and is one of the many services provided by AWS that have formed the foundation for many companies and other PaaS providers for many years, while Azure Mobile App Service is a packaged and branded collection of services including data storage and push notifications that is similar to backend service providers like Parse and Urban Airship pre-pivot (at least one of which was built on top of AWS), and tries to offer services comparable to a subset of other AWS services including SNS (push notifications), RDS or DynamoDB (databases as a service), among others.

It's also quite strange to spotlight Azure as if it's doing something at all remarkable considering the "Mobile Backend as a Service" market has existed for years and actually seems to be on the decline, at least as a standalone segment.

Re: AWS Lambda as a back end for a single-page app

#57
post #39

"the future is now, and it's down because somebody used the secret key to drain the poster's bank account" To be sure, the author specifies that the IAM role being exposed here is only allowed to invoke the function. That's great for the security of the other resources on the account, but still allows a reasonably determined attacker to run up a Bill of Unusual Size quite rapidly. For instance, the rate limiter curre…

But the same is true of any backend. Once you know the endpoint being used by the frontend, you can blast the backend with requests and one of two things will happen: * You will take down the site (a DoS attack). * Or the victim has auto-scaling and you rack up their AWS charges. This is hardly a unique problem to Lambda.

The biggest difference is ease of rate limiting. With lambda, I imagine the best you could do would be check the IP in a Redis cache at the beginning of each request (if the SDK even includes that info) to minimize the damage. But there would be no way to fully stop an attacker without turning off the service entirely.

If you run your own webserver, I think you can stop stuff like that more efficiently / without the expense, eg at the nginx level.

Re: AWS Lambda as a back end for a single-page app

#59
post #56

How would this use differ from Amazon's elastic beanstalk?

With beanstalk, you're paying in terms of multiples of server instances at all times, even if nothing is hitting your servers. With Lambda, you pay only for the execution time of your function, which is only when a request is made.

Re: AWS Lambda as a back end for a single-page app

#60
Some time ago, when Lambda was in its early preview, I've created awsletter [1], a newsletter system w/o any old-style backend components - only AWS SDK for browser, S3 and Lambda. Pretty the same idea - utilize "invoke function" calls to realize backend actions.

[1] https://github.com/jelz/awsletter/

Post reply on HN