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

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

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:

Considera diseñar la red de VPC con anticipación

El diseño de la red de VPC debe ser una parte inicial de la creación de la configuración de la organización en Google Cloud. Cuando hay varias opciones de diseño a nivel de la organización, no se pueden revertir con facilidad una vez que el proceso avanza.

Piensa en tus opciones de diseño de la red de VPC antes de hacer cualquier implementación significativa. Para reubicar los recursos de una red de VPC a otra, es necesario volver a crearlos.

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.

Usa un diseño 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, stage y 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 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-1

  • Subred
    sintaxis: {company-name}-{description(App or BU)-label}-{region/zone-label}
    ejemplo: acmeco-hr-na-ne1-dev-subnet

  • Regla 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-rule

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

Direcciones y subredes

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.
  • 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, Google Cloud crea de forma automática una subred nueva en una red en modo automático. Las redes de VPC en modo personalizado proporcionan más flexibilidad para planificar y evitar la superposición de direcciones.

Después de crear la red de VPC en modo personalizado, puedes borrar la red default. Ten en cuenta que no puedes borrar una red de VPC hasta que hayas quitado todos los recursos (incluidas las instancias de 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

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 proyectos de servicio para los equipos a cada 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 la función 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 están disponibles para implementar recursos en cada proyecto de servicio.

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.

Proyecto de servicio en varias VPC

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 recursos de VPC a los proyectos

Las cuotas son restricciones predeterminadas que se aplican a nivel de proyecto y pueden aumentar si solicitas una cuota adicional en Google Cloud. Están diseñadas para protegerte del uso inesperado de recursos. Sin embargo, existen muchos factores que pueden hacer que solicites aumentos.

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 se suelen aplicar dentro de una red de VPC y están diseñados para proteger los recursos del sistema en conjunto. 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:

  • networkAdmin
  • securityAdmin
  • networkUser
  • networkViewer

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

Una vez que decidas implementar varias redes de VPC, debes conectarlas. Las redes de VPC son espacios de usuario aislados dentro de Andromeda, la SDN de Google, y se pueden comunicar entre sí de varias formas. 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
  • Es fácil de configurar.
  • Ofrece una sobrecarga de administración baja.
  • Tiene un ancho de banda alto.
  • Ofrece cargos de salida bajos (igual que una sola red de VPC).
  • Cada red de VPC mantiene su propio firewall distribuido.
  • Cada red de VPC mantiene sus propias cuentas y permisos de IAM.
  • No es transitivo.
  • Los números de escalamiento están vinculados al grupo agregado de redes de VPC de intercambio de tráfico. Esto incluye la cantidad de VM, rutas y reglas de reenvío interno.
  • Requiere espacio de direcciones que no se superpongan.
  • Las rutas estáticas y dinámicas no se propagan.
  • Las etiquetas de origen y las cuentas de servicio de origen de la VM emisora no se propagan a través del intercambio de tráfico entre redes de VPC.
Enrutamiento externo (IP pública o puerta de enlace de NAT).
  • No se necesita ninguna configuración.
  • Hay un aislamiento completo entre las redes de VPC.
  • Se puede superponer el espacio de direcciones IP.
  • Tiene un ancho de banda alto.
  • Los cargos de salida de las VM ubicadas dentro de la misma zona son más altos que para otras opciones, como el intercambio de tráfico entre redes de VPC.
  • Las VM deben exponerse mediante direcciones IP externas.
  • No hay firewalls con direcciones IP privadas.
  • Las rutas estáticas y dinámicas no se propagan.
  • Las redes de intercambio de tráfico no respetan las etiquetas de origen ni las cuentas de servicio de origen de la VM emisora.
Cloud VPN
  • Habilita topologías transitivas para concentrador y radio (solo enrutamiento estático).
  • Es escalable a través de ECMP.
  • Ofrece un ANS de disponibilidad de servicio del 99.9% en la VPN clásica.
  • Ofrece un ANS de disponibilidad de servicio del 99.9% de VPN con alta disponibilidad cuando esta función está disponible para el público general.
  • Tiene sobrecarga de administración.
  • Se factura según las tarifas de salida de Internet.
  • Ofrece una latencia un poco más alta.
  • Su capacidad de procesamiento está limitada a aproximadamente 1.5 Gbps por túnel.
  • Tiene MTU baja debido al encapsulamiento adicional del túnel.
  • Las etiquetas de origen y las cuentas de servicio de origen de la VM emisora se pierden en el túnel.
Cloud Interconnect: Dedicada o de socio
  • Ofrece ANS basados en la redundancia en la implementación:
  • Cada vínculo de una interconexión dedicada es una conexión de 10 Gbps o 100 Gbps. Se pueden agrupar varios vínculos de interconexión para aumentar la capacidad de procesamiento, con un máximo de 8 circuitos de 10 Gbps (80 Gbps) o 2 circuitos de 100 Gbps (200 Gbps) para cada conexión de interconexión dedicada.
  • Es posible usar ECMP en varias interconexiones para aumentar la capacidad de procesamiento.
  • Tiene cargos adicionales de costo y salida para el tráfico enviado entre redes de VPC a través de una conexión de interconexión.
  • El tráfico no está encriptado.
  • Ofrece latencia adicional sobre las soluciones nativas de la nube.
  • Tiene dispositivos de hardware adicionales en la ruta que pueden fallar.
Interfaces de red múltiples (varias NIC)
  • Se puede escalar mediante grupos de instancias administrados y rutas de ECMP entre instancias.
  • Cada CPU virtual tiene un límite de salida de 2 Gbps para el rendimiento máximo, hasta un valor máximo teórico de 16 Gbps.
  • Ofrece un límite de 8 interfaces por instancia.
  • El balanceo de cargas solo se puede realizar en la interfaz de red predeterminada (nic0) de una VM.

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 VM 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 el nivel de servicio de red que tengan. Usa reglas de firewall de GCP para controlar el tráfico externo entrante (de entrada) a las VM.

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

Cloud VPN proporciona un servicio administrado para conectar redes de VPC mediante la creación de un túnel IPSec entre dos extremos con enrutamiento estático o dinámico. La VPN clásica y el enrutamiento estático permiten 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. No uses Cloud VPN como una red de tránsito entre redes locales, como se explica en la documentación de Cloud VPN. Para otras situaciones, recomendamos VPN con alta disponibilidad, ya que proporciona un ANS del 99.99% en GA, pero solo se admite el enrutamiento dinámico.

Sin embargo, Cloud VPN puede presentar una restricción de rendimiento, ya que requiere una unidad de transmisión máxima (MTU) más baja dentro de la red de VPC debido a los encapsulamientos del túnel adicionales, lo que limita la capacidad de procesamiento de transmisión única.

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 de Cloud Interconnect para conectarte directamente a Google o usar la interconexión de socio a fin de conectarte a Google a través de un proveedor de servicios compatible.

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 de RFC 1918 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 VM de varias NIC, 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 a través de un dispositivo local debido a políticas corporativas.

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

Las VM de interfaces de red múltiples (varias NIC) son comunes en las redes de VPC que requieren seguridad o servicios adicionales entre ellas, porque las VM de varias NIC 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 cada interfaz no deben superponerse.

Varias NIC con VPC compartida

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 dos enfoques para los servicios compartidos son Cloud VPN y el intercambio de tráfico entre redes de VPC. Usa 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. Usa 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.

Intercambio de tráfico entre redes de VPC Intercambio de tráfico de Cloud VPN
Límites de red de VPC con intercambio de tráfico 25 Cuota del túnel VPN
Instancias 15,500 en todas las redes de VPC con intercambio de tráfico 15,000 por red de VPC
Reglas de reenvío internas 50 en todas las redes de VPC con intercambio de tráfico 50 por red de VPC
Costo Sin cargos adicionales Por túnel VPN y cargos de salida de tráfico
Capacidad de procesamiento Igual que la red dentro de la VPC Hasta 3 Gbps por túnel de Cloud VPN

El intercambio de tráfico entre redes de VPC ofrece un enfoque simple para la conectividad de servicios compartidos. En este modelo, 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.

Servicios compartidos con intercambio de tráfico entre redes de VPC

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 Herramientas de redes de servicios. Mediante la API de Herramientas de redes de servicios, 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 una alternativa al intercambio de tráfico entre redes de VPC. 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.

servicios compartidos con Cloud VPN

Diseño híbrido: conexión de un entorno local

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 VM, sin importar la región ni el proyecto de servicio, pueden acceder a la conexión de Cloud Interconnect.

Usa el enrutamiento dinámico cuando sea posible

En general, recomendamos que uses el enrutamiento dinámico. Es posible que debas usar el enrutamiento estático en algunas circunstancias, por ejemplo, si los dispositivos locales no admiten el enrutamiento dinámico.

Enrutamiento dinámico

El enrutamiento dinámico está disponible en todas las soluciones de interconexión, 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, 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 VM, sin importar la región. El enrutamiento estático también permite a los administradores de red configurar de forma selectiva las VM 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:

diseño híbrido

Seguridad de red

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 API y servicios de Google a través del Acceso privado a Google. Este acceso privado permite que los recursos interactúen con servicios clave de Google y Google Cloud, pero que 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 tus 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 a fin de 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.

Google Cloud Marketplace cuenta con un gran ecosistema de soluciones de terceros, incluidas las VM 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 por medio de un hash de 5 tuplas) o con prioridades diferentes (a fin de crear una ruta redundante), como se muestra en varias rutas a la subred de desarrollo que aparece en el siguiente diagrama.

