Uscita centralizzata per l'accesso a Internet
Quando si distribuiscono le applicazioni nella zona di destinazione, molte app richiedono solo l'accesso a Internet in uscita (ad esempio per il download di librerie, patch o aggiornamenti del sistema operativo). È possibile ottenere questo risultato utilizzando di preferenza un gateway NAT (Network Address Translation), o in alternativa, un'istanza EC2 configurata con SNAT (Source NAT) come hop successivo per tutti gli accessi Internet in uscita. Le applicazioni interne si trovano in sottoreti private, mentre le istanze NAT EC2 e del gateway NAT si trovano in una sottorete pubblica.
Uso del gateway NAT
L'implementazione di un gateway NAT in ogni VPC spoke può diventare costosa perché si paga una tariffa oraria per ogni gateway NAT implementato (consulta la pagina Prezzi di Amazon VPC
Nota: quando si centralizza il gateway NAT utilizzando Transit Gateway, si paga un costo aggiuntivo per l'elaborazione dei dati di Transit Gateway, rispetto all'approccio decentralizzato di esecuzione di un gateway NAT in ogni VPC. In alcuni ambienti edge, quando si inviano quantità molto grandi di dati tramite il gateway NAT da un VPC, può essere più conveniente mantenere il gateway NAT in locale nel VPC per evitare il costo di elaborazione dei dati di Transit Gateway.
Figura 10. Gateway NAT centralizzato con l'utilizzo di Transit Gateway (panoramica)
Figura 11. Gateway NAT centralizzato con l'utilizzo di Transit Gateway (progettazione della tabella di routing)
Con questa configurazione, i collegamenti VPC spoke sono associati alla tabella di routing 1 (RT1) e vengono propagati alla tabella di routing 2 (RT2). Abbiamo aggiunto esplicitamente una route blackhole per impedire ai due VPC di comunicare tra loro. Se si desidera permettere la comunicazione tra VPC, è possibile rimuovere la voce di routing "10.0.0.0/8 -> Blackhole" da RT1. Si permette così la comunicazione tramite il gateway NAT. È inoltre possibile propagare i collegamenti VPC spoke a RT1 (o in alternativa, è possibile utilizzare una tabella di routing e associare/propagare tutto in tale tabella), consentendo il flusso di traffico diretto tra i VPC tramite Transit Gateway.
Aggiungiamo una route statica in RT1 che instrada tutto il traffico al VPC in uscita. A causa di questa route statica, Transit Gateway invia tutto il traffico Internet attraverso le interfacce di rete elastica nel VPC in uscita. Una volta nel VPC in uscita, il traffico segue le regole definite nella tabella di routing della sottorete in cui sono presenti le interfacce di rete elastica di Transit Gateway. Aggiungiamo una route nella tabella di routing della sottorete che instrada tutto il traffico verso il gateway NAT. La tabella di routing della sottorete del gateway NAT ha il Gateway Internet (IGW) come hop successivo. Per consentire il flusso di ritorno del traffico, è necessario aggiungere una voce statica nella tabella di routing della sottorete del gateway NAT che instrada tutto il traffico verso i VPC spoke a Transit Gateway come hop successivo.
Disponibilità elevata
Per la disponibilità elevata, è consigliabile utilizzare due gateway NAT (uno in ciascuna zona di disponibilità). All'interno di una zona di disponibilità, il gateway NAT ha un contratto di servizio (SLA, Service Level Agreement) che prevede una disponibilità del 99,9%. La ridondanza in caso di errore dei componenti all'interno di una zona di disponibilità è gestita da AWS in base al contratto SLA. Il traffico non viene trasmesso durante lo 0,1% del tempo in cui il gateway NAT può non essere disponibile in una zona di disponibilità. In caso di problema di un'intera zona di disponibilità, l'endpoint Transit Gateway e il gateway NAT in tale zona di disponibilità non funzionano e tutto il traffico viene trasmesso attraverso gli endpoint Transit Gateway e del gateway NAT nell'altra zona di disponibilità.
Sicurezza
La sicurezza si ottiene grazie a gruppi di sicurezza nelle istanze di origine, route blackhole nelle tabelle di routing di Transit Gateway e lista di controllo degli accessi di rete della sottorete in cui si trova il gateway NAT.
Scalabilità
Un gateway NAT può supportare fino a 55.000 connessioni simultanee a ciascuna destinazione univoca. Dal punto di vista della velocità effettiva, i limiti dipendono dalle prestazioni del gateway NAT. Transit Gateway non è un bilanciatore del carico e non distribuisce il traffico in modo uniforme nel gateway NAT in più zone di disponibilità. Il traffico attraverso Transit Gateway rimane all'interno di una zona di disponibilità, se possibile. Se l'istanza EC2 da cui ha origine il traffico si trova nella zona di disponibilità 1, il traffico esce dall'interfaccia di rete elastica di Transit Gateway nella stessa zona di disponibilità 1 nel VPC in uscita e passa all'hop successivo in base alla tabella di routing della sottorete in cui si trova l'interfaccia di rete elastica. Per un elenco completo di regole, consulta la pagina relativa a regole e limiti del gateway NAT.
Per ulteriori informazioni, consulta il post di blog Creating a single internet exit point from multiple VPCs Using AWS Transit Gateway
Utilizzo di un'istanza EC2 per l'uscita centralizzata
L'utilizzo di un'appliance firewall basata su software (in EC2) disponibile in Marketplace AWS come punto di uscita è simile alla configurazione del gateway NAT. È possibile scegliere questa opzione se si desidera utilizzare le funzionalità IPS/IDS (Intrusion Prevention/Detection System) e firewall di livello 7 delle varie offerte dei fornitori.
Nella Figura 12 il gateway NAT viene sostituito con un'istanza EC2 (con la funzionalità SNAT abilitata nell'istanza EC2). Ci sono alcune considerazioni chiave in merito a questa opzione:
Disponibilità elevata
In questa configurazione, l'utente è responsabile del monitoraggio dell'istanza EC2, del rilevamento degli errori e della sostituzione dell'istanza EC2 con un'istanza di backup/standby. La maggior parte dei fornitori AWS offre un'automazione preconfigurata per il proprio software distribuito in questa configurazione. Tale automazione consente quanto segue:
-
Rilevamento degli errori dell'istanza EC2-1 primaria
-
Modifica della tabella di routing "Route Table Egx 1" in modo da instradare tutto il traffico all'istanza EC2-2 di backup in caso di errore dell'istanza primaria. Ciò deve avvenire anche per le sottoreti nella zona di disponibilità 2.
Figura 12. Soluzione NAT centralizzata con l'utilizzo di istanze EC2 e Transit Gateway
Scalabilità
Transit Gateway non è un bilanciatore del carico e non distribuisce il traffico in modo uniforme tra le istanze nelle due zone di disponibilità. Il traffico attraverso Transit Gateway rimane all'interno di una zona di disponibilità, se possibile. I limiti dipendono dalle capacità di larghezza di banda di una singola istanza EC2. È possibile il dimensionamento verticale dell'istanza EC2 quando l'utilizzo aumenta.
Se il fornitore scelto per l'ispezione del traffico in uscita non supporta l'automazione per il rilevamento degli errori o se è necessario il dimensionamento orizzontale, è possibile utilizzare una progettazione alternativa. Con questo tipo di progettazione (Figura 13), non viene creato un collegamento VPC in Transit Gateway per il VPC in uscita, ma vengono creati un collegamento alla VPN IPsec e una rete VPN IPsec da Transit Gateway verso le istanze EC2 utilizzando BGP per lo scambio di route.
Vantaggi
-
Il rilevamento degli errori e il reinstradamento del traffico sono gestiti da BGP. Non è richiesta l'automazione della tabella di routing della sottorete VPC.
-
È possibile utilizzare la strategia ECMP BGP per il bilanciamento del carico del traffico tra più istanze EC2 ed è possibile il dimensionamento orizzontale.
Figura 13. Soluzione NAT centralizzata con l'utilizzo di istanze EC2 e VPN di Transit Gateway
Considerazioni chiave
-
Costi di gestione della rete VPN nelle istanze EC2.
-
La larghezza di banda di Transit Gateway è limitata a 1,25 Gbps per tunnel VPN. Con la strategia ECMP Transit Gateway può supportare fino a 50 Gbps di larghezza di banda VPN totale. Le funzionalità VPN e di elaborazione dei pacchetti dell'appliance del fornitore possono costituire un fattore limitante.
-
Questo tipo di progettazione presuppone che l'istanza EC2 firewall funzioni con la stessa interfaccia di rete elastica per il traffico in entrata e in uscita.
-
Se si abilita il bilanciamento del carico ECMP del traffico tra più istanze EC2, è necessario applicare la funzionalità SNAT al traffico nell'istanza EC2 per consentire la simmetria del flusso di ritorno, il che significa che la destinazione non conoscerà la vera origine.
