Hai aperto la console AWS per la prima volta e ti sei sentito come davanti a un cruscotto di un aereo? Non sei solo. Ogni developer che si affaccia al cloud AWS parte da qui: account root, utenti IAM, regioni, e il primo servizio che fa qualcosa di concreto. Il problema è che senza metodo si rischia di lasciare la porta aperta — chiavi esposte, costi imprevisti, servizi in regioni sbagliate. Noi di Meteora Web lo vediamo spesso nei progetti che ci arrivano: credenziali root usate per lo sviluppo, bucket S3 pubblici per errore, tutto perché il primo passo non è stato fatto con ordine.
Questa guida ti porta dal click su "Crea account AWS" al tuo primo servizio funzionante, con sicurezza e consapevolezza. Niente fronzoli, solo quello che serve per partire con il piede giusto.
Perché account, IAM e regioni sono la base di tutto
Immagina di comprare un edificio per la tua azienda. La prima cosa che fai? Prendi le chiavi del portone principale e le dai a tutti i dipendenti. È esattamente ciò che succede se usi l'account root di AWS per operazioni quotidiane. L'account root ha poteri illimitati: può chiudere l'account, modificare fatturazione, cancellare risorse. Un errore e sei fuori.
Per questo AWS ha creato IAM (Identity and Access Management): un sistema per creare utenti, gruppi, ruoli e permessi granulari. Con IAM puoi dare a ogni developer solo ciò di cui ha bisogno. Un principio che noi applichiamo su ogni progetto: principio del minimo privilegio. Lo stesso che usiamo per i server dei nostri clienti.
Le regioni sono data center sparsi nel mondo. Scegliere quella sbagliata significa latenza più alta, costi maggiori o servizi non disponibili. Un cliente che vende in Italia con server in Singapore? Latenza inaccettabile. Noi consigliamo sempre eu-west-1 (Irlanda) o eu-south-1 (Milano) per chi opera in Italia.
Cosa fare subito dopo la registrazione
Prima di scrivere una riga di codice, segui questi passaggi:
- Attiva MFA sull'account root. Non si scappa. È il primo baluardo.
- Crea un utente IAM amministratore (ma non usare il nome "admin" — è il primo che cercano).
- Non usare mai le credenziali root per operazioni quotidiane. Mai.
- Scegli la regione primaria per i tuoi carichi di lavoro. Per l'Italia: eu-south-1 o eu-west-1.
Questo ti protegge da incidenti banali ma devastanti. Lo abbiamo visto: un tirocinante che cancella un bucket S3 perché aveva le chiavi root. Non succede più con IAM.
Creare un account AWS sicuro in 5 minuti
Il processo è semplice, ma attento ai dettagli. Vai su aws.amazon.com e clicca su Crea un account AWS. Ti servirà una carta di credito (per verifica) e un numero di telefono. AWS non ti addebita nulla per l'iscrizione, ma attenzione: alcuni servizi hanno un free tier limitato. Noi consigliamo di attivare subito i billing alerts per non ritrovarti con una sorpresa a fine mese.
Dopo la registrazione, la prima cosa è bloccare l'utente root:
# Simbolico: non esiste un comando CLI per abilitare MFA su root
# Vai su AWS Console > IAM > Users > root > Security credentials > Assign MFA device
aws iam create-user --user-name devops-lead
aws iam attach-user-policy --user-name devops-lead --policy-arn arn:aws:iam::aws:policy/AdministratorAccess
aws iam create-access-key --user-name devops-lead
create-access-key restituirà AccessKeyId e SecretAccessKey. Salvali in un posto sicuro — non nel codice! Usa variabili d'ambiente o AWS Secrets Manager. Noi vediamo ancora codice con chiavi hardcoded su GitHub. Un disastro.Dopo aver creato l'utente, configura AWS CLI sul tuo computer:
aws configure
AWS Access Key ID [None]: AKIA...
AWS Secret Access Key [None]: ...
Default region name [None]: eu-west-1
Default output format [None]: json
Ora sei pronto per lavorare con una identità sicura. Non dimenticare di abilitare MFA anche sull'utente IAM — è una buona pratica.
Regioni e Availability Zone: non sono solo parole
Una regione è un'area geografica (es. eu-west-1 = Irlanda). Ogni regione ha almeno tre Availability Zone (AZ) — data center isolati tra loro. Se costruisci un'applicazione distribuita su più AZ, ottieni alta disponibilità. Se scegli una regione sbagliata, paghi di più in trasferimento dati e latenza.
Per esempio: un sito web per utenti italiani. Se metti il server in us-east-1 (Virginia), il dato percorre l'Atlantico. Latenza ~100ms in più. Per un e-commerce, ogni millisecondo conta. Noi di Meteora Web per i clienti italiani usiamo sempre eu-south-1 (Milano) da quando è disponibile. La differenza è tangibile.
Alcuni servizi non sono disponibili in tutte le regioni. Verifica sempre su AWS Regional Services.
Come scegliere la regione giusta
- Vicinanza geografica ai tuoi utenti finali.
- Costi: alcune regioni sono più care (es. São Paulo).
- Servizi disponibili: non tutte le regioni hanno tutti i servizi (es. AWS Lambda con Graviton).
- Conformità normativa: GDPR richiede dati in EU? Scegli una regione EU.
Per iniziare, scegli eu-west-1 (Irlanda) o eu-south-1 (Milano). Sono le più vicine e complete.
Il primo servizio: EC2 o S3? Dipende
Il primo servizio che lanci simbolizza il tuo approccio al cloud. Due strade comuni:
- Amazon EC2: una macchina virtuale. Sei responsabile del sistema operativo, degli aggiornamenti, della sicurezza. È come avere un server fisico, ma virtualizzato.
- Amazon S3: storage di oggetti. Nessun server da gestire. Carichi file, assegni permessi, e via.
Noi consigliamo S3 come primo servizio perché è più facile da capire e non richiede gestione di sistema. Ma se hai bisogno di un server per un'applicazione, parti con EC2.
Lanciare un bucket S3 sicuro
Crea un bucket S3 con la CLI:
aws s3 mb s3://nome-bucket-unico-globalmente --region eu-west-1
Attenzione: il nome del bucket deve essere univoco a livello globale. Aggiungi una policy che blocca l'accesso pubblico (di default è bloccato, ma controlla):
aws s3api put-public-access-block --bucket nome-bucket-unico-globalmente --public-access-block-configuration "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"
Ora carica un file di test:
echo "Ciao, AWS!" > test.txt
aws s3 cp test.txt s3://nome-bucket-unico-globalmente/
Hai appena usato il tuo primo servizio AWS. S3 non è solo storage: è la base per hosting statico, backup, data lake e molto altro. Noi lo usiamo per gli asset dei clienti: immagini, video, static files. Riduce il carico sul server WordPress.
Lanciare un'istanza EC2 (se preferisci un server)
Se vuoi un server per sviluppare, usa la console o CLI. Ecco un esempio minimo:
aws ec2 run-instances --image-id ami-0abcdef1234567890 --instance-type t2.micro --key-name MyKeyPair --security-group-ids sg-12345678 --subnet-id subnet-12345678
Dovrai prima creare un key pair (per SSH) e un security group (firewall). Ma attenzione: t2.micro non è sempre free tier. Verifica che nella tua regione sia ancora incluso. Noi per i test usiamo t3.nano, più economico.
Un consiglio: dopo il lancio, termina l'istanza se non la usi. Ogni ora costa. Noi abbiamo visto clienti con 20 istanze dimenticate in esecuzione per mesi. Un conto salato.
Errori comuni quando si parte con AWS
- Usare l'account root per lo sviluppo. Mai.
- Esporre le chiavi IAM in repository pubblici. Usa
.gitignoree variabili d'ambiente. - Dimenticare i bucket S3 aperti. Verifica sempre con
aws s3api get-public-access-block. - Non attivare i billing alerts. Puoi impostarli in AWS Budgets.
- Lanciare servizi in regioni non vicine e pagare latenza e trasferimento dati inutili.
Noi di Meteora Web abbiamo automatizzato la configurazione iniziale per i nostri clienti: un CloudFormation template che crea account structure, utenti, budget e il primo bucket. Ma per iniziare, fare a mano ti dà consapevolezza.
Cosa fare adesso
- Registrati su AWS con un account personale (non aziendale, per test).
- Attiva MFA sull'utente root.
- Crea un utente IAM con permessi amministrativi e configura AWS CLI.
- Scegli la regione eu-south-1 o eu-west-1.
- Lancia il tuo primo servizio: un bucket S3 con un file di test.
- Imposta un budget alert di $10 per non sforare.
Poi esplora EC2, Lambda, o RDS. Ma ricorda: la sicurezza si costruisce dal primo passo. Noi lo ripetiamo sempre: un account AWS sicuro è come una fondazione solida per la tua applicazione. Se la fondazione è fragile, tutto il resto crolla.
Per approfondire, dai un'occhiata alla nostra guida DevOps: principi, cultura e da dove iniziare praticamente — l'approccio cloud si inserisce in un flusso DevOps solido. E se vuoi andare oltre con l'orchestrazione, leggi Kubernetes da zero.
Sponsored Protocol
