Vous devriez évaluer soigneusement Aurora avant de l'envisager. Lancez une instance et configurez une instance de test de votre application et de votre base de données. Générez une charge aussi élevée que possible. C'est ce que j'ai fait dans ma dernière entreprise, et j'ai constaté que malgré les affirmations d'Amazon sur les hautes performances, Aurora échouait de manière spectaculaire. Deux ordres de grandeur plus lent que RDS. Notre application avait un taux élevé de trafic d'écriture.
Notre conclusion : si vous avez des index secondaires et que vous avez un trafic d'écriture élevé, Aurora ne convient pas. Je parie qu'il est bon pour le trafic en lecture seule cependant.
(Édition : les tests que je décris ont été effectués au premier trimestre 2017. Comme pour la plupart des services AWS, je m'attends à ce qu'Aurora s'améliore au fil du temps. Amazon a une stratégie explicite de " Publier des idées à 70 %, puis itérer. " Nous devrions en conclure qu'un nouveau produit d'AWS vaut la peine d'être testé, mais qu'il ne sera probablement pas prêt pour la production avant au moins quelques années après son lancement).
Dans cette entreprise, j'ai recommandé RDS. Elle n'avait pas de personnel dédié à l'administration des bases de données et l'automatisation qu'offre RDS pour les opérations de base de données comme les mises à niveau et les sauvegardes était très utile. Vous sacrifiez un peu de flexibilité sur les options de réglage, mais cela ne devrait pas être un problème.
Le pire inconvénient de RDS est que vous ne pouvez pas avoir un utilisateur MySQL avec le privilège SUPER, mais RDS fournit des procs stockés pour la plupart des tâches courantes pour lesquelles vous auriez besoin du privilège SUPER.
J'ai comparé une instance RDS multi-AZ à un ensemble de répliques d'instances EC2, gérées par Orchestrator. Étant donné qu'Orchestrator nécessite trois nœuds pour avoir un quorum, RDS est le vainqueur incontesté en termes de coût, ainsi que de facilité de configuration et d'exploitation.