Costi Cloud Storage nel 2026: Guida FinOps a Lifecycle Policy, Auto-Tiering e Terraform

Perché lo storage cloud è il costo nascosto più pericoloso

Parliamoci chiaro: nella maggior parte delle organizzazioni, lo storage rappresenta tra il 25% e il 40% della bolletta cloud totale. Eppure riceve una frazione dell'attenzione dedicata al compute. Il motivo? Semplice. I costi di calcolo generano picchi visibili nel ciclo di fatturazione, mentre lo spreco di storage si accumula silenziosamente — per mesi, a volte anni — prima che qualcuno si prenda la briga di guardare.

Log archiviati dal 2022 ancora nel tier Standard. Versioning abilitato senza policy di scadenza. Milioni di upload multipart mai completati. Singolarmente sembrano trascurabili. Insieme, però, rappresentano migliaia di euro al mese che state buttando dalla finestra.

Secondo il report FinOps in Focus 2025, circa il 21% della spesa infrastrutturale cloud (parliamo di 44,5 miliardi di dollari stimati) viene sprecata in risorse sottoutilizzate. E lo storage è uno dei principali colpevoli. In questa guida affrontiamo il problema con un approccio FinOps completo: analizziamo le classi di storage dei tre major cloud, implementiamo lifecycle policy e auto-tiering con esempi Terraform pronti all'uso, e costruiamo una strategia per tagliare i costi storage del 40–70%.

Classi di storage a confronto: AWS S3, Azure Blob, GCS

Ogni cloud provider struttura i propri tier di storage attorno allo stesso compromesso fondamentale: minor costo per GB in cambio di maggiore latenza di recupero e costi di accesso più elevati. Onestamente, scegliere il tier giusto per ogni tipo di dato è l'ottimizzazione a maggiore impatto che avete a disposizione, con risparmi del 40–70% per singolo livello di transizione.

AWS S3: otto classi di storage

Amazon S3 offre la struttura di tier più granulare tra i tre provider:

• S3 Standard — ~$0,023/GB/mese per i primi 50 TB. Il tier per dati acceduti frequentemente, quello che usate di default (e spesso dove restano dati che non dovrebbero starci).
• S3 Intelligent-Tiering — Sposta automaticamente gli oggetti tra tier in base ai pattern di accesso reali. Fee di monitoraggio: $0,0025 per 1.000 oggetti/mese. Ne parliamo in dettaglio più avanti.
• S3 Standard-IA — ~$0,0125/GB/mese. Per dati acceduti meno di una volta al mese. Attenzione: minimo 30 giorni di storage, e gli oggetti sotto 128 KB vengono fatturati come 128 KB.
• S3 One Zone-IA — ~$0,01/GB/mese. Come Standard-IA ma su una singola AZ — ideale per dati riproducibili come cache o thumbnails.
• S3 Glacier Instant Retrieval — ~$0,004/GB/mese. Retrieval in millisecondi, perfetto per dati acceduti una volta al trimestre.
• S3 Glacier Flexible Retrieval — ~$0,0036/GB/mese. Retrieval da minuti a ore.
• S3 Glacier Deep Archive — ~$0,00099/GB/mese. Il più economico in assoluto: 96% di risparmio rispetto a Standard. Il prezzo da pagare? Retrieval in 12–48 ore.

Azure Blob Storage: quattro tier principali

• Hot — ~$0,018/GB/mese. Per dati acceduti quotidianamente.
• Cool — ~$0,01/GB/mese. Dati acceduti meno di una volta al mese. Minimo 30 giorni.
• Cold — ~$0,0045/GB/mese. Una via di mezzo tra Cool e Archive, con accesso immediato e minimo 90 giorni.
• Archive — ~$0,002/GB/mese. Retrieval in ore. Minimo 180 giorni.

Occhio ai costi di transazione: Cool e Cold possono costare più di Hot se leggete i dati più frequentemente del previsto. Non scegliete un tier basandovi solo sul prezzo per GB — modellate anche read, LIST, write e fee di retrieval. È un errore che ho visto fare troppo spesso.

