Mastering AWS Cost Reduction: Mistakes That Skyrocket Your Bill

Member-only story

Jan Kammerath

The ability of AWS to provide almost infinite resources is great and you shall never consider resource constraints when building cloud native applications. However, there’s the economic factor and no one has infinite budgets. I recently reduced my company’s AWS bill for a set of accounts by 65% which is around $60,000 in cost savings annually. You don’t need fancy software or tooling to manage your cost since AWS already provides a number of services to keep your costs under control. The cost drivers are almost always the same with most accounts and companies.

A highly recommended approach is to review AWS cost at least on a quarterly basis, ideally on a monthly basis. This does not just include reviewing the bills, but also digging into the services with the AWS Cost Explorer. While the Cost Explorer gives you a good insight into what drives your cost, it doesn’t provide solutions on how to lower them. For many of the cost drivers, you’ll often have to analyze the service usage using CloudWatch. Let’s look at these cost drivers and how you can counter them. We’ll also look at many cost drivers that you won’t find in the official AWS documentation or recommendations.

The most common cost driver I encountered across numerous businesses is overprovisioning. To no surprise, overprovisioning is also mentioned in the AWS Solutions Architect certifications. It refers to provisioning resources with memory and compute capacity well over the required capacity for your application. These can be EC2 instances with too much memory or Lambda functions allocated with excessive memory or long execution timeouts.

It may sound silly to provision a Lambda function with just 512 MB of memory. However, if the execution stats show that a Lambda function uses less than 400 MB, you should consider reducing the allocated memory. A common approach for many developers is to deploy Lambda with too much memory and a too long execution timeouts. If your lambda sits behind an API Gateway, you are limited to a maximum execution of 30 seconds anyway. The compute power or available vCPUs of your Lambda directly relates to the allocated…