Cos'è S3 e come funziona lo storage a oggetti

Devi salvare le immagini caricate dagli utenti, i backup o i file statici del sito, e la risposta che trovi ovunque è "usa S3". Poi apri la console, ti chiede un bucket e ti parla di chiavi e classi di storage, e capisci che non è la cartella condivisa che ti aspettavi. In questo articolo trovi come funziona lo storage a oggetti, il modello di costo e la sicurezza.

Cos'è

S3 è un servizio di storage a oggetti: ci depositi file interi identificati da un nome, li recuperi via HTTP o API, e non esiste un disco né un file system da montare.

È il servizio più vecchio di AWS ed è diventato lo standard di fatto: "compatibile S3" è ormai una categoria a sé. È uno dei mattoni base che descrivo in cos'è AWS.

Storage a oggetti contro file system

È la differenza che spiega tutto il resto, e capirla ora ti evita metà dei problemi successivi.

Su un file system tradizionale — il disco del tuo computer, quello di un VPS — esiste una gerarchia vera: le cartelle sono oggetti reali, puoi scrivere cento byte in mezzo a un file, rinominare una directory con tutto il contenuto in un colpo.

Nello storage a oggetti niente di questo esiste. C'è una lista piatta di coppie: una chiave (il nome) e un contenuto (i byte), più alcuni metadati. Le conseguenze:

• Non ci sono cartelle vere. immagini/2026/foto.jpg non è una foto dentro due cartelle: è un unico oggetto la cui chiave contiene per intero quella stringa, barre comprese. La console disegna un albero per cortesia, filtrando per prefisso.
• Rinominare una "cartella" non è un'operazione: significa copiare ogni oggetto con una chiave nuova e cancellare i vecchi. Un milione di oggetti, un milione di operazioni.
• Gli oggetti si sostituiscono, mai si modificano.
• In compenso scala senza limiti pratici, ogni oggetto ha il suo URL, la durabilità è altissima.

Regola pratica: perfetto per file scritti una volta e letti tante, sbagliato per qualcosa da modificare di continuo in piccole parti — un database non ci va sopra.

Bucket, chiavi e oggetti

Tre parole. Il bucket è il contenitore: vive in una regione e il suo nome è unico a livello globale, quindi se qualcuno ha già preso immagini non è più disponibile — per questo i nomi reali somigliano a nomeprogetto-media-prod-eu. La chiave è il nome completo dell'oggetto, barre incluse. L'oggetto è il contenuto più i metadati: tipo MIME, dimensione, data, cache.

Con la CLI di AWS:

aws s3 mb s3://nomeprogetto-media-prod
aws s3 cp foto.jpg s3://nomeprogetto-media-prod/immagini/2026/foto.jpg
aws s3 sync ./build s3://nomeprogetto-media-prod/ --delete
aws s3 ls s3://nomeprogetto-media-prod/immagini/2026/

Nota sync --delete: allinea la destinazione all'origine cancellando ciò che non esiste più in locale. Comodissimo per pubblicare un sito statico, e un ottimo modo per cancellare per sbaglio: provalo con --dryrun.

Le classi di storage

S3 fa pagare in proporzione a quanto vuoi che i file siano pronti. I nomi cambiano nel tempo, la logica è stabile:

Tipo di classe	Per cosa	Compromesso
Standard	File letti spesso	Costo di storage più alto, accesso immediato
A livelli automatici	Accesso imprevedibile	Sposta i file da sola, piccola quota di monitoraggio
Accesso poco frequente	Letti raramente ma subito	Storage meno caro, si paga di più per recupero
Archivio	Backup e conservazione a lungo	Molto economico, recupero lento e a pagamento
Archivio profondo	Conservazione per legge	Il più economico, recupero nell'ordine di ore

Due cose che contano più delle sigle:

Le classi fredde hanno una durata minima di fatturazione. Se archivi un file e lo cancelli dopo pochi giorni paghi comunque il minimo: su file che cambiano spesso costano più di Standard.

Non spostarli a mano: usa le regole del ciclo di vita. Imposti una politica sul bucket — dopo N giorni alla classe poco frequente, dopo M in archivio, poi cancella — e S3 la applica da sola. È la leva di risparmio più efficace, e quasi nessuno la configura. Se non sai stimare gli accessi, la classe a livelli automatici è il compromesso.

Versionamento

Attivandolo, ogni sovrascrittura crea una nuova versione invece di rimpiazzare la precedente, e ogni cancellazione mette un segnaposto sopra l'oggetto senza distruggerlo. È la rete di sicurezza contro l'errore umano e il ransomware, e su dati importanti va acceso.

Due avvertenze: paghi tutte le versioni, quindi il bucket cresce in silenzio e serve una regola che scada le vecchie; e svuotarlo richiede di cancellare anche le versioni, altrimenti resta pieno di roba che paghi e non vedi.

Non sostituisce una strategia di backup: sta nello stesso account e nello stesso servizio, quindi non copre lo scenario in cui perdi l'accesso all'account.

Il modello di costo

Tre voci, e la terza rovina i preventivi.

Storage. Quanti gigabyte tieni, per quanto tempo, in quale classe. La voce più prevedibile e di solito la meno cara.

Richieste e operazioni. Ogni PUT, GET, LIST e copia si paga a tariffe minuscole, rilevanti quando le operazioni sono milioni. Le classi fredde costano di più per richiesta, e alcune aggiungono un costo di recupero.

Traffico in uscita — questa è quella che sorprende. I dati che entrano sono generalmente gratuiti; quelli che escono si pagano al gigabyte. Se il bucket serve immagini o video ai visitatori, la voce dominante non è lo spazio ma il traffico generato dal successo del sito, con rapporti di ordini di grandezza.

