As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Saída centralizada para a Internet
À medida que você implanta aplicativos em seu ambiente de várias contas, muitos aplicativos exigirão acesso somente de saída à Internet (por exemplo, download de bibliotecas, patches ou atualizações do sistema operacional). Isso pode ser feito para tráfego IPv4 e IPv6. Para IPv4, isso pode ser obtido por meio da conversão de endereços de rede (NAT) na forma de um gateway NAT (recomendado) ou, alternativamente, de uma instância NAT autogerenciada em execução em uma instância do Amazon EC2, como meio de acesso à Internet de saída. Os aplicativos internos residem em sub-redes privadas, enquanto os gateways NAT e as instâncias NAT do Amazon EC2 residem em uma sub-rede pública.
A AWS recomenda que você use gateways NAT porque eles oferecem melhor disponibilidade e largura de banda e exigem menos esforço de sua parte para administrar. Para obter mais informações, consulte [Compare gateways NAT e instâncias NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-comparison.html).
Para IPv6 tráfego, o tráfego de saída pode ser configurado para sair de cada VPC por meio de um gateway de Internet somente de saída de forma descentralizada ou pode ser configurado para ser enviado a uma VPC centralizada usando instâncias NAT ou instâncias de proxy. Os IPv6 padrões são discutidos em[Saída centralizada para IPv6](centralized-egress-for-ipv6.md).
**Topics**
+ [Usando o gateway NAT para saída centralizada IPv4](using-nat-gateway-for-centralized-egress.md)
+ [Usando o gateway NAT com AWS Network Firewall para saída centralizada IPv4](using-nat-gateway-with-firewall.md)
+ [Usando o gateway NAT e o Gateway Load Balancer com instâncias do Amazon EC2 para saída centralizada IPv4](using-nat-gateway-and-gwlb-with-ec2.md)
+ [Saída centralizada para IPv6](centralized-egress-for-ipv6.md)
# Usando o gateway NAT para saída centralizada IPv4
O gateway NAT é um serviço gerenciado de tradução de endereços de rede. [Implantar um gateway NAT em cada VPC spoke pode se tornar um custo proibitivo, pois você paga uma taxa por hora por cada gateway NAT implantado (consulte os preços do Amazon VPC).](https://aws.amazon.com/vpc/pricing/) Centralizar os gateways NAT pode ser uma opção viável para reduzir custos. Para centralizar, você cria uma VPC de saída separada na conta de serviços de rede, implanta gateways NAT na VPC de saída e roteia todo o tráfego de saída do spoke VPCs para os gateways NAT que residem na VPC de saída usando Transit Gateway ou CloudWAN, conforme mostrado na figura a seguir.
**nota**
Ao centralizar o gateway NAT usando o Transit Gateway, você paga uma taxa extra de processamento de dados do Transit Gateway, em comparação com a abordagem descentralizada de executar um gateway NAT em cada VPC. Em alguns casos extremos, quando você envia grandes quantidades de dados por meio do gateway NAT de uma VPC, manter a NAT local na VPC para evitar a cobrança de processamento de dados do Transit Gateway pode ser uma opção mais econômica.
![\[Um diagrama que descreve uma arquitetura de gateway NAT descentralizada de alta disponibilidade\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/decentralized-ha-nat-gateway.png)
![\[Um diagrama que descreve um gateway NAT centralizado usando o Transit Gateway (visão geral)\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/centralized-nat-gateway-tg.png)
![\[Um diagrama que descreve um gateway NAT centralizado usando o Transit Gateway (design de tabela de rotas)\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/nat-gateway-tg-rt.png)
Nessa configuração, os anexos de VPC do spoke são associados à Tabela de Rota 1 (RT1) e são propagados para a Tabela de Rota 2 (). RT2 Existe uma rota do [Blackhole](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-route-tables.html) para impedir que os dois VPCs se comuniquem. Se você quiser permitir a comunicação entre VPC, você pode remover a entrada da `10.0.0.0/8 -> Blackhole` rota de. RT1 Isso permite que eles se comuniquem por meio do gateway de trânsito. Você também pode propagar os anexos do VPC spoke RT1 para (ou, alternativamente, usar uma tabela de rotas associate/propagate e tudo mais), permitindo o fluxo de tráfego direto entre eles usando o Transit Gateway. VPCs
Você adiciona uma rota estática ao RT1 apontar todo o tráfego para a VPC de saída. Por causa dessa rota estática, o Transit Gateway envia todo o tráfego da Internet por meio ENIs de sua VPC de saída. Uma vez na VPC de saída, o tráfego segue as rotas definidas na tabela de rotas da sub-rede em que esses Transit Gateway estão presentes. ENIs Você adiciona uma rota nas tabelas de rotas de sub-rede apontando todo o tráfego para o respectivo gateway NAT na mesma zona de disponibilidade para minimizar o tráfego da zona de disponibilidade cruzada (AZ). A tabela de rotas de sub-rede do gateway NAT tem o Internet Gateway (IGW) como o próximo salto. Para que o tráfego de retorno retorne, você deve adicionar uma entrada de tabela de rotas estática na tabela de rotas de sub-rede do gateway NAT, apontando todo o tráfego vinculado ao VPC do Spoke para o Transit Gateway como o próximo salto.
## Alta disponibilidade
Para alta disponibilidade, você deve usar mais de um gateway NAT (um em cada zona de disponibilidade). Se um gateway NAT não estiver disponível, o tráfego poderá ser descartado na zona de disponibilidade que está atravessando o gateway NAT afetado. Se uma zona de disponibilidade não estiver disponível, o endpoint do Transit Gateway junto com o gateway NAT nessa zona de disponibilidade falharão e todo o tráfego fluirá pelos endpoints do Transit Gateway e do gateway NAT na outra zona de disponibilidade.
## Segurança
Você pode confiar em grupos de segurança nas instâncias de origem, nas rotas blackhole nas tabelas de rotas do Transit Gateway e na ACL de rede da sub-rede na qual o gateway NAT está localizado. Por exemplo, os clientes podem usar sub-redes públicas ACLs no NAT Gateway para permitir ou bloquear endereços IP de origem ou destino. Como alternativa, você pode usar o NAT Gateway com AWS Network Firewall a saída centralizada descrita na próxima seção para atender a esse requisito.
## Escalabilidade
Um único gateway NAT pode suportar até 55.000 conexões simultâneas por endereço IP atribuído a cada destino exclusivo. Você pode solicitar um ajuste de cota para permitir até oito endereços IP atribuídos, permitindo 440.000 conexões simultâneas com um único IP e porta de destino. O gateway NAT fornece 5 Gbps de largura de banda e escala automaticamente para 100 Gbps. O Transit Gateway geralmente não atua como um balanceador de carga e não distribuiria seu tráfego uniformemente entre gateways NAT nas várias zonas de disponibilidade. O tráfego no Transit Gateway permanecerá dentro de uma zona de disponibilidade, se possível. Se o tráfego inicial da instância do Amazon EC2 estiver na Zona de Disponibilidade 1, o tráfego fluirá da interface de rede elástica do Transit Gateway na mesma Zona de Disponibilidade 1 na VPC de saída e fluirá para o próximo salto com base na tabela de rotas de sub-rede na qual a interface de rede elástica reside. Para obter uma lista completa de regras, consulte os [gateways NAT na](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) documentação da Amazon Virtual Private Cloud.
Para obter mais informações, consulte a postagem do blog [Como criar um único ponto de saída de internet a partir de vários VPCs usando o 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/).
# Usando o gateway NAT com AWS Network Firewall para saída centralizada IPv4
Se quiser inspecionar e filtrar seu tráfego de saída, você pode incorporar o AWS Network Firewall com o gateway NAT em sua arquitetura de saída centralizada. AWS Network Firewall é um serviço gerenciado que facilita a implantação de proteções de rede essenciais para todos os seus VPCs. Ele fornece controle e visibilidade do tráfego de rede de camada 3-7 para toda a sua VPC. Você pode filtrar o tráfego de saída com base em URL/domain nome, endereço IP e conteúdo para impedir possíveis perdas de dados, ajudar a atender aos requisitos de conformidade e bloquear comunicações de malware conhecidas. AWS Network Firewall suporta milhares de regras que podem filtrar o tráfego de rede destinado a endereços IP inválidos conhecidos ou nomes de domínio inválidos. Você também pode usar as regras IPS do Suricata como parte do AWS Network Firewall serviço importando conjuntos de regras de código aberto ou criando suas próprias regras do Sistema de Prevenção de Intrusões (IPS) usando a sintaxe de regras do Suricata. AWS Network Firewall também permite que você importe regras compatíveis provenientes de parceiros da AWS.
Na arquitetura de saída centralizada com inspeção, o AWS Network Firewall endpoint é um destino padrão da tabela de rotas na tabela de rotas de sub-rede de anexos do gateway de trânsito para a VPC de saída. O tráfego entre o spoke VPCs e a Internet é AWS Network Firewall inspecionado usando o diagrama a seguir.
![\[Um diagrama que descreve a saída centralizada com AWS Network Firewall um gateway NAT (design da tabela de rotas)\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/centralized-egress-rt.png)
Para um modelo de implantação centralizada com o Transit Gateway, a AWS recomenda a implantação de AWS Network Firewall endpoints em várias zonas de disponibilidade. Deve haver um endpoint de firewall em cada zona de disponibilidade em que o cliente está executando cargas de trabalho, conforme mostrado no diagrama anterior. Como prática recomendada, a sub-rede do firewall não deve conter nenhum outro tráfego porque não AWS Network Firewall é capaz de inspecionar o tráfego de origens ou destinos dentro de uma sub-rede do firewall.
Semelhante à configuração anterior, os anexos de VPC do spoke são associados à Route Table 1 (RT1) e são propagados para a Route Table 2 (). RT2 Uma rota Blackhole é adicionada explicitamente para impedir que os dois VPCs se comuniquem.
Continue usando uma rota padrão para RT1 direcionar todo o tráfego para a VPC de saída. O Transit Gateway encaminhará todos os fluxos de tráfego para uma das duas zonas de disponibilidade na VPC de saída. Quando o tráfego chega a um dos Transit Gateway ENIs na VPC de saída, você atinge uma rota padrão que encaminhará o tráfego para um dos AWS Network Firewall endpoints em sua respectiva zona de disponibilidade. AWS Network Firewall em seguida, inspecionará o tráfego com base nas regras definidas antes de encaminhá-lo para o gateway NAT usando uma rota padrão.
Esse caso não exige o modo de dispositivo Transit Gateway, porque você não está enviando tráfego entre anexos.
**nota**
AWS Network Firewall não realiza a tradução de endereços de rede para você, essa função seria tratada pelo gateway NAT após a inspeção de tráfego através do. AWS Network Firewall O roteamento de entrada não é necessário nesse caso, pois o tráfego de retorno será encaminhado para o IPs NATGW por padrão.
Como você está usando um Transit Gateway, aqui podemos colocar o firewall antes do gateway NAT. Nesse modelo, o firewall pode ver o IP de origem por trás do Transit Gateway.
Se você estiver fazendo isso em uma única VPC, podemos usar os aprimoramentos de roteamento da VPC que permitem inspecionar o tráfego entre sub-redes na mesma VPC. Para obter detalhes, consulte a postagem do blog sobre [modelos de implantação AWS Network Firewall com aprimoramentos de roteamento de VPC](https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall-with-vpc-routing-enhancements/).
## Escalabilidade
AWS Network Firewall pode aumentar ou diminuir automaticamente a capacidade do firewall com base na carga de tráfego para manter um desempenho estável e previsível e minimizar os custos. AWS Network Firewall foi projetado para suportar dezenas de milhares de regras de firewall e pode escalar até 100 Gbps de taxa de transferência por zona de disponibilidade.
## Considerações importantes
+ [Cada endpoint de firewall pode lidar com cerca de 100 Gbps de tráfego. Se você precisar de maior intermitência ou taxa de transferência sustentada, entre em contato com o suporte da AWS.](https://docs.aws.amazon.com/awssupport/latest/user/getting-started.html)
+ Se você optar por criar um gateway NAT em sua conta da AWS junto com o Network Firewall, o processamento padrão do gateway NAT e [as cobranças](https://aws.amazon.com/network-firewall/pricing/) de uso por hora serão dispensadas com one-to-one base no processamento por GB e nas horas de uso cobradas pelo seu firewall.
+ Você também pode considerar endpoints de firewall distribuídos AWS Firewall Manager sem um Transit Gateway.
+ Teste as regras de firewall antes de movê-las para a produção, semelhante a uma lista de controle de acesso à rede, conforme a ordem for importante.
+ Regras avançadas de Suricata são necessárias para uma inspeção mais profunda. O firewall de rede oferece suporte à inspeção criptografada de tráfego para entrada e saída.
+ A variável do grupo de `HOME_NET` regras definiu o intervalo de IP de origem elegível para processamento no mecanismo Stateful. Usando uma abordagem centralizada, você deve adicionar todas as CIDRs VPC adicionais anexadas ao Transit Gateway para torná-las elegíveis para processamento. Consulte a [documentação do Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/stateful-rule-groups-domain-names.html) para obter mais detalhes sobre a variável do grupo de `HOME_NET` regras.
+ Considere implantar o Transit Gateway e a VPC de saída em uma conta separada dos Serviços de Rede para segregar o acesso com base na delegação de tarefas; por exemplo, somente administradores de rede podem acessar a conta dos Serviços de Rede.
+ Para simplificar a implantação e o gerenciamento deste AWS Network Firewall modelo, AWS Firewall Manager pode ser usado. O Firewall Manager permite que você administre centralmente seus diferentes firewalls aplicando automaticamente a proteção criada no local centralizado a várias contas. O Firewall Manager oferece suporte a modelos de implantação distribuídos e centralizados para o Firewall de Rede. Para saber mais, consulte a postagem do blog [Como implantar AWS Network Firewall usando AWS Firewall Manager](https://aws.amazon.com/blogs/security/how-to-deploy-aws-network-firewall-by-using-aws-firewall-manager/).
# Usando o gateway NAT e o Gateway Load Balancer com instâncias do Amazon EC2 para saída centralizada IPv4
Usar um dispositivo virtual baseado em software (no Amazon EC2) de AWS Marketplace e AWS Partner Network como um ponto de saída é semelhante à configuração do gateway NAT. Essa opção pode ser usada se você quiser usar os recursos avançados de inspeção de pacotes (camada 7rewall/Intrusion Prevention/Detection System (IPS/IDS) e profunda de pacotes das ofertas de vários fornecedores.
Na figura a seguir, além do gateway NAT, você implanta dispositivos virtuais usando instâncias EC2 por trás de um Gateway Load Balancer (GWLB). Nessa configuração, o GWLB, o Gateway Load Balancer Endpoint (GWLBE), os dispositivos virtuais e os gateways NAT são implantados em uma VPC centralizada conectada ao Transit Gateway usando o anexo VPC. Os raios também VPCs são conectados ao Transit Gateway usando um anexo VPC. Por GWLBEs serem um destino roteável, você pode rotear o tráfego que se move de e para o Transit Gateway para a frota de dispositivos virtuais configurados como destinos por trás de um GWLB. O GWLB atua como um bump-in-the-wire e transmite de forma transparente todo o tráfego de camada 3 por meio de dispositivos virtuais de terceiros e, portanto, é invisível para a origem e o destino do tráfego. Portanto, essa arquitetura permite que você inspecione centralmente todo o tráfego de saída que passa pelo Transit Gateway.
Para obter mais informações sobre como o tráfego flui dos aplicativos VPCs para a Internet e de volta por meio dessa configuração, consulte [Arquitetura de inspeção centralizada com o AWS Gateway Load Balancer e. AWS Transit Gateway](https://aws.amazon.com/blogs/networking-and-content-delivery/centralized-inspection-architecture-with-aws-gateway-load-balancer-and-aws-transit-gateway/)
Você pode ativar o modo de dispositivo no Transit Gateway para manter a simetria do fluxo por meio de dispositivos virtuais. Isso significa que o tráfego bidirecional é roteado pelo mesmo dispositivo e pela zona de disponibilidade durante toda a vida útil do fluxo. Essa configuração é particularmente importante para firewalls com estado que realizam inspeção profunda de pacotes. A ativação do modo de dispositivo elimina a necessidade de soluções alternativas complexas, como tradução de endereço de rede de origem (SNAT), para forçar o tráfego a retornar ao dispositivo correto para manter a simetria. Consulte [Melhores práticas para implantar o Gateway Load Balancer](https://aws.amazon.com/blogs/networking-and-content-delivery/best-practices-for-deploying-gateway-load-balancer/) para obter detalhes.
Também é possível implantar endpoints GWLB de forma distribuída sem o Transit Gateway para permitir a inspeção de saída. Saiba mais sobre esse padrão de arquitetura na publicação do 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/).
![\[Um diagrama que mostra a saída centralizada com o Gateway Load Balancer e a instância EC2 (design da tabela de rotas)\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/centralized-egress-gwlb-and-ec2.png)
## Alta disponibilidade
A AWS recomenda a implantação de balanceadores de carga de gateway e dispositivos virtuais em várias zonas de disponibilidade para maior disponibilidade.
O Gateway Load Balancer pode realizar verificações de integridade para detectar falhas no dispositivo virtual. No caso de um dispositivo não íntegro, o GWLB redireciona os novos fluxos para dispositivos saudáveis. Os fluxos existentes sempre vão para o mesmo alvo, independentemente do estado de saúde do alvo. Isso permite a drenagem da conexão e acomoda falhas na verificação de integridade devido a picos de CPU nos dispositivos. Para obter mais detalhes, consulte a seção 4: Entenda os cenários de falha do dispositivo e da zona de disponibilidade na postagem do blog [Melhores práticas para a implantação do Gateway Load Balancer](https://aws.amazon.com/blogs/networking-and-content-delivery/best-practices-for-deploying-gateway-load-balancer/). O Gateway Load Balancer pode usar grupos de escalonamento automático como alvos. Esse benefício elimina o trabalho pesado de gerenciar a disponibilidade e a escalabilidade das frotas de dispositivos.
## Vantagens
Os endpoints do Gateway Load Balancer e do Gateway Load Balancer são alimentados AWS PrivateLink por, o que permite a troca de tráfego entre os limites da VPC com segurança, sem a necessidade de atravessar a Internet pública.
O Gateway Load Balancer é um serviço gerenciado que elimina o trabalho pesado indiferenciado de gerenciar, implantar e escalar dispositivos de segurança virtual para que você possa se concentrar nas coisas que importam. O Gateway Load Balancer pode expor a pilha de firewalls como um serviço de endpoint para os clientes assinarem usando o. [AWS Marketplace](https://aws.amazon.com/marketplace) Isso é chamado de Firewall as a Service (FWaaS); ele introduz uma implantação simplificada e elimina a necessidade de confiar no BGP e no ECMP para distribuir o tráfego em várias instâncias do Amazon EC2.
## Considerações importantes
+ Os dispositivos precisam suportar o protocolo de encapsulamento [Geneve](https://datatracker.ietf.org/doc/html/rfc8926) para se integrarem ao GWLB.
+ Alguns dispositivos de terceiros podem suportar roteamento SNAT e sobreposição ([modo de dois braços](https://networkgeekstuff.com/networking/basic-load-balancer-scenarios-explained/)), eliminando assim a necessidade de criar gateways NAT para economizar custos. No entanto, consulte um parceiro da AWS de sua escolha antes de usar esse modo, pois isso depende do suporte e da implementação do fornecedor.
+ Anote o tempo limite de [inatividade do GWLB](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/gateway-load-balancers.html#idle-timeout). Isso pode resultar em tempos limite de conexão nos clientes. Você pode ajustar seus tempos limite no nível do cliente, servidor, firewall e sistema operacional para evitar isso. Consulte a *Seção 1: Ajuste os valores de manutenção de atividade ou tempo limite de TCP para oferecer suporte a fluxos de TCP de longa duração* na postagem do blog Melhores práticas [para implantar o Gateway Load Balancer para obter](https://aws.amazon.com/blogs/networking-and-content-delivery/best-practices-for-deploying-gateway-load-balancer/) mais informações.
+ Os GWLBE são alimentados por AWS PrivateLink, portanto, AWS PrivateLink as taxas serão aplicáveis. Você pode saber mais na [página AWS PrivateLink de preços](https://aws.amazon.com/privatelink/pricing/). Se você estiver usando o modelo centralizado com o Transit Gateway, as taxas de processamento de dados do TGW serão aplicáveis.
+ Considere implantar o Transit Gateway e a VPC de saída em uma conta separada de serviços de rede para segregar o acesso com base na delegação de tarefas, como por exemplo, somente administradores de rede podem acessar a conta de serviços de rede.
# Saída centralizada para IPv6
Para oferecer suporte à IPv6 saída em implantações de pilha dupla que tenham IPv4 saída centralizada, um dos dois padrões deve ser escolhido:
+ Saída centralizada com IPv4 saída descentralizada IPv6
+ Saída centralizada e IPv4 saída centralizada IPv6
No primeiro padrão, mostrado no diagrama a seguir, gateways de internet somente de saída são implantados em cada VPC spoke. Os gateways de internet somente de saída são gateways escalonados horizontalmente, redundantemente e altamente disponíveis que permitem a comunicação de saída a partir de instâncias dentro da sua VPC. IPv6 Eles impedem que a Internet inicie IPv6 conexões com suas instâncias. Os gateways de internet somente para saída são gratuitos. Nesse modelo de implantação, o IPv6 tráfego flui dos gateways de Internet somente de saída em cada VPC e o IPv4 tráfego flui pelos gateways NAT centralizados implantados.
![\[Um diagrama que descreve a saída centralizada e a IPV4 saída descentralizada somente para saída. IPv6\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/centralized-ipv4-egress-and-decentralized-outbound-ipv6.png)
No segundo padrão, mostrado nos diagramas a seguir, o IPv6 tráfego de saída das suas instâncias é enviado para uma VPC centralizada. Isso pode ser feito usando IPv6 -to- IPv6 Network Prefix Translation (NPTv6) com NAT66 instâncias e gateways NAT ou usando instâncias de proxy e Network Load Balancer. Esse padrão é aplicável se a inspeção centralizada do tráfego de saída for necessária e não puder ser executada em cada VPC de fala.
![\[Um diagrama que mostra a IPv6 saída centralizada usando gateways e instâncias NAT. NAT66\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/centralized-ipv6-egress-using-nat-gateways.png)
![\[Um diagrama que mostra centralização IPv4 e IPv6 saída usando instâncias de proxy e Network Load Balancer.\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/centralized-ipv4-and-ipv6-egress.png)
O [whitepaper IPv6 na AWS](https://docs.aws.amazon.com/whitepapers/latest/ipv6-on-aws/advanced-dual-stack-and-ipv6-only-network-designs.html) descreve os padrões de saída centralizados IPv6 . Os padrões de IPv6 saída são discutidos com mais detalhes no blog [Tráfego centralizado de saída da Internet para pilha dupla IPv4 e IPv6 VPCs](https://aws.amazon.com/blogs/networking-and-content-delivery/centralizing-outbound-internet-traffic-for-dual-stack-ipv4-and-ipv6-vpcs/), junto com considerações especiais, exemplos de soluções e diagramas.