administra el tráfico con reglas de firewall nativo

La mayoría de las soluciones requieren varias interfaces de red (varias NIC). Debido a que una VM no puede tener más de una interfaz por red de VPC, cuando creas una VM con varias NIC, 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 varias NIC que conecte muchas redes de VPC que residan 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 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 controlar estos factores en las arquitecturas de requisitos de escala alta, envía controles de seguridad a los extremos. Comienza por endurecer las VM y usar reglas de firewall de GCP. 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 VM de varias NIC.

Para obtener un ejemplo adicional de esta configuración, consulta la arquitectura de referencia de firewall con estado L7 entre redes de VPC.

Usa conjuntos de reglas de firewall más amplios pero en menor cantidad cuando sea posible

El firewall de VPC solo permite que se programe una cantidad limitada de reglas en una 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:

  1. Aplica reglas de firewall que se compartan en todas las VM de la red de VPC.
  2. Aplica reglas de firewall que se puedan agrupar en varias VM, como un grupo de instancias de servicio o una subred.
  3. 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 GCP. 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.

Como se mencionó antes, puedes identificar las VM de una subred específica si aplicas una etiqueta de red o una cuenta de servicio únicas a esas instancias. Esto te permite crear reglas de firewall que solo se apliquen a las VM 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 VM 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 VM 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 origen0.0.0.0/0
Regla 2: Permitir el nivel web → nivel de la app Objetivos: etiquetas de objetivo especificadas
Etiquetas de objetivoapp
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 origenapp

