Prácticas recomendadas y arquitecturas de referencia para el diseño de VPCs

En esta guía se presentan las prácticas recomendadas y las arquitecturas empresariales típicas para diseñar una nube privada virtual (VPC) con Google Cloud. Esta guía está dirigida a arquitectos de redes en la nube y arquitectos de sistemas que ya estén familiarizados con los conceptos de redes. Google Cloud

Principios generales y primeros pasos

Identificar a los responsables de la toma de decisiones, los plazos y el trabajo previo

Como primer paso para diseñar tu red de VPC, identifica a las personas que deben tomar las decisiones, los plazos y el trabajo previo necesario para asegurarte de que puedes cumplir los requisitos de las partes interesadas.

Entre las partes interesadas se pueden incluir los propietarios de las aplicaciones, los arquitectos de seguridad, los arquitectos de soluciones y los gestores de operaciones. Las partes interesadas pueden cambiar en función de si estás planificando tu red de VPC para un proyecto, una línea de negocio o toda la organización.

Una de las tareas previas consiste en familiarizar al equipo con los conceptos y la terminología relacionados con el diseño de redes de VPC. Entre los documentos útiles se incluyen los siguientes:

• Documentación de Resource Manager
• Documentación de Gestión de Identidades y Accesos (IAM)
• Documentación de Virtual Private Cloud

Intenta diseñar la red de VPC lo antes posible

Diseña la red de VPC cuando estés empezando a perfilar cómo va a configurarse tu organización en Google Cloud. Si más adelante necesitas cambiar aspectos fundamentales, como la forma en que se segmenta tu red o la ubicación de tus cargas de trabajo, puede ser perjudicial para tu organización.

Las diferentes configuraciones de redes de VPC pueden tener implicaciones significativas en el enrutamiento, la escala y la seguridad. Una planificación cuidadosa y un conocimiento profundo de tus consideraciones específicas te ayudan a crear una base arquitectónica sólida para las cargas de trabajo incrementales.

No te compliques

La mejor forma de asegurarse de que la arquitectura sea fácil de gestionar, fiable y comprensible es diseñar una topología de red de VPC sencilla.

Usar convenciones de nomenclatura claras

Utiliza nomenclaturas que sean simples, intuitivas y coherentes. De esta forma, los administradores y los usuarios finales sabrán para qué sirve cada recurso, dónde se encuentra y en qué se diferencia de otros recursos.

Las abreviaturas de palabras largas que se aceptan comúnmente ayudan a que el texto sea más breve. Usar una terminología familiar siempre que sea posible ayuda a mejorar la legibilidad.

Tenga en cuenta los componentes que se ilustran en el siguiente ejemplo al establecer sus convenciones de nomenclatura:

• Nombre de la empresa: Acme Company: acmeco
• Unidad de negocio: Recursos humanos: hr
• Código de aplicación: sistema de compensación: comp
• Código de región: northamerica-northeast1: na-ne1, europe-west1: eu-we1
• Códigos de entorno: dev, test, uat, stage, prod

En este ejemplo, el entorno de desarrollo del sistema de compensación del departamento de recursos humanos se llama acmeco-hr-comp-eu-we1-dev.

Para otros recursos de redes habituales, puedes usar patrones como estos:

