I subscribed to free 90 days azure trail offered by MS. I was excited and talked about it everywhere(including my blog http://techibee.com/windows-2012/free-try-windows-server-2012-in-azure-for-90-days/1876) about the free service offered by MS and how to make use of it. Well, my excitement lasted only for 7-8 days. Today I got a message from Azure team that my subscription disabled as my computer hours exceed the monthly limit.
I am just wondering how these compute hours are calculated in my case. I configured 2 VMs(2 medium) and using them to explore stuff. I never shutdown them since creation. Anyone has idea how these two VMs constituted to limits.
Another question I have is, since the subscription is disabled for this month, I am considering purchasing few more compute hours(pay-as-you-go). If I do that now, should I shutdown the VMs when I am not using them actively? will it stop the compute hours from increasing or they will continue to charge me for even shutdown hours. All I want is, I should get billed only when I am actively using it, when I am not connected to that host, I shouldn't. Looks like this is not happened in the trail program and their calculations seems different. Can anyone here given me some clarity?
From http://www.windowsazure.com/en-us/pricing/details/#header-3
Compute hours are charged whenever the Virtual Machine is deployed,
irrespective of whether it is running or not.
That's where all your hours went. You need to delete your VMs to prevent them using compute time.
With the free trial account you can configure only 1 VMs medium. Probably your offered expired early becouse you configured two.
Be aware that if you create a VM and you turn it off you will be charged the same as indicated when your turn off a VM.
Related
why managed instance taking more time to create?
It has been almost two days managed instance creation started and it is still showing deployment under progress. This is the first time I'm creating MI. Does anyone know how long will it take to create?
Very basic specification: Gen4 8 core 256 memory location: south central us
I don't see any error yet.
Creating first instance within a subnet takes few hours as Managed Instance is customer VNet-injected service and it takes time to provision the whole dedicated cluster - it's much more work than taking random pre-provisioned VM and spinning up few processes on it.
That said, anything that takes more than 6 hours (at the moment, subject of improvement) indicates some sort of issue.
I'd suggest opening support ticket, or you can contact me via private message with more details for the specific instance.
Two days is excessive, and likely indicates a bug in Azure's back-end scripts. When provisioning large amounts of objects in your Azure subscription, you can run out of resources within your 'Ring', which is a pre-allocated set of resources you have to work with. In the event you've exhausted these resources, it does take some time for Azure to provision more before the managed instance can be created.
I've deployed 10 or so Managed Instances and have seen deployment time take anywhere from
1 to 8 hours for a healthy deploy, and over a day for a deploy that ran into a bug.
I'm using Azure REST API to create, deploy and start a Cloud Service (classic) (cspkg hosted in Azure Storage) with hundreds of instances. I'm noticing that time Azure takes to provision and start the requested instances is really heterogeneous. First instances might start in 6-7 minutes but last ones might take up to 15-20 minutes, about 10 minutes longer than first ones. So my questions are:
Is this the expected behaviour? If so, what's the logic behind this? Could I do anything to speed things up?
How is Azure billing this? Is it counting the total count of instances since the very initial time when Cloud Service is deployed? or is it taking into account the specific timing on each individual instance?
UPDATE: I've been testing more scenarios and I've found a puzzling surprise. If I replace all the processes that my Cloud Service instances should run by a simple wait for some minutes (run .bat file with timeout command) then all the instances start almost at the same time (about 15 seconds between fastest and slowest instance). It was not just luck and random behaviour, I've proved that this behavior is repeatable and I can't even try to explain the root reason.
I also checked this a few weeks ago, and the startup time, depends on the size of the machine, if it is large it has more resources, so the boot time is faster, and also, if there is any error, exception on startup the VM will recycle till it can successfully start. I googled it, but did not find any solution to speed this up, so I don't think it is possible to do anything about the startup time. In the background every time when you deploy something, it will create a Windows Server, and boot it up and deploy your package on it and puts your web roles behind load balancer, this is why it takes so long, because a lot of things are happening.
The billing part is also not the best for the classic cloud services, you have to pay for it even during the startup and recycle, and even when it is turned off, so if you are done with your update, you should delete the VMs from your staging slot or scale it down, because you will pay for it even if it is turned off.
I have 2 specific scenarios that I can't get out of head regarding billing of windows azure.
Scenario 1: If I have 1 instance of say (web role, or work role, or reserved web-site) that sat idle for say 5 hours (by idle i mean no requests or processing or anything at all) will be billed for it? Or am I billed only for when I have activity on it?
Scenario 2: Am I billed for the actual size of my database or the size I declared when Ii created it?
This is quite hard to follow up and i would like to thank everyone in advance. Microsoft site is quite unclear and not straightforward about it.
1) each instance is like renting a car. That capacity is reserved for you and you're charged if its parked in the driveway (stopped), being driven in a parade, or cruising down the freeway at 60mph
2) a bit of both. The web and business editions have a minimum size you'll be billed at. But if you declare say a 150gb business Db, but only use 8, you'll only be billed at 10gb (the minimum).
For scenario 1, you are billed based on if the machine is allocated. So if you setup the machine once and leave it running, as long as it is running you are being billed. If you are just having a single server that needs to be available 24/7 (even though it might only do work for very short periods during the day), you need to account for about 720 hours per month at the bill rate for that machine size.
For scenario 2, you are billed based on the usages with minimums at certain tiers. See this document for more info: http://www.windowsazure.com/en-us/pricing/details/#data-management/
I'm an msdn subscriber and I'm looking at Azure as a possible platform for a new website that will test the water of a new service. This website is expecting low to very low traffic at the time of launch. I've heard that this kind of traffic levels is very expensive for Azure but since they have this msdn offer, I thought I'd finally take a look at Azure.
In the offer, I'm looking at getting "750 small compute hours per month". From the reading I've done, this seems that, if I purchase nothing more than what's given (although the subscription itself is thousands of dollars of course), that an entire month would be covered. Since 24 (hours) x 31 (max days in a month) = 744 I'm still below my allotted 750 for the month.
Am I missing something else from this simple equation? Is there further aspects that could cause the site to be "turned off" temporarily that should be considered?
Yes, you can indeed run a small instance during a whole month. Or you can have 2 extra-small instances instead (having 2 instances means you're covered by the SLA).
There are 2 other things you need to consider:
Depending on your subscription you can have maximum 45GB of storage (blob/table/queue). If you use Virtual Machines you need to know that the system disk (and additional data disks) are persisted as blobs, so make sure not to reach the limit here.
There are also other limits active, but the most important one besides storage is the data transfer limit which is also very limited (max 35GB out).
If you're expecting very low traffic, did you ever consider Windows Azure Web Sites? You get 10 of those for free during 12 months. The free ones run on shared instances, but they are perfect to host the first low-traffic version of your app.
I have a free trial account in Windows Azure...
Does the Compute Hours decrease if I run my app on localhost which is connected to SQL Azure?
Or it only decrease after I deployed my app?
Thanks!
Running instances in the local emulator does not count against your live compute hours.
Adding to #Oliver's answer: If you're just learning / testing, and want to conserve more Compute hours, be sure to stop, then delete, your deployment when not working with it (e.g. at night while you're sleeping). You can certainly leave it running 24x7 but each clock hour is a Compute hour, whether running at 0% or 100%.
Also: I believe the current 3-month offer is for 750 Small instances. If you use Extra Small instead, there's a 6:1 Extra Small:Small ratio, so you'll get more Compute hours with Extra Small.