En esta guía, se presentan las prácticas recomendadas y las arquitecturas empresariales típicas para el diseño de nubes privadas virtuales (VPC) con Google Cloud. Esta guía está diseñada para arquitectos de redes de nube y arquitectos de sistemas que ya están familiarizados con los conceptos de herramientas de redes de Google Cloud.
Principios generales y primeros pasos
Identifica a quienes toman las decisiones, los cronogramas y el trabajo previo.
Considera diseñar la red de VPC con anticipación.
Usa un diseño simple.
Usa convenciones de nombres claras.
Identifica a quienes toman las decisiones, los cronogramas y el trabajo previo
Como primer paso en el diseño de la red de VPC, identifica a quienes toman las decisiones, los cronogramas y el trabajo previo necesarios para asegurarte de que puedas cumplir con los requisitos de las partes interesadas.
Entre las partes interesadas, se pueden incluir propietarios de aplicaciones, arquitectos de seguridad y de soluciones, y administradores de operaciones. Las partes interesadas pueden cambiar en función de si planificas la red de VPC para un proyecto, una línea de negocio o toda la organización.
Parte del trabajo previo consiste en familiarizar al equipo con los conceptos y la terminología relacionados con el diseño de la red de VPC. Entre los documentos útiles, se incluyen los siguientes:
- Documentación de Resource Manager
- Documentación de Cloud Identity and Access Management
- Documentación sobre la nube privada virtual
Considere el diseño de la red de VPC con anticipación
El diseño de la red de VPC debe ser una de las primeras consideraciones a la hora de diseñar la configuración de la organización en Google Cloud. Puede ser perjudicial para la organización si luego necesitas cambiar aspectos fundamentales, como la forma en que se segmenta la red o la ubicación de las cargas de trabajo.
Las diferentes opciones de configuración de la red de VPC pueden tener implicancias significativas en el enrutamiento, el escalamiento y la seguridad. La planificación detallada y la comprensión profunda de las consideraciones específicas te ayudan a crear una base arquitectónica sólida para las cargas de trabajo incrementales.
Mantenlo simple
Mantener simple el diseño de la topología de la red de VPC es la mejor manera de garantizar una arquitectura administrable, confiable y fácil de comprender.
Usa convenciones de nombres claras
Haz que las convenciones de nombres sean simples, intuitivas y coherentes. Esto garantiza que los administradores y los usuarios finales comprendan el propósito de cada recurso, la ubicación en la que se encuentra y cómo se diferencia de otros.
Por cuestiones de brevedad, se recomienda usar las abreviaturas aceptadas de palabras largas. Usar una terminología familiar siempre que sea posible ayuda a facilitar la lectura.
Ten en cuenta los componentes ilustrados en el siguiente ejemplo cuando establezcas las convenciones de nombres:
- Nombre de la empresa: Acme Company:
acmeco - Unidad de negocios: Recursos Humanos:
hr - Código de la aplicación: sistema de compensación:
comp - Código regional: northamerica-northeast1:
na-ne1, europe-west1:eu-we1 - Códigos del entorno:
dev,test,uat,stageyprod
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 usar otros recursos de herramientas de redes comunes, considera emplear patrones como estos:
Red de VPC
sintaxis:{company name}-{description(App or BU)-label}-{environment-label}-{seq#}
ejemplo:acmeco-hr-dev-vpc-1Subred
sintaxis:{company-name}-{description(App or BU)-label}-{region/zone-label}
ejemplo:acmeco-hr-na-ne1-dev-subnetRegla de firewall
sintaxis:{company-name}-{description(App or BU)-label}{source-label}-{dest-label}-{protocol}-{port}-{action}
ejemplo:acmeco-hr-internet-internal-tcp-80-allow-ruleRuta de IP
sintaxis:{priority}-{VPC-label}-{tag}-{next hop}
ejemplo:1000-acmeco-hr-dev-vpc-1-int-gw
Direcciones y subredes
Usa subredes en modo personalizado en las redes de VPC empresariales.
Agrupa aplicaciones en menos subredes con rangos de direcciones más grandes.
Usa redes de VPC en modo personalizado
Cuando inicias tu primer proyecto, comienzas con la red predeterminada, que es una red de VPC en modo automático denominada default. Las redes en modo automático crean subredes y rutas de subredes correspondientes cuyos rangos de IP principales son CIDR de /20 en cada región de Google Cloud mediante un conjunto predecible de rangos de direcciones RFC 1918. La red default también incluye de manera automática algunas reglas de firewall ya propagadas.
Aunque las redes en modo automático pueden ser útiles para la exploración temprana, las redes de 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 modo personalizado desde el principio por los siguientes motivos:
- Las redes de VPC en modo personalizado se integran mejor en los esquemas de administración de direcciones IP existentes. Debido a que todas las redes en modo automático usan el mismo conjunto de rangos de IP internas, los rangos de IP en modo automático pueden superponerse cuando se conectan con tus redes corporativas locales.
- No puedes conectar dos redes de VPC en modo automático en simultáneo mediante el intercambio de tráfico de red de VPC porque sus subredes usan rangos de IP primarios idénticos.
- Todas las subredes de modo automático tienen el mismo nombre que la red. Puedes elegir nombres únicos y descriptivos para las subredes en modo personalizado, lo que hace que las redes de VPC sean más comprensibles y fáciles de mantener.
- Cuando se presenta una región nueva de Google Cloud, las redes de VPC de modo automático obtienen una subred nueva de forma automática en esa región. Las redes de VPC de modo personalizado solo obtienen subredes nuevas si las especificas. Esto puede ser importante por motivos de soberanía y de administración de direcciones IP.
Si no tiene recursos, puedes borrar la red default. No puedes borrar una red de VPC hasta que hayas quitado todos los recursos, incluidas las instancias de máquina virtual (VM), que dependen de esta.
Para obtener más detalles sobre las diferencias entre las redes de VPC en modo automático y personalizado, consulta la descripción general de la red de VPC.
Agrupa aplicaciones en menos subredes con rangos de direcciones más grandes
De manera convencional, algunas redes empresariales están separadas en muchos rangos de direcciones pequeños por diversos motivos. Por ejemplo, esto se hace para identificar o aislar una aplicación o mantener un dominio de transmisión pequeño.
Sin embargo, recomendamos que agrupes las aplicaciones del mismo tipo en menos subredes más fáciles de administrar con rangos de direcciones más grandes en las regiones que deseas usar.
A diferencia de otros entornos de herramientas de redes en los que se usa una máscara de subred, Google Cloud usa un enfoque de red definida por software (SDN) para proporcionar una malla completa de accesibilidad entre todas las VM de la red de VPC global. La cantidad de subredes no afecta el comportamiento del enrutamiento.
Puedes usar cuentas de servicio o etiquetas de red para aplicar políticas de enrutamiento o reglas de firewall específicas. La identidad en Google Cloud no se basa solo en la dirección IP de la subred.
Algunas funciones de VPC, como Cloud NAT, Acceso privado a Google, registros de flujo de VPC y rangos de alias de IP, se configuran por subred. Si necesitas un control más detallado de estas funciones, usa subredes adicionales.
Única red de VPC y VPC compartida
Comienza con una sola red de VPC para los recursos que tienen requisitos comunes.
Usa la VPC compartida para administrar varios grupos de trabajo.
Otorga la función de usuario de red a nivel de la subred.
Usa un solo proyecto host si los recursos requieren varias interfaces de red.
Usa varios proyectos host si los requisitos de recursos exceden la cuota de un solo proyecto.
Usa varios proyectos host si necesitas políticas de administración independientes para cada VPC.
Comienza con una sola red de VPC para los recursos que tienen requisitos comunes
En muchos casos prácticos simples, una sola red de VPC proporciona las funciones que necesitas y es más fácil de crear, mantener y comprender que las alternativas. Cuando agrupas recursos con requisitos y características comunes en una sola red de VPC, comienzas a establecer el borde de la red de VPC como el perímetro para posibles problemas.
Para ver un ejemplo de esta configuración, consulta la arquitectura de referencia de un solo proyecto, un sola red de VPC.
Entre los factores que pueden llevarte a crear redes de VPC adicionales, se incluyen el escalamiento, la seguridad de la red, las consideraciones financieras, los requisitos operativos y la administración de identidades y accesos (IAM).
Usa la VPC compartida para administrar varios grupos de trabajo
En las organizaciones con varios equipos, la VPC compartida proporciona una herramienta eficaz para extender la simplicidad arquitectónica de una sola red de VPC en varios grupos de trabajo. El enfoque más simple consiste en implementar un único proyecto host de VPC compartida con una sola red de VPC compartida y, luego, conectar los proyectos de servicio en equipo a la red del proyecto host.
En esta configuración, la política de red y el control de todos los recursos de Herramientas de redes están centralizados y son más fáciles de manejar. Los departamentos de proyectos de servicio pueden configurar y administrar recursos que no pertenezcan a la red, lo que permite delinear con claridad las responsabilidades de los diferentes equipos de la organización.
Los recursos de esos proyectos pueden comunicarse entre sí de manera más segura y eficiente en todos los límites del proyecto a través de las direcciones IP internas. Puedes administrar recursos de red compartidos, como subredes, rutas y firewalls, desde un proyecto host central, para poder aplicar políticas de red coherentes en todos los proyectos.
Si deseas ver un ejemplo de esta configuración, consulta la arquitectura de referencia de un proyecto host único, varios proyectos de servicios, una única VPC compartida.
Otorga la función de usuario de red a nivel de la subred
El administrador centralizado de la VPC compartida puede otorgar a los miembros de IAM la función de usuario de red (networkUser) a nivel de subred, para la autorización detallada del proyecto de servicio o todas las subredes a nivel del proyecto host.
Según el principio de privilegio mínimo, recomendamos otorgar el rol de usuario de red a nivel de subred a la cuenta de servicio, al usuario o al grupo asociados.
Debido a que las subredes son regionales, este control detallado 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 dentro de la organización. Cada proyecto host de VPC compartida puede alojar una o varias redes de VPC compartida. En esta configuración, los diferentes entornos pueden implementar con facilidad diversas cuestiones de políticas.
Si deseas obtener más información, consulta Funciones de IAM para herramientas de redes.
Usa un solo proyecto host si los recursos requieren varias interfaces de red
Si tienes un proyecto de servicio que necesita implementar recursos en varias redes de VPC aisladas, por ejemplo, instancias de VM con múltiples interfaces de red, el proyecto host debe contener todas las redes de VPC que proporcionan los servicios. Esto se debe a que un proyecto de servicio puede conectarse a un solo proyecto host.
Usa varios proyectos host si los requisitos de recursos superan la cuota de un solo proyecto
En los casos en que los requisitos de recursos agregados de todas las redes de VPC no se puedan cumplir dentro de la cuota de un proyecto, usa una arquitectura con varios proyectos host con una sola red de VPC compartida por proyecto host, en lugar de un solo proyecto host con varias redes de VPC compartida. Es importante evaluar los requisitos de escalamiento, ya que el uso de un solo proyecto host requiere varias redes de VPC en él, y las cuotas se aplican a nivel de proyecto.
Para ver un ejemplo de esta configuración, consulta la arquitectura de referencia de varios proyectos host, varios proyectos de servicio y varias VPC compartidas.
Usa varios proyectos host si necesitas políticas de administración separadas para cada red de VPC
Debido a que cada proyecto tiene su propia cuota, usa un proyecto host de VPC compartida distinto para cada red de VPC a fin de escalar los recursos agregados. Esto permite que cada red de VPC tenga permisos de IAM independientes para la administración de las herramientas de redes y la seguridad, ya que los permisos de IAM también se implementan a nivel de proyecto. Por ejemplo, si implementas dos redes de VPC (A y B) en el mismo proyecto host, la función de administrador de red (networkAdmin) se aplica a ambas.
Decide si crear o no varias redes de VPC
Crea una sola red de VPC por proyecto para asignar cuotas de red de VPC a los proyectos.
Crea una red de VPC para cada equipo autónomo, con servicios compartidos en una red de VPC común.
Crea redes de VPC en diferentes proyectos para controles de IAM independientes.
Aísla los datos sensibles en su propia red 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 red. Todos los recursos tienen una cuota predeterminada inicial diseñada para protegerte del uso inesperado de recursos. Sin embargo, existen muchos factores que pueden hacer que desees una cuota mayor. Para la mayoría de los recursos, puedes solicitar una cuota adicional.
Recomendamos crear una sola red de VPC por proyecto si pretendes superar las cuotas de recursos de VPC predeterminadas. Esto facilita la tarea de asignar a cada red de VPC los aumentos de cuota a nivel de proyecto, en lugar de la combinación de redes de VPC en el mismo proyecto.
Los límites están diseñados para proteger los recursos del sistema de manera no individualizada. Por lo general, los límites no se pueden aumentar con facilidad, aunque los equipos de asistencia y ventas de Google Cloud pueden ayudarte a aumentar algunos.
Consulta Cuotas y límites de recursos de VPC para ver los valores actuales.
La Atención al cliente de Google puede aumentar algunos límites de escalamiento, pero es posible que, en ocasiones, debas compilar varias redes de VPC para cumplir con tus requisitos de escalamiento. Si la red de VPC tiene un requisito para escalar más allá de los límites, conversa sobre tu caso con los equipos de asistencia y ventas de Google Cloud a fin de definir cuál podría ser el mejor enfoque para abordar tus requisitos.
Crea una red de VPC para cada equipo autónomo, con servicios compartidos en una red de VPC común
Algunas implementaciones grandes de empresas involucran equipos autónomos que requieren control total sobre sus respectivas redes de VPC. A fin de cumplir este requisito, crea una red de VPC para cada unidad de negocios con servicios compartidos en una red de VPC común (por ejemplo, herramientas de análisis, máquinas de compilación y canalización de CI/CD y servicios de directorio o DNS). Si deseas obtener más información sobre cómo crear una red de VPC común para servicios compartidos, consulta la sección sobre servicios compartidos.
Crea redes de VPC en diferentes proyectos para controles de IAM independientes
Una red de VPC es un recurso a nivel de proyecto con controles detallados de administración de identidades y accesos (IAM) a nivel de proyecto, que incluye las siguientes funciones:
networkAdminsecurityAdminnetworkUsernetworkViewer
De forma predeterminada, los controles de IAM se implementan a nivel de proyecto, y cada función de IAM se aplica a todas las redes de VPC del proyecto.
Si necesitas controles de IAM independientes por cada red de VPC, crea las redes de VPC en proyectos diferentes.
Si necesitas funciones de IAM con permiso para recursos específicos de Compute Engine, como instancias de VM, imágenes y discos, usa políticas de IAM para recursos de Compute Engine.
Aísla los datos sensibles en su propia red de VPC
En el caso de las empresas que trabajan con iniciativas de cumplimiento, datos sensibles o datos muy regulados que están sujetos a estándares de cumplimiento como la HIPAA o PCI-DSS, tomar medidas de seguridad adicionales suele ser útil. Un método que puede mejorar la seguridad y facilitar el cumplimiento es aislar cada uno de estos entornos en su propia red de VPC.
Conecta varias redes de VPC
Elige el método de conexión de VPC que cumpla con tus necesidades de costo, rendimiento y seguridad.
Usa el intercambio de tráfico entre redes de VPC si no superarás los límites de recursos.
Usa el enrutamiento externo si no necesitas una comunicación mediante direcciones IP privadas.
Usa Cloud VPN para conectar redes de VPC que superarían los límites de grupos de intercambio de tráfico agregados.
Usa Cloud Interconnect para controlar el tráfico entre las redes de VPC a través de un dispositivo local.
Usa dispositivos virtuales con varias NIC para controlar el tráfico entre redes de VPC a través de un dispositivo en la nube.
Crea una VPC de servicios compartidos si varias redes de VPC necesitan acceso a recursos en común, pero no entre sí.
Elige el método de conexión de VPC que cumpla con tus necesidades de costo, rendimiento y seguridad
Una vez que decidas implementar varias redes de VPC, debes conectarlas. Las redes de VPC son espacios de usuario aislados dentro de la SDN de Andromeda de Google, pero existen varias formas de habilitar la comunicación entre ellas. En las siguientes secciones, se brindan prácticas recomendadas para elegir un método de conexión de VPC.
Las ventajas y desventajas de cada uno se resumen en la siguiente tabla y, en las secciones posteriores, se proporcionan prácticas recomendadas para elegir un método de conexión de VPC.
| Ventajas | Desventajas | |
|---|---|---|
| Intercambio de tráfico entre redes de VPC |
|
|
| Enrutamiento externo (IP pública o puerta de enlace de NAT). |
|
|
| Cloud VPN |
|
|
| Cloud Interconnect: Dedicada o de socio |
|
|
| Interfaces de red múltiples (varias NIC) |
|
|
Usa el intercambio de tráfico entre redes de VPC si no superarás los límites de recursos
Recomendamos que uses el intercambio de tráfico entre redes de VPC cuando necesites conectar redes de VPC y no puedas usar una sola VPC compartida, siempre que el total de los recursos necesarios para todos los pares conectados directamente no superen el límite en instancias de VM, cantidad de conexiones de intercambio de tráfico y reglas de reenvío interno.
El intercambio de tráfico entre redes de VPC permite que dos redes de VPC se conecten de forma interna a través de la SDN de Google, sin importar si pertenecen al mismo proyecto o la misma organización. El intercambio de tráfico entre redes de VPC combina el plano de control y la propagación del flujo entre cada intercambio, lo que permite las mismas características de reenvío que se darían si todas las VM estuvieran en la misma red de VPC. Cuando las redes de VPC intercambian tráfico, se puede acceder a todas las subredes, los rangos de alias de IP y las reglas de reenvío interno, y cada red de VPC mantiene su propio firewall distribuido. El intercambio de tráfico entre redes de VPC no es transitivo.
El intercambio de tráfico entre redes de VPC es el método preferido para conectar redes de VPC por los siguientes motivos:
- No hay un cuello de botella en la puerta de enlace: el tráfico se reenvía entre intercambios como si las VM estuvieran en la misma red de VPC.
- Facturación: no hay cargos adicionales; se te factura como si las VM estuvieran en la misma red de VPC.
Usa el enrutamiento externo si no necesitas una comunicación mediante direcciones IP privadas
Si no necesitas comunicación mediante direcciones IP privadas, puedes usar enrutamiento externo con direcciones IP externas o una puerta de enlace de NAT.
Cuando se implementa una red de VPC, se aprovisiona una ruta a la puerta de enlace de Internet predeterminada de Google con una prioridad de 1,000. Si esta ruta existe, y una VM recibe una dirección IP externa, las VM pueden enviar tráfico saliente (de salida) a través de la puerta de enlace de Internet de Google. También puedes implementar servicios mediante una de las muchas ofertas públicas de balanceo de cargas de Google, lo que permite acceder a los servicios de forma externa.
Las VMs con dirección externa se comunican entre sí de forma privada a través de la red troncal de Google, sin importar la región en la que se ubiquen ni los Niveles de servicio de red que tengan. Usa reglas de firewall de Google Cloud para controlar el tráfico externo entrante (de entrada) a las VMs.
El enrutamiento externo es una buena opción para el escalamiento, pero es importante comprender cómo el enrutamiento público afecta los costos. Para obtener más información, consulta la documentación sobre precios de red.
Usa Cloud VPN para conectar redes de VPC que superarían los límites de grupos de intercambio de tráfico agregados
La VPN con alta disponibilidad proporciona un servicio administrado para conectar redes de VPC mediante la creación de túneles IPsec entre conjuntos de extremos. Si configuras tus Cloud Routers con anuncios de ruta personalizados, puedes habilitar el enrutamiento transitivo en las redes de VPC y las topologías de concentrador y radio como se describe más adelante en este documento. Con Network Connectivity Center, puedes usar túneles VPN con alta disponibilidad como una red de tránsito entre redes locales, como se explica en la documentación de Cloud VPN.
Cloud VPN no es compatible con MTU grandes. Para obtener detalles, consulta Consideraciones de MTU.
Usa Cloud Interconnect para controlar el tráfico entre las redes de VPC a través de un dispositivo local
Cloud Interconnect extiende tu red local a la red de Google a través de una conexión de latencia baja con alta disponibilidad. Puedes usar la interconexión dedicada para conectarte directamente a Google o usar una interconexión de socio para conectarte a Google por medio de un proveedor de servicios admitido.
La interconexión dedicada proporciona un servicio L2 de alta velocidad entre Google y un proveedor de colocación o una ubicación local. Esto te permite usar equipos de enrutamiento locales para realizar enrutamientos entre redes de VPC y usar servicios existentes de inspección y seguridad locales a fin de filtrar todo el tráfico entre redes de VPC. Todo el tráfico entre las dos redes de VPC tiene una latencia extra debido a un proceso de ida y vuelta adicional a través del sistema local.
La interconexión de socio ofrece funciones similares, así como la capacidad de intercambiar tráfico directamente con un proveedor en L3 y tener la ruta del proveedor entre las redes de VPC. Esto permite el acceso a las direcciones IP internas en la red local y en las redes de VPC de Google Cloud sin un dispositivo de NAT o un túnel VPN.
Dado que muchos dispositivos de seguridad empresariales se pueden usar en Google Cloud mediante VMs con varias interfaces de red, no es necesario usar Cloud Interconnect para enrutar el tráfico entre redes de VPC, excepto en algunos casos puntuales en los que todo el tráfico debe fluir mediante un dispositivo local debido a políticas corporativas.
Usa dispositivos virtuales para controlar el tráfico entre redes de VPC a través de un dispositivo en la nube
Las VMs de interfaces de red múltiples son comunes en las redes de VPC que requieren seguridad o servicios adicionales entre ellas, ya que varias VMs de interfaz de red permiten que las instancias de VM se comuniquen entre las redes de VPC.
Una VM puede tener solo una interfaz para cada red de VPC a la que se conecte. A fin de implementar una VM en varias redes de VPC, debes tener el permiso de IAM correspondiente para cada red de VPC a la que se conecta la VM.
Cuando implementes una VM con varias NIC, ten en cuenta las siguientes características:
- Una VM con varias NIC puede tener 8 interfaces como máximo.
- Los rangos de IP de subred de las interfaces no deben superponerse.
Crea una VPC de servicios compartidos si varias redes de VPC necesitan acceso a recursos comunes, pero no entre sí
Una red de VPC proporciona una malla completa de accesibilidad global. Por esta razón, los servicios compartidos y las canalizaciones de integración continua que residen en la misma red de VPC no requieren una consideración especial cuando se trata de conectividad, ya que son inherentemente accesibles. La VPC compartida extiende este concepto, lo que permite que los servicios compartidos residan en un proyecto aislado mientras proporcionan conectividad a otros servicios o consumidores.
Los enfoques para los servicios compartidos incluyen Private Service Connect, el intercambio de tráfico entre redes de VPC y Cloud VPN. Usa Private Service Connect, a menos que no puedas hacerlo por algún motivo. Puedes usar el intercambio de tráfico entre redes de VPC para conectarte a una red de VPC de servicios compartidos si no superarás los límites de recursos agregados y no deseas configurar extremos para cada servicio. También puedes usar Cloud VPN para conectar redes de VPC de servicio compartido que, de lo contrario, superarían los límites de grupos de intercambio de tráfico agregados.
Private Service Connect te permite hacer que un servicio alojado en una red esté disponible para las VMs en otra red mediante la creación de un extremo especial en la red del consumidor. Luego, la configuración de Private Service Connect canaliza el tráfico para ese servicio entre las dos redes.
Los consumidores pueden usar sus propias direcciones IP internas para acceder a los servicios sin salir de sus redes de VPC o usar direcciones IP externas. El tráfico permanece completamente dentro de Google Cloud. Private Service Connect proporciona acceso orientado a los servicios entre consumidores y productores con control detallado sobre cómo se accede a los servicios.
En el modelo de intercambio de tráfico entre redes de VPC, cada red de VPC crea una relación de intercambio de tráfico con una red de VPC de servicios compartidos en común para proporcionar accesibilidad. El intercambio de tráfico entre redes de VPC presenta consideraciones de escalamiento, ya que los límites de escalamiento se aplican al uso de recursos agregados de todos los intercambios.
El intercambio de tráfico entre redes de VPC también se puede usar junto con el acceso privado a servicios y la API de Service Networking. Mediante la API de Service Networking, puedes permitir que tus clientes de la misma organización o de otra usen el servicio que ofreces, pero que puedan elegir el rango de direcciones IP que se conecta mediante el intercambio de tráfico entre redes de VPC.
Cloud VPN es otra alternativa. Debido a que Cloud VPN establece la accesibilidad a través de túneles IPsec administrados, no tiene los límites agregados del intercambio de tráfico entre redes de VPC. Cloud VPN usa una puerta de enlace de VPN para la conectividad y no tiene en cuenta el uso de recursos agregados del intercambio de tráfico de IPsec. Las desventajas de Cloud VPN incluyen el aumento de costos (túneles VPN y salida de tráfico), la sobrecarga de administración necesaria para mantener los túneles y la sobrecarga de rendimiento de IPsec.
Diseño híbrido: conexión de un entorno local
Usa el enrutamiento dinámico cuando sea posible.
Usa una red de VPC de conectividad para escalar una arquitectura de concentrador y radio con varias redes de VPC.
Una vez que hayas identificado la necesidad de usar conectividad híbrida y elegido una solución que cumpla con tus requisitos de ancho de banda, rendimiento y seguridad, piensa en cómo integrarla en el diseño de VPC.
El uso de VPC compartida alivia la necesidad de 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, sin importar la región ni el proyecto de servicio, pueden acceder a la conexión de Cloud Interconnect.
Enrutamiento dinámico
El enrutamiento dinámico está disponible en todas las soluciones híbridas, incluida la VPN con alta disponibilidad, la VPN clásica, la interconexión dedicada y la interconexión de socio. El enrutamiento dinámico usa Cloud Router de Google como un altavoz del protocolo de puerta de enlace fronteriza (BGP) para proporcionar enrutamiento dinámico de BGP externo (eBGP).
Cloud Router no está en el plano de datos; solo crea rutas en la SDN.
El enrutamiento dinámico no usa etiquetas, y Cloud Router no 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, Cloud Router solo anuncia subredes que residen en la región en la que este se implementa. Por otro lado, el enrutamiento global anuncia todas las subredes de la red de VPC determinada, sin importar la región, pero penaliza las rutas que se anuncian y aprenden fuera de la región. Esto mantiene la simetría dentro de la región, ya que se prefiere siempre una interconexión local y se calcula mediante el agregado de una métrica de penalización (MED) igual que 200 + TTL en milisegundos entre las regiones.
Enrutamiento estático
El enrutamiento estático solo está disponible en la VPN clásica. El enrutamiento estático ofrece la capacidad de establecer una ruta de siguiente salto que apunta a un túnel de Cloud VPN.
De forma predeterminada, una ruta estática se aplica a todas las VMs de la red, sin importar la región. El enrutamiento estático también permite a los administradores de red configurar de forma selectiva las VMs a las que se aplica la ruta mediante etiquetas de instancia, que pueden orientarse cuando creas una ruta.
Las rutas estáticas se aplican de forma global dentro de la red de VPC, con la misma prioridad de ruta que las demás. Por lo tanto, si tienes varios túneles en diversas regiones con el mismo prefijo y la misma prioridad, una VM usará ECMP basado en hash de 5 tuplas en todos los túneles. Para optimizar esta configuración, puedes crear una ruta en una región de preferencia si haces referencia a las etiquetas de instancia de cada región y creas rutas de preferencia según corresponda.
Si no deseas que el tráfico saliente (de salida) pase por la puerta de enlace de Internet predeterminada de Google, puedes configurar una ruta estática predeterminada de preferencia para enviar todo el tráfico de vuelta a las instalaciones locales a través de un túnel.
Usa una red de VPC de conectividad para escalar una arquitectura de concentrador y radio con varias redes de VPC
Si necesitas escalar una arquitectura de concentrador y radio con varias redes de VPC, configura una conectividad híbrida centralizada en una red de VPC dedicada y usa el intercambio de tráfico con otros proyectos mediante rutas personalizadas anunciadas. Esto permite exportar rutas aprendidas de forma estática o dinámica a redes de VPC de intercambio de tráfico para proporcionar una configuración centralizada y escalar el diseño de la red de VPC.
Esto contrasta con la implementación de la conectividad híbrida convencional, que usa un túnel VPN o adjuntos de VLAN en cada red de VPC individual.
En el siguiente diagrama, se ilustra la conectividad híbrida centralizada con las rutas personalizadas de intercambio de tráfico entre redes de VPC:
Seguridad de red
Identifica objetivos de seguridad claros.
Limita el acceso externo.
Define perímetros de servicio para datos sensibles.
Administra el tráfico con reglas de firewall nativas de Google Cloud.
Usa conjuntos de reglas de firewall más amplios pero en menor cantidad cuando sea posible.
Aísla las VM mediante cuentas de servicio cuando sea posible.
Usa la automatización para supervisar las políticas de seguridad cuando uses etiquetas.
Usa herramientas adicionales para proteger las apps.
Google Cloud ofrece funciones sólidas de seguridad en su infraestructura y servicios, desde la seguridad física de los centros de datos y el hardware de seguridad personalizado hasta equipos especializados de investigadores. Sin embargo, proteger los recursos de Google Cloud es una responsabilidad compartida; debes tomar las medidas adecuadas para asegurarte de que las apps y los datos estén protegidos.
Identifica objetivos de seguridad claros
Antes de evaluar los controles de seguridad nativos de la nube o compatibles con ella, comienza con un conjunto de objetivos de seguridad claros que todas las partes interesadas consideren como aspecto fundamental del producto. Estos objetivos deben enfatizar la viabilidad, la documentación y la iteración, de modo que puedan mencionarse y mejorarse durante el desarrollo.
Limita el acceso externo
Cuando creas un recurso de Google Cloud que usa una red de VPC, eliges una red y una subred en las que residirá. A este recurso se le asigna una dirección IP interna a partir de uno de los rangos de IP asociados con la subred. Los recursos de una red de VPC pueden comunicarse entre sí a través de direcciones IP internas si lo permiten las reglas de firewall.
Limita el acceso a Internet solo a los recursos que lo necesitan. Los recursos que solo tengan una dirección IP interna privada pueden acceder a muchas APIs y servicios de Google a través de Private Service Connect o el Acceso privado a Google. Este acceso privado permite que los recursos interactúen con los servicios clave de Google y Google Cloud, y permanezcan aislados de la Internet pública.
Además, usa políticas de la organización para restringir aún más los recursos que pueden usar direcciones IP externas.
Sin embargo, antes de bloquear el acceso a Internet, ten en cuenta el impacto que esto tendrá en las instancias de VM. Bloquear el acceso a Internet puede reducir el riesgo de robo de datos, pero también puede bloquear el tráfico legítimo, incluido el tráfico esencial para actualizaciones de software y API y servicios de terceros. Sin acceso a Internet, solo puedes acceder a las instancias de VM a través de una red local conectada a través de un túnel de Cloud VPN, una conexión de Cloud Interconnect o Identity-Aware Proxy. Mediante Cloud NAT, las máquinas virtuales pueden iniciar conexiones de salida a Internet para tráfico esencial específico, sin exponer las conexiones de entrada públicas.
Define perímetros de servicio para datos sensibles
En las cargas de trabajo que involucran datos sensibles, usa los Controles del servicio de VPC para configurar perímetros de servicio en torno a los recursos de VPC y los servicios administrados por Google y controlar el movimiento de datos en el límite del perímetro. Mediante los Controles del servicio de VPC, puedes agrupar proyectos y la red local en un solo perímetro que impida el acceso a los datos a través de los servicios administrados por Google. Los perímetros de servicio no pueden contener proyectos de organizaciones distintas, pero puedes usar puentes perimetrales para permitir que los proyectos y servicios de diferentes perímetros de servicio se comuniquen.
Administra el tráfico con reglas de firewall nativo de Google Cloud
La VPC de Google Cloud incluye un firewall con estado L3/L4 que se puede escalar horizontalmente y se aplica a cada VM de manera distribuida. Este firewall se configura mediante políticas de firewall jerárquicas, políticas de firewall de red globales y regionales, y reglas de firewall de VPC. Consulta la descripción general del firewall de Cloud para obtener más información.
Google Cloud Marketplace cuenta con un gran ecosistema de soluciones de terceros, incluidas las VMs que proporcionan seguridad avanzada, como la protección contra la pérdida de información, las vulnerabilidades de aplicaciones y el escalamiento de privilegios; detectan amenazas conocidas y desconocidas; y aplican el filtrado de URL. Tener un solo proveedor que implemente la política en todos los proveedores de servicios en la nube y los entornos locales también ofrece beneficios operativos.
Por lo general, el tráfico se enruta a estas VM mediante la especificación de rutas, ya sea con la misma prioridad (para distribuir el tráfico con un hash de 5 tuplas) o con diferentes prioridades (para crear una ruta redundante), como se muestra en varias rutas a la subred de desarrollo en el siguiente diagrama.
La mayoría de las soluciones requieren varias VMs de interfaz de red. Debido a que 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 distinta.
El escalamiento también es un factor importante cuando se implementan soluciones de terceros en la red de VPC por los siguientes motivos:
- Límites: La mayoría de los dispositivos basados en VM deben insertarse en la ruta de datos. Esto requiere una VM de la interfaz de la red múltiple que conecta varias redes de VPC que residen en el mismo proyecto. Debido a que las cuotas de recursos de VPC se establecen a nivel de proyecto, las necesidades de recursos agregados de todas las redes de VPC pueden ser limitantes.
- Rendimiento: La introducción de un único cuello de botella basado en VM en los atributos de escalabilidad completamente horizontal de una red de VPC va en contra de las metodologías de diseño en la nube. Para mitigar esto, puedes colocar varios dispositivos virtuales de red (NVAs) en un grupo de instancias administrado detrás de un balanceador de cargas de red de transferencia interno.
Para controlar estos factores en las arquitecturas de requisitos de escala alta, envía controles de seguridad a los extremos. Comienza por endurecer las VMs y usar reglas de firewall de Google Cloud. Esta estrategia también puede incluir la introducción de agentes de inspección de extremos basados en host que no cambien la arquitectura de reenvío de la red de VPC mediante varias VMs de interfaz de red.
Para obtener un ejemplo adicional de esta configuración, consulta la arquitectura de referencia de firewall con estado L7 entre redes de VPC.
Usa menos conjuntos de reglas de firewall más amplios cuando sea posible
Solo se puede programar una cierta cantidad de reglas en cualquier VM. Sin embargo, puedes combinar varias reglas en una definición de regla compleja. Por ejemplo, si todas las VM de la red de VPC necesitan permitir de manera explícita 10 puertos TCP de entrada, tienes dos opciones: escribir 10 reglas independientes, y que cada una defina 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 eficaz.
Crea un conjunto de reglas genéricas que se aplique a toda la red de VPC y, luego, usa conjuntos de reglas más específicas para agrupaciones más pequeñas de VM mediante objetivos. En otras palabras, comienza por definir reglas generales y, de manera progresiva, define reglas más específicas según sea necesario:
- Aplica reglas de firewall que se compartan en todas las VM de la red de VPC.
- Aplica reglas de firewall que se puedan agrupar en varias VM, como un grupo de instancias de servicio o una subred.
- Aplica reglas de firewall a VM individuales, como una puerta de enlace de NAT o un host de bastión.
Aísla las VM mediante cuentas de servicio cuando sea posible
Muchas organizaciones tienen entornos que requieren reglas específicas para un subconjunto de VM de una red de VPC. Existen dos enfoques comunes que puedes adoptar en estos casos: el aislamiento de la subred y el filtrado de objetivos.
Aislamiento de la subred
Con el aislamiento, la subred forma el límite de seguridad a través del cual se aplican las reglas de firewall de Google Cloud. Este enfoque es común en las construcciones de redes locales y en los casos en 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 si aplicas una etiqueta única, una etiqueta de red o una cuenta de servicio a esas instancias. Esto te permite crear reglas de firewall que solo se apliquen a las VMs de una subred, es decir, aquellas con la etiqueta de red o cuenta de servicio asociadas. Por ejemplo, para crear una regla de firewall que permita todas las comunicaciones entre las VMs de la misma subred, puedes usar la siguiente configuración de reglas en la página sobre reglas de firewall:
- Objetivos: etiquetas de objetivo especificadas
- Etiquetas de objetivos: subred-1
- Filtro de fuente: subredes
- Subredes: selecciona la subred por nombre (por ejemplo: subred-1).
Filtrado de objetivos
Con el filtrado de objetivos, todas las VM residen en la misma subred o son parte de un conjunto arbitrario de subredes. Con este enfoque, la membresía de subred no se considera parte de la identidad de la instancia para las reglas de firewall. En su lugar, puedes usar etiquetas de red o cuentas de servicio para restringir el acceso entre VM de la misma subred. Cada grupo de VMs que usa las mismas reglas de firewall tiene aplicada la misma etiqueta de red.
Para ilustrar esto, piensa en una aplicación de tres niveles (web, app o base de datos) en la que todas las instancias se implementan en la misma subred. El nivel web puede comunicarse con los usuarios finales y el nivel de la app, y este último puede comunicarse con el nivel de la base de datos, pero no se permite ninguna otra comunicación entre los niveles. Las instancias que ejecutan el nivel web tienen una etiqueta de red de web, las que ejecutan el nivel de la app tienen una etiqueta de red de app y las que ejecutan el nivel de la base de datos tienen una etiqueta de red de db.
Las siguientes reglas de firewall implementan este enfoque:
| Regla 1: Permitir usuarios finales → nivel web | Objetivos: etiquetas de objetivo especificadas Etiquetas de objetivo: web Filtro de origen: rangos de IP Rangos de IP de origen: 0.0.0.0/0 |
| Regla 2: Permitir el nivel web → nivel de la app | Objetivos: etiquetas de objetivo especificadas Etiquetas de objetivo: app Filtro de origen: etiquetas de origen Etiquetas de origen: web |
| Regla 3: Permitir nivel de la app → nivel de la 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 se pueden usar etiquetas de red para el filtrado de objetivos de esta manera, te recomendamos que uses etiquetas o cuentas de servicio siempre que sea posible. Las etiquetas de objetivo no tienen acceso controlado, y una persona que tenga el rol instanceAdmin las puede modificar mientras las VMs están en servicio. Las etiquetas y las cuentas de servicio tienen acceso controlado, lo que significa que un usuario específico debe estar autorizado de manera explícita para usar una cuenta de servicio.
Solo puede haber una cuenta de servicio por instancia, pero puede haber varias etiquetas. Además, las cuentas de servicio asignadas a una VM solo se pueden cambiar cuando esta se detiene.
Usa la automatización para supervisar las políticas de seguridad cuando uses etiquetas
Si usas etiquetas de red, recuerda que un administrador de instancias puede cambiar esas etiquetas. Esto puede eludir la política de seguridad. Por lo tanto, si usas etiquetas de red en un entorno de producción, usa un framework de automatización para superar la falta de control de IAM sobre las etiquetas.
Usa herramientas adicionales para proteger y asegurar tus apps
Además de las reglas de firewall, usa estas herramientas adicionales para proteger las apps.
- Usa un balanceador de cargas de HTTP(S) global de Google Cloud para admitir la alta disponibilidad y la normalización de protocolos.
- Integra Google Cloud Armor al balanceador de cargas de HTTP(S) para proporcionar protección contra DSD y la posibilidad de bloquear o permitir direcciones IP en el perímetro de la red.
- Controla el acceso a las apps mediante IAP (IAP) para verificar la identidad del usuario y el contexto de la solicitud para determinar si se debe otorgar acceso al usuario.
- Proporciona una sola interfaz para obtener estadísticas de seguridad y detección de anomalías y vulnerabilidades mediante Security Command Center.
Servicios de red: NAT y DNS
Usa direcciones IP externas fijas con Cloud NAT.
Usa zonas de DNS privado para la resolución de nombres.
Usa direcciones IP externas fijas con Cloud NAT
Si necesitas direcciones IP externas fijas de un rango de VM, usa Cloud NAT. Un ejemplo de por qué podrías necesitar direcciones IP fijas de salida es el caso en que un tercero permite solicitudes de direcciones IP externas específicas. El uso de Cloud NAT te permite tener una pequeña cantidad de direcciones IP de NAT para cada región que se usa en las comunicaciones salientes.
Cloud NAT también permite que las instancias de VM se comuniquen a través de Internet sin tener sus propias direcciones IP externas. Las reglas de firewall de Google Cloud tienen estado. Esto significa que si se permite una conexión entre una fuente y un objetivo o un objetivo y un destino, se permitirá todo el tráfico posterior en cualquier dirección, siempre que la conexión esté activa. Es decir, las reglas de firewall permiten la comunicación bidireccional después de que se establece una sesión.
Usa zonas de DNS privado para la resolución de nombres
Usa zonas privadas en Cloud DNS para permitir que los servicios se resuelvan con DNS dentro de la red de VPC mediante el uso de sus direcciones IP internas sin exponer esta asignación al exterior.
Usa el DNS de horizonte dividido para asignar servicios a diferentes direcciones IP desde la red de VPC. Por ejemplo, puedes hacer que un servicio se exponga a través del balanceo de cargas de red desde la Internet pública, pero que el balanceo de cargas interno proporcione el mismo servicio mediante el uso del mismo nombre de DNS desde la red de VPC.
Acceso a la API para servicios administrados de Google
Usa la puerta de enlace de Internet predeterminada siempre que sea posible.
Agrega rutas explícitas a las API de Google si necesitas modificar la ruta predeterminada.
Implementa instancias que usen las API de Google en la misma subred.
Usa la puerta de enlace de Internet predeterminada siempre que sea posible
El acceso desde los recursos ubicados dentro de la red de VPC a las API de Google respeta el siguiente salto de la puerta de enlace de Internet predeterminada. A pesar del nombre de la puerta de enlace de siguiente salto, la ruta de tráfico de las instancias a las APIs de Google permanece dentro de 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 acceso desde instancias sin una dirección IP externa, configura extremos de Private Service Connect o usa la función Acceso privado a Google para cada subred. Esto no ralentiza las comunicaciones de las APIs de Google.
Google Kubernetes Engine (GKE) habilita de forma automática el Acceso privado a Google en las subredes en las que se implementan los nodos. Todos los nodos de estas subredes sin una dirección IP externa pueden acceder a los servicios administrados de Google.
Agrega rutas explícitas para las APIs de Google si necesitas modificar la ruta predeterminada
Si necesitas modificar la ruta predeterminada, agrega rutas explícitas a los rangos de IP de destino de la API de Google.
En entornos en los que la ruta predeterminada (0.0.0.0/0) no usa el siguiente salto de la puerta de enlace de Internet predeterminada, configura rutas explícitas para los rangos de direcciones IP de destino que usan las API de Google. Establece el siguiente salto de las rutas explícitas en la puerta de enlace de Internet predeterminada. Un ejemplo de esta situación es cuando necesitas inspeccionar todo el tráfico a través de un dispositivo local.
Implementa instancias que usen las API de Google en la misma subred
Implementa instancias que requieran acceso a las APIs y los servicios de Google de la misma subred y habilita el Acceso privado a Google para las instancias sin direcciones IP externas. Como alternativa, configura extremos de Private Service Connect.
Si accedes a las APIs de Google desde el entorno local con el Acceso privado a Google, consulta Configura el Acceso privado a Google para los hosts locales para acceder a algunos servicios de Google a través de un sistema privado Rangos de direcciones IP. Verifica los servicios compatibles antes de activar esta función, ya que no será posible acceder a otras APIs de Google a través de las direcciones IP que proporciona este servicio. Activar esta función puede requerir una configuración de DNS adicional, como la configuración de las vistas de DNS.
Si accedes a las APIs de Google desde el entorno local mediante extremos de Private Service Connect, consulta Accede al extremo desde hosts locales para obtener más detalles.
Registro, supervisión y visibilidad
Adapta los registros para casos prácticos y públicos de destino específicos.
Aumenta el intervalo de agregación de registros para las redes de VPC con conexiones largas.
Usa el muestreo de los registros de flujo de VPC para reducir el volumen.
Quita los metadatos adicionales cuando solo necesites datos de IP y de puertos.
Adapta los registros para casos prácticos y públicos objetivos específicos
Usa los registros de flujo de VPC para la supervisión de redes, la detección de intrusiones, el análisis de seguridad en tiempo real y la optimización de gastos. Puedes 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, recopilan datos de todas las instancias de VM de esa subred.
Estos registros documentan una muestra de los flujos de red que envían y reciben las instancias de VM. Los casos prácticos de registro ayudan a determinar qué subredes requieren registro y durante cuánto tiempo.
Los registros de flujo se agregan por conexión, en intervalos de 5 segundos, desde las VM de Compute Engine y, luego, se exportan en tiempo real. Puedes ver los registros de flujo en Cloud Logging y exportarlos a cualquier destino que admita la exportación de Cloud Logging.
La página de transferencia de registros de Logging registra el volumen de registros del proyecto y te permite inhabilitar la transferencia de registros o excluir (descartar) las entradas de registro que no te interesen, de modo que puedas minimizar los cargos por registros en la asignación mensual.
Los registros son una parte fundamental del éxito operativo y de seguridad, pero no son útiles, a menos que los revises y tomes alguna medida al respecto. Adapta los registros al público de destino, ya que esto ayuda a garantizar el éxito operativo y de seguridad de las redes de VPC.
Para obtener más información, consulta Usa registros de flujo de VPC.
Aumenta el intervalo de agregación de registros para redes de VPC con conexiones largas
En el caso de las redes de VPC con conexiones de larga duración, configura el intervalo de agregación de registros en 15 minutos para reducir la cantidad de registros generados y permitir un análisis más rápido y sencillo.
Un ejemplo de flujo de trabajo para el que es apropiado aumentar el intervalo de agregación de registros es la supervisión de red, que implica las siguientes tareas:
- Realizar el diagnóstico de la red
- Filtrar los registros de flujo por VM y aplicaciones para comprender los cambios en el tráfico
- Analizar del crecimiento del tráfico para prever la capacidad
Usa el muestreo de los registros de flujo de VPC para reducir el volumen
Usa el muestreo de los registros de flujo de VPC para reducir el volumen de registros de flujo de VPC, pero sin perder la capacidad de ver muestras de bajo nivel y vistas agregadas.
Un flujo de trabajo de ejemplo para el que es apropiado usar el muestreo con el fin de reducir el volumen es la comprensión del uso de red y la optimización de gastos de tráfico de red. Este flujo de trabajo implica las siguientes tareas:
- Estimar el tráfico entre regiones y zonas
- Estimar el tráfico de Internet hacia países específicos
- Identificar a los usuarios que más conversan
Quita los metadatos adicionales cuando solo necesites datos de IP y de puertos
En los casos prácticos de seguridad en los que solo te interesan direcciones IP y puertos, quita los metadatos adicionales para reducir el volumen de datos consumidos en Cloud Logging.
Un ejemplo de flujo de trabajo para el que quitar los metadatos es apropiado es la detección de intrusiones en la red, que implica las siguientes tareas:
- Determinar qué IP se comunicó con quién y en qué momento
- Identificar cualquier dirección IP vulnerada que se encuentre cuando se analizan los flujos de red
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, una sola red de VPC
Esta arquitectura de referencia inicial incluye todos los componentes necesarios para implementar arquitecturas con alta disponibilidad en varias regiones, con aislamiento a nivel de subred y un ANS del 99.99% con conexión a los centros de datos locales.
Proyecto host único, varios proyectos de servicio, VPC compartida única
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 la administración de instancias) a los administradores del proyecto de servicio, mientras mantienen el control centralizado de los recursos de red, como las subredes, las rutas y los firewalls.
Varios proyectos host, varios proyectos de servicio, varias VPC compartidas
En el siguiente diagrama, se ilustra una arquitectura del aislamiento de VPC, que se basa en nuestro diseño de alta disponibilidad y separa la producción de otros proyectos. Existen muchos motivos para considerar el aislamiento de VPC, incluidos los requisitos de auditoría (como PCI), las consideraciones de cuotas entre entornos o solo otra capa de aislamiento lógico. Solo necesitas dos interconexiones (para la redundancia) por ubicación, pero puedes agregar varios adjuntos de interconexión a muchas redes o regiones de VPC a partir de estas.
El uso del aislamiento también puede presentar la necesidad de replicación, ya que tú decides dónde ubicar los servicios principales, como los proxies, la autenticación y los servicios de directorio. El uso de una red de VPC de servicios compartidos puede ayudar a evitar esta replicación y te permite compartir estos servicios con otras redes de VPC a través del intercambio de tráfico entre redes de VPC y, a su vez, centraliza la administración y la implementación.
Firewall con estado L7 entre redes de VPC
Esta arquitectura tiene varias redes de VPC que se conectan mediante un dispositivo de firewall de última generación L7 (NGFW), que funciona como un puente de varias NIC entre las redes de VPC.
Se introduce una red de VPC externa no confiable para interrumpir las interconexiones híbridas y las conexiones basadas en Internet que terminan en el tramo exterior del L7 NGFW para su inspección. Existen muchas variaciones en este diseño, pero el principio clave es filtrar el tráfico a través del firewall antes de que acceda a las redes de VPC confiables.
Este diseño requiere que cada red de VPC resida en el proyecto en el que insertas el NGFW basado en VM. Debido a que las cuotas se aplican a nivel de proyecto, debes tener en cuenta el agregado de todos los recursos de VPC.
¿Qué sigue?
- VPC deep dive and best practices (Cloud NEXT'18 video) (Análisis detallado y prácticas recomendadas de VPC [video de Cloud NEXT'18])
- Topologías de red para nube híbrida y múltiples nubes
- Prácticas recomendadas para el diseño de redes en el framework de arquitectura de Google Cloud
- Prácticas recomendadas para la selección de regiones de Compute Engine
- Google Cloud Platform para profesionales de centros de datos: Herramientas de redes
- Documentación de la VPC
- Descripción general de la red de GKE
- Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.