Een bedrijf implementeert een two-tier webapplicatie in een VPC. De webtier gebruikt een Auto Scaling group in publieke subnets verspreid over meerdere Availability Zones. De databasetier is een Amazon RDS for MySQL DB instance in private subnets. De webtier kan geen verbinding maken met de database, hoewel de DB draait. Network ACL's, security groups en routetabellen staan nog op hun standaardinstellingen. Wat moet een solutions architect aanbevelen om de applicatie te repareren?

De correcte oplossing is het toevoegen van een inkomende regel aan de security group van de RDS-instance. Security groups fungeren als virtuele firewalls op instanceniveau en controleren inkomend en uitgaand verkeer. Standaard blokkeren ze al het inkomende verkeer. Door een inkomende regel toe te voegen die verkeer van de security group van de webtier toestaat, kunnen de webservers verbinding maken met de database. De andere opties zijn incorrect: Network ACL's zijn stateless en werken op subnetniveau. Hoewel ze verkeer kunnen blokkeren, is het onwaarschijnlijk dat ze de oorzaak zijn als security groups en routetabellen op standaard staan en de DB draait. Bovendien zou een expliciete regel in de NACL van het private subnet niet voldoende zijn als de security group van de RDS-instance het verkeer blokkeert. Routetabellen controleren waar netwerkverkeer naartoe wordt gestuurd. Binnen een VPC met standaardinstellingen is er al een impliciete route voor verkeer tussen subnets. Een extra route is niet nodig voor communicatie binnen dezelfde VPC. Het implementeren van de tiers in twee afzonderlijke VPC's en het configureren van VPC peering is een onnodig complexe oplossing voor dit probleem. Het is beter om de communicatie binnen de bestaande VPC te faciliteren.