Een bedrijfskritische applicatie draait op één EC2-instance en gebruikt een ElastiCache for Redis single-node cluster plus een RDS for MariaDB DB-instance. Elk component moet gezond en actief zijn om de applicatie te laten functioneren. Je moet de architectuur opnieuw ontwerpen zodat de infrastructuur automatisch kan herstellen van storingen met minimale downtime. Welke combinatie van wijzigingen moet je implementeren? (Kies er drie.)

Om automatische herstel en minimale downtime te garanderen, moet de applicatie-architectuur redundantie opbouwen. Het plaatsen van EC2-instances achter een Elastic Load Balancer en het gebruik van een Auto Scaling group met minimaal twee instances zorgt ervoor dat de applicatie beschikbaar blijft, zelfs als één instance uitvalt. Een Multi-AZ deployment voor RDS for MariaDB biedt automatische failover naar een stand-by replica in een andere Availability Zone bij een storing van de primaire DB-instance. Voor ElastiCache for Redis zorgt een replicatiegroep met Multi-AZ ervoor dat gegevens beschikbaar blijven en er automatisch wordt gefailoverd naar een replica als de primaire node uitvalt. De optie om de Auto Scaling group in onbeperkte modus te configureren is niet correct, omdat dit de kosten onnodig kan verhogen en niet direct bijdraagt aan herstel van storingen. Een read replica van de RDS DB-instance in dezelfde Availability Zone biedt geen bescherming tegen AZ-brede storingen en vereist handmatige promotie. Het configureren van ElastiCache for Redis met een Auto Scaling group is niet de juiste methode voor ElastiCache; replicatiegroepen en Multi-AZ zijn de correcte benaderingen voor hoge beschikbaarheid.