Een bedrijf migreert twee eenvoudige Node.js-applicaties van on-premises naar AWS. Eén app verzamelt sensordata en schrijft deze naar een MySQL-database; de andere aggregeert data in rapporten. Wanneer aggregatietaken worden uitgevoerd, mislukken sommige laadtaken. De migratie moet de laadfouten oplossen en moet plaatsvinden zonder verstoringen of wijzigingen die zichtbaar zijn voor klanten. Wat moet een solutions architect aanbevelen?

De correcte optie pakt de laadfouten aan door aggregatietaken uit te voeren op een Aurora Replica, waardoor de primaire database wordt ontlast en de prestaties van de collector-applicatie niet worden beïnvloed. AWS DMS zorgt voor continue, non-disruptieve replicatie van de on-premises database naar Aurora. Het gebruik van Lambda-functies achter een ALB en RDS Proxy biedt een schaalbare en veerkrachtige architectuur voor de collector-applicatie, en RDS Proxy verbetert het beheer van databaseverbindingen. De migratie is klant-transparant door het omleiden van DNS na synchronisatie. De eerste optie is onjuist omdat het gebruik van een Network Load Balancer (NLB) voor Lambda-functies niet de meest geschikte keuze is; een Application Load Balancer (ALB) is beter geschikt voor HTTP/S-verkeer naar Lambda. De tweede optie lost de laadfouten niet op, omdat het de aggregatietaken nog steeds op de primaire database zou uitvoeren. De vierde optie introduceert Kinesis, wat een aanzienlijke architectuurwijziging is en niet nodig is om de gestelde problemen op te lossen, en het omleiden van DNS naar een Kinesis-stroom is niet logisch voor een database-migratie.