Esecuzioni Lambda

Quando Lambda esegue una funzione per conto dell'utente, gestisce sia il provisioning che la configurazione dei sistemi sottostanti necessari per eseguire il codice. Ciò consente agli sviluppatori di concentrarsi sulla logica di business e sulla scrittura di codice, non sull'amministrazione e sulla gestione dei sistemi sottostanti.

Il servizio Lambda è suddiviso nel piano di controllo e nel piano dati. Ogni piano ricopre un ruolo distinto nel servizio. Il piano di controllo fornisce le API di gestione (ad esempio CreateFunction, UpdateFunctionCode, PublishLayerVersion e così via) e gestisce le integrazioni con tutti i servizi AWS. Le comunicazioni con il piano di controllo di Lambda sono protette in transito tramite TLS. Tutti i dati degli utenti memorizzati nel piano di controllo di Lambda sono protetti dalla crittografia dei dati a riposo attraverso l'uso di AWS KMS, progettato per proteggerli da divulgazioni non autorizzate o manomissioni.

Il piano dati è l'API Invoke di Lambda che attiva l'invocazione delle funzioni Lambda. Quando viene richiamata una funzione Lambda, il piano dati alloca un ambiente di esecuzionesu un AWS Lambda Worker (o semplicemente Worker, un tipo di istanza Amazon EC2) a quella versione della funzione oppure sceglie un ambiente di esecuzione esistente che è già stato configurato per quella versione di funzione, che poi viene utilizzato per completare l'invocazione. Per ulteriori informazioni, consultare la sezione "MicroVM e Worker di AWS Lambda" di questo documento.

Ambienti di esecuzione Lambda

Ogni chiamata viene instradata dal servizio Invoke di Lambda a un ambiente di esecuzione su un Worker in grado di soddisfare la richiesta. Salvo che attraverso il piano dati, i clienti e gli altri utenti non possono avviare direttamente comunicazioni di rete in ingresso verso un ambiente di esecuzione. Questo aiuta a garantire che le comunicazioni con l'ambiente di esecuzione siano autenticate e autorizzate.

Gli ambienti di esecuzione sono riservati per una versione di funzione specifica e non possono essere riutilizzati tra versioni di funzioni, funzioni o account AWS. Ciò significa che una singola funzione che presenta due versioni diverse comporta la presenza di almeno due ambienti di esecuzione distinti.

Ogni ambiente di esecuzione può essere utilizzato solo per una chiamata simultanea alla volta e può essere riutilizzato su più invocazioni della stessa versione di funzione per motivi prestazionali. A seconda di una serie di fattori (ad esempio, ritmo delle invocazioni, configurazione delle funzioni e così via), possono esistere uno o più ambienti di esecuzione per una data versione di funzione. Con questo approccio, Lambda è in grado di garantire agli utenti l'isolamento a livello di versione delle funzioni.

Lambda attualmente non isola le invocazioni all'interno dell'ambiente di esecuzione di una versione di funzione. Ciò significa che una chiamata può concludersi lasciando uno stato che può influenzare la successiva invocazione (ad esempio, file scritti in /tmp o dati in memoria). Per assicurarsi che un'invocazione non possa influire su un'altra successiva, Lambda consiglia di creare funzioni distinte aggiuntive. Ad esempio, è possibile creare funzioni distinte per operazioni di analisi complesse che sono maggiormente soggette a errori e riutilizzare funzioni che non eseguono operazioni sensibili dal punto di vista della sicurezza. Lambda attualmente non limita il numero di funzioni che gli utenti possono creare. Per ulteriori informazioni sui limiti, consultare la pagina relativa alle quote di Lambda.

Gli ambienti di esecuzione sono costantemente monitorati e gestiti da Lambda e possono essere creati o distrutti per una serie di motivi, tra cui, a titolo esemplificativo ma non esaustivo:

I clienti possono gestire il numero di ambienti di esecuzione con pre-provisioning esistenti per una versione di funzione configurando la concorrenza con provisioning nella configurazione delle funzioni. Se configurato per farlo, Lambda creerà, gestirà e assicurerà che il numero configurato di ambienti di esecuzione sia sempre disponibile. Ciò garantisce ai clienti un maggiore controllo sulle prestazioni di avvio delle loro applicazioni serverless su qualsiasi scala.

A parte la configurazione della concorrenza con provisioning, i clienti non possono controllare in modo deterministico il numero di ambienti di esecuzione creati o gestiti da Lambda in risposta alle chiamate.

Ruolo di esecuzione

