When you deploy an endpoint that is open to the world, you open it not only for use but also for abuse.
AWS provides services to avoid common abuse methods, such as AWS Shield, which mitigates against DDoS. But it doesn't know what is and isn't abusive either.
Of course, if your Lambda feature is private, then you should use one of the API gateway security mechanisms to prevent abuse:
- IAM security
- API key security
- Custom security authorization
If one of them is present, the Lambda function can only be called by authorized users. Cool!
But what to do when your Lambda is open to the public?
Not much, unfortunately.
One of the factors that you might want to control is concurrency or the number of simultaneous requests that are supported per account and per function. You are billed for each request plus the total memory allocation per request, so this is the unit that you want to control. Here is a pretty cool post about this. By the way, you can control this even at the Zappa settings level(!), check lambda_concurrency.
In addition to the limits for each account and for Lambda calls, you can also control Lambda exposure by wrapping up calls to the API Gateway and Create and use API Gateway Usage Plans.
Using API Gateway Limits to create usage plans per customer, you can control API and Lambda access to prevent uncontrolled account billing.
Thank you for reading!
Any questions? Leave your comment below to start fantastic discussions!
Check out my blog or come to say hi 👋 on Twitter or subscribe to my telegram channel.
Plan your best!
Top comments (0)