Hai mai lanciato un'istanza EC2, convinto di aver scelto il tipo giusto, e un mese dopo ti sei ritrovato con una fattura del 40% più alta del previsto? Oppure hai esposto un server su internet con la porta SSH aperta a tutto il mondo e una settimana dopo hai trovato un crypto miner al posto dei tuoi processi? Succede più spesso di quanto pensi. Noi, di Meteora Web, in anni di lavoro su infrastrutture AWS abbiamo visto decine di casi in cui bastava conoscere meglio questi quattro elementi — tipo di istanza, AMI, security group e key pair — per evitare costi inutili, falle di sicurezza e ore di debugging. Questa guida ti porta dentro ciascuno di essi, con esempi reali e comandi che puoi eseguire subito.
Scegliere il tipo di istanza giusto
EC2 offre decine di famiglie di istanze. Il problema è che molte partono con il default (t2.micro gratis per il primo anno) e poi si accorgono che per un carico di produzione serve ben altro. La scelta sbagliata impatta direttamente sul budget: un'istanza memory-optimized per un web server leggero è come comprare un autocarro per portare la spesa.
Famiglie di istanze: a cosa servono
Le famiglie si dividono per carico di lavoro:
- General purpose (A/T/M) – bilanciate tra CPU, RAM e rete. Ideali per web server, ambienti di sviluppo, piccoli database.
- Compute optimized (C) – molta potenza CPU, poca RAM. Per batch processing, rendering, machine learning training.
- Memory optimized (R/X) – tanta RAM, CPU sufficiente. Database in-memory (Redis, Memcached), SAP, analisi grandi dataset.
- Storage optimized (I/D) – SSD NVMe ad alta velocità. Database transazionali, data warehousing.
- GPU (P/G) – per rendering 3D, deep learning, transcodifica video.
Come leggere il nome dell'istanza
Prendiamo c6g.2xlarge:
c= famiglia compute optimized6= generazione (6a è AMD, 6g è ARM Graviton)g= processore ARM (Graviton). Se manca = Intel;a= AMD2xlarge= dimensione (micro, small, medium, large, xlarge, 2xlarge...)
Usare AWS CLI per testare i tipi disponibili
Prima di lanciare un'istanza, esplora i tipi nella tua regione:
aws ec2 describe-instance-types --filters "Name=instance-type,Values=m5.*" --query "InstanceTypes[].[InstanceType, VCpuInfo.DefaultVCpus, MemoryInfo.SizeInMiB]" --output tablePer vedere i prezzi in tempo reale (es. per regione eu-west-1):
aws pricing get-products --service-code AmazonEC2 --filters "Type=TERM_MATCH,Field=instanceType,Value=t3.medium" "Type=TERM_MATCH,Field=regionCode,Value=eu-west-1" | jq '.PriceList[]'Attenzione alle istanze burstable (t2/t3/t4g)
Queste accumulate crediti CPU quando sono in idle e li consumano quando il carico sale. Perfette per ambienti di test o siti a basso traffico. Se il tuo carico è costante al 40% per ore, i crediti finiscono e l'istanza viene throttolata. In quel caso passa a una general purpose (m5/m6i).
AMI – il sistema operativo su misura
L'Amazon Machine Image è lo snapshot di un sistema configurato. Scegliere l'AMI giusta significa risparmiare ore di configurazione e avere un ambiente sicuro dalla prima accensione.
Tipi di AMI
- Pubbliche: fornite da AWS (Amazon Linux, Windows Server) o dalla community (Ubuntu, Debian, CentOS).
- Marketplace: con software preinstallato (es. WordPress, LAMP, SAP).
- Personalizzate: create da te partendo da un'istanza esistente. Questa è la scelta migliore per ambienti di produzione: hai esattamente i pacchetti e le configurazioni che servono.
Creare una AMI personalizzata da CLI
Supponiamo di aver configurato un'istanza con nginx, PHP e un'app Laravel. Vogliamo immortalarla:
aws ec2 create-image --instance-id i-0abcdef1234567890 --name "laravel-prod-2026-03-01" --no-rebootIl flag --no-reboot evita il riavvio forzato, ma per coerenza del filesystem meglio fermare l'istanza prima di creare l'AMI. Poi puoi lanciare nuove istanze da questa AMI in pochi secondi.
Consigli pratici
- Amazon Linux 2023 è ottimizzato per AWS (kernel tuned, integrazione con Systems Manager).
- Ubuntu 24.04 LTS ha pacchetti più recenti per applicazioni moderne.
- Mantieni le AMI aggiornate: ogni mese rilancia l'immagine con gli ultimi patch di sicurezza.
- Assegna tag alle AMI con versione e data, per sapere qual è l'ultima.
Security Group – il firewall dell'istanza
I security group sono firewall stateful a livello di istanza. Ogni regola inbound deve essere giustificata. Noi vediamo sempre lo stesso errore: SSH aperto a 0.0.0.0/0 (tutto il mondo) “tanto poi cambio”. Lo cambierai dopo il primo tentativo di brute force, se sei fortunato.
Regole stateful: cosa significa
Se permetti inbound sulla porta 80, l'outbound per la risposta è permesso automaticamente. Non devi creare regole simmetriche. Attenzione però: l'outbound di default è tutto permesso. Per ambienti sensibili, limita l'outbound solo a ciò che serve (es. solo verso internet per aggiornamenti, verso RDS per database).
Esempio di security group per un web server
Creiamo un security group chiamato web-sg con AWS CLI:
aws ec2 create-security-group --group-name web-sg --description "Security group for web servers" --vpc-id vpc-12345
# SSH solo da IP aziendale
aws ec2 authorize-security-group-ingress --group-id sg-abc123 --protocol tcp --port 22 --cidr 203.0.113.0/24
# HTTP e HTTPS da tutto il mondo
aws ec2 authorize-security-group-ingress --group-id sg-abc123 --protocol tcp --port 80 --cidr 0.0.0.0/0
aws ec2 authorize-security-group-ingress --group-id sg-abc123 --protocol tcp --port 443 --cidr 0.0.0.0/0
# (Opzionale) Outbound solo per aggiornamenti
aws ec2 authorize-security-group-egress --group-id sg-abc123 --protocol tcp --port 443 --cidr 0.0.0.0/0Errori comuni da evitare
- Porta 22 (SSH) aperta a 0.0.0.0/0. Usa un IP fisso o un bastion host.
- Applicare lo stesso security group a tutte le istanze senza distinguere i ruoli (web, database, admin).
- Dimenticare di rimuovere regole vecchie dopo aver cambiato VPN o indirizzo IP.
- Usare il default VPC security group che di solito è troppo permissivo.
Key Pair – la tua unica chiave d'accesso
Le key pair (coppie di chiavi RSA o ED25519) sono il metodo standard per accedere via SSH alle istanze Linux. Perdi la chiave privata? Perdi l'accesso all'istanza. Nessun recovery via console, a meno che non abbia predisposto un meccanismo alternativo (ad esempio Session Manager).
Creare un key pair
Da console AWS:
- Vai a EC2 → Key Pairs → Create key pair
- Scegli il formato (PEM per OpenSSH, PPK per PuTTY)
- Scarica immediatamente la chiave privata. Amazon non la conserva.
Oppure via CLI:
aws ec2 create-key-pair --key-name mio-key --key-type rsa --output text > mio-key.pem
chmod 400 mio-key.pemPuoi anche importare una chiave pubblica esistente:
aws ec2 import-key-pair --key-name mio-key-import --public-key-material fileb://~/.ssh/id_rsa.pubBuone pratiche per la gestione
- Permessi 400 sulla chiave privata (solo lettura per l'utente).
- Mai condividere la chiave privata via email o chat. Usa password manager o vault.
- Usa chiavi diverse per ogni ambiente (dev, staging, prod).
- Aggiungi Session Manager (SSM) come backdoor: così se perdi la chiave puoi comunque accedere tramite IAM.
- Rigenera le chiavi periodicamente (almeno una volta all'anno).
In sintesi — cosa fare adesso
- Analizza il tuo carico di lavoro prima di scegliere il tipo di istanza. Usa CloudWatch o un semplice benchmark per capire se hai bisogno di più CPU, RAM o I/O.
- Costruisci una AMI personalizzata per il tuo ambiente di produzione. Automatizza con Packer o semplicemente con create-image dopo ogni aggiornamento.
- Blocca SSH a un IP specifico nel security group. Se lavori in team, usa un bastion host o una VPN.
- Applica il principio del minimo privilegio anche alle porte outbound: non permettere tutto il traffico in uscita se non serve.
- Proteggi le chiavi private con permessi 400 e un backup crittografato. Prepara un piano di recovery (SSM) per non rimanere fuori.
Se vuoi approfondire come gestire i permessi degli utenti e delle risorse AWS, leggi la nostra guida su IAM AWS: Least Privilege e Policy Management. E ricorda: un'istanza EC2 non è solo un server virtuale — è il tuo patrimonio digitale. Trattalo come tale.
Sponsored Protocol
