Decidir el diseño de la red de la zona de aterrizaje de Google Cloud

Last reviewed 2024-10-31 UTC

Cuando diseñes tu zona de aterrizaje, debes elegir un diseño de red que se adapte a tu organización. En este documento se describen cuatro diseños de red habituales y se te ayuda a elegir la opción que mejor se adapte a los requisitos de tu organización y a su preferencia por el control centralizado o descentralizado. Está dirigido a ingenieros, arquitectos y profesionales técnicos de redes que participan en la creación del diseño de la zona de aterrizaje de tu organización.

Este artículo forma parte de una serie sobre las zonas de aterrizaje.

Elige el diseño de tu red

El diseño de red que elijas dependerá principalmente de los siguientes factores:

  • Control centralizado o descentralizado: en función de las preferencias de tu organización, debes elegir una de las siguientes opciones:
    • Centraliza el control de la red, incluidas las direcciones IP, el enrutamiento y el firewall entre diferentes cargas de trabajo.
    • Ofrece a tus equipos más autonomía para gestionar sus propios entornos y crear elementos de red en ellos.
  • Opciones de conectividad on-premise o de nube híbrida: todos los diseños de red que se describen en este documento proporcionan acceso desde entornos on-premise a entornos de nube a través de Cloud VPN o Cloud Interconnect. Sin embargo, algunos diseños requieren que configures varias conexiones en paralelo, mientras que otros usan la misma conexión para todas las cargas de trabajo.
  • Requisitos de seguridad: es posible que tu organización requiera que el tráfico entre diferentes cargas de trabajo de Google Cloud pase por dispositivos de red centralizados, como cortafuegos de última generación (NGFW). Esta restricción influye en el diseño de tu red de nube privada virtual (VPC).
  • Escalabilidad: algunos diseños pueden ser más adecuados para tu organización que otros en función del número de cargas de trabajo que quieras implementar y del número de máquinas virtuales, balanceadores de carga internos y otros recursos que consuman.

Puntos de decisión para el diseño de la red

El siguiente diagrama de flujo muestra las decisiones que debe tomar para elegir el mejor diseño de red para su organización.

Decisiones sobre los diseños de red.

En el diagrama anterior se responden las siguientes preguntas:

  1. ¿Necesita inspección de capa 7 con dispositivos de red entre diferentes cargas de trabajo enGoogle Cloud?
  2. ¿Muchas de tus cargas de trabajo requieren conectividad on-premise?
    • Si es así, ve al punto de decisión 4.
    • Si no es así, ve a la siguiente pregunta.
  3. ¿Pueden comunicarse tus cargas de trabajo mediante endpoints privados en un modelo de productor y consumidor de servicios?
  4. ¿Quieres administrar el firewall y el enrutamiento de forma centralizada?

Este gráfico tiene como objetivo ayudarte a tomar una decisión, pero a menudo puede ocurrir que varios diseños sean adecuados para tu organización. En estos casos, le recomendamos que elija el diseño que mejor se adapte a su caso práctico.

Opciones de diseño de la red

En las siguientes secciones se describen cuatro opciones de diseño habituales. Recomendamos la opción 1 para la mayoría de los casos prácticos. Los otros diseños que se describen en esta sección son alternativas que se aplican a requisitos específicos de casos extremos de organizaciones.

La red que mejor se adapte a tu caso práctico también puede ser una que combine elementos de varias opciones de diseño que se han tratado en esta sección. Por ejemplo, puedes usar redes de VPC compartida en topologías de concentrador y radios para mejorar la colaboración, centralizar el control y limitar el número de radios de VPC. También puedes diseñar la mayoría de las cargas de trabajo en una topología de VPC compartida, pero aislar un pequeño número de cargas de trabajo en redes de VPC independientes que solo expongan servicios a través de unos pocos endpoints definidos mediante Private Service Connect.

Opción 1: Red de VPC compartida para cada entorno

Recomendamos este diseño de red para la mayoría de los casos prácticos. Este diseño usa redes de VPC compartidas independientes para cada entorno de implementación que tengas enGoogle Cloud (desarrollo, pruebas y producción). Este diseño te permite gestionar de forma centralizada los recursos de red en una red común y proporciona aislamiento de red entre los distintos entornos.

Usa este diseño cuando se cumplan las siguientes condiciones:

  • Quieres tener un control centralizado sobre las reglas de cortafuegos y de enrutamiento.
  • Necesitas una infraestructura sencilla y escalable.
  • Necesitas una gestión centralizada del espacio de direcciones IP.

