Cuando diseñes tu zona de destino, debes elegir un diseño de red que funcione para tu organización. Este documento describe cuatro diseños de red comunes y te ayuda a elegir la opción que mejor se adapte a los requisitos de tu organización y a las preferencias de tu organización para el control centralizado o descentralizado. Está dirigido a ingenieros de red, arquitectos y profesionales técnicos que participan en la creación del diseño de red para la zona de destino de tu organización.
Este artículo forma parte de una serie sobre zonas de destino.
Elige el diseño de tu red
El diseño de red que elijas depende principalmente de los siguientes factores:
- Control centralizado o descentralizado: Según las preferencias de tu organización, debes elegir una de las siguientes opciones:
- Centraliza el control sobre la red, lo que incluye el direccionamiento IP, el enrutamiento y la configuración de firewalls entre diferentes cargas de trabajo.
- Brinda a tus equipos mayor autonomía para ejecutar sus propios entornos y compilar elementos de red dentro de sus entornos.
- Opciones de conectividad de nube híbrida o local: Todos los diseños de red que se analizan en este documento proporcionan acceso desde entornos locales a la 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 la organización requiera que el tráfico entre diferentes cargas de trabajo de Google Cloud pase por dispositivos de red centralizados, como firewalls de última generación (NGFW). Esta restricción influye en el diseño de la red de nube privada virtual (VPC).
- Escalabilidad: Algunos diseños pueden ser mejores para tu organización que otros, según la cantidad de cargas de trabajo que deseas implementar y la cantidad de máquinas virtuales (VM) y balanceadores de carga interna y otros recursos que consumirán.
Puntos de decisión para el diseño de red
En el siguiente diagrama de flujo, se muestran las decisiones que debes tomar a fin de elegir el mejor diseño de red para tu organización.
El diagrama anterior te guía a través de las siguientes preguntas:
- ¿Necesitas una inspección de capa 7 mediante dispositivos de red entre diferentes cargas de trabajo en Google Cloud?
- Si es así, consulta Topología de concentrador y radio con dispositivos centralizados.
- De lo contrario, continúa con la siguiente pregunta.
- ¿Muchas de tus cargas de trabajo requieren conectividad local?
- Si es así, ve al punto de decisión 4.
- De lo contrario, continúa con la siguiente pregunta.
- ¿Tus cargas de trabajo pueden comunicarse mediante extremos privados en un modelo de consumidor y productor de servicios?
- Si es así, consulta Expón servicios en un modelo de productor y consumidor con Private Service Connect.
- De lo contrario, continúa con la siguiente pregunta.
- ¿Quieres administrar el firewall y el enrutamiento de forma centralizada?
- Si es así, consulta Red de VPC compartida para cada entorno.
- Si no es así, consulta Topología de concentrador y radio sin dispositivos.
El objetivo de este gráfico es ayudarte a tomar una decisión; sin embargo, puede ocurrir que varios diseños sean adecuados para tu organización. En estas instancias, te recomendamos que elijas el diseño que mejor se adapte a tu caso de uso.
Opciones de diseño de la red
En las siguientes secciones, se describen cuatro opciones de diseño comunes. Recomendamos la opción 1 para la mayoría de los casos de uso. Los otros diseños que se analizan en esta sección son alternativas que se aplican a los requisitos específicos de casos extremos de la organización.
La mejor opción para tu caso de uso también puede ser una red que combina elementos de varias opciones de diseño que se analizan en esta sección. Por ejemplo, puedes usar las redes de VPC compartida en topologías de concentrador y radio para mejorar la colaboración, controlar de forma centralizada y limitar la cantidad de radios de VPC. O bien, puedes diseñar la mayoría de las cargas de trabajo en una topología de VPC compartida, pero aislar una pequeña cantidad de las cargas de trabajo en redes de VPC independientes que solo expongan servicios a través de algunos extremos definidos mediante Private Service Conect.
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. En este diseño, se usan redes de VPC compartidas independientes para cada entorno de implementación que tienes en Google Cloud (desarrollo, pruebas y producción). Este diseño te permite administrar de forma centralizada los recursos de red en una red común y proporciona aislamiento de red entre los diferentes entornos.
Usa este diseño cuando se cumpla lo siguiente:
- Deseas tener un control central sobre las reglas de firewall y de enrutamiento.
- Necesitas una infraestructura simple y escalable.
- Necesitas administración centralizada del espacio de direcciones IP.
Evita este diseño cuando se cumplan las siguientes condiciones:
- Deseas que los equipos de desarrolladores tengan autonomía total, incluida la capacidad de administrar sus propias reglas de firewall, enrutamiento e intercambio de tráfico con otras redes de equipos.
- Necesitas una inspección de capa 7 con dispositivos NGFW.
En el siguiente diagrama, se muestra un ejemplo de implementación de este diseño.
En el diagrama anterior, se muestra lo siguiente:
- La red local se distribuye en dos ubicaciones geográficas.
- La red local se conecta a través de instancias redundantes de Cloud Interconnect a dos redes de VPC compartidas distintas, una para la producción y otra para el desarrollo.
- Los entornos de producción y de desarrollo están conectados a ambas instancias de Cloud Interconnect con diferentes adjuntos de VLAN.
- Cada VPC compartida tiene proyectos de servicio que alojan las cargas de trabajo.
- Las reglas de firewall se administran de manera 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 las cargas de trabajo específicas deben comunicarse entre sí, puedes permitir la transferencia de datos a través de canales controlados locales o compartir datos entre aplicaciones con los servicios de Google Cloud, como Cloud Storage o Pub/Sub. Recomendamos que evites conectar directamente entornos separados a través del intercambio de tráfico entre redes de VPC, ya que aumenta el riesgo de mezclar de forma accidental los datos entre los entornos. Usar el intercambio de tráfico entre redes de VPC entre entornos grandes también aumenta el riesgo de alcanzar cuotas de VPC en torno al intercambio de tráfico y los grupos de intercambio de tráfico.
Para obtener más información, consulta lo siguiente:
- Descripción general de la VPC compartida
- Arquitectura de VPC compartida en la guía de bases empresarial
- Arquitectura de referencia en las prácticas recomendadas para el diseño de VPC
- Etapa de implementación de Terraform: Herramientas de redes con entornos separados como parte del framework de Fabric FAST
- Etapa de red para la base de ejemplo de Terraform mediante el kit de herramientas de Cloud Foundation
Para implementar esta opción de diseño, consulta Crea la opción 1: Red de VPC compartida para cada entorno.
Opción 2: Topología de concentrador y radio con dispositivos centralizados
Este diseño de red usa la topología de concentrador y radio. Una red de VPC de concentrador contiene un conjunto de VMs de dispositivos, como NGFW, 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 locales o Internet se enruta a través de las VMs de dispositivo para su inspección y filtrado.
Usa este diseño cuando se cumpla lo siguiente:
- Necesitas una inspección de 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 inspeccionar la capa 7 para la mayoría de tus cargas de trabajo.
- Deseas que las cargas de trabajo en Google Cloud no se comuniquen entre sí.
- Solo necesitas una inspección de la capa 7 para el tráfico que va a las redes locales, como se describe en Caso de uso especial con una red de VPC compartida en Google Cloud.
En el siguiente diagrama, se muestra un ejemplo de implementación de este patrón.
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 concentrador mediante el intercambio de tráfico entre redes de VPC.
- La red de VPC de concentrador tiene varias instancias de un dispositivo virtual en un grupo de instancias administrado. El tráfico al grupo de instancias administrado pasa por un balanceador de cargas de red de transferencia interno.
- Las redes de VPC de radio se comunican entre sí a través de los dispositivos virtuales mediante el uso de rutas estáticas con el balanceador de cargas interno como siguiente salto.
- Cloud Interconnect conecta las redes de VPC de tránsito a las ubicaciones locales.
- Las redes locales se conectan a través de las mismas Cloud Interconnects mediante adjuntos de VLAN independientes.
- Las redes de 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 desde y hacia estas redes mediante el dispositivo.
- El entorno de desarrollo tiene la misma estructura de VPC que el entorno de producción.
- Esta configuración no usa traducción de direcciones de red de origen (SNAT). No se requiere una SNAT porque Google Cloud usa el hash simétrico. Para obtener más información, consulta Hash simétrico.
Por diseño, el tráfico de una red de radio no puede llegar a otra. Sin embargo, si las cargas de trabajo específicas deben comunicarse entre sí, puedes configurar el intercambio de tráfico directo entre las redes de radio mediante el intercambio de tráfico entre redes de VPC o puedes compartir datos entre aplicaciones con los servicios de Google Cloud, 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 la implementación en la nube, puedes tener un conjunto de dispositivos y una VPC de concentrador para cada entorno en cada región. Como alternativa, puedes usar etiquetas de red con rutas para que todas las instancias se comuniquen con el dispositivo más cercano.
Las reglas de firewall pueden restringir la conectividad dentro de las redes de VPC de radio que contienen cargas de trabajo. A menudo, los equipos que administran las cargas de trabajo también administran estas reglas de firewall. Para las políticas centrales, puedes usar políticas de firewall jerárquicas. Si necesitas que un equipo de red central tenga control total sobre las reglas de firewall, considera implementar esas reglas de forma centralizada en todas las redes de VPC mediante un enfoque de GitOps. En este caso, restringe los permisos de IAM solo a los administradores que pueden cambiar las reglas de firewall. Las redes de VPC de radio también pueden ser redes de VPC compartidas si varios equipos implementan en los radios.
En este diseño, te recomendamos que uses el intercambio de tráfico entre redes de VPC para conectar la red de VPC de concentrador y las redes de VPC de radio, ya que agrega una complejidad mínima. Sin embargo, el número máximo de radios está limitado por lo siguiente:
- El límite de conexiones de intercambio de tráfico de redes de VPC desde una sola red de VPC.
- Límites del grupo de intercambio de tráfico, como la cantidad máxima de reglas de reenvío para el balanceo de cargas TCP/UDP interno de cada grupo.
Si esperas alcanzar estos límites, puedes conectar las redes de radio a través de Cloud VPN. El uso de Cloud VPN agrega costo 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 lo siguiente:
- Dispositivos de red centralizados en Google Cloud
- Arquitectura de transitividad de concentrador y radio en la guía de bases empresarial
- Etapa de implementación de Terraform: Herramientas de redes con dispositivo virtual de red como parte del framework de Fabric FAST
- Módulo de transitividad de concentrador y radio de Terraform como parte de la base de ejemplo
Para implementar esta opción de diseño, consulta Crea la opción 2: Topología del concentrador y radio con dispositivos centralizados.
Opción 3: Topología de concentrador y radio sin dispositivos
Este diseño de red también usa una topología de concentrador y radio, con una red de VPC central que se conecta a redes locales y redes de VPC de radio que contienen las cargas de trabajo. Debido a que el intercambio de tráfico entre redes de VPC no es transitivo, las redes de radio no pueden comunicarse entre sí directamente.
Usa este diseño cuando se cumpla lo siguiente:
- Quieres que las cargas de trabajo o los entornos de Google Cloud no se comuniquen entre sí mediante direcciones IP internas, pero quieres que compartan la conectividad local.
- Deseas dar a los equipos autonomía en la administración de sus propios firewalls y reglas de enrutamiento.
Evita este diseño cuando se cumplan las siguientes condiciones:
- Necesitas inspección de capa 7 entre cargas de trabajo.
- Deseas administrar de forma centralizada las reglas de enrutamiento y firewall.
- Necesitas comunicaciones de servicios locales a servicios administrados que estén conectados a los radios a través de otro intercambio de tráfico entre redes de VPC, ya que el intercambio de tráfico entre redes de VPC no es transitivo.
En el siguiente diagrama, se muestra un ejemplo de implementación de este diseño.
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 concentrador mediante el intercambio de tráfico entre redes de VPC.
- La conectividad a las ubicaciones locales pasa por las conexiones de Cloud Interconnect en la red de VPC de concentrador.
- Las redes locales se conectan a través de las instancias de Cloud Interconnect mediante adjuntos 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 las cargas de trabajo específicas deben comunicarse entre sí, puedes configurar el intercambio de tráfico directo entre las redes de radio mediante el intercambio de tráfico entre redes de VPC o puedes compartir datos entre aplicaciones con los servicios de Google Cloud, como Cloud Storage o Pub/Sub.
Este diseño de red se usa con frecuencia en entornos en los que los equipos actúan de forma autónoma y no hay control centralizado sobre las reglas de firewall y de enrutamiento. Sin embargo, la escala de este diseño está limitada por lo siguiente:
El límite en las conexiones de intercambio de tráfico de red de VPC desde una sola red de VPC
Límites del grupo de intercambio de tráfico, como la cantidad máxima de reglas de reenvío para el balanceador de cargas de red de transferencia interno de cada grupo
Por lo tanto, este diseño no se suele usar en organizaciones grandes que tienen muchas cargas de trabajo independientes en Google Cloud.
Como una variación del diseño, puedes usar Cloud VPN en lugar del intercambio de tráfico entre redes de VPC. Cloud VPN te permite aumentar la cantidad de radios, pero agrega un límite de ancho de banda para cada túnel y aumenta la complejidad y los costos. Cuando usas anuncios de ruta personalizados, Cloud VPN también permite la transitividad entre los radios sin necesidad de conectar directamente todas las redes de radios.
Para obtener más información, consulta lo siguiente:
- Arquitectura de red de concentrador y radio
- Arquitectura de concentrador y radio en la guía de bases empresarial
- Etapa de implementación de Terraform: Herramientas de redes con intercambio de tráfico entre redes de VPC como parte del framework de Fabric FAST
- Etapa de implementación de Terraform: Herramientas de red con Cloud VPN como parte del framework de Fabric FAST
Para implementar esta opción de diseño, consulta Crea la opción 3: Topología del concentrador y radio sin dispositivos.
Opción 4: Expón servicios en un modelo de productor y consumidor con Private Service Connect
En este diseño de red, cada equipo o carga de trabajo obtiene su propia red de VPC, que puede también ser una red de VPC compartida. Cada red de VPC se administra 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 cumpla lo siguiente:
- Las cargas de trabajo solo se comunican entre sí y con el entorno local a través de extremos definidos.
- Deseas que los equipos sean independientes entre sí y administren su propio espacio de direcciones IP, firewalls 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 los puertos y canales cambian con frecuencia.
- La comunicación entre cargas de trabajo usa protocolos que no son 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.
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 en una red de VPC puede conectarse a una carga de trabajo en otra red de VPC mediante un extremo de Private Service Connect.
- El extremo se conecta a un adjunto de servicio en la red de VPC en la que se encuentra el servicio. El adjunto de servicio puede estar en una región diferente del extremo si el extremo está configurado para el acceso global.
- El adjunto 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 llegar a las cargas de trabajo locales de la siguiente manera:
- El extremo está conectado a un adjunto de servicio en una red de VPC de tránsito.
- El adjunto del servicio está conectado a la red local mediante Cloud Interconnect.
- Un balanceador de cargas de aplicaciones interno se conecta al adjunto de servicio y usa un grupo de extremos de red híbrida para balancear la carga de tráfico entre los extremos que se encuentran en el entorno local.
- Los clientes locales también pueden llegar a los extremos en la red de VPC de tránsito que se conectan con los adjuntos del servicio en las redes de VPC de carga de trabajo.
Para obtener más información, consulta lo siguiente:
- Publica servicios gestionados mediante Private Service Connect
- Accede a los servicios publicados a través de extremos
Para implementar esta opción de diseño, consulta Crea una opción 4: Muestra servicios en un modelo productor de consumidores con Private Service Connect.
Prácticas recomendadas para la implementación de redes
Una vez que elijas el mejor diseño de red para tu caso de uso, te recomendamos implementar las siguientes prácticas recomendadas:
- Usa redes de VPC en modo personalizado y borra la red predeterminada para tener un mejor control sobre las direcciones IP de tu red.
Limita el acceso externo mediante el uso de Cloud NAT para los recursos que necesitan acceso a Internet y la reducción del uso de direcciones IP públicas a los recursos a los que se puede acceder a través de Cloud Load Balancing. Si deseas obtener más información, consulta Compila la conectividad de Internet para VMs privadas.
Si usas Cloud Interconnect, asegúrate de seguir las topologías recomendadas para o aplicaciones de nivel de producción y no críticas. Usa conexiones redundantes para cumplir con el ANS del servicio. Como alternativa, puedes conectar Google Cloud a redes locales a través de Cloud VPN.
Aplica las políticas ingresadas en limitar el acceso externo mediante una política de la organización para restringir el acceso directo a Internet desde tu VPC.
Usa políticas de firewall jerárquicas para heredar políticas de firewall de manera coherente en toda tu organización o carpetas.
Sigue las prácticas recomendadas de DNS para el DNS híbrido entre tu red local y Google Cloud.
Para obtener más información, consulta Prácticas recomendadas y arquitecturas de referencia para el diseño de VPC.
¿Qué sigue?
- Implementa el diseño de red de tu zona de destino de Google Cloud
- Decide la seguridad de tu zona de destino de Google Cloud (siguiente documento de esta serie).
- Lee Prácticas recomendadas para el diseño de redes de VPC.
- Aprende a usar dispositivos de red centralizados en Google Cloud.
- Obtén más información sobre Private Service Connect.