Is there any ActiveMQ instance type available in eu-central-1 az2?

Question

We are hitting an error trying to create an MQ broker in eu-central-1 in our AZA that maps to az2 of the region. The documentation here

https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/rmq-broker-instance-types.html

Says that instance types m4.* and m5.* are unavailable in that AZ temporarily. Seeing it written in the docs makes us think that whatever issue is causing it will last for long. Being m5.* the only instance types currently supported. Does it mean there is no way to create a broker for customers that like use were randomly mapped to that AZ, except by migrating to a different AZ?

If the answer is yes, shouldn't this be reflected in the health status of the service in the region that is shown to have no issues?

Accepted Answer

I understand you are experiencing error when you are trying to create MQ broker in euc1-az2 availability zones. As there is a capacity deficit in the eu-central-1 region, this is considered as a limitation in the MQ service. If, for example, one of the Availability Zones were to fail (eu-central-1c) this would be marked as a temporary public event. As this is a service limitation rather than a temporary public event hence, the MQ service for the eu-central-1 region is shown as healthy.

I kindly recommend creating the brokers in 'eu-central-1b' and/or 'eu-central-1c' subnets until the capacity issues have been resolved. Furthermore, in order to check what instance type are available in what AWS AZ's, you can run below [AWS CLI Describe Broker Instance Options](https://docs.aws.amazon.com/cli/latest/reference/mq/describe-broker-instance-options.html) command as per below:

```
aws mq describe-broker-instance-options --region eu-central-1 --engine-type RABBITMQ
```

Based on the output of the AWS CLI Describe Broker Instance Option command you can then create new brokers in AZ's which have availability until the capacity issue has been resolved, as it is not possible to change your brokers subnet or add another subnet after the broker has been created to perform the upgrade.

Answer

Lack of capacity that leads to nothing less than a full AZ being unavailable for the service should be considered an unhealthy situation of the whole region and be publicly notified.

If this was caused by an API failure that caused errors when trying to create brokers in that AZ, it would trigger a health notification as we regularly see across different services. The cause does not change the impact, which is what should matter to classify the status as healthy or unhealthy.

It is also not the best interpretation from a customer caring perspective. Not notifying this through the health service hides the situation, leads customers to create their architectures in the affected AZ until, after having invested considerable resources, hit the issue and need to migrate to other AZ, with again considerable expense of resources.

Is there any ActiveMQ instance type available in eu-central-1 az2?

Relevant content