# Managing an Amazon MQ broker Managing a broker After you create a broker, you can manage and maintain the different components of your Amazon MQ broker. **Topics** + [Connecting to Amazon MQ](connect-to-amazonmq.md) + [Authentication and authorization](amazon-mq-access.md) + [ # Upgrading an Amazon MQ broker engine version ](upgrading-brokers.md) + [ # Upgrading an Amazon MQ broker instance type ](upgrading-instance-type.md) + [Storage](broker-storage.md) + [Configuring a private Amazon MQ broker](configuring-private-broker.md) + [ # Scheduling the maintenance window for an Amazon MQ broker ](maintaining-brokers.md) + [Rebooting a Broker](amazon-mq-rebooting-broker.md) + [Deleting a broker](amazon-mq-deleting-broker.md) + [Broker statuses](broker-statuses.md) + [ # Adding tags to Amazon MQ resources ](amazon-mq-tagging.md) # Connecting to Amazon MQ Connecting to Amazon MQ You can connect to Amazon MQ from other Amazon services using service endpoints and broker endpoints. ## Service endpoints The following connection methods are used for the **Amazon MQ service API:** | Domains | Connection method | | --- | --- | | `mq.region.amazonaws.com` | IPv4 | | `mq.region.api.aws` | Dual-stack (IPv4 and IPv6) | | `mq-fips.region.amazonaws.com` | FIPS with IPv4 only | | `mq-fips.region.api.aws` | FIPS with Dual-stack | ## Broker endpoints The following connection methods are used for **Amazon MQ brokers:** | Domains | Connection method | | --- | --- | | `brokerId.mq.region.amazonaws.com` | IPv4 | | `brokerId.mq.region.on.aws` | Dual-stack (IPv4 and IPv6) Amazon MQ for ActiveMQ brokers do not support dual-stack. | ## Connect to Amazon MQ using Dual-stack (IPv4 and IPv6) endpoints Dual-stack endpoints support both IPv4 and IPv6 traffic. When you make a request to a dual-stack endpoint, the endpoint URL resolves to an IPv4 or an IPv6 address. For more information on dual-stack and FIPS endpoints, see the [SDK Reference guide](https://docs.amazonaws.cn/sdkref/latest/guide/feature-endpoints.html). Amazon MQ supports Regional dual-stack endpoints, which means that you must specify the Amazon Region as part of the endpoint name. Dual-stack endpoint names use the following naming convention: `mq.region.api.amazonwebservices.com.cn`. For example, the dual-stack endpoint name for the `cn-north-1` Region is `mq.cn-north-1.api.amazonwebservices.com.cn`. Amazon MQ supports Regional dual-stack endpoints, which means that you must specify the Amazon Region as part of the endpoint name. Dual-stack endpoint names use the following naming convention: `mq.region.api.aws`. For example, the dual-stack endpoint name for the `eu-west-1` Region is `mq.eu-west-1.api.aws`. For the full list of Amazon MQ endpoints, see the [Amazon General Reference](https://docs.amazonaws.cn/general/latest/gr/amazon-mq.html). ## Connect to Amazon MQ using Amazon PrivateLink [Amazon PrivateLink](https://docs.amazonaws.cn/vpc/latest/privatelink/what-is-privatelink.html) endpoints for Amazon MQ API with support for IPv4 and IPv6 provides private connectivity between virtual private clouds (VPCs) and the Amazon MQ API without exposing your traffic to the public internet. **Note** Support for PrivateLink is only available for the Amazon MQ API endpoint, not the broker endpoint. For more information on privately connecting to a broker endpoint, see [Configuring a private Amazon MQ broker](configuring-private-broker.md). To access Amazon MQ API using PrivateLink, you must first create an [interface VPC endpoint](https://docs.amazonaws.cn/VPC/latest/privatelink/create-interface-endpoint.html) in the specific VPC you want to connect from. When you create the VPC endpoint, use the service name `com.amazonaws.region.mq` or `com.amazonaws.region.mq-fips` for FIPS endpoints. When you call Amazon MQ using the Amazon CLI or SDK, you must specify the endpoint URL to use the dual-stack domain name: `mq.region.api.aws` or `mq-fips.region.api.aws`. PrivateLink for Amazon MQ does not support the default domain name ending in `amazonaws.com`. For more information , see [Dual-stack and FIPS endpoints](https://docs.amazonaws.cn/sdkref/latest/guide/feature-endpoints.html) in the SDK Reference Guide. The following CLI example shows how to call the `describe-broker-engine-type` in the Asia Pacific (Sydney) Region through an Amazon MQ VPC endpoint. ``` AWS_USE_DUALSTACK=true aws mq describe-broker-engine-types --region ap-southeast-2 ``` For other ways to configure the endpoint in CLI, see [Using endpoints in the Amazon CLI](https://docs.amazonaws.cn/cli/v1/userguide/cli-configure-endpoints.html) You can also determine user access to the VPC endpoints using VPC endpoint policies. For more information, see [Control access to VPC endpoints using endpoint policies](https://docs.amazonaws.cn/vpc/latest/privatelink/vpc-endpoints-access.html). # Authentication and authorization for Amazon MQ brokers Authentication and authorization Amazon MQ offers multiple authentication and authorization methods to secure your messaging infrastructure according to your organization's requirements. ## Authentication and authorization for Amazon MQ for RabbitMQ Amazon MQ for RabbitMQ supports the following authentication and authorization methods: ### Simple authentication and authorization In this method, broker users are stored internally in the RabbitMQ broker and managed through the web console or management API. Permissions for vhosts, exchanges, queues, and topics are configured directly in RabbitMQ. This is the default method. For more information, see [Simple authentication and authorization](rabbitmq-simple-auth-broker-users.md). ### OAuth 2.0 authentication and authorization In this method, broker users and their permissions are managed by an external OAuth 2.0 identity provider (IdP). User authentication and resource permissions for vhosts, exchanges, queues, and topics are centralized through the OAuth 2.0 provider's scope system. This simplifies user management and enables integration with existing identity systems. For more information, see [OAuth 2.0 authentication and authorization](oauth-for-amq-for-rabbitmq.md). ### IAM authentication and authorization In this method, broker users authenticate using Amazon IAM credentials through [IAM outbound federation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html). IAM credentials are used to obtain JWT tokens from Amazon Security Token Service (STS), and these JWT tokens serve as OAuth 2.0 tokens for authentication. This method leverages the existing OAuth 2.0 support in Amazon MQ for RabbitMQ, where Amazon acts as the OAuth 2.0 identity provider. User authentication is handled by Amazon IAM, while resource permissions for vhosts, exchanges, queues, and topics are managed through IAM policies and scope aliases configured in RabbitMQ. For more information, see [IAM authentication and authorization](iam-for-amq-for-rabbitmq.md). ### LDAP authentication and authorization In this method, broker users and their permissions are managed by an external LDAP directory service. User authentication and resource permissions are centralized through the LDAP server, allowing users to access RabbitMQ using their existing directory service credentials. For more information, see [LDAP authentication and authorization](ldap-for-amq-for-rabbitmq.md). ### HTTP authentication and authorization In this method, broker users and their permissions are managed by an external HTTP server. User authentication and resource permissions are centralized through the HTTP server, allowing users to access RabbitMQ using their own Authentication and Authorization provider. For more information about this method, see [HTTP authentication and authorization](http-for-amq-for-rabbitmq.md). ### SSL certificate authentication Amazon MQ supports mutual TLS (mTLS) for RabbitMQ brokers. The SSL authentication plugin uses client certificates from mTLS connections to authenticate users. In this method, broker users are authenticated using X.509 client certificates instead of username and password credentials. The client's certificate is validated against a trusted Certificate Authority (CA), and the username is extracted from a field in the certificate, such as the Common Name (CN) or Subject Alternative Name (SAN). This method provides strong authentication without transmitting credentials over the network. For more information, see [SSL certificate authentication](ssl-for-amq-for-rabbitmq.md). **Note** RabbitMQ supports multiple authentication and authorization methods to be used simultaneously. For example, you can enable both OAuth 2.0 and simple (internal) authentication. For more information, see the OAuth 2.0 tutorial section on [enabling both OAuth 2.0 and simple (internal) authentication](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/oauth-tutorial.html#oauth-tutorial-config-both-auth-methods-using-cli) and the [RabbitMQ access control documentation](https://www.rabbitmq.com/docs/access-control). Amazon MQ recommends creating an internal user when testing authentication configurations. This allows access configuration to be validated using RabbitMQ management API. For more information, see [Access validation](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/arn-support-rabbitmq-configuration.html#access-validation). ## Authentication and authorization for Amazon MQ for ActiveMQ Amazon MQ for ActiveMQ supports the following authentication and authorization methods: ### Simple authentication and authorization In this method, broker users are created and managed through the Amazon MQ console or API. Users can be configured with specific permissions to access queues, topics, and the ActiveMQ Web Console. For more information about this method, see [Creating an ActiveMQ broker user](amazon-mq-listing-managing-users.md). ### LDAP authentication and authorization In this method, broker users authenticate through credentials stored in your LDAP server. You can add, delete, and modify users and assign permissions to topics and queues through the LDAP server, providing centralized authentication and authorization. For more information about this method, see [Integrating ActiveMQ brokers with LDAP](security-authentication-authorization.md). # Upgrading an Amazon MQ broker engine version Upgrading the engine version Amazon MQ regularly provides new broker engine versions for all supported broker engine types. New engine versions include security patches, bug fixes, and other broker engine improvements. Amazon MQ organizes version numbers according to semantic versioning specification as `X.Y.Z`. In Amazon MQ implementations, `X` denotes the major version, `Y` represents the minor version, and `Z` denotes the patch version number. Amazon MQ supports two types of upgrades: + **Major version upgrade** – Occurs when the major engine version numbers change. For example, upgrading from RabbitMQ version **3**.13 to version **4**.2 is considered a major version upgrade. + **Minor version upgrade** – Occurs when only the minor engine version number changes. For example, upgrading from version 3.**11** to version 3.**12** is considered a minor version upgrade. You can manually upgrade your broker at any time to the next supported major or minor version. Amazon MQ manages upgrade to the latest supported patch version for all brokers during the scheduled [maintenance window](maintaining-brokers.md). Both manual and automatic version upgrades occur during the scheduled maintenance window, or after you [reboot your broker](amazon-mq-rebooting-broker.md). Amazon MQ upgrades your broker to the next minor version when the current minor version reaches end of support. ## Manually upgrading the engine version You can upgrade the engine version of a broker by using the Amazon Web Services Management Console, the Amazon CLI, or the Amazon MQ API. ### Amazon Web Services Management Console **To upgrade the engine version of a broker by using the Amazon Web Services Management Console** 1. On the broker details page, choose **Edit**. 1. Under **Specifications**, for **Broker engine version** choose the new version number from the dropdown list. 1. Scroll to the bottom of the page, and choose **Schedule modifications**. 1. On the **Schedule broker modifications** page, for **When to apply modifications**, choose one of the following. + Choose **After the next reboot**, if you want Amazon MQ to complete the version upgrade during the next scheduled maintenance window. + Choose **Immediately**, if you want to reboot the broker and upgrade the engine version immediately. **Important** Single instance brokers are offline while being rebooted. For cluster brokers, only one node is down at a time while the broker reboots. 1. Choose **Apply** to finish applying the changes. ### Amazon CLI **To upgrade the engine version of a broker by using the Amazon CLI** 1. Use the [update-broker](https://docs.amazonaws.cn/cli/latest/reference/mq/update-broker.html) CLI command and specify the following parameters, as shown in the example. + `--broker-id` – The unique ID that Amazon MQ generates for the broker. You can parse the ID from your broker ARN. For example, given the following ARN, `arn:aws-cn:mq:us-east-2:123456789012:broker:MyBroker:b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9`, the broker ID would be `b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9`. + `--engine-version` – The engine version number for the broker engine to upgrade to. ``` aws mq update-broker --broker-id broker-id --engine-version version-number ``` 1. (Optional) Use the [reboot-broker](https://docs.amazonaws.cn/cli/latest/reference/mq/reboot-broker.html) CLI command to reboot your broker if you want to upgrade the engine version immediately. ``` aws mq reboot-broker --broker-id broker-id ``` If you do not want to reboot your broker and apply the changes immediately, Amazon MQ will upgrade the broker during the next scheduled maintenance window. **Important** Single instance brokers are offline while being rebooted. For cluster brokers, only one node is down at a time while the broker reboots. ### Amazon MQ API **To upgrade the engine version of a broker by using the Amazon MQ API** 1. Use the [UpdateBroker](https://docs.amazonaws.cn/amazon-mq/latest/api-reference/brokers-broker-id.html#UpdateBroker) API operation. Specify `broker-id` as a path parameter. The following examples assumes a broker in the `us-west-2` region. For more information about available Amazon MQ endpoints, see [Amazon MQ endpoints and quotas.](https://docs.amazonaws.cn/general/latest/gr/amazon-mq.html#amazon-mq_region) in the *Amazon Web Services General Reference* ``` PUT /v1/brokers/broker-id HTTP/1.1 Host: mq.us-west-2.amazonaws.com Date: Mon, 7 June 2021 12:00:00 GMT x-amz-date: Mon, 7 June 2021 12:00:00 GMT Authorization: authorization-string ``` Use `engineVersion` in the request payload to specify the version number for the broker to upgrade to. ``` { "engineVersion": "engine-version-number" } ``` 1. (Optional) Use the [RebootBroker](https://docs.amazonaws.cn/amazon-mq/latest/api-reference/brokers-broker-id-reboot.html#RebootBroker) API operation to reboot your broker if you want to upgrade the engine version immediately. `broker-id` is specified as a path parameter. ``` POST /v1/brokers/broker-id/reboot-broker HTTP/1.1 Host: mq.us-west-2.amazonaws.com Date: Mon, 7 June 2021 12:00:00 GMT x-amz-date: Mon, 7 June 2021 12:00:00 GMT Authorization: authorization-string ``` If you do not want to reboot your broker and apply the changes immediately, Amazon MQ will upgrade the broker during the next scheduled maintenance window. **Important** Single instance brokers are offline while being rebooted. For cluster brokers, only one node is down at a time while the broker reboots. # Upgrading an Amazon MQ broker instance type Upgrading the instance type **Important** `mq.m7g.x` instances are only available for Amazon MQ for RabbitMQ brokers. Amazon MQ for ActiveMQ brokers only use `mq.m5.x` instances. The combined description of the broker instance class (`m7g`) and size (`large`) is called the broker instance type (for example, `mq.m7g.large`). When choosing an instance type, it is important to consider factors that will affect broker performance: + the number of clients and queues + the volume of messages sent + messages kept in memory + redundant messages Smaller broker instance types (`mq.m7g.medium`) are recommended only for testing application performance. We recommend larger broker instance types (`mq.m7g.large ` and above) for production levels of clients and queues, high throughput, messages in memory, and redundant messages. We recommend upgrading to a larger instance type (i.e. from `micro` to `large`) if you are experiencing performance issues, or if you are moving from testing to a production environment. To upgrade your instance type, you can use the Amazon Web Services Management Console, the Amazon CLI, or the Amazon MQ API. ## Amazon Web Services Management Console **To upgrade to a larger instance type using the Amazon Web Services Management Console, do the following:** 1. Sign in to the [Amazon MQ console](https://console.amazonaws.cn/amazon-mq/). 1. In the left navigation pane, choose **Brokers**, and then choose the broker that you want to upgrade from the list. 1. On the broker details page, choose **Edit**. 1. Under **Specifications**, for **Broker instance type** choose the new instance type from the dropdown list. 1. At the bottom of the page, choose **Schedule modifications**. 1. On the **Schedule broker modifications** page, for **When to apply modifications**, choose one of the following. + Choose **After the next reboot**, if you want Amazon MQ to complete the upgrade during the next scheduled maintenance window. + Choose **Immediately**, if you want to reboot the broker and upgrade the instance type immediately. **Important** Single instance brokers are offline while being rebooted. For cluster brokers, only one node is down at a time while the broker reboots. 1. Choose **Apply** to finish applying the changes. ## Amazon CLI **To upgrade the instance type of a broker by using the Amazon CLI** 1. Use the [modify-broker](https://docs.amazonaws.cn/cli/latest/reference/mq/update-broker.html) CLI command and specify the following parameters, as shown in the example. + `--broker-id` – The unique ID that Amazon MQ generates for the broker. + `--host-instance-type` – The engine version number for the broker engine to upgrade to. ``` aws mq modify-broker --broker-id broker-id --host-instance-type instance-type ``` 1. (Optional) Use the [reboot-broker](https://docs.amazonaws.cn/cli/latest/reference/mq/reboot-broker.html) CLI command to reboot your broker if, you want to upgrade the instance type immediately. ``` aws mq reboot-broker --broker-id broker-id ``` If you do not want to reboot your broker and apply the changes immediately, Amazon MQ will upgrade the broker during the next scheduled maintenance window. **Important** Single instance brokers are offline while being rebooted. For cluster brokers, only one node is down at a time while the broker reboots. ## Amazon MQ API **To upgrade the instance-type of a broker by using the Amazon MQ API** 1. Use the [UpdateBroker](https://docs.amazonaws.cn/amazon-mq/latest/api-reference/brokers-broker-id.html#UpdateBroker) API operation. Specify `broker-id` as a path parameter. The following examples assumes a broker in the `us-west-2` region. For more information about available Amazon MQ endpoints, see [Amazon MQ endpoints and quotas](https://docs.amazonaws.cn/general/latest/gr/amazon-mq.html#amazon-mq_region) in the *Amazon Web Services General Reference*. ``` PUT /v1/brokers/broker-id HTTP/1.1 Host: mq.us-west-2.amazonaws.com Date: Mon, 7 June 2021 12:00:00 GMT x-amz-date: Mon, 7 June 2021 12:00:00 GMT Authorization: authorization-string ``` Use `host-instance-type` in the request payload to specify the instance type for the broker to upgrade to. ``` { "host-instance-type": "host-instance-type" } ``` 1. (Optional) Use the [RebootBroker](https://docs.amazonaws.cn/amazon-mq/latest/api-reference/brokers-broker-id-reboot.html#RebootBroker) API operation to reboot your broker, if you want to upgrade the engine version immediately. `broker-id` is specified as a path parameter. ``` POST /v1/brokers/broker-id/reboot-broker HTTP/1.1 Host: mq.us-west-2.amazonaws.com Date: Mon, 7 June 2021 12:00:00 GMT x-amz-date: Mon, 7 June 2021 12:00:00 GMT Authorization: authorization-string ``` If you do not want to reboot your broker and apply the changes immediately, Amazon MQ will upgrade the broker during the next scheduled maintenance window. **Important** Single instance brokers are offline while being rebooted. For cluster brokers, only one node is down at a time while the broker reboots. # Amazon MQ for ActiveMQ storage types Storage Amazon MQ for ActiveMQ supports Amazon Elastic File System (EFS) and Amazon Elastic Block Store (EBS). By default, ActiveMQ brokers use Amazon EFS for broker storage. To take advantage of high durability and replication across multiple Availability Zones, use Amazon EFS. To take advantage of low latency and high throughput, use Amazon EBS. **Important** You can use Amazon EBS only with the `mq.m5` broker instance type family. Although you can change the *broker instance type*, you can't change the *broker storage type* after you create the broker. Amazon EBS replicates data within a single Availability Zone and doesn't support the [ActiveMQ active/standby](amazon-mq-broker-architecture.md#active-standby-broker-deployment) deployment mode. ## Differences between Storage Types The following table provides a brief overview of the differences between in-memory, Amazon EFS, and Amazon EBS storage types for ActiveMQ brokers. | Storage Type | Persistence | Example Use Case | Approximate Maximum Number of Messages Enqueued per Producer, per Second (1KB Message) | Replication | | --- | --- | --- | --- | --- | | In-memory | Non-persistent | [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/amazon-mq/latest/developer-guide/broker-storage.html) | 5,000 | None | | Amazon EBS | Persistent | [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/amazon-mq/latest/developer-guide/broker-storage.html) | 500 | Multiple copies within a single Availability Zone (AZ) | | Amazon EFS | Persistent | Financial transactions | 80 | Multiple copies across multiple AZs | In-memory message storage provides the lowest latency and the highest throughput. However, messages are lost during instance replacement or broker restart. Amazon EFS is designed to be highly durable, replicated across multiple AZs to prevent the loss of data resulting from the failure of any single component or an issue that affects the availability of an AZ. Amazon EBS is optimized for throughput and replicated across multiple servers within a single AZ. # Configuring a private Amazon MQ broker Configuring a private broker A private broker does not have public accessibility and cannot be accessed from outside of your VPC. Before configuring a private broker, view the following information about VPCs, subnets, and security groups: + **VPCs** + A broker's subnet(s) and security group(s) must be in the same VPC. + When you are using a private broker, you may see IP addresses that you did not configure with your VPC. These are IP addresses from the Amazon MQ infrastructure, and they require no action. + **Subnets** + If subnets are within a shared VPC, the VPC must be owned by the same account creating the broker. + If no subnets are provided, the default subnets in the default VPC will be used. + Once the broker is created, the subnets used cannot be changed. + For cluster and active/standby brokers, subnets must be in different Availability Zones. + For single instance brokers, you can specify which subnet to use and the broker will be created within the same Availability Zone. + **Security groups** + If no security group is provided, the default security groups in the default VPC will be used. + Single-instance, cluster, and active/standby brokers require at least one security group (for example, the default security group). **Note** Public RabbitMQ brokers do not use subnets or security groups. + Once the broker is created, the security group used cannot be changed. The security groups can themselves still be modified. ## Configuring a private broker in the Amazon Web Services Management Console To configure a private broker, begin [creating a new broker](https://docs.amazonaws.cn/amazon-mq/latest/developer-guide/getting-started-activemq.html) in the Amazon Web Services Management Console. Then, in the **Network settings** section, to configure your broker's connectivity, do the following: 1. Choose **Private access** for your broker. To connect to a private broker, you can use IPv4, IPv6, or dual-stack (IPv4 and IPv6). For more information, see [Connecting to Amazon MQ](connect-to-amazonmq.md). 1. Next, choose **Use the default VPC, subnet(s), and security group(s)**, or choose **Select existing VPC, subnet(s), and security group(s)**. If you do not wish to use the default or existing VPC, subnet(s), or security group(s), you must create a new one to connect to the private broker. **Note** For private broker access, the connection method will be the same as the selected IP type of the subnet. Once the broker is created, the VPC endpoint cannot be changed and will always have the IP type of the selected subnets. If you want to use a new IP type, you must create a new broker. **Note** Amazon MQ for ActiveMQ does not use VPC endpoints. When you first create an ActiveMQ broker, Amazon MQ provisions an elastic network interface (ENI) in the VPC. Security groups are placed in the ENI and can be used for both public and private brokers. ## Accessing the Amazon MQ broker web console without public accessibility When you turn off public accessibility for your broker, the Amazon account ID that created the broker can access the private broker. If you turn off public accessibility for your broker, you must perform the following steps to access the broker web console. 1. Create a Linux EC2 instance in `public-vpc` (with a public IP, if necessary). 1. To verify that your VPC is configured correctly, establish an `ssh` connection to the EC2 instance and use the `curl` command with the URI of your broker. 1. From your machine, create an `ssh` tunnel to the EC2 instance using the path to your private key file and the IP address of your public EC2 instance. For example: ``` ssh -i ~/.ssh/id_rsa -N -C -q -f -D 8080 ec2-user@203.0.113.0 ``` A forward proxy server is started on your machine. 1. Install a proxy client such as [FoxyProxy](https://getfoxyproxy.org/) on your machine. 1. Configure your proxy client using the following settings: + For proxy type, specify `SOCKS5`. + For IP address, DNS name, and server name, specify `localhost`. + For port, specify `8080`. + Remove any existing URL patterns. + For the URL pattern, specify `*.mq.*.amazonaws.com*` + For the connection type, specify `HTTP(S)`. When you enable your proxy client, you can access the web console on your machine. **Important** If you are using a private broker, you may see IP addresses that you did not configure with your VPC. These are IP addresses from the RabbitMQ on Amazon MQ infrastructure, and they require no action. # Scheduling the maintenance window for an Amazon MQ broker Scheduling broker maintenance Periodically, Amazon MQ performs maintenance to the hardware, operating system, or the engine software of a message broker during the maintenance window. For example, if you changed the broker instance type, Amazon MQ will apply your changes during the next scheduled maintenance window. The duration of the maintenance can last up to two hours depending on the operations that are scheduled for your message broker. You can minimize downtime during a maintenance window by selecting a broker deployment mode with high availability across multiple Availability Zones (AZ). Amazon MQ for ActiveMQ provides [active/standby](amazon-mq-broker-architecture.md#active-standby-broker-deployment) deployments for high availability. In active/standby mode, Amazon MQ performs maintenance operations one instance at a time, and at least one instance remains available. In addition, you can configure a [network of brokers](network-of-brokers.md) with maintenance windows varied across the week. Amazon MQ for RabbitMQ provides the [cluster](rabbitmq-broker-architecture.md#rabbitmq-broker-architecture-cluster) deployments for high availability. In cluster deployments, Amazon MQ performs maintenance operations one node at a time by keeping at least two running nodes at all times. When you first create your broker, you can schedule the maintenance window to occur once a week at a specified time. You can only adjust the maintenance window of a broker up to four times before the next scheduled maintenance window. Once a broker maintenance window is completed, Amazon MQ resets the limit, and you can adjust the schedule again before the next maintenance window occurs. Broker availability is not affected when adjusting the broker maintenance window. To adjust the broker maintenance window, you can use the Amazon Web Services Management Console, the Amazon CLI, or the Amazon MQ API. ## Schedule the broker maintenance window using the Amazon Web Services Management Console **To adjust the broker maintenance window by using the Amazon Web Services Management Console** 1. Sign in to the [Amazon MQ console](https://console.amazonaws.cn/amazon-mq/). 1. In the left navigation pane, choose **Brokers**, and then choose the broker that you want to upgrade from the list. 1. On the broker details page, choose **Edit**. 1. Under **Maintenance**, do the following. 1. For **Start day**, choose a day of the week, for example, **Sunday**, from the drop-down list. 1. For **Start time**, choose the hour and minute of the day that you want to schedule for the next broker maintenance window, for example, **12**:**00**. **Note** The **Start time** options are configured in UTC\$10 time zone. 1. Next, select **Schedule modifications**. Then choose **After the next reboot** or **Immediately**. Choosing **After the next reboot** will immediately update the maintenance window without rebooting the broker. Choosing **Immediately** will immediately reboot the broker. 1. On the broker details page, under **Maintenance window**, verify that your new preferred schedule is displayed. ## Schedule the broker maintenance window using the Amazon CLI **To adjust the broker maintenance window using the Amazon CLI** 1. Use the [update-broker](https://docs.amazonaws.cn/cli/latest/reference/mq/update-broker.html) CLI command and specify the following parameters, as shown in the example. + `--broker-id` – The unique ID that Amazon MQ generates for the broker. You can parse the ID from your broker ARN. For example, given the following ARN, `arn:aws-cn:mq:us-east-2:123456789012:broker:MyBroker:b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9`, the broker ID would be `b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9`. + `--maintenance-window-start-time` – The parameters that determine the weekly maintenance window start time provided in the following structure. + `DayOfWeek` – The day of the week, in the following syntax: `MONDAY| TUESDAY | WEDNESDAY | THURSDAY | FRIDAY | SATURDAY | SUNDAY` + `TimeOfDay` – The time, in 24-hour format. + `TimeZone` – (Optional) The time zone, in either the Country/City, or the UTC offset format. Set to UTC by default. ``` aws mq update-broker --broker-id broker-id \ --maintenance-window-start-time DayOfWeek=SUNDAY,TimeOfDay=13:00,TimeZone=America/Los_Angeles ``` 1. (Optional) Use the [describe-broker](https://docs.amazonaws.cn/cli/latest/reference/mq/reboot-broker.html) CLI command to verify that the maintenance window is successfully updated. ``` aws mq describe-broker --broker-id broker-id ``` ## Schedule the broker maintenance window using the Amazon MQ API **To adjust the broker maintenance window using the Amazon MQ API** 1. Use the [UpdateBroker](https://docs.amazonaws.cn/amazon-mq/latest/api-reference/brokers-broker-id.html#UpdateBroker) API operation. Specify `broker-id` as a path parameter. The following examples assumes a broker in the `us-west-2` region. For more information about available Amazon MQ endpoints, see [Amazon MQ endpoints and quotas](https://docs.amazonaws.cn/general/latest/gr/amazon-mq.html#amazon-mq_region) in the *Amazon Web Services General Reference*. ``` PUT /v1/brokers/broker-id HTTP/1.1 Host: mq.us-west-2.amazonaws.com Date: Wed, 7 July 2021 12:00:00 GMT x-amz-date: Wed, 7 July 2021 12:00:00 GMT Authorization: authorization-string ``` Use the `maintenanceWindowStartTime` parameter and the [https://docs.amazonaws.cn/amazon-mq/latest/api-reference/brokers-broker-id.html#brokers-broker-id-model-weeklystarttime](https://docs.amazonaws.cn/amazon-mq/latest/api-reference/brokers-broker-id.html#brokers-broker-id-model-weeklystarttime) resource type in the request payload. ``` { "maintenanceWindowStartTime": { "dayOfWeek": "SUNDAY", "timeZone": "America/Los_Angeles", "timeOfDay": "13:00" } } ``` 1. (Optional) Use the [DescribeBroker](https://docs.amazonaws.cn/amazon-mq/latest/api-reference/brokers-broker-id.html#brokers-broker-id-http-methods) API operation to verify that the maintenance window has been successfully updated. `broker-id` is specified as a path parameter. ``` GET /v1/brokers/broker-id HTTP/1.1 Host: mq.us-west-2.amazonaws.com Date: Wed, 7 July 2021 12:00:00 GMT x-amz-date: Wed, 7 July 2021 12:00:00 GMT Authorization: authorization-string ``` # Rebooting an Amazon MQ broker Rebooting a broker To apply a new configuration to a broker, you can reboot the broker. **Note** If your ActiveMQ broker becomes unresponsive, you can reboot it to recover from a faulty state. The following example shows how you can reboot an Amazon MQ broker using the Amazon Web Services Management Console. ## To Reboot an Amazon MQ Broker 1. Sign in to the [Amazon MQ console](https://console.amazonaws.cn/amazon-mq/). 1. From the broker list, choose the name of your broker (for example, **MyBroker**). 1. On the ***MyBroker*** page, choose **Actions**, **Reboot broker**. **Important** Single instance brokers will be offline while being rebooted. Cluster brokers will be available, but each node is rebooted one at a time. 1. In the **Reboot broker** dialog box, choose **Reboot**. Rebooting a broker takes about 5 minutes. If the reboot includes instance size changes or is performed on a broker with high queue depth, the rebooting process can take longer. # Deleting an Amazon MQ broker Deleting a broker If you don't use an Amazon MQ broker (and don't foresee using it in the near future), it is a best practice to delete it from Amazon MQ to reduce your Amazon costs. The following example shows how you can delete a broker using the Amazon Web Services Management Console. ## Deleting an Amazon MQ broker 1. Sign in to the [Amazon MQ console](https://console.amazonaws.cn/amazon-mq/). 1. From the broker list, select your broker (for example, **MyBroker**) and then choose **Delete**. 1. In the **Delete *MyBroker*?** dialog box, type `delete` and then choose **Delete**. Deleting a broker takes about 5 minutes. # Amazon MQ broker statuses Broker statuses A broker's current condition is indicated by a *status*. The following table lists the statuses of an Amazon MQ broker. | Console | API | Description | | --- | --- | --- | | Creation failed | CREATION\$1FAILED | The broker couldn't be created. | | Creation in progress | CREATION\$1IN\$1PROGRESS | The broker is currently being created. | | Deletion in progress | DELETION\$1IN\$1PROGRESS | The broker is currently being deleted. | | Reboot in progress | REBOOT\$1IN\$1PROGRESS | The broker is currently being rebooted. | | Running | RUNNING | The broker is operational. | | Critical action required | CRITICAL\$1ACTION\$1REQUIRED | The broker is running, but is in a degraded state and requires immediate action. You can find instructions to resolve the issue by chosing the action required code from the list in [Troubleshooting Amazon MQ](troubleshooting.md). | # Adding tags to Amazon MQ resources Tagging To organize and identify your Amazon MQ resources for cost allocation, you can add metadata *tags* that identify the purpose of a broker or configuration. This is especially useful when you have many brokers. You can use cost allocation tags to organize your Amazon bill to reflect your own cost structure. To do this, sign up to get your Amazon account bill to include the tag keys and values. For more information, see [Setting Up a Monthly Cost Allocation Report](https://docs.amazonaws.cn/awsaccountbilling/latest/aboutv2/configurecostallocreport.html#allocation-report) in the *Amazon Billing User Guide*. For instance, you could add tags that represent the cost center and purpose of your Amazon MQ resources: **** [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/amazon-mq/latest/developer-guide/amazon-mq-tagging.html) This tagging scheme allows you to group two brokers performing related tasks in the same cost center, while tagging an unrelated broker with a different cost allocation tag. ## Adding tags in the Amazon MQ Console You can quickly add tags to the resources you are creating in the Amazon MQ console by following these steps: 1. From the **Create a broker** page, select **Additional settings**. 1. Under **Tags**, select **Add tag**. 1. Enter a **Key** and **Value** pair. 1. (Optional) Select **Add tag** to add multiple tags to your broker. 1. Select **Create broker**. To add tags as you create a configuration: 1. From the **Create configuration** page, select **Advanced**. 1. Under **Tags** on the **Create configuration** page, select **Add tag**. 1. Enter a **Key** and **Value** pair. 1. (Optional) Select **Add tag** to add multiple tags to your configuration. 1. Select **Create configuration**. After adding tags, you can view, edit, and remove the tags for your resources in the Amazon MQ console. You can also view the tags of your resources using the REST API. For more information, see the [Amazon MQ REST API Reference](https://docs.amazonaws.cn/amazon-mq/latest/api-reference/rest-api-tag.html).