Amazon SAA-C03: Calcolo, Auto Scaling e Gestione delle Istanze — Guida allo studio

By Laurynas Brazys · 17 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Fa parte della AWS SAA-C03 — Guida di studio completa. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Tipi di istanze EC2 e AMI

La scelta della famiglia di istanze EC2 corretta è il fondamento di un livello di calcolo ben architettato, perché famiglia, generazione e dimensione determinano insieme l’architettura della CPU, il rapporto tra memoria e vCPU, la larghezza di banda di rete e gli acceleratori disponibili. Le istanze per uso generale (M6i, M7g, serie T) sono adatte a web tier bilanciati e carichi di lavoro misti. Quelle ottimizzate per il calcolo (C7i, C7gn) si adattano a simulazioni CPU-bound, codifica, elaborazione batch e front-end web. Le ottimizzate per la memoria (R7i, X2idn) sono pensate per database e cache in-memory. Le ottimizzate per lo storage (I4i, D3) sono mirate a NoSQL, HDFS e data warehousing. Le accelerate (P5, G5, Trn1, Inf) forniscono GPU o chip per ML. Le istanze Graviton (suffisso g) offrono tipicamente un rapporto prezzo-prestazioni migliore del 20-40% per carichi di lavoro scale-out che si compilano senza problemi su ARM64.

La famiglia T è “burstabile” e utilizza di default la modalità standard, in cui i crediti CPU si accumulano durante i periodi di inattività e si consumano durante i picchi (burst); una volta esauriti i crediti, le prestazioni vengono limitate al livello di base (baseline). Per carichi di lavoro con picchi imprevedibili — piccoli web tier, ambienti di sviluppo/test o ambienti Elastic Beanstalk a supporto di un front-end con picchi di traffico — le istanze T in modalità illimitata consentono all’istanza di prendere in prestito crediti, fatturando un piccolo sovrapprezzo per vCPU-ora di superamento, evitando così un throttling percepibile dall’utente. Questo è il motivo per cui gli ambienti Beanstalk con brevi periodi di saturazione della CPU vengono solitamente risolti abilitando la modalità illimitata anziché passare a una famiglia ottimizzata per il calcolo più costosa. È importante riservare la serie T a carichi di lavoro genuinamente variabili e con una media di utilizzo bassa: un utilizzo CPU sostenuto in modalità standard esaurisce i crediti in pochi minuti.

La scalabilità verticale (passare a una dimensione maggiore all’interno della stessa famiglia) è limitata dalla più grande istanza disponibile, impone un downtime per la modifica, introduce un singolo punto di guasto (single point of failure) e non può distribuire il carico di lavoro tra più Zone di Disponibilità. Ogni volta che il carico varia in modo significativo, la scalabilità orizzontale con un gruppo di Auto Scaling è la risposta corretta.

Le “Golden AMI” integrano il codice dell’applicazione, il runtime e le dipendenze nello snapshot di root, producendo avvii rapidi e deterministici — un aspetto critico quando l’Auto Scaling reagisce a un picco. Eseguire il bootstrap tramite user-data a ogni avvio aggiunge minuti di latenza proprio nel momento sbagliato.

Scelte di storage: Instance Store vs EBS, Snapshot e Fast Snapshot Restore

Le istanze offrono due substrati di storage: instance store (NVMe effimero collegato all’host fisico) e Amazon EBS (storage a blocchi collegato in rete). L’instance store offre la latenza più bassa possibile, ma i suoi dati vengono distrutti in caso di arresto, ibernazione, terminazione o guasto hardware. Trattarlo come storage durevole è un errore comune e pericoloso — è appropriato solo per spazio temporaneo (scratch space), buffer, cache o dati replicati come un data node HDFS le cui repliche esistono su altri nodi. I dati durevoli devono risiedere su EBS, con backup tramite snapshot archiviate in S3.

