AWS amazon-mq: RabbitMQ 4.3 support and doc cleanup
Summary
Updates Amazon MQ RabbitMQ 4 documentation to mention RabbitMQ 4.3 support and 4.2-to-4.3 in-place upgrades, adjusts default queue type wording, and removes large sections listing RabbitMQ 4 changes, deprecations, and breaking changes.
Security assessment
The diff is a version-support and documentation restructuring update. Although removed sections mention security features such as mTLS and SSL/HTTP authentication, the change does not add security guidance or address a specific vulnerability, CVE, or incident.
Evidence
+Amazon MQ supports RabbitMQ 4.3 and 4.2 in the RabbitMQ 4 release series only on the mq.m7g instance type across all supported instance sizes.
Diff
diff --git a/amazon-mq/latest/developer-guide/rabbitmq-4.md b/amazon-mq/latest/developer-guide/rabbitmq-4.md index 89e2db83a..f81ad63d3 100644 --- a//amazon-mq/latest/developer-guide/rabbitmq-4.md +++ b//amazon-mq/latest/developer-guide/rabbitmq-4.md @@ -7 +7 @@ -The following changes have been introduced in RabbitMQ 4 on Amazon MQThe following features have been deprecated from RabbitMQ 4 on Amazon MQThe following breaking changes may impact your applications when upgrading to RabbitMQ 4.2 on Amazon MQThe following features are not supported on RabbitMQ 4 on Amazon MQ +The following features are not supported on RabbitMQ 4 on Amazon MQ @@ -11 +11 @@ The following changes have been introduced in RabbitMQ 4 on Amazon MQThe followi -Amazon MQ supports RabbitMQ 4.2 in the RabbitMQ 4 release series only on the mq.m7g instance type across all supported instance sizes. +Amazon MQ supports RabbitMQ 4.3 and 4.2 in the RabbitMQ 4 release series only on the mq.m7g instance type across all supported instance sizes. @@ -13 +13 @@ Amazon MQ supports RabbitMQ 4.2 in the RabbitMQ 4 release series only on the mq. -Amazon MQ supports in-place upgrades from RabbitMQ 3.13 to RabbitMQ 4.2. For more information, see [Upgrading from RabbitMQ 3 to 4](./upgrading-rabbitmq-v3-to-v4.html). +Amazon MQ supports in-place upgrades from RabbitMQ 3.13 to RabbitMQ 4.2, and from RabbitMQ 4.2 to 4.3. For more information, see [Upgrading from RabbitMQ 3 to 4](./upgrading-rabbitmq-v3-to-v4.html). @@ -17 +17 @@ Amazon MQ supports in-place upgrades from RabbitMQ 3.13 to RabbitMQ 4.2. For mor -The default queue type on Amazon MQ for RabbitMQ 4.2 brokers will be “quorum”. If no queue type argument is specified during queue creation, a quorum queue will be created. +The default queue type on Amazon MQ for RabbitMQ 4.2 brokers is `quorum`. If no queue type argument is specified during queue creation, a quorum queue will be created. @@ -21,47 +20,0 @@ We highly recommend using quorum queues on RabbitMQ 4 for durability needs, sinc -## The following changes have been introduced in RabbitMQ 4 on Amazon MQ - - * **AMQP 1.0 as a core protocol:** For more information, see [Protocols](./rabbitmq-supported-protocols.html). - - * **Local shovels:** Shovels now support a new protocol called "local" in addition to AMQP 0-9-1 and AMQP 1.0. Local shovels are internally based on AMQP 1.0 but instead of using separate TCP connections, they use intra-cluster connections between cluster nodes and internal APIs for publishing and consuming messages. This can only be used for consuming and publishing within the same cluster and can offer higher throughput while using fewer resources than AMQP 0-9-1 and AMQP 1.0. - - * **Quorum queues support message priorities:** Quorum queue message priorities are always active and do not require a policy to work. As soon as a quorum queue receives a message with a priority set it will enable prioritization. Quorum queues internally only support two priorities - high and normal. Messages without a priority set will be mapped to normal as will priorities 0 - 4. Messages with a priority higher than 4 will be mapped to high. High priority messages will be favoured over normal priority messages at a ratio of 2:1, i.e. for every 2 high priority message the queue will deliver 1 normal priority message (if available). Hence, quorum queues implement a kind of non-strict, "fair share" priority processing. This ensures progress is always made on normal priority messages, but high priorities are favoured at a ratio of 2:1. - - * **Khepri:** Khepri is used as the default metadata store for RabbitMQ 4 brokers - - * **Mutual TLS (mTLS):** Amazon MQ supports mutual TLS (mTLS) for RabbitMQ brokers, allowing clients to authenticate using certificates. For more information, see [mTLS configuration](./configure-mtls.html). - - * **SSL certificate authentication plugin:** The SSL authentication plugin uses client certificates from mTLS connections to authenticate users, allowing authentication using X.509 client certificates instead of username and password credentials. For more information, see [SSL certificate authentication](./ssl-for-amq-for-rabbitmq.html). - - * **HTTP authentication plugin:** The HTTP authentication backend plugin allows delegating authentication and authorization to an external HTTP service. For more information, see [HTTP authentication and authorization](./http-for-amq-for-rabbitmq.html). - - * **JMS support:** The broker now supports JMS workloads with the JMS topic exchange plugin enabled, allowing JMS applications to connect using the [RabbitMQ JMS client](https://github.com/rabbitmq/rabbitmq-jms-client). - - * **Configurable storage size:** RabbitMQ 4.x brokers deployed in CLUSTER_MULTI_AZ mode support configurable EBS storage sizes. For more information, see [mq.m7g instance types](./rmq-broker-instance-types.html#instance-types-m7g-cluster). - - - - -## The following features have been deprecated from RabbitMQ 4 on Amazon MQ - - * **Mirroring of classic queues:** Classic queues continue to be supported without any breaking changes for client libraries and applications, but they are now a non-replicated queue type. Clients will be able to connect to any node to publish to and consume from any non-replicated classic queues. Quorum queues are recommended for replication and data safety. - - * **Removal of Global QoS:** Customers are recommended to set per-consumer QoS (non-global) instead of Global QoS, where a single shared prefetch is used for an entire channel. - - * **Support for transient, non-exclusive queues:** Transient queues are queues whose lifetime is linked to the uptime of the node they are declared on. In a single instance broker, they are removed when the node is restarted. In a cluster deployment, they are removed when the node they are hosted on is restarted. We recommend using queue TTL for auto-deleting unused, idle queues after some time of inactivity. Exclusive queues continue to be supported and are deleted once all connections to the queue have been removed. - - - - -## The following breaking changes may impact your applications when upgrading to RabbitMQ 4.2 on Amazon MQ - - * **Default queue type:** The default queue type on a RabbitMQ 4 broker is set to quorum. If no queue type argument is specified during queue creation, a quorum queue will be created. - - * **Default redelivery limit on quorum queues is set to 20:** Messages that are redelivered 20 times or more will be dead-lettered or dropped (removed). If 20 deliveries per message is a common scenario for a queue, a dead-lettering target or a higher limit must be configured for such queues to avoid data loss. The recommended way of doing that is via a policy. - - * **amqplib:** Node JS client **amqplib versions older than 0.10.7** or any AMQP client library using **frame_max < 8192 ** will not be able to connect to RabbitMQ - - * [Default resource limits:](./rabbitmq-resource-limits-configuration.html) Amazon MQ for RabbitMQ has introduced default resource usage limits for connections, channels, consumers per channel, queues, vhosts, shovels, exchanges, and maximum message size. These serve as guardrails to protect broker availability and can be customized using configurations to match your specific requirements. - - - - @@ -87 +40 @@ Version management -Version support +RabbitMQ 4.3