Evita este diseño cuando se cumplan las siguientes condiciones:

  • Quieres que los equipos de desarrollo tengan plena autonomía, incluida la capacidad de gestionar sus propias reglas de firewall, el enrutamiento y el peering a otras redes de equipos.
  • Necesitas inspección de capa 7 con dispositivos NGFW.

En el siguiente diagrama se muestra un ejemplo de implementación de este diseño.

Diagrama de la opción 1.

En el diagrama anterior se muestra lo siguiente:

  • La red local está distribuida en dos ubicaciones geográficas.
  • La red on-premise se conecta a través de instancias de Cloud Interconnect redundantes a dos redes de VPC compartidas independientes, una para producción y otra para desarrollo.
  • Los entornos de producción y desarrollo están conectados a ambas instancias de Cloud Interconnect con diferentes vinculaciones de VLAN.
  • Cada VPC compartida tiene proyectos de servicio que alojan las cargas de trabajo.
  • Las reglas de cortafuegos se administran de forma centralizada en el proyecto host.
  • El entorno de desarrollo tiene la misma estructura de VPC que el entorno de producción.

Por diseño, el tráfico de un entorno no puede llegar a otro. Sin embargo, si cargas de trabajo específicas deben comunicarse entre sí, puedes permitir la transferencia de datos a través de canales controlados on-premise o compartir datos entre aplicaciones con servicios como Cloud Storage o Pub/Sub. Google Cloud Te recomendamos que no conectes directamente entornos separados mediante el emparejamiento de redes de VPC, ya que aumenta el riesgo de mezclar accidentalmente datos entre los entornos. Usar el emparejamiento entre redes VPC en entornos grandes también aumenta el riesgo de alcanzar las cuotas de VPC en relación con el emparejamiento y los grupos de emparejamiento.

Para obtener más información, consulta las siguientes secciones:

Para implementar esta opción de diseño, consulta Opción de creación 1: red de VPC compartida para cada entorno.

Opción 2: Topología de concentrador y radios con dispositivos centralizados

Este diseño de red usa una topología de concentrador y radios. Una red de VPC de concentrador contiene un conjunto de VMs de dispositivo, como NGFWs, que están conectadas a las redes de VPC de radio que contienen las cargas de trabajo. El tráfico entre las cargas de trabajo, las redes on-premise o Internet se enruta a través de las máquinas virtuales del dispositivo para inspeccionarlo y filtrarlo.

Usa este diseño cuando se cumplan las siguientes condiciones:

  • Necesitas inspección de la capa 7 entre diferentes cargas de trabajo o aplicaciones.
  • Tienes un mandato corporativo que especifica el proveedor del dispositivo de seguridad para todo el tráfico.

Evita este diseño cuando se cumplan las siguientes condiciones:

  • No necesitas inspección de la capa 7 para la mayoría de tus cargas de trabajo.
  • Quieres que las cargas de trabajo de Google Cloud no se comuniquen entre sí.
  • Solo necesitas la inspección de la capa 7 para el tráfico que va a las redes locales.

En el siguiente diagrama se muestra un ejemplo de implementación de este patrón.

Diagrama de la opción 2.

En el diagrama anterior se muestra lo siguiente:

  • Un entorno de producción que incluye una red de VPC de concentrador y varias redes de VPC de radio que contienen las cargas de trabajo.
  • Las redes de VPC de radio se conectan con la red de VPC de centro mediante el emparejamiento entre redes de VPC.
  • La red de VPC de concentrador tiene varias instancias de un dispositivo virtual en un grupo de instancias gestionado. El tráfico al grupo de instancias gestionado pasa por un balanceador de carga de red de paso a través interno.
  • Las redes VPC de radio se comunican entre sí a través de los dispositivos virtuales mediante rutas estáticas con el balanceador de carga interno como siguiente salto.
  • Cloud Interconnect conecta las redes de VPC de tránsito con las ubicaciones on-premise.
  • Las redes on-premise se conectan a través de las mismas interconexiones de Cloud Interconnect mediante vinculaciones de VLAN independientes.
  • Las redes VPC de tránsito están conectadas a una interfaz de red independiente en los dispositivos virtuales, lo que te permite inspeccionar y filtrar todo el tráfico hacia y desde estas redes mediante tu dispositivo.
  • El entorno de desarrollo tiene la misma estructura de VPC que el entorno de producción.
  • Esta configuración no usa la traducción de direcciones de red de origen (SNAT). No es necesario usar SNAT porque Google Cloud usa hash simétrico. Para obtener más información, consulta Hashing simétrico.

