Architettura VPC e blocchi CIDR

Una Amazon Virtual Private Cloud (VPC) è una rete privata logicamente isolata all'interno di una Regione AWS, che Lei definisce e controlla. Ogni account AWS include una VPC predefinita (CIDR 172.31.0.0/16) in ogni Regione, ma le architetture di produzione utilizzano sempre VPC personalizzate. Una VPC si estende a tutte le Availability Zone della relativa Regione e offre il pieno controllo sull'indirizzamento IP, sulle subnet, sulle tabelle di routing, sui gateway Internet e sulla sicurezza. Le risorse all'interno di una VPC sono isolate dalle altre VPC e da Internet, a meno che non configuri esplicitamente la connettività.

Un blocco CIDR (Classless Inter-Domain Routing) definisce l'intervallo di indirizzi IP di una VPC o di una subnet utilizzando il formato x.x.x.x/prefix. La lunghezza del prefisso determina il numero di indirizzi IP nell'intervallo: /16 = 65.536 indirizzi, /24 = 256 indirizzi, /28 = 16 indirizzi (dimensione minima di una subnet su AWS). Per le VPC, AWS consente blocchi CIDR da /16 (il più grande) a /28 (il più piccolo). Scelga un CIDR VPC che: (1) non si sovrapponga alle reti on-premises (per future connessioni VPN/Direct Connect), (2) sia abbastanza grande per le subnet pianificate e (3) utilizzi lo spazio di indirizzi privati RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).

Una subnet è un segmento dell'intervallo di indirizzi IP di una VPC che risiede in una singola Availability Zone. Le subnet sono classificate come pubbliche (dispongono di una route verso un gateway Internet) o private (non dispongono di una route diretta verso Internet). Una best practice per una tipica architettura a 3 livelli consiste nel creare almeno tre livelli di subnet: public (load balancer, bastion host), private-app (istanze EC2, task ECS) e private-data (RDS, ElastiCache), replicando ogni livello in almeno due AZ per garantire l'alta disponibilità.

Un layout CIDR comune per una VPC con CIDR 10.0.0.0/16 distribuita su due AZ e tre livelli è il seguente: Public AZ-a: 10.0.1.0/24; Public AZ-b: 10.0.2.0/24; Private-App AZ-a: 10.0.10.0/24; Private-App AZ-b: 10.0.11.0/24; Private-Data AZ-a: 10.0.20.0/24; Private-Data AZ-b: 10.0.21.0/24. Questo layout lascia spazio per aggiungere subnet AZ-c (10.0.3.0/24, 10.0.12.0/24, 10.0.22.0/24) senza riprogettare l'intero schema CIDR. Progetti sempre tenendo conto della crescita futura.

AWS riserva i primi quattro e l'ultimo indirizzo IP in ogni subnet. Per una subnet 10.0.1.0/24: 10.0.1.0 (rete), 10.0.1.1 (router VPC), 10.0.1.2 (DNS/DHCP), 10.0.1.3 (uso futuro) e 10.0.1.255 (broadcast). Una subnet /24 dispone di 256 IP totali, meno 5 riservati, per un totale di 251 IP utilizzabili. Una subnet /28, la dimensione minima, dispone di 16 IP, meno 5, per un totale di 11 utilizzabili. Questo aspetto è importante quando dimensiona le subnet in base al numero di risorse, come istanze EC2 e funzioni Lambda con VPC, che prevede di distribuire.

È possibile aggiungere fino a quattro blocchi CIDR secondari a una VPC esistente senza ricrearla. Questa soluzione è utile quando il CIDR primario è esaurito (tutte le subnet sono piene) o quando è necessario aggiungere spazio di indirizzamento da un intervallo RFC 1918 diverso per un caso d'uso specifico, ad esempio il networking dei pod Kubernetes. I CIDR secondari sono soggetti ad alcune restrizioni: ad esempio, non è possibile aggiungere un CIDR sovrapposto e non è possibile utilizzare determinati intervalli pubblici non RFC 1918. Pianifichi attentamente il dimensionamento del CIDR della VPC fin dall'inizio, per ridurre al minimo la necessità di CIDR secondari.

