Serverless: pagare solo per ciò che si usa

Il modello serverless è la risposta preferita dell’esame quando i requisiti citano carichi variabili, imprevedibili o a burst e l’obiettivo è minimizzare sia i costi sia l’overhead operativo. AWS Lambda esegue codice in risposta a eventi, scala automaticamente a zero quando non c’è traffico e fattura in base al numero di invocazioni e ai millisecondi di durata (con la memoria allocata come moltiplicatore): nessun server acceso significa nessun costo a riposo. È ideale per event processing, backend di API con Amazon API Gateway e task brevi e stateless.

Quando il carico è containerizzato o richiede esecuzioni più lunghe di quelle consentite da Lambda, AWS Fargate offre container senza gestire istanze Amazon EC2: paghi vCPU e memoria per la durata del task. La regola di scelta: EC2 quando serve controllo del sistema operativo o un utilizzo costante e prevedibile (dove Reserved Instances o Savings Plans battono il pay-per-use); serverless quando il carico è intermittente e vuoi eliminare la gestione della capacità.

Servizi gestiti e decoupling

Preferire servizi gestiti (Amazon RDS/Aurora, Amazon DynamoDB, Amazon SQS, Amazon SNS) riduce l’overhead operativo: patching, backup, alta disponibilità e scaling sono a carico di AWS. All’esame, “ridurre il carico amministrativo” è quasi sempre un indizio verso un managed service piuttosto che una soluzione self-managed su EC2.

Il decoupling permette di dimensionare i componenti in modo indipendente e di assorbire i picchi. Inserendo una coda Amazon SQS tra un produttore e un consumatore, quest’ultimo elabora al proprio ritmo e puoi scalare i worker (o la concurrency di Lambda) solo quando la coda cresce, evitando di sovradimensionare l’intero stack. Amazon SNS e Amazon EventBridge aggiungono pattern publish/subscribe ed event-driven. Il beneficio economico: ogni parte paga per la propria scala reale, non per il picco combinato.

Storage classes e riduzione dei costi

I dati raramente hanno tutti lo stesso profilo di accesso, e allineare la storage class all’accesso reale è una leva di risparmio classica. Su Amazon S3: Standard per dati frequenti; Standard-IA e One Zone-IA per accessi infrequenti (One Zone costa meno ma sacrifica la ridondanza multi-AZ); le classi Glacier per archiviazione a lungo termine con tempi di recupero crescenti e costi decrescenti. Se il pattern d’accesso è sconosciuto o variabile, S3 Intelligent-Tiering sposta automaticamente gli oggetti tra tier senza retrieval fee, evitando scelte errate. Le lifecycle policy automatizzano la transizione verso classi più economiche e l’eliminazione a scadenza.

Governance dei costi: Budgets e Cost Explorer

AWS Budgets serve a essere avvisati prima che la spesa sfugga: definisci una soglia (costo, utilizzo o copertura di Savings Plans/RI) e ricevi un alert quando la spesa reale o prevista la supera. È lo strumento proattivo, orientato al futuro. AWS Cost Explorer è invece analitico e retrospettivo: visualizza e filtra la spesa storica per servizio, tag o account, individua trend e anomalie e fornisce raccomandazioni di right-sizing. La combinazione tipica: Cost Explorer per capire dove va il denaro, Budgets per presidiare le soglie. Per l’impegno di capacità stabile, Savings Plans e Reserved Instances riducono il costo con impegni di 1 o 3 anni, mentre le Spot Instances tagliano fino a circa il 90% su carichi fault-tolerant e interrompibili.

Trappole tipiche d’esame

  • Carico intermittente/imprevedibile con minimo overhead → Lambda: scala a zero e fattura solo le invocazioni; una EC2 sempre accesa paga anche le ore di inattività.
  • Utilizzo costante e prevedibile 24/7 → Savings Plans/Reserved Instances: qui il serverless o le On-Demand costano di più; l’impegno pluriennale è la scelta economica.
  • “Avvisami quando supero X di spesa” → AWS Budgets, non Cost Explorer: Budgets genera alert su soglia; Cost Explorer analizza solo a posteriori.
  • Pattern di accesso sconosciuto o variabile → S3 Intelligent-Tiering: evita di scegliere a mano la classe e non applica retrieval fee, a differenza di IA/Glacier se i dati vengono letti spesso.
  • Assorbire picchi e scalare i componenti in modo indipendente → SQS (decoupling): una coda disaccoppia produttore e consumatore; ingrandire le istanze non risolve l’accoppiamento.
  • Batch fault-tolerant e interrompibile al minimo costo → Spot Instances: ideali per lavori che tollerano l’interruzione; da evitare per workload stateful sempre attivi.