Amazon DOP-C02: Container e Operazioni Serverless — Guida allo studio

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

Fa parte della AWS DevOps Engineer Professional DOP-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Panoramica

I container e il serverless cambiano il modo in cui si operano, si scalano e si rilasciano le applicazioni su AWS. Questa sezione collega le primitive operative tra Amazon ECS, AWS Fargate, Amazon EKS, Amazon ECR, AWS Lambda e Amazon API Gateway in modo da poter progettare deployment sicuri, applicare la governance delle immagini, ottimizzare la concorrenza e fare scelte coerenti tra capacità basata su EC2 e Fargate. Si concentra sui modelli di scheduling di task e pod, sugli health check e i controlli di deployment, sullo spostamento del traffico (traffic shifting), sulla distribuzione di immagini tra account e sulle funzionalità di performance come il caching delle API e la concorrenza provvista (provisioned concurrency) di Lambda.

Amazon ECS e AWS Fargate

Le definizioni di task (task definition) di ECS dichiarano uno o più container e tutta la configurazione di runtime necessaria allo scheduler. Gli elementi chiave includono riserve e limiti di CPU/memoria, portMappings, variabili d’ambiente e segreti (da AWS Secrets Manager o Systems Manager Parameter Store), parametri Linux e ulimit, logConfiguration (awslogs, firelens, ecc.), dimensione di ephemeralStorage (per Fargate, 20–200 GB) e volumi (incluso EFS). Utilizzare il ruolo di esecuzione del task (task execution role) per il pull delle immagini e per i driver di log; utilizzare il ruolo del task (task role) per l’accesso dell’applicazione alle API AWS. L’healthCheck del container definisce comando, intervallo, timeout, tentativi e startPeriod. In combinazione con dependsOn (condition=HEALTHY), gli health check impongono un ordine di avvio per i sidecar.

I servizi ECS mantengono il numero di task desiderato e, opzionalmente, registrano i task con un ALB/NLB. La deploymentConfiguration del servizio controlla gli aggiornamenti rolling con minimumHealthyPercent e maximumPercent. Il circuit breaker di deployment (enabled/rollback) può annullare automaticamente i rollout falliti quando i task non superano gli health check. L’autoscaling del servizio si integra con Application Auto Scaling per il target tracking basato su CPU/memoria o su ALB RequestCountPerTarget. Il service discovery (AWS Cloud Map) e ECS Service Connect semplificano il traffico service-to-service.

Tipi di cluster e capacità:

Il launch type EC2 esegue i task su istanze EC2 autogestite. Utilizza gruppi di Auto Scaling, vincoli/strategie di posizionamento (placement constraints/strategies) e qualsiasi networkMode (bridge/host/awsvpc). I task daemon e le AMI specializzate (es. Bottlerocket) sono supportati.
Il launch type Fargate è l’ambiente di calcolo serverless per container. Utilizza esclusivamente il networking awsvpc, fornendo a ogni task la propria ENI e il proprio gruppo di sicurezza. Non ci sono task daemon; ci si affida a sidecar o a integrazioni native del servizio (es. FireLens). Le versioni della piattaforma (platform version) determinano le funzionalità disponibili (controllare le note di rilascio per il supporto di EFS, ephemeral storage e exec). Fargate Spot riduce i costi per i task interrompibili. Scegliere CPU/memoria in coppie supportate (es. da 0,25 vCPU/0,5–2 GB fino a 16 vCPU/120 GB). Quando si opera in subnet private, aggiungere endpoint di interfaccia VPC per ECR (api e dkr), CloudWatch Logs e un endpoint gateway S3 per effettuare il pull delle immagini e inviare i log senza un NAT.

Fargate e EFS: definire un volume EFS nella definizione del task e montarlo con TLS; preferire i punti di accesso (access point) EFS per applicare il principio del minimo privilegio e l’imposizione dell’identità. Questo supporta esigenze stateful come configurazioni condivise, pesi di modelli di machine learning o file intermedi, senza doverli incorporare (baking) nelle immagini.

Health check dei container, aggiornamenti rolling e blue/green:

