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 VPC a VPC
*Los clientes pueden usar dos patrones de conectividad de VPC diferentes para configurar entornos de múltiples VPC: de *muchas a muchas* o de hub and spoke.* En many-to-many este enfoque, el tráfico entre cada VPC se administra individualmente entre cada VPC. En el hub-and-spoke modelo, todo el tráfico entre VPC fluye a través de un recurso central, que enruta el tráfico según las reglas establecidas.
# Emparejamiento de VPC
La primera forma de conectar dos VPCs es utilizar la interconexión de VPC. En esta configuración, una conexión permite una conectividad bidireccional total entre. VPCs Esta conexión de emparejamiento se utiliza para enrutar el tráfico entre. VPCs VPCs en diferentes cuentas y regiones de AWS también se pueden emparejar entre sí. Toda la transferencia de datos a través de una conexión de emparejamiento de VPC que permanezca dentro de una zona de disponibilidad es gratuita. Todas las transferencias de datos a través de una conexión de emparejamiento de VPC que atraviese las zonas de disponibilidad se cobran según las tarifas de transferencia de datos estándar de la región. Si VPCs se transfieren entre regiones, se aplicarán las tarifas estándar de transferencia de datos entre regiones.
[El emparejamiento de VPC es point-to-point conectividad y no admite el enrutamiento transitivo.](https://docs.aws.amazon.com/vpc/latest/peering/invalid-peering-configurations.html#transitive-peering) Por ejemplo, si tiene una conexión de [emparejamiento de VPC entre la VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html) A y la VPC B y entre la VPC A y la VPC C, una instancia de la VPC B no puede transitar por la VPC A para llegar a la VPC C. Para enrutar los paquetes entre la VPC B y la VPC C, debe crear una conexión de emparejamiento de VPC directa.
A gran escala, cuando tienes decenas o cientos de ellas VPCs, interconectarlas con el peering puede dar como resultado una malla de cientos o miles de conexiones peering. Una gran cantidad de conexiones puede resultar difícil de gestionar y escalar. Por ejemplo, si tiene 100 VPCs y desea configurar una interconexión de malla completa entre ellas, se necesitarán 4.950 conexiones de interconexión [`n(n-1)/2`], que `n` es el número total de. VPCs Hay un [límite máximo](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html) de 125 conexiones de emparejamiento activas por VPC.
![\[Un diagrama que muestra la configuración de la red mediante el emparejamiento de VPC\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/network-setup-vpc-peering.png)
Si utiliza la interconexión de VPC, se debe establecer una conectividad local (VPN y/o Direct Connect) con cada VPC. Los recursos de una VPC no pueden llegar a las instalaciones locales mediante la conectividad híbrida de una VPC interconectada, como se muestra en la figura anterior.
El emparejamiento de VPC se utiliza mejor cuando los recursos de una VPC deben comunicarse con los recursos de otra VPC, el entorno de ambas VPCs está controlado y protegido y el número de personas a conectar es inferior VPCs a 10 (para permitir la administración individual de cada conexión). La interconexión de VPC ofrece el costo total más bajo y el rendimiento agregado más alto en comparación con otras opciones de conectividad entre VPC.
# AWS Transit Gateway
[AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)ofrece un diseño de concentrador y radio para conexiones VPCs y redes locales como un servicio totalmente gestionado sin necesidad de aprovisionar dispositivos virtuales de terceros. No se requiere una superposición de VPN y AWS gestiona la alta disponibilidad y escalabilidad.
Transit Gateway permite a los clientes conectar miles de VPCs. Puede conectar toda su conectividad híbrida (conexiones VPN y Direct Connect) a una sola puerta de enlace, consolidando y controlando toda la configuración de AWS enrutamiento de su organización en un solo lugar (consulte la siguiente figura). Transit Gateway controla la forma en que se enruta el tráfico entre todas las redes radiales conectadas mediante tablas de enrutamiento. Este hub-and-spoke modelo simplifica la administración y reduce los costos operativos, ya que VPCs solo se conecta a la instancia de Transit Gateway para acceder a las redes conectadas.
![\[Un diagrama que muestra el diseño de ejes y radios con AWS Transit Gateway\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/hub-and-spoke-design.png)
Transit Gateway es un recurso regional y puede conectar miles de personas VPCs dentro del mismo Región de AWS. Puede conectar varias puertas de enlace a través de una única conexión Direct Connect para una conectividad híbrida. Normalmente, puedes usar una sola instancia de Transit Gateway para conectar todas las instancias de VPC de una región determinada y usar las tablas de enrutamiento de Transit Gateway para aislarlas donde sea necesario. Tenga en cuenta que no necesita pasarelas de tránsito adicionales para obtener una alta disponibilidad, ya que las pasarelas de tránsito están diseñadas con una alta disponibilidad; para mayor redundancia, utilice una única puerta de enlace en cada región. Sin embargo, hay motivos válidos para crear varias puertas de enlace para limitar los errores de configuración del radio de alcance y segregar las operaciones del plano de control y las administrativas. ease-of-use
Con la interconexión de Transit Gateway, los clientes pueden emparejar sus instancias de Transit Gateway dentro de la misma o de varias regiones y enrutar el tráfico entre ellas. Utiliza la misma infraestructura subyacente que la interconexión de VPC y, por lo tanto, está cifrada. Para obtener más información, consulte [Creación de una red global mediante el peering interregional de AWS Transit Gateway y AWS Transit Gateway ahora admite el peering](https://aws.amazon.com/blogs/networking-and-content-delivery/building-a-global-network-using-aws-transit-gateway-inter-region-peering/) [intrarregional](https://aws.amazon.com/blogs/networking-and-content-delivery/aws-transit-gateway-now-supports-intra-region-peering/).
Coloque la instancia de Transit Gateway de su organización en su cuenta de servicios de red. Esto permite la administración centralizada por parte de los ingenieros de red que administran la cuenta de servicios de red. Utilice AWS Resource Access Manager (RAM) para compartir una instancia de Transit Gateway y conectarse VPCs a varias cuentas de su organización de AWS dentro de la misma región.AWS RAM le permite compartir AWS recursos de forma fácil y segura con cualquier Cuenta de AWS organización de AWS o dentro de ella. Para obtener más información, consulte la sección [Automatización de los adjuntos de AWS Transit Gateway a una puerta de enlace de tránsito en una entrada de blog sobre una cuenta central](https://aws.amazon.com/blogs/networking-and-content-delivery/automating-aws-transit-gateway-attachments-to-a-transit-gateway-in-a-central-account/).
Transit Gateway también le permite establecer la conectividad entre la infraestructura SD-WAN y el AWS uso de Transit Gateway Connect. Utilice un accesorio Transit Gateway Connect con el Border Gateway Protocol (BGP) para el enrutamiento dinámico y el protocolo de túnel Generic Routing Encapsulation (GRE) para obtener un alto rendimiento, con un ancho de banda total de hasta 20 Gbps por cada accesorio Connect (hasta cuatro pares Transit Gateway Connect por cada accesorio Connect). Con Transit Gateway Connect, puede integrar tanto la infraestructura SD-WAN local como los dispositivos SD-WAN que se ejecutan en la nube mediante un adjunto de VPC o Direct Connect un adjunto como capa de transporte subyacente. Consulte [Simplifique la conectividad SD-WAN con AWS Transit Gateway Connect](https://aws.amazon.com/blogs/networking-and-content-delivery/simplify-sd-wan-connectivity-with-aws-transit-gateway-connect/) para ver las arquitecturas de referencia y la configuración detallada.
# Solución Transit VPC
[Transit VPCs](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/transit-vpc-option.html) puede crear conectividad entre ellas VPCs por un medio diferente al de la interconexión de VPC al introducir un diseño de hub and spoke para la conectividad entre VPC. En una red de VPC de tránsito, una VPC central (la VPC central) se conecta con todas las demás VPC (VPC habladas) a través de una conexión VPN que normalmente aprovecha BGP Over. [IPsec](https://en.wikipedia.org/wiki/IPsec) La VPC central contiene instancias de [Amazon Elastic Compute Cloud](https://aws.amazon.com/ec2/) EC2 (Amazon) que ejecutan dispositivos de software que enrutan el tráfico entrante a sus destinos mediante la superposición de VPN. La interconexión de VPC de Transit tiene las siguientes ventajas:
+ El enrutamiento transitivo se habilita mediante la red VPN superpuesta, lo que permite un diseño de concentrador y radio.
+ Cuando se utiliza software de terceros en la EC2 instancia de la VPC de tránsito central, la funcionalidad del proveedor gira en torno a la seguridad avanzada (experiencia de capa 7firewall/Intrusion Prevention System (IPS)/Intrusion Detection System (IDS) ) can be used. If customers are using the same software on-premises, they benefit from a unified operational/monitoring).
+ La arquitectura Transit VPC permite la conectividad que puede desearse en algunos casos de uso. Por ejemplo, puede conectar una GovCloud instancia de AWS y una VPC de una región comercial o una instancia de Transit Gateway a una VPC de tránsito y habilitar la conectividad entre las VPC entre las dos regiones. Evalúe sus requisitos de seguridad y conformidad al considerar esta opción. Para mayor seguridad, puede implementar un modelo de inspección centralizado utilizando los patrones de diseño que se describen más adelante en este documento técnico.
![\[Un diagrama que muestra una VPC de tránsito con dispositivos virtuales\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/transit-vpc-virtual-appliances.png)
Transit VPC presenta sus propios desafíos, como el aumento de los costes de funcionamiento de dispositivos virtuales de terceros en EC2 función del tamaño o la familia de las instancias, el rendimiento limitado por conexión VPN (hasta 1,25 Gbps por túnel de VPN) y una sobrecarga adicional de configuración, administración y resiliencia (los clientes son responsables de gestionar la alta disponibilidad y la redundancia de las instancias que ejecutan dispositivos virtuales de terceros). EC2
## Emparejamiento de VPC frente a Transit VPC frente a Transit Gateway
*Tabla 1: Comparación de conectividad*
| Criterios | Emparejamiento de VPC | VPC de tránsito | Transit Gateway | PrivateLink | WAN en la nube de | VPC Lattice |
| --- | --- | --- | --- | --- | --- | --- |
| Alcance | Regional/global | Regional | Regional | Regional | Global | Regional |
| Arquitectura | Malla completa | Basado en VPN hub-and-spoke | Basado en archivos adjuntos hub-and-spoke | Modelo de proveedor o consumidor | Basado en archivos adjuntos, multirregional | Conectividad de aplicación a aplicación |
| Escalado | 125 pares activos/VPC | Depende del router virtual/ EC2 | 5000 archivos adjuntos por región | Sin límites | 5000 archivos adjuntos por red principal | 500 asociaciones de VPC por servicio |
| Segmentación | Grupos de seguridad | Gestionado por el cliente | Tablas de rutas de Transit Gateway | Sin segmentación | Segmentos | Políticas de servicio y red de servicios |
| Latencia | Mínima | Además, debido a la sobrecarga de cifrado de la VPN | Tienda adicional de Transit Gateway | El tráfico permanece en la red troncal de AWS, los clientes deberían probarlo | Utiliza el mismo plano de datos que Transit Gateway | El tráfico permanece en la red troncal de AWS, los clientes deberían probarlo |
| Límite de ancho de banda | Límites por instancia, sin límite agregado | Sujeto a los límites de ancho de banda de las EC2 instancias según el tamaño o la familia | Hasta 100 Gbps (ráfaga) por conexión | 10 Gbps por zona de disponibilidad, se amplía automáticamente hasta 100 Gbps | Hasta 100 Gbps (ráfaga) por archivo adjunto | 10 Gbps por zona de disponibilidad |
| Visibilidad | Logs de flujo de VPC | Registros y métricas de flujo de VPC CloudWatch | Transit Gateway Network Manager, registros de flujo de VPC, métricas CloudWatch | CloudWatch Métricas | Administrador de red, registros de flujo de VPC, métricas CloudWatch | CloudWatch Registros de acceso |
| Grupo de seguridad referencias cruzadas | Compatible | No admitido | No admitido | No admitido | No admitido | No aplicable |
| IPv6 apoyo | Compatible | Depende del dispositivo virtual | Soportado | Soportado | Soportado | Soportado |
# AWS PrivateLink
[AWS PrivateLink](https://aws.amazon.com/privatelink/)proporciona conectividad privada entre VPCs los servicios de AWS y sus redes locales sin exponer su tráfico a la Internet pública. Los puntos finales de VPC de interfaz, impulsados por AWS PrivateLink, facilitan la conexión AWS y otros servicios entre diferentes cuentas y VPCs simplifican considerablemente la arquitectura de red. Esto permite a los clientes que deseen exponer de forma privada un servicio/aplicación que reside en una VPC (proveedor de servicios) a otra VPCs (consumidor) de forma que solo el consumidor VPCs inicie conexiones con la VPC del proveedor de servicios. Región de AWS Un ejemplo de ello es la posibilidad de que sus aplicaciones privadas accedan al proveedor de servicios. APIs
Para usarlo AWS PrivateLink, cree un Network Load Balancer para su aplicación en su VPC y cree una configuración de servicio de punto final de VPC que apunte a ese balanceador de carga. A continuación, un consumidor de servicios crea un punto final de interfaz para tu servicio. Esto crea una interface de red elástica (ENI) en la subred del consumidor con una dirección IP privada que sirve como punto de entrada para el tráfico destinado al servicio. No es necesario que el consumidor y el servicio estén en la misma VPC. Si la VPC es diferente, el consumidor y el proveedor de servicios VPCs pueden tener intervalos de direcciones IP superpuestos. Además de crear el punto de enlace de la VPC de la interfaz para acceder a los servicios de otros VPCs, puede crear puntos de enlace de la VPC de la interfaz para acceder de forma privada a los [servicios de AWS](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html) compatibles AWS PrivateLink, como se muestra en la siguiente figura.
Con Application Load Balancer (ALB) como objetivo de NLB, ahora puede combinar las capacidades de enrutamiento avanzado de ALB con. AWS PrivateLink Consulte [Grupo objetivo tipo Application Load Balancer para Network Load Balancer para ver las arquitecturas](https://aws.amazon.com/blogs/networking-and-content-delivery/application-load-balancer-type-target-group-for-network-load-balancer/) de referencia y la configuración detallada.
![\[Un diagrama que muestra AWS PrivateLink la conectividad con otros servicios VPCs y con los de AWS\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/aws-privatelink.png)
La elección entre Transit Gateway o VPC peering depende de la AWS PrivateLink conectividad.
+ **AWS PrivateLink**— Úselo AWS PrivateLink cuando tenga un cliente/servidor configurado en el que desee permitir a uno o más consumidores el acceso VPCs unidireccional a un servicio o conjunto de instancias específicos en la VPC del proveedor de servicios o a determinados servicios. AWS Solo los clientes con acceso a la VPC de consumo pueden iniciar una conexión al servicio en la VPC o el servicio del proveedor de servicios. AWS Esta también es una buena opción cuando el cliente y los servidores de los dos VPCs tienen direcciones IP superpuestas porque se AWS PrivateLink utilizan ENIs dentro de la VPC del cliente de una manera que garantiza que no haya conflictos de IP con el proveedor de servicios. Puede acceder a AWS PrivateLink los puntos de conexión a través de interconexiones de VPC, VPN, Transit Gateway, Cloud WAN y. AWS Direct Connect
+ **Emparejamiento de VPC y Transit Gateway**: utilice el emparejamiento de VPC y Transit Gateway cuando desee habilitar la conectividad IP de capa 3 entre ellos. VPCs
Su arquitectura contendrá una combinación de estas tecnologías para adaptarse a diferentes casos de uso. Todos estos servicios se pueden combinar y operar entre sí. Por ejemplo, AWS PrivateLink gestionando la conectividad cliente-servidor al estilo de una API, la interconexión de VPC para gestionar los requisitos de conectividad directa cuando aún se deseen grupos de ubicación dentro de la región o se necesite conectividad interregional, y Transit Gateway para simplificar la conectividad VPCs a escala, así como la consolidación perimetral para la conectividad híbrida.
# Uso compartido de VPC
VPCs El uso compartido resulta útil cuando el propietario de la VPC no necesita gestionar estrictamente el aislamiento de la red entre equipos, pero sí los usuarios y permisos a nivel de cuenta. Con la [VPC compartida, varias](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html) cuentas de AWS crean sus recursos de aplicaciones (como las EC2 instancias de Amazon) en Amazon compartido y gestionado de forma centralizada. VPCs En este modelo, la cuenta propietaria de la VPC (propietario) comparte una o más subredes con otras cuentas (participantes). Después de compartir una subred, los participantes pueden ver, crear, modificar y eliminar los recursos de su aplicación en las subredes compartidas con ellos. Los participantes no pueden ver, modificar ni eliminar recursos que pertenezcan a otros participantes o al propietario de la VPC. La seguridad entre los recursos compartidos VPCs se gestiona mediante grupos de seguridad, listas de control de acceso a la red (NACLs) o mediante un firewall entre las subredes.
Ventajas del uso compartido de VPC:
+ Diseño simplificado: sin complejidad en torno a la conectividad entre VPC
+ Se gestionan menos VPCs
+ Separación de funciones entre los equipos de red y los propietarios de las aplicaciones
+ Mejor utilización de las IPv4 direcciones
+ Costos más bajos: sin cargos por transferencia de datos entre instancias que pertenezcan a cuentas diferentes dentro de la misma zona de disponibilidad
**nota**
Cuando compartes una subred con varias cuentas, tus participantes deberían tener cierto nivel de cooperación, ya que comparten espacio IP y recursos de red. Si es necesario, puede optar por compartir una subred diferente para cada cuenta de participante. Una subred por participante permite que la ACL de red proporcione aislamiento de red además de los grupos de seguridad.
La mayoría de las arquitecturas de clientes contendrán varias VPCs, muchas de las cuales se compartirán con dos o más cuentas. Se pueden usar Transit Gateway y el peering de VPC para conectar lo compartido. VPCs Por ejemplo, supongamos que tiene 10 aplicaciones. Cada aplicación requiere su propia cuenta de AWS. Las aplicaciones se pueden clasificar en dos carteras de aplicaciones (las aplicaciones de la misma cartera tienen requisitos de red similares: las aplicaciones de 1 a 5 en «Marketing» y las aplicaciones de 6 a 10 en «Ventas»).
Puede tener una VPC por cartera de aplicaciones (dos en VPCs total) y la VPC se comparte con las distintas cuentas de propietarios de aplicaciones de esa cartera. Los propietarios de las aplicaciones implementan aplicaciones en sus respectivas VPC compartidas (en este caso, en las diferentes subredes para segmentar y aislar las rutas de la red). NACLs Los dos compartidos VPCs están conectados a través de Transit Gateway. Con esta configuración, podría pasar de tener que conectar 10 VPCs a solo dos, como se ve en la siguiente figura.
![\[Un diagrama que muestra un ejemplo de configuración para una VPC compartida\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/example-setup-shared-vpc.png)
**nota**
Los participantes que comparten VPC no pueden crear todos los recursos de AWS en una subred compartida. Para obtener más información, consulte la sección [Limitaciones](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html#vpc-share-limitations) de la documentación sobre el uso compartido de VPC.
Para obtener más información sobre las consideraciones clave y las mejores prácticas para el uso compartido de VPC, consulte la entrada del blog [Uso compartido de VPC: consideraciones clave y mejores](https://aws.amazon.com/blogs/networking-and-content-delivery/vpc-sharing-key-considerations-and-best-practices/) prácticas.
# Puerta de enlace NAT privada
Los equipos suelen trabajar de forma independiente y pueden crear una nueva VPC para un proyecto, que puede tener bloques de enrutamiento entre dominios (CIDR) superpuestos. Para la integración, es posible que deseen habilitar la comunicación entre redes superpuestas CIDRs, lo que no se puede lograr con funciones como la interconexión de VPC y Transit Gateway. Una puerta de enlace NAT privada puede ayudar con este caso de uso. La puerta de enlace NAT privada utiliza una dirección IP privada única para realizar la NAT de origen para la dirección IP de origen superpuesta, y el ELB realiza la NAT de destino para la dirección IP de destino superpuesta. Puede enrutar el tráfico desde su puerta de enlace NAT privada a otras redes VPCs o a redes locales mediante Transit Gateway o una puerta de enlace privada virtual.
![\[Un diagrama que muestra un ejemplo de configuración para una puerta de enlace NAT privada\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/example-setup-private-nat-gateway.png)
La figura anterior muestra dos subredes no enrutables (superpuestas CIDRs`100.64.0.0/16`) en la VPC A y B. Para establecer una conexión entre ellas, puede agregar subredes secundarias CIDRs no superpuestas o enrutables (`10.0.1.0/24`subredes enrutables y) a la VPC A y B, respectivamente. `10.0.2.0/24` El equipo de administración de red responsable de la asignación de IP debe asignar el enrutable CIDRs . Se agrega una puerta de enlace NAT privada a la subred enrutable de la VPC A con una dirección IP de. `10.0.1.125` La puerta de enlace NAT privada realiza la traducción de direcciones de red de origen en las solicitudes de instancias de la subred no enrutable de la VPC A (`100.64.0.10`) como `10.0.1.125` el ENI de la puerta de enlace NAT privada. Ahora el tráfico se puede dirigir a una dirección IP enrutable asignada al Application Load Balancer (ALB) de la VPC B `10.0.2.10` (), cuyo objetivo es. `100.64.0.10` El tráfico se enruta a través de Transit Gateway. La puerta de enlace NAT privada procesa el tráfico de retorno y lo devuelve a la EC2 instancia original de Amazon que solicitó la conexión.
La puerta de enlace NAT privada también se puede usar cuando la red local restringe el acceso a los aprobados. IPs Las redes locales de unos pocos clientes están obligadas a comunicarse únicamente con redes privadas (sin IGW) únicamente a través de un bloque contiguo limitado de propiedad del cliente y aprobado. IPs En lugar de asignar a cada instancia una IP independiente del bloque, puede ejecutar grandes cargas de trabajo AWS VPCs detrás de cada IP de la lista de permitidos mediante una puerta de enlace NAT privada. Para obtener más información, consulte la entrada del blog [Cómo solucionar el agotamiento de la IP privada con una solución de NAT privada](https://aws.amazon.com/blogs/networking-and-content-delivery/how-to-solve-private-ip-exhaustion-with-private-nat-solution/).
![\[Un diagrama que muestra cómo usar una puerta de enlace NAT privada IPs para proporcionar una red local aprobada\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/how-to-use-nat.png)
# AWS WAN en la nube
La WAN en la nube de AWS es una nueva forma de conectar redes que antes podíamos hacer con Transit Gateways, VPC Peering y túneles VPN IPSEC. Antes, se configuraban uno o más VPCs, se conectaban entre sí mediante uno de los métodos anteriores y se utilizaba una VPN IPSEC o se conectaba Direct Connect a redes locales. Tendría definidas las estructuras de red y de seguridad en un lugar y las redes en otro. La WAN en la nube le permite centralizar todas estas estructuras en un solo lugar. Por política, puede segmentar sus redes para determinar quién puede hablar con quién y aislar el tráfico de producción a través de estos segmentos de las cargas de trabajo de desarrollo o prueba, o de sus redes locales.
![\[Un diagrama que muestra la conectividad WAN en la nube de AWS\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/cloud-wan-diagram.png)
Administre su red global a través de la interfaz de usuario de AWS Network Manager y APIs. La red global es el contenedor a nivel raíz de todos los objetos de la red; la red principal es la parte de la red global administrada por AWS. Una política de red principal (CNP) es un documento de política con una sola versión que define todos los aspectos de su red principal. Los adjuntos son cualquier conexión o recurso que desee añadir a su red principal. Un perímetro de red central (CNE) es un punto de conexión local para los archivos adjuntos que cumplen con la política. Los segmentos de red son dominios de enrutamiento que, de forma predeterminada, permiten la comunicación solo dentro de un segmento.
Para usar CloudWAN:
1. En AWS Network Manager, cree una red global y una red principal asociada.
1. Cree un CNP que defina los segmentos, el rango de ASN Regiones de AWS y las etiquetas que se utilizarán para adjuntarlos a los segmentos.
1. Aplique la política de red.
1. Comparta la red principal con sus usuarios, cuentas u organizaciones mediante el administrador de acceso a los recursos.
1. Cree y etiquete archivos adjuntos.
1. Actualice las rutas de su VPCs conexión para incluir la red principal.
Cloud WAN se diseñó para simplificar el proceso de conexión de su infraestructura de AWS a nivel mundial. Le permite segmentar el tráfico con una política de permisos centralizada y utilizar la infraestructura existente en las ubicaciones de su empresa. La WAN en la nube también conecta sus recursos de SD VPCsWANs, cliente VPNs, firewalls y centros de datos para conectarse a la WAN en la nube. VPNs Para obtener más información, consulte [las publicaciones del blog AWS Cloud WAN](https://aws.amazon.com/blogs/networking-and-content-delivery/category/networking-content-delivery/aws-cloud-wan/).
La WAN en la nube de AWS permite una red unificada que conecta los entornos locales y en la nube. Las organizaciones utilizan firewalls (NGFWs) y sistemas de prevención de intrusiones () de última generación por motivos de seguridadIPSs. La entrada del blog sobre los [patrones de migración e interoperabilidad de AWS Cloud WAN y Transit Gateway](https://aws.amazon.com/blogs/networking-and-content-delivery/aws-cloud-wan-and-aws-transit-gateway-migration-and-interoperability-patterns/) describe los patrones arquitectónicos para administrar e inspeccionar de forma centralizada el tráfico de red saliente en una red WAN en la nube, incluidas las redes de una o varias regiones, y configura las tablas de rutas. Estas arquitecturas garantizan que los datos y las aplicaciones permanezcan seguros y, al mismo tiempo, mantienen un entorno de nube seguro.
Para obtener más información sobre la WAN en la nube, consulte la entrada del blog [AWS Cloud WAN sobre la arquitectura de inspección saliente centralizada](https://aws.amazon.com/blogs/networking-and-content-delivery/centralized-outbound-inspection-architecture-in-aws-cloud-wan/).
# Amazon VPC Lattice
Amazon VPC Lattice es un servicio de redes de aplicaciones totalmente gestionado que se utiliza para conectar, supervisar y proteger los servicios de varias cuentas y nubes privadas virtuales. VPC Lattice ayuda a interconectar los servicios dentro de un límite lógico, de modo que pueda gestionarlos y detectarlos de forma eficaz.
Los componentes de VPC Lattice constan de:
+ **Servicio**: es una unidad de aplicación que se ejecuta en una instancia, un contenedor o una función Lambda y consta de oyentes, reglas y grupos objetivo.
+ **Red de servicios**: este es el límite lógico que se utiliza para implementar automáticamente la detección y la conectividad de los servicios y aplicar políticas comunes de acceso y observabilidad a un conjunto de servicios.
+ Políticas de **autenticación: políticas** de recursos de IAM que se pueden asociar a una red de servicios o a servicios individuales para respaldar la autenticación a nivel de solicitud y la autorización específica del contexto.
+ **Directorio de servicios**: una vista centralizada de los servicios que posee o que se han compartido con usted a través de AWS Resource Access Manager.
Pasos de uso de VPC Lattice:
1. Cree la red de servicio. La red de servicio normalmente reside en una cuenta de red a la que un administrador de red tiene acceso total. La red de servicios se puede compartir entre varias cuentas de una organización. El uso compartido se puede realizar en servicios individuales o en toda la cuenta de servicio.
1. Conéctelo VPCs a la red de servicios para habilitar la red de aplicaciones para cada VPC, de modo que los diferentes servicios puedan empezar a consumir otros servicios que estén registrados en la red. Los grupos de seguridad se utilizan para controlar el tráfico.
1. Los desarrolladores definen los servicios, que se rellenan en el directorio de servicios y se registran en la red de servicios. VPC Lattice contiene la libreta de direcciones de todos los servicios configurados. Los desarrolladores también pueden definir políticas de enrutamiento para utilizar despliegues azules o verdes. La seguridad se gestiona a nivel de la red de servicio, donde se definen las políticas de autenticación y autorización, y a nivel de servicio, donde se implementan las políticas de acceso con IAM.
![\[Un diagrama que muestra los flujos de comunicación de VPC Lattice\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/images/vpc-lattice.png)
Encontrará más información en la guía del usuario de [VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/what-is-vpc-lattice.html ).