Google Cloud Storage: quattro classi + Autoclass

• Standard — ~$0,020/GB/mese. Dati acceduti frequentemente.
• Nearline — ~$0,010/GB/mese. Accesso meno di una volta al mese. Minimo 30 giorni.
• Coldline — ~$0,004/GB/mese. Accesso meno di una volta al trimestre. Minimo 90 giorni.
• Archive — ~$0,0012/GB/mese. Accesso meno di una volta all'anno. Minimo 365 giorni.

Tabella riepilogativa prezzi (regioni US, aprile 2026)

Tier	AWS S3	Azure Blob	GCS
Hot / Standard	$0,023/GB	$0,018/GB	$0,020/GB
Infrequent / Cool	$0,0125/GB	$0,010/GB	$0,010/GB
Cold / Coldline	$0,004/GB	$0,0045/GB	$0,004/GB
Archive	$0,00099/GB	$0,002/GB	$0,0012/GB

Lifecycle Policy: automatizzare le transizioni di tier

Le lifecycle policy sono, senza esagerare, lo strumento FinOps a più alto ROI per lo storage. Una volta configurate, funzionano in background senza intervento manuale — automatizzano la transizione degli oggetti verso tier più economici e cancellano i dati scaduti. Configurate e dimenticate (ma non troppo, come vedremo).

AWS S3 Lifecycle Rules

Le regole di lifecycle S3 possono transitare oggetti tra qualsiasi classe di storage in base all'età o al prefisso, ed espirare automaticamente gli oggetti dopo un periodo definito. Le regole più impattanti per la maggior parte dei team:

• Standard → Standard-IA dopo 30 giorni per log e dati operativi
• Standard-IA → Glacier dopo 90 giorni per backup
• Expiry rule per cancellare oggetti o versioni non correnti dopo il periodo di retention
• Abort incomplete multipart upload dopo 7 giorni (questa da sola può farvi risparmiare più di quanto pensiate)

Azure Blob Lifecycle Management

Azure esegue le lifecycle policy una volta al giorno in background. Le regole si basano sull'età del blob — giorni dall'ultima modifica, ultimo accesso o creazione:

• Hot → Cool dopo 30 giorni
• Cool → Cold dopo 90 giorni
• Cold → Archive dopo 180 giorni
• Delete dopo 365 giorni per log e dati temporanei

Una buona notizia: le policy sono gratuite. Si paga solo per le chiamate API Set Blob Tier. Le operazioni di delete non costano nulla.

GCS Lifecycle Rules vs Autoclass

GCS offre due approcci mutuamente esclusivi (e questo è un dettaglio che molti trascurano):

• Lifecycle rules manuali — Transizioni basate su età, prefisso o condizioni personalizzate. Pieno controllo, ma richiedono manutenzione attiva.
• Autoclass — Monitora i pattern di accesso reali e sposta automaticamente gli oggetti nel tier ottimale. Nessuna regola da scrivere o aggiornare. Se Autoclass è attivo su un bucket, le lifecycle rules per il tiering vengono disabilitate.

Autoclass transita gli oggetti non acceduti verso Nearline dopo 30 giorni, Coldline dopo 90 giorni e Archive dopo 365 giorni (se configurato come terminal class). Quando un oggetto viene acceduto, torna automaticamente in Standard. Fee di gestione: $0,0025 per 1.000 oggetti/mese.

Intelligent Tiering vs Lifecycle Policy: quando usare cosa

Ecco, questa è la decisione che molti team sbagliano. La confusione è comprensibile — entrambi gli approcci promettono risparmi automatici, ma funzionano in modo molto diverso. Vediamo una guida decisionale pratica.

Usate Intelligent Tiering / Autoclass quando:

• I pattern di accesso sono imprevedibili o cambiano nel tempo (contenuti generati dagli utenti, media library, data lake)
• Non avete risorse per monitorare e aggiornare le lifecycle rules regolarmente
• Gli oggetti hanno una dimensione media superiore a 128 KB
• Il vostro team preferisce un approccio set-and-forget

