Amazon SOA-C02: Elaborazione e Auto Scaling — Guida allo studio

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

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

Questo dominio copre la gestione delle istanze EC2 e di Auto Scaling per fornire capacità di calcolo affidabile ed economicamente vantaggiosa. Si concentra sulle operazioni del ciclo di vita delle istanze, sulle strategie di scalabilità, sull’integrazione con i load balancer, sul posizionamento per le prestazioni e la resilienza, e sui comportamenti di manutenzione/terminazione che influenzano la disponibilità e lo stato. La padronanza operativa significa scegliere i tipi di istanza corretti, i modelli di configurazione di avvio, le policy di scalabilità e l’integrazione dei controlli di integrità (health check) per soddisfare gli SLA controllando al contempo i costi.

Ciclo di vita e gestione delle istanze EC2

La gestione del ciclo di vita di EC2 inizia dal punto della configurazione di avvio: utilizzare i Launch Template (aws ec2 create-launch-template / console) per definire AMI, tipo di istanza, profilo dell’istanza IAM, user-data, interfacce di rete, mappatura EBS e opzioni dei metadati; i template supportano il versioning, il che rende semplici le implementazioni immutabili (immutable deploys). Le implementazioni immutabili utilizzano una nuova versione del launch template (o un nuovo launch template) e creano un nuovo Auto Scaling group oppure utilizzano la funzione di aggiornamento delle istanze (instance refresh) dell’ASG per sostituire le istanze; evitare aggiornamenti sul posto (in-place upgrades) delle istanze in esecuzione quando le modifiche influiscono sul comportamento all’avvio o su patch a livello di AMI.

I pattern operativi da CLI/console includono

undefined

per avvii singoli e

undefined

per avvii gestiti da ASG. Scegliere tra il “baking” di AMI (Packer/CodeBuild) e gli script di avvio user-data in base al tempo di avvio: integrare (“bake”) le dipendenze pesanti nelle AMI per ridurre la durata dell’avvio; utilizzare gli user-data per la configurazione specifica dell’ambiente. Per lo storage effimero, ricordare che i volumi instance store vengono persi alla terminazione; configurare i volumi root e di dati con DeleteOnTermination=false se si richiede la persistenza di EBS dopo la terminazione dell’istanza.

Gruppi di Auto Scaling, policy e lifecycle hook

Gli Auto Scaling Group (ASG) sono configurati con un launch template o una launch configuration e controllano la capacità desiderata/minima/massima tra le zone di disponibilità (Availability Zone). Scegliere launch template + MixedInstancesPolicy per flotte ottimizzate in termini di costi che combinano istanze On-Demand e Spot con un elenco di tipi di istanza; utilizzare la ponderazione delle istanze (instance weighting) e le strategie di allocazione ottimizzate per la capacità (capacity-optimized) per una capacità prevedibile. Per le implementazioni, preferire pattern immutabili: creare una nuova versione del launch template ed eseguire un aggiornamento delle istanze dell’ASG (instance refresh) o uno scambio blue/green anziché riconfigurare le istanze esistenti.

Le policy di scalabilità si esprimono come:

Target tracking (PolicyType=TargetTrackingScaling): imposta una metrica predefinita come ALB RequestCountPerTarget o la CPU media dell’ASG e un valore target; l’ASG gestisce automaticamente gli aggiustamenti.
Step scaling (PolicyType=StepScaling): definisce allarmi CloudWatch che attivano specifici passaggi di aggiustamento (es. +2, +4) in base alla gravità della violazione; utile per carichi di lavoro con picchi (bursty).
Simple scaling (legacy): aggiustamenti a singolo passo con un periodo di cooldown; generalmente superata dal target tracking o dallo step scaling.

Utilizzare i lifecycle hook (

undefined

) per mettere in pausa la terminazione/l’avvio dell’istanza. I lifecycle hook consentono di drenare le connessioni (drain connections), replicare lo stato (su S3/RDS) o notificare i sistemi di orchestrazione tramite SNS/SQS/Lambda prima del completamento; impostare sempre un HeartbeatTimeout e un’azione predefinita per evitare stati di blocco.

