Amazon SAP-C02: Compute e Auto Scaling — Guida allo studio

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

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

Progettazione, storage e networking delle istanze EC2

La progettazione delle istanze EC2 inizia abbinando le caratteristiche del carico di lavoro alle famiglie di istanze, bilanciando vCPU, memoria, rete e storage locale. Scegliere tipi di istanza ottimizzati per il calcolo (C), per la memoria (R/X), per lo storage (I/D) o con GPU (P/G) in base al profiling. Sfruttare le istanze basate su Nitro e ENA/SR-IOV per un throughput di rete elevato e una bassa latenza. Per dati temporanei sensibili alla latenza o con IOPS elevati, considerare l’instance store (effimero) su SSD I3/I4 o Nitro; per lo storage a blocchi durevole, utilizzare EBS con Provisioned IOPS (io2/io2 Block Express) e abilitare la crittografia EBS con KMS per la gestione delle chiavi. Quando le istanze si trovano in VPC dietro ad Application Load Balancer, assicurarsi che gli ALB esposti su Internet siano posizionati in subnet pubbliche e che i target risiedano in subnet private; posizionare erroneamente gli ALB o configurare in modo errato i security group è una trappola comune. Utilizzare i Placement Group (cluster per HPC a bassa latenza, partition per sistemi stateful distribuiti su larga scala, spread per l’isolamento dei guasti) per influenzare il posizionamento, ma accettandone i compromessi: il tipo cluster offre le migliori prestazioni ma riduce la tolleranza ai guasti a livello di AZ. Per la crittografia dei dati in transito, utilizzare la terminazione TLS sull’ALB o TLS end-to-end con passthrough su NLB. I criteri decisionali ponderano il costo rispetto alle prestazioni: tipi di istanza più densi riducono i costi ma possono aumentare il “blast radius” (raggio d’impatto) e i costi di licenza; preferire il right-sizing guidato da CloudWatch, AWS Compute Optimizer e test di carico piuttosto che regole empiriche.

Auto Scaling Group, policy e gestione del ciclo di vita

Gli Auto Scaling Group (ASG) devono essere progettati per l’elasticità, la resilienza e l’efficienza dei costi, utilizzando una combinazione di launch template, policy per istanze miste, lifecycle hook e policy di scalabilità. Utilizzare i launch template per versionare AMI, override del tipo di istanza, configurazioni EBS e user-data; le istanze miste con un’allocazione Spot ottimizzata per la capacità o una strategia diversificata riducono il rischio di interruzione e abbassano i costi. Per il comportamento di scalabilità, preferire le policy di target-tracking per metriche prevedibili (CPU, numero di richieste per target) e lo step-scaling quando sono necessarie azioni multi-stadio basate su soglie; la scalabilità predittiva può pre-allocare capacità per modelli diurni noti. Implementare i lifecycle hook per eseguire attività di inizializzazione personalizzate o di “draining” prima della terminazione; combinarli con i warm pool per ridurre il tempo di avvio del servizio (“time-to-serve”) e con la scalabilità pianificata per le baseline durante l’orario di lavoro. Gli health check dovrebbero integrare i controlli di stato di ELB e EC2 per evitare sostituzioni premature. Fare attenzione a trappole come il “churn” (avvicendamento) durante lo scale-in causato da cooldown troppo aggressivi, la ponderazione errata delle istanze negli ASG misti e il non tenere conto del tempo di “warm-up” dell’applicazione. Per i servizi stateful, evitare uno scale-in rapido che causa la perdita delle cache in memoria; per il compromesso costo/resilienza, la capacità basata su istanze Spot con fallback su On-Demand offre risparmi ma richiede la gestione delle interruzioni, mentre il 100% On-Demand massimizza la prevedibilità a un costo maggiore.

Container e orchestrazione: scelte tra ECS, EKS e Fargate

La scelta tra Amazon ECS, EKS e Fargate dipende dal modello operativo, dalle esigenze di controllo e dai pattern del carico di lavoro. Fargate elimina la gestione dei nodi ed è ideale per i team che danno priorità alla semplicità operativa, ma ha un prezzo per vCPU più alto e limiti sullo storage effimero; supporta Fargate Spot per ridurre i costi. ECS offre una stretta integrazione con AWS e semplicità per i clienti che desiderano l’orchestrazione di container senza la complessità di Kubernetes. EKS è appropriato quando sono richiesti l’ecosistema Kubernetes, la portabilità o funzionalità di scheduling avanzate; considerare i managed node group o nodi autogestiti (Self-Managed) con Karpenter per un right-sizing dinamico. I limiti di rete (densità di ENI/pod) e il comportamento del CNI influenzano la densità dei pod e il dimensionamento dei nodi; su EKS, gli IAM Roles for Service Accounts e l’EBS CSI per i volumi persistenti riducono la proliferazione delle credenziali e abilitano lo storage per-pod. Per i file system condivisi, utilizzare EFS (NFS) o FSx (Lustre) a seconda delle esigenze di throughput e latenza; evitare container basati su NFS per operazioni con un alto numero di metadati—preferire EFS con modalità di throughput ottimizzate per il carico di lavoro. Implementare il cluster autoscaler o Karpenter per la scalabilità dei nodi e l’auto scaling dei servizi con le metriche di ALB/ECS. Tra le trappole comuni ci sono l’ignorare i pod disruption budget, il sottostimare le quote del control plane di Kubernetes e il sovradimensionare i nodi invece di usare strategie di bin-packing—i compromessi tra controllo, costo e carico operativo dovrebbero guidare la scelta.