Gli health check avvengono su più livelli: container (basato su CMD), task ECS (stati aggregati dei container) e stato di salute del target del load balancer (HTTP/TCP). Allineare intervalli e soglie in modo che ECS possa sostituire gradualmente i task non integri prima che l’ALB deregistri i target.
Gli aggiornamenti rolling sono l’impostazione predefinita di ECS. Ottimizzare minHealthy/maxPercent per controllare il surge (picco di carico) e la sicurezza della capacità.
Il blue/green utilizza CodeDeploy con ECS (deploymentController di tipo

undefined

). CodeDeploy gestisce due gruppi di target dietro l’ALB, sposta il traffico di test sul set “green” (AfterAllowTestTraffic), esegue controlli automatizzati (ad esempio tramite Lambda), quindi sposta il traffico di produzione. Collegare gli allarmi di CloudWatch per eseguire il rollback in caso di picchi di errori 5XX, latenza o metriche personalizzate. Questo pattern isola i fallimenti e fornisce ripristini rapidi con un downtime quasi nullo.

Governance delle immagini con ECR:

Scansione: abilitare la scansione “scan-on-push” e adottare la scansione avanzata (enhanced scanning) di Amazon Inspector per una copertura continua delle CVE e per gli SBOM. Bloccare i deployment in base alla gravità delle vulnerabilità utilizzando controlli nella pipeline.
Le policy del ciclo di vita (lifecycle policies) fanno scadere i vecchi tag delle immagini per numero/età e prefisso del tag. Combinarle con l’immutabilità dei tag (tag immutability) per bloccare le sovrascritture accidentali.
Crittografia: utilizzare la crittografia gestita da ECR o una chiave KMS gestita dal cliente (customer-managed) con una policy della chiave appropriata.
Cross-account: allegare policy di risorsa al repository per concedere permessi di pull/push da altri account o ruoli di CI. Utilizzare le regole di replica (replication rules) di ECR per copiare le immagini tra Regioni/account per migliorare la località e ridurre il raggio d’impatto (blast radius). PrivateLink (endpoint VPC) consente il pull delle immagini senza accesso a Internet.

Modelli di Compute per Amazon EKS

EKS separa il control plane gestito dalle scelte relative al data plane:

I gruppi di nodi gestiti (MNG) si occupano del provisioning e della gestione del ciclo di vita dei nodi worker EC2. Si integrano con i launch template per la scelta dell’AMI (Amazon Linux 2, Bottlerocket), dei tipi di istanza e dei parametri di bootstrap. Gli MNG gestiscono gli aggiornamenti continui (rolling update) con capacità di surge e cordon/drain automatizzati per ridurre al minimo le interruzioni. Utilizza i taint e le toleration dei nodi per indirizzare carichi di lavoro specifici. Combinali con il Cluster Autoscaler (o Karpenter) per dimensionare correttamente la capacità dei nodi in base ai pod in attesa (pending).

I nodi autogestiti offrono pieno controllo sul bootstrap e sul sistema operativo, ma aggiungono un sovraccarico operativo; sono tipicamente riservati per kernel speciali o hardware di nicchia.

EKS su Fargate esegue i pod senza la necessità di gestire i nodi. I profili Fargate associano namespace/label a Fargate. Ogni pod ottiene la propria ENI (awsvpc), semplificando l’isolamento di rete. Le limitazioni includono l’assenza di DaemonSet, l’impossibilità di usare la rete/i volumi dell’host e restrizioni sui carichi di lavoro privilegiati. Gli agenti di osservabilità (es. Fluent Bit) devono essere eseguiti come sidecar o utilizzare la raccolta di log gestita. Questo modello è ideale per carichi di lavoro con picchi di traffico (spiky), di piccole dimensioni (small-footprint) o multi-tenant che beneficiano dell’isolamento per-pod e di un modello economico pay-per-pod.

Add-on operativi:

VPC CNI, CoreDNS e kube-proxy sono add-on gestiti; fissa le versioni compatibili con la versione del cluster ed esegui l’aggiornamento in modo deliberato.
IAM Roles for Service Accounts (IRSA) applica l’accesso AWS con il principio del privilegio minimo (least-privilege) per pod e sostituisce la condivisione delle credenziali del ruolo del nodo.
Il bilanciamento del carico tramite l’AWS Load Balancer Controller supporta ALB/NLB per Service e Ingress; assicurati di avere regole IAM e dei security group corrette, specialmente quando si utilizzano MNG e Fargate insieme.
Storage persistente tramite driver CSI (EBS per lo storage a blocchi per-pod, EFS per lo storage condiviso POSIX). Per Fargate, EFS è l’opzione tipica per lo stato condiviso.

Operatività e Concorrenza di AWS Lambda

Packaging e configurazione:

