Building February’s Hosting Bill: $1.85.


Earlier this week, I wrote about how we designed the database for Because we went with AWS DynamoDB for the database storage and AWS Lambda for the processing work, costs are really, really low:

PollGab hosting bill, page 1

That is not a typo: that’s $1.85 USD.

Richie puts the business logic in functions, and those functions run in AWS Lambda. That’s the compute power, or what used to be known as an application server. It was completely free last month because Amazon gives you the first 1,000,000 requests totaling less than 3.2M seconds of compute time (889 hours, aka 37 days) free of charge. We’re in the free tier for data transfer and email services as well.

We spent $0.04 on Amazon S3, aka file storage. I honestly don’t remember what we’re putting in file storage, and at four cents, I’m not gonna bother to look.

Scrolling on down to page 2 of the bill:

The free tier of DynamoDB includes up to 25GB data and enough capacity to handle about 200 million well-written queries per month. My kind of database right there.

The most expensive thing in our hosting bill is $1.01 for Route 53, which is DNS. When you type into a web browser, DNS is the magical service that tells your browser where to go.

This incredibly exorbitant pricing is due to the fact that each domain costs $0.50 per month, and we have two domains. ¯\_(?)_/¯ We’ll have to learn to live with that expense.

Next up is $0.74 for CloudWatch, which is monitoring. Yes, that’s right: monitoring is 5-6x the cost of the rest of our infrastructure combined, hahaha. Upon reading that, my first reaction was, “I have to stop what I’m doing and check CloudWatch’s settings.” After spending approximately $0.74 worth of my time, I realized that I was already sidetracked because we were getting write alerts in the dev environment. I abandoned that task.

So why does PollGab cost $59 per year?

Well, the hosting part is doggone near free, but the development costs certainly are not.

Building a cloud-native application is about spending more development time up-front in exchange for lower long-term costs of ownership – both lower hosting costs, and lower systems administration costs. By himself, Richie’s been able to crank out PasteThePlan, SQL ConstantCare®, and and more over the last few years, and we haven’t had to hire sysadmins or support teams.

The hosting costs on these do indeed go up as they become more popular – but as they gain more paying customers, it’s much easier to get apps like this to become profitable, and keep them that way. That’s where cloud-native pays off.

Previous Post
Who’s Hiring in the Database Community? March 2022 Edition
Next Post
Office Hours: 7 Questions for You to Answer Edition

10 Comments. Leave new

  • Hey Brent, sweet new site! I noticed a discrepancy. The checkout page pricing says $59/year, but the post here says $59/month. I think the confusion may deter some potential customers.

    As always, thanks for all the awesome tools!

    • Ah! You’re absolutely right, it’s $59/year. Doh! Fixing the post. Thanks!

      • Damien Jones
        March 3, 2022 7:37 pm

        It was good to read a blog about cloud costs in your style Brent. Thanks for taking the time to write it! Most of the costs here are trivial but CloudWatch can spike from time to time depending on what’s going on, so maybe consider setting up an AWS Budget if you haven’t already.

  • Richie Rump
    March 3, 2022 4:52 pm

    Brent, S3 holds all of the client-side files like HTML/JavaScript/Images. But 4 cents to too much. We need to figure out how to lower it.

  • I apparently need to shop around for domain names. 🙂

  • The model of ‘spend a lot on development to save operational costs’ has been a bit of a paradox everywhere I worked on projects towards that.

    at several clients sites that had huge hardware and software costs, they would begin by addressing legacy systems, sprawl, superfluous applications and if custom apps were messy enough, refactor and optimize them to make them easier to understand and support in preparation for moving to a solution like the above. I had one client that was able to retire an entire SAN cluster just by cleaning up some horrible queries and disabling some near real time jobs for data that was done by batch only and never after office hours. In the end, all of them had their hardware and software requirements so drastically reduced that they lost interest in spending more money to port everything to full *aaS deployments, or ended up only moving a handful of small, inconsequential items while leaving the rest

    • Right – you’re looking at EXISTING apps.

      If you look at existing apps that already spend a lot, then it’s hard and expensive to make changes.

      The time to decide cloud-native vs conventional isn’t after you’ve already built the app. It’s before.

  • Hey Brent – clicking on “Claim your URL” from the page leads me to a dead end. Tried it on several browsers. Could be me… but maybe not.

  • These emails are great. BTW, I drilled into the Robert Davis article about “neat solutions” and hit a WordPress error. Was looking forward to reading on…


Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.