Azure pricing multiple cloud services vs multiple web roles

190 Views Asked by At

Executive summary for the sake of clarity: Is it cheaper (in terms of compute-hours) to create two cloud services, each with its own web role, or have two web roles under a single cloud service?

We would like to create more than one web application on azure and would like each to have its own VM so they can scale independently. I understand that this can be done in two ways-

  1. Create multiple webroles under the same cloud service
  2. Create a cloud service and webrole for each

Option 2 is preferable to me because I understand that option 1 requires each webrole to have a different port number which could create difficulties with the SSL binding. Option 2 also means we can have a separate public IP address for each.

However, I'm trying to work out if it will be more costly in terms of billing to do option 2.

Currently we have a single cloud service and 2 webroles. Each is an A1 instance (single core), yet I notice in our detailed billing statement we are being billed 3 compute hours for every actual hour? Does this mean the cloud service itself incurs a compute hour? If this is the case, then this will be cheaper than having 2 cloud services in which case we will be billed 4 compute hours for the 2 A1 instances.

Detailed billing snippet:

"A1 Cloud Services" "Compute Hours" "US South Central"  "Hours" 24  "South Central US"  "Compute"
"A1 Cloud Services" "Compute Hours" "US South Central"  "Hours" 48  "South Central US"  "Compute"

Any other thoughts on the options and which will be cheaper and/or why we are being billed 3 hours for the 2 instances under a single cloud service?

1

There are 1 best solutions below

0
On

Answer: It costs the same in terms of compute-hours to run x web/admin roles under a single cloud service or to run x cloud services with a single role in each.

That answer is based on the answer I received from Microsoft and I'm busy confirming it by checking the detailed usage report. So, it seems that usage is based on the roles within the cloud service, not the service itself which is just some type of grouping entity. This makes sense since each role is effectively a virtual machine.