In sintesi
A listino, i prezzi di AWS EC2 sembrano lineari. Nella pratica, i costi accessori come data transfer, storage EBS e indirizzi IPv4 pubblici possono aggiungere il 40-50% alle ore di compute. Questa guida analizza con numeri concreti i prezzi on-demand, reserved, spot e Savings Plan, quantifica le voci nascoste che i team FinOps tendono a sottostimare in fase di budget e illustra le strategie di ottimizzazione che trasformano una spesa EC2 imprevedibile in un dato gestibile e difendibile.
Quasi tutti i team FinOps conoscono la tariffa on-demand di EC2. Sono molti meno quelli in grado di dire quanto costi davvero EC2 una volta inclusi data transfer, storage, load balancer e l'addebito per gli IPv4 pubblici introdotto nel 2024. È proprio in questo divario tra listino e fattura reale che nascono le sorprese di budget capaci di mettere sotto esame i programmi FinOps.
I prezzi di EC2 non sono complicati per mancanza di trasparenza: AWS pubblica ogni cifra. Lo diventano perché le tariffe si articolano su decine di dimensioni e la maggior parte dei modelli di costo sottostima gli addebiti accessori che si sommano attorno a ogni istanza. Questa guida offre ai professionisti FinOps il contesto sui prezzi, i calcoli sui costi nascosti e i framework di ottimizzazione necessari per costruire budget EC2 accurati e saperli difendere.
Cos'è AWS EC2?
Amazon Elastic Compute Cloud (AWS EC2) mette a disposizione server virtuali ridimensionabili, chiamati istanze, nel cloud AWS. I team possono allocare capacità di compute on demand senza acquistare né gestire hardware fisico.
Per chi lavora in ambito FinOps, la prospettiva più rilevante è un'altra: EC2 rappresenta in genere la voce più consistente della fattura AWS. Gartner stima una spesa mondiale per il public cloud di 723 miliardi di dollari nel 2025 (Gartner), e il compute traina questa crescita. AWS fattura EC2 al secondo (con un minimo di un minuto) per le istanze Linux e all'ora per Windows. Le tariffe variano in base a famiglia di istanze, dimensione, regione, sistema operativo e tenancy.
Un'istanza general-purpose m7i.large in US East (N. Virginia) costa 0,1008 $/ora on demand. Una c7i.large compute-optimized nella stessa regione costa 0,08925 $/ora. Piccole differenze orarie diventano significative su larga scala: 100 istanze m7i.large in esecuzione continua costano circa 73.584 $/anno on demand, prima di qualsiasi addebito accessorio.
Prezzi aggiornati a maggio 2026. Per le tariffe in tempo reale, consulti la pagina dei prezzi AWS EC2 On-Demand.
In che modo i tipi di istanza EC2 incidono sulle decisioni di prezzo?
Ogni famiglia di istanze EC2 ottimizza un diverso rapporto tra le risorse, e questo rapporto influenza direttamente il trade-off costo-prestazioni che i team FinOps devono valutare.
Le istanze general-purpose (famiglia m) bilanciano CPU, memoria e networking. Coprono la gamma più ampia di workloads e sono il punto di partenza per la maggior parte delle applicazioni. Le istanze compute-optimized (famiglia c) offrono più vCPU per dollaro di memoria e risultano dal 10 al 15% più economiche per vCPU-ora sui workloads CPU-intensive come batch processing e codifica multimediale. Le istanze memory-optimized (famiglie r e x) ribaltano il rapporto, allocando più RAM per vCPU per database in-memory e analytics.
L'impatto sui prezzi dipende dall'aderenza al carico. Far girare un workload CPU-bound su un'istanza memory-optimized significa pagare RAM che resta inutilizzata. Far girare un database memory-intensive su un'istanza compute-optimized significa sovradimensionare le vCPU per ottenere abbastanza RAM, gonfiando sia il conteggio sia il costo. Il gruppo di lavoro EC2 autoscaling della FinOps Foundation raccomanda di puntare a un utilizzo medio di CPU del 40-70% e di segnalare per il downsizing tutto ciò che resta costantemente sotto il 20-30% (FinOps Foundation).
Anche le generazioni più recenti hanno un peso sui prezzi. Nel 2025 AWS ha lanciato le famiglie m8i e c8i di ottava generazione, con un rapporto prezzo-prestazioni fino al 15% migliore rispetto alla settima. Prima di rinnovare i commitments, i team FinOps dovrebbero confrontare le istanze di nuova generazione con le reservation in essere.
Come calcola e fattura AWS i prezzi di EC2?
La fatturazione EC2 parte dalla tariffa per ora-istanza, ma non si esaurisce lì. Questa sezione analizza i tre modelli di prezzo, i costi accessori che gonfiano il dato reale e le metriche di right-sizing che lo riportano sotto controllo.
Quale modello di prezzo EC2 si adatta al suo workload?
AWS offre tre modelli di prezzo principali per EC2, ciascuno con un proprio trade-off tra flessibilità e profondità di sconto.
On-demand: si paga la tariffa oraria a listino, senza alcun impegno. Offre piena flessibilità ma è l'opzione più costosa. È adatta a workloads imprevedibili, progetti di breve durata e qualsiasi capacità non ancora abbastanza stabile da essere prevista.
Reserved Instances (RI) e Savings Plans: si scambia impegno in cambio di sconti. Una RI Standard a 1 anno offre in media circa il 40% di sconto rispetto all'on-demand; una RI Standard a 3 anni arriva mediamente al 60%. I Compute Savings Plans offrono sconti analoghi (fino al 66%) con maggiore flessibilità, applicandosi automaticamente a famiglie di istanze, regioni e perfino a Fargate e Lambda. La FinOps Foundation calcola il break-even di una RI a 1 anno a circa 7-8 mesi di utilizzo pieno con uno sconto del 40% (FinOps Foundation).
Il rovescio della medaglia: i commitments non si possono annullare a metà periodo. I pattern dei workloads cambiano e le reservation inutilizzate diventano costi affondati. Per questo i tipici errori sui commitments AWS sono tra i problemi più costosi del FinOps.
Le Spot Instances attingono alla capacità EC2 inutilizzata con sconti del 60-90% rispetto all'on-demand. AWS fissa i prezzi Spot in base a domanda e offerta di lungo periodo (non con aste) e dà un preavviso di interruzione di 2 minuti quando la capacità viene recuperata. Per workloads fault-tolerant come batch processing, pipeline CI/CD e microservizi stateless, Spot offre lo sconto più aggressivo disponibile.
Prezzi aggiornati a maggio 2026. Per le tariffe in tempo reale, consulti la pagina dei prezzi AWS Reserved Instance e la pagina dei prezzi Spot.
| Modello | Sconto vs. On-Demand | Impegno | Flessibilità | Garanzia di capacità |
|---|---|---|---|---|
| On-Demand | Nessuno | Nessuno | Piena | Sì |
| RI Standard 1 anno | ~40% | 1 anno | Bassa (vincolata a famiglia/regione) | Solo a livello di AZ |
| RI Standard 3 anni | ~60% | 3 anni | Bassa | Solo a livello di AZ |
| Compute Savings Plan | Fino al 66% | 1 o 3 anni | Alta (cross-family, cross-region) | No |
| Spot | 60-90% | Nessuno | Piena (capacità revocabile) | No |
La tabella riflette le fasce di sconto pubblicate da AWS a maggio 2026. Gli sconti effettivi variano in base a tipo di istanza, regione e opzione di pagamento.
Quali costi nascosti si aggiungono oltre al prezzo dell'istanza?
La tariffa dell'istanza raramente racconta tutta la storia. Storage EBS, data transfer, load balancer e addebiti per IPv4 pubblici possono aggiungere il 40-50% alle ore di compute in un tipico workload esposto a internet.
Lo storage EBS (il block storage di default per EC2) parte da 0,08 $/GB-mese per i volumi gp3. Un modesto volume di root da 100 GB per istanza aggiunge 8 $/mese a istanza, ovvero 960 $/anno su una flotta di 10 istanze. Gli snapshot costano altri 0,05 $/GB-mese.
Il data transfer coglie i team FinOps di sorpresa più di qualsiasi altra voce. L'egress internet da US East costa 0,09 $/GB dopo i primi 100 GB/mese gratuiti. Un workload con 5 TB/mese di egress paga circa 450 $/mese di soli trasferimenti. Il traffico inter-AZ costa 0,01 $/GB per direzione (0,02 $/GB andata e ritorno): una sorpresa frequente nei deployment Kubernetes multi-AZ in cui il traffico di service mesh attraversa di continuo le availability zone.
Gli indirizzi IPv4 pubblici costano oggi 0,005 $/ora (~3,60 $/mese ciascuno) dopo la variazione di prezzo di febbraio 2024. L'addebito si applica a ogni IPv4 pubblico in uso su istanze EC2, load balancer, NAT gateway ed endpoint RDS.
I NAT Gateway peggiorano il problema del data transfer: 0,045 $/ora per AZ (~32,40 $/mese) più 0,045 $/GB elaborato, oltre alle tariffe standard di egress per il traffico verso internet.
Consideri uno scenario realistico: 10 istanze m7i.large con 100 GB di storage gp3 ciascuna, un ALB, 12 indirizzi IPv4 pubblici, 5 TB di egress mensili e 500 GB di traffico inter-AZ. Quell'ambiente costa circa 1.380 $/mese. Le ore di istanza ne pesano per 736. I costi accessori rappresentano il 47% della fattura.
Prezzi aggiornati a maggio 2026. Per le tariffe in tempo reale, consulti la pagina dei prezzi AWS EBS e la pagina dei prezzi del Data Transfer EC2.
Come fare right-sizing delle istanze in base all'utilizzo?
Right-sizing significa allineare la capacità delle istanze alla domanda effettiva del workload. Resta la via più rapida per ridurre la spesa EC2 senza ricorrere a commitments o modifiche architetturali.
Il whitepaper di AWS sul right-sizing fissa una soglia chiara: ogni istanza con utilizzo massimo di CPU e memoria inferiore al 40% su un periodo di quattro settimane è candidata al downsizing (AWS). Dimezzare un'istanza sovradimensionata fa risparmiare circa il 50% sull'istanza stessa, senza impatto sulle prestazioni, a patto che l'utilizzo resti entro la nuova capacità.
AWS Compute Optimizer automatizza l'analisi con il machine learning, puntando a una CPU P99.5 all'80% di utilizzo sostenuto. Il motore di rightsizing di Cost Explorer segnala come inattive le istanze con utilizzo massimo di CPU pari o inferiore all'1% e ne raccomanda la terminazione.
Anche le configurazioni di sicurezza incidono sui costi. Crittografare i volumi EBS con AWS KMS aggiunge un piccolo addebito per richiesta, e le istanze in dedicated tenancy (talvolta richieste per la compliance) costano molto più di quelle in tenancy condivisa. Conviene includere questi impatti di prezzo legati alla compliance nei calcoli di right-sizing, anziché trattare la spesa di sicurezza come overhead fisso.
Per le strategie di ottimizzazione continua, il right-sizing dovrebbe essere un'attività permanente, non trimestrale. I pattern dei workloads cambiano con l'evoluzione delle applicazioni e un'istanza ben dimensionata oggi può ritrovarsi sovradimensionata nel giro di poche settimane.
Su quali strategie di ottimizzazione dei costi EC2 dovrebbero puntare i team FinOps?
McKinsey ha rilevato che pratiche FinOps efficaci riducono i costi cloud del 20-30%, sulla base dell'analisi di 3 miliardi di dollari di fatture cloud reali (McKinsey). Questo risparmio non arriva da una singola leva, ma da un approccio di portafoglio che combina sconti basati su commitments, adozione di Spot e right-sizing continuo.
Come valutare le strategie di acquisto delle reserved instance?
La FinOps Foundation raccomanda di valutare gli acquisti di commitments rispetto all'Effective Savings Rate (ESR), non rispetto alla percentuale di sconto nominale. L'ESR misura il risparmio effettivo al netto del costo dei commitments inutilizzati, diviso per la spesa equivalente on-demand. L'ESR medio su AWS Compute si attesta intorno al 26%, ben al di sotto dei massimi teorici del 66-72%, perché la maggior parte delle organizzazioni si porta dietro un certo inventario di commitments inutilizzati (FinOps Foundation).
Un portafoglio difendibile parte coprendo la baseline prevedibile, ovvero il minimo di utilizzo registrato nel mese, con EC2 Instance Savings Plans o RI Standard per ottenere gli sconti più aggressivi. Sopra a questo strato si aggiungono i Compute Savings Plans per i workloads steady-state variabili, dato che si applicano trasversalmente a famiglie, regioni e compute serverless. I workloads bursty o incerti restano in on-demand finché l'utilizzo non si stabilizza al punto da poter essere previsto.
I giusti strumenti di ottimizzazione dei costi cloud automatizzano l'analisi della copertura e segnalano quando l'utilizzo dei commitments scende sotto le soglie obiettivo.
Quando usare le Spot Instances per workloads cost-sensitive?
Spot funziona per qualsiasi workload che tolleri le interruzioni. Job batch, pipeline CI/CD, data processing, server API stateless dietro auto-scaling group e microservizi containerizzati con gestione graceful dello shutdown sono tutti candidati validi.
La chiave per un uso affidabile di Spot è diversificare tra tipi di istanze e availability zone. Usi la selezione delle istanze basata su attributi per consentire a EC2 di pescare dal pool di capacità più ampio possibile. Lo Spot Instance Advisor di AWS mostra la frequenza di interruzione per tipo di istanza: la maggior parte delle famiglie general-purpose e compute-optimized in US East si colloca sotto il 5%.
Affiancare Spot a un fallback on-demand o Savings Plan in un auto-scaling group crea una tariffa mista. Una flotta con il 70% di Spot e il 30% di on-demand può ottenere un risparmio effettivo del 45-60% rispetto a una tariffazione 100% on-demand.
Come rendere i prezzi AWS EC2 prevedibili e difendibili?
Il report State of FinOps 2025 della FinOps Foundation, che copre 69 miliardi di dollari di spesa cloud su 861 rispondenti, indica come la riduzione degli sprechi e l'ottimizzazione dei workloads restino la priorità numero uno per il 50% dei practitioner (FinOps Foundation). Su questa scala, anche miglioramenti marginali nella gestione dei costi EC2 si traducono in cifre rilevanti.
L'ottimizzazione manuale non scala. Revisioni trimestrali di right-sizing, tracking delle RI su foglio elettronico e adozione reattiva di Spot lasciano risparmi sul tavolo tra un ciclo di revisione e l'altro. L'analisi di McKinsey su 3 miliardi di dollari di fatture cloud ha individuato un ulteriore 10-20% di risparmi non sfruttati nella maggior parte delle organizzazioni, comprese quelle con programmi FinOps già avviati (McKinsey).
FlexSave for Compute di DoiT automatizza gli sconti basati su commitments analizzando in continuo i pattern di utilizzo di EC2 e applicando il mix ottimale di Savings Plans e capacità riservata senza alcun intervento manuale. La piattaforma Procurement di DoiT consolida la fatturazione tra account AWS e fornisce la visibilità sui costi di cui gli strumenti FinOps per AWS hanno bisogno per rendere la spesa EC2 prevedibile invece che reattiva.
Domande frequenti sui prezzi AWS EC2
Quanto costa al mese un'istanza EC2?
Il costo mensile dipende da tipo di istanza, regione e modello di prezzo. Una general-purpose m7i.large in US East costa circa 73,58 $/mese on demand (730 ore × 0,1008 $/ora). Reserved Instances e Savings Plans riducono questa cifra del 40-72% in base a durata e opzione di pagamento. A ciò si aggiungono storage EBS, data transfer e altri addebiti accessori per ottenere il quadro completo.
Quali modelli di prezzo offre AWS per EC2?
AWS offre quattro opzioni di prezzo principali per EC2: On-Demand (nessun impegno, piena flessibilità), Reserved Instances (impegno di 1 o 3 anni, sconto fino al 72%), Savings Plans (impegno di 1 o 3 anni, fino al 66% con maggiore flessibilità tra famiglie e regioni) e Spot Instances (nessun impegno, sconto del 60-90%, interrompibili).
Perché la mia fattura EC2 supera il prezzo dell'istanza?
Le fatture EC2 includono molto più delle sole ore di istanza. Storage EBS, data transfer (in particolare l'egress internet a 0,09 $/GB), Elastic Load Balancer, indirizzi IPv4 pubblici (0,005 $/ora da febbraio 2024), NAT Gateway e snapshot sono tutte voci che si sommano. Per i workloads esposti a internet, questi costi accessori possono rappresentare il 40-50% della spesa EC2 totale.
Quale Effective Savings Rate dovrebbero porsi come obiettivo i team FinOps?
L'ESR medio su AWS Compute si attesta intorno al 26%. Le pratiche FinOps mature puntano al 30-40% o oltre, mantenendo un'elevata utilizzazione dei commitments, coprendo il carico di baseline con gli strumenti dal maggior sconto e misurando i risparmi rispetto alla spesa equivalente on-demand anziché rispetto alle percentuali di sconto nominali.
Scopra come FlexSave for Compute può aiutarla a ottimizzare i costi di AWS EC2 con strumenti pratici e affidabili, pensati per i team cloud di oggi. Ci contatti per scoprire come DoiT può rendere prevedibile la sua spesa EC2.