Cloud infrastructure costs

Approximating compute costs for a mobile app

Ori Spigelman Founder at Spatter, Inc.

January 13th, 2014

I am working on a location driven mobile app.  I am trying to approximate the costs of running such a thing on top of AWS or Rackspace and clearly there are very many guesswork parameters involved with respect to adoption, usage, geographies etc.  Does anyone have a high-high level, back of the envelope, off the top of your head, way to approximate how much money you'd need to set aside to "assure" that your mobile app doesn't run out of compute power in year 1 ?  Underlying assumptions:  (1) low I/O rates (2) decent non-greedy design (3) supporting 1M users by the end of that time frame (optimism is key =)

Gil Benton Entrepreneur

January 13th, 2014

Very High Level- AWS will be a good way to go, and yes there are tons of parameters which could affect the cost of the hosting. AWS has a great pricing tool, but there will be some dimensions that you just may not know. I was running a mobile application company and we priced out a HUGE project for the government. We were WAY over estimating, and we couldn't even get our hosting costs above $20k / month. Having said that, you could easily support a simple app for much less. $2500 / month would get you some really substantial power, and the beauty is you can just grow your hosting with your success. Meaning, buy what you can afford in the beginning. As your number of users grow, or your hosting needs grow (I/O, data, backup, disaster recovery, etc), you can just ramp up your AWS services. It is NOT "click of a button" easy, but it is certainly easier than having your own machines, own data center, doing your own monitoring, backup, disaster recovery, etc. I would call AWS support, or go to their online pricing tool, and you can get within a few hundred bucks per month of your needs, even if you don't know the details of what you need. Just over estimate a little to be safe, but the pricing wont change that much. Gil

Michael Barnathan Adaptable, efficient, and motivated

January 13th, 2014

The answer is "it all depends on the app". A properly configured dedicated nginx/Apache web server can typically serve 5k-10k concurrent requests for static content with acceptable (second-range) latencies. That's likely to be an optimal case - dynamic content (e.g. app backends) will tax systems more. I've also noticed that many PaaS services such as Heroku and AppEngine have far less concurrency per worker, probably because they run your server in a single process (whereas a dedicated webserver can spawn workers).

There are a few measures which have become more or less standard practices - offloading your static assets to a CDN is a good low-cost way to eliminate bottlenecking there. Load balancing will become necessary once you grow past a certain point. Aggressive caching where you can do it (via a very fast cache, e.g. Varnish) will help save on the raw number of requests that reach the backend.

My suggestion is to start building the prototype with a design that will be easy to scale (such as REST, which distributes very nicely due to the stateless nature of REST requests). Do some load testing once it reaches prototype phase - there are tools like "ab" which can do quick benchmarks, or more professional ones such as which will simulate geographically distributed load for you. Figure out how many users you can realistically expect, then plan for that.

Don't prematurely scale (it's expensive and risky until you have evidence that you can get the customers), but do try to design your software architecture so that you can scale when necessary without having to rewrite half of your app.

praneeth patlola

January 13th, 2014

Looks like my copy/paste of xls did not work. here is the link to the same just in case, hoping it might be helpful.

Andrew Donoho President at Donoho Design Group, LLC

January 14th, 2014


Everybody's products are shaped by early choices. If you have a server team, then you will most likely build server products -- hammer and nail and all that. 

Let's remember that the opening poster/questioner wanted to know what server costs would be. I pointed out that a pay as you go situation is probably a lot cheaper. I'm not trying to get you or anyone else to change their mind. I am trying to get you to look at the real costs that come from running your own infrastructure. These are strategic decisions that are frequently made by technical teams based upon biases and history and not based upon goals or likely changes.

I bring this up because you made a rather astonishing claim, that you spend less than 1% of your resources running your servers? I find that very hard to believe. Are you appropriately accounting for your headcount that writes code for those servers? Are you accounting for weekend staff time when those servers go down? Are you accounting for opportunity costs when you are working on maintaining something truly mundane, such as making backups or upgrading to the latest version of something and that ends up taking your machines down. 

Lets be very clear. No one runs their servers in a server centric business, unless they are offloaded to some other organization, with just 1% of their resources. You are not sharing the real cost of your choices with the opening poster or the rest of us.

Let make sure this is a pomegranates to pomegranates comparison and not a comparison to a banana.


Andrew Donoho President at Donoho Design Group, LLC

January 13th, 2014

We implemented the Austin, TX Startup Crawl app on top of, As it is/was a one day event, we were not particularly frugal with our location based messages. Frankly, by spending $200/month on Parse, we can say you'l spend $2,400/year. It is really hard to build a 24x7 hosted solution as cheaply as that. If you out grow Parse, then you have the happy problem of migrating to your own infrastructure. But You will have to significantly overload Parse for that to become economically feasible.

Brian McConnell

January 13th, 2014

