Trying to manage your AWS costs? It can often feel overwhelming, and you may struggle to figure out where to start. And for good reason, there’s over 200 different aws services, all with a slightly different pricing model, and it can be difficult to know how to optimize cost for each one. For many, cost ends up becoming an afterthought that only comes up once you’re application is in production.
Now over the past 8 years of working with AWS, I’ve faced my fair share of challenges grappling with my cloud bill. I’ve also learned a bunch of simple things you can do to ensure you’re not spending more than you need to.
So in this article, I’m going to share with you my Top 5 Cost Optimization Tips That Every AWS user should know. These tips will apply regardless if you’re a beginner to AWS or even someone with experience that isn’t very cost conscious. I guarantee you’ll learn at least one thing!
Tip # 5 – Rightsizing your Workloads
Rightsizing your workload is the process of matching the infrastructure you provision with the workload requirements of your application. The goal of right sizing is to eliminate waste by using the right type of infrastructure that will minimize cost, while at the same time not compromising application performance.
Rightsizing as a concept applies to many AWS services, but the way you apply it can differ depending on which service you’re working with. Lets take a look at two examples across different areas.
For compute services like EC2, the rightsizing lever we have at our disposal is instance type. To optimize costs, we should look at a metric like the existing CPU utilization, Memory Usage, and Network Bandwith of our instances. You should generally try to keep your average utilization at around 80% of capacity. If you’re utilization across any of these metrics are low, it may indicate its time to drop down the instance type or select a more suitable instant class for your application.
For storage services like S3, there are a multitude of different storage classes at our disposal. This includes general purpose, infrequent access, Glacier, and more. Each of these storage classes offer different performance, availability, durability, and of course cost. Rightsizing for this category would involve evaluating the needs of your application and picking the right type. For example, general purpose mode is great for frequently accessed data that require high levels of durability with low and reliable latency. Glacier on the other hand is a fraction of the cost and acts has performance characteristics that make it best suited for data archiving use cases.
The key takeaway is that the steps you take to rightsize will be different depending on what service you’re working with, and a combination of performance, availability, or durability needs of the service. However, the simple principle stays the same – pick the option that minimizes cost and allows for enough application headroom to function.
Tip # 4 – Beware of Egress and Ingress
Egress and Ingress refer to data transfers across network boundaries. This can be data that’s moving across internal networks, data centers, or even data moving via the public internet.
In AWS, charges can apply when data moves across certain network boundaries. It’s important to be aware of when charges may apply so that you can avoid them if possible, or at a minimum factor them into your budget when you’re working on a new project.
Here are a couple important ways that AWS charges for data transfers that you should be aware of:
First is data that is transferred between AWS and the internet. For uploading to AWS no charges apply, but for moving data out of AWS through the public internet, be prepared to pay. What makes this even more complicated is that the amount you pay is dependent on which AWS service you’re using. For example, to transfer data out of your S3 bucket to your home machine via the internet, it would cost you approximately $.09 per GB for the first 10 terabytes. So if you have 1 terabyte to retrieve, you’re looking at about $90 in data transfer costs alone.
Next is data that is transferred across AWS Regions. Regions are the general locations of a collection of different AWS data centers in a particular geography. Some of the popular ones include us east 1, us west 2, and eu west 1.
Cross region transfers are sometimes encountered when users try to ensure better durability by replicating their data into another AWS region. Despite being a good idea in principle, this can end up costing you. Costs are dependent on the source and destination regions, but you’re generally looking at a couple of cents per gb transferred on average.
Finally, data moving between different availability zones, but within the same region, is also charged. This can sometimes occur when an application hosted in one AZ is attempting to communicate with another component, say a database, in another AZ. For this type of scenario, you would be charged one cent per GB in each direction for your component. This may not sound like a lot but bulky and frequent dataabse queries can quickly result in a lot of data transfer costs.
Tip # 3 – Make use of retention policies
My next tip for you is to leverage data retention policies whenever possible. This typically means to set up some kind of timed migration to move your data either from one service to another, or using a different storage classification that has better cost options.
Where I’ve seen this bite particularly hard is with Cloudwatch Logs. Cloudwatch logs charge a mind boggling 50 cents per gigabyte. With any high throughout or chatty application, this can easily end up costing an arm and a leg. An easy mitigation is to use the migration policies that cloudwatch provides.
Using this method, you can easily configure your log groups to be archived to something more affordable, like Amazon S3, after a pre-determined period of time. This way, you can keep only your most recent logs in Cloudwatch for easy analysis, while moving less important logs to a long term storage option like S3 Glacier.
Tip # 2 – Use the AWS Pricing Calculator
My next tip for you is to leverage the AWS Pricing Calculator. This tool is provided by AWS for free and makes it easy to get a rough idea of how much an application will cost before you ever egin developing.
You can use it for any AWS service and create hypothetical estimates based on your specific usage to get an estimate. For example, in this clip, here I am creating a pricing plan for using Amazon S3 and viewing the estimated cost breakdown at the bottom.
I’ve used this tool multiple times and I can’t say enough positive things. Be sure to leverage it for any upcoming project. You can access the tool here.
Tip # 1 – Design your applications with cost in mind
This last tip is arguably the most important, and oddly enough, the one that is most often overlooked. The tip is to Design your applications with cost in mind.
A disturbing trend I’ve been noticing lately is developers designing entire application architectures without considering cost. Its only when the application is designed and ready to e implemented do folks run the numbers and try to produce a cost estimate. This is a sure fire way to run in to some nasty surprises that are hard to undo.
This is without doubt the wrong way of doing things.
In my opinion, cost considerations should be applied at the design phase. This is so that any quirks in how AWS charges you are accounted for, and a different more cost effective solution could instead be proposed. Its important to remember that a service or feature that looks attractive at face value can sometimes be ridiculously expensive for your particular use case. Be sure to be cost conscious while you’re developing to avoid any surprise bills.
An easy way to implement this in real life is to require a Cost section in any design document. Having a dedicated discussion on cost estimates show that the author put thought into cost effectiveness and the potential for alternative options. It also gives reviewers an opportunity to identify and gaps or red flags that may not have been considered by the design author. I’ve found that tip is an easy mechanism that helps develop a culture where cost is at the forefront alongside design and implementation details.
I hope you enjoyed these top 5 tips. Let me know down below what tip you think is most important in terms of cost and any important ones that I may have missed. Thanks so much and I’ll see you next time.
