10 Tips to Manage Your AWS Serverless Costs

Serverless architectures are amazing. The advent of AWS Lambda has introduced a whole new type of ‘serverless’ compute that allows developers to only pay for the exact amount of compute their applications utilize. DynamoDB and others have introduced similar pricing models for other types of infrastructure. Compared to more traditional architectures serverless arcitectures often represents massive cost savings as well as increased developer productivity. That being said, the total infrastructure cost for a serverless architecture can certainly grow over time and there are lots of ways to optimize and manage those costs as you scale.

  1. Utilizing Cost Allocation Tags

AWS tags allow you to add metadata to each of your AWS resources, including AWS Lambda. A great way to utilize these tags is to allocate costs from your AWS bill to individual functions or to groups of functions in order to better understand your cost breakdown.

You can also specify a tag for an entire CloudFormation stack, providing a high level overview of the costs for your entire Serverless application or service.

  1. DynamoDB Capacity Modes

DynamoDB offers two types of capacity modes; on-demand and provisioned. The mode you select determines how you are charged for read and write throughput. On-demand is more flexible, since you only pay for what you use, but it can also be more expensive and harder to control costs since DynamoDB will automatically scale up to meet your application’s traffic.

In provisioned mode you specify your required reads and writes per second and throttling prevents your application from exceeding that capacity. You can use auto-scaling to adjust your provisioned capacity, for instance to meet higher than normal traffic, but it is your responsibility to move this up and down. 

We recommend starting with on-demand provisioning for all new projects and then switching to provisioned if you validate that your traffic patterns are mostly predictable.

  1. Take Advantage of Savings Plans and DynamoDB Reserved Capacity 

Savings Plans are an alternative pricing model offered by AWS. Basically you commit to a certain amount of usage over 1-3 years and in exchange AWS gives you cost breaks on infrastructure. Savings Plans are only offered on limited compute infrastructure but both Lambda and Fargate qualify so this can be a great way of reducing costs if you are comfortable with a long term commitment to AWS. AWS offers a pricing calculator to help you understand the discounts you can get from a Savings Plan.
DynamoDB often makes up a large percentage of the cost of an AWS Serverless architecture, and DynamoDB Reserved Capacity is the same concept as Savings Plans except for DynamoDB. You pay upfront for capacity at a specified hourly reserved capacity rate. It’s important to note that you can only use reserved capacity if you are in provisioned mode. You can manage your Reserved Capacity in your DynamoDB console.

  1. Be Aware of DynamoDB Query Costs

Optimizing your table design with DynamoDB query costs in mind is a great way to manage costs for high traffic applications. It’s important to note that writing to DynamoDB is 10x the cost of reading, so optimizing your queries to minimize writes can significantly reduce costs. Another important factor to remember is that when you update certain items in a table, the cost of that write will be calculated based on the capacity of all items in that table.

  1. Optimize Lambda Memory Size

When it comes to Lambda Function memory size, less memory does not always mean a lower bill. Often times increasing your Lambda memory can result in a much shorter execution time and lower overall costs while also improving performance. There’s no magic formula, it takes some experimenting to figure out the optimal memory setting, but Alex Casalboni’s AWS Lambda Power Tuning project is a great way to automate this process. The project is free and open source, check it out on GitHub.

  1. Optimize CloudWatch Logs Retention Period 

CloudWatch Logs are often one of the most expensive parts of an AWS Serverless Architecture. By adjusting the amount of logs as well as the retention period you can dramatically affect your costs. Do you really need a large amount of logs for a long time for a staging environment? How much logging do you actually utilize in your production application? Review this periodically and ensure that your CloudWatch settings are well optimized.

  1. Choose the Right Type of API Gateway

AWS API Gateway has two main modes: Rest API and HTTP API. The HTTP API is limited to only the core functionality, but has lower latency and lower cost than the REST API. Unless you need the additional features offered with the REST API you can save a lot of money by utilizing the HTTP API.

  1. Understand Step Function Costs

Step Functions is a service that allows you to define workflows around Lambda. Step function are implemented through a UI console so you can easily see your application workflow. This makes it easy to track down and investigate problems when they occur. The downside is that Step Functions cost $25 per million state transition, which is 15 times more expensive than a normal Lambda. It’s a very good idea to understand the benefits when using Step Functions and decide if they are worth the cost. 

  1. Be Careful of Lambda Infinite Loops

As all developers know, occasionally a bug or a security attack can result in an infinite loop or an unexpedly high number of invocations. With Lambda this can result in very high costs if it is not identified quickly. A great way to reduce the risk of this is to useCloudWatch notifications to raise an alert when this unexpected behavior occurs.

  1. Optimize the Number of Shards in Kinesis Data Stream

The number of shards in your Kinesis Data Stream determines both your throughput and costs. Optimizing this setting will ensure your streams perform well without needlessly driving up costs. We recommend performing a load test and calculating the optimum number of Shards in advance from the estimated traffic volume.