Você deve comparar o Aurora cuidadosamente antes de considerá-lo. Inicie uma instância e configure uma instância de teste do seu aplicativo e banco de dados. Gere a maior carga possível. Eu fiz isso na minha última empresa e descobri que, apesar das alegações de alto desempenho da Amazon, o Aurora falhou espetacularmente. Duas ordens de magnitude mais lentas que o RDS. Nosso aplicativo teve uma alta taxa de tráfego de gravação.

Nossa conclusão:se você tiver índices secundários e alto tráfego de gravação, o Aurora não é adequado. Aposto que é bom para tráfego somente leitura.

(Edit:o teste que estou descrevendo foi feito no primeiro trimestre de 2017. Assim como a maioria dos serviços da AWS, espero que o Aurora melhore com o tempo. A Amazon tem uma estratégia explícita de "Libere ideias em 70% e repita. " A partir disso, devemos concluir que vale a pena testar um novo produto da AWS, mas provavelmente não estará pronto para produção por pelo menos alguns anos após o lançamento).

Naquela empresa, eu recomendei o RDS. Eles não tinham uma equipe de DBA dedicada, e a automação que o RDS oferece para operações de banco de dados, como upgrades e backups, foi muito útil. Você sacrifica um pouco de flexibilidade nas opções de ajuste, mas isso não deve ser um problema.

O pior inconveniente do RDS é que você não pode ter um usuário MySQL com privilégio SUPER, mas o RDS fornece procs armazenados para as tarefas mais comuns para as quais você precisaria do privilégio SUPER.

Comparei uma instância do RDS multi-AZ com um conjunto de réplicas de instâncias do EC2, gerenciadas pelo Orchestrator. Como o Orchestrator requer três nós para que você possa ter quorum, o RDS foi o vencedor claro em custo aqui, bem como facilidade de configuração e operações.