Le snapshot sono incrementali e indipendenti una volta create, quindi il ripristino di una di esse su un nuovo volume non influisce mai sulla sorgente. Il modo canonico per duplicare un grande set di dati di produzione in un ambiente di test è creare una snapshot del volume di origine e creare nuovi volumi da quella snapshot. Tuttavia, i volumi ripristinati da snapshot caricano i blocchi da S3 in modalità lazy-load alla prima lettura, causando una latenza I/O significativa finché ogni blocco non viene “idratato”. Lo stesso caricamento lazy-load influisce sulle nuove istanze avviate da AMI i cui snapshot di root sono di grandi dimensioni — queste appaiono lente per diversi minuti dopo l’avvio.

EBS Fast Snapshot Restore (FSR) elimina questa penalità. Abilita FSR sulla snapshot per le AZ in cui il gruppo di Auto Scaling avvia le istanze, e i volumi creati da essa forniranno immediatamente le massime prestazioni assegnate (provisioned performance):

aws ec2 enable-fast-snapshot-restores \
  --availability-zones us-east-1a us-east-1b \
  --source-snapshot-ids snap-0123456789abcdef0

Questo è essenziale quando gli eventi di scale-out devono aggiungere capacità in pochi secondi anziché minuti.

Networking avanzato con ENA ed EFA

Il throughput di rete pubblicizzato scala con la dimensione dell’istanza, ma è raggiungibile solo quando è presente il driver Elastic Network Adapter (ENA). ENA fornisce un networking avanzato basato su SR-IOV, supportando fino a 200 Gbps sulle istanze più recenti. Le AMI moderne (Amazon Linux 2, Ubuntu recenti, Windows) vengono fornite con ENA abilitato; è possibile verificarlo con:

aws ec2 describe-instances --instance-ids i-0abc \
  --query 'Reservations[].Instances[].EnaSupport'

modinfo ena | grep version
ethtool -i eth0

Senza ENA, le istanze ricadono silenziosamente su un throughput inferiore e un jitter più elevato, compromettendo qualsiasi architettura a bassa latenza, indipendentemente dalla scelta del gruppo di posizionamento.

Per operazioni collettive su scala di microsecondi — CFD, modellazione meteorologica, dinamica molecolare, training di modelli di grandi dimensioni — aggiungi l’Elastic Fabric Adapter (EFA). EFA espone un trasporto OS-bypass (Libfabric) a MPI e NCCL, evitando completamente lo stack di rete del kernel. EFA offre i suoi vantaggi solo all’interno di un gruppo di posizionamento di tipo cluster su tipi di istanza supportati (c7gn, hpc7a, p5) e richiede il driver EFA più una build compatibile di MPI (Open MPI, Intel MPI) o NCCL.

aws ec2 create-placement-group --group-name hpc-cg --strategy cluster
aws ec2 run-instances --instance-type hpc7a.96xlarge \
  --placement GroupName=hpc-cg \
  --network-interfaces InterfaceType=efa,DeviceIndex=0,SubnetId=subnet-abc

Placement Group

I placement group controllano la topologia fisica delle istanze:

Scegliere in modo errato vanifica la funzionalità. Un gruppo di tipo cluster non può estendersi su più AZ — è intra-AZ per progettazione. Un gruppo di tipo spread non può ospitare cento server web a causa del limite di sette per AZ. Il posizionamento di tipo partition, non spread, è lo strumento corretto per un cluster Kafka da 40 nodi perché allinea il posizionamento delle repliche con i domini di errore. Per un’alta disponibilità generica, non confinare un ASG a un singolo placement group in una AZ — distribuisci l’ASG su più AZ.

Per carichi di lavoro di analisi in streaming o MPI che richiedono la minima latenza da nodo a nodo, la combinazione corretta è un placement group di tipo cluster più istanze con ENA abilitato; il cluster riduce il numero di hop e l’ENA fornisce la capacità in pacchetti al secondo necessaria per concretizzare tale beneficio di latenza.

Auto Scaling Group e Launch Template