Por diseño, el tráfico de una red de radio no puede llegar a otra. Sin embargo, si cargas de trabajo específicas deben comunicarse entre sí, puedes configurar el emparejamiento directo entre las redes de radio mediante el emparejamiento de redes de VPC o compartir datos entre aplicaciones con Google Cloud servicios como Cloud Storage o Pub/Sub.

Para mantener una latencia baja cuando el dispositivo se comunica entre cargas de trabajo, el dispositivo debe estar en la misma región que las cargas de trabajo. Si usas varias regiones en tu implementación en la nube, puedes tener un conjunto de dispositivos y una VPC de centro de control para cada entorno de cada región. También puedes usar etiquetas de red con rutas para que todas las instancias se comuniquen con el dispositivo más cercano.

Las reglas de cortafuegos pueden restringir la conectividad dentro de las redes de VPC de spoke que contienen cargas de trabajo. A menudo, los equipos que administran las cargas de trabajo también administran estas reglas de cortafuegos. En el caso de las políticas centrales, puedes usar políticas de cortafuegos jerárquicas. Si necesitas que un equipo de red central tenga control total sobre las reglas de cortafuegos, considera la posibilidad de desplegar esas reglas de forma centralizada en todas las redes de VPC mediante un enfoque GitOps. En este caso, restringe los permisos de IAM solo a los administradores que puedan cambiar las reglas de cortafuegos. Las redes de VPC de radio también pueden ser redes de VPC compartidas si varios equipos se implementan en los radios.

En este diseño, te recomendamos que uses el emparejamiento entre redes de VPC para conectar la red de VPC de concentrador y las redes de VPC de radios, ya que añade una complejidad mínima. Sin embargo, el número máximo de radios está limitado por lo siguiente:

  • El límite de conexiones de emparejamiento entre redes de VPC procedentes de una sola red de VPC.
  • Límites de los grupos de emparejamiento, como el número máximo de reglas de reenvío para el balanceo de carga TCP/UDP interno de cada grupo de emparejamiento.

Si prevés alcanzar estos límites, puedes conectar las redes de radio a través de la VPN de Cloud. Usar Cloud VPN añade costes y complejidad adicionales, y cada túnel de Cloud VPN tiene un límite de ancho de banda.

Para obtener más información, consulta las siguientes secciones:

Para implementar esta opción de diseño, consulta Crear la opción 2: topología de concentrador y radios con dispositivos centralizados.

Opción 3: Topología de concentrador y radios sin electrodomésticos

Este diseño de red también usa una topología de concentrador y radios, con una red de VPC de concentrador que se conecta a redes on-premise y redes de VPC de radios que contienen las cargas de trabajo. Como el emparejamiento entre redes de VPC no es transitivo, las redes de radio no pueden comunicarse entre sí directamente.

Usa este diseño cuando se cumplan las siguientes condiciones:

  • Quieres que las cargas de trabajo o los entornos de Google Cloud no se comuniquen entre sí mediante direcciones IP internas, pero sí quieres que compartan la conectividad local.
  • Quieres dar autonomía a los equipos para que gestionen sus propias reglas de cortafuegos y de enrutamiento.

Evita este diseño cuando se cumplan las siguientes condiciones:

  • Necesitas inspección de capa 7 entre cargas de trabajo.
  • Quieres gestionar de forma centralizada las reglas de enrutamiento y de cortafuegos.
  • Necesitas que los servicios on-premise se comuniquen con los servicios gestionados que están conectados a los radios a través de otro emparejamiento de redes de VPC, ya que el emparejamiento de redes de VPC no es transitivo.

En el siguiente diagrama se muestra un ejemplo de implementación de este diseño.

Diagrama de la opción 3.

En el diagrama anterior se muestra lo siguiente:

  • Un entorno de producción que incluye una red de VPC de concentrador y varias redes de VPC de radio que contienen las cargas de trabajo.
  • Las redes de VPC de radio se conectan con la red de VPC de centro mediante el emparejamiento entre redes de VPC.
  • La conectividad con las ubicaciones on-premise pasa por las conexiones de Cloud Interconnect en la red de VPC de concentrador.
  • Las redes on-premise se conectan a través de las instancias de Cloud Interconnect mediante vinculaciones de VLAN independientes.
  • El entorno de desarrollo tiene la misma estructura de VPC que el entorno de producción.