VPC Peering stabilisce una connessione di rete privata tra due VPC, in modo che le relative risorse possano comunicare utilizzando indirizzi IP privati. Le VPC con peering possono appartenere allo stesso account, ad account diversi o persino a Regioni diverse (peering inter-regionale). Requisiti: i CIDR delle due VPC non devono sovrapporsi. Limitazioni: il peering è non transitivo: se VPC-A ha un peering con VPC-B e VPC-B ha un peering con VPC-C, VPC-A non può comunicare con VPC-C attraverso VPC-B. Per ottenere una connettività a maglia completa tra molte VPC, utilizzi invece AWS Transit Gateway.

AWS Transit Gateway (TGW) funge da hub di rete centrale, ovvero da router cloud, che connette più VPC, VPN e connessioni Direct Connect. Invece di creare N*(N-1)/2 connessioni VPC peering per una maglia completa di N VPC, colleghi ogni VPC e connessione al Transit Gateway, che instrada il traffico tra di esse. TGW supporta tabelle di routing che consentono di controllare quali collegamenti possono comunicare tra loro, permettendo la segmentazione della rete (ad esempio, isolando le VPC di produzione dalle VPC di sviluppo sullo stesso TGW).

Due impostazioni DNS controllano la risoluzione dei nomi in una VPC. enableDnsSupport: quando è impostato su true (valore predefinito), la VPC utilizza il resolver DNS fornito da AWS all'indirizzo 169.254.169.253 o al secondo indirizzo IP del CIDR della VPC (ad esempio, 10.0.0.2 per 10.0.0.0/16). enableDnsHostnames: quando è impostato su true (deve essere abilitato per le VPC personalizzate, mentre è attivo per impostazione predefinita nella VPC predefinita), le istanze EC2 nella VPC ricevono nomi host DNS come ip-10-0-1-15.ec2.internal. Entrambe le impostazioni devono essere abilitate affinché le Route 53 Private Hosted Zones funzionino all'interno della VPC.

VPC Flow Logs acquisisce i metadati relativi al traffico di rete che attraversa la VPC: IP di origine e destinazione, porta, protocollo, byte trasferiti e indicazione che il traffico sia stato accettato o rifiutato. I log dei flussi possono essere pubblicati in CloudWatch Logs (per le query con Logs Insights) o in S3 (per l'analisi con Athena). Sono fondamentali per le analisi forensi di sicurezza (chi si è connesso a cosa), l'analisi del traffico (per identificare i flussi ad ampia larghezza di banda) e la risoluzione dei problemi (perché una connessione è stata rifiutata?). I log dei flussi operano a livello di VPC, subnet o singola ENI.

Prima di creare una VPC, pianifichi tutte le esigenze future di connettività: connettività con la rete on-premises (VPN o Direct Connect): si assicuri che il CIDR della VPC non si sovrapponga alle subnet on-premises; connettività tra VPC (peering o Transit Gateway): pianifichi CIDR non sovrapposti in tutte le VPC dell'organizzazione; accesso ai servizi AWS (endpoint VPC per S3, DynamoDB e SSM, per evitare che il traffico passi da Internet); e dimensionamento delle subnet: lasci spazio sufficiente in ogni subnet per il consumo di indirizzi IP da parte dei pod EKS, delle funzioni Lambda e delle interfacce di rete elastiche.

Verifichi la Sua comprensione dei concetti AWS Solutions Architect (SAA-C03) trattati in questa lezione.

In questa lezione ha imparato che: una VPC è una rete logicamente isolata in una Regione, definita da un blocco CIDR che viene suddiviso in subnet pubbliche e private distribuite tra le AZ; AWS riserva 5 IP in ogni subnet, quindi deve sempre dimensionare le subnet tenendo conto di questa riduzione; e VPC Peering e Transit Gateway connettono privatamente le VPC, ma gli intervalli CIDR non devono sovrapporsi. Prossimamente esamineremo gli Internet Gateway e le tabelle di routing.