Un Auto Scaling group (ASG) è l’unità di runtime che mantiene un numero desiderato di istanze EC2 su una o più AZ, definito da tre numeri interi — MinSize, DesiredCapacity, MaxSize — e un elenco di sottoreti. L’ASG stesso non descrive cosa avviare; questa è la responsabilità di un launch template, il sostituto moderno delle launch configuration. I launch template supportano il versioning, le policy per istanze miste, la combinazione di istanze Spot/On-Demand, l’imposizione di IMDSv2, le prenotazioni di capacità e le istanze T in modalità illimitata. Un launch template fa riferimento a un’AMI, a uno o più tipi di istanza, a security group, a un profilo di istanza IAM, a user data e alle mappature dei dispositivi a blocchi.

Il pattern canonico per applicazioni web stateless è AMI + Launch Template + ASG + ALB. L’AMI garantisce un avvio rapido; l’ALB (o NLB per TCP/UDP) distribuisce il traffico e gestisce gli health check; l’ASG registra automaticamente le nuove istanze nel target group e termina quelle non integre. L’implementazione multi-AZ (minimo due AZ, tre per sistemi basati su quorum) è obbligatoria — un ASG legato a una singola sottorete non può sopravvivere a un’interruzione di AZ perché l’ASG stesso non può lanciare sostituzioni mentre l’AZ è compromessa.

MyASG:
  Type: AWS::AutoScaling::AutoScalingGroup
  Properties:
    MinSize: 2
    MaxSize: 20
    DesiredCapacity: 4
    VPCZoneIdentifier: [subnet-a, subnet-b]
    TargetGroupARNs: [!Ref AppTargetGroup]
    LaunchTemplate:
      LaunchTemplateId: !Ref AppLT
      Version: !GetAtt AppLT.LatestVersionNumber
    HealthCheckType: ELB
    HealthCheckGracePeriod: 120

Policy di scaling: Target Tracking, Step, Scheduled, Predictive

Lo scaling degli ASG ha quattro modalità, ognuna delle quali risolve un problema diverso:

• Target tracking sceglie una metrica e la mantiene vicino a un valore target (es. ASGAverageCPUUtilization = 50%, ALBRequestCountPerTarget = 1000). È auto-regolante — AWS gestisce gli allarmi e adatta la velocità in base a quanto la metrica si discosta. Questa dovrebbe essere la scelta predefinita.
• Step scaling aggiunge o rimuove capacità in scaglioni graduali in base a quanto una metrica è fuori dall’intervallo desiderato, utile quando l’entità della reazione deve essere proporzionale alla gravità dell’allarme.
• Simple scaling è obsoleto: un singolo aggiustamento per allarme, si blocca durante il cooldown e non dovrebbe essere scelto per nuove architetture.
• Scheduled scaling modifica MinSize/DesiredCapacity/MaxSize a orari prestabiliti (cron).
• Predictive scaling utilizza il machine learning su uno storico fino a 14 giorni per prevedere le successive 48 ore, pre-allocando la capacità prima del picco di domanda.

Lo scaling dinamico è intrinsecamente reattivo — reagisce solo dopo che una metrica supera una soglia, e le nuove istanze necessitano poi di minuti per avviarsi, registrarsi e riscaldarsi. Per un’applicazione aziendale in cui gli utenti arrivano tutti alle 09:00 e riscontrano 2-3 ore di lentezza mentre l’ASG si adegua, lo scaling dinamico da solo non è la risposta corretta. Sovrapponi azioni pianificate prima del picco per aumentare MinSize e DesiredCapacity prima che arrivi la domanda:

ScheduledAction:
  AutoScalingGroupName: web-asg
  ScheduledActionName: pre-sale-warmup
  Recurrence: "0 8 * * *"
  MinSize: 20
  DesiredCapacity: 30
  MaxSize: 200

Poi, lascia che il target tracking assorba la variabilità residua. Il predictive scaling è la scelta giusta quando la forma del picco è stabile ma il suo orario esatto varia di giorno in giorno. Per spegnimenti prevedibili non di produzione (ambienti di sviluppo spenti di notte e nei fine settimana), un’azione pianificata per impostare desired=0, min=0 il venerdì sera e ripristinare il lunedì mattina è la soluzione con il minor overhead — l’ASG stesso funge da motore di pianificazione, senza bisogno di codice collante (glue) con Lambda o EventBridge.

