"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.
AWS Lambda as a back end for a single-page app
51–60 of 77 posts
Re: AWS Lambda as a back end for a single-page app
#52The 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.
Re: AWS Lambda as a back end for a single-page app
#53Earlier 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?
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.
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
#55Re: AWS Lambda as a back end for a single-page app
#56Re: AWS Lambda as a back end for a single-page app
#57"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.
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
#58Re: AWS Lambda as a back end for a single-page app
#59How would this use differ from Amazon's elastic beanstalk?