Een bedrijf draait EC2-instances in een private subnet en Lambda-functies die directe netwerktoegang tot die EC2-instances nodig hebben. De applicatie zal minstens 1 jaar draaien en het aantal Lambda-functies zal naar verwachting groeien. Het bedrijf wil de besparingen op applicatieresources maximaliseren en de netwerklatentie laag houden. Welke oplossing voldoet aan deze vereisten?

De correcte optie is om een Compute Savings Plan te kopen, de duur en het geheugengebruik van de Lambda-functies, het aantal aanroepen en de hoeveelheid overgedragen data te optimaliseren, en de Lambda-functies te verbinden met het private subnet dat de EC2-instances bevat. Een Compute Savings Plan biedt flexibiliteit en besparingen voor zowel EC2-instances als Lambda-functies, wat ideaal is voor een groeiend aantal Lambda-functies. Het verbinden van Lambda met het private subnet zorgt voor directe, low-latency toegang tot de EC2-instances. De eerste optie is incorrect omdat een EC2 Instance Savings Plan alleen van toepassing is op EC2 en niet op Lambda, wat de besparingen beperkt. De tweede optie is incorrect omdat het verbinden van Lambda met een public subnet de beveiliging in gevaar brengt en niet de beste praktijk is voor communicatie met private EC2-instances. De vierde optie is incorrect omdat het houden van Lambda-functies in de Lambda service VPC directe netwerktoegang tot de private EC2-instances verhindert, wat de vereiste van directe toegang en lage latentie niet vervult.