La scelta della metrica è importante tanto quanto la scelta della policy. La CPU funziona per carichi di lavoro web CPU-bound, ma per worker guidati da un backlog che elaborano messaggi da SQS, è necessario scalare sulla profondità della coda, non sulla CPU: un worker bloccato in attesa di I/O può mostrare il 10% di utilizzo della CPU mentre milioni di messaggi si accumulano. Usa ApproximateNumberOfMessagesVisible per istanza, esposto come metrica personalizzata o tramite il target integrato SQSQueueBacklogPerInstance:

backlog_per_instance = messages_visible / running_instances
target = acceptable_latency_seconds / avg_processing_seconds_per_msg

TargetTrackingConfiguration:
  CustomizedMetricSpecification:
    MetricName: BacklogPerInstance
    Namespace: MyApp/Scaling
    Statistic: Average
  TargetValue: 100

Allo stesso modo, i tier HTTP sensibili alla latenza dovrebbero monitorare TargetResponseTime o RequestCountPerTarget; le applicazioni limitate dalla memoria, dal disco o dalla latenza di servizi a valle dovrebbero pubblicare una metrica personalizzata che rifletta il vero collo di bottiglia. Scalare sulla base della CPU quando la CPU non è il vincolo produce esattamente lo scenario di fallimento in cui le istanze non scalano orizzontalmente (scale out), le code crescono senza limiti e l’ALB restituisce errori 5xx.

Controlli di Integrità e Lifecycle Hook

Gli ASG utilizzano di default i controlli di stato di EC2, che rilevano i guasti dell’hypervisor ma non quelli dell’applicazione. Abilitare i controlli di integrità dell’ELB sull’ASG delega la decisione di sostituzione alla sonda a livello di applicazione del load balancer, il che è essenziale quando il sistema operativo funziona correttamente ma il processo è bloccato. Impostare HealthCheckGracePeriod con una durata sufficiente a completare l’esecuzione dei dati utente; altrimenti, le nuove istanze vengono terminate a metà del bootstrap, in un ciclo continuo.

La scelta del load balancer influisce sul significato di “sano” (healthy):

Un’applicazione HTTP dietro un NLB che esegue solo controlli di integrità TCP continuerà a ricevere traffico su un’istanza che accetta connessioni ma restituisce errori 500. Passare a un ALB — o configurare controlli di integrità HTTP sull’NLB — per ripristinare una segnalazione significativa.

I lifecycle hook mettono in pausa le istanze negli stati Pending:Wait o Terminating:Wait per consentire l’intervento di automazioni esterne. Al momento del lancio, un hook permette di registrare l’istanza con un sistema di gestione della configurazione, pre-riscaldare le cache o recuperare segreti prima che l’ALB inizi a inviare traffico. Durante la terminazione, un hook consente di drenare le sessioni, svuotare i log e deregistrare l’istanza da una service mesh. Gli hook emettono eventi EventBridge; i gestori devono chiamare CompleteLifecycleAction o l’hook scadrà (timeout), applicando l’azione predefinita (CONTINUE o ABANDON).

Warm Pool e Ibernazione

Il tempo di avvio a freddo (cold-launch) è un problema reale per le applicazioni che caricano modelli di grandi dimensioni, pre-riscaldano le cache o eseguono la compilazione JIT prima di poter servire richieste. Un warm pool è una riserva di istanze pre-inizializzate collegata all’ASG: le istanze si avviano, eseguono il bootstrap, e poi vengono fermate, mantenute in esecuzione o ibernate, rimanendo nel pool fino a quando l’ASG non esegue uno scale-out. Prelevare un’istanza dal pool evita minuti di avvio.