Ori, I use Google App Engine. One of the things I like about it (besides its auto-scaling and near-zero sys admin overhead) is they have great instrumentation that allows you to measure costs in minute detail (on a per transaction/API call basis). This enables you to get into the weeds and figure out where your compute costs are, and to optimize your app both for performance and cost. I've been using GAE for six years and am pretty happy with it. Regarding your question, its hard to answer until you've built your app since there are so many factors that can impact computing and hosting costs. That said, if you use a tool like App Engine's appstats, you can calculate the cost of each user interaction and build an accurate model of costs from there. Brian

praneeth patlola

January 13th, 2014

We recently did something similar to help a founder finish estimation for bplan. It is going to be almost impossible to come up with even a ballpark number with out having the actual app built out, as your tech stack would define what horse power you might need. Eg: How many background tasks or application specific requests to be handled. Your cost would be directly related to how many "concurrent users" you would have on your app, which would need Here is a sample of our exercise: iOS app targeted with API built out in Rails. These number might be more conservative. Below numbers are baselined for AWS and Rackspace would come down to the same numbers. If you have strong Devops/Engineering talent onboard, your can use Linode or Digital ocean to built out most of the below for 20% less cost. You also might want to consider costs for Email delivery (sendgrid) and File store cost (S3). To get more actual numbers, it is highly recommended to do LoadTest to see the scalability work in realtime. No of concurrent Users 100 1000 5000 10000 No of App Servers No of App Servers No of App Servers No of App Servers Webservers 1 10 50 100 App Servers 10 100 500 1000 Caching Server 2 20 100 200 DB Servers 2 20 100 200 LoadBalancer 1 10 50 100 Background Task Servers 1 10 50 100 XXXXXX app specific Processing Servers 2 20 100 200 Total (per month) $1,048.08 $10,480.80 $52,404.00 $1,048,080.00 A good place to start out is here for AWS: Praneeth Patlola Founder/CEO CrowdSourced Hiring Marketplace @praneethpatlola 512 963 3956

Tom Maiaroto Full Stack Consultant

January 13th, 2014

It all depends on your code. How your'e handling sessions. The database you're using. etc.

This is where architecture is SO important. It's also just an experience game. You likely will not know why until your servers are on fire and you need to fix or tune something.

If you're looking for real cheap VPS hosting, Digital Ocean is pretty good. I've only had minor issues with them (during some network upgrades - so my suggestion would be turn on several servers in different regions - but that's a good idea whether you're on AWS or Rackspace or anything else). Digital Ocean has SSD based VPS for SUPER cheap.

If you need bandwidth/network performance then you must stay with AWS. I work with a lot of analytics and data mining. There was no way I could do all that on anything else other than Amazon. You'll really start to see the difference between hosting providers when you need to make millions and millions of requests.  Of course this is outgoing...This is different than serving millions and millions of visitors - all which can be done with any of these hosting providers.

Anyway, like others have said it's going to depend on your app. How it's coded and what it needs to do. I just wanted to quickly point out Digital Ocean because it's the most affordable hosting option I've found. For the SSD performance.

Will Koffel Co-Founder at Outlearn

January 13th, 2014

Michael's answer is great, Ori.

One major consideration is the data side of things.  Compute resources are relatively cheap, and you can scale them up and down to meet need.  So start with a couple of m1.medium instances, perhaps, and see how they fare based on the needs of the application.

I large site I run on AWS uses about 12 m1.large instances running PHP, processing about 1000 API calls per second to mobile apps, just to give you one concrete measure of scale.  And I wouldn't say it's particularly optimized, it's doing quite a bit of work per request.

But the database is where things get tricky.  Both because you need additional redundancy in a way that you don't with the application servers (essentially two copies of your DB, Multi-AZ RDS, or whatever is equivalent for you).  And because the database typically can't scale up and down with traffic.  So you'll end up paying a bit more than you need to at the beginning out of fear of not having to shut it down to resize every time you hit a new capacity threshold.

Most small companies (< 1M users) don't do any sort of auto-scaling (meaning, spinning up and down resources during the day, so you have more capacity at peak hours and less over night), but if you really are trying to save cash, you can go that route.  Typically, the developer resources to build a stable effective auto-scaling solution aren't worth it, unless you get it "for free" via another platform layer (like, rightscale, etc.)

But heed what Michael says, don't worry too much about scale early on.  Spend more time making sure that your mobile application is flexible, well-behaved, can take behavior hints from the server, has the ability to enable/disable features of the app remotely.  That stuff will buy you flexibility to scale server-side as your needs demand.

Todd Ellermann Experienced I.T. Leader, CTO, and Creative Entrepreneur

January 13th, 2014

Here at VT we have a little over 1 Million registered users, but the real question for load, is how many will log in at a given time…. we run 100-200 concurrent member sessions but most of our load comes from researchers. 5-8 million/month. 

I think you should budget an average of 2000/month per 25 concurrent users.  BTW 100 concurrent users is generally about 1 million registered users.  This may vary widely with application profile, B2C vs B2B etc…  Our group mobile photo sharing application has a much higher cost and load because of all the photos we are shipping up and down, but the users only fire it up for a week or two once or twice a year.

Bottom line you aren't going to start with that load.  Budget $20,000 in the first year and you will likely have extra to play with.  If you don't, you are having success and revenue to cover the difference. :)