Azure Queue or Azure Service Bus Queue

Comparison Criteria	Storage queues	Service Bus queues
Ordering guarantee	No . Messages in Storage queues are typically first-in-first-out, but sometimes they can be out of order; for example, when a message's visibility timeout duration expires (for example, as a result of a client application crashing during processing). When the visibility timeout expires, the message becomes visible again on the queue for another worker to dequeue it. At that point, the newly visible message might be placed in the queue (to be dequeued again) after a message that was originally enqueued after it.	Yes - First-In-First-Out (FIFO) (through the use of messaging sessions)
Delivery guarantee	At-Least-Once	At-Least-Once (using PeekLock receive mode - this is the default) At-Most-Once (using ReceiveAndDelete receive mode) Learn more about various Receive modes
Atomic operation support	No	Yes
Receive behavior	Non-blocking (completes immediately if no new message is found)	Blocking with/without timeout (offers long polling, or the "Comet technique") Non-blocking (through the use of .NET managed API only)
Push-style API	No	Yes OnMessage and OnMessage sessions .NET API.
Receive mode	Peek & Lease	Peek & Lock Receive & Delete
Exclusive access mode	Lease-based	Lock-based
Lease/Lock duration	30 seconds (default) 7 days (maximum) (You can renew or release a message lease using the UpdateMessage API.)	60 seconds (default) You can renew a message lock using the RenewLock API.
Lease/Lock precision	Message level (each message can have a different timeout value, which you can then update as needed while processing the message, by using the UpdateMessage API)	Queue level (each queue has a lock precision applied to all of its messages, but you can renew the lock using the RenewLock API.)
Batched receive	Yes (explicitly specifying message count when retrieving messages, up to a maximum of 32 messages)	Yes (implicitly enabling a pre-fetch property or explicitly through the use of transactions)
Batched send	No	Yes (through the use of transactions or client-side batching)
Infrastructure	Part of the Azure storage infrastructure, feature a simple REST-based GET/PUT/PEEK interface, providing reliable, persistent messaging within and between services.	Part of a broader Azure messaging infrastructure that supports queuing as well as publish/subscribe, and more advanced integration patterns.
When to use	Your application must store over 80 GB of messages in a queue. Your application wants to track progress for processing a message inside of the queue. This is useful if the worker processing a message crashes. A subsequent worker can then use that information to continue from where the prior worker left off. You require server side logs of all of the transactions executed against your queues.	Your solution must be able to receive messages without having to poll the queue. With Service Bus, this can be achieved through the use of the long-polling receive operation using the TCP-based protocols that Service Bus supports. Your solution requires the queue to provide a guaranteed first-in-first-out (FIFO) ordered delivery. Your solution must be able to support automatic duplicate detection. You want your application to process messages as parallel long-running streams (messages are associated with a stream using the SessionId property on the message). In this model, each node in the consuming application competes for streams, as opposed to messages. When a stream is given to a consuming node, the node can examine the state of the application stream state using transactions. Your solution requires transactional behavior and atomicity when sending or receiving multiple messages from a queue. Your application handles messages that can exceed 64 KB but will not likely approach the 256 KB limit. You deal with a requirement to provide a role-based access model to the queues, and different rights/permissions for senders and receivers. For more information, see the following articles: Authenticate with managed identities Authenticate from an application Your queue size will not grow larger than 80 GB. You want to use the AMQP 1.0 standards-based messaging protocol. For more information about AMQP, see Service Bus AMQP Overview. You can envision an eventual migration from queue-based point-to-point communication to a message exchange pattern that enables seamless integration of additional receivers (subscribers), each of which receives independent copies of either some or all messages sent to the queue. The latter refers to the publish/subscribe capability natively provided by Service Bus. Your messaging solution must be able to support the "At-Most-Once" delivery guarantee without the need for you to build the additional infrastructure components. You would like to be able to publish and consume batches of messages.

Source : https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-azure-and-service-bus-queues-compared-contrasted