L’ibernazione sospende il sistema operativo sul volume root EBS crittografato, in modo che l’heap della JVM, i pesi di ML e la cache delle pagine del sistema operativo vengano ripristinati alla ripresa. Requisiti: volume root crittografato abbastanza grande da contenere la RAM, RAM dell’istanza ≤ 150 GB su una famiglia supportata, e HibernationOptions.Configured = true al momento del lancio. Un warm pool con PoolState: Hibernated combina entrambi i vantaggi: le istanze non hanno costi di calcolo mentre sono fermate e riprendono l’esecuzione in pochi secondi con la memoria già popolata. Questo è il pattern corretto quando un’applicazione “impiega molto tempo a caricare dati in memoria prima di diventare produttiva”.

Ripristino Automatico per Carichi di Lavoro non Scalabili

Non tutti i carichi di lavoro possono scalare orizzontalmente. Le applicazioni legacy con licenze legate all’indirizzo MAC, blocchi basati su file o stato di sessione in memoria senza uno store condiviso non possono essere eseguite su più di un’istanza: l’avvio di nodi aggiuntivi causerebbe corruzione dei dati o violazioni della licenza. Per questi carichi, la resilienza si ottiene tramite il ripristino automatico, non con lo scale-out.

Funzionano due pattern. Un allarme CloudWatch su StatusCheckFailed_System abbinato all’azione di ripristino di EC2 preserva l’ID dell’istanza, l’IP privato, l’Elastic IP e i volumi EBS collegati in caso di guasto dell’host sottostante. Ancora più semplice: un ASG con MinSize=MaxSize=1 che si estende su più AZ sostituisce un’istanza guasta e, a differenza dell’azione di ripristino, può sopravvivere a un guasto dell’AZ, a condizione che lo stato sia esternalizzato dal volume root o che l’AMI sia ricostruibile.

Load Balancer e Posizionamento nelle Subnet

L’ALB opera al livello 7 (L7), terminando le connessioni HTTP/HTTPS, offrendo routing basato su host/path/header, HTTP/2, WebSockets e integrazione con WAF/Cognito/OIDC. L’NLB opera al livello 4 (L4), preserva l’IP del client, supporta IP statici e TLS passthrough, PrivateLink e sostiene milioni di connessioni al secondo. Il Gateway Load Balancer inserisce appliance di terze parti (firewall, IDS) nel percorso del traffico.

Il posizionamento nelle subnet è il punto in cui le architetture si rompono più spesso. Un ALB esposto su Internet deve essere collegato a subnet pubbliche — ovvero subnet con una rotta 0.0.0.0/0 verso un Internet Gateway — una per ogni AZ in cui si trovano le destinazioni (target). Le destinazioni stesse rimangono in subnet private. Se l’ALB viene posizionato in subnet private, o se le subnet “pubbliche” non hanno una rotta predefinita verso un IGW, i client riscontreranno timeout di connessione. La raggiungibilità delle destinazioni richiede che il loro security group consenta il traffico in entrata dal security group dell’ALB sulla porta di destinazione; non è necessario alcun NAT tra l’ALB e le destinazioni nello stesso VPC.

Client → IGW → ALB (public subnets, SG: allow 443 from 0.0.0.0/0)
              → Targets (private subnets, SG: allow 8080 from ALB-SG)

Abilita i controlli di integrità dell’ELB sull’ASG in modo che le destinazioni non integre vengano sostituite, non semplicemente deregistrate. Il bilanciamento del carico tra zone (cross-zone load balancing), attivo di default su ALB e opzionale su NLB, distribuisce uniformemente le richieste indipendentemente dal numero di istanze per AZ. Route 53 deve risolvere il nome DNS dell’ALB tramite un record alias (o una policy di tipo weighted/latency su più ALB) — non puntare mai Route 53 agli IP delle singole istanze EC2, perché un’istanza guasta continuerebbe a ricevere traffico fino alla scadenza del TTL e l’istanza sostitutiva dell’ASG avrebbe un IP diverso.

Modelli di acquisto e flotte di istanze miste

