Service Bus

In this page we will look at the costs factors for Azure Service Bus.

Factors that affect cost

• Per hour charge for base charge for Premium and Standard

• Messaging Operations for consumption costs in basic and standard

• How many messages am I processing

• What is the throughput for messages that I need

• What advanced features which would influence my tier choice

Things to Think about

How many service buses should I have

Many customers have a lot of Service Bus namespaces.  They are pretty versatile and can be used for a number of different types of scenarios.

I think as a general rule if you are using Service Bus Premium they you should be very conscious of how many namespaces you have as the cost of each one is significant.  If you are using basic or standard then you may be less cautious as the costs are much lower.  There is still a cost though so dont go crazy.

Which tier of Service Bus should I use

This choice really depends on a balance of your requirements and cost.  The below table summarizes some of the choices.

Can I use a storage queue

In the right scenario a storage queue within an Azure Storage account can be a cheaper choice than Service Bus.  A storage queue is cut down to the bare bones compared to the advanced features Service Bus has.  You would be very unlikely to use a storage queue for an enterprise message broker because you would need many of the advanced features but in an “in application” queues processing scenario then a storage queue can be a low cost way to go.

Storage queues costs focus more on amount of data stored and message operations.

Some of the storage queue limitations include:

• Message size 64k

• Message retention 7 days

• No dead letter / ordered delivery / transactions / duplicate detection / scheduled messaging

• No topics / pub/sub

• HTTP only

If you want low cost, In Application, high throughput messaging then Storage Queues are a great way to go

If you want Cross Application, Advanced message scenarios.

Do I really need network integration?

A requirement for network integration will automatically push you to needing the premium SKU.  This is a big cost jump.

While Service Bus standard would have a public endpoint, you can lock down access to require Entra ID authentication which may meet your needs, especially in a non-production environment.

This is a key trade off between cost and security.

How important is shared infrastructure to me?

When processing messages at scale having dedicated infrastructure would give you more reliable performance levels and may reduce the risk of noise neighbours.

This may sway your decision towards a premium namespace.

How will my throughput needs affect costs?

The higher the throughput needs the more likely you are to need a higher tier of service bus.  Here are some key points:

Assuming 1k message size

• Basic

  • 1,000 messages per second per queue

  • 1,000 concurrent connections per namespace

• Standard

  • 1000 messages per second for non-partitioned queues

  • 2,000 messages per second for a partitioned queue or topic

  • 16 partitions could get you 32,000 messages per second

  • 1,000 concurrent connections per namespace

• Premium

  • 11,000 messages per second for each messaging unit (MU)

  • 16 MU could support 176,000 messages per second

  • Each MU can typically support 7,200 concurrent connections

While you can move up the tiers, if throughput is your sole need there may be cases where using multiple namespaces or queues would give you the desired throughput without scaling up.  A great example would be a partitioned queue on the standard tier.

Do the volume of messages I am processing make Premium make more sense?

If you look at the table below you can see some example scenarios which show approximate cost comparisons.

• The break even point for Service Bus Standard vs Premium is if you are sending around 800k messages per hour

• Note there are some costs ive assumed to have a minimal impact to approximate the cost comparison.  For example connection costs

Geo-Replication

Service Bus Premium has a feature for Geo-Replication.  This provides replication to a 2nd namespace in a different region which can be promoted to primary in a disaster scenario.

Before this feature became an option people would try to implement patterns which could achieve the objective having a DR approach but having this out of the box can be a compelling reason to move to the premium SKU.  There is so much complexity taken away from you here by the service which is very justifiable.

While this feature is still in preview, it is expected there will be the following charges

• The charge for the MU in the 2nd namespace

• The charge for the bandwidth to replicate messages

Geo-Disaster Recovery

The simplest way to explain this feature is that it is like Geo-Replication but only replicates the metadata and entities of the namespace but not the actual messages.

Pricing wise you will need the cost of the 2nd namespace MU’s but without the data replication there should be minimal bandwidth charges.

My gut feeling is when Geo-Replication is GA it would make most sense to have Geo-replication rather than Geo-disaster recovery because its such a bigger improvement in your availability and DR strategy that the additional cost of bandwidth would make sense for customers in that position.

Common Optimizations

Clean up unused namespaces

You might have namespaces sitting around which are not used.  If you have many standard namespaces which are no longer used then there is nearly $10 per month per namespace you could be saving.

Can I share a service bus

In cases where a customer has Service Bus Premium, it is much more likely they will look for scenarios where they want to share a service bus namespace across environments to reduce cost.   A common scenario is if the customer needs VNET integration this forces the decision to use premium.

Having a premium namespace for every non-production environment can get very expensive.

You can work around this problem by using a naming convention on your queues and topics then you can share the same namespace across multiple environments with each environment working with queues and topics specific to their environment.

Use Connection Multiplexing

With Service Bus SDK’s you can share connections within an application.  A single connection can send messages to multiple queues and topics.  This can reduce the number of connections you concurrently have with the Service Bus namespace which would then reduce one of the parameters which may require you to scale.

Closing idle connections

If your applications are maintaining open connections which are unlikely to be used then this can increase the number of active connections on the namespace.  This can require you to scale eventually or incur costs.

Use batching

Batching can help you save money by reducing the number of operations you use to perform actions.

As an example:

• If you send 1000 messages individually then you “pay for” 1000 operations

• If you send 1000 messages in batches of 100 then you “pay for” 10 operations

At scale this can have a significant reduction in your overall operations.

While the operation based costs apply more for standard and basic namespaces, it can also help you with a premium namespace where by batching would reduce the likely hood you would reach limits of a single messaging unit and need to scale to 2 messaging units in a busy namespace.

Batching can also reduce the number of network round trips your application is taking which can help with the overall cost and performance of your application.  A good example of this is a function app receiving messages in batches will have better throughput than one processing messages individually and reduce some of the parameters that might drive a requirement to scale.

As a ball park example for service bus standard where an application is receiving 10 million messages per month.

Savings = $7.2 (90%)

A few caveats in this case are that:

• I am assuming the hourly charge for the namespace are not in the scope of this calculation

• I am ignoring costs related to the sending side for messages and just focusing on receiving side

Consider Claim Check Pattern

If you are using larger messages there may be scenarios where you can save the message body in storage and pass a pointer message through service bus to where the payload is.  This is called the claim check pattern.

If you were in a scenario where you had messages larger than 256kb then you might be looking at Service Bus Premium to support your larger messages.  If this was the only reason you were looking at the premium sku then this pattern is an alternative approach which could save you some money.

Make sure to optimize available MU in Premium

If you are using the premium SKU then you can set rules in Azure to scale the number of messaging units available.  Making sure you only have just enough messaging units reduces waste and minimizes cost.

How can Turbo360 help

• Turbo360 can help you get a good visualization on the costs of different service bus namespaces across your environment

• You can create a tree node to focus on on managing just your service bus costs on their own if you want to

• You can investigate what is making up your costs using meter views holistically or within a resource

• You could setup monitoring just for the billing data of your service bus costs

• If you are seeing a large increase in the processing of messages that would affect your costs this would be spotted by the anomaly detection features

Useful Resources