Debe evaluar cuidadosamente a Aurora antes de considerarlo. Inicie una instancia y configure una instancia de prueba de su aplicación y su base de datos. Genere la mayor cantidad de carga posible. Lo hice en mi última empresa y descubrí que, a pesar de las afirmaciones de alto rendimiento de Amazon, Aurora fracasó espectacularmente. Dos órdenes de magnitud más lento que RDS. Nuestra aplicación tuvo una alta tasa de tráfico de escritura.
Nuestra conclusión:si tiene índices secundarios y tiene un alto tráfico de escritura, Aurora no es adecuado. Sin embargo, apuesto a que es bueno para el tráfico de solo lectura.
(Editar:las pruebas que describo se realizaron en el primer trimestre de 2017. Al igual que con la mayoría de los servicios de AWS, espero que Aurora mejore con el tiempo. Amazon tiene una estrategia explícita de "Libere ideas al 70 % y luego repita. " A partir de esto, debemos concluir que vale la pena probar un nuevo producto de AWS, pero probablemente no esté listo para la producción durante al menos unos años después de su presentación).
En esa empresa, recomendé RDS. No tenían personal de DBA dedicado, y la automatización que le brinda RDS para operaciones de base de datos como actualizaciones y copias de seguridad fue muy útil. Sacrificas un poco de flexibilidad en las opciones de ajuste, pero eso no debería ser un problema.
El peor inconveniente de RDS es que no puede tener un usuario de MySQL con privilegio SUPER, pero RDS proporciona procesos almacenados para la mayoría de las tareas comunes para las que necesitaría privilegio SUPER.
Comparé una instancia RDS multi-AZ con un conjunto de réplicas de instancias EC2, administradas por Orchestrator. Debido a que Orchestrator requiere tres nodos para que pueda tener quórum, RDS fue el claro ganador en cuanto a costo aquí, así como también por la facilidad de configuración y operaciones.