La scelta del modello di acquisto è la leva principale per ridurre la spesa di EC2, indipendentemente dal pattern architetturale.

La strategia razionale: carico di base (baseline) su Reserved Instances o Savings Plan, picchi (burst) su On-Demand, lavoro tollerante ai guasti su Spot. In un ASG, questo si esprime come una policy per istanze miste:

MixedInstancesPolicy:
  LaunchTemplate:
    LaunchTemplateSpecification:
      LaunchTemplateId: lt-0abc123
      Version: $Latest
    Overrides:
      - InstanceType: m5.large
      - InstanceType: m5a.large
      - InstanceType: m6i.large
      - InstanceType: m6a.large
  InstancesDistribution:
    OnDemandBaseCapacity: 4          # covered by Savings Plan
    OnDemandPercentageAboveBaseCapacity: 20
    SpotAllocationStrategy: price-capacity-optimized

Diversificare i tipi di istanza aumenta la profondità del pool di Spot e riduce le interruzioni correlate. price-capacity-optimized (o capacity-optimized) bilancia il prezzo con la profondità del pool in modo che le istanze abbiano meno probabilità di essere reclamate.

Le istanze Spot sono appropriate per carichi di lavoro stateless, che supportano checkpoint, ritentabili o ridondanti orizzontalmente: worker web dietro un ALB, processi Batch con tentativi automatici, executor Spark, runner CI. Non è appropriato come unica capacità per servizi critici sempre attivi, database primari stateful o nodi leader senza un percorso di ripristino — un preavviso di due minuti non può garantire uno spegnimento sicuro, e la bonifica correlata a livello di flotta di un tipo di istanza specifico è una modalità di guasto reale. Quando il requisito dice “non deve essere interrotto”, l’uso di Spot è escluso.

La trappola inversa è applicare RI o Savings Plan a carichi di lavoro realmente variabili: si paga l’impegno orario indipendentemente dall’utilizzo, quindi un carico di lavoro in esecuzione per 40 ore a settimana con un impegno di 168 ore spreca il 76% della prenotazione. Quando la preoccupazione è la capacità stessa — non il prezzo — (picchi guidati da eventi, disaster recovery), si utilizza una On-Demand Capacity Reservation: una garanzia pura a livello di AZ alle tariffe On-Demand, combinabile con un Savings Plan per ottenere lo sconto.

Calcolo Serverless: Lambda e Fargate

Il serverless sposta la gestione della capacità sulla piattaforma. Lambda è adatto a lavori guidati da eventi e di breve durata: trigger ObjectCreated di S3, DynamoDB Streams, consumer SQS a basso volume, backend di API Gateway, logica di raccordo (glue logic). La memoria (128 MB – 10.240 MB) alloca la CPU in modo proporzionale, quindi aumentare la memoria spesso riduce i costi abbreviando la durata. I limiti rigidi ne definiscono l’ambito: 15 minuti di esecuzione massima, 10 GB di memoria, 10 GB in /tmp, 250 MB di pacchetto di deployment decompresso (o 10 GB tramite immagine container), 6 MB di payload sincrono. Usare Lambda per una transcodifica video di 30 minuti, un ETL di più ore o un training GPU è architettonicamente sbagliato — la funzione andrà in timeout a metà lavoro e la logica di ritentativo non farà che moltiplicare lo spreco. Per percorsi sensibili alla latenza, si mitigano i cold start e il tempo di inizializzazione delle ENI collegate a una VPC con la Provisioned Concurrency.

Fargate esegue container senza gestire gli host EC2. È la scelta giusta quando i task superano i 15 minuti, necessitano di runtime personalizzati o si adattano all’orchestrazione di ECS/EKS ma il team non vuole gestire la capacità. Fargate è più costoso per vCPU-ora rispetto a EC2 Spot, quindi quando l’utilizzo a stato stazionario è elevato e prevedibile, un ASG con istanze miste e Spot su ECS risulta più economico. Per traffico con picchi (bursty) o imprevedibile, la fatturazione al secondo di Fargate è vincente.

