Perché S3 non è un hard disk (e perché conta per l'esame)
Pensare ad Amazon S3 come a un hard disk è l'errore che fa sbagliare metà delle domande all'esame AWS. Ecco perché S3 è un servizio attivo, non uno storage.
Perché S3 non è un hard disk (e perché conta per l’esame)
Francesco apre la console AWS per la prima volta, clicca Services, scrolla fino a Storage e seleziona S3. Vede una schermata vuota con un pulsante Create bucket.
Il suo cervello, in automatico, fa una traduzione: “Ah, è come Dropbox. O come una cartella di rete aziendale. Carico file, li scarico, fine.”
Ed è qui, al minuto cinque della sua avventura in AWS, che inizia il malinteso che gli farà sbagliare metà delle domande su S3 al Cloud Practitioner. Per non parlare del Solutions Architect.
S3 non è un hard disk. Non è un Dropbox. Non è una cartella di rete. È qualcosa di diverso, e capire la differenza è uno di quei momenti che ti fanno scattare la classica lampadina sopra la testa.
In questo articolo ti spiego il modello mentale giusto, il vocabolario che ti serve davvero, e tre caratteristiche di S3 che non puoi permetterti di non conoscere, sia per l’esame, sia per il primo giorno di lavoro vero su AWS.
S3 non è uno storage. È un servizio attivo.
Prima distinzione, quella che cambia tutto.
Quando colleghi un hard disk al tuo PC, lavori sui blocchi. Il sistema operativo divide i file in pezzi piccoli, li scrive in posizioni precise, e tiene una mappa per ritrovarli. Tu vedi le cartelle, ma sotto è solo una griglia di blocchi. Block storage.
Quando monti una share di rete con NFS o SMB, lavori sui file. Il sistema gestisce una gerarchia di cartelle, permessi, lock di scrittura, modifiche concorrenti. File storage.
S3 è una terza cosa: object storage. Non lavori sui blocchi, non lavori sui file gerarchici. Lavori su oggetti, pacchetti autonomi composti da contenuto, metadati, e un’etichetta univoca che li identifica.
Pensalo così. S3 è un magazzino automatizzato gigante. Tu non scegli lo scaffale, non monti niente, non gestisci la struttura interna. Consegni un pacco al portone con un’etichetta sopra, e il magazzino:
- decide dove metterlo;
- ne fa copie automatiche in altre città;
- te lo restituisce in un secondo se gli mostri l’etichetta;
- tiene una ricevuta di ogni spostamento.
E tu interagisci con questo magazzino solo via API HTTP. Niente mount, niente file system, niente cartelle vere. Solo PUT, GET, DELETE su un endpoint.
Questa differenza non è teoria astratta. È il punto da cui dipendono almeno tre tipologie di domande all’esame, e il motivo per cui in produzione si usa S3 dove un sistemista tradizionale userebbe un file server (e si farebbe del male).
Bucket, oggetto, chiave: il vocabolario che non puoi saltare
Tre parole. Imparale bene e ti aprirà la porta a tutto il resto.
Bucket. È il magazzino. Lo crei, gli dai un nome, scegli una regione AWS dove vivrà fisicamente. Il nome del bucket è univoco a livello globale: se lo prendi tu, nessun altro al mondo può usarlo. Non è una scelta poetica di AWS, è perché il nome del bucket finisce dentro l’URL pubblico dell’oggetto.
Oggetto. È il pacco. Composto da tre cose: il contenuto vero e proprio (il file), una serie di metadati (tipo MIME, data di scrittura, header personalizzati), e una key.
Key. È l’etichetta del pacco. Sembra un percorso filesystem (/clienti/2026/aprile/fattura-1234.pdf) ma non lo è: è una stringa unica dentro il bucket. Quelle che la console mostra come “cartelle” sono un’illusione visiva, S3 le costruisce per te a partire dagli slash nelle key, ma sotto non esistono directory reali.
Questa è una di quelle cose che, finché non te lo dicono, non immagini. E al primo esame Solutions Architect ti mettono almeno una domanda dove la risposta dipende proprio da questo.
Bonus per l’esame: ogni oggetto può arrivare a 5 TB di dimensione, e il bucket non ha un limite di numero di oggetti. Tradotto: se stai cercando un servizio AWS dove “metto qualunque cosa, qualunque dimensione, qualunque quantità”, la risposta è quasi sempre S3.
Le 3 caratteristiche di S3 che cambiano tutto
Ci sono decine di feature di S3. La verità è che, per il 90% delle domande d’esame e dei casi reali, te ne servono tre.
1. Strong consistency. Quando scrivi un oggetto su S3 e subito dopo lo leggi, ottieni la versione più recente. Sempre. Senza eccezioni. È un cambio storico, fino al 2020 S3 garantiva eventual consistency in alcuni scenari, e questo creava bug sottili nelle applicazioni che leggevano subito dopo aver scritto. Ora non più.
Se ti capita di studiare su un materiale che parla di “eventual consistency su S3”, buttalo. Non è più aggiornato.
2. Versioning. Puoi attivare il versioning su un bucket e da quel momento ogni modifica a un oggetto crea una nuova versione, senza cancellare la precedente. Anche le cancellazioni diventano “soft”: creano una delete marker, ma puoi recuperare l’oggetto in qualsiasi momento.
L’analogia migliore è Google Drive con la cronologia delle versioni. Ti permette di tornare indietro su una modifica errata, di proteggerti da overwrite accidentali, e, combinato con MFA Delete, di costruire archivi a prova di errore umano.
Domanda d’esame tipica: “L’azienda vuole proteggersi da cancellazioni accidentali su S3. Cosa attiva?”. Se hai capito il versioning, hai trovato la risposta in tre secondi.
3. Storage classes. S3 non è un solo livello di storage. È una famiglia. Stessi bucket, stesse API, ma sotto puoi scegliere classi diverse a seconda di quanto spesso accedi ai dati e quanto vuoi pagare:
- Standard, accesso frequente, costo pieno, performance massima.
- Intelligent-Tiering, S3 sposta i tuoi oggetti tra livelli automaticamente in base agli accessi.
- Infrequent Access (IA), paghi meno per lo storage, ma paghi un piccolo costo aggiuntivo a ogni recupero.
- Glacier (e Deep Archive), archivio profondo, costi minimi, recupero da minuti a ore.
Il pattern d’esame è sempre lo stesso: “L’azienda accede a questi dati una volta al mese / una volta all’anno / mai. Quale classe scegli?”. Conosci l’asse “frequenza di accesso → costo storage / costo recupero” e prendi quei punti praticamente a occhi chiusi.
Strong consistency, versioning, storage classes. Mettiti queste tre in tasca e hai già spostato la lancetta sui domini Security e Services del CLF-C02.
Quando S3 è la risposta (spoiler: più spesso di quanto pensi)
C’è un trucco non scritto per le domande a scenario sull’esame AWS: se la domanda parla di “salvare”, “archiviare”, “ospitare contenuti statici”, “ricevere log”, “fare da sorgente per Lambda”, la risposta nel 70% dei casi è S3.
Non sto esagerando. S3 è il servizio centrale di praticamente ogni architettura su AWS. Vediamo quando lo trovi nel mondo reale (e nello scenario d’esame).
- Hosting di siti statici. S3 + CloudFront davanti. È la combo più economica per servire un sito di contenuti.
- Backup e archivi. Versioning + Glacier per pagare poco e dormire sereni.
- Data lake. Migliaia di file CSV, Parquet, JSON dentro lo stesso bucket, interrogati con Athena o letti da pipeline ETL.
- Log centralizzati. ALB, CloudFront, VPC Flow Logs scrivono direttamente su S3. Da lì li analizzi.
- Distribuzione software. Pacchetti, immagini, asset di applicazioni mobile. Spesso tramite presigned URL, di cui parlerò in un articolo dedicato.
- Trigger event-driven. Quando un oggetto arriva in un bucket, S3 può triggerare una Lambda. È la base di metà delle architetture serverless reali.
C’è anche il rovescio della medaglia: S3 non è un database. Se in una domanda d’esame ti chiedono “salvare lo stato di una sessione utente in tempo reale con accesso a chiave-valore a bassissima latenza”, la risposta è DynamoDB, non S3. È una trappola classica e cade ancora chi confonde “storage di oggetti” con “key-value store”.
Logica prima, memoria poi. S3 risponde a una domanda specifica: “dove metto qualcosa di grande, raramente modificato e accessibile via API?”. Quando la domanda è quella, S3 è quasi sempre la risposta giusta.
Domande frequenti su Amazon S3
Quanto costa S3? Paghi tre cose: lo storage occupato (al GB/mese, con prezzi diversi per classe), le richieste API (PUT, GET, LIST), e il traffico in uscita verso internet. Le tariffe variano per regione e cambiano nel tempo: per i numeri aggiornati controlla la pagina pricing ufficiale di S3. Il Free Tier include una quota mensile di GB e richieste sufficiente per esercitarti senza spendere.
S3 è pubblico di default? No. Dal 2023 i bucket sono privati di default e il Block Public Access è attivo a livello di account su tutti i nuovi bucket. Per renderli pubblici devi disattivare il blocco e aggiungere una bucket policy esplicita. Se hai materiale di studio più vecchio che dice il contrario, è obsoleto.
Qual è la differenza tra S3 ed EBS? EBS è block storage attaccato a una singola EC2. È come l’hard disk del tuo PC: lo monti su un’istanza, ci scrivi un file system sopra, e da lì tratti i file in modo tradizionale. S3 è object storage globale, accessibile via API HTTP da qualunque servizio. EBS lo usi quando hai bisogno di un disco vero per un’app. S3 lo usi per quasi tutto il resto.
Si possono cancellare oggetti per sbaglio? Sì, se non hai protezioni attive. Le difese standard sono tre: versioning attivo, MFA Delete per cancellazioni definitive, e le Object Lock per bucket regolamentati. Combinandole, ottieni un livello di protezione che resiste anche all’errore umano e agli incidenti di sicurezza.
S3 funziona offline o solo via internet? S3 è un servizio cloud accessibile via API HTTP. Per usarlo da una VPC privata senza far passare il traffico per internet pubblico, AWS offre i VPC Endpoint (Gateway Endpoint specifico per S3). È una topologia che vedrai in molte domande SAA.
Qual è la dimensione massima di un singolo oggetto? Cinque TB. Per oggetti grandi è obbligatorio il multipart upload, che divide il file in parti caricate in parallelo e poi ricomposte da S3.
Una volta che hai capito che S3 non è un hard disk, hai capito metà di AWS. Davvero.
Quasi ogni servizio del catalogo, prima o poi, parla con S3. Se l’oggetto, la chiave e il bucket ti sono limpidi, il resto si appoggia naturalmente sopra.
Se vuoi andare più a fondo su S3, versioning, lifecycle policy, presigned URL, replicazione cross-region, tutta la parte di sicurezza con bucket policy e ACL, il corso verticale S3 nell’Academy è esattamente questo. Un singolo servizio, smontato pezzo per pezzo, con laboratori reali in console.
E se stai preparando un esame AWS, il consiglio è uno: nelle simulazioni, ogni volta che leggi una domanda con dentro le parole “salva”, “archivia”, “ospita” o “raccoglie”, chiediti “è S3?” prima di guardare le opzioni. Otto volte su dieci, lo è.
La prossima volta che apri la console S3, ricorda: non stai salvando un file. Stai consegnando un pacco a un magazzino.
E quel magazzino lavora per te.
Ti è stata utile questa guida? Condividila con il collega che ha appena ricevuto il voucher e non sa da dove iniziare.