AMQP

What is AMQP?

AMQP (Advanced Message Queuing Protocol) is an open, binary application protocol for reliable, asynchronous message exchange between applications, usually through a message broker, standardised in version 1.0 by OASIS (2012) and as ISO/IEC 19464:2014. Within OT, the Industrial Internet of Things and OT convergence, AMQP mainly connects systems at enterprise level: SCADA, historians, MES, ERP and cloud platforms. Whereas MQTT and CoAP are optimised for lightweight telemetry from small devices, the strength of AMQP lies in guaranteed delivery, flow control and flexible routing.

🧠 Where does AMQP come from and which versions exist?

AMQP originated in the early 2000s at JPMorgan Chase. Banks relied heavily on message-oriented middleware, but every product had its own closed protocol. Choosing a broker meant being locked into that vendor’s libraries. AMQP was meant to be an open protocol that lets components from different vendors, languages and operating systems exchange messages.

One point matters a great deal in practice: “AMQP” is really two different protocols that are not compatible with each other.

Whenever someone says “we use AMQP”, always ask which version. An Azure integration speaks AMQP 1.0, while a classic RabbitMQ installation usually speaks 0-9-1. Since version 4.0 (2024), RabbitMQ supports both protocols natively on the same port 5672; the client’s protocol header determines which version a connection uses.

🔧 How does AMQP 0-9-1 work with exchanges and queues?

The AMQP 0-9-1 model is the best-known picture of AMQP. Its building blocks are:

There are four standard exchange types:

A single broker therefore supports both point-to-point messaging (one queue, several consumers sharing the work) and publish/subscribe (one message, several queues). A routing key such as temperature.plant1.line3 allows fine-grained filtering without changing the producer.

🔄 What is different about AMQP 1.0?

AMQP 1.0 does not describe a broker, only how two parties transfer messages securely and reliably. A connection (TCP, optionally with TLS) carries sessions, and within a session run links: one-way channels from a source to a target, identified by an address. Whatever sits behind that address, a queue, a topic or another application, is up to the implementation.

Three properties make AMQP 1.0 attractive for industrial integration:

• Credit-based flow control - the receiver states per link how many messages it can handle, so a slow cloud connection or an overloaded consumer throttles the sender instead of losing messages.
• Delivery guarantees per message - from fire-and-forget (at-most-once) to acknowledged delivery (at-least-once) and exactly-once through two-phase settlement.
• Multiplexing - one TLS connection carries several sessions and links. Azure IoT Hub therefore recommends AMQP for field and cloud gateways that forward messages on behalf of many devices, each with its own identity.

⚡ Which reliability mechanisms does AMQP offer?

Part of the reliability lives in the protocol, part in the broker. That distinction matters when you design a solution.

RabbitMQ removed the old classic mirrored queues in version 4.0; for high availability, quorum queues on a cluster of three or five nodes are now the norm. An odd number of nodes is recommended: three nodes tolerate one failure and five tolerate two, because a majority (quorum) must remain available; a fourth node adds no extra fault tolerance.

📡 How does AMQP compare with MQTT and Kafka?

AMQP, MQTT and Apache Kafka are often mentioned in the same breath, but they solve different problems.

In practice they complement each other. A common chain is: PLC to edge gateway via OPC UA or Sparkplug B, gateway to the cloud via AMQP or MQTT, and in the data centre a Kafka cluster for long-term storage and analytics. A Unified Namespace usually runs on MQTT; AMQP is more common for the connection to business applications.

🏭 Where is AMQP used in industrial automation?

Within industrial automation, AMQP rarely sits at field level. The protocol is too heavy for sensors and not deterministic enough for real-time control. It plays its role higher up in the Purdue Model:

The benefit of a broker in this OT architecture is decoupling: a historian that is briefly offline does not miss messages, because the queue holds them. The architecture does become dependent on the broker itself, which therefore has to be redundant.

🔐 How do you secure an AMQP environment?

AMQP provides the building blocks for security and cybersecurity, but a broker’s default settings are not automatically secure. A compromised broker gives an attacker control over every message flow.

