Een bedrijf draait een on-premises applicatie die wordt ondersteund door een MySQL-database. Het bedrijf migreert de applicatie naar AWS om de elasticiteit en beschikbaarheid te verbeteren. De productiedatabase ervaart veel leesactiviteit tijdens normale operatie. Elke 4 uur haalt het ontwikkelingsteam een volledige export van de productiedatabase op om een staging-database te vullen; tijdens deze export ervaren gebruikers onacceptabele latentie en kan het ontwikkelingsteam de staging-omgeving niet gebruiken totdat de export is voltooid. Een solutions architect moet een vervangende architectuur aanbevelen die de applicatielatentie elimineert en het ontwikkelingsteam in staat stelt de staging-omgeving zonder vertraging te gebruiken. Welke oplossing voldoet aan deze vereisten?

De correcte optie lost de problemen op door Amazon Aurora MySQL te gebruiken voor hoge beschikbaarheid en prestaties, en database cloning voor de staging-omgeving. Aurora MySQL biedt superieure leesprestaties via Aurora Replicas, die ook Multi-AZ ondersteunen. Database cloning in Aurora maakt het mogelijk om direct een kopie van de productiedatabase te maken zonder de prestaties van de productie-instance te beïnvloeden, en de staging-omgeving is direct beschikbaar. De eerste optie is incorrect omdat mysqldump nog steeds latentieproblemen kan veroorzaken op de productie-instance tijdens de export en de staging-omgeving pas na voltooiing beschikbaar is. De derde optie is incorrect omdat het gebruik van de standby-instance van een Multi-AZ RDS-implementatie voor staging niet mogelijk is; de standby is alleen voor failover. De vierde optie is incorrect omdat mysqldump de latentieproblemen niet oplost en de beschikbaarheid van de staging-omgeving vertraagt.