Single simple answer to multiple questions: Azure does not do processor-time billing. Azure does VM-time billing similar to how Amazon AWS bills. It is more "infrastructure" like in this regard. You decide how many VM's you want to rent
and what their sizes are (there are 5 sizes available: Xtra-SMall, SMall, Medium, Large, Extra-Large, although only the latter four are good enough for production environment).
Azure bills you per VM per hour. Regardless of how busy that VM is. Azure also bills for the amount of data coming out of the data center and for the space you consume OUTSIDE of VM's like in SQL Azure or Azure Storage.
Azure does not auto-adjust quantity of your VM's or SQL Azure databases automatically in anyway. You're in full control. You can program the auto-adjustment (autoscaling) yourself - there are a few examples on the web, including the WASABi application
block. Or you can take the easy way out and use a service like AzureWatch (link in signature).
Thus, your answers are:
1. It doesn't matter that your app doesn't do anything. You will be billed for the amount of VM's running per hour. So, in times when your app is not doing anything, scale down to 1 or 2 VMs (depends on your SLA requirements).
2. You can run as many threads on your VM's as your VM's can handle. You're not billed for threads.
3. Your app slows down and you should consider scaling out to more VM's.
4. Yes but only if you build it yourself or use something like AzureWatch
5. SQL Azure is not billed by queries. Only amount of space consumed. Data transferred outside of the Azure data center boundaries (regardless of it was originating in your VM's, or SQL Azure, or Azure storage, etc) also has a fee per gigabyte
6. You're not paying for memory separately than for CPU. You're paying for a VM per hour. Up to you to decide what size is optimal for the amount of ram/cpu/cost that you get. Only 4 real choices available.
7. Ditto.
8. Azure has a number of DDOS preventative measures at the data center and load-balancer level. If there is some DDOS attack that does get through you will unlikely be charged alot unless you start scaling up out of control and
don't notice it for weeks. Since most of the requests are inbound during a DDOS attack, you're not charged for them, only for data responses that they generate. I've had this discussion with a few folks on a LinkedIn group who were
afraid of letting automating systems like AzureWatch scale them out of control during a DDOS attack. Because it sounds "scary". But reality is too boring. During a DDOS attack, you will likely be scaling up up no more often than once per15
minutes. Thus, even if you chose to not set any safety limits to scaling up in a service like AzureWatch, and you raise your Azure quota to 200 cores (by default it is 20 cores), you would have to ignore scale-up alerts for 24hours to ring up a mighty
bill of $5.76 (assuming you scale up by a single core once per 15mins for 24hrs). Your business impact of the DDOS will be much greater than Azure charges.
Hope this helps.
Auto-scaling & monitoring service for Windows Azure applications at
http://www.paraleap.com