Tipi di Elastic Load Balancing e controlli di integrità (health check)

Scegliere il tipo di load balancer in base al pattern di traffico: Application Load Balancer (ALB) per HTTP/HTTPS con routing basato sul contenuto e regole su host/percorso; Network Load Balancer (NLB) per prestazioni estreme e IP statici per TCP/UDP; Classic Load Balancer (CLB) solo per stack legacy. Creare ALB e target group con

undefined

; registrare i target dell’ASG utilizzando l’associazione del target group dell’ASG per un’integrazione automatica con il ciclo di vita dei controlli di integrità.

L’integrazione dei controlli di integrità richiede l’allineamento dei controlli di integrità dell’ASG e dell’ELB: impostare HealthCheckType dell’ASG su ELB (

undefined

) in modo che un’istanza sia considerata integra solo dopo che il load balancer ha contrassegnato il suo target come integro. Tipi di controlli di integrità e implicazioni:

Controllo di integrità del target group di ALB/NLB: supporta HTTP/HTTPS/TCP e misura la prontezza a livello di applicazione; raccomandato per le app web.
Controlli di integrità del solo ASG: da utilizzare per semplici controlli a livello di host (es. controlli di stato EC2).
HealthCheckGracePeriod: concede alle nuove istanze il tempo di avviarsi, eseguire gli user-data e superare i controlli a livello di applicazione.

Implicazioni della stickiness (session affinity): la stickiness del target group dell’ALB utilizza un’affinità basata su cookie applicativi (basata sulla durata) che può migliorare l’affinità di sessione ma riduce la distribuzione uniforme e complica gli aggiornamenti continui (rolling updates). NLB supporta l’affinità basata sull’IP del client; utilizzare la stickiness solo quando lo stato della sessione non può essere esternalizzato.

Posizionamento delle istanze, pianificazione della capacità e metriche di scalabilità

Le decisioni sul posizionamento influenzano la latenza e i domini di errore: i gruppi di posizionamento (placement group) offrono strategie di tipo cluster (rete a bassa latenza), spread (un’istanza per rack per istanze critiche) e partition (partizioni isolate dai guasti). Gli ASG bilanciano le istanze tra le AZ per impostazione predefinita; è preferibile una pianificazione della capacità consapevole delle AZ per evitare hotspot in una singola AZ. Per la CLI: aws ec2 create-placement-group --strategy cluster|spread|partition.

La pianificazione della capacità considera i tipi di istanza, le opzioni di acquisto e le metriche:

Tipi di istanza: scegliere famiglie ottimizzate per CPU/memoria/rete (M/C/R/T/D/I) in base al carico di lavoro; misurare con test di carico rappresentativi.
Acquisto: On-Demand per la prevedibilità, Reserved o Savings Plans per la riduzione dei costi a regime, Spot per l’efficienza dei costi transitori; utilizzare una MixedInstancesPolicy per combinare tipi e opzioni di acquisto.
Metriche di scalabilità: le metriche predefinite degli ASG utilizzano la media della CPU del gruppo; preferire metriche a livello di applicazione come ALB RequestCountPerTarget o metriche personalizzate di CloudWatch (es. profondità della coda) per il tracciamento degli obiettivi (target tracking). Pattern comuni:
Utilizzare il target tracking con ALB/request-count-per-target quando è necessario un numero costante di richieste per istanza.
Utilizzare lo step scaling per picchi improvvisi e di grandi dimensioni con passaggi di ripristino definiti.
Considerare il Predictive Scaling per carichi di lavoro ciclici giornalieri.

Ripristino delle istanze, comportamento alla terminazione e manutenzione

Pianificare i guasti e la manutenzione delle istanze abilitando il ripristino automatico per problemi hardware (allarme CloudWatch con azione EC2 Recover) e gestendo gli eventi pianificati (describe-instance-status). Configurare i flag instance-initiated-shutdown-behavior e EBS DeleteOnTermination per controllare il ciclo di vita dei volumi; utilizzare aws ec2 modify-instance-attribute --instance-id i-xxx --block-device-mappings per le modifiche.