Per l’orchestrazione di molte funzioni Lambda, Step Functions è preferibile al concatenamento tramite SNS/SQS perché offre una cronologia visiva dell’esecuzione, semantica di ritentativo, gestione centralizzata degli errori e stato durevole. I flussi di lavoro Standard fatturano per transizione di stato e possono durare fino a un anno; i flussi di lavoro Express sono ottimizzati per l’elaborazione di eventi ad alto volume e di breve durata.

Per il fan-out di migliaia di processi containerizzati e parametrizzati — genomica, Monte Carlo, ETL — AWS Batch gestisce l’accodamento, la risoluzione delle dipendenze, i ritentativi e il provisioning su EC2 gestito, Spot o Fargate. I processi fanno riferimento a una definizione di processo (container + vCPU/memoria + ruolo IAM) e Batch li impacchetta (bin-packing) su istanze di dimensioni adeguate. Step Functions orchestra frequentemente Batch, Lambda ed ECS all’interno di un’unica macchina a stati.

Elastic Beanstalk

Beanstalk è un PaaS gestito che esegue il provisioning di ALB, ASG, istanze EC2 e, opzionalmente, RDS a partire da un pacchetto applicativo (application bundle). Supporta deployment di tipo rolling, rolling-with-additional-batch, immutable e blue/green con integrazione CloudWatch. Le policy di scaling sono esposte come opzioni dell’ambiente (metrica, soglie, min/max). Poiché Beanstalk utilizza di default tipi di istanza con capacità di picco (burstable), abilitare la modalità T-unlimited è la soluzione a basso sforzo per una breve saturazione della CPU. Le azioni di scaling pianificate si collegano all’ASG gestito da Beanstalk come qualsiasi altra. Scegliere Beanstalk quando il team desidera una topologia standard per applicazioni web senza dover creare manualmente CloudFormation e quando gli aggiornamenti continui (rolling updates) e i pacchetti versionati si adattano alla cadenza di rilascio.

Gestione della flotta con Systems Manager

I pattern basati su SSH e bastion host sono fragili e costosi da mettere in sicurezza. AWS Systems Manager li sostituisce. L’agente SSM (preinstallato su Amazon Linux 2, Ubuntu, Windows), insieme a un profilo di istanza che concede i permessi AmazonSSMManagedInstanceCore, è tutto ciò che serve.

• Run Command esegue comandi shell/PowerShell su flotte di istanze identificate tramite tag, con un output consolidato.
• Session Manager apre shell interattive tramite l’API di AWS: nessuna porta 22 in entrata, nessun bastion host, autenticazione IAM completa e sessioni registrate su S3 o CloudWatch Logs.
• Patch Manager applica patch del sistema operativo in modo pianificato, utilizzando le finestre di manutenzione.

aws ssm send-command \
  --targets Key=tag:Env,Values=prod \
  --document-name AWS-RunShellScript \
  --parameters 'commands=["yum -y update"]'

Automazione di avvio/arresto pianificato

Per le istanze EC2 e RDS non di produzione che devono rimanere spente al di fuori dell’orario lavorativo, il pattern a bassa manutenzione è EventBridge Scheduler → Lambda. Una regola cron (cron(0 19 ? * MON-FRI *)) invoca una funzione Lambda che arresta le risorse con tag specifici; una seconda regola alle 07:00 le avvia.

import boto3
ec2 = boto3.client('ec2'); rds = boto3.client('rds')

def handler(event, _):
    action = event['action']  # 'start' or 'stop'
    ids = [i['InstanceId'] for r in ec2.describe_instances(
        Filters=[{'Name':'tag:AutoStop','Values':['true']}]
    )['Reservations'] for i in r['Instances']]
    getattr(ec2, f'{action}_instances')(InstanceIds=ids)
    for db in rds.describe_db_instances()['DBInstances']:
        if any(t['Key']=='AutoStop' and t['Value']=='true' for t in db['TagList']):
            getattr(rds, f'{action}_db_instance')(DBInstanceIdentifier=db['DBInstanceIdentifier'])

