VPC: la rete AWS senza diventare network engineer
VPC spiegato con l'analogia del quartiere residenziale privato. Subnet pubbliche e private, route table, Internet Gateway e NAT Gateway: la rete AWS spiegata senza presupposti di networking avanzato.
VPC: la rete AWS senza diventare network engineer
VPC è dove inciampa metà degli studenti al SAA.
Non perché la rete sia difficile in sé, ma perché la maggior parte dei corsi la spiega come se tu avessi dieci anni di networking alle spalle. Subnet, CIDR, route table, NACL, Security Group, Internet Gateway, NAT Gateway, VPC peering, Transit Gateway, buttati in faccia tutti insieme nei primi venti minuti di video. Risultato: Francesco apre la console AWS, vede sette pannelli diversi sotto “VPC”, chiude il browser e si convince che il networking “non fa per lui”.
La buona notizia è che ti serve molto meno di quanto pensi. Per il Cloud Practitioner basta un concetto. Per il SAA bastano cinque. E tutti e cinque si capiscono in una sola immagine.
In questo articolo non ti spiego il networking. Ti spiego VPC: cos’è davvero, come sono fatte le subnet, chi decide dove va il traffico, e come diagnosticare i tre errori di rete più comuni. Senza giri di parole, e con un’analogia che ti porti dietro per sempre.
VPC è un quartiere recintato dentro AWS
Quando crei un account AWS, ricevi automaticamente accesso a una rete pubblica condivisa con milioni di altri utenti, l’infrastruttura globale di AWS. Su quella rete, di default, non puoi fare quasi nulla: tutto il traffico è isolato per account e per servizio. Per costruirci sopra un’applicazione vera (server, database, load balancer che si parlano tra loro), ti serve un tuo spazio di rete privato e dedicato. Quello spazio è la VPC, Virtual Private Cloud.
Pensala come un quartiere residenziale privato dentro una grande città.
La città è AWS. Il quartiere è la tua VPC. Lo recinti, gli dai un indirizzo (un blocco CIDR, tipo 10.0.0.0/16), e da quel momento è tuo. Solo tu decidi chi ci entra, chi può uscire, e dove vanno le strade. Tutto quello che metti dentro la VPC, istanze EC2, database RDS, container Fargate, Lambda configurate in VPC, diventa raggiungibile internamente con indirizzi IP privati, come case dello stesso quartiere che si parlano per la via di servizio.
Tre cose da fissare subito.
La VPC è regionale. Una VPC vive in una regione AWS (es. eu-south-1 per Milano). Non si estende automaticamente in altre regioni. Se ti servono risorse in più regioni, hai più VPC che poi colleghi.
La VPC è suddivisa in Availability Zone. Ogni regione ha tipicamente tre o più AZ, data center fisicamente separati nella stessa area geografica. Per costruire un’architettura ad alta disponibilità, “spalmi” la tua VPC su più AZ.
La VPC è gratuita. Crearla non costa nulla. Quello che paghi sono i componenti che ci metti dentro (istanze, NAT Gateway, indirizzi IP elastici riservati ma non usati). Questo è importante per chi sta facendo i primi esperimenti senza voler bruciare la prima bolletta.
L’errore mentale più comune è pensare la VPC come una “rete aziendale in cloud”, una specie di LAN remota. Non lo è. È un contenitore di rete configurabile dentro l’infrastruttura AWS. Il fatto che si comporti come una rete privata è un effetto della configurazione, non un’eredità del modello on-premise.
Subnet pubbliche e private: la regola d’oro
Dentro la VPC, le strade su cui camminano i pacchetti si chiamano subnet.
Una subnet è una porzione del tuo blocco CIDR di VPC, dedicata a un’Availability Zone. Esempio: se la VPC è 10.0.0.0/16, puoi creare la subnet 10.0.1.0/24 nell’AZ eu-south-1a e la subnet 10.0.2.0/24 nell’AZ eu-south-1b. Le risorse che lanci dentro una subnet vivono in quell’AZ e prendono un IP da quel range.
La distinzione fondamentale, sia per l’esame che per ogni architettura reale, è tra subnet pubbliche e subnet private.
Una subnet pubblica è una subnet che ha una rotta verso un Internet Gateway. Tradotto: le risorse che ci metti dentro possono essere raggiunte da internet (se hanno un IP pubblico) e possono uscire verso internet. Tipico abitante: un load balancer, un bastion host, un server web rivolto al pubblico.
Una subnet privata è una subnet che non ha una rotta verso un Internet Gateway. Le risorse che ci metti dentro non sono raggiungibili da internet e, di default, non possono nemmeno uscire. Tipico abitante: un database RDS, un application server interno, un microservizio raggiungibile solo da altri servizi della stessa VPC.
La regola d’oro: tutto ciò che non deve essere esposto a internet va in una subnet privata.
Ed è qui che cade il SAA di metà degli studenti. Domanda: “Dove dovrebbe stare il database di produzione?”. Risposta corretta: subnet privata. Quasi sempre. Anche se l’applicazione che lo legge è in una subnet pubblica. Anche se ti sembra “scomodo” perché poi non ti ci colleghi più via internet, è esattamente il punto, non deve essere raggiungibile via internet.
Pensa a un quartiere residenziale. Le strade che si affacciano sul viale principale sono le subnet pubbliche, chiunque dalla città può imboccarle. I vicoli ciechi interni sono le subnet private, esistono, hanno case dentro, ma da fuori non si vedono nemmeno. Il database è la cassaforte in cantina. Non la metti sulla strada del viale.
Un’architettura web tipica su AWS ha questa forma: load balancer in subnet pubblica → server applicativi in subnet privata → database in subnet privata (in un’AZ diversa per ridondanza). Tre layer, due tipi di subnet, replicati su almeno due AZ. Questo schema è il pattern di base che il SAA chiede continuamente in forme diverse.
Route table, Internet Gateway, NAT Gateway: chi fa cosa
A questo punto Francesco fa la domanda giusta: “Ma chi decide se una subnet è pubblica o privata? Cosa la rende tale?”
La risposta è una sola: la route table.
Una route table è una tabella di regole che dice, per ogni destinazione, dove mandare il traffico. Ogni subnet è associata a una route table. Le regole hanno la forma: “se il traffico è destinato all’IP X, mandalo verso Y”. Esempio reale per una subnet pubblica:
| Destinazione | Target |
|---|---|
| 10.0.0.0/16 | local (la VPC stessa) |
| 0.0.0.0/0 | igw-abc123 (Internet Gateway) |
La seconda riga è quella che fa la differenza. 0.0.0.0/0 significa “qualunque IP non già coperto da regole più specifiche”, cioè il resto di internet. E quella destinazione viene mandata verso un Internet Gateway.
L’Internet Gateway (IGW) è l’unico punto di uscita ufficiale dalla VPC verso internet. Lo crei una volta per VPC, lo “attacchi” alla VPC, e lo referenzi nelle route table delle subnet pubbliche. Funzionalmente è un router NAT distribuito e ridondante che AWS gestisce per te. Costo: zero, è incluso nella VPC.
Per le subnet private, la route table normalmente non ha la riga 0.0.0.0/0 → IGW. Solo la regola locale. Questo significa che le risorse nella subnet privata non possono uscire verso internet. Esattamente come vogliamo per un database.
Ma c’è un caso intermedio molto comune: una risorsa in subnet privata che deve poter scaricare aggiornamenti, chiamare un’API esterna, mandare email via SES. Deve poter uscire, ma non essere raggiungibile da fuori. Per questo serve il NAT Gateway.
Il NAT Gateway è un componente che metti in una subnet pubblica e che fa da intermediario per il traffico in uscita delle subnet private. La route table della subnet privata punta 0.0.0.0/0 al NAT Gateway, che a sua volta esce attraverso l’Internet Gateway. Il traffico esterno vede solo il NAT, non può iniziare una connessione verso le risorse private dietro.
Pensa al NAT Gateway come al portinaio del quartiere. Tu, dentro casa nel vicolo cieco, puoi chiamare l’esterno (ordini una pizza, chiami un servizio) e il portinaio ti gira la chiamata. Ma se uno da fuori chiama il portinaio chiedendo di te, non ti passa nessuno. Connessione in uscita sì, in entrata no.
Una cosa da sapere assolutamente per l’esame e per la bolletta: il NAT Gateway non è gratuito. Costa una tariffa oraria fissa per ogni AZ in cui lo metti, più una tariffa per ogni GB di dati che ci passa attraverso. È uno dei componenti che fa “esplodere” la prima bolletta AWS degli studenti che lasciano un’architettura accesa per giorni. Se stai sperimentando, ricordati di cancellarlo a fine giornata.
Ricapitolando il flusso del traffico nelle due direzioni:
- Subnet pubblica → internet: traffico esce direttamente via Internet Gateway. Traffico in entrata arriva al load balancer o all’IP pubblico dell’istanza.
- Subnet privata → internet: traffico esce via NAT Gateway → Internet Gateway. Traffico in entrata da internet è bloccato a livello di rete.
Tre componenti, due regole, una tabella. Questo è il 70% di ciò che ti chiede il SAA su VPC.
La diagnosi dei tre problemi di rete più comuni
Quando qualcosa non funziona in una VPC, l’errore è quasi sempre uno di tre. Imparare a riconoscerli sblocca metà del troubleshooting.
Problema 1, “La mia istanza EC2 non risponde da internet, eppure è in una subnet pubblica”.
Checklist veloce, in ordine: l’istanza ha un IP pubblico assegnato (non basta essere in subnet pubblica)? La route table della subnet ha effettivamente la regola 0.0.0.0/0 → IGW? Il Security Group dell’istanza permette il traffico in entrata sulla porta richiesta (di default i SG bloccano tutto in entrata)? La NACL (Network ACL) della subnet permette il traffico in entrata e in uscita? Nel 90% dei casi il colpevole è il Security Group dimenticato. Per la diagnosi sistematica del 10% rimanente, dai un’occhiata all’articolo su come diagnosticare un Access Denied, la logica del “controlla layer per layer” è la stessa.
Problema 2, “La mia Lambda non riesce a chiamare un’API esterna”. Quasi sicuramente la Lambda è configurata per girare in VPC (vedi anche l’articolo dedicato a Lambda) ma sta in una subnet privata senza NAT Gateway. Soluzioni: o sposti la Lambda fuori dalla VPC (se non le serve l’accesso a risorse private), o aggiungi un NAT Gateway alla VPC. Errore classico, e costa anche caro perché il NAT Gateway è a pagamento.
Problema 3, “Due risorse nella stessa VPC non si parlano”. Sono in subnet diverse? Le NACL di entrambe le subnet permettono il traffico tra i due range? I Security Group reciproci si autorizzano? Le subnet sono nella stessa AZ o in AZ diverse (cambia poco a livello di connettività, ma cambia la latenza)? Nel 95% dei casi il problema è di Security Group, non di routing, la route table locale della VPC autorizza già il traffico intra-VPC di default.
Una nota generale: i Security Group sono stateful (se autorizzi il traffico in uscita, le risposte tornano automaticamente), le NACL sono stateless (devi autorizzare esplicitamente sia inbound che outbound). Confondere i due livelli è la fonte di metà dei falsi positivi nella diagnosi. Regola pratica per il SAA: parti sempre dai Security Group. Le NACL servono come secondo strato di sicurezza, ma raramente sono il problema.
Domande frequenti su VPC
Quante VPC posso creare? Di default, AWS limita a 5 VPC per regione per account, ma il limite è alzabile su richiesta. Per progetti piccoli e medi, una sola VPC ben progettata è quasi sempre sufficiente. Più VPC servono per isolare ambienti (dev / staging / prod) o team.
Posso connettere due VPC tra loro? Sì, con tre meccanismi principali. VPC Peering per collegare due VPC punto a punto (semplice ma non transitivo). Transit Gateway per collegare molte VPC come un hub centrale (la scelta per architetture multi-VPC complesse). PrivateLink per esporre un singolo servizio di una VPC ad altre VPC senza dare accesso completo alla rete.
Cosa cambia tra Security Group e NACL? Il Security Group è una regola firewall a livello di risorsa (istanza, ENI, Lambda) ed è stateful. La NACL è una regola a livello di subnet ed è stateless. In pratica: i SG sono il primo strumento da usare e sono sufficienti nel 95% dei casi; le NACL si toccano solo per scenari particolari o di compliance.
Cos’è un VPC Endpoint? È un modo per accedere ad altri servizi AWS (S3, DynamoDB, e molti altri) direttamente dalla VPC, senza passare da internet. Utile per ragioni di sicurezza (il traffico non lascia mai la rete AWS) e di costo (eviti il traffico attraverso il NAT Gateway). Per S3 esiste anche un endpoint “gateway” gratuito, usalo se le tue istanze parlano molto con S3.
Una Lambda dentro una VPC ha cold start più lento? Sì, anche se la differenza si è ridotta molto rispetto al passato. Oggi una Lambda in VPC parte solo qualche centinaio di millisecondi più lentamente di una Lambda non-in-VPC. Mettila in VPC solo se le serve davvero accedere a risorse private (un RDS, una ElastiCache, una EC2 interna).
Come gestisco la rete tra più Availability Zone? La VPC è regionale, quindi copre già tutte le AZ. Quello che fai è creare almeno una subnet per AZ dove vuoi essere presente, e disegnare il sistema in modo che ogni layer sia replicato su più AZ. Una buona architettura web di base ha sei subnet (una pubblica e una privata per ognuna di tre AZ).
Posso usare la stessa VPC per dev e prod? Tecnicamente sì, isolando con subnet, SG e NACL. Praticamente sconsigliato: la separazione fisica tra VPC è uno strato di sicurezza in più che ti evita errori catastrofici (es. un comando sbagliato che cancella istanze di produzione perché credi siano dev). Una VPC per ambiente è il pattern di base.
VPC non è una “rete in cloud” e non richiede dieci anni di networking. Richiede di tenere a mente cinque concetti: VPC come quartiere, subnet come strade, route table come cartelli stradali, Internet Gateway come ingresso dalla città, NAT Gateway come portinaio. Tutto il resto, endpoint, peering, transit, NACL avanzate, sono dettagli che si aggiungono solo quando un’architettura cresce.
Per il Cloud Practitioner, ti basta sapere cos’è una VPC e la distinzione tra subnet pubbliche e private. Per il SAA, vanno aggiunti route table, IGW, NAT Gateway, Security Group vs NACL e qualche caso di endpoint. Per il professional, c’è un mondo. Ma il fondamentale è quello che hai appena letto.
Se stai costruendo le basi per il Cloud Practitioner, il Cloud Practitioner Starter Kit include una sezione “Networking essentials” che riprende esattamente questa logica per arrivare pronto all’esame. Gratis, dieci minuti.
Se sei già su un percorso più strutturato, il corso AWS Cloud Practitioner CLF-C02 in italiano tratta VPC con la stessa progressione: analogia del quartiere prima, componenti dopo, troubleshooting al fondo.
E se la tua tappa successiva è il SAA, il networking è uno dei domini dove si gioca il maggior numero di punti, l’articolo sulla preparazione al SAA-C03 in 60 giorni ti dice in che ordine affrontarlo nel piano di studio.
Una VPC è un quartiere recintato. Le strade le decidi tu. I cartelli stradali li scrivi tu. L’ingresso lo apri tu, o lo lasci chiuso. Tutto il resto è solo questione di tenere a mente chi fa cosa.
Ti è stato utile questo articolo? Condividilo con il collega che continua a confondere Security Group e NACL davanti alla console, l’analogia del quartiere gli sblocca tutto in cinque minuti.