How to reduce your AWS cost — Part 1
I am an AWS certified Architect (Professional) and I have worked with AWS services more than 5 years now. During this period I identified some tricks to save some of your AWS costs. Even though some folks overlook these if you run your infrastructure in a cost-optimized manner that means several things.
- You are not spending money unnecessarily and you can spend that money on a useful thing. e.g R&D work
- Your infrastructure is optimized and hence lower environmental footprint (At the end your workload runs on an actual data center which consumes electricity and other resources)
- Your applications might perform better since you are using an optimized setup (will be further explained later).
Since AWS has many services it is hard to cover all in one article. Therefore I will be writing a series of articles starting with this. I will be appending the links to the upcoming articles to this once those are published. In this article, I will try to cover EC2. But I will not cover obvious things like autoscaling, rightsizing since there are various resources and services which can be used for those. As an example AWS compute optimizer will show you if you have over-provisioned your EC2 instances. You should use these free services to maintain your infrastructure at an optimal state. In these article(s), I will cover not so obvious tricks which can further reduce the cost. These are just guidelines and to get the actual cost difference you can always use the AWS pricing calculator and get the actual difference.
Saving your EC2 costs.
Even though it is very easy to provision an EC2 instance these add up to the bill in a significant manner. So saving a few cents per hour can accumulate to a large number.
- Use a free OS
I have seen many people use Linux distributions like Redhat or Suse without any proper reasoning. Even though these operating systems are open source they have a subscription fee. Therefore the hourly cost is much higher than compared to an EC2 instance with an OS with no subscription or licensing fee. Amazon Linux 2 and Ubuntu are very good alternatives that fall to the latter category if your workload is compatible with these OSs (Most workloads are).
As an example, if you are running a custom Java application or off-the-shelf application like Jenkins or any DB you can run it using any of these OSs without any issue.
Amazon Linux 2 has enterprise support and it is a no-brainer. Once I faced an issue with an Amazon Linux 2 OS patching and AWS support helped to resolve my issue within a very short period of time.
If your workload runs on Windows your options are limited. But I have seen some sysadmins run Linux compatible workloads (e.g MySQL) in Windows instances because that is what they are familiar with. But spending some effort and migrating those workloads to Linux can save big time in the long run. Also, Linux instances are much secure and easy to maintain.
2. Always use the latest instance types.
Usually, when a vendor releases a new version of an existing product it is usually expensive. But in AWS usually newer types of EC2 instances are cost-effective than the previous generation. That means you get more computing power compared to the amount you spend if you use a newer generation instance. An example is given below.
So if you are launching a new workload that requires a general-purpose instance using m6 vs m5 is a no-brainer.
The tricky part of this is sometimes the AWS console has the previous generation as the default selection and people are too lazy to change it. I have seen this many times with burstable instances. Even though T3 has been available for a long time now, the default selection in the console is T2 which is the previous generation.
So the person who is launching the instance should aware of what are the latest generations and always use those for new workloads. Some examples are given below.
- M7 over M6,M5, M4, M3, etc.
- T3/T4 over T2
- R7 over R5,R6
- Etc.
Another reason for not using the latest generation is people are too lazy or sometimes afraid to change existing Cloudformation, Terraform, etc. scripts. But it would be worth it to periodically check whether your infrastructure as code uses the optional type of resources.
So far we discussed provisioning new instances. But changing the type of existing infrastructure to the latest generation can always save a lot of money. Most of these changes require only stopping the instance changing the type and starting again. If it is an HA setup it could be done without even a downtime.
Changing existing workloads to use the latest generation not only saves you some money but it will makes your application perform better since the new instance types have CPUs with higher clock speeds, more network bandwidth, etc. But the cost will be the same or less most of the time.
3. AWS Graviton
AWS Graviton is a CPU by AWS which has ARM architecture. The same architecture powers the new MacBooks. More details can be found here https://aws.amazon.com/ec2/graviton/ .
In the context of this article, the most important factor is the below statement from the above article.
Graviton2-based instances provide the best price performance for workloads in Amazon EC2
So if you are using an instance with Gravion CPU compared to an instance with X86–64 CPU by Intel or AMD you can get the same or more CPU power at a much lower cost.
The tricky part of this is that all workloads are not compatible with ARM CPU architecture without some additional work. But if your workload is cross-platform (e.g. an application runs on JVM) it should run on Graviton without any issue. Even if it is not it might be worth it to make it ARM compatible depending on the cost.
4. Instance types with AMD CPUs
Strangely, this is something that most people aren’t aware of. AWS has some instance types with two flavors. I.e Intel CPUs vs AMD CPUs(three if you consider Graviton explained in the previous point). Some examples are below
- M6i -Intel, M6a — AMD
- T3- Intel, T3a — AMD
- Etc.
According to AWS documentation, AMD instances are about 10% cheaper compared to their Intel counterparts. Source: https://aws.amazon.com/pm/ec2-amd/
The important factor compared to Graviton CPUs explained in the previous point is that both Intel and AMD have CPU architecture. So almost all the general applications can be run on both CPU types without any compatibility issues. If you want to test it out you can change your test environment(s) to an AMD instance type and if it works without any issue you can apply the same to production.
But there is a tradeoff here. AMD CPU performance can be a little lower compared to the equivalent Intel one.
So you have to decide whether you want optimal performance or the most cost-effective solution. There are some situations where AMD instances came handly for me.
- For non-prod environments. Non-prod environments get much less traffic compared to the prod ones so a slightly less powerful CPU is not an issue.
- For workloads that are not CPU bound. As an example, I have a prod workload that runs on a T3 instance with average CPU usage under 20%. So I could change it from T3 to T3a without any hesitation.
5. Scale down/ Stop your environments when you are not using them.
I am not going to discuss about auto-scaling patterns since it is covered in AWS resources itself. But sometimes you can stop servers/ environments entirely. As an example, if you have a dev environment you can stop it on the weekends. That will save a big cost. There are many ways you can achieve this. But if you do not take that complexity to your hand there are third-party services like Park My Cloud which could be used to do this easily. Even though these third-party services charge you some amount the cost you are saving might be much higher compared to that.
6. Using managed services vs. Installing software on EC2
As the final point, I want to highlight that as a best practice, you should always try to use a managed service instead of getting a bare EC2 instance and installing and managing software on it.
As an example, one can get a Windows EC2 instance and install and run an MSSQL DB in it. But instead, you can use the MSSQL service provided under AWS RDS. It would save a lot of money in the long run and the availability and performance will be better as well.