I pacchetti di deployment possono essere archivi ZIP (con il runtime del linguaggio) o immagini container fino a 10 GB. Il formato ZIP è più leggero per codice di piccole dimensioni; le immagini unificano gli strumenti con build basate su container.
I Layer incapsulano librerie condivise tra più funzioni; mantienili minimali e versionati. Una funzione può includere fino a cinque layer.
Le versioni sono snapshot immutabili; gli alias sono puntatori stabili alle versioni e possono avere pesi per la distribuzione del traffico (traffic shifting).
Lo storage effimero ha un valore predefinito di 512 MB e può essere aumentato fino a 10.240 MB per build, file temporanei o cache di inferenza ML. Scegli tra x86_64 o arm64 per un compromesso tra costo e prestazioni. Utilizza le variabili d’ambiente per la configurazione e integra con Secrets Manager o Parameter Store.

Distribuzione del traffico e sicurezza:

Usa CodeDeploy per distribuzioni canary/lineari con rollback automatico basato su allarmi CloudWatch (es. errori 5XX, latenza o metriche applicative personalizzate). In alternativa, imposta direttamente i pesi degli alias per un semplice routing A/B.
Utilizza il logging strutturato verso CloudWatch Logs e crea filtri di metrica per derivare metriche dimensionate per operazione/versione/codice senza modificare la strumentazione delle metriche. Abilita X-Ray per il tracciamento della latenza end-to-end.

Controlli della concorrenza:

La concorrenza non riservata attinge dal pool regionale dell’account. Picchi di traffico possono “affamare” (starve) le altre funzioni, sottraendo loro risorse.
La concorrenza riservata limita la concorrenza massima di una funzione e ne garantisce la capacità, ritagliandola dal pool regionale; questo fornisce isolamento dai “vicini rumorosi” (noisy neighbors).
La concorrenza fornita (provisioned) mantiene gli ambienti di esecuzione inizializzati per una versione/alias, eliminando virtualmente i cold start e stabilizzando la latenza. Scala la concorrenza fornita con Application Auto Scaling in base all’orario o a metriche.
Il throttling si verifica quando una funzione raggiunge il suo limite di concorrenza; i chiamanti sincroni ricevono errori 429, mentre le invocazioni asincrone vengono ritentate con backoff esponenziale e possono finire in una dead-letter queue dopo un numero configurato di tentativi. Per le sorgenti basate su polling come SQS, Lambda aumenta la concorrenza in base alla profondità della coda; assicurati che la concorrenza riservata/fornita e la capacità a valle corrispondano al numero massimo di messaggi in transito (inflight) per evitare la crescita del backlog.

Progettazione di API Gateway e Accesso Cross-Account a ECR

API Gateway: confronto tra REST API e HTTP API:

Le REST API offrono il set di funzionalità più ricco: mapping di richiesta/risposta (VTL), piani di utilizzo e chiavi API, authorizer, WAF e caching a livello di stage. Scegli le REST API quando hai bisogno di trasformazioni avanzate, chiavi API con quote o integrazioni mature con l’ecosistema.
Le HTTP API hanno latenza e costi inferiori, con un routing più semplice verso backend Lambda e HTTP (incluse le integrazioni con ALB/NLB/private). Supportano authorizer JWT e IAM ma mancano di molte funzionalità delle REST API, tra cui il caching a livello di stage e le trasformazioni VTL. Scegli le HTTP API per un proxying diretto con un overhead minimo.

Stage e throttling:

Gli stage associano una specifica distribuzione (deployment) a un percorso URL. Configura variabili di stage, logging e throttling a livello di stage. Applica i piani di utilizzo (REST) per imporre throttling e quote per singola chiave API. Le impostazioni di throttling includono rate e burst; si combinano con i limiti a livello di account, quindi assicurati che il traffico aggregato non superi le quote regionali. Abilita i log di accesso con JSON strutturato e integra WAF per ispezionare e bloccare le richieste malevole.

Caching (solo REST API):

La cache a livello di stage riduce il carico sul backend e la latenza; imposta i TTL per metodo, abilita la crittografia e considera i parametri/header della chiave di cache per garantirne la correttezza. Invalida le cache dopo i deployment che modificano la forma o il comportamento della risposta.

Connettività privata:

Scegli il tipo di endpoint: edge-optimized (REST, globale tramite CloudFront), regional o private (endpoint VPC). Le integrazioni private con VPC Link si connettono a backend NLB/ALB in VPC senza esposizione pubblica.

Accesso cross-account a ECR:

Usa le policy di risorsa del repository per concedere permessi di pull/push ai principal in altri account (ruoli di CI/CD o di runtime). Se si utilizza una chiave KMS gestita dal cliente, estendi di conseguenza la policy della chiave. Per la distribuzione multi-account, definisci regole di replica ECR verso gli account/Regioni di destinazione e valida l’integrità dell’immagine con l’immutabilità dei tag e il pinning del digest nei deployment.

