Decoding your hidden AWS EC2 costs
For the average AWS customer Elastic Cloud Compute (EC2) usage accounts for 70-75% of their bill. This makes it a great place to start optimizing AWS costs. But with thousands of unique EC2-related line items that could show up on your AWS bill, it can be difficult to understand exactly what’s driving all that spending, let alone figure out what you need and what you don’t.
In this post, we’ll try to whittle down the vastness of AWS EC2 costs into some meaningful categories to help figure out what you’re spending all that money on, and where you could look to spend less.
The anatomy of EC2 spending
At the end of the day it’s simple to think of your EC2 infrastructure as a bunch of ‘computers’ with associated resources. Indeed, costs like computation, memory, and local storage are very much related to the computer itself. AWS bills these costs as instance hours: what you pay to run the EC2 instance for every hour of every day. For example, use an m3.medium Linux instance in us-east and you’ll pay 6.7¢ per hour with on-demand rates.
When spinning up instances there is a vast array of options to chose from which impact cost—sometimes unnecessarily. For example, do you need to have a compute optimized instance with 16 EC2 compute units, or a memory optimized instance with 244 GB of RAM? As long as your instance is running, you pay for it—whether you are actively using it or not. There are well known strategies to manage these costs such as right-sizing, turning off pre-prod instances out of business hours, and getting better rates via spot instances and reservations, but you can’t stop there. Many people commonly think of these instance costs as being the only meaningful EC2 cost metric, however we are seeing more and more that ‘non-instance’ EC2 costs are contributing to surging AWS bills.
EBS, or elastic block storage, has become an indispensable component of EC2 and generally finds use as volumes attached to individual EC2 instances. It’s important to remember that although an EBS volume – which commonly provides the root volume for an instance – is attached to individual instances, they are actually billed separately. And, unlike EC2 instances, an EBS volume doesn’t even have to be ‘running’ to be costing you money. There are three key categories you get billed on: the EBS storage itself (GB-months), snapshots which may be used as a backup or for creating future EBS volumes/EC2 instances (also in GB-months) and finally provisioned IOPS (IOPS-months). To save money in this space you’ll need to make sure you don’t have unattached EBS volumes sitting around, make sure to choose the right type of EBS volume, and have an efficient EBS snapshot retention policy.
There are various costs related to transferring data in and out of EC2 and depending on your workloads these costs can be significant. Transfer costs are normally calculated based on the amount of data being transferred and where that data is going. For more details on understanding this aspect of AWS costs and how to optimize them, read our previous post on this topic.
Probably the next biggest cost you’ll see for EC2 is for your elastic load balancers (ELB). ELBs are most commonly put in front of your web servers. These load balancers are able to balance load between availability zones, manage the health of your instances, and effectively be the public-facing component of your infrastructure. You are charged per ELB-month and per GB transferred. The last item we’ll cover are called elastic IP addresses (EIP). EIPs are static IP addresses which can be switched around between different EC2 instances. You are charged if you have unattached EIPs or more than one on an individual EC2 instance.
How EC2 costs show up on your bill
If you are logged into the AWS console and have access to your organisation’s billing management you can see a high level cost breakdown of each AWS product including EC2. Within this EC2 product section you’ll see your spending grouped by AWS region, and within each region it’s broken out by the sub-categories mentioned above. Here is a partial example:
This high level view may be handy in some cases but it doesn’t include detailed information such as availability zone, breakdown by tag, or which instance used a reservation.
For this information we can refer to the detailed billing files AWS produces for you. Since each aspect of EC2 is charged differently, every item will appear in a specific way within your detailed billing files. Below we can see an example of one entry—resource cost for one hour—within the detailed billing file for an actual EC2 instance (the bit you normally think of). The great news is that all of this key information can be surfaced within Cloudability in our cost analytics or dashboarding sections.
Where you should start optimizing your EC2 costs
A great place to start is building a report or dashboard widget which lets you visualize these different EC2 components. Even better yet, reach out to your friendly Technical Account Manager who will be able to activate a pre-seeded dashboard for you which includes this. Here is a great example:
Having a visualization like this is going to allow you to see where the greatest EC2 costs are and where you should start prioritizing your cost saving efforts.