Comportamento alla terminazione negli ASG: le policy di terminazione degli ASG decidono quale istanza terminare per prima (Default: la più vecchia launch configuration o euristiche basate sulla salute dell’istanza e sul bilanciamento delle AZ). Dettagli operativi importanti:

Lo stato locale è effimero: i volumi instance-store e le cache in memoria vengono persi alla terminazione. Non dare per scontato che la sostituzione preservi lo stato locale; persistere i dati critici su EBS (con snapshot/backup appropriati), S3 o una cache esterna (ElastiCache).
Utilizzare i lifecycle hook per drenare il traffico e scaricare lo stato prima della terminazione.
Utilizzare l’instance refresh o il blue/green per la manutenzione al fine di sostituire le istanze in sicurezza; aws autoscaling start-instance-refresh --auto-scaling-group-name my-asg --preferences file://prefs.json.

Errori Comuni e Criteri Decisionali

Fare affidamento sui cooldown predefiniti e su metriche basate solo sulla CPU: scegliere metriche allineate al comportamento dell’applicazione (ALB RequestCountPerTarget, profondità della coda); impostare i cooldown per tenere conto del tempo di avvio e HealthCheckGracePeriod per evitare oscillazioni.
Non utilizzare i lifecycle hook per una terminazione controllata (graceful termination): senza hook, le richieste in corso e le cache locali vengono perse; implementare hook con SNS/SQS/Lambda per drenare e persistere lo stato.
Presumere che la sostituzione di un’istanza preservi lo stato locale: i volumi instance-store locali e le cache in memoria sono effimeri; progettare istanze stateless o replicare lo stato su storage durevoli.
Abusare della stickiness: la stickiness aumenta la distribuzione non uniforme del carico e complica la scalabilità e gli aggiornamenti; preferire archivi di sessione esterni (ElastiCache, DynamoDB) per lo scale-out.
Ignorare il bilanciamento tra AZ e i placement group: posizionare troppe istanze in una singola AZ o in un gruppo cluster può creare single point of failure; utilizzare la distribuzione multi-AZ degli ASG e strategie di placement group appropriate.
Configurare in modo errato l’integrazione degli health check: il health-check-type dell’ASG deve corrispondere agli health check dell’ELB/target group e HealthCheckGracePeriod deve essere sufficientemente lungo per l’inizializzazione dell’app, altrimenti le istanze sane verranno terminate.

Problema Pratico: Scenario d’Uso

StreamingCo gestisce un’API per le anteprime video che subisce picchi di traffico giornalieri e utilizza cache su disco locale sulle istanze EC2; di recente, lo scale-up è stato lento e le istanze terminate perdono la cache, causando tempi di risposta scarsi.

Migrare la launch configuration in un Launch Template e creare una AMI leggera (bake) con le dipendenze di runtime; utilizzare aws ec2 create-launch-template e il versioning per deploy immutabili.
Configurare un ASG con una MixedInstancesPolicy che elenchi diversi tipi di istanza e un’allocazione Spot + On-Demand per bilanciare costi e capacità.
Collegare un ALB e utilizzare il TargetTrackingScaling sulla metrica ALB RequestCountPerTarget con un HealthCheckGracePeriod impostato sul tempo di bootstrap dell’applicazione.
Implementare lifecycle hook sulle terminazioni dell’ASG per drenare le connessioni ed eseguire un flusso Lambda/SNS per persistere le chiavi di cache necessarie su ElastiCache o S3 prima della terminazione.
Esternalizzare lo stato di sessione e cache su ElastiCache o S3 e utilizzare placement group/distribuzione tra AZ per soddisfare i requisiti di latenza e dominio di errore.

Motivazione: L’uso di launch template e deploy immutabili riduce la variabilità all’avvio; il target tracking basato su ALB lega la scalabilità al carico di richieste anziché alla CPU; i lifecycle hook prevengono la perdita di dati alla terminazione; l’esternalizzazione della cache elimina la dipendenza dallo stato locale effimero, consentendo una scalabilità rapida e sicura e costi inferiori grazie a strategie miste di istanze/acquisto.

← Archiviazione e gestione dei dati · Tutti i domini · Database e caching →

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