Usate Lifecycle Policy quando:

• I pattern di accesso sono chiaramente prevedibili e basati sul tempo (log giornalieri, backup settimanali)
• Avete milioni di oggetti piccoli (<128 KB) dove le monitoring fee supererebbero i risparmi
• Dovete implementare cancellazione automatica per compliance o retention policy
• Volete controllo granulare sulle transizioni per prefisso o tag

Combinare i due approcci

Su AWS potete (e dovreste) combinare Intelligent Tiering con lifecycle rules: usate una regola per spostare gli oggetti in Intelligent-Tiering come classe di storage, e lasciate che il servizio gestisca le transizioni tra i sub-tier. Aggiungete poi una regola di expiration per la cancellazione automatica. Su GCS, invece, i due approcci sono mutuamente esclusivi per bucket — dovrete scegliere.

Implementazione Infrastructure-as-Code con Terraform

Bene, passiamo alla parte pratica. Di seguito trovate gli esempi Terraform pronti all'uso per ogni cloud provider. Tutto il codice è compatibile con le versioni correnti dei provider Terraform ad aprile 2026.

AWS S3: Lifecycle completa con Intelligent Tiering

# Bucket S3 con lifecycle ottimizzata
resource "aws_s3_bucket" "data" {
  bucket = "azienda-data-prod-2026"

  tags = {
    Team        = "platform"
    CostCenter  = "engineering"
    Environment = "production"
  }
}

# Lifecycle rules (AWS provider v4+: risorsa separata)
resource "aws_s3_bucket_lifecycle_configuration" "data_lifecycle" {
  bucket = aws_s3_bucket.data.id

  # Regola 1: Log operativi - transizione aggressiva
  rule {
    id     = "logs-tiering"
    status = "Enabled"

    filter {
      prefix = "logs/"
    }

    transition {
      days          = 30
      storage_class = "STANDARD_IA"
    }

    transition {
      days          = 90
      storage_class = "GLACIER"
    }

    transition {
      days          = 180
      storage_class = "DEEP_ARCHIVE"
    }

    expiration {
      days = 730  # 2 anni
    }

    noncurrent_version_expiration {
      noncurrent_days = 30
    }
  }

  # Regola 2: Dati applicativi - Intelligent Tiering
  rule {
    id     = "app-data-intelligent-tiering"
    status = "Enabled"

    filter {
      prefix = "app-data/"
    }

    transition {
      days          = 0
      storage_class = "INTELLIGENT_TIERING"
    }
  }

  # Regola 3: Cleanup multipart upload incompleti
  rule {
    id     = "abort-incomplete-uploads"
    status = "Enabled"

    filter {
      prefix = ""
    }

    abort_incomplete_multipart_upload {
      days_after_initiation = 7
    }
  }
}

# Configurazione Intelligent Tiering: attivare Archive Access
resource "aws_s3_bucket_intelligent_tiering_configuration" "data_tiering" {
  bucket = aws_s3_bucket.data.id
  name   = "EntireBucket"

  tiering {
    access_tier = "ARCHIVE_ACCESS"
    days        = 180
  }

  tiering {
    access_tier = "DEEP_ARCHIVE_ACCESS"
    days        = 365
  }
}

Azure Blob: Lifecycle Management Policy

# Storage Account
resource "azurerm_storage_account" "main" {
  name                     = "stproddata2026"
  resource_group_name      = azurerm_resource_group.storage.name
  location                 = azurerm_resource_group.storage.location
  account_tier             = "Standard"
  account_replication_type = "GRS"
  account_kind             = "StorageV2"
  min_tls_version          = "TLS1_2"
  https_traffic_only_enabled = true
}

