NAT gateway e subnet private

Le risorse nelle subnet private dispongono solo di indirizzi IP privati e non hanno alcuna route verso un Internet Gateway, quindi non possono avviare connessioni in uscita verso Internet. Tuttavia, spesso hanno bisogno di raggiungere Internet per scaricare patch del sistema operativo, estrarre immagini Docker, chiamare API di terze parti o aggiornare il software. La soluzione consiste nell'instradare il traffico delle subnet private attraverso un dispositivo che dispone dell'accesso a Internet ed esegue la NAT (Network Address Translation), nascondendo gli IP privati dietro un IP pubblico. AWS offre due opzioni: NAT Gateway (gestito) e NAT Instance autogestita (legacy).

Un NAT Gateway è un servizio completamente gestito e ad alta disponibilità che consente alle istanze nelle subnet private di avviare connessioni in uscita verso Internet, bloccando al contempo il traffico in entrata non richiesto. Risiede in una subnet pubblica, dispone di un Elastic IP e raggiunge automaticamente una larghezza di banda fino a 100 Gbps. Non è necessario applicare patch, dimensionare o gestire l'infrastruttura sottostante. Il NAT Gateway traduce l'IP privato di origine dei pacchetti in uscita nel proprio EIP, quindi restituisce le risposte all'IP privato originale.

Dopo aver creato un NAT Gateway, aggiunga una route alla tabella di routing della sottorete privata: destinazione 0.0.0.0/0 → ID del NAT Gateway. In questo modo tutto il traffico diretto a Internet dalle istanze della sottorete privata viene inviato al NAT Gateway, che lo inoltra quindi tramite l'Internet Gateway verso Internet. La tabella di routing mantiene anche la route locale della VPC (ad esempio, 10.0.0.0/16 → local) per il traffico interno. Senza questa voce nella tabella di routing, le istanze della sottorete privata non avranno accesso a Internet, anche se è stato implementato un NAT Gateway.

Un NAT Gateway è specifico per una AZ: gestisce il traffico solo dalle sottoreti presenti nella stessa AZ. Per ottenere un'elevata disponibilità, implementi un NAT Gateway per ogni AZ e crei tabelle di routing private specifiche per AZ: la tabella di routing privata nella AZ-a instrada 0.0.0.0/0 verso il NAT-GW nella AZ-a; la tabella di routing privata nella AZ-b instrada il traffico verso il NAT-GW nella AZ-b. In questo modo evita i costi di trasferimento dati tra AZ e garantisce che, se la AZ-a si guasta, le istanze nella AZ-b, con il proprio NAT, continuino ad avere accesso a Internet.

Una NAT Instance è un'istanza EC2 gestita autonomamente che esegue una NAT AMI: l'approccio precedente all'introduzione dei NAT Gateway. Le NAT Instance richiedono di: disabilitare il controllo dell'origine/destinazione sull'istanza EC2, gestire larghezza di banda e scalabilità, applicare le patch al sistema operativo e gestire i guasti. Sono più economiche per casi d'uso con larghezza di banda molto ridotta e possono essere utilizzate come bastion host. I NAT Gateway sono la scelta consigliata per la produzione: sono completamente gestiti, scalano automaticamente, offrono uno SLA di disponibilità del 99,99% all'interno di una AZ e non richiedono l'applicazione di patch. L'esame ha tradizionalmente verificato questo confronto.

Il prezzo dei NAT Gateway comprende due componenti: un costo orario per ogni NAT Gateway (circa 0,045 $/ora in us-east-1, ovvero circa 32 $/mese) e un costo di elaborazione dei dati per GB (circa 0,045 $/GB in us-east-1). Per i carichi di lavoro che trasferiscono grandi quantità di dati tramite NAT, ad esempio il download di immagini di container di grandi dimensioni o download in blocco, il costo di elaborazione dei dati può diventare predominante. Ottimizzi i costi del NAT instradando il traffico verso S3 e DynamoDB tramite VPC Gateway Endpoints (che bypassano completamente il NAT e sono gratuiti) e instradando le chiamate alle API AWS tramite VPC Interface Endpoints invece che tramite NAT.

