none
Azure ServiceBus Pricing

    Question

  • We are trying to formulate a pricing model for our end users for our software built on top of the Azure Service Bus.

     

    However, I’m still a bit confused about pricing for the Azure Service Bus.

     

    For example, I see $9.95 for a pack of 5 connections.

     

    Does this mean I can only register 5 endpoints and only have 5 clients connected to those 5 endpoints?

    Or can I register 5 endpoints and have 5000 clients connected to those 5 endpoints?

    Or can I register 5 endpoints and have 5000 clients connected to those 5 endpoints but only 5 connected concurrently?

    Or can I register 500 endpoints and have only 5 clients connected at any one time?

    Or can I register 500 endpoints and have 5000 clients connected to only 5 unique endpoints at any one time?

     

    I haven’t found any clear explanation of what constitutes a connection in terms of pricing.

     

    • Moved by Steve Marx Saturday, September 18, 2010 3:24 AM service bus question (From:Windows Azure)
    • Moved by SrikumarV Tuesday, September 28, 2010 10:10 PM Migration (From:Windows Azure AppFabric)
    Thursday, September 16, 2010 7:36 PM

Answers

  • Are you saying that we are going to be charged for registering a service endpoint? If so, this is very different to the implied per connection fee. If this truly is correct, then yes, we are going to have to implement our own dynamic service endpoint registration plumbing code which really defeats the purpose of the service bus.


    Registering a service endpoint requires the service host to connect to the ServiceBus. This counts as one of your connections.

    And as I understand your requirements, you will need to implement your own dynamic service bus connectivity management if you want to control costs. This doesn't truely defeat the purposes of the service bus which is to allow services to meet at a middle ground by establishing outbound connections. Thus helping bypass NAT/Firewall issues.

    If you don't have a need for "near real time" communication between a host and client, then Azure Storage Queues are likely a more cost affective option for you.

    • Marked as answer by DaveSn Sunday, September 26, 2010 3:01 PM
    Sunday, September 26, 2010 12:36 PM
    Moderator