Scenario Pratico

Spotify sta modernizzando uno stack di microservizi per le playlist per ridurre la variabilità della latenza durante i picchi di rilascio e per rafforzare la supply chain delle immagini tra più account AWS.

Standardizzare la build e la governance delle immagini

Implementa repository ECR con scan-on-push e scansione avanzata di Amazon Inspector. Aggiungi l’immutabilità dei tag e policy di lifecycle per conservare le ultime N versioni per branch e rimuovere quelle obsolete (prune drift). Configura la replica cross-Region/account dall’account di build agli account di produzione (prod) e di staging. Perché: Inspector assicura una copertura continua delle CVE, l’immutabilità previene l’hijacking dei tag e la replica localizza le operazioni di pull per ridurre la latenza di deployment e il blast radius.

Erogare API stateless su ECS con Fargate

Definisci le task definition di ECS con awslogs e FireLens per log e metriche strutturate. Abilita l’healthCheck del container e allinea gli health check del target group dell’ALB. Monta un volume EFS per la configurazione condivisa in sola lettura tramite un access point. Esegui i servizi su Fargate con una strategia di capacity provider che combina Fargate e Fargate Spot per l’efficienza dei costi. Perché: Fargate elimina la gestione dei nodi e isola i task per ENI; EFS evita di includere (baking) le configurazioni nelle immagini e supporta rollback atomici della configurazione.

Deployment sicuri con blue/green e test automatizzati

Passa i servizi ECS a un deployment controller di tipo CodeDeploy. Configura due target group sull’ALB. Usa uno spostamento canary (canary shift) con AfterAllowTestTraffic per invocare un test runner Lambda che esegue test sugli endpoint critici entro 5 minuti. Associa allarmi CloudWatch sulla latenza p90 e sugli errori 5XX per attivare il rollback. Perché: il blue/green di CodeDeploy isola il rischio, l’hook di test valida l’ambiente green prima del cutover completo e gli allarmi forniscono un rollback automatico e oggettivo.

Operazioni sensibili alla latenza su Lambda con cold start stabilizzati

Per un’API di supporto alla tokenizzazione, impacchetta la funzione come ZIP con dipendenze ridotte (slim). Crea una versione/alias e abilita la provisioned concurrency dimensionata per i picchi di traffico. Gestisci la provisioned concurrency tramite Application Auto Scaling con una pianificazione giornaliera che segue le finestre di rilascio. Usa un canary di CodeDeploy (10%/15 minuti) per lo spostamento del traffico basato su alias, collegato ad allarmi CloudWatch. Perché: la provisioned concurrency elimina i cold start durante i picchi; i canary su alias consentono un’esposizione graduale con un rollback rapido.

Esporre API esterne tramite API Gateway e proteggere i backend privati

Esponi Lambda e l’ALB di ECS tramite API Gateway (fronting). Usa le HTTP API per il proxy Lambda per minimizzare costi/latenza. Usa la REST API per il percorso dell’ALB di ECS che necessita di mapping richiesta/risposta e caching di stage per gli endpoint con carichi di lettura elevati. Applica web ACL di WAF e throttling a livello di stage; abilita i log di accesso strutturati. Perché: abbinare i tipi di API alle necessità ottimizza costi e funzionalità; il caching riduce il carico; WAF e il throttling aggiungono protezione durante i picchi di traffico.

Pull cross-account in runtime senza accesso a Internet

Nei VPC di runtime, aggiungi endpoint di interfaccia per ECR (api, dkr) e CloudWatch Logs, e un gateway endpoint per S3. Associa le policy di risorsa del repository ECR per consentire ai ruoli di esecuzione dei task dell’account di produzione di effettuare il pull. Usa una chiave KMS gestita dal cliente con una policy della chiave cross-account per la crittografia delle immagini at-rest. Perché: i pull di immagini privati evitano i costi del NAT e i rischi di egress; le policy esplicite di risorsa/chiave applicano il principio del minimo privilegio (least-privilege) per l’accesso cross-account.

Questo design riduce il carico operativo (nessun nodo da gestire), fornisce una latenza deterministica tramite la provisioned concurrency e rollout allineati agli health check dell’ALB, e garantisce la provenienza dell’immagine end-to-end con la scansione, la replica e l’immutabilità di ECR.

← Sicurezza · Tutti i domini · Alta Affidabilità →

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