# Lifecycle Management Policy
resource "azurerm_storage_management_policy" "lifecycle" {
  storage_account_id = azurerm_storage_account.main.id

  # Regola 1: Log - tiering aggressivo
  rule {
    name    = "logs-tiering"
    enabled = true

    filters {
      prefix_match = ["logs/"]
      blob_types   = ["blockBlob"]
    }

    actions {
      base_blob {
        tier_to_cool_after_days_since_modification_greater_than    = 15
        tier_to_cold_after_days_since_modification_greater_than    = 60
        tier_to_archive_after_days_since_modification_greater_than = 120
        delete_after_days_since_modification_greater_than          = 365
      }
      snapshot {
        delete_after_days_since_creation_greater_than = 30
      }
      version {
        delete_after_days_since_creation = 30
      }
    }
  }

  # Regola 2: Backup - conservazione più lunga
  rule {
    name    = "backups-tiering"
    enabled = true

    filters {
      prefix_match = ["backups/"]
      blob_types   = ["blockBlob"]
    }

    actions {
      base_blob {
        tier_to_cool_after_days_since_modification_greater_than    = 30
        tier_to_cold_after_days_since_modification_greater_than    = 90
        tier_to_archive_after_days_since_modification_greater_than = 180
      }
    }
  }
}

GCS: Autoclass con Terraform

# Opzione 1: Autoclass (consigliato per pattern variabili)
module "gcs_autoclass" {
  source  = "terraform-google-modules/cloud-storage/google"
  version = "~> 12.3"

  project_id     = var.project_id
  names          = ["data-prod"]
  prefix         = "azienda"
  set_admin_roles = true
  admins         = ["group:[email protected]"]

  # Abilitare Autoclass
  autoclass = { data-prod = true }

  labels = {
    team        = "platform"
    cost-center = "engineering"
    environment = "production"
  }
}

# Opzione 2: Lifecycle rules manuali (per pattern prevedibili)
resource "google_storage_bucket" "logs" {
  name          = "azienda-logs-prod-2026"
  location      = "EU"
  storage_class = "STANDARD"

  lifecycle_rule {
    condition {
      age = 30
    }
    action {
      type          = "SetStorageClass"
      storage_class = "NEARLINE"
    }
  }

  lifecycle_rule {
    condition {
      age = 90
    }
    action {
      type          = "SetStorageClass"
      storage_class = "COLDLINE"
    }
  }

  lifecycle_rule {
    condition {
      age = 365
    }
    action {
      type          = "SetStorageClass"
      storage_class = "ARCHIVE"
    }
  }

  lifecycle_rule {
    condition {
      age = 730
    }
    action {
      type = "Delete"
    }
  }
}

Costi nascosti che erodono i risparmi

Ok, le lifecycle policy e l'auto-tiering possono ridurre drasticamente i costi. Ma ci sono delle trappole — e se non ne tenete conto, rischiate di vanificare buona parte dei benefici.

Early deletion charges

Tutti i tier freddi hanno un periodo minimo di storage. Se cancellate un oggetto prima della scadenza, pagate comunque l'intero periodo. Nessuna eccezione.

• S3 Standard-IA: 30 giorni minimo
• S3 Glacier: 90 giorni minimo
• Azure Cool: 30 giorni | Cold: 90 giorni | Archive: 180 giorni
• GCS Nearline: 30 giorni | Coldline: 90 giorni | Archive: 365 giorni

Le lifecycle rules devono rispettare questi minimi. Una transizione da Cool ad Archive dopo soli 60 giorni, ad esempio, genera early deletion charges su Azure. Sembra ovvio, eppure è un errore sorprendentemente comune.

Monitoring fee per oggetti piccoli

Ecco una cosa che non tutti sanno: S3 Intelligent-Tiering e GCS Autoclass applicano una fee di monitoraggio per oggetto. Con milioni di oggetti piccoli (<128 KB), il costo di monitoraggio può tranquillamente superare il risparmio.

Facciamo un esempio concreto: 10 milioni di oggetti da 50 KB generano $25/mese di monitoring fee senza alcun risparmio di storage, perché gli oggetti sotto 128 KB non vengono mai spostati. Azure Smart Tier, per contro, non applica fee esplicite per oggetto — il che lo rende più vantaggioso per bucket con molti file piccoli.

Costi di egress e trasferimento

