AWS Cloud Cost Optimization
One of the big selling points of cloud computing is that it is very easy to scale up and down in line with changing business requirements. This is one area in which Amazon Web Services particularly excels. While this is good news in a lot of ways, it does mean that companies have to be really careful to implement effective cloud cost management. If they get this right, they can make significant cost savings. If, however, they get it wrong, those cost savings can evaporate and the cloud migration could go down as an expensive mistake.
With that in mind, here are seven key tasks for AWS cloud cost optimization.
1. Set up AMIs for your standard configurations
AMIs are Amazon Machine Images, or, in other words, templates for software configurations. You can use these to start and stop EC2 instances. This approach not only ensures that you actually remember to start everything required for a job. It ensures that you remember to shut it all down again after the job has completed.
Everything includes the likes of storage and network IP, both of which will continue to be billed for as long as they are active, regardless of whether they are being used. This can be a serious leak in your cloud cost management, but, fortunately, it should be an easy fix.
2. Remember to release your Elastic IPs
Remember that Elastic IPs are only free when your instance is actually running and even then you only get one free Elastic IP per instance. Basically Amazon wants you to use it or lose it, in other words, make it available for someone else to use. Take the hint and enjoy the cost savings.
3. Make it a priority to delete orphaned snapshots
Snapshot is the Amazon Web Services term for back-up. Snapshots only have meaning when an instance still exists. As with most things cloud, however, the onus is on you to remember to delete them when you end the instance and delete the volumes. Given that the snapshot is basically a copy of the original volume, remembering to delete it can save you as much as remembering to delete the original volumes.
For the record, if your cloud spend is higher than you anticipated and you’re trying to work out why, this is a good place to start your investigations as orphaned snapshots are often low-hanging fruit for people who want (or need) to make cost savings.
4. Look at your usage graphs
AWS provides you with metrics on CPU and memory usage for each and every one of your compute instances. It displays these in graphical form, which means it’s really easy to see when usage peaks and when it dips. Take a good look at both the highs and the lows and see what they mean in practice. For example, is a peak a genuinely busy time or is it a sign that a department is failing to use the cloud efficiently? Is a low genuinely low usage or is it a sign that someone has just left an instance “idling”, rather than turning it off?
5. Check you’re actually using the right instances/reservation types
This may seem like stating the obvious, but it can be surprisingly easy to miss. If you can achieve the same result with different instances/reservations types, then use the one which works out most economical. This will typically be the newest-generation system.
6. Check that you’re using the right storage configurations
Similar comments apply here. You don’t need to use a sledgehammer to crack a nut. In other words, save your fastest storage for your business-critical apps. Tasks such as data warehousing can run just fine on slower storage. In fact, if you look at your actual usage, you may well find opportunities for making cost savings without really impacting users by just switching to storage which is a bit slower.
7. Minimize interzone traffic
This one can take a bit of work, but the cost savings can make it worth the effort. The key point to remember is that Amazon Web Services works on a zonal basis and that interzone traffic is charged. You therefore want to minimize it as much as possible.
For example, let’s say you have an application running over two zones. Each zone has a load balancer and there are two application servers in each zone. If you have your load balancers spread the load between all four servers, then basically you are, at least potentially, just creating avoidable interzonal traffic, otherwise known as pure profit for Amazon Web Services. If, by contrast, you have each load balancer just work with the two servers within its own zone, then you eliminate this interzonal traffic and you can enjoy the cost savings.
Similarly if you have the application servers connected to two databases (one in each zone), then again, you’re just creating interzonal traffic for which you will be charged. If you just have the application servers point to the database in their own zone (i.e. either the master or the slave not both), then again, you can make cost savings.