What should a solutions architect do to meet these requirements?
Migrate the queue to a redundant pair (active/standby) of RabbitMQ instances on Amazon MQ. Create a Multi-AZ Auto Scaling group for EC2 instances that host the application. Create another Multi-AZ Auto Scaling group for EC2 instances that host the PostgreSQL database.
Migrate the queue to a redundant pair (active/standby) of RabbitMQ instances on Amazon MQ. Create a Multi-AZ Auto Scaling group for EC2 instances that host the application. Migrate the database to run on a Multi-AZ deployment of Amazon RDS for PostgreSQL.
Create a Multi-AZ Auto Scaling group for EC2 instances that host the RabbitMQ queue. Create another Multi-AZ Auto Scaling group for EC2 instances that host the application. Migrate the database to run on a Multi-AZ deployment of Amazon RDS for PostgreSQL.
Create a Multi-AZ Auto Scaling group for EC2 instances that host the RabbitMQ queue. Create another Multi-AZ Auto Scaling group for EC2 instances that host the application. Create a third Multi-AZ Auto Scaling group for EC2 instances that host the PostgreSQL database.
Explanations:
While this option proposes migrating RabbitMQ to Amazon MQ for redundancy, it does not address the need for high availability of the PostgreSQL database. The Active/Standby configuration does not provide the same level of availability and failover capabilities as a Multi-AZ RDS deployment. Additionally, a Multi-AZ Auto Scaling group for EC2 instances hosting the application does not ensure the database’s availability.
This option effectively enhances availability by migrating RabbitMQ to Amazon MQ, which offers built-in redundancy, and utilizing Multi-AZ deployments for the application and PostgreSQL database via Amazon RDS. This reduces operational overhead by managing database failover and backups, while the application can scale across multiple availability zones.
This option suggests creating Multi-AZ Auto Scaling groups for both RabbitMQ and the application, but it does not migrate the PostgreSQL database to a Multi-AZ deployment. Without Multi-AZ for the database, the overall architecture remains vulnerable to database instance failures, which impacts overall availability.
Although this option includes Multi-AZ Auto Scaling groups for RabbitMQ, the application, and the database, it introduces unnecessary complexity. The solution can be simplified by migrating the PostgreSQL database to Amazon RDS Multi-AZ deployment rather than managing EC2 instances for the database. Managing too many Auto Scaling groups adds operational overhead without significant benefits.