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.
# Conectividad de red para una arquitectura de varias cuentas
## Conectando VPCs
Muchas empresas utilizan la interconexión de VPC en Amazon Virtual Private Cloud (Amazon VPC) para conectar el desarrollo y la producción. VPCs Con una conexión de emparejamiento de VPC, puede enrutar el tráfico entre dos VPCs mediante un direccionamiento IP privado. Lo conectado VPCs puede estar en diferentes Cuentas de AWS y en diferentes. Regiones de AWS Para obtener más información, consulte [¿Qué es una interconexión de VPC?](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) (documentación de Amazon VPC). A medida que las empresas crecen y el número de ellas VPCs aumenta, mantener conexiones interconectadas entre todas ellas VPCs puede convertirse en una carga de mantenimiento. También puede estar limitado por la cantidad máxima de conexiones de emparejamiento de VPC por VPC. Para obtener más información, consulte [Cuota de conexiones de emparejamiento de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html#vpc-limits-peering) (documentación de Amazon VPC).
Si tiene varios entornos de desarrollo, pruebas y almacenamiento provisional que alojan datos que no son de producción en varios de ellos Cuentas de AWS, puede que desee proporcionar conectividad de red entre todos ellos, VPCs pero no permitir el acceso a los entornos de producción. Se puede utilizar [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)para conectar varias cuentas a VPCs través de varias cuentas. Puede separar las tablas de enrutamiento para evitar que el desarrollo VPCs se comunique con la producción a VPCs través de la pasarela de tránsito, que actúa como router centralizado. Para obtener más información, consulte [Enrutador centralizado](https://docs.aws.amazon.com/vpc/latest/tgw/transit-gateway-centralized-router.html) (documentación de Transit Gateway).
Transit Gateway también admite la interconexión con otras puertas de enlace de tránsito, incluidas las de diferentes Cuentas de AWS o Regiones de AWS. Como Transit Gateway es un servicio totalmente administrado y de alta disponibilidad, solo necesita aprovisionar una puerta de enlace de tránsito para cada región.
Para obtener más información y arquitecturas de red detalladas, consulte [Creación de una infraestructura de AWS red multiVPC escalable y segura](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/welcome.html) (AWS documento técnico).
## Conexión de aplicaciones
Si necesita establecer la comunicación entre aplicaciones diferentes Cuentas de AWS en el mismo entorno (como el de producción), puede utilizar una de las siguientes opciones:
+ [La interconexión de VPC](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) o [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) pueden brindar conectividad a nivel de red si desea abrir un amplio acceso a varios puertos y direcciones IP.
+ [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) crea puntos de conexión en una subred privada de la VPC y estos puntos de conexión se registran como entradas de DNS en [Amazon Route 53 Resolver](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html). Al usar DNS, las aplicaciones pueden resolver los puntos de conexión y conectarse a los servicios registrados, sin la necesidad de puertas de enlace NAT o puertas de enlace de Internet en la VPC.
+ [Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/what-is-vpc-service-network.html) asocia servicios, como aplicaciones, a varias cuentas VPCs y los recopila en una red de servicios. Los clientes VPCs asociados a la red de servicios pueden enviar solicitudes a todos los demás servicios asociados a la red de servicios, independientemente de si se encuentran en la misma cuenta. VPC Lattice se integra con AWS Resource Access Manager (AWS RAM) para que pueda compartir recursos con otras cuentas o a través de ellas. AWS Organizations Puede asociar una VPC a una sola red de servicio. Esta solución no requiere el uso de interconexiones de VPC o AWS Transit Gateway para comunicarse entre cuentas.
## Prácticas recomendadas para la conectividad de red
+ Cree una Cuenta de AWS que utilice para la red centralizada. Asigne el nombre **network-prod** a esta cuenta y utilícela para AWS Transit Gateway Amazon [VPC IP Address](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html) Manager (IPAM). Agregue esta cuenta a la unidad organizativa **Infrastructure\$1Prod**.
+ Utilice [AWS Resource Access Manager](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html) (AWS RAM) para compartir la puerta de enlace de tránsito, las redes de servicios de VPC Lattice y los grupos de IPAM con el resto de la organización. Esto permite que cualquier miembro Cuenta de AWS de su organización interactúe con estos servicios.
+ Al utilizar los grupos de IPAM para gestionar IPv4 y IPv6 abordar las asignaciones de forma centralizada, puede permitir que sus usuarios finales se aprovisionen ellos mismos VPCs mediante el uso de [AWS Service Catalog](https://aws.amazon.com/servicecatalog/) Esto le ayuda a dimensionar adecuadamente los espacios de direcciones IP VPCs y a evitar que se superpongan.
+ Utilice un enfoque de salida centralizado para el tráfico vinculado a Internet y un enfoque de entrada descentralizado para el tráfico que llegue a su entorno desde Internet. Para obtener más información, consulte [Salida centralizada](centralized-egress.md) y [Entrada descentralizada](decentralized-ingress.md).
# Salida centralizada
La *salida centralizada* es el principio de utilizar un único punto de entrada común para todo el tráfico de red que se destina a Internet. Puede configurar la inspección en este punto de entrada y permitir el tráfico solo a dominios específicos o solo a través de puertos o protocolos específicos. La centralización de las salidas también puede ayudarlo a reducir los costos, ya que elimina la necesidad de implementar pasarelas NAT en cada uno de sus VPCs puertos para poder conectarse a Internet. Esto es beneficioso desde el punto de vista de la seguridad, ya que limita la exposición a recursos maliciosos de acceso externo, como la infraestructura de comando y control (CyC) de malware. Para obtener más información y opciones de arquitectura para la salida centralizada, consulte Salida [centralizada a Internet (documento técnico](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-egress-to-internet.html)).AWS
Puede usar [AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/what-is-aws-network-firewall.html), que es un firewall de red administrado y con estado y un servicio de detección y prevención de intrusiones, como punto de inspección central del tráfico de salida. Este firewall se configura en una VPC dedicada para el tráfico de salida. Network Firewall admite reglas con estado que puede usar para limitar el acceso a Internet a dominios específicos. Para obtener más información, consulte [Filtrado de dominios](https://docs.aws.amazon.com/network-firewall/latest/developerguide/suricata-examples.html#suricata-example-domain-filtering)(documentación de Network Firewall).
También puede usar [Firewall de DNS de Amazon Route 53 Resolver](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall.html) para limitar el tráfico de salida a nombres de dominio específicos, principalmente para evitar la exfiltración no autorizada de sus datos. En las reglas del firewall de DNS, puede aplicar [listas de dominios](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-domain-lists.html) (documentación de Route 53), que permiten o deniegan el acceso a dominios específicos. Puede utilizar listas de dominios AWS gestionadas, que contienen nombres de dominio asociados a actividades malintencionadas u otras amenazas potenciales, o puede crear listas de dominios personalizadas. Puede crear grupos de reglas del firewall de DNS y, a continuación, aplicarlos a los suyos VPCs. Las solicitudes de DNS salientes se enrutan a través de un Resolver en la VPC para la resolución de nombres de dominio, y el firewall de DNS filtra las solicitudes en función de los grupos de reglas aplicados a la VPC. Las solicitudes de DNS recursivas que se envían al Resolver no fluyen a través de la puerta de enlace de tránsito ni de la ruta de Network Firewall. Route 53 Resolver y el firewall de DNS deben considerarse una ruta de salida independiente de la VPC.
En la imagen siguiente, se muestra un ejemplo de arquitectura para salida centralizada. Antes de que comience la comunicación de red, las solicitudes de DNS se envían al Route 53 Resolver, donde el firewall de DNS permite o deniega la resolución de la dirección IP utilizada para la comunicación. El tráfico destinado a Internet se enruta a una puerta de enlace de tránsito en una cuenta de red centralizada. La puerta de enlace de tránsito reenvía el tráfico a Network Firewall para su inspección. Si la política de firewall permite el tráfico de salida, el tráfico pasa a través de una puerta de enlace NAT, a través de una puerta de enlace de Internet y se luego a Internet. Puede usarlo AWS Firewall Manager para administrar de forma centralizada los grupos de reglas del Firewall de DNS y las políticas de Network Firewall en toda su infraestructura de cuentas múltiples.
![\[Enrutamiento del tráfico desde otras cuentas a través de la cuenta de red y hacia Internet.\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/images/3_egress.png)
## Prácticas recomendadas para proteger el tráfico de salida
+ Comience en [modo de solo registro](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-rule-actions.html) (documentación de Route 53). Cambie al modo de bloqueo después de haber validado que el tráfico legítimo no se ve afectado.
+ Bloquee el tráfico de DNS que va a Internet mediante [AWS Firewall Manager políticas para las listas de control de acceso a la red](https://docs.aws.amazon.com/waf/latest/developerguide/getting-started-fms-network-acl.html) o mediante AWS Network Firewall. Todas las consultas de DNS deben enrutarse a través de un Route 53 Resolver, donde puede supervisarlas con Amazon GuardDuty (si está habilitado) y filtrarlas con el [firewall DNS de Route 53 Resolver](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall.html) (si está habilitado). Para obtener más información, consulte [Resolución de consultas de DNS entre VPCs y su red](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-overview-DSN-queries-to-vpc.html) (documentación de Route 53).
+ Utilice las [Listas de dominios administradas de AWS](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-managed-domain-lists.html) (documentación de Route 53) en firewall de DNS y Network Firewall.
+ Considere bloquear los dominios de nivel superior no utilizados y de alto riesgo, como .info, .top, .xyz o algunos dominios de código de país.
+ Considere bloquear los puertos no utilizados y de alto riesgo, como los puertos 1389, 4444, 3333, 445, 135, 139 o 53.
+ Como punto de partida, puede usar una lista de denegaciones que incluya las reglas AWS administradas. A continuación, podrá trabajar poco a poco para implementar un modelo de lista de permitidos. *Por ejemplo, en lugar de incluir solo una lista estricta de nombres de dominio totalmente cualificados en la lista de dominios permitidos, comience por utilizar algunos caracteres comodín, como \$1.example.com.* Incluso puedes permitir solo los dominios de nivel superior que esperes y bloquear todos los demás. Luego, con el tiempo, redúzcalos también.
+ Utilice [los perfiles de Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/profiles.html) (documentación de Route 53) para aplicar configuraciones de Route 53 relacionadas con el DNS en muchas VPCs y diferentes configuraciones. Cuentas de AWS
+ Defina un proceso para gestionar las excepciones a estas mejores prácticas.
# Entrada descentralizada
La *entrada descentralizada* es el principio que define, a nivel de cuenta individual, cómo el tráfico de Internet llega a las cargas de trabajo de esa cuenta. En las arquitecturas de varias cuentas, una de las ventajas de la entrada descentralizada es que cada cuenta puede usar el servicio o recurso de entrada más adecuado para sus cargas de trabajo, como un equilibrador de carga de aplicación, Amazon API Gateway o un Equilibrador de carga de red.
Si bien el ingreso descentralizado significa que debe administrar cada cuenta de forma individual, puede administrar y mantener sus configuraciones de forma centralizada mediante [AWS Firewall Manager](https://docs.aws.amazon.com/waf/latest/developerguide/fms-chapter.html). Firewall Manager admite protecciones como [AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/waf-chapter.html) y [Grupos de seguridad de Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html). Puede asociarse AWS WAF a un Application Load Balancer CloudFront, Amazon, API Gateway o. AWS AppSync Si utiliza una VPC de salida y una puerta de enlace de tránsito, como se describe en [Salida centralizada](centralized-egress.md), cada VPC de radio contiene subredes públicas y privadas. Sin embargo, no es necesario implementar puertas de enlace NAT porque el tráfico se enruta a través de la VPC de salida de la cuenta de red.
La siguiente imagen muestra un ejemplo de una persona Cuenta de AWS que tiene una sola VPC que contiene una carga de trabajo accesible a través de Internet. El tráfico de Internet accede a la VPC a través de una puerta de enlace de Internet y llega a los servicios de equilibrio de carga y seguridad alojados en una subred pública. (Una *subred pública* contiene una ruta predeterminada hacia una puerta de enlace de Internet). Implemente balanceadores de carga en subredes públicas y adjunte listas de control de AWS WAF acceso (ACLs) para protegerse contra el tráfico malintencionado, como las secuencias de comandos entre sitios. Implemente cargas de trabajo que alojen aplicaciones en *subredes privadas*, que no tienen acceso directo a Internet ni desde ella.
![\[Tráfico de Internet que accede a una VPC a través de una puerta de enlace a Internet y AWS WAF balanceadores de carga.\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/images/4_ingress.png)
Si tiene muchos VPCs en su organización, es posible que desee compartir lo común Servicios de AWS mediante la creación de puntos de enlace de VPC de interfaz o zonas alojadas privadas en una interfaz dedicada y compartida. Cuenta de AWS Para obtener más información, consulte [Acceder y Servicio de AWS utilizar un punto final de VPC de interfaz](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) (AWS PrivateLink documentación) y [Trabajar con zonas alojadas privadas](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html) (documentación de Route 53).
La siguiente imagen muestra un ejemplo de una Cuenta de AWS que aloja recursos que se pueden compartir en toda la organización. Los puntos de conexión de VPC se pueden compartir en varias cuentas al crearlos en una VPC dedicada. Al crear un punto de conexión de VPC, de forma opcional, puede hacer que AWS administre las entradas de DNS del punto de conexión. Para compartir un punto de conexión, desactive esta opción y cree las entradas de DNS en una zona alojada privada (PHZ) de Route 53 independiente. A continuación, puede asociar el PHZ a todos los componentes de su organización para obtener una resolución de DNS centralizada de los puntos finales de la VPC. VPCs También debe asegurarse de que las tablas de enrutamiento de la puerta de enlace de tránsito incluyan rutas de la VPC compartida a la otra. VPCs Para obtener más información, consulte [Acceso centralizado a los puntos finales de la interfaz de la VPC](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-access-to-vpc-private-endpoints.html#interface-vpc-endpoints) (AWS documento técnico).
![\[Una cuenta compartida que aloja los puntos finales de servicio y los recursos para compartirlos con las cuentas de otros miembros.\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/images/5_shared.png)
Una cuenta compartida también Cuenta de AWS es un buen lugar para alojar AWS Service Catalog carteras. Una *cartera* es un conjunto de servicios de TI en los que desea que estén disponibles para su implementación AWS, y la cartera contiene información de configuración de esos servicios. Puede crear las carteras en la cuenta compartida, compartirlas con la organización y, a continuación, cada cuenta de miembro importa la cartera a su propia instancia regional de Service Catalog. Para obtener más información, consulte [Compartir con AWS Organizations](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/catalogs_portfolios_sharing_how-to-share.html#portfolio-sharing-organizations) (documentación de Service Catalog).
Del mismo modo, con Amazon VPC Lattice, puede usar la cuenta compartida para administrar de forma centralizada el entorno y las plantillas de servicio como entidades y, a continuación, configurar las conexiones de las cuentas con las cuentas de los miembros de la organización. Para obtener más información, consulte [Compartir sus entidades de VPC Lattice (](https://docs.aws.amazon.com/vpc-lattice/latest/ug/sharing.html)documentación de VPC Lattice).