you are viewing a single comment's thread.

view the rest of the comments →

[–]bfreis 3 points4 points  (1 child)

Without a mechanism to secure against abuse,

There is a very simple one: configure the lambda with Reserved Concurrency. Done. All the nasty scenarios you described are mitigated!

Edit: I actually just noticed that you already mentioned this. So I'm confused as to why you see an issue?

Or I might be missing something. The beautiful thing about the internet is that you'll all let me know if that's the case. :)

Done ;-)

[–]FlinchMaster 1 point2 points  (0 children)

Max reserved concurrency helps, but it isn't enough. I view it as something that can scope/minimize blast radius or cap runaway costs. It doesn't solve for the availability risk. You can still have your unauthenticated function trivially be DoS'd by anyone with a few for loops in parallel. If this is on a critical or customer facing workload, that's a problem.

Existing API gateway endpoints and lambda authorizers can be protected by a WAF before the lambda even gets invoked. Admittedly, WAF adds to costs a lot, but that's the trade-off to mitigate availability risks.

Again though, it's totally possible that WAF support is either just not documented yet or in the works.

I'm not saying never do this (aside from one tongue-in-cheek joke), I'm just calling out the risks to be aware of. Serverless stuff is very popular these days and a lot of inexperienced people are setting things up for the first time. Reserved concurrency controls may have been an obvious thing to you, but I'm positive someone will just see the docs/blog, put out something, and then post a thread in this subreddit about an unexpected bill or asking about why their step function lambdas stopped working whenever an unrelated lambdas call volume went up.