Since version 3.3, RabbitMQ only allows the default guest account from localhost, but that account should be removed in production. For AMQP 1.0, RabbitMQ always requires SASL.

In line with IEC 62443, a broker belongs in its own zone, often the IDMZ between OT and IT, with network segmentation and an industrial firewall that only allows the required ports. Hardening, logging of connections and access failures, and security monitoring complete the picture. NIST SP 800-82 and ISO 27001 provide the wider framework. Organisations that fall under the Dutch Cybersecurity Act should include such a broker in their risk assessment as part of their critical chain.

🛠️ How do you set up AMQP step by step in an OT environment?

A practical approach for a first AMQP link between production and IT:

1. Choose the version deliberately - AMQP 1.0 for Azure integrations and interoperability between vendors; 0-9-1 if you already have a RabbitMQ ecosystem with existing clients.
2. Design the routing - define a naming convention for routing keys or addresses, for example site.area.line.signal, and keep it aligned with the ISA-95 hierarchy you use elsewhere.
3. Place the broker in the right zone - not in the control network itself, but in a DMZ segment where OT publishes and IT consumes.
4. Arrange availability - a three-node cluster with quorum queues, persistent messages and dead-letter queues for messages that cannot be processed.
5. Secure from day one - TLS with certificates managed through certificate management, one account per application and least privilege.
6. Monitor actively - queue depth, number of unacknowledged messages, the broker’s memory and disk alarms, and certificate expiry dates.
7. Bring the broker under management - lifecycle management, patch management, configuration management of the definitions (exchanges, queues, users), a backup of those definitions and a disaster recovery plan.

A useful rule of thumb: a healthy queue is almost empty. A queue that grows steadily means consumers cannot keep up, which is an early warning before the broker reaches its memory limit.

❓ Frequently asked questions

Is AMQP the same as RabbitMQ?

No, AMQP is a protocol and RabbitMQ is a broker that implements it. RabbitMQ was built around AMQP 0-9-1 and has also supported AMQP 1.0 natively since version 4.0. Other products such as Azure Service Bus and ActiveMQ Artemis speak AMQP 1.0.

Which port does AMQP use?

AMQP uses TCP port 5672 by default for unencrypted traffic and port 5671 for AMQP over TLS. In environments where only HTTPS is allowed outbound, AMQP can run over WebSockets on port 443, as Azure supports. In OT networks, only the encrypted variant should be open.

Is AMQP 1.0 compatible with AMQP 0-9-1?

No, AMQP 1.0 and AMQP 0-9-1 are different protocols with different models. AMQP 0-9-1 defines exchanges and queues, whereas AMQP 1.0 only describes message transfer through connections, sessions and links. A client for one version cannot simply talk to a broker that only supports the other.

When should you choose AMQP instead of MQTT?

AMQP is the better choice when messages between business applications must arrive guaranteed and in order, when you need rich routing, or when a gateway bundles many devices over one connection. MQTT suits small devices, sensors and a Unified Namespace better because its client is lighter. Many architectures use both.

Is AMQP suitable for real-time control?

AMQP is not suitable for deterministic real-time process control. The broker architecture, buffering and TCP connections cause variable latency. For control, fieldbuses and industrial Ethernet such as PROFINET remain the right choice; AMQP belongs at the data integration level.

Is AMQP secure?

AMQP supports TLS encryption and SASL authentication, but it is only secure when both are enabled and configured properly. Default accounts, unencrypted traffic on port 5672 and an exposed management interface are the most common weak spots. An AMQP broker belongs in a segmented zone with least-privilege permissions per application.

📌 In summary

AMQP is the open messaging protocol for reliable, decoupled message exchange between industrial systems, business applications and the cloud. The distinction between AMQP 0-9-1 (RabbitMQ, exchanges and queues) and the ISO standard AMQP 1.0 (Azure, links and flow control) is essential for every design decision. Use AMQP at the integration level alongside MQTT, not for real-time control, and secure the broker with TLS, SASL, least privilege and its own zone in your OT/IT architecture.