Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Uscita centralizzata verso Internet
Quando distribuisci applicazioni in un ambiente con più account, molte app richiederanno l'accesso a Internet solo in uscita (ad esempio, il download di librerie, patch o aggiornamenti del sistema operativo). Ciò può essere ottenuto sia per il traffico IPv4 che IPv6. Per IPv4, ciò può essere ottenuto tramite la traduzione degli indirizzi di rete (NAT) sotto forma di gateway NAT (consigliato) o, in alternativa, un'istanza NAT autogestita in esecuzione su un'istanza Amazon EC2, come mezzo per l'accesso a Internet in uscita. Le applicazioni interne risiedono in sottoreti private, mentre i gateway NAT e le istanze NAT Amazon EC2 risiedono in una sottorete pubblica.
AWS consiglia di utilizzare i gateway NAT perché offrono disponibilità e larghezza di banda migliori e richiedono meno sforzi da parte dell'utente per l'amministrazione. Per ulteriori informazioni, [consulta Confronta](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-comparison.html) i gateway NAT e le istanze NAT.
Per quanto riguarda il IPv6 traffico, il traffico in uscita può essere configurato per lasciare ogni VPC attraverso un gateway Internet solo in uscita in modo decentralizzato oppure può essere configurato per essere inviato a un VPC centralizzato utilizzando istanze NAT o istanze proxy. I IPv6 modelli sono discussi in. [Uscita centralizzata per IPv6](centralized-egress-for-ipv6.md)
**Topics**
+ [Utilizzo del gateway NAT per l'uscita centralizzata IPv4](using-nat-gateway-for-centralized-egress.md)
+ [Utilizzo del gateway NAT con AWS Network Firewall per l'uscita centralizzata IPv4](using-nat-gateway-with-firewall.md)
+ [Utilizzo del gateway NAT e del Gateway Load Balancer con istanze Amazon EC2 per l'uscita centralizzata IPv4](using-nat-gateway-and-gwlb-with-ec2.md)
+ [Uscita centralizzata per IPv6](centralized-egress-for-ipv6.md)
# Utilizzo del gateway NAT per l'uscita centralizzata IPv4
Il gateway NAT è un servizio gestito di traduzione di indirizzi di rete. [L'implementazione di un gateway NAT in ogni VPC a socket può diventare proibitiva in termini di costi, perché si paga una tariffa oraria per ogni gateway NAT che si distribuisce (consulta i prezzi di Amazon VPC).](https://aws.amazon.com/vpc/pricing/) La centralizzazione dei gateway NAT può essere un'opzione valida per ridurre i costi. Per centralizzare, si crea un VPC in uscita separato nell'account dei servizi di rete, si distribuiscono i gateway NAT nel VPC in uscita e si instrada tutto il traffico in uscita dagli spoke ai VPCs gateway NAT che risiedono nel VPC in uscita utilizzando Transit Gateway o CloudWAN, come illustrato nella figura seguente.
**Nota**
Quando si centralizza il gateway NAT utilizzando Transit Gateway, si paga un costo aggiuntivo per l'elaborazione dei dati Transit Gateway, rispetto all'approccio decentralizzato che prevede l'esecuzione di un gateway NAT in ogni VPC. In alcuni casi limite, quando si inviano enormi quantità di dati tramite il gateway NAT da un VPC, mantenere il NAT locale nel VPC per evitare i costi di elaborazione dei dati Transit Gateway potrebbe essere un'opzione più conveniente.
![\[Un diagramma che illustra un'architettura gateway NAT decentralizzata ad alta disponibilità\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/decentralized-ha-nat-gateway.png)
![\[Un diagramma che illustra un gateway NAT centralizzato che utilizza Transit Gateway (panoramica)\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/centralized-nat-gateway-tg.png)
![\[Un diagramma che illustra un gateway NAT centralizzato che utilizza Transit Gateway (progettazione della tabella delle rotte)\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/nat-gateway-tg-rt.png)
In questa configurazione, gli allegati VPC Spoke sono associati alla Route Table 1 (RT1) e vengono propagati alla Route Table 2 (). RT2 Esiste un percorso [Blackhole](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-route-tables.html) per impedire ai due di comunicare VPCs tra loro. Se si desidera consentire la comunicazione tra VPC, è possibile rimuovere l'ingresso del `10.0.0.0/8 -> Blackhole` percorso da. RT1 Ciò consente loro di comunicare tramite il gateway di transito. Puoi anche propagare gli allegati RT1 Spoke VPC (o in alternativa, puoi utilizzare una tabella di routing associate/propagate e tutto il resto), abilitando il flusso di traffico diretto tra i Transit Gateway in uso VPCs .
Aggiungi un percorso statico RT1 indirizzando tutto il traffico verso il VPC in uscita. A causa di questa route statica, Transit Gateway invia tutto il traffico Internet attraverso il suo VPC ENIs in uscita. Una volta nel VPC in uscita, il traffico segue le rotte definite nella tabella delle rotte di sottorete in cui sono presenti questi Transit Gateway. ENIs Nelle tabelle di routing delle sottoreti si aggiunge un percorso che indirizza tutto il traffico verso il rispettivo gateway NAT nella stessa zona di disponibilità per ridurre al minimo il traffico tra zone di disponibilità (AZ). La tabella di routing della sottorete del gateway NAT ha come punto successivo il gateway Internet (IGW). Affinché il traffico di ritorno possa rifluire, è necessario aggiungere una voce statica della tabella di routing nella tabella di routing della sottorete del gateway NAT, indicando come hop successivo il traffico legato al VPC a spoke verso Transit Gateway.
## Elevata disponibilità
Per un'elevata disponibilità, è necessario utilizzare più di un gateway NAT (uno in ogni zona di disponibilità). Se un gateway NAT non è disponibile, il traffico potrebbe essere interrotto nella zona di disponibilità che attraversa il gateway NAT interessato. Se una zona di disponibilità non è disponibile, l'endpoint Transit Gateway e il gateway NAT in quella zona di disponibilità non funzioneranno e tutto il traffico fluirà attraverso gli endpoint Transit Gateway e gateway NAT nell'altra zona di disponibilità.
## Sicurezza
Puoi fare affidamento sui gruppi di sicurezza sulle istanze di origine, sulle route blackhole nelle tabelle di routing del Transit Gateway e sull'ACL di rete della sottorete in cui si trova il gateway NAT. Ad esempio, i clienti possono utilizzare ACLs le sottoreti pubbliche del gateway NAT per consentire o bloccare gli indirizzi IP di origine o di destinazione. In alternativa, è possibile utilizzare NAT Gateway con l'uscita centralizzata descritta nella sezione successiva AWS Network Firewall per soddisfare questo requisito.
## Scalabilità
Un singolo gateway NAT può supportare fino a 55.000 connessioni simultanee per indirizzo IP assegnato a ciascuna destinazione unica. È possibile richiedere un aggiustamento della quota per consentire fino a otto indirizzi IP assegnati, consentendo 440.000 connessioni simultanee a un unico IP e porta di destinazione. Il gateway NAT fornisce 5 Gbps di larghezza di banda e si ridimensiona automaticamente fino a 100 Gbps. Transit Gateway generalmente non funge da load balancer e non distribuisce il traffico in modo uniforme tra i gateway NAT nelle diverse zone di disponibilità. Il traffico attraverso il Transit Gateway rimarrà all'interno di una zona di disponibilità, se possibile. Se l'istanza Amazon EC2 che avvia il traffico si trova nella zona di disponibilità 1, il traffico uscirà dall'interfaccia di rete elastica Transit Gateway nella stessa zona di disponibilità 1 nel VPC in uscita e fluirà verso l'hop successivo in base alla tabella di routing di sottorete in cui risiede l'interfaccia di rete elastica. Per un elenco completo delle regole, consulta i [gateway NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) nella documentazione di Amazon Virtual Private Cloud.
Per ulteriori informazioni, consulta il post di blog [Creazione di un singolo punto di uscita Internet da più di un unico punto di uscita Internet VPCs con AWS Transit Gateway](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-a-single-internet-exit-point-from-multiple-vpcs-using-aws-transit-gateway/).
# Utilizzo del gateway NAT con AWS Network Firewall per l'uscita centralizzata IPv4
Se desideri ispezionare e filtrare il traffico in uscita, puoi incorporare AWS Network Firewall con gateway NAT nella tua architettura di uscita centralizzata. AWS Network Firewall è un servizio gestito che semplifica l'implementazione di protezioni di rete essenziali per tutti i tuoi. VPCs Fornisce controllo e visibilità al traffico di rete di livello 3-7 per l'intero VPC. È possibile filtrare il traffico in uscita basato su URL/domain nome, indirizzo IP e contenuto per bloccare possibili perdite di dati, contribuire a soddisfare i requisiti di conformità e bloccare le comunicazioni malware note. AWS Network Firewall supporta migliaia di regole in grado di filtrare il traffico di rete destinato a noti indirizzi IP o nomi di dominio non validi. Puoi anche utilizzare le regole IPS di Suricata come parte del AWS Network Firewall servizio importando set di regole open source o creando regole personalizzate del sistema di prevenzione delle intrusioni (IPS) utilizzando la sintassi delle regole Suricata. AWS Network Firewall consente inoltre di importare regole compatibili fornite dai partner AWS.
Nell'architettura di uscita centralizzata con ispezione, l' AWS Network Firewall endpoint è un obiettivo predefinito della tabella di routing nella tabella di routing della sottorete degli allegati del gateway di transito per il VPC in uscita. Il traffico tra spoke VPCs e Internet viene ispezionato utilizzando quanto illustrato nel diagramma seguente. AWS Network Firewall
![\[Un diagramma che illustra l'uscita centralizzata con un gateway NAT (progettazione della tabella di AWS Network Firewall percorso)\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/centralized-egress-rt.png)
Per un modello di distribuzione centralizzato con Transit Gateway, AWS consiglia di implementare gli AWS Network Firewall endpoint in più zone di disponibilità. Dovrebbe esserci un endpoint firewall in ogni zona di disponibilità in cui il cliente esegue i carichi di lavoro, come mostrato nel diagramma precedente. Come procedura ottimale, la sottorete firewall non deve contenere altro traffico perché non AWS Network Firewall è in grado di ispezionare il traffico proveniente da fonti o destinazioni all'interno di una sottorete firewall.
Analogamente alla configurazione precedente, gli allegati Spoke VPC sono associati alla Route Table 1 (RT1) e vengono propagati alla Route Table 2 (). RT2 Viene aggiunta esplicitamente una route Blackhole per impedire ai due VPCs di comunicare tra loro.
Continua a utilizzare un percorso predefinito per RT1 indirizzare tutto il traffico verso il VPC in uscita. Transit Gateway inoltrerà tutti i flussi di traffico a una delle due zone di disponibilità nel VPC in uscita. Una volta che il traffico raggiunge uno dei Transit Gateway ENIs nel VPC in uscita, segui un percorso predefinito che inoltrerà il traffico a uno degli endpoint AWS Network Firewall nella rispettiva zona di disponibilità. AWS Network Firewall esaminerà quindi il traffico in base alle regole impostate prima di inoltrare il traffico al gateway NAT utilizzando un percorso predefinito.
Questo caso non richiede la modalità appliance Transit Gateway, perché non si invia traffico tra gli allegati.
**Nota**
AWS Network Firewall non esegue la traduzione degli indirizzi di rete per voi, questa funzione verrebbe gestita dal gateway NAT dopo l'ispezione del traffico tramite. AWS Network Firewall Il routing in ingresso non è richiesto in questo caso poiché il traffico di ritorno verrà inoltrato al NATGW per impostazione predefinita. IPs
Poiché si utilizza un Transit Gateway, qui possiamo posizionare il firewall prima del gateway NAT. In questo modello, il firewall può vedere l'IP di origine dietro il Transit Gateway.
Se lo facevi in un singolo VPC, possiamo utilizzare i miglioramenti del routing VPC che consentono di ispezionare il traffico tra sottoreti nello stesso VPC. Per i dettagli, consulta il post sul [blog Deployment models for AWS Network Firewall with VPC routing enhancements](https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall-with-vpc-routing-enhancements/).
## Scalabilità
AWS Network Firewall può aumentare o ridurre automaticamente la capacità del firewall in base al carico di traffico per mantenere prestazioni stabili e prevedibili e ridurre al minimo i costi. AWS Network Firewall è progettato per supportare decine di migliaia di regole firewall e può scalare fino a 100 Gbps di velocità effettiva per zona di disponibilità.
## Considerazioni chiave
+ [Ogni endpoint firewall è in grado di gestire circa 100 Gbps di traffico, se hai bisogno di un burst più elevato o di un throughput sostenuto, contatta il supporto AWS.](https://docs.aws.amazon.com/awssupport/latest/user/getting-started.html)
+ Se scegli di creare un gateway NAT nel tuo account AWS insieme a Network Firewall, non verranno addebitati i costi di elaborazione del gateway NAT standard e di utilizzo all'ora in one-to-one base all'elaborazione per GB e alle ore di utilizzo [addebitate](https://aws.amazon.com/network-firewall/pricing/) per il firewall.
+ Puoi anche prendere in considerazione l'utilizzo di endpoint firewall distribuiti AWS Firewall Manager senza Transit Gateway.
+ Verifica le regole del firewall prima di trasferirle in produzione, in modo simile a una lista di controllo degli accessi alla rete, poiché l'ordine è importante.
+ Per un'ispezione più approfondita sono necessarie regole avanzate in Suricata. Il firewall di rete supporta l'ispezione crittografata del traffico in ingresso e in uscita.
+ La variabile del gruppo di `HOME_NET` regole definiva l'intervallo IP di origine idoneo per l'elaborazione nel motore Stateful. Utilizzando un approccio centralizzato, è necessario aggiungere tutti i VPC aggiuntivi CIDRs collegati al Transit Gateway per renderli idonei all'elaborazione. Consulta la [documentazione di Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/stateful-rule-groups-domain-names.html) per maggiori dettagli sulla variabile del gruppo di `HOME_NET` regole.
+ Prendi in considerazione la possibilità di implementare Transit Gateway e VPC in uscita in un account di servizi di rete separato per separare l'accesso in base alla delega di compiti; ad esempio, solo gli amministratori di rete possono accedere all'account Network Services.
+ Per semplificare l'implementazione e la gestione di questo modello, può essere AWS Network Firewall utilizzato. AWS Firewall Manager Firewall Manager consente di amministrare centralmente i diversi firewall applicando automaticamente la protezione creata nella posizione centralizzata a più account. Firewall Manager supporta modelli di distribuzione distribuiti e centralizzati per Network Firewall. Per ulteriori informazioni, consulta il post del blog [How to deploy AWS Network Firewall by using. AWS Firewall Manager](https://aws.amazon.com/blogs/security/how-to-deploy-aws-network-firewall-by-using-aws-firewall-manager/)
# Utilizzo del gateway NAT e del Gateway Load Balancer con istanze Amazon EC2 per l'uscita centralizzata IPv4
L'utilizzo di un'appliance virtuale basata su software (su Amazon EC2) da Marketplace AWS e AWS Partner Network come punto di uscita è simile alla configurazione del gateway NAT. Questa opzione può essere utilizzata se si desidera utilizzare le funzionalità avanzate di livello 7 (4rewall/Intrusion Prevention/Detection System (IPS/IDS) e di ispezione approfondita dei pacchetti delle offerte dei vari fornitori.
Nella figura seguente, oltre al gateway NAT, vengono distribuite appliance virtuali utilizzando istanze EC2 dietro un Gateway Load Balancer (GWLB). In questa configurazione, GWLB, Gateway Load Balancer Endpoint (GWLBE), le appliance virtuali e i gateway NAT vengono implementati in un VPC centralizzato collegato a Transit Gateway tramite collegamento VPC. Gli spoke VPCs sono inoltre collegati al Transit Gateway tramite un attacco VPC. Poiché GWLBEs si tratta di una destinazione instradabile, è possibile indirizzare il traffico che si sposta da e verso il Transit Gateway verso la flotta di appliance virtuali configurate come destinazioni dietro una GWLB. GWLB funge da interfaccia bump-in-the-wire e trasmette in modo trasparente tutto il traffico di livello 3 attraverso dispositivi virtuali di terze parti e quindi è invisibile alla fonte e alla destinazione del traffico. Pertanto, questa architettura consente di ispezionare centralmente tutto il traffico in uscita che attraversa Transit Gateway.
Per ulteriori informazioni su come il traffico fluisce dalle applicazioni VPCs verso Internet e viceversa attraverso questa configurazione, consulta [Architettura di ispezione centralizzata con AWS Gateway Load AWS Transit Gateway Balancer](https://aws.amazon.com/blogs/networking-and-content-delivery/centralized-inspection-architecture-with-aws-gateway-load-balancer-and-aws-transit-gateway/) e.
È possibile abilitare la modalità appliance su Transit Gateway per mantenere la simmetria del flusso attraverso le appliance virtuali. Ciò significa che il traffico bidirezionale viene instradato attraverso lo stesso dispositivo e la zona di disponibilità per tutta la durata del flusso. Questa impostazione è particolarmente importante per i firewall stateful che eseguono un'ispezione approfondita dei pacchetti. L'attivazione della modalità appliance elimina la necessità di soluzioni alternative complesse, come la traduzione degli indirizzi di rete di origine (SNAT), per forzare il ritorno del traffico all'appliance corretta per mantenere la simmetria. Per ulteriori informazioni, consulta [le best practice per l'implementazione di Gateway Load](https://aws.amazon.com/blogs/networking-and-content-delivery/best-practices-for-deploying-gateway-load-balancer/) Balancer.
È anche possibile implementare gli endpoint GWLB in modo distribuito senza Transit Gateway per consentire l'ispezione in uscita. Scopri di più su questo modello architettonico nel post di blog [Introducing AWS Gateway Load Balancer: Supported architecture patterns](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-gateway-load-balancer-supported-architecture-patterns/).
![\[Un diagramma che illustra l'uscita centralizzata con Gateway Load Balancer e istanza EC2 (progettazione della tabella di routing)\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/centralized-egress-gwlb-and-ec2.png)
## Elevata disponibilità
AWS consiglia di implementare Gateway Load Balancer e appliance virtuali in più zone di disponibilità per una maggiore disponibilità.
Gateway Load Balancer può eseguire controlli di integrità per rilevare i guasti delle appliance virtuali. In caso di malfunzionamento dell'appliance, GWLB reindirizza i nuovi flussi verso dispositivi funzionanti. I flussi esistenti vanno sempre allo stesso obiettivo indipendentemente dallo stato di salute dell'obiettivo. Ciò consente di esaurire la connessione e di evitare errori nei controlli di integrità dovuti a picchi di CPU sui dispositivi. Per ulteriori dettagli, fare riferimento alla sezione 4: Comprendere gli scenari di errore di appliance e Availability Zone nel post del blog [Best practice for deploying Gateway Load Balancer](https://aws.amazon.com/blogs/networking-and-content-delivery/best-practices-for-deploying-gateway-load-balancer/). Gateway Load Balancer può utilizzare i gruppi di auto scaling come obiettivi. Questo vantaggio elimina l'oneroso compito di gestire la disponibilità e la scalabilità delle flotte di appliance.
## Vantaggi
Gli endpoint Gateway Load Balancer e Gateway Load Balancer sono alimentati AWS PrivateLink da, che consente lo scambio di traffico attraverso i confini del VPC in modo sicuro senza la necessità di attraversare la rete Internet pubblica.
Gateway Load Balancer è un servizio gestito che elimina il carico indifferenziato di gestione, implementazione e scalabilità delle appliance di sicurezza virtuali, in modo che tu possa concentrarti sulle cose che contano. Gateway Load Balancer può esporre lo stack di firewall come servizio endpoint a cui i clienti possono abbonarsi utilizzando il. [Marketplace AWS](https://aws.amazon.com/marketplace) Si chiama Firewall as a Service (FWaaS); introduce una distribuzione semplificata ed elimina la necessità di affidarsi a BGP ed ECMP per distribuire il traffico su più istanze Amazon EC2.
## Considerazioni chiave
+ [Le appliance devono supportare il protocollo di incapsulamento Geneve per integrarsi con GWLB.](https://datatracker.ietf.org/doc/html/rfc8926)
+ Alcuni dispositivi di terze parti possono supportare SNAT e overlay routing ([modalità a due bracci](https://networkgeekstuff.com/networking/basic-load-balancer-scenarios-explained/)), eliminando così la necessità di creare gateway NAT per risparmiare sui costi. Tuttavia, consulta un partner AWS di tua scelta prima di utilizzare questa modalità, poiché dipende dal supporto e dall'implementazione del fornitore.
+ Prendi nota del timeout di inattività di [GWLB.](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/gateway-load-balancers.html#idle-timeout) Ciò può comportare dei timeout di connessione sui client. È possibile regolare i timeout a livello di client, server, firewall e sistema operativo per evitare che ciò si verifichi. Per ulteriori informazioni, consulta la *Sezione 1: Ottimizzazione dei valori di keep-alive o timeout TCP per supportare flussi TCP di lunga durata* nel post di blog Best practice [for deploying Gateway Load Balancer](https://aws.amazon.com/blogs/networking-and-content-delivery/best-practices-for-deploying-gateway-load-balancer/).
+ I GWLBE sono alimentati da, pertanto verranno applicati dei costi. AWS PrivateLink AWS PrivateLink Puoi saperne di più nella pagina dei [AWS PrivateLink prezzi](https://aws.amazon.com/privatelink/pricing/). Se si utilizza il modello centralizzato con Transit Gateway, saranno applicabili i costi di elaborazione dati TGW.
+ Prendi in considerazione la possibilità di implementare Transit Gateway e il VPC in uscita in un account di servizi di rete separato per separare l'accesso in base alla delega di compiti, ad esempio solo gli amministratori di rete possono accedere all'account di servizi di rete.
# Uscita centralizzata per IPv6
Per supportare l' IPv6 uscita in implementazioni dual stack con uscita centralizzata IPv4 , è necessario scegliere uno dei due modelli seguenti:
+ IPv4 Uscita IPv6 centralizzata con uscita decentralizzata
+ Uscita centralizzata e uscita centralizzata IPv4 IPv6
Nel primo schema, illustrato nel diagramma seguente, i gateway Internet di sola uscita vengono distribuiti in ogni VPC a raggi. I gateway Internet solo in uscita sono gateway a scalabilità orizzontale, ridondanti e ad alta disponibilità che consentono la comunicazione in uscita dalle istanze all'interno del tuo VPC. IPv6 Impediscono a IPv6 Internet di avviare connessioni con le tue istanze. I gateway Internet solo in uscita sono gratuiti. In questo modello di implementazione, il IPv6 traffico esce dai gateway Internet di sola uscita in ogni VPC e il IPv4 traffico fluisce attraverso i gateway NAT centralizzati implementati.
![\[Un diagramma che illustra l'uscita centralizzata e l'uscita decentralizzata solo in uscita. IPV4 IPv6\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/centralized-ipv4-egress-and-decentralized-outbound-ipv6.png)
Nel secondo schema, illustrato nei diagrammi seguenti, il IPv6 traffico in uscita dalle istanze viene inviato a un VPC centralizzato. Ciò può essere ottenuto utilizzando IPv6 -to- IPv6 Network Prefix Translation (NPTv6) con NAT66 istanze e gateway NAT o utilizzando Proxy Instances e Network Load Balancer. Questo modello è applicabile se è richiesta un'ispezione centralizzata del traffico per il traffico in uscita e non può essere eseguita in ogni VPC a raggi.
![\[Un diagramma che illustra l'uscita centralizzata utilizzando gateway e istanze IPv6 NAT. NAT66\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/centralized-ipv6-egress-using-nat-gateways.png)
![\[Un diagramma che illustra la centralizzazione IPv4 e l' IPv6 uscita utilizzando istanze proxy e Network Load Balancer.\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/centralized-ipv4-and-ipv6-egress.png)
Il [white paper IPv6 su AWS descrive i modelli di](https://docs.aws.amazon.com/whitepapers/latest/ipv6-on-aws/advanced-dual-stack-and-ipv6-only-network-designs.html) uscita centralizzati IPv6 . I modelli IPv6 di uscita sono discussi più dettagliatamente nel blog [Traffico Internet in uscita centralizzato per il dual stack IPv4 e IPv6 VPCs, insieme a considerazioni speciali, soluzioni di esempio e](https://aws.amazon.com/blogs/networking-and-content-delivery/centralizing-outbound-internet-traffic-for-dual-stack-ipv4-and-ipv6-vpcs/) diagrammi.