Cost management is typically the first issue people encounter when they enter the cloud. Unfortunately, however, it does not lend itself to a 1-time and move on type of resolution. Instead the most effective cost management requires vigilance and a commitment to continual review.
So, with that introduction here are 5 of the most common AWS cost issues, explanations of why they are important, and some ideas on how to mitigate the issues.
1. Underutilized and Idle EC2 Instances
EC2 Instances are charged by time usage. As such, if a running EC2 instance is using less than its capacity or, even worse, sitting idle and not being used at all, you continue to be charged for the instance. Idle and underutilized instances can be detected by looking at your CloudWatch data and analyzing a combination of CPU Utilization and Network activity. If all these factors are low, the EC2 instance should be flagged. You should contact the owner of the instance and verify if the instance is needed at its current size or needed at all. Be aware that some instances may appear oversized but are purposefully configured that way for memory or other reasons. Do not turn off instances without first contacting the owner!
By detecting and shutting down any idle instances you can immediately start saving money on your bill.
2. Previous Generation EC2 Instances That Should Be Migrated
EC2 provides a virtual computing environment where instances can be launched using a wide variety of operating systems and configuration options. AWS users can run their custom applications on these instances, while maintaining full control over their security access.
When Amazon launches a new, upgraded family of instances (example, m3 to m4), in addition to providing more compute power the new instances are often less expensive. Because of this, it almost always makes sense to migrate previous generation instances to their corresponding new generation instances. Doing so will improve your performance AND lower your bill!
NOTE: Migrating some instances from t1 to t2 may require a complete rebuild of the instance.
3. Track and Minimize Reserved Instance Types with Unused Hours
Reserved instances require an up-front payment to Amazon and a commitment of one or three years. In exchange for this, the hourly rate for the instance is at a substantial discount over On-Demand pricing. Importantly, Amazon will bill you for the full month’s usage for the reserved instances, whether they are used or not. Users should also that when you buy an RI, you need to match key fields to ensure that it is used. If you are mismatching fields, you will end up paying 2x – 1x for the RI and 1x for the On-Demand instance you are using.
Tracking unused hours ensures that you can readily identify and mitigate areas of waste where you have either purchased too many instances or failed to properly map your RI to your environment.
4. Actively Manage DynamoDB Tables
Amazon’s DynamoDB is a fully managed NoSQL database service that can store and retrieve large amounts of data, and serve high levels of request traffic. All data items are stored on Solid State Drives (SSDs), and are replicated across 3 Availability Zones for high availability and durability.
Idle DynamoDB tables are detected by looking at CloudWatch data over the last 48 hours and analyzing its utilization. If the average Consumed Reads and Writes are less than 2% of the Provisioned Reads and Writes, a table should be considered idle. In that case you should reduce the Provisioned Reads and Writes to reduce the cost of the table or delete the table if it is unused. You should contact the owner of any flagged tables and verify if the additional Provisioned Reads and Writes are actually needed.
5. Convert EBS PIOPS Volumes to General Purpose SSD
General Purpose (SSD) volumes are backed by Solid-State Drives (SSDs) and are suitable for a broad range of workloads, including small to medium-sized databases, development and test environments, and boot volumes. General Purpose (SSD) volumes are designed to offer single digit millisecond latencies, deliver a consistent baseline performance of 3 IOPS/GB to a maximum of 10,000 IOPS.
General Purpose (SSD) drives are given a base IOPS level of 3 IOPS/GB. For instance, if you allocate 1,000 GB of storage space for an EBS volume, the volume has a base IOPS level of 3,000 IOPS. For General Purpose (SSD) drive, you only pay for the storage. When you create a drive with Provisioned IOPS, you pay per IOPS and for the storage allocated. You can often attain high IOPS and high storage space for a LOWER cost by converting your volumes to General Purpose (SSD) drives. This check calculates the cost of each configuration and recommends if there is a configuration for General Purpose (SSD) that would be less expensive for equal or greater storage and IOPS. This is often possible by configuring larger amount of storage which gives you a higher base level of IOPS.
An example of this would be if you were using a 200GB EBS volume with 2000 PIOPS, you would save money by using a General Purpose (SSD) volume by creating a drive of 1,000GB which would give you 3,000 PIOPS. For less money, you would get more IOPS and more storage space.
Now, before you start worrying about the time involved – and we know some of you are – we want to make it clear that cost management does not require tremendous time if you are able to automate the reporting to ensure that your attention is only spent on high value items that impact your results while avoiding the low value time wasting items that barely register relative to your entire bill.
This identification and differentiation is where CloudCheckr specializes. We can automate the detection of each of these issues. We will also provide you with each issue’s relative value and savings – so that you turn off or downsize the EC2 instances costing you $1000s per month but don’t waste time tracking down the owners of the ones costing you $20 per month. If you’re interested in seeing how we can drastically simplify the process, take a test run with a free trial.