Right-size your cloud environment for cost optimisation
If your current systems cope well with everyday demands, but fail miserably if hit with sudden and unpredicted surges in demand, then our blog on Cloud Elasticity would be the best place to start.
If your current systems are struggling with everyday demands, or meeting those demands but your costs are sky high - then our blog on Right-sizing is perfect for you. Read on.
Typically, almost two-thirds of a Cloud Service bill is compute, with the next largest component, database services representing one fifth. Right-sizing activities should therefore prioritise these two areas to deliver the biggest impact on costs.
Amazon Elastic Cloud Compute (EC2) right sizing is the process of provisioning the lowest cost resource that still meets the technical specifications of a specific workload. The first step is accurately quantifying the usage patterns and identifying consistently under utilised resources. Different circumstances require different approaches:
For an EC2 instance that is effectively doing nothing at all, terminate it, and delete all the AWS Elastic Block Store (EBS) volumes associated with it.
For an EC2 instance that runs only during specific hours - for example 8am to 6pm weekdays only and is idle for the rest of the time, use a service to stop it and restart it for only the hours it is required. Development and Test environments are a classic example of this and would save 70% of the cost of running it 24/7 if turned off when not in use.
For an instance with consistently low utilisation, you may consider changing the instance type. Analysis of detailed metrics in CloudWatch will help you determine which instance type is most suitable for your workload.
For an instance with consistently varied and even unpredictable utilisation, check our Blog Post on Elasticity. You can likely save money by changing instance type, and introducing another service or resource to deal just with the peaks in utilisation.
In addition to right-sizing your environment, there are two other ways to achieve cost savings in the area of Amazon EC2 compute, and they are using Reserved Instances and Spot Instances, instead of on-demand compute. Reserved instances can provide savings when you have predictable workloads. This allows you to ‘commit ahead of time and buy in bulk’ - for which you are rewarded with a discounted rate. Spot Instances provide savings when you have flexible workloads. A bit like flying standby - the airline is committed to getting you to the destination - but you might just get bumped a couple of times before you get there.
Right-sizing Database usage
Similar to Right-sizing EC2, there are also a number of different approaches, and like EC2, the key is to analyse and understand the requirements of your workload when selecting the right one. Here are some different strategies:
If you are using Amazon Relational Database Service (RDS), you can simply change the database engine. Amazon RDS supports 6 different types of relational database engines: MySQL, PostgreSQL, MariaDB, Oracle, Microsoft SQL Server, and Amazon Aurora. The first three are open source, and run at a fraction of the cost of the likes of Oracle and Microsoft SQLServer.
Ensure you have the right instance for your workload. If you are able to switch to a smaller instance, the database is typically half the previous size and so you will save 50%. You will need a clear of your memory, CPU and IO requirements to ensure the instance you select still meets your requirements.
Use Amazon ElastiCache for Read-Heavy Applications. ElastiCache allows you to improve load and response times to user actions and queries, while reducing the cost associated with scaling web applications. ElastiCache is an in-memory data store, used for read-heavy applications where users demand real-time response. It caches subsets of data from the database. When a read request is sent, ElastiCache checks to see if it has the answer and returns it. If the cache does not have the required data, the application will retrieve it from the database, and the data will be stored for subsequent reads by ElastiCache. Using a cache.m3.large costs just one tenth of the amount of a db.m3.large for the same number of reads.
In addition to right-sizing your database services, there are two other ways to achieve cost savings. Like EC2 compute, you can consider stopping and starting databases that are not used during certain times. There are some other limitations, and you still pay for the storage and any snapshots, but you can still make considerable savings if a database is run for just 50 hours in a 168 hour week.
Likewise, if you are able to commit to using a database instance for 1 or 3 years, you can purchase a Reserved Instance plan, which can save you 30% to 64% against on demand pricing depending on whether you commit to 1 or 3 years, and whether you can pay upfront.
Ok. I’m right-sized - what’s next?
Note that right-sizing is not a one-time thing. Though organisations are typically seeking to scale up to survive, adaptation is also key to survival. Whilst some parts of your Cloud environment are scaling up, others might be winding down. Every major change to your business should trigger a right-sizing review. Similarly, AWS’ business is changing constantly too. So when AWS pricing changes, or more efficient resource types are released - this too should trigger a right-sizing review.
As an alternative to constantly right-sizing, you might want to consider a managed Cloud service provider, particularly if you are developing your own applications. One pillar of PolarSeven’s p7-Managed service is continuous right-sizing and cost optimisation.
If you are concerned that your AWS environment might not be right-sized, book a free consultation or callback, and our cloud professionals can discuss your unique circumstances.