Modalità di invocazione Lambda

L'API Invoke può essere invocata in due modalità: modalità evento e modalità richiesta-risposta.

• La modalità evento aggiunge il payload a una coda per una chiamata asincrona.

• La modalità richiesta-risposta invoca in modo sincrono la funzione con il payload fornito e restituisce immediatamente una risposta.

In entrambi i casi, l'esecuzione della funzione viene sempre eseguita in un ambiente di esecuzione Lambda, ma il payload segue percorsi diversi. Per ulteriori informazioni, consultare "Ambienti di esecuzione Lambda" in questo documento.

È anche possibile utilizzare altri servizi AWS che eseguono invocazioni per conto dell'utente. La modalità di invocazione utilizzata dipende dal servizio AWS in uso e da come è configurato. Per ulteriori informazioni su come altri servizi AWS si integrano con Lambda, consultare Utilizzo di AWS Lambda con altri servizi.

Quando Lambda riceve un'invocazione di tipo richiesta-risposta, il payload viene passato direttamente al servizio Invoke. Se il servizio Invoke non è disponibile, i chiamanti possono mettere temporaneamente in coda il payload lato client per ritentare la chiamata un determinato numero di volte. Se il servizio Invoke riceve il payload, questo tenta di identificare un ambiente di esecuzione disponibile per la richiesta e passa il payload a tale ambiente di esecuzione per completare la chiamata. Se non esistono ambienti di esecuzione esistenti o appropriati, ne verrà creato uno dinamicamente in risposta alla richiesta. Durante il transito, i payload di invocazione inviati al servizio Invoke sono protetti con TLS 1.2+. Il traffico all'interno del servizio Lambda (dal bilanciatore del carico in poi) passa attraverso un Virtual Private Cloud (VPC) interno isolato, di proprietà del servizio Lambda, all'interno della regione AWS a cui è stata inviata la richiesta.

Figura 2: Modello di invocazione per la modalità richiesta-risposta di AWS Lambda

I payload della modalità di invocazione evento vengono sempre aggiunti a una coda per l'elaborazione prima della chiamata. Tutti i payload destinati all'elaborazione sono aggiunti a una coda Amazon Simple Queue Service (Amazon SQS). Gli eventi in coda sono sempre protetti in transito con TLS 1.2+, ma al momento non sono soggetti a crittografia dei dati a riposo. Le code Amazon SQS utilizzate da Lambda sono gestite dal servizio Lambda e non sono visibili all'utente. Gli eventi in coda possono essere archiviati in una coda condivisa, ma possono essere migrati o assegnati a code dedicate in base a una serie di fattori che non possono essere controllati direttamente dagli utenti (ad esempio, ritmo di invocazione, dimensione degli eventi e così via).

Gli eventi in coda vengono recuperati in batch dal parco istanze di poller di Lambda. Il parco istanze di poller è un gruppo di istanze EC2 il cui scopo è quello di elaborare le chiamate di eventi in coda che non sono ancora state elaborate. Quando il parco istanze di poller recupera un evento in coda che deve essere elaborato, lo fa passandolo al servizio Invoke proprio come farebbe un utente che utilizza la modalità richiesta-risposta.

Se l'invocazione non può essere eseguita, il parco istanze di poller memorizzerà temporaneamente l'evento in memoria sull'host finché non sarà in grado di completare correttamente l'esecuzione o finché non sarà stato superato il numero di tentativi di esecuzione. Nessun dato di payload viene mai scritto su disco nel parco istanze di poller stesso. Le attività del parco istanze di polling possono essere condivise da tutti i clienti AWS, garantendo il minor tempo possibile per l'invocazione. Per ulteriori informazioni su quali servizi possono utilizzare la modalità di invocazione evento, consultare Utilizzo di AWS Lambda con altri servizi.