Stop Paying AWS Tax – Engineers Guide to AWS Cost Optimisation

Are you overpaying for your AWS infra?

That was a rhetorical question. I know you are. If it makes you feel any better you are in company of almost every company out there who is using AWS. Here is a guide to save 10-40% on your AWS bill.

Let us get started.

The first question you need to ask yourself is what is the nature of load on your servers as well as type of data you deal with.

Classify your services in these buckets

1. Availability – do you need it on for the whole day
2. Load patterns – is the usage uniform whole day

Classify your data in these buckets

1. Availability – is it essential for operations, is it just for conformance, do I need to access it in real-time
2. The sensitivity of data – is it confidential
3. Mode of creation – primary, derived

Now let us get into AWS specific dirty details.

AWS Instance Optimisation

Instance type

There is a great likelihood that you are using a wrong instance type. First thing is that upgrade to the latest instance types. Prices keep going down with time for hardware. If you are on t2, look at t3. If you are on t3, look at t3a.

Instance Size

How daoes a 2 week graph of CPU Utilization for your instance look like. If your usage is less than 30% for most of the time, You can move to a lower size without blinking. If you opted for a higher size because of RAM requirements you might want to look for memory optimized instances.

EBS Storage

What is the percentage of disk usage on all your servers? Overestimating the disk usage is one of the most common mistakes. Make sure that you are not paying for disk space you are not using. Do you have any old snapshots or volumes lying around?

Unused Elastic IP adresses

AWS won’t charge you for Elastic IPs which are attached to instances but they will charge you for IP addresses which are not attached. Free them up to save some dollars.

Databases/Storage

First thing is to figure out the type of storage you need. Different types of storages come at a different cost. And the appropriate medium also depends on your access patterns of the data.

Rightsizing RDBMS/RDS

If you are using hosted RDS/Aurora services it is a good idea to check the CPU usage of those instances. If you are using it below 30% you can downsize it for sure.

Backups/Snapshots Deletion

You might have automated or manual snapshots of databases which you might not need. They will add to your cost. For the databases which are not production databases, you might want to disable automated backups.

Multi AZ Deployments

Multi AZ deplyments will cost you twice of regular deployments. Make sure you use it only if you need it. If you have non-production servers, you can disable it on them. Even on production servers, evaluate if you really need them.

Archival Process

You might want to archive your data which is not used any more to cheaper storage mediums which are better for Archival ( eg. Glacier ). Rightsizing the active databases also makes sure that your queries will return faster and will require lesser resources.

Caching Layer

This directly does not save price but it helps you in reducing the load on your storage layer and enables you to save significant money there.

Amazon Services

Amazon provides various hosted services which are very useful – ElastiCache, Elastic Search, Dynamo etc. But all these services come at a cost. It is fine to use these services if you do not have the devops bandwidth to manage them otherwise you might to run them on your instances.

Route 53

Do you have domains configured which you are not using at all. They might be leaking you few dollars per month for no reason.

Kubernetes/Beanstalk Scaling

Lot of people setup auto scaling on their environments even when they don’t need it. Horizontal scaling is not necessary in lot of cases. Simple vertical scaling works for most of the smaller enterprises. All these solutions come at a cost so better stick to vertical scaling unless you have too much variation in your usage and you are managing a very large cluster of servers.

Conclusion

Right architecture and active monitoring of your resources is key to optimize your cost. Throwing extra hardware is not the solution for writing bad code. Build a culture of usage-based approval processes for new hardware. You can make rules like only when you use more than 50% of a resource, you can request a new resource. Ask teams to run multiple services on a single server. Don’t let various teams maintain their fleet of servers as their kingdoms. Cost optimization is as much about culture as it is about technical knowledge.

Happy Cost Cutting.

PS: Feel free to contact me if you are a startup and need free advice on cutting AWS costs in these challenging times.