Sin embargo, aunque se pueden usar etiquetas para el filtrado de objetivos de esta manera, te recomendamos que uses cuentas de servicio siempre que sea posible. Las etiquetas de objetivo no tienen acceso controlado, y una persona que tenga la función instanceAdmin las puede modificar mientras las VM están en servicio. 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, recuerda que un administrador de instancias puede cambiar esas etiquetas. Esto puede eludir la política de seguridad. Por lo tanto, si usas etiquetas en un entorno de producción, usa un framework de automatización para superar la falta de control de IAM sobre las etiquetas. Por ejemplo, usa Forseti, que te brinda estadísticas sobre los cambios en la configuración y puede ayudarte a solucionar problemas.

Usa herramientas adicionales para proteger y asegurar las 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 Cloud Identity-Aware Proxy (IAP) para verificar la identidad del usuario y el contexto de la solicitud a fin de 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

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 IP de NAT por región que se usan para las comunicaciones salientes.

Sin embargo, 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 GCP son reglas con 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

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 API de Google permanece dentro de la red de Google.

De forma predeterminada, solo las instancias con una dirección IP externa pueden comunicarse con las API y los servicios de Google. Si necesitas acceso desde instancias que no tengan una dirección IP externa, usa la función Acceso privado a Google para cada subred. Esto no ralentiza las comunicaciones de las API 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 API 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 API y los servicios de Google de la misma subred y habilita el Acceso privado a Google para las instancias sin direcciones IP externas.

Si accedes a las API de Google desde el entorno local, consulta Configura el Acceso privado a Google de los hosts locales a fin de acceder a algunos servicios de Google a través de rangos de direcciones IP privadas. Verifica los servicios compatibles antes de activar esta función, ya que no será posible acceder a otras API 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.

Registro, supervisión y visibilidad

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 del registro de flujo de VPC para reducir el volumen

Usa el muestreo del registro 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 único, red de VPC única

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.

Proyecto host único, varios proyectos de servicio y VPC compartida única

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.

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

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.

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

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.

Firewall con estado L7 entre VPC

¿Qué sigue?