Building an infinitely scalable cloud host for less than $5/mo
Tags: aws, scalability, serverless, lambda
Published: 2019-08-07 19:57:04

So I’ve got this idea called Wünderbucket. It’s [simple static web hosting for designer / developers who can only write HTML & CSS](https://wunderbucket.io). I really want to build an app that’s sustainable. And for me sustainable means _cheap_.

I need a system that:

- **Costs nothing if nobody is using it.** If my idea sucks or it takes me longer to find users then I think, I don’t want to be paying for resources that I’m not using.
- **Scales up automatically to meet demand.** If my idea connects and people start registering, I don’t want to hit bottlenecks. My system should just _scale_ to meet demand.
- **Scales up affordably to meet demand.** This is critical. As the system scales, it needs to pay for itself. I can’t fund an expensive hosting bill for a hobby.

Seeing as Wünderbucket is cloud hosting, this could get expensive quick.

## Paper napkin business model

My model is freemium with Pro plans at $5/mo & $60/year. I’m assuming that we’re going to have 99% free users and 1% pro users (pretty standard SaaS conversion metrics). That means **$5/mo has to pay for 100 users worth of cloud hosting costs and be profitable**. That’s not a lot of margin. 

- If cloud hosting costs are $2.50 per 100 users, I’ll need to get to 500k users before I could even support a full-time employee. That seems like a lot of users to support without any full-time employees. ![](https://files.nunn.ink/GoXqps.png)
- But what if hosting costs are only $0.05 per 100 users? Seems aggressive but it means I could get to sustainability around 200k users.
![](https://files.nunn.ink/WlCDl5.png) Still a lot of users but it might be more doable.

The dynamics of this business are pretty simple: The lower I can keep our cloud hosting bill per 100 users, the quicker this becomes a self-sustaining enterprise. Here’s how I’m going to design this system so it works for me:

## What Cloud to use?

There’s really only three options that are worth considering: [AWS](https://aws.amazon.com/), [Microsoft Azure](http://azure.com), and [Google Cloud](https://cloud.google.com). They’re all fighting for eachother's business and they’ll give you secret discounts so it’s pretty tough to choose. 

I’m going with AWS because I’m really familiar with their stack. I’ve used Azure and Google in the past and they would do fine too with the features I’m looking for. This is one of those situations where I need to lean on my past experience and move fast so even if those hosts offer some discounts up front, the learning curve isn’t worth it to me. 

Bottom line, there’s not any significant across-the-board pricing advantage between the major clouds. They’re all racing to the bottom with their pricing. Just pick the one that you’re the most comfortable with and has the features that best fit your needs.

Anyway, my pick is AWS.

## Web application costs

Here’s where we get into the first strategic decision. My service is going to have a [REST API](https://restfulapi.net/) component that clients will use to manage their sites. Clients will need to interact with this API every time they update their site but it’s impossible to predict how often that will be. No matter what, it needs to be quick and respond back to the client fast.

So let’s say I want to host my API web app on a couple of [EC2 instances](https://aws.amazon.com/ec2/) with load balancing. Pretty standard setup. 

![](https://thepracticaldev.s3.amazonaws.com/i/8c49rmb92qrq57dqvm9u.png)

Ok so with this model we already have a problem: the cost for my web application hosting is $61/mo. That means, I’d need to have 13 pro users and 1,300 free users before this broke even—way above the $0.05 per 100 users Holy Gail. This setup would have to easily support 120k users before it hit that number. I’m not sure two medium instances will be able to do that. And there’s another problem: I’m going to have to manually scale this infrastructure as my service scales: monitor response time, CPU usage, latency. That takes time and attention and more money. There’s a better way to do this. 

It’s called [Serverless](https://serverless.com).

So what happens if I build my application logic using [Serverless Lambda](https://aws.amazon.com/lambda/) functions behind [API Gateway](https://aws.amazon.com/api-gateway/)?

With Lambda I don’t have to worry about a server, I only need to know how much memory an API request is going to take and how long it should run. In my setup, each HTTP request translates to one Lambda invocation. All of my requests are only doing things like DB lookups and responding back to the client (nothing memory/cpu intensive like image resizing, etc) so I feel pretty comfortable using 128MB of memory for each invocation. But how many requests will my users make? Ok here’s some more paper napkin math:

- Let’s say each user will update their website 200 times every month. (Seems like a lot but let’s be aggressive here.)
- That means 100 users will invoke 20k Lambdas every month. Lambda charges $0.20 per 1 million invocations. That means _100 users will cost me $0.004/mo_.

But I also want to use API Gateway so let’s add that in too:

- API Gateway charges $3.5/million requests so that would mean that 100 users will cost me $0.07/mo.

The other benefit with Lambda + API gateway is that it automatically scales to meet demand. _If nobody uses it. I pay nothing._ If more people use it, I pay accordingly. I don’t need to monitor servers and try to match my EC2 instances to meet need. It all just happens. This is much more sustainable.

One more thing though, Lambda and API Gateway have a free tier. It’s going to be a while before I even need to start paying for them. With these numbers I can scale to 25k users before I pay anything.

**⚡️ Web application total cost per 100 users (after 25k users): `$0.074`**

## Database costs

*Sigh*, databases. It’s impossible to build a web app without them but they’re almost always the bottleneck and a great source of pain and suffering. If you don’t do backups right, optimize your queries and indexes, and set up replication correctly you can find yourself in a world of hurt. If your app is slow, it’s almost always because of your database. Fortunately my service has a pretty simple data model: we’re just tracking users, websites, and what’s in those sites. A fundamental requirement is automated backups and the ability to restore. A simple data model makes No-SQL a good candidate but let’s look at this with a few different scenarios:

- [Relational DB](https://aws.amazon.com/rds/aurora/) (MySQL/PostgresDB): If I go with a db.t3.medium instance (seems small but maybe it will work for my needs) that’s $60/mo. And there’s no “free tier” here. I have to get to 120k users before that becomes profitable. And based on my experience with MySQL, I have serious doubts that this tiny instance is going to scale to 120k users.
- [No SQL DB (Mongo)](https://aws.amazon.com/documentdb/): Mongo seems better suited to my needs but for the bare minimum—to host it on AWS using their fully managed option DocumentDB on a db.r4.large instance—it’s going to be $245/mo. No free tier. I’d have to hit 50k users before I even started breaking even on the database bill. I’d have to get to 1 million users before this became profitable enough to run at the margins I want. And there’s no way it’s going to scale up without changing instances from db.r4.large.25

So just to start development with any of those databases, I’d be immediately loosing money. 

But let’s look at [DynamoDB](https://aws.amazon.com/dynamodb/). 

Dynamo charges on requests, storage, and backups. Let’s crunch some numbers:

- **Requests.** There’s a pricing difference between read and write requests. My hosting service is going to be read heavy so I’ll guess a ratio of 20% write and 80% read. With my estimate of 20,000 requests per 100 users, the sum total requests would cost $0.054. ($0.05 writes and $0.004 reads).
- **Storage.** The data I’ll be storing is really small, even at scale, so I don’t anticipate going over the 25GB free tier.
- **Backups.** Let’s say that I get halfway to the 25GB free tier. My backups would cost $1.25/mo. This is the riskiest part here because, unless I clean out my data, this cost will just increase over time. Still it’s pretty cheap. I’m estimating that each user will consume about 10KB of storage. That means that backups will cost $0.00125/mo per 100 users.

**⚡️ Database total costs per 100 users: `$0.05`**

## File hosting

The last part of my service is hosting customer static web files and serving them up over a CDN. This is where things can get really dangerous. What happens if someone hosts a webpage with an embedded video and that webpage goes to the front of HackerNews and gets 200k visits in a single day? I need to be very careful how I structure the free and pro tiers so I don’t get killed with bandwidth and storage. Here’s what I’m thinking:

- Free users: 100MB total storage and 100MB transfer/mo. 
- Pro users: 1GB total storage and 10GB transfer/mo.

I’m building a static web host, not a media service. These limits should be more than enough for the average site with HTML, CSS, JS and images.

For the block storage I’ll use [S3](https://aws.amazon.com/s3/) and for the CDN I’ll use [CloudFront](https://aws.amazon.com/cloudfront/). (I’ll limit the CloudFront CDN to US and EU pricing just to make things simpler.)

- Free S3 storage costs: $0.23
- Pro S3 storage costs: $0.23
- Free data transfer costs: $0.084
- Pro data transfer costs: $0.85

Again at this model, I won’t start even going over the free tier until I break 5,000 users.

**⚡️ Data storage and transfer costs per 100 users: `$1.394`**

## Wrapping things up

One of the reasons I’ve written this article is that I wanted to show how big of an impact your technology and architecture choices can have on the sustainability of your business. You need to keep costs low when you’re starting out but you also need to keep them low as you scale. If you pick the wrong tech or price things the wrong way, you can find yourself with a hosting bill that you won’t be able to pay. But if you use technologies that are designed for your needs and budget, you can go from small to big while maintaining a healthy profit.

To recap, here’s the ranges of pricing scenarios that I covered in this article:


- $306/mo to just start. I’d need to hit 6,000 users before I started to break even. About 300k users before I start making a healthy profit. But I would need to increase my infrastructure to accomodate. It’s likely that at 300k users, I would have be running a $5k/mo infrastructure bill for my EC2 instances and database hosting, giving me a $10,000 profit margin. That’s not bad but it’s barely enough for a full time employee and this system would need constant infrastructure maintenance to continue to grow.
- $1.424/mo to start. Automated scaling. Zero server maintenance. Instant profitability, even with small amounts of users. If I get to 300k users, I’ll be able to host them and make a $13,800 profit. The best part is that this would automatically scale up to meet the demand, allowing for investment in the product instead of investing scaling the infrastructure.

**⚡️ Final hosting costs per 100 users:  `$1.424/mo.` `$3.58/mo` profit.**

That looks pretty sustainable to me.

===

Obviously there’s other ways to make your business profitable than just picking serverless, cheap technologies. You can raise your pricing, increase conversion rates from free, reduce the amount of expensive features you give your free users, etc. But my recommendation is to go cheap when starting out. Build a business that automatically scales with your success and doesn’t punish your wallet for early experiments. Hit me up if you have any questions. Have fun!