This is continuation of a blog about common mistakes when building serverless systems on AWS. It is split into the following parts:
- Coding
- Architecture
- Performance, scalability, optimization, and monitoring
- Costs (here)
- Communication with other systems
- Security
- Unexpected Behaviors
One of downsides of serverless is that it is hard to estimate costs. Yes, you can count all requests your system will make, but are your estimates correct? A complex billing system is another problem. You can make calculations online using this or this. Do not forget hidden costs. But generally, serverless solutions are much cheaper than traditional ones. Even if you miscalculate, your solution will still be cheap. Additionally, you can make a lot of savings on operational costs.
Here is another in-depth analysis on how to calculate the costs of Lambda.
Mistakes That Can Cost You = Self-DoS
Be careful with reclusive calls and repetitive retry. For example, if you set up an event that is triggered when a new image is dropped in S3, to shrink it and upload it again to S3 you will trigger the same event again and cause recursion. It's better to drop a new file into another bucket. This happened to this guy. This is only one example of a reclusive call you can make by mistake and self-DoS your system.
Do not self-DoS your serverless system with reclusive calls and repetitive retry
DDoS and Other Attacks
Your serverless system is going to scale according to traffic. So, if you are DDoS-attacked, your system will likely scale and work seamlessly, but you will pay. Because serverless systems are cheap, that can mean only a few dollars, but it could be much, much more.
To prevent this, you must set limits. At least set this:
Lambda Concurrent Execution Limit
You limit how many concurrent functions can be executed at the same time.
In case of a malicious request (or bug), you limit function timeout. Do not set this too low, because sometimes a function needs a little more time and, in that case, the function would be terminated. It is really hard to debug those random errors.
Set Lambda Concurrent Execution Limit and API Gateway Throttling to prevent billing attack on your serverless system
Cost of BaaS
Lambda is extremely cheap. There is a low chance that you will pay more for Lambda than any other AWS service. Why is Lambda so cheap? Because it is the glue between other services you use. In a well-architected serverless solution, you should use Lambda as little as possible. This approach is significantly different from the traditional system.
In most cases, you will pay more for services like CloudWatch or API Gateway, and quite certainly pay more for a database. CloudWatch Logs charges at $0.50 per GB for ingested logs and $0.03 per GB for stored logs. In production, you should only log what you need or you should sample debug logs for a small percentage of invocations. Default retention policy never expires! A common practice is to ship your logs to another log aggregation service and to set the retention policy to X days. See this post for more details. You can set retention time in Serverless.yml with property logRetentionInDays if you are using Serverless Framework. Read more in a blog post about monitoring.
Default CloudWatch Logs retention policy is never expires! Do not pay for logs more than for Lambda!
Set Alarms
You can configure CloudWatch to send you various types of alarms. In case everything goes south, there are always billing alarms.
Alarms are only alarms. They notify you. They do not limit spending, shut down services, or block requests. They just inform you. While you are busy figuring out what is going up, expenses go up. Quick hint: If you want to stop the execution of Lambda, set the Concurrent Execution Limit to 0.
If you want to stop the execution of Lambda, set the Concurrent Execution Limit to 0