AMQP is a wire-level messaging protocol standardized by OASIS and adopted as an ISO/IEC standard, designed for reliable, interoperable messaging between applications and messaging systems. Unlike protocols that assume a particular server model, AMQP 1.0 defines only the protocol between peers: what a message looks like on the wire, how it is transferred, and how delivery is negotiated. What sits on either end of that wire — a broker, a client, a bridge, an application — is up to the implementation.
This guide explains what AMQP 1.0 actually is, why it exists in the form it does, how its message and transport model work, the delivery guarantees it offers, its security model, and how it compares to the other messaging protocols people typically consider alongside it. It is written as a technical reference. Each major mechanism summarized here can be explored in its own dedicated article in this category.
Table of Contents
AMQP 1.0 at a glance
| Property | Detail |
|---|---|
| Full name | Advanced Message Queuing Protocol, version 1.0 |
| Standardized | OASIS Standard, 29 October 2012; ISO/IEC 19464:2014 |
| Model | Peer-to-peer wire protocol; server model deliberately unspecified |
| Transport | TCP; TLS is standard for encryption |
| Encoding | Binary, self-describing, with typed primitive and composite types |
| Message flow | Between nodes, along links, with source and target endpoints |
| Delivery outcomes | Accepted, Rejected, Released, Modified |
| Settlement modes | Configurable per link (sender and receiver) |
| Authentication | SASL (PLAIN, SCRAM, EXTERNAL, and others) |
| Broker required? | No — a broker is one kind of container, but not mandated |
| Primary use cases | Enterprise messaging, cross-vendor interoperability, cloud messaging services |
The naming problem you need to know about first
Before anything else, an important clarification. AMQP 1.0 is not simply the next version of AMQP 0.9.1. They are different protocols that happen to share a name. They are not wire-compatible, they define different things at very different levels of abstraction, and a client library for one cannot talk to a broker that speaks only the other. AMQP 0.9.1 remains widely deployed (it is RabbitMQ’s default protocol), but this article is specifically about AMQP 1.0, the OASIS and ISO standard.
If you are trying to understand AMQP 0.9.1 instead — the version with exchanges, queues, bindings, and routing keys — the model described in this article does not apply. When documentation says “AMQP,” always check which version it means. This article covers AMQP 1.0 exclusively.
Why AMQP exists
The history of AMQP is unusual for a messaging protocol. It started as an industry initiative in 2003, led by JPMorgan Chase, to address a problem enterprise messaging had struggled with for years: every major message broker had its own proprietary wire protocol, and connecting them was a painful, custom-integration task each time. The goal was to define an open, standardized wire protocol so that message brokers and clients from different vendors could interoperate at a byte level.
Early versions of the protocol (AMQP 0.8, 0.9, 0.9.1, 0.10) went through several iterations, and one of them — 0.9.1 — was adopted by RabbitMQ and became widely used. But the working group came to view those early versions as too tightly coupled to a specific server model, and in 2011–2012 they produced AMQP 1.0, which was a nearly complete redesign.
AMQP 1.0 is deliberately more generic than its predecessors. Rather than assuming that the server has exchanges, queues, and bindings (as 0.9.1 did), AMQP 1.0 says only that two peers exchange messages, and leaves all the questions about what sits at each end open. This shift from “protocol plus mandated server model” to “wire protocol only” is the single most important thing to understand about how AMQP 1.0 differs from its predecessors and from most other messaging protocols.
AMQP 1.0 became an OASIS Standard on 29 October 2012 and an ISO/IEC standard (ISO/IEC 19464) in 2014. Both designations are current.
The core concepts
To understand AMQP 1.0, you need six terms. They are all defined in the specification, and they form a small, coherent model that everything else builds on.
Container
A container is anything that hosts AMQP nodes and terminates AMQP connections. Examples include brokers, client applications, gateways, and bridge processes. The specification is deliberate about not privileging any particular kind of container: “Examples of containers are brokers and client applications.” This is what makes AMQP 1.0 unusually broker-agnostic. A container might be an enterprise message broker, but it might just as well be a Python program or a cloud service — the protocol does not care.
Node
A node is a named entity inside a container that is responsible for the safe storage and delivery of messages. Producers, consumers, and queues are all examples of nodes. Messages originate from nodes, terminate at nodes, and can be relayed by nodes along the way to their eventual destination. A single container can hold many nodes.
Link
A link is a unidirectional route between two nodes, used to transfer messages. A link is not a physical connection — many links can share the same underlying TCP connection — but a logical channel for transferring messages in one direction. To send messages in both directions between two nodes, you use two links.
Source and target
Every link has two ends, each of which is a terminus: a source at the sending end and a target at the receiving end. When a message is transferred along a link, it flows from the source to the target. The source and target each have addresses that identify what they refer to on their side. In a broker-based deployment, a source might refer to a queue you are consuming from and a target might refer to a queue or exchange you are publishing to; in a peer-to-peer deployment, they might refer to internal application constructs. What the address means is up to the container.
Address
An address identifies a source or target. AMQP 1.0 does not define what an address must look like or how it must be resolved; that is entirely up to the implementation. In one broker, addresses might be strings that name queues. In another, they might name streams, topics, or internal application handlers. In a third, they might not exist as separately-declared entities at all. This is one of the biggest sources of vendor-specific behavior in AMQP 1.0: the same client library, using the same wire protocol, can behave very differently against different brokers because of how they resolve addresses.
Session and connection
A connection is a TCP (typically TLS) network connection between two containers. Within a connection, one or more sessions carry links. This layering — connection carries sessions, sessions carry links, links transfer messages — is what lets AMQP 1.0 multiplex many concurrent message flows over a single network connection efficiently. It is also how AMQP 1.0 provides isolation: different sessions on the same connection can fail or reset independently.
Together, these six concepts describe the entire AMQP 1.0 model: containers hold nodes; nodes are connected by links; links have source and target endpoints with addresses; and everything runs over sessions on a connection.
The wire protocol
AMQP 1.0 is a binary protocol with a self-describing type system. Every value on the wire is tagged with its type, which means a receiver can parse an AMQP message without prior knowledge of its schema — an important property for a protocol designed to bridge heterogeneous systems.
The type system
The AMQP 1.0 type system is layered. At the bottom are primitive types: booleans, several integer sizes (byte, short, int, long, and unsigned variants), floating-point types, characters, timestamps, UUIDs, binary blobs, strings, and symbols. Above them are composite types built from primitives, and above those are the domain-specific types the protocol uses — message headers, delivery states, and so on. Every composite type has a descriptor that identifies it, typically by both a symbolic name (amqp:accepted:list) and a numeric code (0x00000000:0x00000024). This lets a receiver identify what it is looking at even if it does not recognize the specific type.
Performatives
The unit of protocol interaction in AMQP 1.0 is called a performative. A performative is one of a defined set of protocol messages that tell a peer to do something: open a connection, begin a session, attach a link, transfer a message, adjust flow, dispose of a delivery, close a link, end a session, close a connection. Every AMQP interaction on the wire consists of frames that contain performatives, sometimes with an opaque payload (as with the transfer performative that carries an actual message).
The full set of performatives is small (about a dozen), and each one has a well-defined meaning and expected response. This makes the protocol implementable in a reasonable amount of code, even though it is more sophisticated than something like MQTT.
Framing
Data on the wire is organized into frames. A frame has a fixed-size header and a body containing a performative (and optionally a payload). The framing is designed for streaming, so an implementation can process each frame as it arrives without waiting for a complete message. Multi-frame deliveries let messages larger than a single frame be split across many frames of the same delivery.
How a message flows
A useful way to make the abstract model concrete is to trace a single message end to end.
- Two containers establish a connection. One initiates a TCP connection to the other and both perform the AMQP protocol handshake (agreeing on version, security layer, and so on). If TLS is used, the TLS handshake happens first; if SASL is used for authentication, the SASL exchange happens as part of the AMQP negotiation.
- They open sessions. The client sends a
beginperformative to open a session inside the connection. Sessions provide flow control and framing isolation. - They attach links. To send messages, the client sends an
attachperformative describing the link: its name, its role (sender or receiver), and the source and target endpoints. The remote peer responds with its ownattach, and the link is now established. - The sender transfers a message. The sender sends a
transferperformative, carrying the message payload. Each transfer has a delivery-tag identifying it. If the message is larger than a single frame, it is spread across multiple transfer frames sharing the same delivery-tag. - Flow control governs the exchange. Each link has a credit system: the receiver grants credit to the sender via
flowperformatives, and the sender can only transfer messages while it has credit. This is how AMQP 1.0 prevents senders from overwhelming receivers, and how consumers assert back-pressure explicitly. - The delivery reaches a state. As the message is processed, it moves through delivery states. When the receiver has decided the outcome (accepted, rejected, released, or modified), it sends a
dispositionperformative back to the sender, communicating that state. - Settlement occurs. Depending on the settlement mode negotiated on the link, the delivery is settled either by the sender when it transfers (in the simplest mode) or after acknowledgement (in the more reliable modes). Settlement means both peers can release the state they were holding for that delivery.
- The link, session, and connection eventually close. When the sender is done, it can detach the link with a
detachperformative. The session closes withend, and the connection closes withclose.
This flow is the essence of AMQP 1.0. The details of each step are covered in more depth in the dedicated articles in this category.
Delivery guarantees
Delivery guarantees are one of AMQP 1.0’s defining features. The protocol has one of the most sophisticated delivery models of any messaging protocol, with formal outcomes, configurable settlement modes, and support for recovery of in-flight deliveries across connection failures.
Delivery outcomes
Every delivery in AMQP 1.0 ends in one of four terminal outcomes:
- Accepted — the receiver successfully processed the message. The sender can consider the delivery complete.
- Rejected — the receiver considered the message invalid and refused to process it. The sender is informed with an error, and the delivery does not succeed.
- Released — the receiver no longer holds the message; it is being returned so someone else can process it. Neither successful nor a rejection; more like handing the message back.
- Modified — the receiver returns the message with modifications to its state (for example, incrementing a delivery-count so retry logic can track how many times it has been seen). Also a form of return, but with information about why.
These are terminal states — once a delivery has reached one of them, it does not change. The rich outcome vocabulary is why AMQP 1.0 is often the choice for messaging with complex reliability requirements, such as financial-messaging systems where “the message failed” is not detailed enough.
Settlement modes
Each link negotiates two settlement modes: one for the sender and one for the receiver. These control when a delivery is considered settled — that is, when both sides can release the state they were holding for it.
The sender modes range from “settle the delivery immediately when transferred” (which is essentially at-most-once) to “wait for the receiver to indicate its outcome before settling” (which enables exactly-once behavior with additional coordination). The receiver modes mirror this. The combination of the two determines the effective delivery semantics: at-most-once, at-least-once, or exactly-once.
Unlike protocols where the delivery guarantee is a single per-message setting (like MQTT’s QoS), AMQP 1.0 lets the two peers negotiate settlement per link, and the delivery-state machinery makes the exact semantics of “when is a message really delivered” explicit and inspectable on the wire.
Recovery across failures
If a connection breaks in the middle of a delivery, both peers retain state about unsettled deliveries. When the connection is re-established and the same links are re-attached, they can exchange their unsettled state and resume mid-delivery. This is unusual: many protocols simply fail unsettled deliveries and force the application to retry. AMQP 1.0’s ability to resume a delivery in progress is one of the reasons it is favored for financial and regulated environments where every message must be accounted for.
Flow control
AMQP 1.0’s flow control is explicit and per-link. Rather than relying on TCP’s own back-pressure, which is coarse and applies to the whole connection, AMQP gives every receiver a way to say “I can accept N more messages on this link” via flow performatives.
The sender’s message credit determines how many transfers it may make. When credit reaches zero, the sender stops until the receiver grants more. This lets consumers apply back-pressure precisely, per-link, without affecting other traffic on the same connection.
A consumer that is slow can throttle a single link without stopping the connection. A consumer that is fast can keep credit high. This kind of per-link flow control is one of the operational advantages of AMQP 1.0 in high-throughput deployments.
Security
AMQP 1.0 delegates most security concerns to lower layers, which is deliberate. The protocol itself defines how a peer can negotiate TLS (transport layer security) and SASL (authentication) as part of the connection setup, but the specific mechanisms are pluggable.
TLS
The standard way to run AMQP 1.0 securely is over TLS. The client and server perform the TLS handshake first, using X.509 certificates (with or without client certificates), and then AMQP is negotiated on top of the encrypted stream. This is how virtually every production AMQP 1.0 deployment secures its traffic.
SASL
For authentication, AMQP 1.0 uses SASL, the Simple Authentication and Security Layer defined by IETF. SASL is a framework that supports many concrete authentication mechanisms, and AMQP 1.0 implementations commonly support:
- PLAIN — username and password, sent in the clear (should be used only over TLS).
- SCRAM — a challenge-response mechanism that avoids sending the password directly.
- EXTERNAL — authentication is provided by the underlying transport, typically a TLS client certificate.
- ANONYMOUS — no authentication (for development and testing only).
The AMQP 1.0 SASL exchange happens before the AMQP protocol handshake proper. Once SASL authentication succeeds, the connection proceeds to the normal AMQP negotiation.
Authorization
Authorization — who is allowed to send to which target, who can consume from which source — is not defined by AMQP 1.0. That is left to the container. Different brokers implement authorization very differently, and this is another area where AMQP 1.0 code often needs to be tuned to a specific broker’s model rather than being purely broker-agnostic.
What AMQP 1.0 does not specify
Because AMQP 1.0 is deliberately a wire protocol rather than a complete messaging system, some things that other messaging protocols include are simply outside its scope. It is important to know what these are:
- Server topology. There are no exchanges, queues, bindings, or topics defined by the protocol. Whether the container has them, and what they look like, is up to the container.
- Address semantics. AMQP 1.0 says addresses identify sources and targets, but does not say what they refer to or how they are resolved.
- Routing rules. The protocol does not define how a message is routed from a target to any subsequent destination. That is a container concern.
- Message persistence. Whether the container stores messages durably, and how, is not part of the AMQP 1.0 spec.
- Authorization policies. The spec does not define what actions require authorization or how permissions are described.
- Federation, clustering, and high availability. Also up to the container.
This is what people mean when they say AMQP 1.0 is “unopinionated about the server.” The protocol is precise about the bytes on the wire and the state machine each peer must implement, and quiet about everything else.
Common containers and brokers
In practice, most AMQP 1.0 deployments involve a broker of some kind. The main options:
- Azure Service Bus — Microsoft’s managed messaging service uses AMQP 1.0 as its primary protocol.
- IBM MQ — IBM’s flagship enterprise messaging product supports AMQP 1.0.
- Apache ActiveMQ — both Classic and Artemis variants support AMQP 1.0.
- Solace — event streaming and messaging platform, native AMQP 1.0.
- RabbitMQ — added AMQP 1.0 as a core protocol in version 4.0, alongside its long-standing AMQP 0.9.1 default.
- Apache Qpid — a family of AMQP 1.0 clients and brokers under the Apache umbrella.
- Red Hat AMQ — Red Hat’s supported build of ActiveMQ Artemis with AMQP 1.0.
Cloud services (Azure Service Bus in particular) have driven a lot of AMQP 1.0 adoption in recent years, because they expose AMQP 1.0 as the native way to interact with their messaging primitives.
Beyond brokers, AMQP 1.0 client libraries exist in most major languages: Java (Qpid JMS, Qpid Proton), Python (Qpid Proton), .NET (AMQP.Net Lite, Qpid Proton), C/C++ (Qpid Proton), JavaScript (Rhea), Rust (fe2o3-amqp), and others. Because AMQP 1.0 was designed for interoperability, the same client library will typically talk to multiple different brokers, though vendor-specific behavior around addressing and authorization means some code is inevitably broker-aware.
How AMQP 1.0 compares to other protocols
A brief orientation on how AMQP 1.0 fits alongside the protocols it is often compared to. Each of these has its own comparison article in this category or in the MQTT category.
AMQP 1.0 vs AMQP 0.9.1. Different protocols despite the shared name. AMQP 0.9.1 is a message-queue protocol with an explicit server model (exchanges, queues, bindings), used primarily by RabbitMQ. AMQP 1.0 is a peer-to-peer wire protocol with no server model, used across many vendors. AMQP 0.9.1 is simpler to reason about within its model; AMQP 1.0 is more interoperable across vendors.
AMQP 1.0 vs MQTT. MQTT is a lightweight publish/subscribe protocol designed for IoT and constrained devices. AMQP 1.0 is a heavier, more feature-rich protocol designed for enterprise messaging. MQTT wins for small devices, high connection counts, and simple pub/sub; AMQP 1.0 wins for cross-vendor interoperability and sophisticated delivery semantics. See the MQTT vs AMQP article for a detailed comparison.
AMQP 1.0 vs Kafka. Different tools for different jobs. Kafka is a distributed log for high-throughput event streaming, with a specific model built around partitioned, ordered logs and consumer groups. AMQP 1.0 is a message-oriented protocol focused on delivery semantics between peers. Some use cases overlap; many do not.
AMQP 1.0 vs HTTP. HTTP is request/response, stateless per exchange, and text-based. AMQP 1.0 is stateful, message-oriented, binary, and connection-persistent. HTTP is universal and simple; AMQP 1.0 is specialized and more capable for messaging patterns HTTP handles poorly.
When to choose AMQP 1.0
AMQP 1.0 makes sense as the right choice in a few specific situations:
Cross-vendor interoperability. If you need to interact with multiple different messaging systems from a single client codebase (Azure Service Bus and IBM MQ, for example), AMQP 1.0 is designed for exactly this. The same client library will speak to both.
Managed cloud messaging. Azure Service Bus in particular is designed around AMQP 1.0. If you are building on Azure and using Service Bus, AMQP 1.0 is the native protocol.
Sophisticated delivery semantics. If your messaging patterns need the full delivery-state model (accepted, rejected, released, modified) and the fine-grained settlement modes, AMQP 1.0 exposes this at the protocol level in a way that most alternatives do not.
Enterprise integration. Environments that must connect heterogeneous message brokers, ESBs, and applications from different vendors, particularly in regulated industries, benefit from AMQP 1.0’s interoperability and formal delivery model.
Standards-mandated environments. Some organizations require ISO- or OASIS-standardized protocols. AMQP 1.0 is both.
When AMQP 1.0 is not the right choice: For IoT and constrained devices, MQTT is lighter and more appropriate. For high-throughput event streaming with strong ordering guarantees per partition, Kafka is purpose-built. For simple pub/sub messaging patterns that fit in the RabbitMQ ecosystem, AMQP 0.9.1 is often simpler to work with.
Frequently asked questions
What is AMQP 1.0? AMQP 1.0 is the Advanced Message Queuing Protocol, version 1.0 — a wire-level messaging protocol standardized by OASIS in 2012 and adopted as an ISO/IEC standard (19464) in 2014. It defines how two peers exchange messages over a TCP connection, with a formal delivery-state model, but it does not mandate any particular server model.
Is AMQP the same as AMQP 0.9.1? No. Despite the shared name, AMQP 1.0 and AMQP 0.9.1 are different protocols. They are not wire-compatible. AMQP 0.9.1 defines a specific server model with exchanges, queues, and bindings; AMQP 1.0 is a peer-to-peer wire protocol that leaves the server model unspecified.
What port does AMQP 1.0 use? Port 5672 for plain (unencrypted) AMQP and port 5671 for AMQP over TLS. RabbitMQ, for example, listens for both AMQP 0.9.1 and AMQP 1.0 on port 5672.
Does AMQP 1.0 require a broker? No. The specification defines containers, which can be brokers, client applications, or anything else. Broker-based deployments are the most common, but the protocol supports peer-to-peer usage without a central broker.
How is AMQP 1.0 secured? Through TLS for transport encryption and SASL for authentication. Common SASL mechanisms include PLAIN, SCRAM, and EXTERNAL (typically used with TLS client certificates). Authorization is handled by the container, not by the protocol.
What are AMQP 1.0’s delivery guarantees? The protocol supports at-most-once, at-least-once, and exactly-once semantics, depending on the settlement modes negotiated per link. Every delivery ends in one of four terminal outcomes: accepted, rejected, released, or modified. Deliveries can also be resumed after connection failures.
What is a “node” in AMQP 1.0? A node is a named entity inside a container that stores and delivers messages. Producers, consumers, and queues are examples of nodes. Messages flow from node to node along links.
What is a “link” in AMQP 1.0? A link is a unidirectional route between two nodes, used to transfer messages. Many links can share the same TCP connection. Each link has a source endpoint on one side and a target endpoint on the other.
Which broker should I use for AMQP 1.0? Depends on your environment. Azure Service Bus for Azure deployments; IBM MQ for existing IBM shops; Apache ActiveMQ (Classic or Artemis) for on-premises open source; Solace for managed event streaming; RabbitMQ (4.0+) for teams already on RabbitMQ. All support AMQP 1.0 as a first-class protocol.
Is AMQP 1.0 the right choice for IoT? Usually not. AMQP 1.0 is more feature-rich than IoT typically needs, and its client libraries are heavier than MQTT’s. For IoT and constrained devices, MQTT is the standard recommendation. AMQP 1.0 is a better fit for enterprise messaging, cross-vendor interoperability, and cloud messaging services.