{"id":8177,"date":"2025-12-03T08:00:00","date_gmt":"2025-12-03T07:00:00","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=8177"},"modified":"2025-12-02T18:47:57","modified_gmt":"2025-12-02T17:47:57","slug":"finops-su-aws-governare-i-costi-del-cloud-prima-che-siano-loro-a-governare-noi","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/finops-su-aws-governare-i-costi-del-cloud-prima-che-siano-loro-a-governare-noi\/","title":{"rendered":"FinOps su AWS: governare i costi del Cloud prima che siano loro a governare noi"},"content":{"rendered":"\n
Introduzione<\/h2>\n\n\n\n
Che cosa significa FinOps? O meglio, che cos\u2019\u00e8? <\/p>\n\n\n\n
In questi ultimi anni si \u00e8 sentito parlare sempre di pi\u00f9 di concetti come ottimizzazione dei costi e analisi della bolletta, ma quanti di voi sono mai andati oltre, pensando non solo all\u2019azione ma al significato che c\u2019\u00e8 dietro e al come applicare al meglio queste pratiche?<\/p>\n\n\n\n
Se siete una di quelle persone che ha sempre messo da parte questo argomento, beh questo articolo \u00e8 specificatamente per voi. Se, invece, conoscete gi\u00e0 l\u2019argomento… continuate a leggere comunque: ci sono alcune chicche dalla nostra esperienza da non perdere!<\/p>\n\n\n\n
Il Framework FinOps<\/h2>\n\n\n\n
Come tutti gli standard che si rispettino, anche il Framework FinOps \u00e8 stato ben documentato e definito; si tratta infatti di un approccio iterativo, suddiviso in 3 differenti momenti:<\/p>\n\n\n\n
<\/p>\n\n\n
\n<\/figure><\/div>\n\n\n
Inform<\/h4>\n\n\n\n
Dovendo prendere decisioni proiettate sul futuro, dobbiamo prima capire bene il presente e il passato. Infatti, in questa fase ci si concentrer\u00e0 sulla raccolta, l\u2019analisi e la standardizzazione di informazioni.<\/p>\n\n\n\n
Come disse un saggio: “I dati raccontano una storia, ma devi quantomeno saperli leggere\u2026”<\/p>\n\n\n\n
Un grande obiettivo che dobbiamo prefissarci, oltre alla raccolta di dati e alla loro standardizzazione, \u00e8 il come renderli confrontabili tra diversi gruppi di lavoro o progetti. I KPI, quindi, risultano tanto importanti quanto il saper leggere i dati.<\/p>\n\n\n\n
Immaginiamoci che la raccolta dati sia il decollo di un aereo e che l\u2019analisi sia il volo. Dovremmo riuscire comunque ad atterrare sani e salvi, altrimenti il valore di quello che abbiamo fatto si perderebbe! <\/p>\n\n\n\n
Optimize<\/h4>\n\n\n\n
A questo punto, abbiamo finalmente delle idee chiare su che cosa \u00e8 superfluo o su quali componenti dobbiamo abbattere i costi. Non ci resta che concretizzare.<\/p>\n\n\n\n
Il Cloud ci rende questo processo pi\u00f9 semplice: alcune opzioni, come le \u2018Reserved Instances\u2019, \u2018Saving Plans\u2019 o \u2018Committed Use Discounts\u2019 contribuiscono a tagliare i costi in bolletta, ma riguardano la bonifica di una situazione gi\u00e0 in atto; il vero processo di FinOps deve partire sin da subito, dalla nascita di un progetto.<\/p>\n\n\n\n
Una delle difficolt\u00e0 maggiori di questa fase \u00e8 il doversi interfacciare con diverse Persone o Team all\u2019interno della stessa azienda o, addirittura, di differenti aziende. Questo potrebbe comportare dei momenti di tensione e di competizione, ma ricordiamoci sempre che alla fine stiamo remando tutti verso la stessa direzione.<\/p>\n\n\n\n
Operate<\/h4>\n\n\n\n
In questo punto del percorso abbiamo preso delle decisioni informate basate sui dati e ridotto la bolletta. Abbiamo quindi risolto il problema, no? <\/p>\n\n\n\n
Beh, non proprio.<\/p>\n\n\n\n
Confrontiamo due grafici:<\/p>\n\n\n\n
<\/p>\n\n\n
\n<\/figure><\/div>\n\n\n
<\/p>\n\n\n\n
Nel primo esempio (serie in blu), non siamo partiti con un approccio FinOps sin dall\u2019inizio, incombendo in costi evitabili, per poi raggiungere un picco insostenibile per il progetto e dover rifattorizzare il tutto. <\/p>\n\n\n\n
Il refactoring ha senz’altro abbassato drasticamente i costi, ma la bolla iniziale di costo ha comunque aumentato di molto la spesa, portando il totale a 3300$.<\/p>\n\n\n\n
Prendiamo invece il secondo caso (serie rossa), in cui sin da subito si ha avuto un’ottica improntata alle Best Practices FinOps, mantenendo un costo ottimizzato sin da subito. Non dovendo poi effettuare dei grossi cambiamenti durante il ciclo di vita del progetto, il costo totale \u00e8 risultato di 1625$.<\/p>\n\n\n\n
In questi casi risulta essere molto utile partire con un TCO (Total Cost of Ownership), il quale ci permette di stimare sin da subito quanto coster\u00e0 la nostra implementazione, andando eventualmente a efficientare le aree che ce lo permettono, abbattendo i costi di sviluppo e di mantenimento del progetto.<\/p>\n\n\n\n
Risulta dunque fondamentale avere e coltivare una cultura attorno alle pratiche FinOps, cos\u00ec da garantire sempre dei progetti sostenibili e efficienti dal punto di vista economico.<\/p>\n\n\n\n
Come possiamo applicarlo su AWS?<\/h2>\n\n\n\n
Abbiamo parlato della teoria. Ora cerchiamo di capire come poterla mettere in pratica.<\/p>\n\n\n\n
Partiamo dai servizi che ci possono aiutare a comprendere la situazione dei nostri account, ad esempio, Cost Optimization Hub che offre una visione sui costi generale, ma completa:<\/p>\n\n\n\n
<\/p>\n\n\n
\n<\/figure><\/div>\n\n\n
<\/p>\n\n\n\n
Qui, possiamo osservare quali sono le opzioni disponibili per iniziare ad effettuare delle ottimizzazioni. <\/p>\n\n\n\n
Cost Optimization Hub non svolge operazioni complesse, ma controlla semplicemente quali risorse non sono usate, come EBS non in uso, e se possiamo sfruttare Saving Plan o Reserved Instance: semplice ma efficace.<\/p>\n\n\n\n
Il servizio sfrutta un insieme di altri dati, come ad esempio Compute Optimizer.<\/p>\n\n\n\n
Stiamo per\u00f2 toccando solamente la punta dell\u2019iceberg. <\/p>\n\n\n\n
Ad esempio, potremmo sottoscrivere dei Saving Plan ottimizzando cos\u00ec il costo, ma non dovremmo fermarci una volta effettuata questa prima bonifica.<\/p>\n\n\n\n
Al posto di utilizzare passivamente i servizi AWS, dunque, dovremmo invece cercare di porci delle domande mirate e ragionate per esempio: <\/p>\n\n\n\n
\n
Possiamo modernizzare questa applicazione?<\/li>\n\n\n\n
Ci sono soluzioni gestite che ci permettono di abbassare i costi?<\/li>\n\n\n\n
Possiamo effettuare del decoupling del monolite e gestirne i picchi dinamicamente con delle politiche di scaling?<\/li>\n<\/ul>\n\n\n\n
Cos\u00ec facendo, ci assicureremo di non accettare senza consapevolezza l\u2019infrastruttura attuale, ma di comprendere e definire il perch\u00e9 di queste decisioni e azioni.<\/p>\n\n\n\n
Facciamo un esempio concreto: se avessi un centesimo per ogni volta che ho migrato un web server monolitico utilizzato per fare hosting di un sito statico da on-premise verso AWS, ne avrei due. Il che non \u00e8 molto, ma \u00e8 strano che sia successo due volte.<\/p>\n\n\n\n
Se al posto di migrare direttamente il sito statico avessimo affrontato il contesto e modernizzato la soluzione sfruttando Cloudfront e S3, avremmo potuto fornire un servizio migliore, ad una frazione del costo di una EC2 dedicata.<\/p>\n\n\n\n
Ovviamente non sempre \u00e8 possibile effettuare queste operazioni per limiti tecnici o per situazioni non documentate; in questo caso si pu\u00f2 per\u00f2 ragionare sul costo del mantenimento rispetto al costo di ammodernamento! <\/p>\n\n\n\n
Questa strategia non solo si pu\u00f2, ma si deve applicare in continuazione, proprio per come il cloud provider AWS ha concepito il modello di Pricing<\/em>.<\/p>\n\n\n\n
Facciamo un esempio reale, senza entrare troppo nel dettaglio dell casistica, ma concentrandoci sulla struttura del costo:<\/p>\n\n\n\n
Nel grafico qui sotto abbiamo due casistiche:<\/p>\n\n\n\n
\n
Un API Gateway che espone delle API ed inoltra le richieste a delle Lambda, il cui tempo medio di risposta \u00e8 3 secondi per ogni chiamata<\/li>\n\n\n\n
Un autoscaling group composto da due istanze EC2 che espongono API tramite un ALB. Abbiamo ipotizzato la creazione di due istanze per ogni 5 Milioni di richieste<\/li>\n<\/ul>\n\n\n\n
<\/p>\n\n\n
\n<\/figure><\/div>\n\n\n
<\/p>\n\n\n\n
In questo caso possiamo vedere come alcuni servizi gestiti possano avere le stesse funzionalit\u00e0, o in alcuni casi anche di pi\u00f9, ad un costo minore, essendo ottimizzati proprio per quel caso d\u2019uso.<\/p>\n\n\n\n
In questo specifico caso, dovremmo per\u00f2 contare anche un delta di costo per il refactor dell\u2019applicativo per renderlo utilizzabile da API GW e Lambda. Bisogner\u00e0 quindi valutare caso per caso qual \u00e8 la soluzione migliore e pi\u00f9 efficiente, sia economicamente che tecnologicamente.<\/p>\n\n\n\n
In alcuni casi, seppure possa sembrare controindicato, si potrebbero presentare delle infrastrutture serverless che costano pi\u00f9 di alcune serverfull. Non in questo caso, ma pensate se la Lambda al posto di essere eseguita in 3 secondi ne impiegasse 10; sarebbe pi\u00f9 che triplicato il costo, spostando di molto in alto la \u2018Linea Blu\u2019 del grafico.<\/p>\n\n\n\n
Questo articolo \u00e8 un\u2019introduzione allo standard FinOps, ma anche al nostro approccio a riguardo. \u00c8 anche il nostro punto di vista su ci\u00f2 che riteniamo possa dare valore al cliente e su quali siano le domande-chiave che ci possono spingere verso un migliore approccio al cloud.<\/p>\n\n\n\n
Ma non \u00e8 tutto qui! Presto torneremo con una seconda parte dove ci concentreremo sulle domande che siamo posti in questi paragrafi in relazione all’applicazione dell’approccio FinOps e di come tutto ci\u00f2 abbia permesso di ottimizzare, e in certi casi anche di modernizzare, alcuni Workload<\/em> di clienti.<\/p>\n\n\n\n
Speriamo che, da ora in poi, il vostro punto di vista su cosa sia realmente FinOps possa essere arricchito. Fatecelo sapere! <\/p>\n\n\n\n
![\"Fasi](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2025\/12\/image5-298x300.png\")
<\/figure><\/div>\n\n\n![\"\"](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2025\/12\/image4-1.png\")
<\/figure><\/div>\n\n\n![\"\"](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2025\/12\/image1.png\")
<\/figure><\/div>\n\n\n![\"\"](\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2025\/12\/image2-1-1024x632.png\")
<\/figure><\/div>\n\n\n