Vous devez soigneusement comparer 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. Je l'ai fait dans ma dernière entreprise et j'ai constaté que malgré les affirmations d'Amazon en matière de hautes performances, Aurora a échoué de manière spectaculaire. Deux ordres de grandeur plus lent que RDS. Notre application a enregistré un taux élevé de trafic en écriture.
Notre conclusion :si vous avez des index secondaires et un trafic en écriture élevé, Aurora n'est pas adapté. Je parie que c'est bon pour le trafic en lecture seule.
(Edit :les tests que je décris ont été effectués au premier trimestre de 2017. Comme pour la plupart des services AWS, je m'attends à ce qu'Aurora s'améliore avec le temps. Amazon a une stratégie explicite de "Libérer des idées à 70 %, puis itérer. " De cela, nous devrions conclure qu'un nouveau produit d'AWS vaut la peine d'être testé, mais probablement pas prêt pour la production pendant au moins quelques années après son introduction).
Dans cette entreprise, j'ai recommandé RDS. Ils n'avaient pas de personnel DBA dédié, et l'automatisation que RDS vous offre pour les opérations de base de données telles que les mises à niveau et les sauvegardes a été 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 procédures stockées 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éplicas d'instances EC2, géré par Orchestrator. Étant donné qu'Orchestrator nécessite trois nœuds pour que vous puissiez avoir un quorum, RDS a été le grand gagnant en termes de coût, ainsi que de facilité de configuration et d'opérations.
