Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés. # Salida centralizada a Internet A medida que despliegues aplicaciones en tu entorno de múltiples cuentas, muchas de ellas requerirán acceso a Internet únicamente de forma saliente (por ejemplo, para descargar bibliotecas, parches o actualizaciones del sistema operativo). Esto se puede lograr tanto para el tráfico IPv4 como para el IPv6. En el caso de IPv4, esto se puede lograr mediante la traducción de direcciones de red (NAT) en forma de puerta de enlace NAT (se recomienda) o, alternativamente, mediante una instancia de NAT autogestionada que se ejecute en una instancia de Amazon EC2, como medio para todos los accesos de salida a Internet. Las aplicaciones internas residen en subredes privadas, mientras que las instancias NAT de NAT y Amazon EC2 residen en una subred pública. AWS recomienda utilizar puertas de enlace NAT porque ofrecen mejor disponibilidad y ancho de banda y requieren menos esfuerzo de su parte para administrarlas. Para obtener más información, consulte [Comparación de pasarelas NAT e instancias](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-comparison.html) de NAT. Para IPv6 el tráfico, el tráfico de salida se puede configurar para que salga de cada VPC a través de una puerta de enlace de Internet de solo salida de forma descentralizada o se puede configurar para que se envíe a una VPC centralizada mediante instancias de NAT o instancias de proxy. Los IPv6 patrones se describen en. [Salida centralizada para IPv6](centralized-egress-for-ipv6.md) **Topics** + [Uso de la puerta de enlace NAT para la IPv4 salida centralizada](using-nat-gateway-for-centralized-egress.md) + [Uso de la puerta de enlace NAT AWS Network Firewall para una IPv4 salida centralizada](using-nat-gateway-with-firewall.md) + [Uso de la puerta de enlace NAT y el Load Balancer de puerta de enlace con instancias de Amazon EC2 para una salida centralizada IPv4](using-nat-gateway-and-gwlb-with-ec2.md) + [Salida centralizada para IPv6](centralized-egress-for-ipv6.md) # Uso de la puerta de enlace NAT para la IPv4 salida centralizada La puerta de enlace NAT es un servicio gestionado de traducción de direcciones de red. La implementación de una puerta de enlace NAT en todas las VPC radiales puede resultar prohibitiva, ya que se paga una tarifa por hora por cada puerta de enlace NAT que se implemente (consulte los precios de Amazon [VPC](https://aws.amazon.com/vpc/pricing/)). La centralización de las pasarelas NAT puede ser una opción viable para reducir los costos. Para centralizar, debe crear una VPC de salida independiente en la cuenta de servicios de red, implementar puertas de enlace NAT en la VPC de salida y enrutar todo el tráfico de salida del radio VPCs a las puertas de enlace NAT que residen en la VPC de salida mediante Transit Gateway o CloudWAN, como se muestra en la siguiente figura. **nota** Cuando centraliza la puerta de enlace NAT mediante Transit Gateway, paga un cargo adicional de procesamiento de datos de Transit Gateway, en comparación con el enfoque descentralizado de ejecutar una puerta de enlace NAT en cada VPC. En algunos casos extremos, cuando se envían grandes cantidades de datos a través de una puerta de enlace NAT desde una VPC, mantener la NAT local en la VPC para evitar el cargo por procesamiento de datos de Transit Gateway podría ser una opción más rentable. ![\[Un diagrama que muestra una arquitectura de puerta de enlace NAT descentralizada de alta disponibilidad\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/decentralized-ha-nat-gateway.png) ![\[Diagrama que muestra una puerta de enlace NAT centralizada mediante Transit Gateway (descripción general)\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/centralized-nat-gateway-tg.png) ![\[Un diagrama que muestra una puerta de enlace NAT centralizada que utiliza Transit Gateway (diseño de tabla de rutas)\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/nat-gateway-tg-rt.png) En esta configuración, los adjuntos de VPC radiales se asocian a la tabla de rutas 1 (RT1) y se propagan a la tabla de rutas 2 (). RT2 Existe una ruta [Blackhole](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-route-tables.html) para impedir que los dos se comuniquen VPCs entre sí. Si desea permitir la comunicación entre VPC, puede eliminar la entrada de `10.0.0.0/8 -> Blackhole` ruta de. RT1 Esto les permite comunicarse a través de la pasarela de tránsito. También puede propagar los archivos adjuntos RT1 de la VPC radial (o, como alternativa, puede utilizar una tabla de enrutamiento associate/propagate y todo lo demás), lo que permite un flujo de tráfico directo entre las VPCs Transit Gateway que utilice. Agrega una ruta estática para dirigir todo el RT1 tráfico a la VPC de salida. Debido a esta ruta estática, Transit Gateway envía todo el tráfico de Internet a través ENIs de su VPC de salida. Una vez en la VPC de salida, el tráfico sigue las rutas definidas en la tabla de rutas de subred donde están presentes estas Transit Gateway. ENIs Agregue una ruta en las tablas de enrutamiento de subred que dirija todo el tráfico hacia la puerta de enlace NAT correspondiente en la misma zona de disponibilidad para minimizar el tráfico de la zona de disponibilidad cruzada (AZ). La tabla de rutas de subred de la puerta de enlace NAT tiene la puerta de enlace a Internet (IGW) como siguiente salto. Para que el tráfico de retorno regrese, debe añadir una entrada de tabla de enrutamiento estática en la tabla de enrutamiento de subred de la puerta de enlace NAT que dirija todo el tráfico radiado vinculado a la VPC a Transit Gateway como siguiente salto. ## Alta disponibilidad Para obtener una alta disponibilidad, debe usar más de una puerta de enlace NAT (una en cada zona de disponibilidad). Si una puerta de enlace NAT no está disponible, es posible que se interrumpa el tráfico en la zona de disponibilidad que atraviesa la puerta de enlace NAT afectada. Si una zona de disponibilidad no está disponible, el punto final de Transit Gateway junto con la puerta de enlace NAT de esa zona de disponibilidad fallarán y todo el tráfico fluirá a través de los puntos de enlace de Transit Gateway y NAT de la otra zona de disponibilidad. ## Seguridad Puede confiar en los grupos de seguridad de las instancias de origen, en las rutas de agujero negro de las tablas de rutas de Transit Gateway y en la ACL de red de la subred en la que se encuentra la puerta de enlace NAT. Por ejemplo, los clientes pueden utilizar ACLs las subredes públicas de la puerta de enlace NAT para permitir o bloquear las direcciones IP de origen o destino. Como alternativa, puede utilizar la puerta de enlace NAT con AWS Network Firewall la salida centralizada que se describe en la siguiente sección para cumplir con este requisito. ## Escalabilidad Una sola puerta de enlace NAT puede admitir hasta 55 000 conexiones simultáneas por dirección IP asignada a cada destino único. Puede solicitar un ajuste de cuota para permitir la asignación de hasta ocho direcciones IP, lo que permitirá establecer 440 000 conexiones simultáneas a un único puerto e IP de destino. La puerta de enlace NAT proporciona 5 Gbps de ancho de banda y se amplía automáticamente a 100 Gbps. Por lo general, Transit Gateway no actúa como un equilibrador de carga y no distribuiría el tráfico de manera uniforme entre las puertas de enlace NAT de las múltiples zonas de disponibilidad. Si es posible, el tráfico a través de Transit Gateway permanecerá dentro de una zona de disponibilidad. Si la instancia de Amazon EC2 que inicia el tráfico se encuentra en la zona de disponibilidad 1, el tráfico saldrá de la interfaz de red elástica Transit Gateway en la misma zona de disponibilidad 1 de la VPC de salida y pasará al siguiente salto en función de la tabla de enrutamiento de subred en la que reside la interfaz de red elástica. Para obtener una lista completa de reglas, consulte las [pasarelas NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) en la documentación de Amazon Virtual Private Cloud. Para obtener más información, consulte la entrada del blog sobre [cómo crear un único punto de salida de Internet a partir de varios dispositivos 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/). # Uso de la puerta de enlace NAT AWS Network Firewall para una IPv4 salida centralizada Si desea inspeccionar y filtrar el tráfico saliente, puede incorporar AWS Network Firewall con puerta de enlace NAT en su arquitectura de salida centralizada. AWS Network Firewall es un servicio gestionado que facilita la implementación de las protecciones de red esenciales para todos sus dispositivos. VPCs Proporciona control y visibilidad del tráfico de red de capa 3 a 7 para toda la VPC. Puede filtrar el tráfico saliente por URL/domain nombre, dirección IP y contenido para evitar posibles pérdidas de datos, cumplir con los requisitos de conformidad y bloquear las comunicaciones de malware conocidas. AWS Network Firewall admite miles de reglas que pueden filtrar el tráfico de red destinado a direcciones IP o nombres de dominio incorrectos conocidos. También puede utilizar las reglas IPS de Suricata como parte del AWS Network Firewall servicio importando conjuntos de reglas de código abierto o creando sus propias reglas del Sistema de Prevención de Intrusiones (IPS) mediante la sintaxis de reglas de Suricata. AWS Network Firewall también le permite importar reglas compatibles procedentes de socios de AWS. En la arquitectura de salida centralizada con inspección, el AWS Network Firewall punto final es un objetivo de la tabla de enrutamiento predeterminado en la tabla de enrutamiento de subred adjunta a la pasarela de tránsito para la VPC de salida. El tráfico entre los radios VPCs e Internet se inspecciona AWS Network Firewall tal como se muestra en el siguiente diagrama. ![\[Un diagrama que muestra la salida centralizada con AWS Network Firewall una puerta de enlace NAT (diseño de tabla de enrutamiento)\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/centralized-egress-rt.png) Para un modelo de implementación centralizada con Transit Gateway, AWS recomienda implementar AWS Network Firewall puntos de enlace en varias zonas de disponibilidad. Debe haber un punto final de firewall en cada zona de disponibilidad en la que el cliente ejecute las cargas de trabajo, como se muestra en el diagrama anterior. Como práctica recomendada, la subred del firewall no debe contener ningún otro tráfico porque AWS Network Firewall no puede inspeccionar el tráfico procedente de las fuentes o los destinos dentro de una subred de firewall. Al igual que en la configuración anterior, los adjuntos de VPC radiales se asocian a la tabla de rutas 1 (RT1) y se propagan a la tabla de rutas 2 (). RT2 Se añade explícitamente una ruta Blackhole para impedir que ambas se comuniquen VPCs entre sí. Siga utilizando una ruta predeterminada para dirigir todo el RT1 tráfico a la VPC de salida. Transit Gateway reenviará todos los flujos de tráfico a una de las dos zonas de disponibilidad de la VPC de salida. Una vez que el tráfico llega a una de las Transit Gateway ENIs de la VPC de salida, se llega a una ruta predeterminada que reenviará el tráfico a uno de AWS Network Firewall los puntos finales de su zona de disponibilidad correspondiente. AWS Network Firewall A continuación, inspeccionará el tráfico según las reglas que haya establecido antes de reenviar el tráfico a la puerta de enlace NAT mediante una ruta predeterminada. Este caso no requiere el modo de dispositivo Transit Gateway, ya que no se envía tráfico entre archivos adjuntos. **nota** AWS Network Firewall no realiza la traducción de direcciones de red por usted; esta función la gestionaría la puerta de enlace NAT tras inspeccionar el tráfico a través del AWS Network Firewall. En este caso, no se requiere el enrutamiento de entrada, ya que el tráfico de retorno se reenviará al NATGW IPs de forma predeterminada. Como está utilizando una Transit Gateway, aquí podemos colocar el firewall antes de la puerta de enlace NAT. En este modelo, el firewall puede ver la IP de origen detrás de la Transit Gateway. Si lo hacía en una sola VPC, podemos usar las mejoras de enrutamiento de la VPC que le permiten inspeccionar el tráfico entre subredes de la misma VPC. Para obtener más información, consulta la entrada del blog sobre [modelos de implementación para AWS Network Firewall mejoras de enrutamiento de VPC](https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall-with-vpc-routing-enhancements/). ## Escalabilidad AWS Network Firewall puede aumentar o reducir automáticamente la capacidad del firewall en función de la carga de tráfico para mantener un rendimiento estable y predecible y minimizar los costes. AWS Network Firewall está diseñado para admitir decenas de miles de reglas de firewall y puede ampliarse hasta 100 Gbps por zona de disponibilidad. ## Consideraciones clave + Cada punto final del firewall puede gestionar unos 100 Gbps de tráfico. Si necesita una ráfaga mayor o un rendimiento sostenido, póngase en contacto con el soporte de [AWS](https://docs.aws.amazon.com/awssupport/latest/user/getting-started.html). + Si decide crear una puerta de enlace NAT en su cuenta de AWS junto con Network Firewall, no se cobrarán los [cargos](https://aws.amazon.com/network-firewall/pricing/) de procesamiento estándar de la puerta de enlace NAT ni de uso por hora, sino one-to-one que se cobrarán el procesamiento por GB y las horas de uso del firewall. + También puede considerar la posibilidad de utilizar puntos finales de firewall distribuidos AWS Firewall Manager sin Transit Gateway. + Pruebe las reglas del firewall antes de pasarlas a producción, de forma similar a una lista de control de acceso a la red, ya que el orden importa. + Se requieren reglas avanzadas de Suricata para una inspección más profunda. El firewall de red admite la inspección del tráfico cifrado tanto para el tráfico de entrada como para el de salida. + La variable del grupo de `HOME_NET` reglas definió el rango de IP de origen que podía procesarse en el motor Stateful. Si utiliza un enfoque centralizado, debe añadir todos los VPC adicionales CIDRs conectados a la Transit Gateway para que puedan procesarse. Consulte la [documentación de Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/stateful-rule-groups-domain-names.html) para obtener más información sobre la variable del grupo de `HOME_NET` reglas. + Considere la posibilidad de implementar Transit Gateway y la VPC de egreso en una cuenta de servicios de red independiente para segregar el acceso en función de la delegación de funciones; por ejemplo, solo los administradores de red pueden acceder a la cuenta de servicios de red. + Para simplificar la implementación y la administración de AWS Network Firewall este modelo, AWS Firewall Manager se puede utilizar. Firewall Manager le permite administrar de forma centralizada sus diferentes firewalls al aplicar automáticamente la protección que cree en la ubicación centralizada a varias cuentas. Firewall Manager admite modelos de implementación distribuidos y centralizados para Network Firewall. Para obtener más información, consulte la entrada del blog [Cómo implementar AWS Network Firewall mediante el uso AWS Firewall Manager](https://aws.amazon.com/blogs/security/how-to-deploy-aws-network-firewall-by-using-aws-firewall-manager/). # Uso de la puerta de enlace NAT y el Load Balancer de puerta de enlace con instancias de Amazon EC2 para una salida centralizada IPv4 El uso de un dispositivo virtual basado en software (en Amazon EC2) AWS Marketplace desde AWS Partner Network y como punto de salida es similar a la configuración de la puerta de enlace NAT. Esta opción se puede utilizar si desea utilizar las capacidades avanzadas de inspección profunda de paquetes (capa 7rewall/Intrusion Prevention/Detection System (IPS/IDS) y de inspección profunda de paquetes que ofrecen los distintos proveedores. En la siguiente figura, además de la puerta de enlace NAT, se implementan dispositivos virtuales mediante instancias EC2 detrás de un Gateway Load Balancer (GWLB). En esta configuración, la GWLB, el Gateway Load Balancer Endpoint (GWLBE), los dispositivos virtuales y las puertas de enlace NAT se implementan en una VPC centralizada que se conecta a Transit Gateway mediante un adjunto de VPC. Los radios también VPCs se conectan a la Transit Gateway mediante un accesorio de VPC. Como GWLBEs se trata de un objetivo enrutable, puede enrutar el tráfico que se mueve hacia y desde Transit Gateway a la flota de dispositivos virtuales que están configurados como objetivos detrás de un GWLB. El GWLB actúa como un dispositivo virtual de terceros bump-in-the-wire y lo transfiere de forma transparente a través de dispositivos virtuales de terceros y, por lo tanto, es invisible para el origen y el destino del tráfico. Por lo tanto, esta arquitectura le permite inspeccionar de forma centralizada todo el tráfico de salida que pasa por Transit Gateway. Para obtener más información sobre cómo fluye el tráfico de las aplicaciones a Internet y viceversa VPCs a través de esta configuración, consulte [Arquitectura de inspección centralizada con AWS Gateway Load Balancer](https://aws.amazon.com/blogs/networking-and-content-delivery/centralized-inspection-architecture-with-aws-gateway-load-balancer-and-aws-transit-gateway/) y. AWS Transit Gateway Puede activar el modo dispositivo en Transit Gateway para mantener la simetría del flujo a través de los dispositivos virtuales. Esto significa que el tráfico bidireccional se enruta a través del mismo dispositivo y de la zona de disponibilidad durante todo el flujo. Esta configuración es especialmente importante para los firewalls con estado que realizan una inspección profunda de paquetes. La activación del modo dispositivo elimina la necesidad de soluciones alternativas complejas, como la traducción de direcciones de red de origen (SNAT), que obligan al tráfico a volver al dispositivo correcto para mantener la simetría. Consulte [las prácticas recomendadas para implementar Gateway Load Balancer](https://aws.amazon.com/blogs/networking-and-content-delivery/best-practices-for-deploying-gateway-load-balancer/) para obtener más información. También es posible implementar puntos finales de GWLB de forma distribuida sin Transit Gateway para permitir la inspección de egreso. Obtenga más información sobre este patrón arquitectónico en la entrada del 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 diagrama que muestra la salida centralizada con Gateway Load Balancer e instancia EC2 (diseño de tabla de rutas)\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/centralized-egress-gwlb-and-ec2.png) ## Alta disponibilidad AWS recomienda implementar balanceadores de carga de Gateway y dispositivos virtuales en varias zonas de disponibilidad para aumentar la disponibilidad. Gateway Load Balancer puede realizar comprobaciones de estado para detectar errores en los dispositivos virtuales. En caso de que un dispositivo no funcione correctamente, GWLB redirige los nuevos flujos a dispositivos en buen estado. Los flujos existentes siempre se dirigen al mismo objetivo, independientemente del estado de salud del objetivo. Esto permite que la conexión se agote y se adapta a las fallas en las comprobaciones de estado causadas por picos de CPU en los dispositivos. Para obtener más información, consulte la sección 4: Conozca los escenarios de error del dispositivo y la zona de disponibilidad en la entrada del blog [Mejores prácticas para implementar Gateway Load Balancer](https://aws.amazon.com/blogs/networking-and-content-delivery/best-practices-for-deploying-gateway-load-balancer/). Gateway Load Balancer puede usar grupos de autoescalado como objetivos. Esta ventaja elimina la pesada tarea de administrar la disponibilidad y la escalabilidad de las flotas de dispositivos. ## Ventajas Los puntos finales Gateway Load Balancer y Gateway Load Balancer funcionan con tecnología AWS PrivateLink, lo que permite el intercambio de tráfico a través de los límites de la VPC de forma segura sin necesidad de atravesar la Internet pública. Gateway Load Balancer es un servicio gestionado que elimina el pesado trabajo indiferenciado de gestionar, implementar y escalar dispositivos de seguridad virtuales para que pueda centrarse en las cosas que importan. Gateway Load Balancer puede exponer la pila de firewalls como un servicio de punto final al que los clientes pueden suscribirse mediante. [AWS Marketplace](https://aws.amazon.com/marketplace) Esto se denomina Firewall as a Service (FwaAS); introduce una implementación simplificada y elimina la necesidad de depender de BGP y ECMP para distribuir el tráfico entre varias instancias de Amazon EC2. ## Consideraciones clave + Los dispositivos deben ser compatibles con el protocolo de encapsulación [Geneve](https://datatracker.ietf.org/doc/html/rfc8926) para integrarse con el GWLB. + Algunos dispositivos de terceros admiten SNAT y el enrutamiento superpuesto ([modo de dos brazos](https://networkgeekstuff.com/networking/basic-load-balancer-scenarios-explained/)), lo que elimina la necesidad de crear puertas de enlace NAT para ahorrar costes. Sin embargo, consulte con un socio de AWS de su elección antes de utilizar este modo, ya que depende del soporte y la implementación del proveedor. + Tome nota del tiempo de espera de [inactividad del GWLB](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/gateway-load-balancers.html#idle-timeout). Esto puede provocar tiempos de espera de conexión en los clientes. Para evitarlo, puede ajustar los tiempos de espera a nivel de cliente, servidor, firewall y sistema operativo. Para obtener más información, consulte la *Sección 1: Ajustar los valores de mantenimiento o tiempo de espera de TCP para admitir flujos de TCP de larga duración* en la entrada del blog [Best practices for deploy Gateway Load Balancer](https://aws.amazon.com/blogs/networking-and-content-delivery/best-practices-for-deploying-gateway-load-balancer/). + Los GWLBE funcionan con tecnología GWLBE, por lo que se aplicarán cargos. AWS PrivateLink AWS PrivateLink Puedes obtener más información en la página de [AWS PrivateLink precios](https://aws.amazon.com/privatelink/pricing/). Si utiliza el modelo centralizado con Transit Gateway, se aplicarán los cargos por procesamiento de datos de TGW. + Considere la posibilidad de implementar Transit Gateway y la VPC de egreso en una cuenta de servicios de red independiente para segregar el acceso en función de la delegación de funciones, ya que solo los administradores de red pueden acceder a la cuenta de servicios de red. # Salida centralizada para IPv6 Para admitir la IPv6 salida en las implementaciones de doble pila que tienen una IPv4 salida centralizada, se debe elegir uno de estos dos patrones: + Salida centralizada con IPv4 salida descentralizada IPv6 + Salida centralizada y IPv4 salida centralizada IPv6 En el primer patrón, que se muestra en el siguiente diagrama, se implementan puertas de enlace de Internet solo de salida en cada VPC radial. Las puertas de enlace de Internet solo de salida son puertas de enlace de escalamiento horizontal, redundantes y de alta disponibilidad que permiten la comunicación saliente desde instancias dentro de su VPC. IPv6 Impiden que Internet inicie conexiones con las instancias. IPv6 Las pasarelas de Internet que solo permiten el acceso a Internet son gratuitas. En este modelo de implementación, el IPv6 tráfico sale de las puertas de enlace de Internet de solo salida en cada VPC y el IPv4 tráfico fluye a través de las puertas de enlace NAT centralizadas implementadas. ![\[Un diagrama que muestra la salida centralizada y la salida solo saliente descentralizada IPV4 . IPv6\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/centralized-ipv4-egress-and-decentralized-outbound-ipv6.png) En el segundo patrón, que se muestra en los siguientes diagramas, el IPv6 tráfico de salida de las instancias se envía a una VPC centralizada. Esto se puede lograr mediante la traducción IPv6 de prefijos de IPv6 red a la red (NPTv6) con NAT66 instancias y puertas de enlace NAT o mediante instancias proxy y Network Load Balancer. Este patrón se aplica si se requiere una inspección de tráfico centralizada para el tráfico saliente y no se puede realizar en cada VPC radial. ![\[Un diagrama que muestra la IPv6 salida centralizada mediante instancias y pasarelas de NAT. NAT66\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/centralized-ipv6-egress-using-nat-gateways.png) ![\[Un diagrama que muestra la centralización IPv4 y la IPv6 salida mediante instancias proxy y Network Load Balancer.\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/centralized-ipv4-and-ipv6-egress.png) El [documento técnico IPv6 sobre AWS](https://docs.aws.amazon.com/whitepapers/latest/ipv6-on-aws/advanced-dual-stack-and-ipv6-only-network-designs.html) describe los patrones de IPv6 salida centralizados. Los patrones de IPv6 salida se analizan con más detalle en el blog [Centralized Outbound Internet Traffic for Dual-Stack IPv4 y IPv6 VPCs](https://aws.amazon.com/blogs/networking-and-content-delivery/centralizing-outbound-internet-traffic-for-dual-stack-ipv4-and-ipv6-vpcs/), junto con consideraciones especiales, ejemplos de soluciones y diagramas.