AWS Cost Optimization: 5 Ways to Find and Cut Waste

1. Begin with an audit of your AWS environment before attempting optimization. This structured review follows the AWS Well-Architected Framework and covers five cost optimization pillars. By using tools like the AWS Well-Architected Tool, Amazon Inspector, and Trusted Advisor, you can uncover critical issues such as vulnerabilities, deprecated resources, and inefficient configurations.

For example, a London-based foreign exchange company discovered numerous problems, including remote code execution flaws, unencrypted backups, and functions with excessively long timeouts. The review also qualified the company for $5,000 in AWS credits, which can offset the cost of the assessment itself. When using Compute Optimizer, ensure you have at least a week of CloudWatch metrics before making rightsizing decisions, as short samples may lead to ineffective recommendations.

2. Examine the processor architecture used by your Lambda functions. If your functions are still running on x86_64, you can achieve significant cost savings by switching to arm64 architecture on Graviton2, which can offer up to 19% better performance and 20% lower cost. This is a straightforward optimization because x86_64 is the default setting, and many functions inherit this default setting without any deliberate engineering decision.

A serverless application marketplace named Tibica migrated its Lambda functions from x86_64 to arm64 architecture, resulting in a 17% reduction in average Lambda response time, a 22% decrease in full user workflow duration, and a 20% reduction in Lambda compute cost. Before making this change, verify that your runtime and any native dependencies support arm64 builds, and test your application thoroughly on the new architecture to ensure compatibility.

3. Evaluate whether Lambda functions are necessary in your application's request path. This is a common oversight that can lead to wasted resources. In the case of Tibica, the company found that many Lambda functions were being invoked solely to relay requests between API Gateway and other services, with no actual processing logic involved.

These functions were further compounded by cold start delays, which added up to two seconds of latency per request. By streamlining the request path and eliminating unnecessary Lambda invocations, Tibica was able to achieve a significant reduction in costs and response times. This optimization does not require rewriting application logic or rebuilding infrastructure, making it an efficient first step in any cost optimization program.