Ogni funzione Lambda deve inoltre essere configurata con un ruolo di esecuzione, che è un ruolo IAM che viene assunto dal servizio Lambda durante l'esecuzione di operazioni relative al piano di controllo e al piano dati relative alla funzione. Il servizio Lambda assume questo ruolo per recuperare credenziali di sicurezza temporanee che sono poi disponibili come variabili di ambiente durante l'invocazione di una funzione. Per motivi prestazionali, il servizio Lambda memorizzerà nella cache tali credenziali e potrà riutilizzarle in diversi ambienti di esecuzione che utilizzano lo stesso ruolo di esecuzione.

Per garantire il rispetto del principio del privilegio minimo, Lambda raccomanda che ogni funzione disponga del proprio ruolo unico e che sia configurata con il set minimo di autorizzazioni richieste.

Il servizio Lambda può anche assumere il ruolo di esecuzione per eseguire specifiche operazioni del piano di controllo come quelle relative alla creazione e alla configurazione di interfacce di rete elastiche (ENI) per funzioni VPC, invio di log ad Amazon CloudWatch Application Insights, invio di tracciamenti a AWS X-Ray o altre operazioni correlate differenti dalle invocazioni. Gli utenti possono sempre esaminare ed eseguire l'audit di tali casi d'uso esaminando i log di audit in AWS CloudTrail.

Per ulteriori informazioni su questo argomento, consultare la pagina della documentazione sul ruolo di esecuzione di AWS Lambda.

Lambda MicroVM e Worker

Lambda creerà i suoi ambienti di esecuzione su un parco istanze Amazon EC2 chiamate AWS Lambda Worker. I Worker sono istanze Nitro EC2 bare metal che vengono avviate e gestite da Lambda in un account AWS isolato separato che non è visibile agli utenti. I Worker dispongono di una o più Micro Virtual Machines (MVM) virtualizzate tramite hardware create da Firecracker. Firecracker è un Virtual Machine Monitor (VMM) open source che utilizza la macchina virtuale basata sul kernel Linux (KVM) per creare e gestire MVM. È progettato appositamente per la creazione e la gestione di container e servizi basati su funzioni sicuri e multi-tenant che forniscono modelli operativi serverless. Per ulteriori informazioni sul modello di sicurezza di Firecracker, consultare il sito web del progetto Firecracker.

Come parte del modello di responsabilità condivisa, Lambda è responsabile del mantenimento della configurazione di sicurezza, dei controlli e del livello di applicazione delle patch dei Worker. Il team Lambda utilizza Amazon Inspector per scoprire potenziali problemi di sicurezza noti, nonché altri meccanismi di notifica dei problemi di sicurezza personalizzati ed elenchi di pre-divulgazione, in modo che gli utenti non debbano gestire il livello di sicurezza sottostante del loro ambiente di esecuzione.

Figura 3: Modello di isolamento per i Worker di AWS Lambda

I Worker sono soggetti a una durata massima del tempo di lease di 14 ore. Quando un Worker si avvicina al tempo massimo di lease, non vengono instradate verso di esso ulteriori invocazioni, le MVM vengono regolarmente arrestate e l'istanza Worker sottostante viene terminata. Lambda monitora e genera allarmi in modo continuo relativamente alle attività del ciclo di vita del suo parco istanze.

Tutte le comunicazioni del piano dati con i Worker sono crittografate utilizzando Advanced Encryption Standard with Galois/Counter Mode (AES-GCM). Oltre alle operazioni sul piano dati, i clienti non possono interagire direttamente con un Worker in quanto è ospitato in un Amazon VPC isolato in rete gestito da Lambda negli account di servizio di Lambda.

Quando un Worker deve creare un nuovo ambiente di esecuzione, gli viene concessa un'autorizzazione limitata nel tempo per accedere agli artefatti delle funzioni del cliente. Questi artefatti sono ottimizzati specificamente per l'ambiente di esecuzione e i Worker di Lambda. Il codice funzione che viene caricato utilizzando il formato ZIP viene ottimizzato una sola volta e quindi viene archiviato in un formato crittografato utilizzando una chiave gestita da AWS e AES-GCM.

Anche le funzioni caricate su Lambda utilizzando il formato immagine container sono ottimizzate. L'immagine del container viene prima scaricata dalla fonte originale, ottimizzata in blocchi distinti e quindi archiviata sotto forma di blocchi crittografati utilizzando un metodo di crittografia convergente autenticato che utilizza una combinazione di AES-CTR, AES-GCM e MAC SHA-256. Il metodo di crittografia convergente consente a Lambda di deduplicare in modo sicuro i blocchi crittografati. Tutte le chiavi necessarie per decrittare i dati degli utenti sono protette tramite Customer Master Key AWS KMS (CMK) gestite dal cliente. L'utilizzo di CMK da parte del servizio Lambda è disponibile per gli utenti nei log di AWS CloudTrail a fini di monitoraggio e auditing.