Pattern di elaborazione serverless, vincoli di Lambda e progettazione event-driven

Il serverless riduce l’overhead operativo ma richiede pattern architetturali che gestiscano la concorrenza, lo stato e i limiti dei sistemi a valle. Lambda è eccellente per attività di breve durata e basate su eventi, per backend di API tramite API Gateway o ALB e per l’elaborazione asincrona con SQS o SNS. Utilizzare Step Functions per orchestrare flussi di lavoro di lunga durata e DynamoDB o RDS Proxy per l’accesso ai database al fine di mitigare le “connection storm” (tempeste di connessioni). Prestare attenzione all’overhead dei cold start di Lambda in VPC, causato dalla creazione delle ENI; mitigare con la concorrenza fornita (provisioned concurrency) per endpoint sensibili alla latenza o utilizzare endpoint VPC e RDS Proxy per limitare le connessioni. Implementare il pattern fan-out/fan-in tramite SNS + SQS, o Kinesis/MKS per l’elaborazione ordinata di stream; utilizzare le code dead-letter (DLQ) di SQS e gestori idempotenti per gestire i tentativi (retry) e i duplicati. I limiti di concorrenza, la concorrenza riservata e il throttling devono essere pianificati per evitare fallimenti a cascata; progettare per la contropressione (backpressure) utilizzando throttle, retry con jitter e circuit breaker (tramite API Gateway o personalizzati). I compromessi costo-prestazioni sono chiari: Lambda è conveniente per carichi di lavoro con picchi e di breve durata, mentre Fargate o EC2 sono migliori per attività ad alta intensità di CPU o di lunga esecuzione. Le trappole comuni includono l’affidarsi a retry sincroni che sovraccaricano i sistemi a valle, l’archiviare lo stato nella directory locale /tmp aspettandosi persistenza e il non predisporre risorse per i cold start in flussi di lavoro critici per la latenza.

Problema Pratico: Migrazione del contact center di NovaTel Enterprise

Scenario: NovaTel Enterprise gestisce un contact center ibrido con instradamento delle chiamate on-premise e una connessione Direct Connect verso AWS. Eseguono i session broker su istanze EC2 in due Availability Zone e desiderano migrare a un contact center gestito da AWS con alta disponibilità e latenza prevedibile tra il PBX on-premise e i servizi cloud.

Sfida: Hanno bisogno di connettività a bassa latenza per il traffico SIP, di un livello di elaborazione scalabile per la gestione della voce che tolleri le interruzioni delle istanze Spot e di una strategia di DR (Disaster Recovery) tra Regioni senza aumentare la complessità operativa.

Approccio Raccomandato:

Provisionare Amazon Connect per le funzionalità di contact center e utilizzare una VPN Site-to-Site o Direct Connect con un AWS Transit Gateway per il trunking SIP a bassa latenza, terminando su un NLB con passthrough TLS davanti ai session broker.
Eseguire i componenti di elaborazione delle sessioni come un Auto Scaling Group misto con launch template che utilizzano istanze Spot ottimizzate per la capacità (capacity-optimized) più un fallback su istanze On-Demand, e usare i Placement Group (di tipo spread) per l’isolamento dei guasti dei broker critici.
Per i media delle chiamate stateful che richiedono storage effimero a bassa latenza, utilizzare istanze basate su instance store (Nitro) per il buffering dei media e replicare i metadati della sessione su DynamoDB o ElastiCache con replica multi-AZ; impiegare RDS (Multi-AZ) o Aurora Global DB per i dati persistenti con repliche di lettura cross-Region per il DR.
Implementare lifecycle hook e warm pool per minimizzare il cold-start dei broker, il failover ponderato di Route 53 per il DR cross-Region, e CloudWatch + SNS/SQS per l’alerting e i runbook di failover automatizzati.

Motivazione: L’utilizzo di servizi di contact center gestiti riduce il carico operativo, mentre gli ASG misti con istanze Spot ottimizzano i costi; l’isolamento dei media effimeri su instance store preserva le prestazioni, e la replica dello stato durevole su DynamoDB/ElastiCache più RDS/Aurora multi-AZ fornisce resilienza e un failover rapido, in linea con le best practice di architettura professionale.

← Sicurezza · Tutti i domini · Storage e gestione dei dati →

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