Por diseño, el tráfico de una red de radio no puede llegar a otra. Sin embargo, si cargas de trabajo específicas deben comunicarse entre sí, puedes configurar el emparejamiento directo entre las redes de radio mediante el emparejamiento de redes de VPC o compartir datos entre aplicaciones con Google Cloud servicios como Cloud Storage o Pub/Sub.

Este diseño de red se suele usar en entornos en los que los equipos actúan de forma autónoma y no hay un control centralizado sobre las reglas de cortafuegos y de enrutamiento. Sin embargo, la escala de este diseño está limitada por lo siguiente:

Por lo tanto, este diseño no se suele utilizar en organizaciones grandes que tienen muchas cargas de trabajo independientes en Google Cloud.

Como alternativa al diseño, puedes usar Cloud VPN en lugar del emparejamiento entre redes de VPC. Cloud VPN te permite aumentar el número de radios, pero añade un límite de ancho de banda para cada túnel y aumenta la complejidad y los costes. Cuando usas rutas anunciadas personalizadas, Cloud VPN también permite la transitividad entre los radios sin que tengas que conectar directamente todas las redes de radio.

Para obtener más información, consulta las siguientes secciones:

Para implementar esta opción de diseño, consulta Crear opción 3: topología de concentrador y radios sin dispositivos.

Opción 4: Exponer servicios en un modelo de consumidor-productor con Private Service Connect

En este diseño de red, cada equipo o carga de trabajo tiene su propia red de VPC, que también puede ser una red de VPC compartida. Cada red de VPC se gestiona de forma independiente y usa Private Service Connect para exponer todos los servicios a los que se debe acceder desde fuera de la red de VPC.

Usa este diseño cuando se cumplan las siguientes condiciones:

  • Las cargas de trabajo solo se comunican entre sí y con el entorno local a través de endpoints definidos.
  • Quieres que los equipos sean independientes entre sí y gestionen su propio espacio de direcciones IP, cortafuegos y reglas de enrutamiento.

Evita este diseño cuando se cumplan las siguientes condiciones:

  • La comunicación entre servicios y aplicaciones usa muchos puertos o canales diferentes, o bien los puertos y canales cambian con frecuencia.
  • La comunicación entre cargas de trabajo usa protocolos distintos de TCP o UDP.
  • Necesitas inspección de capa 7 entre cargas de trabajo.

En el siguiente diagrama se muestra un ejemplo de implementación de este patrón.

Diagrama de la opción 4.

En el diagrama anterior se muestra lo siguiente:

  • Las cargas de trabajo independientes se encuentran en proyectos y redes de VPC independientes.
  • Una VM cliente de una red de VPC puede conectarse a una carga de trabajo de otra red de VPC a través de un punto final de Private Service Connect.
  • El punto final se adjunta a una vinculación de servicio en la red de VPC en la que se encuentra el servicio. La vinculación de servicio puede estar en una región distinta a la del endpoint si este se ha configurado para el acceso global.
  • La vinculación de servicio se conecta a la carga de trabajo a través de Cloud Load Balancing.
  • Los clientes de la VPC de la carga de trabajo pueden acceder a las cargas de trabajo que se encuentran en las instalaciones de la siguiente manera:
    • El punto final está conectado a una vinculación de servicio en una red de VPC de tránsito.
    • La vinculación de servicio está conectada a la red on-premise mediante Cloud Interconnect.
  • Un balanceador de carga de aplicaciones interno se adjunta a la vinculación de servicio y usa un grupo de puntos finales de red híbrido para equilibrar la carga de tráfico entre los puntos finales que se encuentran en las instalaciones.
  • Los clientes on-premise también pueden acceder a los endpoints de la red de VPC de tránsito que se conectan a las vinculaciones de servicio de las redes de VPC de carga de trabajo.

Para obtener más información, consulta las siguientes secciones:

Para implementar esta opción de diseño, consulta Opción 4: exponer servicios en un modelo de consumidor-productor con Private Service Connect.

Prácticas recomendadas para la implementación de redes

Una vez que hayas elegido el mejor diseño de red para tu caso práctico, te recomendamos que implementes las siguientes prácticas recomendadas:

Para obtener más información, consulta las prácticas recomendadas y las arquitecturas de referencia para el diseño de VPCs.

Siguientes pasos