All replies

  • the way its been explained to me is this is connections, both service host and consuming clients.

    If you have massive connection scaling needs, you might be best served by putting a public endpoint in Windows Azure that can proxy/share the service bus connections by multi-plexing the connections.

    Thursday, September 16, 2010 7:40 PM
    Moderator
  • So, if it is actual connections, then I should be able to register 5,000 endpoints and have any 5 clients connect to any of those 5,000 endpoints at any time.

    The real world scenario is of a help-desk environment. Our software will be installed on 5,000 computers around the world and will be supported by 5 help desk operators. In this scenario, is my only cost $9.95 per month plus data bandwidth charges?

    As you can imagine, it is critical that I know the absolutely correct answer before we start selling on top of this service as any wrong advice could cost us $9,950 per month.

    Thursday, September 16, 2010 7:49 PM
  • End point alone does not directly map to a connection. In case of  multi casting, one end point can be used by multiple services and consumers. similarly, MessageBuffers are accessed through REST calls. Here is a brief extract from FAQ pricing section,

    When you create applications that are connected to the Service Bus, we charge you for each Connection, rather than the number of messages or the volume of data. These Connections result from opening services, opening client channels, or making HTTP requests against the Service Bus. 

     

    HTH.

     


    Please mark it as answer by clicking on "Propose As Answer", if it helps
    • Marked as answer by Yi-Lun Luo Thursday, September 23, 2010 8:43 AM
    • Unmarked as answer by DaveSn Thursday, September 23, 2010 10:41 AM
    Thursday, September 16, 2010 7:49 PM
  • This Service Bus forum post has some pricing details. I do think the FAQ and pricing page needs a lot more detail on this to avoid concerns like DaveSn's.

    The basic idea appears to be that Microsoft measures the average number of connections open for each five minute period. It then averages the daily maximum number of open connections over the month and charges $3.99 per month per connection in this average.

    • Marked as answer by Yi-Lun Luo Thursday, September 23, 2010 8:43 AM
    • Unmarked as answer by DaveSn Thursday, September 23, 2010 10:41 AM
    Thursday, September 16, 2010 10:30 PM
    Answerer
  • you'll need 5,000+5 connections.

    In your scenario, I would recommed hosting an endpoint in Windows Azure and use it to relay traffic to your on-premise service.

    • Marked as answer by Yi-Lun Luo Thursday, September 23, 2010 8:43 AM
    • Unmarked as answer by DaveSn Thursday, September 23, 2010 10:41 AM
    Friday, September 17, 2010 1:10 AM
    Moderator
  • DaveSN - I laughed a little when I saw all the "Unmarked As Answer"s above. 

    Yes, the service bus is expensive when priced per connection....but when you think about it do you really need the ServiceBus?  Most of the time you can simply have a WCF service published from your datacenter (SaaS offering)... or directly from your customer's site (on premise).

    Suppose you're in a situation where a remote user needs access to the server and the customer refuses to open the firewall for whatever reason.  This one situation requires the SB, but not every deployment does.  The solution is easy...  just  have the customer be responsible for paying Microsoft for the monthly fees for edge cases that require SB connectivity.  

    Now consider that it is possible to use both a WCF endpoint and an SB endpoint at the same time.  You just have to make your clients smart enough choose which one is active.  Let the customer choose and be responsible for the deployment edge cases.  You just be responsible for making an app that works either WCF or Service Bus.  This is where you just need to explain to the customer how this "add-in" feature is priced by MSFT and it's not under your control.

    This is the model I'll be taking for the free and paid versions of http://eventvwr.com (Event Log Managment Service) and http://perfmon.com (System performance monitoring).  Every SB endpoint (server and client) will be paid for by the customer and I inform them that my servers count as a client.  One thing I want to do (but haven't yet) when working with Azure Web/Worker roles is to make sure that I only have N connections to the bus at any one time.  Based on my beta experiences with Azure, I would have some roles active and working while not in my portal.  This 'lingering' state may have been corrected but I think it is wise to really think if you really need the service bus, or if WCF will handle your needs.... just use the SB for the edge cases. 

    Hope this helps

    Friday, September 24, 2010 3:46 AM
  • I'm trying to build a solution for my customers on top of azure. We have a distribution channel that can be several layers deep. I can't ask the end user to give Microsoft their credit card to use our service. They won't understand why nor how to control their usage. We need each site to register their endpoint on the service bus so that we can "dial up" the service running on their box. It's a catch 22. We need their endpoint registered so that we can access them when there is a service issue, such as updating our software or remotely diagnosing any problems. As far as I know, we can't use WCF through the firewalls if the service we wish to talk to hasn't registered on the service bus. I deliberately unmarked all the answers because none of them is the definitive answer that I can bet my business on.
    Friday, September 24, 2010 4:46 AM
  • I'm trying to build a solution for my customers on top of azure. We have a distribution channel that can be several layers deep. I can't ask the end user to give Microsoft their credit card to use our service. They won't understand why nor how to control their usage. We need each site to register their endpoint on the service bus so that we can "dial up" the service running on their box. It's a catch 22. We need their endpoint registered so that we can access them when there is a service issue, such as updating our software or remotely diagnosing any problems. As far as I know, we can't use WCF through the firewalls if the service we wish to talk to hasn't registered on the service bus. I deliberately unmarked all the answers because none of them is the definitive answer that I can bet my business on.
    Friday, September 24, 2010 4:46 AM
  • So most of the time the SB will be inactive?

    If that's the case, then have the client HTTP Poll your ASP.NET website at some interval waiting for a command to start the SB component.  That way you're in control of the connections and charges, and still get a heartbeat that you can track via ASP.NET and possibly SQL.

    Friday, September 24, 2010 12:47 PM
  • Just a thought: The target of the "polling" can either be a plain old ASPX page, or a BasicHTTP WCF service.  Not much complexity or overhead involved in either.  If your client may have a XML firewall you may want to poll the ASPX page since the XML firewall could kill both the WCF service and the ServiceBus.  Do share more info on your implementation when you decide what you will do
    Friday, September 24, 2010 12:53 PM
  • Right, most of the time there are no physical connections but I will have registered thousands of endpoints. We will have a team of service engineers that can connect to any one of those endpoints so the maximum number of simultaneous connections will be limited to the number of service engineers working. I don't like the idea of polling to our web service. Polling sucks and just chews up unnecessary bandwidth and resources although I'm sure that under the covers the SB does this for you anyway but I know it will do a far better job than we could do.
    Friday, September 24, 2010 3:29 PM
  • ok Dave, i think I finally understand what you're trying to do.

    Have you given any thought to running all your traffic through Azure Storage Queues? If your application, running at the client can periodically poll Azure Storage, you'll have a semi-controllable and much less expensive option for sending messages to a remote application. One of those messages could be telling it to create a remote service endpoint, a level of service you could then end up charging the client additional for to offset your costs or bake into your licensing fees.

    Its a bit clumsy, but would give you a great deal of flexibility. You could use the queues for basic communication where delays aren't critical (such as informing the app of updates, configuration changes, etc...) But when a more real time connection is needed, have it spin up a service bus connection.

    Thoughts?

    Friday, September 24, 2010 4:26 PM
    Moderator
  • DaveSn

    Would it be safe to say you want a new feature added to the Service Bus where a connection could be placed in a "pending activation" state that would keep the connection idle, unused, and not charged until you activated it?

    Sounds like a pretty good feature request if you ask me... and MSFT should write the code for such a thing.  Yes it would probably be implemented by polling, long lasting TCP connection, or variation of both.  Submit your idea here and I'll support you. (just be sure to post the link in this thread)

    http://www.mygreatwindowsazureidea.com/forums/34192-windows-azure-feature-voting

    In the meantime, polling Azure Storage, or your server seems like a pretty good option for the near term just so you can get version 1 out the door.

    Saturday, September 25, 2010 3:40 AM
  • Are you saying that we are going to be charged for registering a service endpoint? If so, this is very different to the implied per connection fee. If this truly is correct, then yes, we are going to have to implement our own dynamic service endpoint registration plumbing code which really defeats the purpose of the service bus.
    Saturday, September 25, 2010 12:38 PM
  • Ok, I've added the feature request: http://www.mygreatwindowsazureidea.com/forums/34192-windows-azure-feature-voting/suggestions/1087065-service-bus-should-not-charge-for-registering-an-e
    Saturday, September 25, 2010 12:51 PM
  • I added my 3 votes and a couple of comments...
    Saturday, September 25, 2010 1:26 PM
  • Are you saying that we are going to be charged for registering a service endpoint? If so, this is very different to the implied per connection fee. If this truly is correct, then yes, we are going to have to implement our own dynamic service endpoint registration plumbing code which really defeats the purpose of the service bus.


    Registering a service endpoint requires the service host to connect to the ServiceBus. This counts as one of your connections.

    And as I understand your requirements, you will need to implement your own dynamic service bus connectivity management if you want to control costs. This doesn't truely defeat the purposes of the service bus which is to allow services to meet at a middle ground by establishing outbound connections. Thus helping bypass NAT/Firewall issues.

    If you don't have a need for "near real time" communication between a host and client, then Azure Storage Queues are likely a more cost affective option for you.

    • Marked as answer by DaveSn Sunday, September 26, 2010 3:01 PM
    Sunday, September 26, 2010 12:36 PM
    Moderator
  • Service Bus pricing has been revised and we no longer have connection packs. The current Relay pricing model is based on the number of hours that you have at least one listener connected to an endpoint (at $0.10 per 100 hours) along with a message transfer charge ($0.01 per 10,000 messages of up to 64KB).

    This should provide a much more simplified pricing for your scenario.

    Wednesday, August 07, 2013 11:44 PM