I costi di egress sono forse i più sottovalutati di tutti. A 100 TB/mese le sole tariffe di uscita ammontano a $8.500–10.000/mese. Non è poco.

Tariffe attuali (regioni US):

• AWS S3: $0,09/GB per i primi 10 TB
• Azure: $0,087/GB per i primi 10 TB
• GCS: $0,12/GB per il primo TB, $0,11/GB per 1–10 TB

Come mitigare: Usate la CDN del vostro provider (CloudFront, Azure CDN, Cloud CDN) — il trasferimento dallo storage alla CDN è gratuito su tutti e tre i provider. E soprattutto, mantenete dati e compute nella stessa regione e sullo stesso provider quando possibile.

Costi di transazione Azure

Un avvertimento specifico per chi usa Azure: i tier Cool e Cold hanno costi di transazione significativamente più elevati di Hot. Se accedete ai dati più frequentemente del previsto, il tier Cool può finire per costare più di Hot. Modellate sempre il costo totale (storage + operazioni + retrieval) prima di scegliere un tier. Sul serio, fatelo.

Audit e pulizia: identificare lo spreco esistente

Prima di implementare nuove policy, vale la pena fare un audit per quantificare lo spreco corrente. Potreste restare sorpresi da quello che troverete.

AWS: S3 Storage Lens e CLI

# Trovare upload multipart incompleti (spreco silenzioso)
aws s3api list-multipart-uploads --bucket nome-bucket

# Analizzare la distribuzione per classe di storage
aws s3api list-objects-v2 --bucket nome-bucket \
  --query "Contents[].{Key:Key,Size:Size,StorageClass:StorageClass}" \
  --output table | head -50

# Attivare S3 Storage Lens per dashboard avanzate
aws s3control put-storage-lens-configuration \
  --account-id 123456789012 \
  --config-id cost-optimization-lens \
  --storage-lens-configuration '{"Id":"cost-optimization-lens","IsEnabled":true}'

Azure: Storage Analytics e Cost Management

# Analizzare i blob per tier
az storage blob list --container-name logs \
  --account-name stproddata2026 \
  --query "[].{Name:name,Tier:properties.blobTier,Size:properties.contentLength}" \
  --output table

# Verificare blob nel tier sbagliato (Hot ma non acceduti da 90+ giorni)
az storage account management-policy show \
  --account-name stproddata2026 \
  --resource-group storage-rg

GCS: gsutil e Cloud Monitoring

# Dimensione totale per classe di storage
gsutil du -s -c gs://nome-bucket/

# Elenco oggetti con metadata di classe
gsutil ls -L gs://nome-bucket/logs/ | grep "Storage class"

# Verificare se Autoclass è attivo
gcloud storage buckets describe gs://nome-bucket \
  --format="value(autoclass)"

Best practice FinOps per lo storage cloud

Dopo aver analizzato meccanismi e strumenti, ecco le best practice consolidate. Alcune sembreranno ovvie, ma vi assicuro che vengono ignorate molto più spesso di quanto si pensi.

1. Mai il tier Hot come default per tutto

Backup, log, archivi di compliance, dati acceduti meno di una volta al mese — niente di tutto questo dovrebbe stare in Hot/Standard. Il risparmio per singola transizione di tier va dal 40% al 70%.

Un caso reale: un provider SaaS ha scoperto che 22 mesi di log utente giacevano nel tier Hot. Spostarli in Cold ha generato un risparmio di $8.000/mese. Ventidue mesi di spreco invisibile.

2. Partite con un pilot su bucket non critici

Non lanciatevi a configurare lifecycle policy su tutto il vostro storage di produzione al primo giorno. Implementatele su 1–2 bucket non critici, monitorate i risultati per 30 giorni, poi espandete progressivamente. Questo costruisce fiducia nello strumento e permette di calibrare le soglie di transizione senza rischi.

3. Rivedete le policy regolarmente

Le lifecycle rules sono spesso create una volta e mai più toccate. Male. Includetele nel vostro ciclo di review trimestrale FinOps. I workload cambiano, e policy scritte nel 2024 potrebbero non riflettere i pattern di accesso del 2026.