• Red de VPC
  sintaxis: {company name}-{description(App or BU)-label}-{environment-label}-{seq#}
  ejemplo: acmeco-hr-dev-vpc-1

• Subred
  Sintaxis: {company-name}-{description(App or BU)-label}-{region-label}-{environment-label}-{subnet-label}
  Ejemplo: acmeco-hr-na-ne1-dev-vpc-1-subnet-1
  Nota: Si una subred contiene recursos en una sola zona, puedes usar "zone-label" en lugar de "region-label".

• Regla de cortafuegos
  sintaxis: {company-name}-{description(App or BU)-label}{source-label}-{dest-label}-{protocol}-{port}-{action}
  ejemplo: acmeco-hr-internet-internal-tcp-80-allow-rule

• Ruta IP
  sintaxis: {priority}-{VPC-label}-{tag}-{next hop}
  ejemplo: 1000-acmeco-hr-dev-vpc-1-int-gw

Direcciones y subredes

Usar redes de VPC en modo personalizado

Aunque las redes en modo automático pueden ser útiles para las primeras exploraciones, las redes VPC en modo personalizado son más adecuadas para la mayoría de los entornos de producción.

Recomendamos que las empresas usen redes de VPC en el modo personalizado desde el principio por los siguientes motivos:

• Las redes de VPC en modo personalizado se integran mejor en los esquemas de gestión de direcciones IP que ya tengas. Como todas las redes del modo automático usan el mismo conjunto de intervalos de IP internos, los intervalos de IP del modo automático pueden solaparse cuando se conectan con tus redes corporativas locales.
• No puedes conectar dos redes de VPC de modo automático mediante el emparejamiento entre redes de VPC porque sus subredes usan intervalos de IP principales idénticos.
• Todas las subredes del modo automático tienen el mismo nombre que la red. Puedes elegir nombres únicos y descriptivos para las subredes de modo personalizado, lo que hará que tus redes VPC sean más fáciles de entender y mantener.
• Cuando se introduce una nueva Google Cloud región, las redes VPC de modo automático obtienen automáticamente una nueva subred en esa región. Las redes de VPC en modo personalizado solo obtienen subredes nuevas si las especificas. Esto puede ser importante por motivos de soberanía y de gestión de direcciones IP.

Si no tiene recursos, puedes eliminar la default red. No puedes eliminar una red de VPC hasta que hayas eliminado todos los recursos que dependen de ella, incluidas las instancias de máquina virtual (VM).

Para obtener más información sobre las diferencias entre las redes de VPC en modo automático y en modo personalizado, consulta la descripción general de las redes de VPC.

Agrupar las aplicaciones en menos subredes con intervalos de direcciones más grandes

Por lo general, algunas redes empresariales se dividen en muchos intervalos de direcciones pequeños por varios motivos. Por ejemplo, esto se puede hacer para identificar o aislar una aplicación, o para mantener un dominio de difusión pequeño.

Sin embargo, te recomendamos que agrupes las aplicaciones del mismo tipo en menos subredes, pero más fáciles de gestionar, con rangos de direcciones más amplios en las regiones en las que quieras operar.

A diferencia de otros entornos de red en los que se usa una máscara de subred,Google Cloud utiliza un enfoque de redes definidas por software (SDN) para proporcionar una malla completa de accesibilidad entre todas las VMs de la red VPC global. El número de subredes no afecta al comportamiento de enrutamiento.

Puedes usar cuentas de servicio o etiquetas de red para aplicar políticas de enrutamiento o reglas de cortafuegos específicas. La identidad de Google Cloud no se basa únicamente en la dirección IP de la subred.

Algunas funciones de VPC, como Cloud NAT, Acceso privado de Google, registros de flujo de VPC y rangos de IPs de alias, se configuran por subred. Si necesitas un control más detallado de estas funciones, usa subredes adicionales.

Una sola red VPC y VPC compartida

Empieza con una única red de VPC para los recursos que tengan requisitos en común

En muchos casos prácticos sencillos, una única red de VPC proporciona las funciones que necesitas y, al mismo tiempo, es más fácil de crear, mantener y comprender que las alternativas más complejas. Si agrupas los recursos con requisitos y características comunes en una única red de VPC, podrás establecer el límite de la red de VPC como perímetro de los posibles problemas.

Para ver un ejemplo de esta configuración, consulta la arquitectura de referencia de un solo proyecto y una sola red de VPC.

Entre los factores que pueden llevarte a crear redes de VPC adicionales se incluyen la escala, la seguridad de la red, las consideraciones financieras, los requisitos operativos y la gestión de identidades y accesos (IAM).

Usar una VPC compartida para gestionar varios grupos de trabajo

Una VPC compartida es una herramienta eficaz que permite que las organizaciones con varios equipos puedan simplificar aún más la arquitectura de su única red de VPC en varios grupos de trabajo. La forma más sencilla es implementar un único proyecto del host de VPC compartida con una única red de VPC compartida y, a continuación, vincular los proyectos de servicio del equipo a la red del proyecto del host.

En esta configuración, la política de red y el control de todos los recursos de red se centralizan y son más fáciles de gestionar. Los departamentos del proyecto de servicio pueden configurar y gestionar recursos que no sean de red, lo que permite separar claramente las responsabilidades de los diferentes equipos de la organización.

Los recursos de esos proyectos pueden comunicarse entre sí de forma más segura y eficiente entre proyectos mediante direcciones IP internas. Puedes gestionar los recursos de red compartidos (como subredes, rutas y cortafuegos) desde un proyecto host central, de modo que puedas aplicar políticas de red coherentes en todos los proyectos.

Para ver un ejemplo de esta configuración, consulta la arquitectura de referencia Un proyecto del host, varios proyectos de servicio y una VPC compartida.

Conceder el rol de usuario de red a nivel de subred

El administrador centralizado de la VPC compartida puede conceder a los miembros el rol de usuario de red (networkUser) a nivel de subred para autorizar proyectos de servicio de forma granular o a nivel de proyecto host para todas las subredes.

De acuerdo con el principio de mínimos accesos, te recomendamos que asignes el rol de usuario de red a nivel de subred al usuario, la cuenta de servicio o el grupo asociados.

Como las subredes son regionales, este control granular te permite especificar qué regiones puede usar cada proyecto de servicio para implementar recursos.

Con las arquitecturas de VPC compartida, también tienes la flexibilidad de implementar varios proyectos host de VPC compartida en tu organización. Cada proyecto host de VPC compartida puede incluir una o varias redes de VPC compartidas. En esta configuración, los distintos entornos pueden aplicar diferentes políticas.

Para obtener más información, consulta Roles de gestión de identidades y accesos para redes.

Usa un solo proyecto host si los recursos requieren varias interfaces de red

Si tienes un proyecto de servicio que necesita desplegar recursos en varias redes de VPC aisladas (por ejemplo, instancias de VM con varias interfaces de red), tu proyecto host debe contener todas las redes de VPC que proporcionen los servicios. Esto se debe a que un proyecto de servicio solo puede vincularse a un proyecto del host.

Usar varios proyectos host si los requisitos de recursos superan la cuota de un solo proyecto

En los casos en los que no se puedan cumplir los requisitos de recursos agregados de todas las redes de VPC dentro de la cuota de un proyecto, utiliza una arquitectura con varios proyectos del host con una sola red de VPC compartida por proyecto del host, en lugar de un solo proyecto del host con varias redes de VPC compartidas. Es importante que evalúes tus requisitos de escalado, ya que, si utilizas un solo proyecto del host, necesitarás varias redes VPC en ese proyecto y las cuotas se aplican a nivel de proyecto.

Para ver un ejemplo de esta configuración, consulta la arquitectura de referencia de varias VPC compartidas, varios proyectos del host y varios proyectos de servicio.

Usa varios proyectos host si necesitas políticas de administración independientes para cada red de VPC

Como cada proyecto tiene su propia cuota, utiliza un proyecto host de VPC compartida independiente para cada red de VPC con el fin de escalar los recursos agregados. De esta forma, cada red de VPC tiene permisos de gestión de identidades y accesos independientes para la gestión de redes y de seguridad, ya que los permisos de gestión de identidades y accesos también se implementan a nivel de proyecto. Por ejemplo, si implementas dos redes de VPC (red de VPC A y red de VPC B) en el mismo proyecto host, el rol de administrador de red (networkAdmin) se aplica a ambas redes de VPC.

Decidir si se deben crear varias redes de VPC

Crea una sola red de VPC por proyecto para asignar cuotas de recursos de VPC a los proyectos

Las cuotas son restricciones que se aplican a nivel de proyecto o de red. Todos los recursos tienen una cuota predeterminada inicial para protegerte de un uso inesperado de los recursos. Sin embargo, hay muchos factores que pueden llevarte a querer más cuota. En la mayoría de los recursos, puede solicitar cuota adicional.

Te recomendamos que crees una sola red de VPC por proyecto si prevés que vas a superar las cuotas de recursos de VPC predeterminadas. De esta forma, es más fácil asignar los aumentos de cuota a nivel de proyecto a cada red de VPC en lugar de a una combinación de redes de VPC del mismo proyecto.

Los límites se han diseñado para proteger los recursos del sistema de forma agregada. Por lo general, los límites no se pueden aumentar fácilmente, aunque losGoogle Cloud equipos de Asistencia y Ventas pueden ayudarte a aumentar algunos límites.

Consulta los límites y cuotas de recursos de las VPC para ver los valores actuales.

El equipo de Asistencia de Google puede aumentar algunos límites de escalado, pero puede que en ocasiones tengas que crear varias redes de VPC para cumplir tus requisitos de escalado. Si tu red VPC necesita superar los límites, habla con los equipos deGoogle Cloud Ventas y Asistencia para determinar la mejor forma de satisfacer tus necesidades.

Crear una red VPC para cada equipo autónomo, con servicios compartidos en una red VPC común

Algunas implementaciones de grandes empresas implican equipos autónomos que requieren un control total sobre sus respectivas redes de VPC. Para cumplir este requisito, puedes crear una red de VPC para cada unidad de negocio, con servicios compartidos en una red de VPC común (por ejemplo, herramientas analíticas, una canalización de CI/CD y máquinas de compilación, servicios de DNS o de directorio).

Crear redes de VPC en diferentes proyectos para tener controles de gestión de identidades y accesos independientes

Una red de VPC es un recurso a nivel de proyecto con controles de gestión de identidades y accesos (IAM) pormenorizados a nivel de proyecto, incluidos los siguientes roles:

• networkAdmin
• securityAdmin
• networkUser
• networkViewer

De forma predeterminada, los controles de IAM se implementan a nivel de proyecto y cada rol de IAM se aplica a todas las redes de VPC del proyecto.

Si necesitas controles de gestión de identidades y accesos independientes para cada red de VPC, crea las redes de VPC en proyectos diferentes.

Si necesitas roles de gestión de identidades y accesos con un ámbito específico para recursos de Compute Engine, como instancias de máquina virtual, discos e imágenes, usa políticas de gestión de identidades y accesos para recursos de Compute Engine.

Aísla los datos sensibles en su propia red de VPC

Las empresas que gestionan iniciativas de cumplimiento, datos sensibles o datos altamente regulados que están sujetos a estándares de cumplimiento como HIPAA o PCI-DSS, suelen adoptar medidas de seguridad adicionales. Un método que puede mejorar la seguridad y facilitar la demostración del cumplimiento consiste en aislar cada uno de estos entornos en su propia red VPC.

Conectar varias redes de VPC

Elige el método de conexión de VPC que se ajuste a tus necesidades de coste, rendimiento y seguridad

El siguiente paso después de decidir implementar varias redes de VPC es conectar esas redes. Las redes de VPC son espacios de cliente que están aislados en la red definida por software (SDN) Andromeda de Google, pero hay varias formas de habilitar la comunicación entre ellas. En las secciones siguientes se describen las prácticas recomendadas para elegir un método de conexión de VPC.

En la siguiente tabla se resumen las ventajas y desventajas de cada una de ellas. En las secciones posteriores se ofrecen prácticas recomendadas para elegir un método de conexión de VPC.

	Ventajas	Desventajas
Radios de VPC de Network Connectivity Center	Hasta 250 radios de VPC activos por centro de conectividad. Exportar filtros. Topologías predefinidas. Escalado máximo de instancias de máquina virtual por VPC sin cuotas de grupo de emparejamiento independientes. Flujo de trabajo de administrador de concentrador a administrador de radio para la conectividad de VPC entre organizaciones. La propagación de conexiones de Private Service Connect permite la accesibilidad transitiva de los endpoints de Private Service Connect en las VPCs de radio. Además de todas las ventajas del emparejamiento entre redes de VPC.	Las etiquetas de origen y las cuentas de servicio de origen de la VM de envío no se propagan en Network Connectivity Center. Opciones de inserción de VNA limitadas. Costes de tránsito entre VPCs. Solo IPv4.
Emparejamiento entre redes VPC	Fácil de configurar. Sobrecarga de gestión baja. Ancho de banda alto. Cargos de salida bajos (iguales que en una sola red de VPC). Cada red de VPC mantiene su propio cortafuegos distribuido. Cada red de VPC mantiene sus propias cuentas y permisos de IAM.	No transitiva. Los números de escalado están vinculados al grupo agregado de redes de VPC emparejadas. Esto incluye el número de máquinas virtuales, rutas y reglas de reenvío interno. Requiere un espacio de direcciones que no se solape. Las rutas estáticas y dinámicas no se propagan. Las etiquetas de origen y las cuentas de servicio de origen de la VM de envío no se propagan a través del emparejamiento entre redes de VPC. Las rutas estáticas y dinámicas no se propagan.
Enrutamiento externo (IP pública o pasarela de NAT)	No es necesario configurar nada. Aislamiento completo entre redes de VPC. Es posible que haya espacio de direcciones IP superpuesto. Ancho de banda alto.	Los cargos de salida de las VMs de la misma zona son más altos que los de otras opciones, como el emparejamiento entre redes de VPC. Las VMs deben exponerse mediante direcciones IP externas. No se puede usar un cortafuegos con direcciones IP privadas. Las rutas estáticas y dinámicas no se propagan. Las redes emparejadas no tienen en cuenta las etiquetas de origen ni las cuentas de servicio de origen de la VM de envío.
Cloud VPN	Cloud VPN permite topologías transitivas para las configuraciones de concentrador y radio. Escalable mediante ECMP. Acuerdo de nivel de servicio con una disponibilidad del 99,99% en las VPN de alta disponibilidad.	Sobrecarga de gestión. Se factura según las tarifas de salida de Internet. Latencia ligeramente superior. Rendimiento por túnel limitado. MTU inferior debido a la encapsulación adicional del túnel. Las etiquetas de origen y las cuentas de servicio de origen de la VM de envío se pierden a través del túnel.
Varias interfaces de red (Multi-NIC)	Se puede escalar mediante grupos de instancias gestionados y rutas ECMP en las instancias. Las VMs individuales tienen límites de ancho de banda.	Número limitado de interfaces por instancia de VM. Tienes que gestionar las instancias de VM por tu cuenta.

Usar radios de VPC de Network Connectivity Center

Te recomendamos que uses radios de VPC de Network Connectivity Center cuando necesites conectar redes de VPC. Los radios de VPC de Network Connectivity Center permiten reutilizar direcciones en diferentes VPCs del mismo proyecto y organización, o de otro proyecto y organización.

Los radios de VPC de Network Connectivity Center son el método preferido para conectar redes de VPC por los siguientes motivos:

• El plano de datos está distribuido, por lo que no hay cuellos de botella en la pasarela. El tráfico se desplaza por las redes de VPC como si las VMs estuvieran en la misma red de VPC.
• Conectividad entre redes de diferentes organizaciones. Las redes incluyen VPCs y redes externas.
• Hasta 250 redes de VPC por hub.
• Accesibilidad transitiva entre VPCs de puntos de acceso de servicio.
• Cloud NAT entre VPCs integrado para habilitar la reutilización de direcciones IP en las VPCs.
• Reglas de accesibilidad de red definidas mediante topologías predefinidas y filtros de prefijo.

Usa el emparejamiento de redes de VPC si necesitas insertar NVAs o si tu aplicación no admite Private Service Connect

Te recomendamos que uses el emparejamiento entre redes de VPC si necesitas insertar dispositivos virtuales de red (NVAs), como máquinas virtuales de cortafuegos. Es posible que tengas que insertar NVAs para el tráfico que atraviesa varias redes de VPC o para la conectividad privada a servicios que no se publican mediante Private Service Connect.

Cuando utilices el emparejamiento entre redes de VPC, asegúrate de que el total de los recursos necesarios para todos los peers conectados directamente no supere los límites de instancias de VM, número de conexiones de emparejamiento y reglas de reenvío internas.

El emparejamiento entre redes de VPC permite que dos redes de VPC se conecten entre sí internamente a través de la SDN de Google, independientemente de si pertenecen al mismo proyecto o a la misma organización. El emparejamiento de redes de VPC combina el plano de control y la propagación de flujo entre cada peer, lo que permite que se apliquen las mismas características de reenvío que si todas las VMs estuvieran en la misma red de VPC. Cuando se emparejan redes de VPC, se puede acceder a todas las subredes, los intervalos de IP de alias y las reglas de reenvío internas, y cada red de VPC mantiene su propio cortafuegos distribuido. El emparejamiento entre redes de VPC no es transitivo.

Usar el enrutamiento externo si no necesitas la comunicación con direcciones IP privadas

Si no necesitas comunicación con direcciones IP privadas, puedes usar el enrutamiento externo con direcciones IP externas o una pasarela NAT.

Cuando se implementa una red de VPC, se aprovisiona una ruta a la pasarela de Internet predeterminada de Google con una prioridad de 1000. Si esta ruta existe y se asigna una dirección IP externa a una máquina virtual, las máquinas virtuales pueden enviar tráfico saliente a través de la pasarela de Internet de Google. También puedes desplegar servicios detrás de una de las muchas ofertas de balanceo de carga públicas de Google, lo que permite acceder a los servicios desde fuera.

Las máquinas virtuales con direcciones externas se comunican entre sí de forma privada a través de la red troncal de Google, independientemente de la región y de los niveles de servicio de red. Usa reglas de cortafuegos de Google Cloud para controlar el tráfico entrante externo a tus VMs.

El enrutamiento externo es una buena opción para escalar, pero es importante entender cómo afecta el enrutamiento público a los costes. Para obtener más información, consulta la documentación sobre precios de red.

Usar Cloud VPN para conectar redes VPC que alojan puntos de acceso de servicio a los que no se puede acceder de forma transitiva a través de Network Connectivity Center

La VPN de alta disponibilidad proporciona un servicio gestionado para conectar redes de VPC mediante la creación de túneles IPsec entre conjuntos de endpoints. Si configuras tus routers de Cloud Router con el modo de anuncio personalizado, puedes habilitar el enrutamiento transitivo en las redes de VPC y las topologías de concentrador y radios, tal como se describe más adelante en este documento. Con Network Connectivity Center, puedes usar túneles de VPN de alta disponibilidad como red de tránsito entre redes on-premise, tal como se explica en la documentación de Cloud VPN.

Cloud VPN no admite MTU grandes. Para obtener más información, consulta Consideraciones sobre la MTU.

Usar dispositivos virtuales para controlar el tráfico entre redes de VPC a través de un dispositivo en la nube

Es habitual que las redes de VPC que requieren seguridad o servicios adicionales entre ellas tengan varias máquinas virtuales con interfaces de red, ya que estas máquinas permiten que las instancias de VM puenteen la comunicación entre redes de VPC.

Una VM solo puede tener una interfaz por cada red de VPC a la que se conecte. Para desplegar una VM en varias redes de VPC, debes tener el permiso de IAM adecuado para cada red de VPC a la que se conecte la VM.

Ten en cuenta las siguientes características al implementar una máquina virtual con varias NICs:

• Una VM con varias NICs puede tener un máximo de 8 interfaces.
• Los intervalos de IP de las subredes de las interfaces no deben solaparse.

Conectividad de servicios

Private Service Connect permite a los consumidores acceder a servicios de forma privada desde su red de VPC sin necesidad de un modelo de implementación orientado a la red. Del mismo modo, permite que los productores alojen estos servicios en sus propias redes de VPC independientes y que ofrezcan una conexión privada a sus consumidores dentro de la misma organización o en otras organizaciones. Private Service Connect permite la conectividad con servicios gestionados propios y de terceros, lo que elimina la necesidad de asignar subredes para el acceso a servicios privados y el emparejamiento de redes VPC.

Private Service Connect ofrece un modelo de seguridad centrado en los servicios con las siguientes ventajas:

• No hay dependencias compartidas
• Autorización explícita
• Rendimiento de velocidad de línea

Private Service Connect está disponible en diferentes tipos que ofrecen distintas funciones y modos de comunicación:

• Endpoints de Private Service Connect: los endpoints se implementan mediante reglas de reenvío que proporcionan al consumidor una dirección IP asignada al servicio de Private Service Connect.
• Backends de Private Service Connect: los backends se implementan mediante grupos de endpoints de red (NEGs) que permiten a los consumidores dirigir el tráfico a su balanceador de carga antes de que llegue a un servicio de Private Service Connect. Si los backends se despliegan con un balanceador de carga HTTPS, pueden admitir certificados.
• Interfaces de Private Service Connect: las interfaces permiten que el consumidor y el productor originen tráfico, lo que habilita la comunicación bidireccional. Las interfaces se pueden usar en la misma red de VPC que los puntos finales y los back-ends.

Una alternativa a Private Service Connect es Acceso privado a servicios, que permite a los consumidores conectar los servicios del productor mediante el emparejamiento entre redes VPC. Cuando uses el acceso a servicios privados, te recomendamos que tengas en cuenta la asignación de IP de cada servicio productor, la superposición de IP y la cuota compartida.

Diseño híbrido: conectar un entorno local

Una vez que hayas identificado la necesidad de una conectividad híbrida y hayas elegido una solución que cumpla tus requisitos de ancho de banda, rendimiento y seguridad, piensa en cómo integrarla en el diseño de tu VPC.

Con la VPC compartida, no es necesario que cada proyecto replique la misma solución. Por ejemplo, cuando integras una solución de Cloud Interconnect en una VPC compartida, todas las VMs (independientemente de la región o del proyecto de servicio) pueden acceder a la conexión de Cloud Interconnect.

Usar el enrutamiento dinámico cuando sea posible

El enrutamiento dinámico está disponible en todas las soluciones híbridas, incluidas la VPN de alta disponibilidad, la VPN clásica, Interconnect dedicada y Partner Interconnect. El enrutamiento dinámico usa Cloud Router de Google como altavoz del protocolo de pasarela fronteriza (BGP) para proporcionar un enrutamiento dinámico del BGP externo (eBGP).

Cloud Router no está en el plano de datos, sino que solo crea rutas en la SDN.

El enrutamiento dinámico no usa etiquetas y Cloud Router nunca vuelve a anunciar los prefijos aprendidos.

Puedes habilitar cualquiera de los dos modos de Cloud Router (regional o global) en cada red de VPC. Si eliges el enrutamiento regional, el router de Cloud Router solo anuncia las subredes que se encuentran en la región en la que se ha implementado el router de Cloud Router. Por otro lado, el enrutamiento global anuncia todas las subredes de la red de VPC dada, independientemente de la región, pero penaliza las rutas que se anuncian y se aprenden fuera de la región. De esta forma, se mantiene la simetría en la región, ya que siempre se prefiere una interconexión local. Para calcularla, se añade una métrica de penalización (MED) igual a 200 + TTL en milisegundos entre regiones.

Enrutamiento estático

El enrutamiento estático solo está disponible en la VPN clásica. El enrutamiento estático ofrece la posibilidad de definir una ruta de salto siguiente que apunte a un túnel de Cloud VPN.

De forma predeterminada, una ruta estática se aplica a todas las VMs de la red, independientemente de la región. El enrutamiento estático también permite a los administradores de redes definir de forma selectiva a qué máquinas virtuales se aplica la ruta mediante etiquetas de instancia, que se pueden especificar al crear una ruta.

Las rutas estáticas se aplican de forma global en la red de VPC y tienen la misma prioridad entre sí. Por lo tanto, si tienes varios túneles en varias regiones al mismo prefijo con la misma prioridad, una VM usará ECMP basado en hash de 5 tuplas en todos los túneles. Para optimizar esta configuración, puede crear una ruta preferida en la región haciendo referencia a las etiquetas de instancia de cada región y creando las rutas preferidas correspondientes.

Si no quieres que el tráfico saliente pase por la pasarela de Internet predeterminada de Google, puedes definir una ruta estática predeterminada preferida para enviar todo el tráfico de vuelta a las instalaciones a través de un túnel.

Usar una red de VPC de conectividad para escalar una arquitectura de concentrador y radios con varias redes de VPC

Si necesitas escalar una arquitectura de concentrador y radios con varias redes de VPC, configura la conectividad híbrida centralizada en una o varias redes de VPC dedicadas y, a continuación, añade las conexiones híbridas y todos los radios de VPC a un hub de Network Connectivity Center. Deberá habilitar el intercambio de rutas con los spokes de VPC. Esta configuración permite exportar rutas estáticas o rutas aprendidas de forma dinámica a las VPCs de radio para proporcionar una configuración centralizada y escalar el diseño de tu red de VPCs.

En el siguiente diagrama se muestra un diseño de conectividad híbrida centralizada con Network Connectivity Center:

También puedes usar el emparejamiento entre redes de VPC y rutas anunciadas personalizadas para proporcionar acceso a conexiones híbridas compartidas, si no superas los límites de recursos y necesitas usar NVAs.

En el siguiente diagrama se muestra la conectividad híbrida centralizada con rutas personalizadas de emparejamiento entre redes de VPC:

Este diseño centralizado contrasta con la implementación de conectividad híbrida convencional, que usa túneles VPN o vinculaciones de VLAN en cada red de VPC.

Seguridad de la red

Google Cloud ofrece funciones de seguridad sólidas en toda su infraestructura y sus servicios, desde la seguridad física de los centros de datos y el hardware de seguridad personalizado hasta equipos de investigadores especializados. Sin embargo, proteger tus Google Cloud recursos es una responsabilidad compartida. Debes tomar las medidas adecuadas para asegurarte de que tus aplicaciones y datos estén protegidos.

Identificar objetivos de seguridad claros

Antes de evaluar los controles de seguridad nativos de la nube o aptos para la nube, empieza con un conjunto de objetivos de seguridad claros que todas las partes interesadas acepten como parte fundamental del producto. Estos objetivos deben centrarse en la viabilidad, la documentación y la iteración para que se puedan consultar y mejorar a lo largo del desarrollo.

Limitar el acceso externo

Cuando creas un Google Cloud recurso que usa una red de VPC, eliges una red y una subred en las que se encuentra el recurso. Al recurso se le asigna una dirección IP interna de uno de los intervalos de IPs asociados a la subred. Los recursos de una red de VPC pueden comunicarse entre sí mediante direcciones IP internas si las reglas de cortafuegos lo permiten.

Limita el acceso a Internet solo a los recursos que lo necesiten. Los recursos que solo tienen una dirección IP interna privada pueden seguir accediendo a muchas APIs y servicios de Google a través de Private Service Connect o Acceso privado de Google. El acceso privado permite que los recursos interactúen con servicios clave de Google y Google Cloud mientras permanecen aislados de Internet público.

Además, usa políticas de organización para restringir aún más los recursos que pueden usar direcciones IP externas.

Para permitir que las VMs accedan a Internet, usa Secure Web Proxy si el tráfico se puede descargar a través de HTTP(S) y quieres implementar controles de identidad. De lo contrario, usa Cloud NAT.

Definir perímetros de servicio para datos sensibles

En el caso de las cargas de trabajo que impliquen datos sensibles, utiliza Controles de Servicio de VPC para configurar perímetros de servicio en torno a tus recursos de VPC y servicios gestionados por Google, así como para controlar el movimiento de datos a través del límite del perímetro. Con los Controles de Servicio de VPC, puedes agrupar proyectos y tu red local en un único perímetro que impida el acceso a los datos a través de los servicios gestionados por Google. Los perímetros de servicio no pueden contener proyectos de diferentes organizaciones, pero puedes usar perímetros puente para permitir que los proyectos y servicios de diferentes perímetros de servicio se comuniquen.

Gestionar el tráfico con Google Cloud reglas de cortafuegos cuando sea posible

Google Cloud La VPC incluye un cortafuegos con reconocimiento del estado que se puede escalar horizontalmente y que se aplica a cada VM de forma distribuida. Consulta la descripción general de Cloud NGFW para obtener más información.

Google Cloud Marketplace ofrece un amplio ecosistema de soluciones de terceros, incluidas las máquinas virtuales que proporcionan seguridad avanzada, como protección frente a fugas de información, vulnerabilidades de aplicaciones y escaladas de privilegios, detectan amenazas conocidas y desconocidas, y aplican filtros de URL. También hay ventajas operativas al tener un único proveedor que implemente políticas en todos los proveedores de servicios en la nube y entornos on-premise.

Normalmente, el tráfico se enruta a estas VMs especificando rutas, ya sea con la misma prioridad (para distribuir el tráfico mediante un hash de 5 tuplas) o con prioridades diferentes (para crear una ruta redundante), como se muestra en las varias rutas a la subred de desarrollo del siguiente diagrama.

La mayoría de las soluciones requieren VMs con varias interfaces de red. Como una VM no puede tener más de una interfaz por red de VPC, cuando creas una VM con varias interfaces de red, cada interfaz debe conectarse a una red de VPC independiente.

La escalabilidad también es un factor importante a la hora de implementar soluciones de terceros en tu red de VPC por los siguientes motivos:

• Límites: la mayoría de los dispositivos basados en máquinas virtuales deben insertarse en la ruta de datos. Para ello, se necesita una VM con varias interfaces de red que conecte varias redes de VPC que residan en el mismo proyecto. Como las cuotas de recursos de las VPC se definen a nivel de proyecto, las necesidades de recursos agregados de todas las redes de VPC pueden convertirse en un factor limitante.
• Rendimiento: introducir un único punto de estrangulamiento basado en una VM en los atributos de escalabilidad horizontal completa de una red de VPC va en contra de las metodologías de diseño de la nube. Para mitigar este problema, puedes colocar varios dispositivos virtuales de red (NVAs) en un grupo de instancias gestionado detrás de un balanceador de carga de red interno con paso a través.

Para tener en cuenta estos factores en las arquitecturas de requisitos a gran escala, implementa controles de seguridad en tus endpoints. Empieza por proteger tus VMs y usar Google Cloud reglas de cortafuegos. Esta estrategia también puede implicar la introducción de agentes de inspección de endpoints basados en el host que no cambien la arquitectura de reenvío de tu red VPC a través de varias VMs de interfaz de red.

Para ver otro ejemplo de esta configuración, consulta la arquitectura de referencia del cortafuegos de capa 7 con estado entre redes de VPC.

Utiliza conjuntos de reglas de cortafuegos más amplios pero menos numerosos cuando sea posible

Solo se puede programar un número determinado de reglas en cualquier VM. Sin embargo, puedes combinar muchas reglas en una definición de regla compleja. Por ejemplo, si todas las VMs de la red de VPC deben permitir explícitamente 10 puertos TCP de entrada, tienes dos opciones: escribir 10 reglas independientes, cada una de las cuales define un solo puerto, o definir una sola regla que incluya los 10 puertos. Definir una sola regla que incluya los 10 puertos es la opción más eficiente.

Crea un conjunto de reglas genérico que se aplique a toda la red de VPC y, a continuación, usa conjuntos de reglas más específicos para grupos más pequeños de máquinas virtuales mediante destinos. Es decir, empieza definiendo reglas generales y, progresivamente, define reglas más específicas según sea necesario:

1. Aplica reglas de cortafuegos que sean comunes a todas las VMs de la red de VPC.
2. Aplica reglas de cortafuegos que se puedan agrupar en varias VMs, como un grupo de instancias de servicio o una subred.
3. Aplica reglas de cortafuegos a VMs concretas, como una pasarela NAT o un host bastion.

Aísla las VMs mediante cuentas de servicio siempre que sea posible

Muchas organizaciones tienen entornos que requieren reglas específicas para un subconjunto de las VMs de una red de VPC. En estos casos, puedes adoptar dos enfoques habituales: aislamiento de subred y filtrado de destino.

Aislamiento de subredes

Con el aislamiento de subredes, la subred forma el límite de seguridad en el que se aplican las Google Cloud reglas de cortafuegos. Este enfoque es habitual en las estructuras de redes locales y en los casos en los que las direcciones IP y la ubicación de la red forman parte de la identidad de la VM.

Puedes identificar las VMs de una subred específica aplicando una etiqueta, una etiqueta de red o una cuenta de servicio únicas a esas instancias. De esta forma, puedes crear reglas de cortafuegos que solo se apliquen a las VMs de una subred, es decir, a las que tengan la etiqueta, la etiqueta de red o la cuenta de servicio asociadas. Por ejemplo, para crear una regla de cortafuegos que permita toda la comunicación entre las VMs de la misma subred, puedes usar la siguiente configuración de regla en la página Reglas de cortafuegos:

• Objetivos: Etiquetas de destino especificadas
• Etiquetas de destino: subnet-1
• Filtro de origen: Subredes
• Subredes: selecciona una subred por su nombre (por ejemplo, subnet-1).

Filtrado por segmentación

Con el filtrado por destino, todas las VMs residen en la misma subred o forman parte de un conjunto arbitrario de subredes. Con este enfoque, la pertenencia a una subred no se considera parte de la identidad de la instancia en las reglas de cortafuegos. En su lugar, puedes usar etiquetas, etiquetas de red o cuentas de servicio para restringir el acceso entre las VMs de la misma subred. Cada grupo de VMs que usa las mismas reglas de cortafuegos tiene aplicada la misma etiqueta de red.

Para ilustrarlo, vamos a usar una aplicación de tres niveles (web, aplicación y base de datos) en la que todas las instancias se han desplegado en la misma subred. El nivel web puede comunicarse con los usuarios finales y el nivel de aplicación, y el nivel de aplicación puede comunicarse con el nivel de base de datos, pero no se permite ninguna otra comunicación entre niveles. Las instancias que ejecutan el nivel web tienen la etiqueta de red web, las instancias que ejecutan el nivel de aplicación tienen la etiqueta de red app y las instancias que ejecutan el nivel de base de datos tienen la etiqueta de red db.

Las siguientes reglas de cortafuegos implementan este enfoque:

Regla 1: Permitir usuarios finales → nivel web	Destinos: Etiquetas de destino especificadas Etiquetas de destino: web Filtro de origen: Intervalos de IPs Intervalos de IPs de origen: 0.0.0.0/0
Regla 2: Permitir el nivel web → nivel de aplicación	Objetivos: etiquetas de destino especificadas Etiquetas de destino: aplicación Filtro de origen: etiquetas de origen Etiquetas de origen: web
Regla 3: Permitir el nivel de aplicación → nivel de base de datos	Objetivos: etiquetas de objetivo especificadas Etiquetas de objetivo: db Filtro de origen: etiquetas de origen Etiquetas de origen: app

Sin embargo, aunque es posible usar etiquetas de red para filtrar por objetivo de esta forma, le recomendamos que utilice etiquetas o cuentas de servicio siempre que sea posible. Las etiquetas de destino no tienen control de acceso y las puede cambiar cualquier persona con el rol instanceAdmin mientras las VMs están en servicio. El acceso a las etiquetas y las cuentas de servicio está controlado, lo que significa que un usuario específico debe tener autorización explícita para usar una cuenta de servicio. Solo puede haber una cuenta de servicio por instancia, mientras que puede haber varias etiquetas. Además, las cuentas de servicio asignadas a una máquina virtual solo se pueden cambiar cuando la máquina está detenida.

Usar la automatización para monitorizar las políticas de seguridad al usar etiquetas

Si usas etiquetas de red, recuerda que un administrador de instancias puede cambiarlas. Esto puede eludir la política de seguridad. Por lo tanto, si usa etiquetas de red en un entorno de producción, utilice un marco de automatización para superar la falta de gobernanza de IAM sobre las etiquetas de red.

Usar herramientas adicionales para proteger tus aplicaciones

Además de las reglas de cortafuegos, usa estas herramientas adicionales para proteger tus aplicaciones:

• Usa un Google Cloud balanceador de carga HTTP(S) global para admitir la alta disponibilidad y la normalización de protocolos.
• Integra Google Cloud Armor con el balanceador de carga HTTP(S) para proporcionar protección contra ataques DDoS y la capacidad de bloquear o permitir direcciones IP en el perímetro de la red.
• Controla el acceso a las aplicaciones mediante IAP (Identity-Aware Proxy) para verificar la identidad de los usuarios y el contexto de las solicitudes, y así determinar si se les debe conceder acceso.
• Ofrece una única interfaz para obtener información de seguridad, detectar anomalías y detectar vulnerabilidades con Security Command Center.

Servicios de red: NAT y DNS

Usar direcciones IP externas fijas con Cloud NAT

Si necesitas direcciones IP externas fijas de un intervalo de VMs, usa Cloud NAT. Un ejemplo de por qué podrías necesitar direcciones IP salientes fijas es el caso en el que un tercero permite solicitudes de direcciones IP externas específicas. Con Cloud NAT, puedes tener un número reducido de direcciones IP de NAT por región que se usen para las comunicaciones salientes.

Cloud NAT también permite que tus instancias de VM se comuniquen a través de Internet sin tener sus propias direcciones IP externas. Google Cloud Las reglas de firewall tienen estado. Esto significa que, si se permite una conexión entre un origen y un destino, o entre un destino y otro, se permitirá todo el tráfico posterior en ambas direcciones mientras la conexión esté activa. En otras palabras, las reglas de cortafuegos permiten la comunicación bidireccional una vez que se ha establecido una sesión.

Reutilizar direcciones IP en varias VPCs con Cloud NAT

Las direcciones IP se pueden reutilizar en varias VPCs cuando se habilita Cloud NAT para Network Connectivity Center. Inter-VPC Cloud NAT está disponible cuando las VPCs se conectan mediante radios de VPC de Network Connectivity Center. Si las direcciones IP de la VPC se solapan con los intervalos de las redes externas, habilita NAT híbrido. Solo se traducen las conexiones iniciadas desde cargas de trabajo de Google Cloud hacia redes externas.

Usar zonas de DNS privadas para la resolución de nombres

Usa zonas privadas en Cloud DNS para permitir que tus servicios se resuelvan con DNS en tu red de VPC mediante sus direcciones IP internas sin exponer esta asignación al exterior.

Usa DNS de horizonte dividido para asignar servicios a diferentes direcciones IP desde la red VPC que desde fuera. Por ejemplo, puedes exponer un servicio a través del balanceo de carga de red desde Internet, pero hacer que el balanceo de carga interno proporcione el mismo servicio con el mismo nombre de DNS desde la red de VPC.

Acceso a las APIs de los servicios gestionados de Google

Usar la pasarela de Internet predeterminada siempre que sea posible

El acceso de los recursos de la red de VPC a las APIs de Google sigue el siguiente salto de la pasarela de Internet predeterminada. A pesar del nombre de la pasarela de salto siguiente, la ruta del tráfico de las instancias a las APIs de Google permanece en la red de Google.

De forma predeterminada, solo las instancias de VM con una dirección IP externa pueden comunicarse con las APIs y los servicios de Google. Si necesitas acceder desde instancias sin una dirección IP externa, configura los endpoints de Private Service Connect o usa la función de acceso privado a Google para cada subred. Esto no ralentiza las comunicaciones de las APIs de Google.

Google Kubernetes Engine (GKE) habilita automáticamente la función Acceso privado de Google en las subredes en las que se despliegan los nodos. Todos los nodos de estas subredes sin una dirección IP externa pueden acceder a los servicios gestionados de Google.

Añade rutas explícitas para las APIs de Google si necesitas modificar la ruta predeterminada

Si necesitas modificar la ruta predeterminada, añade rutas explícitas para los intervalos de direcciones IP de destino de la API de Google.

En los entornos en los que la ruta predeterminada (0.0.0.0/0) no usa el siguiente salto de la pasarela de Internet predeterminada, configura rutas explícitas para los intervalos de direcciones IP de destino que usan las APIs de Google. Define el siguiente salto de las rutas explícitas como la pasarela de Internet predeterminada. Por ejemplo, cuando necesites inspeccionar todo el tráfico a través de un dispositivo local.

Desplegar instancias que usen APIs de Google en la misma subred

Implementa instancias que requieran acceso a las APIs y los servicios de Google en la misma subred y habilita el acceso privado a Google para las instancias sin direcciones IP externas. También puedes configurar endpoints de Private Service Connect.

Si accedes a las APIs de Google desde tu entorno local mediante el acceso privado de Google, consulta el artículo Configurar el acceso privado de Google para hosts locales para acceder a algunos servicios de Google a través de intervalos de direcciones IP privadas. Consulta qué servicios se admiten antes de activar esta función, ya que no se podrá acceder a otras APIs de Google a través de las direcciones IP proporcionadas por este servicio. Para activar esta función, puede que tengas que configurar los DNS, como las vistas de DNS.

Si accedes a las APIs de Google desde tu entorno local mediante puntos finales de Private Service Connect, consulta Acceder al punto final desde hosts locales para obtener más información.

Registro, monitorización y visibilidad

Adaptar el registro a casos prácticos y audiencias concretos

Usa registros de flujo de VPC para monitorizar la red, optimizar el gasto y hacer evaluaciones de informática forense y análisis de seguridad en tiempo real. Puede habilitar o inhabilitar los registros de flujo de VPC a nivel de subred. Si los registros de flujo de VPC están habilitados en una subred, se recogen datos de todas las instancias de VM de esa subred.

Estos registros guardan una muestra de los flujos de red que envían y reciben las instancias de VM. Los casos prácticos de registro te ayudan a determinar qué subredes requieren registro y durante cuánto tiempo.

Los registros de flujo se agregan por conexión a intervalos de 5 segundos desde las VMs de Compute Engine y, a continuación, se exportan en tiempo real. Puedes ver los registros de flujo en Cloud Logging y exportarlos a cualquier destino compatible con la exportación desde este servicio.

La página de ingestión de registros de Logging monitoriza el volumen de registros de tu proyecto y te permite inhabilitar la ingestión de todos los registros o excluir (descartar) las entradas de registro que no te interesen para minimizar los cargos por registros que superen tu asignación mensual.

Los registros son una parte fundamental del éxito tanto operativo como de seguridad, pero no son útiles a menos que los revises y tomes medidas. Adapta los registros a la audiencia prevista, lo que ayuda a garantizar el éxito operativo y de seguridad de tus redes VPC.

Para obtener más información, consulta Usar registros de flujo de VPC.

Aumentar el intervalo de agregación de registros de redes de VPC con conexiones largas

En las redes de VPC con conexiones que suelen ser de larga duración, define el intervalo de agregación de registros en 15 minutos para reducir considerablemente el número de registros generados y para que el análisis sea más rápido y sencillo.

Un ejemplo de flujo de trabajo en el que es adecuado aumentar el intervalo de agregación de registros es la monitorización de redes, que implica las siguientes tareas:

• Realizando diagnóstico de red
• Filtrar los registros de flujo por máquinas virtuales y por aplicaciones para comprender los cambios en el tráfico
• Analizar el crecimiento del tráfico para prever la capacidad

Usar el muestreo de registros de flujo de VPC para reducir el volumen

Usa el muestreo de registros de flujo de VPC para reducir el volumen de registros de flujo de VPC, pero sin dejar de ver muestras de bajo nivel y vistas agregadas.

Un ejemplo de flujo de trabajo en el que es adecuado usar el muestreo para reducir el volumen es el de comprender el uso de la red y optimizar los gastos de tráfico de red. Este flujo de trabajo incluye las siguientes tareas:

• Estimar el tráfico entre regiones y zonas
• Estimar el tráfico a países específicos en Internet
• Identificar a los usuarios que más hablan

Eliminar metadatos adicionales cuando solo necesites datos de IP y puerto

En los casos prácticos de seguridad en los que solo te interesan las direcciones IP y los puertos, elimina los metadatos adicionales para reducir el volumen de datos consumidos en Cloud Logging.

Un ejemplo de flujo de trabajo en el que es adecuado eliminar metadatos es la informática forense de redes, que implica las siguientes tareas:

• Determinar qué IPs han hablado con quién y cuándo
• Identificar las direcciones IP vulneradas, que se han detectado analizando los flujos de red

Usar Network Intelligence Center para obtener información valiosa sobre tus redes

Network Intelligence Center ofrece una sola consola para gestionar la visibilidad, la monitorización y la solución de problemas de la red. Google Cloud En las siguientes secciones se ofrecen detalles sobre los componentes de Network Intelligence Center.

Topología de las redes

Usa Topología de red para visualizar la topología de tu red.

Pruebas de conectividad

Usa las pruebas de conectividad para diagnosticar problemas de conectividad con tus redes de VPC.

Panel de rendimiento

Usa el panel de control de rendimiento para comprobar el rendimiento de la red física subyacente a tus redes virtuales de VPC.

Firewall Insights

Usa Firewall Insights para obtener información sobre tus reglas de cortafuegos y cómo interactúan.

Network Analyzer

Usa Network Analyzer para monitorizar las configuraciones de tu red de VPC y detectar las configuraciones que son erróneas o no óptimas.

Flow Analyzer

Usa Analizador de flujo para conocer mejor los flujos de tráfico de la VPC.

Arquitecturas de referencia

En esta sección se destacan algunas arquitecturas que ilustran algunas de las prácticas recomendadas de este documento.

Un solo proyecto y una sola red de VPC

Esta arquitectura de referencia inicial incluye todos los componentes necesarios para implementar arquitecturas de alta disponibilidad en varias regiones, con aislamiento a nivel de subred y un acuerdo de nivel de servicio del 99,99% para conectarse a tus centros de datos locales.

Un proyecto host, varios proyectos de servicio y una VPC compartida

A partir de la arquitectura de referencia inicial, los proyectos host de VPC compartida y varios proyectos de servicio permiten a los administradores delegar responsabilidades administrativas (como la creación y gestión de instancias) en los administradores de proyectos de servicio, al tiempo que mantienen el control centralizado de los recursos de red, como las subredes, las rutas y los cortafuegos.

Varios proyectos host, varios proyectos de servicio y varias VPC compartidas

En el siguiente diagrama se muestra una arquitectura de aislamiento de VPC, que se basa en nuestro diseño de alta disponibilidad y, al mismo tiempo, separa la producción de otros proyectos. Hay muchos motivos para plantearse el aislamiento de VPCs, como los requisitos de auditoría (por ejemplo, PCI), las consideraciones sobre las cuotas entre entornos o simplemente otra capa de aislamiento lógico. Solo necesitas dos interconexiones (para la redundancia) por ubicación, pero puedes añadir varias vinculaciones de interconexión a varias redes o regiones de VPC.

El uso del aislamiento también puede requerir la replicación, ya que debes decidir dónde colocar los servicios principales, como los proxies, la autenticación y los servicios de directorio. Usar una red de VPC de servicios compartidos puede ayudarte a evitar esta replicación y permitirte compartir estos servicios con otras redes de VPC a través de Network Connectivity Center, al tiempo que centralizas la administración y la implementación.

Cortafuegos con estado de nivel 7 entre redes de VPC

Esta arquitectura tiene varias redes de VPC conectadas mediante un dispositivo de cortafuegos de última generación (NGFW) de nivel 7, que funciona como un puente de varias NIC entre redes de VPC.

Se introduce una red VPC externa no fiable para finalizar las interconexiones híbridas y las conexiones basadas en Internet que finalizan en la parte externa del firewall NGFW de nivel 7 para su inspección. Hay muchas variaciones de este diseño, pero el principio clave es filtrar el tráfico a través del cortafuegos antes de que llegue a las redes VPC de confianza.

Este diseño requiere que cada red de VPC se encuentre en el proyecto en el que insertes el cortafuegos de nueva generación basado en VMs. Como las cuotas se aplican a nivel de proyecto, debes tener en cuenta el conjunto de todos los recursos de VPC.

Varias redes de VPC interconectadas con Network Connectivity Center

Esta arquitectura tiene varias redes de VPC que se conectan entre sí mediante Network Connectivity Center. Se introduce una red de VPC de tránsito para finalizar las interconexiones híbridas y compartir la conectividad híbrida en todas las demás VPCs, lo que evita la necesidad de crear vinculaciones de VLAN para cada red de VPC. De esta forma, se consolida la conectividad externa y las consideraciones de enrutamiento asociadas. Del mismo modo, se pueden introducir una o varias redes de VPC de servicios compartidos para alojar servicios comunes, como proxies, autenticación y servicios de directorio. Hay muchas variaciones de este diseño, pero el principio clave es gestionar los diferentes servicios y tipos de conexión como radios de un centro de conectividad de red que proporcione conectividad de cualquier tipo entre ellos. Esta arquitectura de referencia se describe en detalle en el artículo Conectividad entre VPCs de Red Multinube mediante Network Connectivity Center.

Siguientes pasos

• Red Multinube para aplicaciones distribuidas
• Análisis detallado de las VPCs y prácticas recomendadas (vídeo de Cloud NEXT'18)
• Topologías de red para nube híbrida y multinube
• Decide la jerarquía de recursos de tu Google Cloud zona de aterrizaje
• Prácticas recomendadas para seleccionar la región de Compute Engine
• Google Cloud para profesionales de centros de datos: redes
• Documentación de VPC
• Información general sobre las redes de GKE
• Consulta arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Centro de arquitectura de Cloud.