Analyzing AWS Billing Issues
If you’re running software on AWS, then each month you’ll end up troubleshooting AWS billing issues.
This last month, my AWS bill for one of our internal accounts was higher than expected. Surprise, surprise!
I started to investigate the issues by navigating to my previous months bill from the Billing & Cost Management Dashboard by selecting the Bills section of the menu, highlighted in red.
AWS provides a range of cost management tools that are instrumental in analyzing and optimizing usage. The most frequently used is the Cost Explorer, which empowers users to track and assess their AWS costs over time. With the Cost Explorer, users can identify spending trends, break down costs by service or resource, and generate custom reports. AWS Budgets enables users to establish personalized cost and usage budgets and receive notifications when nearing or surpassing these limits. These tools offer users enhanced visibility into their AWS expenditure and aid in making well-informed decisions to optimize usage effectively.
To start this process on your own AWS account, click here.
When I click on Bills, the following view defaults to the current month in the Date combobox, so you will want to pick the previous month. The bill that I’m investigating is November 2019, also highlighted in red.
This specific AWS account has very little traffic on it. We used the account as a staging area for one of our clients that required Kubernetes. The staging area ran in US West (Oregon) and US East (Ohio) so effectively all of the services in these regions should be turned off.
CloudWatch AWS billing issues
Let’s start with the first item on the list, CloudWatch. CloudWatch is turned on at the EC2 instance level. The majority of the CloudWatch charges are coming from Oregon, the region that is no longer required, so I should be able to eliminate this cost by disabling the CloudWatch monitoring.
To disable the CloudWatch monitoring, I can follow the instructions to Enable CloudWatch monitoring here, and turn off CloudWatch.
To start, I’ll open a new tab to display the AWS EC2 instances in Oregon by clicking on Service from the navigation bar, and then right mouse clicking on EC2, and opening this url in a new browser tab.
The EC2 region will display. I’ll want to ensure that I’m pointing to the right region, Oregon, highlighted in orange. Next, I’ll click on the Running Instances 1 highlighted in red.
I’ll select the running instance, click on the Action menu, select CloudWatch Monitoring, and select Disable Detailed Monitoring.
Hmm, that’s interesting Disable Detailed Monitoring is turned off. I suppose this isn’t a problem after all, but why was I being billed?
DynamoDB AWS billing issues
The next service charge on our invoice was for DynamoDB. Let’s take a closer look and see if we can terminate these costs for good!
DocumentDB is Amazon’s version of MongoDB. We use DocumentDB to store unstructured data in a JSON format.
In November of 2019, our DocumentDB bill was entirely out of US West (Oregon), which is one of the areas that we should no longer be billed for. A quick glance at our DocumentDB in US West (Oregon) displays that we should no longer be charged for DocumentDB in December of 2019.
To further optimize our AWS costs, it is crucial to take a comprehensive approach to managing expenses. The next significant expense to address is our EC2 Instances. For November 2019, more than 50% of the spend was on EC2 instances.
In the previous section, we successfully deleted the micro EC2 instance, but it is essential to ensure that all unnecessary resources are removed. A quick trip to the VPC dashboard reveals that we still have 2 NAT Gateways operational, impacting our costs.
We have identified that we are incurring charges for an ELB. To address this, navigate to the EC2 Instances view and scroll down to the Elastic Load Balancing section to delete the ELB.
We also notice that we’re being bill for an ELB. On the EC2 Instances view, scroll down to the Elastic Load Balancing section to delete the ELB.
Moreover, our usage of Amazon’s Elastic Container Service for Kubernetes (K8S) has implications on our costs. Confirming the utilization of resources is essential to avoid unnecessary expenses.
Moving forward, it is crucial to identify and address all cost-driving factors. For instance, we currently have a t2.medium MySQL RDS instance running, which should be decommissioned to reduce costs.
Lastly, AWS is billing us for Hosted Zones that were utilized by our Kubernetes setup. To address this, navigate to Route 53 and remove the Hosted Zones for US-West-2. While the process may be cumbersome due to the single-select limitation in the Admin interface, it is a necessary step to optimize costs effectively.
We’ll navigate to Route 53 to blow away these Hosted Zones for US-West-2. Deleting Hosted Zones via the Admin interface is painful as you can only single select.
At this point, we’ve hopefully cleaned up our problematic Oregon (US-West) zone. Continue to go through your other problems and check back in during every billing period.
AWS Billing Experts
Need some additional help? Reach out to us and we can point you in the right direction!
You might also like…
What is Amazon EC2? – Elastic Compute Cloud
Data Lake vs Data Warehouse on AWS
