Pela minha experiência, o Amazon Aurora não é adequado para executar um banco de dados com tráfego intenso de gravação. Pelo menos em sua implementação por volta de 2017. Talvez melhore com o tempo.

Trabalhei em alguns benchmarks para um aplicativo de gravação pesada no início de 2017 e descobrimos que o RDS (não Aurora) era muito superior ao Aurora no desempenho de gravação, considerando nosso aplicativo e banco de dados. Basicamente, o Aurora era duas ordens de magnitude mais lento que o RDS. As alegações de alto desempenho da Amazon para a Aurora são, aparentemente, uma bobagem totalmente direcionada ao marketing.

Em novembro de 2016, participei da conferência Amazon re:Invent em Las Vegas. Tentei encontrar um engenheiro experiente da Aurora para responder às minhas perguntas sobre desempenho. Tudo o que pude encontrar foram engenheiros juniores que receberam ordens para repetir a afirmação de que o Aurora é magicamente 5-10x mais rápido que o MySQL.

Em abril de 2017, participei da conferência Percona Live e vi uma apresentação sobre como desenvolver uma arquitetura de armazenamento distribuído semelhante ao Aurora usando MySQL padrão com CEPH para uma camada de armazenamento distribuído de código aberto. Há um webinar sobre o mesmo tópico aqui:https://www.percona. com/resources/webinars/mysql-and-ceph , co-apresentado por Yves Trudeau, o engenheiro que vi falar na conferência.

O que ficou claro sobre o uso do MySQL com CEPH é que os engenheiros tiveram que desabilitar o Buffer de alteração do MySQL porque não há como armazenar em cache as alterações em índices secundários, além de distribuir o armazenamento. Isso causou enormes problemas de desempenho para gravações em tabelas que possuem índices secundários (não exclusivos).

Isso foi consistente com os problemas de desempenho que vimos ao comparar nosso aplicativo com o Aurora. Nosso banco de dados tinha muitos índices secundários.

Portanto, se você absolutamente precisar usar o Aurora para um banco de dados com alto tráfego de gravação, recomendo que a primeira coisa a fazer seja descartar todos os seus índices secundários.

Obviamente, isso é um problema se os índices forem necessários para otimizar algumas de suas consultas. Ambas as consultas SELECT, é claro, mas também algumas consultas UPDATE e DELETE podem usar índices secundários.

Uma estratégia pode ser fazer uma réplica de leitura não Aurora de seu cluster Aurora e criar os índices secundários apenas na réplica de leitura para dar suporte às suas consultas SELECT. Eu nunca fiz isso, mas aparentemente é possível, de acordo com https://aws.amazon.com/premiumsupport/knowledge-center/enable-binary-logging-aurora/

Mas isso ainda não ajuda nos casos em que suas instruções UPDATE/DELETE precisam de índices secundários. Não tenho nenhuma sugestão para esse cenário. Você pode estar sem sorte.

Minha conclusão é que eu não escolheria usar o Aurora para um aplicativo de gravação pesada. Talvez isso mude no futuro.

Atualização de abril de 2021:

Desde que escrevi o acima, executei benchmarks do sysbench com relação ao Aurora versão 2. Não posso compartilhar os números específicos, mas concluo que as melhorias atuais do Aurora são melhores para cargas de trabalho pesadas de gravação. Eu executei testes com muitos índices secundários para ter certeza. Mas eu encorajo qualquer pessoa séria sobre a adoção do Aurora a executar seus próprios benchmarks.

Pelo menos, o Aurora é muito melhor que o Amazon RDS for MySQL convencional usando armazenamento EBS. Provavelmente é aí que eles afirmam que o Aurora é 5x mais rápido que o MySQL. Mas o Aurora não é mais rápido do que algumas outras alternativas que testei e, de fato, não pode corresponder:

• 
  O MySQL Server instalou-se em instâncias EC2 usando armazenamento local, especialmente instâncias i3 com NVMe conectado localmente. Entendo que o armazenamento de instâncias não é confiável, portanto, seria necessário executar nós redundantes.
  
• 
  O MySQL Server me instalou em hosts físicos em nosso data center, usando armazenamento SSD de conexão direta.
  

O valor de usar o Aurora como um banco de dados de nuvem gerenciado não é apenas sobre desempenho. Também possui monitoramento automatizado, backups, failover, upgrades, etc.