Minimizing Costs for Your Web App on AWS (after your free tier has expired)

Many developers first get their feet wet in AWS by creating applications inside of the free tier, which is great. However, after a year, your "free tier" application may hit you with an unexpected bill once the year trial is finished. This happened to me recently with my personal website.

Originally, my website had been running ECS with On-Demand t3.micro instances, along with an RDS database. After the free tier expired, my monthly bill went up to about $30 a month, which was way more than I wanted to spend - especially since I knew it was possible to get that price down. So, I spent some time changing my infrastructure to minimize my monthly fee, and this is what I came up with.

A Quick Warning

My solution may not be a perfect fit for your use case. The tools I discuss migrating to in this blog post may not be ideal for your own application, but for me they fit well. For example, I will discuss my move from RDS to DynamoDB, but this may not truly be a good fit for you depending on your data structures. Additionally, I will still be using ECS since my website consists of an Angular application along with a Golang API, but if you are using a static website you might save much more by hosting it in S3 instead.

Part 1: Moving Data Storage to Serverless

After your free tier is up, the cheapest version of RDS will cost you $0.016 per hour, or $11.52 per month. That's more than I'm paying for Spotify - didn't seem worth it for my use case :-).

So, I migrated over to DynamoDB. For those who aren't familiar, DynamoDB is a fully managed NoSQL, key-value database in AWS. DynamoDB is serverless, so there is no need to provision any database server like RDS - and also therefore no need for hourly charges. Instead, you get charged based off your usage, which is perfect if you are running a small website with lower loads of traffic. The price model is as follows:

• $1.25 per million write request units
• $0.25 per million read request units

One write request unit (WRU) is charged per write, and two for transactional writes (a write operation that groups up to 25 writes together, see here. One read request unit (RRU) is charged per read (up to 4 KB).

Some quick math - let's say I'm making 10,000 reads per day and 5,000 writes. For reads, 10,000 is 1% of 1 million so my price for those 10,000 would be .01 * .25 = 0.0025. For an entire year, that's only 91 cents! Similarly for writes, with 5,000 as .05% of a million, we would be charged 0.00625 per day and $2.28 per year - that's pretty good!

Clearly the cost savings here are a great reason of why to choose DynamoDB over RDS, but of course there are many other factors in considering this for your application. I won't go into detail about that here - but if you haven't had exposure with NoSQL or key-value data stores, I recommend looking at the pros and cons in these versus relational databases.

Part 2: ECS

If you set up an ECS cluster following the default configurations, you'll end up with a cluster using On-Demand EC2 instances and two EBS volumes (a 30 GiB root another 22 GiB one). This isn't bad, but there's some savings to be made.

For an On-Demand instance, you pay by the hour for your given instance selection. The current lowest price for an instance is the t4g.nano at $0.0042 per hour. There are many other nano instances, which notably have 2 vCPUs and .5 GiB memory. Personally, my app wasn't able to use less than .5 GiB of memory so I've used larger instances instead. I'm going to continue forward doing the price comparison with t2.micro, since this is the free tier eligible instance and will likely be in use by my target audience (however, this isn't to say you shouldn't consider other instance types!).

After the free tier is up, a t2.micro instance will cost you $0.0116 per hour, or a little over $8 a month. This isn't awful, but there are some better options depending on your workload.

If your website needs a dedicated workload, has higher traffic, or is unable to deal with small spouts of downtime every once in a while, then you may want to stick with On-Demand instances (or you could save some money by purchasing a Reserved instance!).

However, if your app does not meet the requirements above, then Spot instances may be the way to go.

Spot instances

Spot instances allow you to utilize unused EC2 space that is sold in the AWS marketplace. Since you are essentially bidding for this space, you're able to get some nice savings compared to having your own On-Demand or Reserved instance. Since this is an ongoing auction, prices do fluctuate; this still tends to be a much cheaper option. At the time of writing this post, a t2.micro spot instance is being sold for $0.0035 per hour which is about 70% cheaper than the On-Demand instance! For an entire month at this price, we would be looking at about $2.50.

AWS advertises a 90% discount for Spot instances which tends to be the average, so your discounts could likely be even more than this. Regardless of the exact amount, it's clear that this is some nice savings, and definitely something you should consider if you are dealing with a non-critical workload.

EBS Volume

Another small way to save is by removing the 22 GiB attached volume, or rather determining a proper size for the volume. The 30 GiB root has been enough for my simple use cases in the past. The price impact of this volume isn't huge, but if we're trying to minimize the price as much as possible this likely isn't needed.

Other Ways to Save

I may update this article later with more detailed instructions on these, but for the time being here are some other potential ways to save big on AWS.

S3

S3 (Simple Storage Service) is an object storage service that allows you to store images, HTML files, mp3, etc. for a decent price. There are many different tiers with different prices, outlined here. I recommend taking a look to see if any of these fit your needs. S3 can be a great cheap solution for deploying a static website.

Lambda

Lambda is a serverless solution for running event-driven functions in the cloud. Lambdas can be triggered by many different actions, but if you're building a website pairing it with API Gateway may be the solution you're looking for. Similar to DynamoDB, Lambda charges you based off of the number of requests you make (and also the time it takes for the function to run). This is great for when you have an inconsistent but somewhat low workload, as your costs will stay relatively cheap.

Final words

I hope this helps anyone who is new to AWS (but past the free tier) prevent themselves from racking up large bills on the cloud. For those who have completed AWS certifications or use it daily, this is likely nothing new. However, I hope this sheds light on some of the ways you can save for those new to the platform and looking to experiment.