Scegliere il modello compute

Il primo asse decisionale è l’overhead operativo contro il controllo. Amazon EC2 con Auto Scaling offre controllo totale su OS, kernel e istanze specializzate (GPU, ARM Graviton, licenze BYOL), ma paghi in gestione di patching, AMI e capacity planning. È la scelta obbligata per workload con esigenze di licensing legacy, dipendenze a livello di kernel o processi long-running con footprint elevato. AWS Lambda sta all’estremo opposto: nessun server da gestire, scaling automatico per singola richiesta, billing al millisecondo, ideale per carichi event-driven, spiky o intermittenti. I limiti da ricordare a livello architetturale sono il timeout massimo (15 minuti), memoria e CPU accoppiate, e i cold start, che spingono verso Provisioned Concurrency quando serve latenza prevedibile. Fra i due estremi stanno i container, che disaccoppiano l’applicazione dall’host preservando la portabilità del serverless mindset senza rinunciare al packaging tradizionale.

Container: ECS, EKS e Fargate

Amazon ECS è l’orchestratore proprietario, semplice e profondamente integrato con l’ecosistema AWS (IAM task role, ALB, CloudWatch); ottimo quando non serve Kubernetes. Amazon EKS è Kubernetes gestito: sceglilo quando esistono già competenze e manifest Kubernetes, requisiti di portabilità multi-cloud o l’ecosistema CNCF (Helm, operatori, service mesh). L’asse ortogonale è il modello di capacità: AWS Fargate è il compute serverless per container (sia ECS sia EKS), elimina la gestione delle worker node e fattura per vCPU e memoria richiesta dal task. Usa il launch type EC2 quando servono GPU, DaemonSet privilegiati, bin-packing spinto o istanze Spot gestite per abbattere i costi; usa Fargate per minimizzare l’overhead operativo e ottenere isolamento per-task. In contesti enterprise, EKS con Fargate riduce la superficie di gestione ma offre meno controllo fine su networking e costi rispetto ai node group EC2.

Disaccoppiare e reagire agli eventi

Il decoupling è centrale per resilienza e scalabilità. Amazon SQS fornisce code per il disaccoppiamento asincrono producer/consumer, assorbe i picchi (load leveling) e protegge i downstream. Ricorda la distinzione: Standard offre throughput quasi illimitato con semantica at-least-once e ordinamento best-effort; FIFO garantisce ordine ed exactly-once ma con throughput limitato. Le Dead-Letter Queue isolano i messaggi non processabili. Amazon SNS implementa il pub/sub e il pattern fan-out: un messaggio pubblicato su un topic viene consegnato in parallelo a più subscriber, tipicamente più code SQS, così ogni sistema elabora in modo indipendente. Amazon EventBridge è il bus eventi con routing basato su rule di content filtering, schema registry e integrazione con SaaS partner e servizi AWS; scegli EventBridge quando serve routing sofisticato per contenuto o integrazione con eventi di terze parti, SNS quando serve fan-out ad alto throughput verso molti endpoint. EventBridge Pipes collega source e target con filtering ed enrichment senza codice glue.

Orchestrazione con Step Functions

Quando un flusso richiede stato, sequenze, branching, retry e compensazione, AWS Step Functions orchestra i passi come state machine, evitando il “Lambda pinball” (Lambda che invocano altre Lambda in catena fragile). Distingui Standard workflow (fino a un anno, exactly-once, adatto a processi long-running e auditabili) da Express workflow (alto volume, breve durata, at-least-once, per event processing ad alta frequenza). Step Functions gestisce nativamente retry con backoff e integra centinaia di servizi AWS, riducendo drasticamente il codice di orchestrazione.

Trappole tipiche d’esame

  • Processo batch oltre 15 minuti presentato come “serverless” → soluzione: non Lambda (timeout), ma un task Fargate o Step Functions che coordina container; l’esame propone Lambda come esca.
  • Fan-out a più consumatori indipendenti → soluzione: SNS topic con più code SQS sottoscritte (pattern SNS→SQS), non una singola coda condivisa fra tutti i consumer.
  • Ordinamento stretto ed elaborazione una-sola-volta → soluzione: SQS FIFO (o SNS FIFO→SQS FIFO), mai Standard; ricorda il trade-off sul throughput.
  • Routing per contenuto dell’evento o integrazione SaaS/terze parti → soluzione: EventBridge con rule di pattern matching, non SNS che filtra solo per message attribute.
  • Kubernetes richiesto o portabilità multi-cloud → soluzione: EKS; se lo scenario dice solo “container su AWS senza vincoli”, ECS ha meno overhead operativo.
  • Orchestrazione con stato, retry e compensazione → soluzione: Step Functions (Standard per durata e audit, Express per alto volume), non catene di Lambda accoppiate.