8 Common AWS Cost Management Mistakes and How to Avoid Them

Problem

You can rack up unnecessary AWS costs by leaving Elastic Compute Cloud (EC2) instances running when you are no longer using them. This frequently occurs when you have short-term projects or if you have testing environments.

We commonly see cases where instances are launched but not properly shut down once the project is completed. Since EC2 instances continue to accrue charges for both EC2 time and its associated storage, idle or forgotten instances can rack up significant costs over time.

Solution

You will need your unused EC2 instances stopped or eliminated for effective AWS cost management. You should regularly audit EC2 instances using Cost Explorer or Trusted Advisor to identify idle or underutilized instances. You can implement Auto Scaling or Instance Scheduler to automatically turn off instances during non-peak hours or you can base it on demand. And, regularly scheduled (daily, weekly, monthly) audits of the EC2 console will help.

Tagging EC2 instances with date, creator name, purpose, environment, etc., is crucial to driving down unnecessary costs.

Problem

When you terminate an EC2 instance, your associated Elastic Block Store (EBS) volumes are not automatically deleted unless you specifically configured them to do so. Zombie EBS volumes can add a lot of cost. If you create tags for EBS, this aids you in detection and deletion of unused EBS volumes.

Solution

Your AWS Cost Management efforts should include EBS.

Develop an in-house Standard Operating Procedure (SOP) and regularly review the EBS dashboard for handling the lifetime of EBS volumes. Implementing lifecycle policies that automatically delete EBS volumes when instances are terminated is also a good idea.

Create a policy that the EBS volume dashboard will be manually checked when deleting an EC2 instance.

Problem

Elastic Load Balancers (ELBs) will continue running and incur costs even when you have little or no traffic passing through them. This often happens when your application’s demand decreases or instances behind the load balancer are shut down, but your ELB itself remains active. Since AWS charges for load balancer uptime and data processed, keeping your ELBs idle can lead to an unnecessary bill.

Solution

You should regularly review your load balancer usage using Cost Explorer or Trusted Advisor and identify ELBs and their current statuses.

Problem

Cleaning up large amounts of undocumented and untagged backups is a challenging part of AWS cost management.

Just like EC2, Relational Database Service (RDS) instances can be left running without active usage. Similarly, snapshots may be left when you no longer need them, and you end up paying for idle storage. Having a system for your developers to track EBS lifecycles is key.

Solution

In order to drive down your AWS costs, you should regularly audit your RDS instances and snapshots for unused databases. Be sure to enable automatic snapshot deletion after a specified retention period and scale down or terminate unused instances. You should also develop an in-house SOP for automating the lifetime of an RDS instance.

It is important to remember that manual snapshots are not deleted automatically. And if you have poor tagging, you could end up with a confusing mess of backups. If you are unsure about deleting a backup, you can always move it to Glacier.

In order to avoid confusion and unnecessary costs, it is best practice to create a company standard operating procedure (SOP) for handling the lifecycle, retention, and tagging of snapshots and backups.

Problem

When you don’t fully utilize Reserved Instances (RIs) or Savings Plans you end paying for unused capacity. This can occur when you purchase more capacity than needed or when your workloads shift, rendering some RIs unnecessary or redundant. Changes in your demand levels or unforeseen changes in cloud requirements can leave you with capacity that is not being put to work—which negatively effects your AWS cost management.

You end up wasting money on RIs or Savings Plans that are not fully utilized if you’re not paying attention. Instead of getting the cost savings these plans are designed to offer, you are left with resources that add to your bill without giving you any real value. This inefficiency destroys the reason to have RIs and Savings Plans in the first place.

Solution

To address this issue, you should actively monitor your RI or Savings Plan usage using Cost Explorer. Cost Explorer helps track utilization and can identify any capacity that you aren’t taking full advantage of. If underutilization is detected, you can take steps to modify your RIs. If necessary, you can sell unused instances in the AWS Marketplace. Companies like ProsperOps and Cloudforecast can help you in this area.

There are 6 AWS drivers that can help you in this area – Cost Explorer, Budgets, Trusted Advisor, Cost and Usage Reports, Savings Plans Coverage Reports, and proper tagging. Proper tagging will save you in many instances, so you should consider a company-wide SOP for tagging. This practice alone can significantly improve AWS cost management outcomes.

Problem

Another AWS cost management pitfall is that many organizations see AWS S3 as a place to dump anything and everything. However, when using AWS S3, allowing data to accumulate over time will result in unnecessary storage costs.

Over the course of time, it is common for organizations to end up with data that is no longer needed and has been stored in Standard storage (the default). The problem is that AWS S3 Standard storage is the most expensive class. If you gradually accumulate more and more unused or infrequently accessed data, you could rack up a sneaky S3 bill.

Solution

You should set life cycle policies to automatically delete your unused data after a certain period of time. This proactive approach, configured within the life cycle policies dashboard, can help optimize your storage costs and keep your S3 expenses down. Set it and forget it. In fact, I would argue that setting up lifecycle policies should be SOP for setting up a bucket. AWS, by default, doesn’t transition objects smaller than 128KB. This is because of the cost benefit ratio of transitioning.

You should consider creating a company policy that sets Intelligent-Tiering as a default setting for creating buckets. You can set this up and forget it; and, you can also transition into Intelligent-Tiering.

Pro-tip: don’t be afraid of S3 One Zone-IA.

Problem

Misconfigured Auto Scaling Groups (ASGs) can cause you to have an over-provisioning of EC2 capacity. When your traffic spikes, EC2 scaling is activated but if your thresholds are set too low or your scaling policies are poorly tuned, you will have problems. You can end up with more instances launched than needed, and you will have to pay for all of it. This can occur during sudden traffic spikes or load fluctuations, as it should, but if you have it set too high, the added capacity becomes costly.

Solution

Right sizing ASG’s is a delicate balancing act. Avoid paying to extra compute by taking your time to correctly set your ASGs. Implementing better monitoring and alerting tools can also help you identify and correct over-provisioning in real-time, preventing unnecessary costs.

You should ensure that health checks are also properly set up. You can set up detailed EC2 monitoring so CloudWatch can better support your ASG’s. The costs in CloudWatch monitoring can be recouped in savings from properly scaling ASGs.

Lastly ensure you are rightsizing your EC2 instances. Spot.io Elastigroup is a third- party tool that can help with ASGs. These tools can help support your ongoing AWS cost management efforts.

Problem

Deploying CloudFront for low-traffic websites or applications without properly monitoring your traffic can lead to unnecessary bills. CloudFront is designed to optimize performance for high-demand websites. However, if you have a low-traffic site, this level of optimization may not be necessary for you. Also, if you’re not monitoring traffic closely, you may find yourself paying for an over-engineered solution. This can be particularly problematic when your site has sporadic or minimal user engagement.

Solution

If you want to avoid an unnecessary bill, it’s crucial to regularly review CloudFront traffic data. By analyzing your usage patterns, you can assess whether CloudFront is providing real value. If your traffic remains consistently low, you can switch to more cost-effective methods, such as serving your content directly from S3 or scaling down your CloudFront configurations.

This proactive approach ensures that your Content Delivery Network (CDN) efforts remain aligned with the actual traffic demands of your site. A properly aligned CDN will save you money. You may also want to consider keeping your cache times longer and being conservative with query string caching.