Du bör jämföra Aurora noggrant innan du överväger det. Starta en instans och ställ in en testinstans av din applikation och din databas. Generera så hög belastning du kan. Jag gjorde det på mitt senaste företag, och jag upptäckte att trots Amazons påståenden om hög prestanda, misslyckades Aurora spektakulärt. Två storleksordningar långsammare än RDS. Vår app hade en hög skrivtrafik.
Vår slutsats:om du har sekundära index och har hög skrivtrafik är Aurora inte lämpligt. Jag slår vad om att det är bra för skrivskyddad trafik dock.
(Edit:testningen jag beskriver gjordes under första kvartalet 2017. Som med de flesta AWS-tjänster förväntar jag mig att Aurora kommer att förbättras med tiden. Amazon har en explicit strategi med "Släpp idéer till 70 % och upprepa sedan. " Av detta bör vi dra slutsatsen att en ny produkt från AWS är värd att testa, men troligen inte produktionsklar förrän åtminstone några år efter att den har introducerats.
På det företaget rekommenderade jag RDS. De hade ingen dedikerad DBA-personal, och automatiseringen som RDS ger dig för DB-operationer som uppgraderingar och säkerhetskopieringar var till stor hjälp. Du offrar lite flexibilitet när det gäller inställningsalternativ, men det borde inte vara ett problem.
Det värsta besväret med RDS är att du inte kan ha en MySQL-användare med SUPER-behörighet, men RDS tillhandahåller lagrade processer för de vanligaste uppgifterna som du skulle behöva SUPER-behörighet för.
Jag jämförde en multi-AZ RDS-instans med en replikuppsättning av EC2-instanser, som hanteras av Orchestrator. Eftersom Orchestrator kräver tre noder så att du kan ha kvorum, var RDS den klara vinnaren när det gäller kostnaden här, såväl som enkel installation och drift.