Scegliere il tipo di istanza EC2

Le istanze Amazon EC2 sono organizzate in famiglie ottimizzate per un profilo di carico: general purpose (M, T) per workload bilanciati, compute optimized (C) per lavoro CPU intensive, memory optimized (R, X) per database in-memory e cache, storage optimized (I, D) per IOPS elevati, accelerated computing (P, G) per GPU e ML. In ottica di design, la scelta parte dal collo di bottiglia del carico (CPU, RAM, rete, disco), non dal prezzo di listino. Le istanze della famiglia T sono burstable: accumulano CPU credit e vanno bene per traffico intermittente, ma sotto carico costante subiscono throttling.

Il modello di acquisto è un secondo asse: On-Demand per carichi imprevedibili o brevi; Savings Plans e Reserved Instances per il baseline prevedibile (sconto in cambio di impegno 1 o 3 anni); Spot per lavori fault-tolerant e interrompibili (batch, HPC, rendering) con forti sconti ma revoca con breve preavviso. Per la performance di rete alcune istanze supportano enhanced networking, utile insieme ai placement group per ridurre la latency.

Elasticità: Auto Scaling ed Elastic Load Balancing

Un Auto Scaling group (ASG) mantiene un numero desiderato di istanze distribuite su più Availability Zone e rimpiazza quelle unhealthy. Le policy principali sono: target tracking (mantiene una metrica, es. CPU media al 50%, la scelta più semplice e consigliata), step/simple scaling (soglie su allarmi Amazon CloudWatch) e scheduled scaling (variazioni prevedibili, es. picco ricorrente alle 9:00). Il pattern canonico per l’availability è un ASG multi-AZ dietro un load balancer.

Elastic Load Balancing distribuisce il traffico. Application Load Balancer (ALB) opera a livello 7 (HTTP/HTTPS): routing per path e host header, WebSocket, integrazione con AWS WAF e target group verso EC2, container e Lambda. Network Load Balancer (NLB) opera a livello 4 (TCP/UDP/TLS): latenza bassissima, milioni di richieste al secondo, IP statico per AZ e supporto di protocolli non-HTTP. Scegli ALB per traffico web con routing applicativo, NLB per throughput estremo, IP fisso o protocolli non HTTP.

Distribuzione globale: CloudFront e Global Accelerator

Amazon CloudFront è una CDN: mette in cache contenuti cacheable (immagini, video, static asset, ma anche risposte API) nelle edge location vicino all’utente, riducendo latency e carico sull’origin. Integra AWS Shield, AWS WAF e certificati TLS; l’origin può essere Amazon S3, un ELB o un server on-premises.

AWS Global Accelerator non è una cache: fornisce due IP anycast statici e instrada il traffico TCP/UDP sulla rete backbone AWS fino all’endpoint sano più vicino, con failover rapido tra Region. È la scelta per traffico dinamico o non-HTTP (gaming, IoT, VoIP) che richiede IP fissi e bassa latency globale. Regola pratica: contenuto cacheable → CloudFront; traffico dinamico/non-cacheable con failover multi-region → Global Accelerator.

Caching applicativo e placement group

Amazon ElastiCache offre caching in-memory gestito con due engine: Redis (o Valkey) per strutture dati ricche, persistenza, replica, pub/sub e Multi-AZ con failover automatico; Memcached per cache semplice, multi-thread e scalabile orizzontalmente ma volatile. Il pattern cache-aside davanti a un database (es. Amazon RDS) abbatte la latency di lettura e alleggerisce il DB; ElastiCache serve anche come session store condiviso tra istanze.

I cluster placement group collocano le istanze vicine nella stessa AZ per latency minima e throughput di rete elevato: ideali per HPC e workload strettamente accoppiati. Lo spread placement group distribuisce le istanze su hardware distinto (massima resilienza per poche repliche critiche), mentre il partition placement group serve carichi distribuiti su larga scala (Hadoop, Cassandra, Kafka).

Trappole tipiche d’esame

  • Contenuto statico cacheable a utenti globali → CloudFront: non Global Accelerator, che non fa caching. È il distrattore più frequente.
  • Traffico UDP o gaming con IP statici e failover multi-region → Global Accelerator: CloudFront è HTTP-centrico e un NLB singolo non attraversa più Region.
  • IP statico o protocollo non-HTTP a livello di load balancer → NLB: l’ALB fa routing L7 ma non offre IP fisso né TCP/UDP puro.
  • Picco di traffico prevedibile e ricorrente → scheduled scaling: il target tracking è reattivo e può arrivare tardi su picchi noti a orario fisso.
  • HPC con bassa latency tra istanze → cluster placement group: lo spread group massimizza la resilienza, non la vicinanza; sono obiettivi opposti.
  • Session store condiviso con failover → ElastiCache for Redis: Memcached non offre replica né persistenza. Il passing score dell’esame è 700/1000.