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
- Availability – do you need it on for the whole day
- Load patterns – is the usage uniform whole day
Classify your data in these buckets
- Availability – is it essential for operations, is it just for conformance, do I need to access it in real-time
- The sensitivity of data – is it confidential
- 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.