Tre conseguenze: CDN davanti ai file pubblici; ottimizza le immagini, perché paghi i byte trasferiti; attiva un budget con avviso.

Servire file statici e perché serve una CDN

Puoi far servire al bucket i file di un sito statico o gli asset di un'applicazione. È la configurazione più semplice, ma senza qualcosa davanti è una cattiva idea per tre motivi.

Il costo. Ogni richiesta paga l'operazione e il traffico in uscita. Con una CDN davanti il grosso arriva dalla cache e l'origine è interrogata raramente.

La latenza. Il bucket sta in una regione, e chi è dall'altra parte del mondo paga il viaggio a ogni file. Una CDN serve dal punto più vicino — l'edge computing applicato ai file.

Il controllo. HTTPS su dominio personalizzato, intestazioni di caching, compressione, protezione dagli abusi.

Lo schema classico è bucket privato più CloudFront davanti: il contenuto è pubblico, il bucket mai. Se però ti serve solo un sito statico online, Cloudflare Pages o Vercel fanno storage, CDN, HTTPS e deploy in un passaggio.

Sicurezza: i bucket pubblici per errore

I bucket lasciati pubblici per sbaglio sono una delle cause più comuni e documentate di fughe di dati degli ultimi dieci anni. Non attacchi sofisticati: dati sanitari, documenti d'identità, backup di database e credenziali trovati da chi ha provato a indovinare un nome di bucket, con strumenti automatici che scandagliano internet cercando esattamente questo.

L'errore non è malizia, è fretta. Un file non si scarica, i permessi non sono chiari, qualcuno apre il bucket "solo per provare", funziona, e nessuno torna indietro.

Come si evita

Tieni attivo il blocco dell'accesso pubblico. È un interruttore, a livello di account e di bucket, che impedisce qualsiasi configurazione che renda i dati pubblici. Attivalo sull'account: le eccezioni diventano deliberate, non accidentali.

Il bucket resta privato: pubblico è ciò che c'è davanti. I file raggiungibili dal web si espongono tramite la CDN autorizzata a leggerlo, mai con la lettura anonima.

Per gli accessi temporanei usa gli URL prefirmati: danno il diritto di scaricare o caricare un oggetto per un tempo limitato, senza aprire nulla.

import boto3

s3 = boto3.client("s3")

url = s3.generate_presigned_url(
    "get_object",
    Params={"Bucket": "nomeprogetto-media-prod", "Key": "fatture/2026/f-001.pdf"},
    ExpiresIn=300,  # 5 minuti
)

Con put_object lo stesso meccanismo fa caricare il browser direttamente sul bucket, senza far passare il file dal tuo server e senza dare credenziali al client.

Applica il privilegio minimo. Chi carica le immagini non deve poter cancellare i backup: un'identità per compito, ruoli al posto di chiavi statiche. Le chiavi, se servono, stanno nelle variabili d'ambiente, mai nel repository.

Cifra a riposo e imponi HTTPS. La cifratura lato server è ormai predefinita; aggiungi una politica che rifiuti le richieste non cifrate.

Attiva i log di accesso. AWS segnala i bucket pubblici o condivisi fuori dall'account: guarda quei report, invece di scoprire il problema dalla stampa.

Attenzione ai backup. Il file più pericoloso non è il contenuto pubblico: è il dump del database messo "temporaneamente" accanto. Tienilo in un bucket separato e privato. Il quadro generale è in rendere sicuro un sito e cos'è la cybersecurity.

Cosa fa perdere ore e soldi

Trattare S3 come un disco. Montarlo come file system è possibile, ma prestazioni e semantica non sono quelle di un disco.

Dimenticare le versioni vecchie. La fattura cresce senza spiegazione: la console mostra solo le versioni correnti.

Fare LIST su bucket enormi in un ciclo. Costa ed è lento su milioni di chiavi: tieni l'indice in un database.

Mettere tutto in classi fredde. Con durata minima e costi di recupero, su file che si toccano spesso si spende di più.

Il tipo MIME sbagliato. Il browser scarica il file invece di mostrarlo. Succede spessissimo via API.

I servizi compatibili e perché conta

L'API di S3 è uno standard di fatto, e diversi prodotti la parlano:

• Cloudflare R2 — non fattura il traffico in uscita, il che ribalta il calcolo per chi serve molti file. Si integra con Cloudflare e i Workers.
• MinIO — lo installi tu, sul tuo server o in un container. Ottimo per lo sviluppo locale e per chi tiene i dati in casa.
• DigitalOcean Spaces e simili — stessa API, prezzi più semplici da prevedere.

Perché conta: lo stesso SDK e lo stesso codice funzionano cambiando endpoint e credenziali. È uno dei pochi punti del cloud dove il lock-in è davvero basso — se scrivi contro l'API S3 senza usare funzioni esclusive di AWS, spostarti è configurazione, non riscrittura. Il tema più ampio è in AWS, Azure o Google Cloud.

In sintesi

S3 è storage a oggetti, non un disco: una lista piatta di chiavi e contenuti, dove le cartelle non esistono e il "percorso" è parte del nome.

Le classi di storage e le regole del ciclo di vita sono la leva di risparmio più efficace, e quasi nessuno le configura.

Il costo ha tre voci e quella che sorprende è il traffico in uscita: per questo davanti ai file pubblici ci va sempre una CDN.

Il bucket resta privato, sempre. Blocco dell'accesso pubblico, CDN o URL prefirmati per esporre ciò che serve, privilegio minimo, attenzione ai backup parcheggiati per sbaglio.

L'API è uno standard: R2, MinIO e Spaces parlano la stessa lingua, quindi resti libero di cambiare.

Per il contesto vedi cos'è AWS, e per cosa mettere davanti ai file cos'è una CDN.