If your site is set up to run on a single instance and will always run on a single instance then I don't believe you should need to use service bus for remote events. If there's a possibility you may need to scale out beyond that one instance (license permitting), it might be worth leaving the service bus in place so that option is available to you.

The messages sent are primarily there to ensure that, when a content item is published, the relevant items in the caches on all instances are invalidated and rebuilt. If you're interested in what's being sent via service bus then you should be able to create an additional subscription to your service bus topic then, as I recall, you can view the messages it receives via the service bus explorer in Azure portal (or there's a standalone service bus explorer app if you prefer).

Hi Ricardo

If there is only one instance, and you will not scale up to more, then you don't need a Service Bus. It would just send to a topic, with no other subscribers.

If you don't configure an event provider, CMS will fall back to the NullEventProvider (which is just a black hole for the messages).

Thank you for all replies

As mentioned in previous emails, the only explicit usage for servicebus was is cache invalidation (when you install the CloudPlatform.Cms, it replaces the default event provider). However you need to make sure your 3rd parties are not relying on SB - for example using it for a queueing mechanism. It is not a very common use case, but it does happen