Well, it's impossible to give an universal response. It's like trying to guess how much you will pay on gas on your daily commute without knowing the distance o

Well, it's impossible to give an universal response. It's like trying to guess how much you will pay on gas on your daily commute without knowing the distance or the kind of car you're driving. It depends how much work is done in each "hit". If 99% of those 10k hits are to display the 10 most recent entries in a table, a very small setup will take you very far. A couple of 96 MB Python front-ends, 64 MB for SQL, you would pay maybe about $40/mo for a decent setup. Now if most of the hits trigger complex geographic queries against a database of millions of records, with a high write/read ratio, it's a whole different story. You need to know about the size of your working set (you can then infer your database memory requirements), and have a rough idea of the average request time and concurrency (to infer your number of workers, if you're using a synchronous server like most deployments of Django or Rails). While the "per-megabyte" price will be higher than "raw hosting", keep in mind that the granularity will allow you to do huge savings. Instead of paying for this 1.7 GB instance, you can pay for just 200 or 300 MB of RAM if that's what your app requires :-)