4. Tagging obbligatorio sui bucket

Senza tag non potete allocare i costi di storage ai team responsabili. Applicate almeno i tag Team, CostCenter e Environment su ogni bucket. Se avete già una strategia di tagging, estendetela allo storage — sembra banale, ma è il fondamento di qualsiasi pratica FinOps seria.

5. Automatizzate la pulizia dei dati temporanei

Upload multipart incompleti, versioni non correnti, snapshot orfani — configurate regole di expiration automatiche. Il costo di non farlo cresce linearmente con il tempo, e nessuno si ricorderà di fare pulizia manuale ogni mese.

6. Usate Reserved Capacity per workload prevedibili

Su Azure, la Reserved Capacity per Blob Storage offre sconti significativi con impegni a 1 o 3 anni. Se i vostri volumi di storage crescono in modo prevedibile, è un'ulteriore leva di risparmio che si somma alle lifecycle policy.

7. Monitorate i costi di egress separatamente

Create alert dedicati per i costi di trasferimento dati. Un singolo job di migrazione cross-region o cross-cloud mal configurato può generare costi di egress superiori a mesi interi di storage. Ho visto succedere — e non è piacevole spiegarlo al management.

Domande frequenti (FAQ)

Quanto si può risparmiare con le lifecycle policy sullo storage cloud?

Con lifecycle policy ben configurate, il risparmio tipico è del 40–55% sui costi di storage. Il range esatto dipende dalla distribuzione dei dati tra i tier: spostare dati da Standard a Archive può ridurre il costo per GB fino al 96% su AWS (Glacier Deep Archive). Le organizzazioni che implementano lifecycle policy proattivamente risparmiano il 25–40% in più rispetto a quelle che intervengono dopo anni di accumulo.

S3 Intelligent Tiering conviene sempre?

No, non sempre. Intelligent Tiering è ideale per dati con pattern di accesso imprevedibili e oggetti superiori a 128 KB. Per dataset con milioni di oggetti piccoli (<128 KB), le monitoring fee ($2,50 per milione di oggetti/mese) possono superare i risparmi, perché gli oggetti sotto 128 KB restano permanentemente nel tier Frequent Access. Per pattern prevedibili e basati sul tempo, le lifecycle rules manuali restano più efficienti.

Qual è la differenza tra GCS Autoclass e le lifecycle rules?

Autoclass monitora i pattern di accesso reali e sposta automaticamente gli oggetti nel tier ottimale senza regole da configurare. Le lifecycle rules, invece, richiedono definizioni manuali basate sull'età degli oggetti. Dettaglio cruciale: i due approcci sono mutuamente esclusivi su GCS. Attivando Autoclass su un bucket, le lifecycle rules per il tiering vengono disabilitate. Autoclass è consigliato per workload con accesso variabile; le lifecycle rules per dati con ciclo di vita prevedibile.

Come evitare le early deletion charges?

Assicuratevi che le soglie di transizione delle lifecycle rules rispettino i periodi minimi di ogni tier. Non transitare da Standard-IA prima di 30 giorni, da Glacier prima di 90 giorni, da Azure Cool prima di 30 giorni e da GCS Archive prima di 365 giorni. Se i vostri dati hanno una retention breve, valutate attentamente se la transizione a un tier freddo genera effettivamente risparmi netti, o se il costo di early deletion annulla il beneficio.

Meglio gestire le lifecycle policy con Terraform o dalla console?

Terraform, senza dubbio, per ambienti di produzione. Le lifecycle policy gestite tramite Infrastructure-as-Code offrono versionamento, review via pull request, consistency tra ambienti e documentazione automatica. La console va bene per prototyping e bucket singoli, ma diventa rapidamente ingestibile con decine o centinaia di bucket. Un'ultima nota su Azure: ogni azurerm_storage_management_policy sostituisce l'intera policy dell'account, quindi gestite tutte le regole in Terraform per evitare drift.