Un'azienda ha un account AWS utilizzato per l'ingegneria del software. L'account ha accesso al data center on-premise dell'azienda tramite una coppia di connessioni AWS Direct Connect. Tutto il traffico non-VPC viene instradato al virtual private gateway. Un team di sviluppo ha creato una funzione AWS Lambda tramite la console. Il team deve consentire alla funzione di accedere a un database che viene eseguito in una sottorete privata nel data center dell'azienda. Quale soluzione soddisferà questi requisiti?

La risposta corretta è configurare la funzione Lambda per l'esecuzione nella VPC con il gruppo di sicurezza appropriato. Le funzioni Lambda, per impostazione predefinita, vengono eseguite al di fuori di una VPC e non possono accedere direttamente alle risorse in una sottorete privata on-premise. Configurando la funzione Lambda per l'esecuzione all'interno della VPC, le viene assegnata un'interfaccia di rete elastica (ENI) che le consente di accedere alle risorse all'interno della VPC e, tramite Direct Connect, al data center on-premise. Il gruppo di sicurezza appropriato garantirà che la funzione Lambda possa comunicare con il database. Le altre opzioni non sono corrette: Configurare una VPN non è necessario poiché esiste già una connessione Direct Connect. Aggiornare le tabelle di routing non è sufficiente; la funzione Lambda deve prima essere all'interno della VPC per poter utilizzare il routing. Creare un indirizzo IP elastico e non utilizzare un'interfaccia di rete elastica è errato; le funzioni Lambda in una VPC utilizzano ENI e gli EIP sono per l'accesso pubblico, non per l'accesso privato on-premise.