AWS has been number one according to the Gartner rating in Strategic Cloud Platform for thirteen years. This is a feat no cloud provider has ever reached in the Cloud computing space, making AWS the leader in the Strategic Cloud Platform Space. But being a leader also comes with its pros and cons, and many people always need help with their cloud economics and tend to accuse AWS of huge cloud costs.
The issue of cloud cost is usually a controversial topic about one provider being more expensive than others, but the culture of your organization and the architecture of your workloads reflect in your cloud costs. When these two are properly managed, you can rest assured that you will get the most optimized cost for your workload and efficient services.
The How?
As I stated previously, two techniques can be deployed to optimize your cloud cost-efficiently. In this article, I shall mention a few of them that are more culture-based than architecture, because culture is more important than technical architecture. Going from the popular saying that “culture eats strategy for breakfast”, here is a list of systems to follow to ensure you do not overspend in provisioning workload in your AWS cloud account:
Set Budget Alarms:
Budget alarms provide a quick and effective way to monitor and control your AWS spending by triggering alerts before costs exceed your limits. In the AWS Billing Console, the Budget Alarms feature lets you set notifications based on a specific dollar amount or a percentage threshold. When your usage reaches the defined threshold, an alert is automatically sent to the configured destination. These alerts are routed through an SNS subscription, so they don’t have to be sent via email, reducing the risk of being overlooked. You can also explore alternative notification methods, such as webhooks, to route alerts to more visible or actionable channels.
Use Reserved Instance/ Savings Plans / Spot Instances
This is one of the oldest and most effective cost-saving practices in AWS. If your EC2 instances are expected to run continuously for up to a year, the next step is to take advantage of a discounted billing option. AWS offers several types of discounted pricing, but here we’ll focus on two of the most commonly used options within the AWS ecosystem.
Reserved Instances
As the name suggests, a Reserved Instance means you’re committing to use specific AWS instances over a set period—either 1 year or 3 years. In return for this commitment, AWS offers a significant discount of up to 72% compared to regular On-Demand pricing. Essentially, AWS allocates a dedicated portion of its infrastructure to your reserved usage, which is why the cost is lower. However, to benefit from this discount, certain conditions must be met, such as the type and availability of the instance. Reserved Instances are available for services like EC2, RDS, and ElastiCache. A common use case for EC2 reservations is hosting web application servers that run continuously and need high availability. Below is an example showing the price difference between using On-Demand pricing (the default option) and a Reserved Instance. For more detailed information, you can refer to the AWS documentation on Reserved Instances.
Savings Plans
Savings Plans are a newer discounted billing option in AWS that, like Reserved Instances, require you to commit to using AWS services for either 1 or 3 years. You choose the amount you’re willing to commit to spending per hour, and in return, you receive a significant discount. Similar to Reserved Instances, Savings Plans offer flexible payment options: all upfront, partial upfront, or no upfront.
However, the key difference is that Reserved Instances are tied to specific instance types and configurations, while Savings Plans are based on your hourly spend commitment, giving you more flexibility. There are three types of Savings Plans: Compute Savings Plans, EC2 Instance Savings Plans, and SageMaker Savings Plans. The diagram below explains how Savings Plans apply to EC2 usage. Most of the use cases that are ideal for Reserved Instances also apply to Savings Plans. You can find more details in the AWS documentation on Savings Plans.
Spot Instances
Spot Instances offer a very different pricing model compared to Reserved Instances and Savings Plans. While they are a highly cost-effective way to run EC2 instances, they come with some important limitations. The main thing to understand about Spot Instances is that AWS can reclaim them at any time. When this happens, you’ll receive a two-minute warning to shut down or clean up your workloads before the instance is terminated. This means that Spot Instances are not guaranteed to run continuously; they are available only as long as AWS has spare capacity. Despite this, they offer substantial cost savings, with discounts of up to 90% compared to On-Demand pricing.
Use Serverless Services on AWS
Services like AWS Lambda and Fargate provide serverless compute options that can be more cost-effective than traditional EC2 instances. They help reduce not just capital expenses (CapEx), which are the obvious monthly charges, but also operational expenses (OpEx), such as system maintenance, patching, and update costs, often overlooked with EC2. With AWS Lambda, for example, you only pay when your function is invoked. If there are no requests, you incur no charges at all. This pay-per-use model can result in significant savings, especially for workloads with variable or unpredictable traffic. Additionally, since AWS handles all the backend maintenance, your operational overhead is nearly zero.
Deploy on PipeOps
PipeOps is a no-code, serverless, fully managed platform that enables businesses and developers to easily deploy and scale their applications in the cloud, without needing to understand complex infrastructure. Built by developers for developers, PipeOps simplifies cloud deployment with user-friendly, cost-effective solutions. It offers pre-configured, end-to-end DevOps capabilities, including CI/CD automation, allowing you to focus on building your application while it handles the rest. With transparent, usage-based pricing, PipeOps ensures you only pay for what you use—no hidden fees or unexpected charges.
Shutdown Services when not in Use
In my early days as a Cloud Engineer, this was one of the fastest options to save some hours of cost on EC2 instances that are not regularly used. I would start the staging EC2 instances at 9 am and shut them down at 6 pm. This means the instances will not run between 6.01 pm and 8.59 am, which saves some cost. But as with everything manual, I forgot to perform this operation sometimes, so I had to automate it using AWS Lambda and Amazon EventBridge (former CloudWatch Events). The following guide shows how to configure an automated start and stop using AWS Lambda and Amazon EventBridge. https://repost.aws/knowledge-center/start-stop-lambda-eventbridge. You can also read more about optimizing EC2 workloads on AWS.
Use Graviton-type EC2 Instances
In setting up an EC2 instance, AWS has various instance type options. The advisable option to choose is the Graviton-type processors. These are ARM-based processors proprietary to the AWS Compute environment. Graviton processors are more cost-effective, faster, and ecosystem-friendly because of their energy efficiency capabilities. Graviton processors are also more affordable compared to their Intel-based processor counterparts. Graviton-based processors are available on Amazon EC2, Amazon RDS, AWS Elasticache, Amazon MemoryDB, and AWS Neptune. To identify if an instance type is Graviton-based, you need to search for any instance type with a g just after the instance generation. For example, an instance type of t4g.small is a graviton-based instance type, and a database instance type of db.r6g.large is a graviton-based instance type. The small letter g after the number tells you it is Graviton-based, which is different from a t4.small or a db.r6.large, which are Intel-based.
Periodic Cost and System Audit
Conducting a cost audit in your AWS account is a reliable way to ensure your cloud spending is optimized. Over time, various resources are created across your environment, and without regular audits, it’s difficult to track what’s in use, what’s redundant, and what can be optimized or removed. An audit helps identify unused or underutilized resources—such as unattached EBS volumes or Security Groups not linked to any ENI or EC2 instance—that still contribute to your monthly bill. Beyond identifying waste, a thorough audit provides insights that can drive architectural improvements. For example, if your workload relies heavily on EC2 instances, but could run more efficiently and cost-effectively on EKS or a serverless platform like AWS Lambda, the audit will highlight this opportunity. Similarly, infrequently used APIs might be better served by Lambda’s pay-per-use model rather than persistent EC2 instances. In short, audits provide the data needed to make informed decisions about resource optimization and system architecture.
Conclusion
There are many ways to reduce costs in your AWS cloud environment, but the most critical among them is performing regular audits. Continuously reviewing and validating your cloud expenses helps you identify where money is being spent and uncover opportunities for optimization. These insights are key to making informed decisions about re-architecting your workloads for greater cost efficiency.
