Difference between Azure Queue and Service Bus Queue

This MSDN page shows in detail the differences between the two types (and there are many - in terms of performance, capacity, security, quotas, among others).

Basically, you should use Azure Queue if:

• Your application needs to store the equivalent of more than 80 GB of messages in a queue, where messages have a lifespan of less than 7 days.
• Your application wants to track the progress to process a message within the queue. This is useful if the job that is processing a message fails. Subsequent work can then use this information to continue from where the previous one stopped.
• You need server logs of all the transactions executed in your queues.

And you would use Service Bus Queue if:

• Your solution should be able to receive messages without probing the queue. With Service Bus, this can be achieved by using the long polling receive operation via TCP or protocol-based protocols that the Service Bus supports.
• Your solution requires the queue to provide guaranteed FIFO (first-in, first-out) delivery.
• You want a symmetric experience in Azure and Windows Server (private cloud). For more information, see Service Bus for Windows Server.
• Your solution should be able to support automatic detection of duplicates.
• You want your application to process messages in the form of long-running parallel flows (messages are bound to a stream by using the SessionId property in the message). In this model, each node in the consumer application competes for flows, not for messages. When a flow is given to a consumption node, the node can examine the flow state of the application using transactions.
• Your solution requires transactional behavior and atomicity when sending or receiving multiple messages in a queue.
• The TTL (lifetime) feature of the application-specific workload may exceed the 7 day period.
• Your application handles messages that can exceed 64KB but will probably not approach the 256KB limit.
• You handle a requirement to provide a role-based access template to queues, and different rights / permissions for senders and recipients.
• The queue size will not exceed 80 GB.
• You want to use the standards-based messaging agent AMQP 1.0. For more information on AMQP, see Service Bus AMQP Overview.
• You can predict an eventual migration of queue-based point-to-point communication to a messaging standard that allows seamless integration of additional recipients (subscribers), each of whom receives independent copies of some or all of the messages sent to the queue. The latter refers to the publishing / signing facility provided by the Service Bus natively.
• Your messaging solution must be able to support the delivery guarantee "at most once" without the need for you to create the additional components of the infrastructure.
• You would like to be able to publish and consume batches of messages.
• Needs full integration with the Windows Communication Foundation (WCF) communication stack in the .NET Framework.

The differences can be seen in the response sent by Carlos Figueira. Speaking of Service Bus Queue, it allows unidirectional communication. Provides load balancing, where messages are received and processed by competing recipients in the order they were added to the same queue. By moving this service to Azure, developers can work on distributed applications using the Message Queuing focused system. Thus, through the middle layer, an application creates and places a message in the queue, while another application processes and returns the first one in the same way (when necessary).

More information about Azure Service Bus can be viewed at link