📅 Posted 2018-03-31
How much exactly? Turns out to be not a lot. This is a short write-up on the infrastructure costs of running a “serverless” CMS using AWS. The data is based on figures from March 2018, although the numbers don’t really change a lot from month to month.
Firstly, if cost was a primary goal, then the solution may be a little different. I know you could go down pretty thrifty routes with GitHub Pages + Cloudflare… However, the primary goal of my CMS product is to make the management of websites easy for business users. In addition, other goals include moving off running common solutions like Wordpress or Drupal and at the same time, investigating possibilities of a serverless architecture “in the real world”.
For more information on the architecture, make sure you check out my previous blog entry at Building a serverless CMS using AWS and Hugo. It’s changed a little since then, but nothing drastic.
- All figures are in USD, for the Sydney AWS region and exclude some minor services which sit in the “Free tier” easily catering for 100 or more websites.
- All websites are assumed to have a maximum of 2,000 unique visitors per month, which is quite low (all things considered) but normal for small business websites.
- Domain registration is excluded as this largely differs based on the TLD.
- Storage of data in DynamoDB is negligible as most sites have between 50 and 4,500 pages.
These costs don’t really change depending on the number of sites (at least at this scale) and are kind of a “minimum” entry cost into reserving serverless infrastructure on AWS like DynamoDB. These are not using the auto scaling capacity feature of DynamoDB mainly because I made the reservations a while ago and thought I might start with just using them and optimise later.
- Reserved DynamoDB capacity (assumed 3 years up-front, divided by 3) $205.20 (100 write units) + $41.04 (100 read units) / 3 = $82.08 per year
- DynamoDB (monthly, because AWS dips again even with reservations) $8.26 x 12 = $99.12 per year
- Cloudwatch alarms for DynamoDB tables and indexes (monthly) $3.11 x 12 = $37.32 per year
Total $18.21 / month
Costs per site
- Route 53 (assumed to be DNS hosting with AWS, which is comparatively expensive) $0.50
- S3 storage and retrieval costs $0.10
- Cloudfront delivery $0.17
- Lambda functions $0.01
- API Gateway $0.01
Total $0.79 / month
This is quite low per site, but keep in mind this doesn’t include the platform costs which are required to keep most features of the websites alive.
Example cost for 12 low traffic websites for a year of hosting
Why 12? Seems like a nice round figure to kick things off with.
Platform costs are $218.52
Per Site $9.48 x 12 sites = $113.76
Total per year $332.28 … or $27.69 per site per year
Comparatively, DynamoDB seems really expensive. Route 53 also seems quite expensive at this low end of the scale. Both of these costs are fairly fixed because they aren’t related to delivering content.
These 2 components alone are responsible for two thirds of the total cost which feels rough but at this end of the traffic scale, that’s just the reality of the AWS billing model.
DynamoDB could be replaced by a cluster of RDS instances but that would be cheating and would mean the solution is no longer “serverless”. We can’t have that.
What if we had more websites?
Say we had 100 low-traffic small business websites. What would the picture look like then?
Key assumption: capacity on DynamoDB would be enough to support the amount of sites. This could be tested based on the low rate of updates to existing sites and then extrapolated (basically, people don’t have a lot of time to make changes to their own websites and my website is no exception!).
Site cost would be $948 (100 sites) + $218.52 (platform) = $1166.52 per year… or $11.67 per site per year. That is great value.
Time for a graph
You can see the cost per site flattens out nice and quickly after the first few sites are set up.
Wrapping it up
AWS bills are a little unusual compared to most hosting costs. The way things are itemised are, in some ways, optimised for larger traffic volumes than what small businesses would be used to. However, there are some great savings to be had by simply using the tools and services wisely.
Now with recent features like backups for DynamoDB and auto scaling of capacity, the reality of relying on “serverless” capabilities over traditional RDS instances is becoming much more viable.