Amazon DVA-C02: Serverless e AWS Lambda — Guida allo studio

By Laurynas Brazys · 27 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

Fa parte della AWS Developer Associate DVA-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Versioni, alias, layer e pacchettizzazione

Le versioni di Lambda sono snapshot immutabili del codice e della configurazione, create con l’API PublishVersion (ad esempio, boto3.client(’lambda’).publish_version(FunctionName=‘MyFunc’)). Utilizza le versioni per fornire rilasci riproducibili e poi crea alias (boto3.client(’lambda’).create_alias o update_alias) come puntatori stabili che possono anche contenere una configurazione di routing per suddividere il traffico tra le versioni per rollout graduali. I layer forniscono un modo per condividere librerie native o pacchetti di runtime comuni; publish_layer_version consente di allegare dipendenze (ad es. binari compilati) separatamente dal pacchetto della funzione, in modo che le build siano più piccole e i cold start più veloci. Per la pacchettizzazione, preferisci piccoli archivi zip per deploy rapidi (o upload su S3 per artefatti più grandi) e adotta immagini container quando hai bisogno di binari di grandi dimensioni o runtime personalizzati; docker build + aws lambda create-function –package-type Image registrerà le immagini archiviate in ECR (le immagini container supportano dimensioni molto più grandi). Le trappole comuni includono l’inserimento di credenziali nelle variabili d’ambiente, il superamento dei limiti di dimensione del pacchetto di deployment e il dimenticare che i layer sono versionati e immutabili: aggiorna le dipendenze pubblicando una nuova versione del layer e aggiornando la configurazione della funzione. Per i rollback programmatici, aggiorna l’alias in modo che punti a una versione precedente (boto3.client(’lambda’).update_alias(FunctionName=‘MyFunc’, Name=‘prod’, FunctionVersion=‘3’)) per minimizzare l’impatto operativo.

Ambiente di esecuzione, ottimizzazione delle prestazioni e mitigazione dei cold start

La CPU di Lambda scala con la memoria, quindi il miglioramento dei carichi di lavoro CPU-bound si ottiene tipicamente aumentando l’impostazione MemorySize (tramite UpdateFunctionConfiguration) piuttosto che modificando un parametro CPU separato; misura con AWS X-Ray e le metriche di CloudWatch per trovare il punto di equilibrio ottimale tra durata e costo. I cold start sono influenzati dalla dimensione del pacchetto, dal codice di inizializzazione, dall’uso del networking VPC (latenza di collegamento dell’ENI) e dal runtime del linguaggio; si possono mitigare riducendo l’inizializzazione, spostando le librerie pesanti nei layer, utilizzando la Provisioned Concurrency (put_provisioned_concurrency_config) o usando immagini container con entrypoint ottimizzati. Per le funzioni collegate a un VPC, evita i picchi di cold start utilizzando endpoint VPC per S3/DynamoDB o RDS Proxy per limitare il ricambio di connessioni (connection churn) e i costi del NAT Gateway; assicurati che il ruolo di esecuzione di Lambda includa la policy gestita AWSLambdaVPCAccessExecutionRole e che le sottoreti dispongano di uno spazio di indirizzi IP adeguato per le ENI. Fai attenzione a trappole come i timeout sincroni: imposta il timeout della funzione su un valore inferiore a quello delle dipendenze a valle per garantire che i chiamanti in uscita vedano un modello di fallimento coerente, e usa token di idempotenza per i tentativi (retry) poiché servizi come SQS, SNS e Kinesis forniscono una semantica at-least-once (almeno una volta).

Accesso VPC, storage effimero e controlli di sicurezza

Quando inserisci una Lambda in un VPC, devi configurare gli ID delle sottoreti e i gruppi di sicurezza nella configurazione della funzione; la funzione utilizza quindi le ENI in quelle sott

Integrazioni di eventi, gestione degli errori, test in locale e strategie di deployment

