You must carefully measure Aurora before taking this. Run the instance and configure the test instance of your application and your database. Generate as much load as possible. I did this at my last company, and I found that despite Amazon's claims of high performance, Aurora failed impressively. Two orders of magnitude slower than RDS. Our application had a high level of write traffic.
Our conclusion: if you have secondary indexes and high write traffic, Aurora is not suitable. I am sure this is good for read-only traffic.
(Edit: The testing that I am describing was done in the first quarter of 2017. Like most AWS services, I expect Aurora to improve over time. Amazon has a clear strategy of β Delivering ideas 70% and then iterating. β From this we conclude that the new AWS product is worth checking out, but is probably not ready for production for at least several years after it was introduced).
At this company, I recommended RDS. They did not have any special DBA personnel, and the automation that RDS gives you for database operations, such as updates and backups, was very useful. You sacrifice a bit of flexibility in settings, but that should not be a problem.
The worst inconvenience of RDS is that you cannot have a MySQL user with the SUPER privilege, but RDS provides stored procs for most common tasks for which you need the SUPER privilege.
I have been comparing an RDS instance with several AZs and an Orchestrator managed EC2 instance set. Since Orchestrator requires three nodes, so you can have a quorum, RDS was a clear winner in terms of cost here, as well as the ease of configuration and operations.
source share