Questa soluzione è serverless, non ha una flotta da manutenere con patch e scala in base ai tag. La soluzione AWS Instance Scheduler funziona in modo equivalente. Una sottigliezza: un’istanza RDS arrestata si riavvia automaticamente dopo sette giorni, quindi la pianificazione di arresto deve essere ricorrente per fermarla di nuovo. In combinazione con gli ASG le cui azioni pianificate azzerano la capacità durante i fine settimana, il costo nelle ore di inattività si avvicina a zero.

Insidie di networking relative al calcolo su larga scala

Posizionamento del NAT Gateway. Un NAT gateway risiede in una singola AZ. Una flotta che si estende su tre AZ e che instrada tutto il traffico in uscita (egress) attraverso un unico NAT in us-east-1a paga i costi di trasferimento inter-AZ per ogni pacchetto proveniente da us-east-1b/us-east-1c, e perde completamente la connettività in uscita quando us-east-1a subisce un degrado. Il pattern corretto prevede un NAT gateway per ogni AZ, con la tabella di routing di ogni sottorete privata che punta al NAT nella propria AZ. Questo localizza il traffico ed elimina il single point of failure legato alla singola AZ.

Istanze NAT. Una singola istanza NAT basata su EC2 diventa un collo di bottiglia per la larghezza di banda e i pacchetti al secondo (PPS) man mano che la flotta cresce, oltre a essere un SPOF (Single Point of Failure). I NAT Gateway gestiti scalano fino a 100 Gbps per gateway. Per il traffico diretto ai servizi AWS, i VPC endpoint (di tipo Gateway per S3/DynamoDB, di tipo Interface per gli altri) bypassano completamente il NAT, riducendo i costi ed eliminando il rischio di saturazione durante gli eventi di scaling.

Trappole di progettazione ricorrenti

• ASG in una singola AZ non possono sopravvivere a un’interruzione di una AZ: collegare sempre sottoreti di almeno due AZ (tre per i sistemi basati su quorum) e mantenere MinSize ≥ 2.
• Presumere che ogni carico di lavoro scali orizzontalmente. Le applicazioni che mantengono uno stato (stateful), con un singolo writer o con licenze non clusterizzabili peggiorano sotto un ASG. Utilizzare prima l’auto-recovery o effettuare un refactoring.
• Scaling reattivo per picchi prevedibili: produce il sintomo di “lentezza per le prime 2-3 ore”. Utilizzare lo scaling pianificato o predittivo per il pre-riscaldamento (pre-warm).
• Scalare sulla base della CPU quando non è la CPU il vincolo. Pubblicare una metrica che rifletta il vero collo di bottiglia: profondità della coda, tempo di risposta, numero di connessioni.
• Simple scaling e launch configuration sono legacy: preferire il target tracking e i launch template.
• Health check solo TCP su applicazioni HTTP: lasciano istanze non funzionanti in rotazione. Utilizzare health check HTTP (tramite ALB o i check in modalità HTTP di NLB).
• Utilizzare istanze Spot per carichi di lavoro stateful o che non devono essere interrotti: le istanze Spot richiedono worker sostituibili e in grado di eseguire checkpoint.
• Utilizzare Reserved Instance o Savings Plan su carichi di lavoro genuinamente variabili: l’impegno non utilizzato è puro spreco; ridurre invece i costi con il right-sizing e le istanze Spot.
• Puntare Route 53 a singoli IP di EC2: instradare il traffico verso l’alias dell’ALB in modo che il DNS rifletta i cambiamenti della flotta (churn).
• Trattare l’instance store come se fosse durevole: i dati svaniscono in caso di arresto, terminazione o guasto dell’host.
• Ignorare la latenza del lazy-loading dopo il ripristino da snapshot o l’avvio di un’AMI: abilitare Fast Snapshot Restore nelle AZ di destinazione.

Tutti i domini · Container e Orchestrazione →

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

Sfoglia Amazon →