Il tuo team ha appena spinto in produzione un servizio su EC2 e il giorno dopo qualcuno ti chiama perché la dashboard è irraggiungibile. Controlli i log: il database è esposto su una porta pubblica, un security group aperto a 0.0.0.0/0 e il tutto vive in una subnet che non doveva essere pubblica. Non è uno scenario raro: lo vediamo spesso quando un progetto cresce in fretta e il networking AWS viene improvvisato. Se stai leggendo, probabilmente hai già un assaggio del problema: la VPC di default non è pensata per la produzione, e le subnet private non sono private per magia, ma per configurazione.
Questa guida parte dal problema concreto: come progettare una VPC che separi davvero ciò che deve essere pubblico da ciò che deve restare interno, e come usare i security group senza trasformarli in un colabrodo. Niente teoria accademica: subnet, route table, internet gateway, NAT gateway e security group spiegati con esempi reali, comandi da copiare e una checklist finale per non sbagliare.
Perché la VPC di Default Non Va Bene per la Produzione?
Quando crei un account AWS, la VPC di default ti dà tutto subito: subnet in ogni availability zone, internet gateway collegato, route table configurate. Sembra comodo, ma è una trappola. Ogni istanza che lanci in quella VPC ha un indirizzo pubblico e una route verso internet. Il database, il backend, il frontend: tutto raggiungibile dall'esterno se il security group lo permette. E spesso lo permette, perché chi ha fretta apre le porte e pensa di chiuderle dopo.
Noi, di Meteora Web, ragioniamo da ex contabili: se un errore di configurazione ti costa un data breach, il prezzo non è solo tecnico, è economico. La VPC di default è come un ufficio con una sola porta aperta su strada: funziona finché non entra qualcuno che non dovrebbe. In produzione, la VPC va progettata come un edificio con zone distinte: reception pubblica, uffici interni, caveau.
Sponsored Protocol
Come Funzionano le Subnet Pubbliche e Private in AWS?
La differenza tra una subnet pubblica e una privata non è una proprietà intrinseca della subnet stessa, ma della sua route table. Una subnet è pubblica se la sua route table ha una rotta verso 0.0.0.0/0 che punta a un internet gateway. È privata se quella rotta punta a un NAT gateway o non c'è proprio. Sembra banale, ma è il concetto che sblocca tutto il resto.
Esempio pratico: hai un web server che deve ricevere traffico HTTPS da internet, e un database che deve parlare solo con il web server. Il web server va in una subnet pubblica, con un internet gateway nella route table. Il database va in una subnet privata, senza rotta verso internet. Se qualcuno prova a raggiungere il database dall'esterno, non ci riesce: non esiste un percorso di rete, non è una questione di firewall.
# Creare una VPC con due subnet pubbliche e due private (us-east-1)
aws ec2 create-vpc --cidr-block 10.0.0.0/16
# Annota il VpcId, poi crea le subnet
aws ec2 create-subnet --vpc-id vpc-xxxx --cidr-block 10.0.1.0/24 --availability-zone us-east-1a
aws ec2 create-subnet --vpc-id vpc-xxxx --cidr-block 10.0.2.0/24 --availability-zone us-east-1b
aws ec2 create-subnet --vpc-id vpc-xxxx --cidr-block 10.0.10.0/24 --availability-zone us-east-1a
aws ec2 create-subnet --vpc-id vpc-xxxx --cidr-block 10.0.11.0/24 --availability-zone us-east-1b
# Le prime due saranno pubbliche, le seconde private. La differenza la fai dopo, con le route table.Come Configurare un Internet Gateway e un NAT Gateway nella VPC?
L'internet gateway è il punto di ingresso e uscita verso il mondo. Senza di lui, niente traffico pubblico. Il NAT gateway, invece, è l'uscita controllata per le risorse private: permette alle istanze in subnet private di fare aggiornamenti di sistema o chiamate API verso l'esterno, ma impedisce a chiunque dall'esterno di iniziarle. È un concetto che i nostri clienti faticano a capire all'inizio: il database può scaricare pacchetti, ma non può essere contattato. Come un ufficio che può spedire posta, ma non riceverne.
Sponsored Protocol
Passaggi Pratici per Collegare le Subnet Pubbliche a Internet
Prima di tutto, crea un internet gateway e attaccalo alla VPC. Poi modifica la route table associata alle subnet pubbliche, aggiungendo una rotta 0.0.0.0/0 verso l'IGW. Per le subnet private, crea un NAT gateway in una subnet pubblica (deve avere un IP elastico) e aggiungi una rotta 0.0.0.0/0 verso il NAT nella route table privata. Attenzione: il NAT gateway costa, circa 32 dollari al mese. Se il budget è un problema, puoi usare un'istanza NAT self-managed, ma noi preferiamo il gateway gestito: meno manutenzione, meno rischi.
# Creare un Internet Gateway e associarlo alla VPC
aws ec2 create-internet-gateway
aws ec2 attach-internet-gateway --internet-gateway-id igw-xxxx --vpc-id vpc-xxxx
# Creare una route table pubblica e aggiungere la rotta verso l'IGW
aws ec2 create-route-table --vpc-id vpc-xxxx
aws ec2 create-route --route-table-id rtb-xxxx --destination-cidr-block 0.0.0.0/0 --gateway-id igw-xxxx
# Associare la route table alle subnet pubbliche
aws ec2 associate-route-table --route-table-id rtb-xxxx --subnet-id subnet-xxxxCome Usare i Security Group per Proteggere le Istanze EC2?
I security group sono il firewall virtuale a livello di istanza. Funzionano come un buttafuori: decidono chi entra e chi esce, ma solo se configurati bene. Il problema è che molti li trattano come una lista della spesa: aprono porte a caso, usano 0.0.0.0/0 per tutto, e poi si chiedono perché arrivano attacchi. La regola d'oro è il principio del minimo privilegio: apri solo ciò che serve, solo verso chi serve.
Un errore comune che vediamo nei progetti che ci arrivano: il security group del database aperto a 0.0.0.0/0 sulla porta 3306. Bastano pochi minuti con uno scanner per trovare database MySQL esposti su internet. Il modo corretto è riferirsi al security group del web server, non all'IP. In questo modo, solo le istanze con quel security group possono parlare con il database, indipendentemente dall'IP che hanno.
Sponsored Protocol
Come Referenziare un Security Group da un Altro per il Database
Supponiamo di avere un'istanza web con security group sg-web e un database con security group sg-db. Sul sg-db, apri la porta 3306 solo per il traffico in ingresso proveniente da sg-web. Non serve sapere l'IP del web server: AWS risolve la relazione a livello di gruppo. Se il web server cambia IP, la regola continua a funzionare. Questo è il modo professionale di gestire il traffico interno.
# Aggiungere una regola al security group del database
aws ec2 authorize-security-group-ingress \
--group-id sg-db \
--protocol tcp \
--port 3306 \
--source-group sg-web
# Solo le istanze con sg-web possono raggiungere il database sulla 3306Quali Errori Evitare nella Progettazione della VPC?
Il primo errore è non pianificare il CIDR. Usare 10.0.0.0/16 va bene, ma se in futuro devi fare peering con un'altra VPC e i range si sovrappongono, hai un problema serio. Scegli un range ampio ma non troppo, e lascia spazio per crescere. Il secondo errore è dimenticare i VPC endpoints: per servizi come S3 o DynamoDB, puoi evitare il traffico via internet usando un endpoint di gateway o di interfaccia. Costa meno, è più sicuro e riduce la latenza.
Il terzo errore è non testare mai la configurazione. Crei la VPC, lanci le istanze, e scopri solo in produzione che il NAT gateway non funziona o che il security group blocca il traffico legittimo. Noi testiamo sempre con un'istanza di prova: lanci una macchina in una subnet privata, provi a fare un ping verso un IP pubblico e verifichi che il traffico passi dal NAT. Se non funziona, lo scopri prima, non dopo.
Sponsored Protocol
Come Testare la Connettività di una Subnet Privata
Lancia un'istanza in una subnet privata, collegati via Session Manager (non serve una chiave SSH pubblica) e prova a raggiungere internet. Se il NAT è configurato bene, il comando ping funziona. Se no, controlla le route table e assicurati che il NAT sia in una subnet pubblica con un IP elastico associato. Un dettaglio che molti dimenticano: il NAT gateway deve avere una rotta verso internet, altrimenti non può inoltrare il traffico.
# Da una istanza in subnet privata, testa la connettività
ping -c 4 8.8.8.8
# Se non risponde, controlla le route table della subnet privata
aws ec2 describe-route-tables --route-table-ids rtb-privataCome Ridurre i Costi della VPC senza Compromettere la Sicurezza?
Il NAT gateway è il componente più costoso della VPC, ma puoi ridurre i costi usando un'istanza NAT self-managed su una piccola EC2. Costa meno, ma richiede manutenzione: devi gestire gli aggiornamenti e la disponibilità. In alternativa, per carichi di lavoro non critici, puoi eliminare del tutto il NAT e usare i VPC endpoints per i servizi AWS. Se il tuo traffico verso internet è minimo, un NAT gateway è uno spreco.
Un'altra strategia è consolidare le risorse: non serve una VPC per ambiente di sviluppo e una per produzione se puoi usare subnet diverse nella stessa VPC. Noi lo facciamo spesso per i clienti con budget limitato: stessa VPC, subnet separate, security group diversi. Il rischio di contaminazione è basso se le regole sono chiare e documentate.
Come Usare i VPC Endpoints per Ridurre il Traffico verso Internet
Per S3 e DynamoDB, crea un endpoint di gateway. È gratuito e instrada il traffico direttamente sulla rete AWS, senza passare da internet. Per altri servizi come EC2 API o Systems Manager, usa un endpoint di interfaccia: costa qualche centesimo all'ora, ma elimina la necessità di un NAT per quelle chiamate. Il risultato è una VPC più sicura e più economica.
Sponsored Protocol
# Creare un VPC endpoint per S3 (gateway endpoint)
aws ec2 create-vpc-endpoint \
--vpc-id vpc-xxxx \
--service-name com.amazonaws.us-east-1.s3 \
--route-table-ids rtb-privata
# Il traffico verso S3 ora passa dalla rete AWS, non da internetCosa fare adesso
Se stai gestendo una VPC di default o una configurazione improvvisata, non aspettare che qualcosa si rompa. Ecco le azioni concrete da fare subito:
1. Audit delle route table: controlla ogni subnet e verifica che le route verso 0.0.0.0/0 puntino solo dove devono. Se trovi una subnet privata con una rotta verso l'internet gateway, correggila.
2. Rivedi i security group: cerca regole con 0.0.0.0/0 su porte non HTTP/HTTPS. Se trovi il database aperto al mondo, chiudilo e referenzia il security group dell'applicazione.
3. Testa la connettività: lancia un'istanza in una subnet privata e verifica che il NAT funzioni. Se non hai un NAT, decidi se crearne uno o usare i VPC endpoints.
4. Documenta la configurazione: scrivi un diagramma della VPC con subnet, route table e security group. Se qualcuno deve intervenire, deve capire la struttura in cinque minuti.
5. Approfondisci con la nostra guida pillar: se vuoi il quadro completo sull'infrastruttura AWS, parti dalla guida pillar su AWS per sviluppatori e poi torna qui per i dettagli sulla VPC.
La VPC non è un dettaglio tecnico: è la base su cui poggia la sicurezza di tutto il tuo stack. Sbagliare qui significa esporre i dati dei clienti, e il prezzo non è solo tecnico, è reputazionale ed economico. Noi lo sappiamo bene: veniamo dalla contabilità, e i numeri non mentono mai.
