Il modello di compute e come sceglierlo

Il compute è la capacità di elaborazione su cui girano le applicazioni e i workload. AWS offre più modelli lungo uno spettro che va dal massimo controllo alla massima gestione delegata al provider. All’estremo del controllo c’è Amazon EC2 (virtual machine complete); all’estremo opposto c’è AWS Lambda (serverless), dove non gestisci alcun server; in mezzo stanno i container, con Amazon ECS ed Amazon EKS. Il criterio d’esame è quasi sempre lo stesso: più controllo e responsabilità operativa servono, più ti sposti verso EC2; meno vuoi gestire infrastruttura, più ti sposti verso il serverless. Ricorda lo Shared Responsibility Model: con EC2 sei responsabile del patching del sistema operativo, mentre con Lambda e Fargate quella responsabilità passa ad AWS.

Amazon EC2 e l’auto scaling

Amazon EC2 fornisce virtual machine (chiamate “istanze”) con controllo completo su sistema operativo, rete e software installato: è il modello IaaS classico, ideale per applicazioni legacy, per il lift-and-shift e quando serve accesso a livello di OS. Le istanze sono organizzate in famiglie ottimizzate per caso d’uso (general purpose, compute optimized, memory optimized, storage optimized, accelerated computing). Sul piano dei costi conta conoscere le opzioni di pricing: On-Demand (flessibile, nessun impegno), Reserved Instances e Savings Plans (sconto in cambio di un impegno di 1 o 3 anni, per carichi stabili), Spot Instances (forti sconti su capacità inutilizzata, ma interrompibili, per workload fault-tolerant) e Dedicated Hosts (hardware fisico dedicato, spesso per licenze o compliance).

A EC2 si affianca EC2 Auto Scaling, che aggiunge o rimuove istanze automaticamente in base alla domanda tramite un Auto Scaling group. È il servizio che realizza l’elasticità: paghi solo la capacità che serve e migliori la fault tolerance sostituendo le istanze non sane. In genere lavora insieme a un Elastic Load Balancer, che distribuisce il traffico fra le istanze attive.

AWS Lambda e il paradigma serverless

AWS Lambda è il servizio serverless per eccellenza: esegue il tuo codice in risposta a eventi (una richiesta via API Gateway, un upload su Amazon S3, un messaggio in coda) senza che tu debba provisionare o gestire server. Paghi solo per il numero di invocazioni e per il tempo di calcolo consumato: se non c’è traffico, non paghi nulla. Lo scaling è automatico e gestito da AWS. Lambda è adatto a workload event-driven, a job brevi e a microservizi; non è pensato per processi a lunga esecuzione né per applicazioni che richiedono controllo sull’OS. “Serverless” non significa “senza server”, ma che la gestione dei server è invisibile e a carico di AWS.

Container: Amazon ECS, Amazon EKS e AWS Fargate

I container impacchettano applicazione e dipendenze in un’unità portabile e leggera. AWS offre due orchestratori: Amazon ECS (Elastic Container Service), soluzione nativa AWS, e Amazon EKS (Elastic Kubernetes Service), Kubernetes gestito, utile quando serve compatibilità con l’ecosistema Kubernetes. La distinzione chiave d’esame riguarda il modello di esecuzione: con il launch type su EC2 gestisci tu le istanze che ospitano i container; con AWS Fargate il compute è serverless e non gestisci né provisioni alcuna istanza. Fargate funziona sia con ECS sia con EKS ed è la scelta quando vuoi container senza gestire i server sottostanti.

Trappole tipiche d’esame

  • Serve controllo totale sul sistema operativo o un lift-and-shift → soluzione: Amazon EC2, non Lambda né Fargate; solo con EC2 hai accesso a livello di OS.
  • Codice event-driven, breve, senza gestione server → soluzione: AWS Lambda; se la domanda enfatizza “no server management” e “pay per use”, è serverless.
  • Container senza gestire le istanze sottostanti → soluzione: AWS Fargate; se invece la domanda richiede controllo sulle istanze host, è il launch type EC2.
  • Serve Kubernetes o compatibilità con l’ecosistema K8s → soluzione: Amazon EKS, non ECS (ECS è l’orchestratore proprietario AWS).
  • Adeguare la capacità automaticamente alla domanda → soluzione: EC2 Auto Scaling per l’elasticità; l’Elastic Load Balancer distribuisce il traffico, non scala il numero di istanze.
  • Workload interrompibile e fault-tolerant al minor costo → soluzione: Spot Instances; per carichi stabili e prevedibili convengono invece Reserved Instances o Savings Plans.