Lambda si integra nativamente con molte sorgenti di eventi: notifiche di eventi S3, DynamoDB Streams, Kinesis, SQS e API Gateway. Per le sorgenti basate su stream, è necessario ottimizzare la dimensione del batch (batch size) e il parallelizationFactor, monitorare IteratorAge e gestire i fallimenti parziali, poiché Lambda ritenterà i batch falliti e può bloccare l’elaborazione a valle quando gli errori persistono. Per le invocazioni asincrone, utilizzare DLQ o Destinations per catturare i fallimenti (configurare l’invocazione asincrona con destinazioni onFailure/onSuccess). Le funzioni attivate da S3 devono proteggersi da invocazioni ricorsive quando si scrive nuovamente nello stesso bucket, controllando le chiavi degli oggetti o usando i tag degli oggetti. Il test in locale si esegue al meglio con la CLI di AWS SAM (sam build; sam local invoke; sam local start-api) o con runtime Lambda containerizzati; i test unitari possono usare moto o mocking locale, ma i test di integrazione dovrebbero essere eseguiti su risorse AWS reali in account di test effimeri. I deployment dovrebbero usare funzioni versionate con alias e lo spostamento del traffico tramite CodeDeploy o UpdateAlias con una RoutingConfig per eseguire deployment canary o lineari; implementare hook PreTraffic e PostTraffic per la verifica. Le trappole tipiche includono l’ignorare l’idempotenza per i tentativi (retry), non gestire le risposte parziali di BatchGetItem (controllare UnprocessedKeys) e usare ruoli IAM con permessi eccessivamente ampi per l’esecuzione.

Problema Pratico: Scenario d’Uso

Scenario: PhotoSpot Inc. gestisce una Lambda in Python che elabora immagini caricate su S3, scrive metadati su DynamoDB e chiama un’API di terze parti per l’ottimizzazione delle immagini. La funzione richiede prestazioni rapide di cold-start, credenziali API sicure, rollback sicuri e accesso a un proxy RDS ospitato in un VPC per l’arricchimento dei metadati.

Sfida: Ridurre la latenza di cold-start per gli upload visibili all’utente, proteggere e ruotare la chiave API di terze parti, e abilitare rollback sicuri senza downtime con spostamento controllato del traffico.

Approccio Raccomandato:

Costruire e pubblicare release immutabili: usare la CLI di AWS o boto3 per aggiornare il codice, poi boto3.client('lambda').publish_version(FunctionName='PhotoProcessor') e creare/aggiornare un alias con boto3.client('lambda').update_alias(FunctionName='PhotoProcessor', Name='prod', FunctionVersion='7', RoutingConfig={'AdditionalVersionWeights': {'8': 0.1}}).
Mitigare i cold-start: configurare la Provisioned Concurrency per l’alias con boto3.client('lambda').put_provisioned_concurrency_config(FunctionName='PhotoProcessor', Qualifier='prod', ProvisionedConcurrentExecutions=10) e spostare le librerie native pesanti in un layer pubblicato (boto3.client('lambda').publish_layer_version).
Mettere in sicurezza le credenziali: archiviare la chiave API di terze parti in AWS Secrets Manager, concedere al ruolo della Lambda il principio del privilegio minimo (least-privilege) e recuperarla al cold-start con boto3.client('secretsmanager').get_secret_value(SecretId=secret_arn) invece di incorporare i segreti nel codice o in variabili d’ambiente in chiaro.
Gestione del VPC e delle connessioni: posizionare la funzione in subnet private con security group, usare RDS Proxy per l’accesso al DB per evitare tempeste di connessioni (connection storm) e creare un endpoint VPC per S3 in modo che le letture delle immagini non richiedano un NAT.

Motivazione: L’uso di versioni e alias con lo spostamento del traffico (traffic shifting) consente rollout sicuri e rollback immediati riassegnando un alias. La Provisioned Concurrency e i layer riducono la latenza di inizializzazione, mentre Secrets Manager centralizza la rotazione delle credenziali e minimizza l’esposizione dei segreti. RDS Proxy e gli endpoint VPC riducono la latenza e i costi operativi, diminuendo il ricambio continuo di connessioni (connection churn) e la dipendenza dal NAT.

Tutti i domini · Amazon API Gateway e Integrazione di applicazioni →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →