Cos'è AWS: guida per principianti

Apri la console di AWS per la prima volta e ti trovi davanti una lista di servizi che non finisce mai, con nomi che non dicono niente. La documentazione presuppone che tu sappia già cosa cerchi, e in sottofondo c'è la paura vera: quella di lasciare acceso qualcosa e ritrovarsi un addebito assurdo. In questo articolo trovi cos'è davvero AWS, i pochi servizi che contano all'inizio, e la sezione sui costi che avrei voluto leggere prima di aprire l'account.

Cos'è

AWS non è "il cloud": è un catalogo di circa duecento servizi separati, che affitti singolarmente e paghi a consumo, ognuno con la sua console, i suoi permessi e la sua fattura.

Questa frase risolve metà della confusione iniziale. Chi arriva da un hosting web tradizionale si aspetta un pannello dove carichi il sito e sei online. AWS non funziona così: ti dà i mattoni e ti lascia costruire. Un sito su AWS può voler dire mettere insieme quattro o cinque servizi diversi, ognuno da configurare.

Il contesto generale del modello — pagare a consumo invece di comprare hardware — è in cos'è il cloud computing. Qui parliamo di cosa significa in pratica quando la console è aperta davanti a te.

Il problema vero di chi inizia

Non è la difficoltà tecnica dei singoli servizi: è che non esiste un punto di partenza ovvio. Cerchi "come pubblicare un sito su AWS" e trovi cinque risposte diverse, tutte corrette — S3 più CloudFront, EC2, Amplify, Elastic Beanstalk, ECS. Nessuna è sbagliata, e questo è esattamente il problema.

Il secondo scoglio è la fiducia. Su un servizio a canone fisso sai quanto spendi; su AWS non lo sai finché non arriva la fattura, e questa incertezza blocca più di qualsiasi difficoltà tecnica. Si risolve, ma va risolta il primo giorno.

I servizi che contano davvero all'inizio

Su duecento servizi, questi sono quelli che incontri per primi. Una riga a testa:

• EC2 — macchine virtuali. È un server che affitti a ore, concettualmente identico a un VPS: scegli taglia e sistema operativo, poi lo configuri tu.
• S3 — archiviazione di file. Ci metti immagini, backup, file statici, e li recuperi via URL o API.
• RDS — database gestiti (PostgreSQL, MySQL e altri). Il database lo usi, ma non ti occupi di installarlo, aggiornarlo o farne il backup.
• Lambda — esegui una funzione senza gestire un server, quando serve. È il modello delle serverless functions in versione AWS.
• CloudFront — la CDN di AWS, distribuisce i contenuti da punti vicini agli utenti.
• Route 53 — DNS. Registri o gestisci i domini e li fai puntare alle risorse.
• IAM — gestione di utenti e permessi. Non costa nulla ed è l'unico della lista che non puoi ignorare.

Tutto il resto — code, notifiche, container, data warehouse, machine learning — arriva dopo, quando hai un problema che lo richiede. Imparare AWS "in generale" non ha senso: se ne impara un pezzo alla volta, quando serve.

Regioni e zone di disponibilità

Questo modello va capito subito perché condiziona tutto quello che crei.

Una regione è un'area geografica (Irlanda, Francoforte, Milano, Nord Virginia). Quando crei una risorsa, la crei in una regione precisa. Dentro ogni regione ci sono più zone di disponibilità, cioè data center fisicamente separati ma collegati tra loro a bassissima latenza.

Le conseguenze pratiche:

• La console mostra solo la regione selezionata. L'errore classico del principiante è creare qualcosa, cambiare regione senza accorgersene e credere che sia sparito. Non è sparito: è nell'altra regione, e continua a essere fatturato.
• Scegli la regione vicina ai tuoi utenti, perché la latenza è fisica.
• Alcuni servizi sono globali, non regionali: IAM, Route 53 e CloudFront tra questi.
• Le zone di disponibilità servono per l'alta affidabilità. Distribuire l'applicazione su più zone la rende resistente al guasto di un singolo data center, tipicamente con un load balancer davanti.

IAM e il privilegio minimo

IAM è il servizio che decide chi può fare cosa. È gratuito, è noioso, ed è quello che separa un account gestito bene da un incidente.

Le regole minime, in ordine di importanza:

Non usare l'utente root per lavorare. È l'account creato all'iscrizione: può fare qualsiasi cosa, compreso chiudere l'account. Attiva l'autenticazione a due fattori, crea un utente amministrativo separato e usa quello. Il root si tocca due volte l'anno.

Applica il privilegio minimo. Ogni utente, ruolo o applicazione riceve solo i permessi che gli servono. È tentante assegnare accesso completo per far funzionare le cose, ma diventa permanente: nessuno torna indietro a stringere i permessi.

Usa i ruoli, non le chiavi. Un'istanza EC2 o una Lambda che devono leggere da S3 non hanno bisogno di credenziali scritte da qualche parte: gli assegni un ruolo e AWS gestisce credenziali temporanee. Se ti servono chiavi, trattale come password e tienile fuori dal codice — vedi variabili d'ambiente.

Una chiave finita su un repository pubblico viene trovata in minuti, non in giorni. Esistono programmi automatici che scandagliano GitHub proprio per questo, e il conto di un account usato per minare criptovalute arriva a cifre a quattro zeri in un fine settimana.

Come non ricevere bollette a sorpresa

Questa è la sezione che conta più di tutte le altre messe insieme.

Imposta un budget con avviso il primo giorno

Prima di creare qualsiasi risorsa, vai in AWS Budgets e crea un budget mensile con una soglia bassa e un avviso via email. Non blocca nulla — AWS non spegne i servizi al superamento — ma ti fa scoprire il problema dopo tre giorni invece che dopo trenta. È la differenza tra un fastidio e un danno. Metti più soglie, e abilita gli avvisi sul piano gratuito nelle preferenze di fatturazione.

Capisci cosa c'è davvero nel piano gratuito

Il piano gratuito di AWS non è una cosa sola, sono tre tipi diversi mescolati nella stessa pagina, e questa è la trappola:

Tipo	Come funziona	Il rischio
Sempre gratuito	Una quota mensile che non scade mai	Bassa, ma la quota si può superare
12 mesi gratis	Gratuito per un anno dall'iscrizione	Alto: al tredicesimo mese inizi a pagare senza che nulla cambi
Prova a tempo	Gratuito per un periodo breve dall'attivazione	Media, spesso dimenticato

Il caso classico è la macchina EC2 lasciata accesa. Rientra nei dodici mesi, funziona benissimo, te ne dimentichi. Un anno dopo la fattura non è più zero senza che tu abbia cambiato niente: è scaduto il periodo. Segnati la data di iscrizione sul calendario.

Attenzione anche a cosa è gratis e cosa no dentro lo stesso servizio: un'istanza può rientrare nella quota, ma il disco allegato, l'IP statico non associato e gli snapshot sono fatturati a parte. Le risorse accessorie sopravvivono alla cancellazione di quella principale e continuano a costare.

Il traffico in uscita è la voce che sorprende tutti

Ricordati questa regola: su AWS i dati che entrano sono generalmente gratuiti, i dati che escono verso internet si pagano.

Sembra un dettaglio e invece è la voce che manda fuori strada i preventivi. Un'applicazione che serve immagini o video pesanti genera traffico in uscita continuo, e il conto cresce in proporzione al successo del progetto. Vale anche tra regioni diverse.

Tre cose che riducono il problema: metti una CDN davanti ai contenuti statici, così il grosso viene servito dalla cache; ottimizza le immagini, perché i byte trasferiti sono esattamente ciò che paghi; non spostare dati tra regioni senza un motivo preciso.

Le altre buone abitudini

• Attiva i tag sulle risorse e usa Cost Explorer per capire quale progetto sta spendendo cosa.
• Fai pulizia periodica. Volumi orfani, snapshot vecchi, IP non associati, bilanciatori di un esperimento finito: costano poco singolarmente e per sempre.
• Se segui un tutorial, cancella tutto alla fine.

L'onestà che serve: quando AWS non ti serve

Devo dirtelo chiaramente, perché quasi nessuno lo scrive: per un sito o un'applicazione piccola, AWS è quasi sempre la scelta sbagliata.

Non perché sia peggiore, ma perché il costo non è quello in fattura: è il tuo tempo. Su AWS anche una cosa semplice richiede di capire ruoli, gruppi di sicurezza e reti private, configurazioni che esistono per scenari molto più grandi del tuo. Passi giorni a fare infrastruttura invece che prodotto.

Le alternative sensate, per caso:

• Sito statico o frontend moderno: Vercel o Cloudflare Pages ti mettono online in minuti.
• Applicazione con backend e database: un VPS ben configurato o una piattaforma gestita, con una fattura prevedibile.
• Backend completo senza gestione: Supabase o Firebase risolvono database, autenticazione e archiviazione in un colpo.

AWS inizia ad avere senso quando hai requisiti che le piattaforme semplici non coprono, un team che sa amministrarlo, vincoli di conformità precisi, o quando lavori in un'azienda che è già lì. Impararlo resta un investimento professionale ottimo — è la competenza cloud più richiesta — ma impararlo e usarlo per il tuo blog sono due cose diverse.

In sintesi

AWS è un catalogo di servizi, non un prodotto. Non si impara tutto: si impara il pezzo che serve al problema che hai.

I servizi da conoscere all'inizio sono sette, non duecento: EC2, S3, RDS, Lambda, CloudFront, Route 53 e IAM.

Regioni e zone contano fin dal primo clic: le risorse vivono in una regione, e la console te ne mostra una sola alla volta.

IAM è l'unica cosa non rimandabile. Root con due fattori e mai usato, utenti separati, privilegio minimo, ruoli al posto delle chiavi.

Il budget con avviso va creato prima della prima risorsa, e le tre voci che sorprendono sono il piano gratuito che scade a dodici mesi, le risorse accessorie dimenticate accese e il traffico in uscita.

E se il progetto è piccolo, la risposta onesta è che AWS non ti serve. Meglio arrivarci quando hai un motivo, non per abitudine.

Per orientarti tra i grandi provider vedi AWS, Azure o Google Cloud, e per approfondire il servizio da cui quasi tutti iniziano cos'è S3.