When you're building a new app based around a handful of these services, how do you have any idea what it will cost to host your business on a startup? In the past I've avoided using these, and just used VPS servers doing my own thing, because it's really hard for me to, for example, guess how many database queries I'll do or messages I'll send between app components. I feel much safer saying that I can limit myself to N servers with so much memory. How do you make that jump to thinking the other way?
Well, there's a cost calculator that you can use to get an idea (though it requires understanding their services somewhat to put it together correctly):
http://calculator.s3.amazonaws.com/index.html
You can also set up billing alerts, though as has been discussed, they aren't strict caps, so you can still exceed your cap.
You can start with just a few EC2 instances, so conceivably, you could everything on those you'd do with a VPS.
Maybe you decide that managing a database is taking too much of your time, so now you're looking at RDS. It's more expensive, but, it manages just about everything for you. Maybe you make the decision to switch to RDS Now you turn down that EC2 instance running your database.
Maybe now you're thinking that RabbitMQ is too much of a pain to manage, so you do the same thing with SQS. Analyze the time/cost savings of switching, and see if it makes sense.
I think for new applications, estimating is a lot harder, right? You have no traffic until someone is interested in your product, but you can sort of spitball. There's a bunch of free load testing services out there to let you roughly simulate N concurrent users, and open-source projects to simulate those users yourself.
Ultimately, and maybe someone has an idea how to do this: I don't think you can ever plan beforehand. You could be optimistic, and assume your app is going to explode, and that you'll need 8 web servers and redundant load balancers and DB with a read replica... but that's just what it seems like, optimistic. I think the closest you can get is spitballing -- assuming maybe you'll get 100 concurrent users or something -- and making sure you can handle that.
Separately, there's the whole issue of trying to make smart decisions ahead of time with your infrastructure, but similarly, this can be really hard to do.
The good thing is that services and charges that are hard to estimate (SQS, egress network bandwidth, S3 access charges) are mostly drops in a bucket compared to those that are easy to plan for (ec2, RDS, S3 / Dynamo storage).
Right. There's a lot of simple choices you can make -- SQS instead of RabbitMQ, ELBs instead of HAProxy -- that aren't going to cut your burn rate in half or anything.
The estimation part is definitely very hard to do for the things you mentioned at the end, especially things like DynamoDB which want you to specify throughput. Not only do you spend time on that, you then spend time on handling when you exceed your provisioned throughput, etc. There's a lot of time spent thinking about shit there.
Anywho, I agree overall. Some of their services just make sense to use because you'll be hard pressed to paint yourself into a corner with them.
I'd say run on Heroku, but IIRC they gave up on their free plan. You could run on Google App Engine though, IIRC they still offer a free service up until a certain number of requests or CPU usage or something in that direction. You could use those to determine how much your application actually uses the service.
IIRC, Amazon also offers services for a fixed monthly price, you could look into that too.
