Cost savings is a top priority for almost every customer we talk to at Rackspace. The first thing most customers want help with when attempting to reduce costs with AWS is the purchase of Reserved Instances (RIs). With RIs, customers can trade a time commitment to a specific instance type or family for a discount (up to 75 percent) from AWS.
As tempting as it may be to run off and make a commitment to RIs right off the bat, it can quickly turn into a costly mistake. We advise that you slow down and take stock before committing to anything.
At Rackspace, we practice a tried and true approach, blending our AWS expertise and integrated tooling to maximize your cost savings on AWS (we help solve a lot of other challenges, too — but this post is all about cost savings). We’ll explore the steps in this article (spoiler alert: RIs are the last step).
Eliminate the unnecessary
Almost every house has at least a few neglected and unnecessary items. Why don’t we recycle or donate them? Often, it’s because they’re free to keep (also: they require effort to move). However, if we were charged rent for each and every item we owned, we’d likely be far more intentional about what we keep.
Some AWS environments we’ve seen resemble fraternity houses where nobody knows exactly why particular resources showed up. When we perform a cost optimization exercise for our customers, we usually identify “unused items” such as unattached EBS volumes and unused Elastic IPs, Elastic Load Balancers, DynamoDB tables and WorkSpaces. Like a professional organizer, we systematically walk you through your environment and make sure every resource has a purpose.
It’s common to find unused resources in dev/test/stage environments since users often neglect to delete resources they created for testing purposes, as an example. An effective way to overcome this problem is to implement and enforce a tagging policy within the organization requiring all users to use resource tags such as: “owner”, “project”, “purpose”, and “NeededUntil”. Tooling (such as Rackspace’s Compass) can make this easy to report on, audit and enforce.
Upgrade previous generation resources
Now that we’ve eliminated the unnecessary, we can focus on updating outdated resources. When Amazon launches a new, upgraded family of instances (e.g. T1 to T2), they typically provide more compute power — and almost always at a lower unit cost.
Migration of instances to the latest generation is a quick win since it doesn’t require deep analysis. Additionally, it’s a good practice to schedule a periodic review (typically quarterly) to ensure you never get out-of-date.
Depending on instance configuration, changing the type of an EC2 instance (usually referred to as resizing) can be as simple as a reboot. However, in some cases it might require manual migration of applications and data. Our certified AWS support engineers can advise on the right approach and help with the implementation.
Do something about those idle resources
Now it’s time to look at the utilization data of our resources. The first step is to identify idle resources like EC2 instances, RDS DB instances and ELBs. Even if a running instance or node is idle and not being used, you will continue to be charged for it. Idle instances can be detected by looking at CloudWatch data over a defined period of time and analyzing a combination of CPU utilization and network activity.
What to do with idle instances?
- Terminate the instance — If the instance is not required at all, terminate it. If unsure, take a snapshot of it beforehand, in case you ever need to restore it.
- Stop the instance — If the instance is needed, but not on an ongoing basis, stop it. EBS-backed instances can be stopped and restarted when required.
- Change the type of the instance — If the instance is needed on an ongoing basis, resize it. Since the instance is idle, you might be able to move to a smaller (cheaper) instance type.
Make costs right by making sizing right
Instance prices are proportional to instance sizes. The more CPU and RAM an instance has, the more it will cost. When new applications are built on AWS, it can be difficult to predict the amount of compute and memory required. To ensure uptime, capacity is usually over-provisioned. Severe overprovisioning is a bad habit that many of us bring from our pre-cloud days. However, once the application is live, usage statistics can be collected and analyzed in order to right-size the instances based on the actual needs of the application.
Right-sizing is not limited to scaling up or down. Sometimes it requires changing the instance family. Different instance families are suited for different workloads:
- The “C” family is suited for compute heavy applications.
- The “R” family is suited for application that need a lot of RAM.
- The “T” family is suited for bursting workloads.
Instance right-sizing is a very important preparation step for purchasing RIs, which we are going to examine next. A purchase of RIs involves commitment to specific instance types for a long period of time. As such, we must make sure that the instances are suited for that purpose. We recommend that you never purchase RIs without right-sizing your instances first (and for that matter, all of the other steps we’ve mentioned up to this point).
Without further ado: Reserved Instances
Now that we have the context of the previous steps, we can confidently proceed to committing to the right RIs.
Reserved Usage is not limited to EC2 – it’s also available for RDS, ElastiCache, Redshift and DynamoDB. RIs can be purchased for a period of one or three years and there are three payment options: no upfront, partial upfront and all upfront.
In general, the more money you pay up front, the greater the discount. However, time value of money must be accounted for — and we often recommend one-year RIs over their three-year counterparts due to this, as well as other factors like new generation resources.
RIs are typically linked to a specific instance type, OS, tenancy and Availability Zone. However, there are ways to add flexibility by using the regional benefit or convertible RIs. Choosing the right type may not be straightforward, but getting to the optimal answer is much easier with the right tooling and knowledge. While determining the right RIs for our customers, our Technical Account Managers simulate and explain the different options and help them achieve the best ROI considering application and business needs.
Fanatical Support for AWS
Along with areas like security and governance, cost savings is top of mind for most AWS users. We’ve built a world-class team of AWS experts and tools using a customer-obsessed approach that helps you solve for these and more.
Our Compass tool is included with every account we manage and it helps us guide you on everything from reviewing and breaking down costs on a monthly basis to enforcing tagging to identifying unused and idle resources and determining optimal RI types.
For our Aviator customers, we operationalize important tasks like cost savings and walk you through everything from costs to potential savings to security reviews and much more! You know that we’ve got your back and are helping you to run your AWS environment effectively, allowing you to focus on other areas — like running your business.
Note: This post covers the traditional approach for cost savings on AWS. There are other approaches which aren’t covered here (e.g. stop/start or terminate/launch resources on demand, use of managed services to replace EC2 instances).