Le istanze di database nelle sottoreti private non dovrebbero instradare il traffico tramite il NAT Gateway: non devono avviare connessioni verso Internet. I database devono solo ricevere connessioni dal livello applicativo, all'interno della VPC, e potenzialmente raggiungere servizi AWS come S3, per esportazioni e importazioni, tramite un VPC endpoint. Per l'applicazione di patch e gli aggiornamenti dei database, RDS è un servizio gestito, quindi le patch del sistema operativo non vengono applicate direttamente. Per i database autogestiti su EC2, utilizzi Systems Manager Patch Manager, che può applicare le patch tramite SSM senza accesso a Internet se è stato configurato il VPC endpoint SSM.

Il NAT Gateway fornisce un NAT stateful solo in uscita: consente le connessioni in uscita avviate dalle istanze e le relative risposte, ma blocca tutto il traffico in ingresso non sollecitato. Non è un firewall: non ispeziona né filtra il contenuto del traffico. Per filtrare il traffico in uscita, ad esempio consentendo solo determinati domini o indirizzi IP di destinazione dalle sottoreti private, sono necessari controlli aggiuntivi: AWS Network Firewall implementato nella VPC oppure un'appliance firewall di terze parti dietro un Gateway Load Balancer. I gruppi di sicurezza e le NACL si applicano comunque alle istanze nelle sottoreti private, indipendentemente dal NAT.

Oltre ai NAT Gateway pubblici, con EIP per l'accesso a Internet, AWS supporta i NAT Gateway privati senza EIP. I NAT Gateway privati vengono utilizzati per tradurre gli indirizzi IP privati del traffico tra VPC oppure tra una VPC e reti on-premises quando gli intervalli CIDR si sovrappongono. Ad esempio, se VPC-A (10.0.0.0/16) deve comunicare con una rete on-premises che utilizza anch'essa 10.0.0.0/16, un NAT Gateway privato nella VPC-A traduce gli IP di origine in un intervallo non sovrapposto prima di instradare il traffico tramite un Transit Gateway verso l'ambiente on-premises.

Monitori lo stato e le prestazioni del NAT Gateway tramite le metriche CloudWatch. Metriche principali: ActiveConnectionCount (connessioni TCP attive attualmente tramite il NAT), BytesInFromDestination / BytesInFromSource (trasferimento dati in entrambe le direzioni), PacketDropCount (pacchetti eliminati, indicano limiti di larghezza di banda o errori) ed ErrorPortAllocation (il NAT ha esaurito le allocazioni delle porte, situazione che può indicare l'esaurimento delle porte a causa di un numero eccessivo di connessioni). Ogni NAT Gateway supporta fino a 55.000 connessioni simultanee per ogni destinazione univoca; oltre tale limite, le connessioni potrebbero essere eliminate.

Non tutti i carichi di lavoro nelle sottoreti private necessitano di un NAT Gateway. Valuti il modello di accesso: se le istanze devono comunicare solo con altre risorse della VPC e con servizi AWS accessibili tramite VPC endpoint (S3, DynamoDB, SSM, ECR, Secrets Manager), può eliminare completamente il NAT Gateway, risparmiando circa 32 $ al mese per AZ oltre ai costi di elaborazione dei dati. Questo è il modello ideale per microservizi completamente privati che utilizzano VPC Interface Endpoints per accedere a tutti i servizi AWS. Valuti ogni servizio chiamato dalle istanze e verifichi se un Gateway Endpoint gratuito o un Interface Endpoint a pagamento può sostituire il NAT.

In questa lezione ha imparato che: i NAT Gateway consentono alle istanze delle sottoreti private di accedere a Internet in uscita traducendo i relativi IP privati in un Elastic IP; è necessario aggiungere una route 0.0.0.0/0 nella tabella di routing della sottorete privata che punti al NAT Gateway; e per ottenere un'elevata disponibilità ed evitare i costi di trasferimento dati tra AZ è necessario implementare un NAT Gateway per ogni AZ. Nella prossima lezione confronteremo le Network ACL e i Security Group per una difesa VPC a più livelli.