Diseñar redes para migrar cargas de trabajo empresariales: enfoques de arquitectura

Last reviewed 2025-01-13 UTC

En este documento se presenta una serie que describe las arquitecturas de redes y de seguridad para las empresas que están migrando cargas de trabajo de centros de datos aGoogle Cloud. Estas arquitecturas hacen hincapié en la conectividad avanzada, los principios de seguridad de confianza cero y la gestión en un entorno híbrido.

Tal como se describe en el documento complementario Arquitecturas para proteger los planos de datos en la nube, las empresas implementan un espectro de arquitecturas que tienen en cuenta las necesidades de conectividad y seguridad en la nube. Clasificamos estas arquitecturas en tres patrones distintos: lift-and-shift, servicios híbridos y distribución de confianza cero. En este documento se analizan diferentes enfoques de seguridad en función de la arquitectura que haya elegido una empresa. También se describe cómo llevar a cabo estos enfoques con los elementos básicos que proporcionaGoogle Cloud. Debes usar estas directrices de seguridad junto con otras directrices de arquitectura que abarquen la fiabilidad, la disponibilidad, la escalabilidad, el rendimiento y la gobernanza.

Este documento está diseñado para ayudar a los arquitectos de sistemas, administradores de redes y administradores de seguridad que estén planeando migrar cargas de trabajo locales a la nube. Se da por sentado lo siguiente:

  • Conoces los conceptos de redes y seguridad de centros de datos.
  • Tienes cargas de trabajo en tu centro de datos local y sabes qué hacen y quiénes son sus usuarios.
  • Tienes al menos algunas cargas de trabajo que quieres migrar.
  • Conoces los conceptos que se describen en el artículo Arquitecturas para proteger los planos de datos en la nube.

La serie consta de los siguientes documentos:

En este documento se resumen los tres patrones de arquitectura principales y se presentan los componentes básicos de recursos que puede usar para crear su infraestructura. Por último, se describe cómo ensamblar los componentes básicos en una serie de arquitecturas de referencia que coincidan con los patrones. Puedes usar estas arquitecturas de referencia como guía para tu propia arquitectura.

En este documento se mencionan las máquinas virtuales como ejemplos de recursos de carga de trabajo. La información se aplica a otros recursos que usan redes VPC, como las instancias de Cloud SQL y los nodos de Google Kubernetes Engine.

Descripción general de los patrones de arquitectura

Por lo general, los ingenieros de redes se han centrado en crear la infraestructura de redes físicas y la infraestructura de seguridad en centros de datos locales.

El proceso de transición a la nube ha cambiado este enfoque, ya que las estructuras de redes en la nube se definen por software. En la nube, los propietarios de las aplicaciones tienen un control limitado de la pila de infraestructura subyacente. Necesitan un modelo que tenga un perímetro seguro y que proporcione aislamiento para sus cargas de trabajo.

En esta serie, analizamos tres patrones de arquitectura habituales. Estos patrones se basan unos en otros y se pueden ver como un espectro en lugar de como una elección estricta.

Patrón de migración mediante lift-and-shift

En el patrón de arquitectura de migración directa, los propietarios de aplicaciones empresariales migran sus cargas de trabajo a la nube sin refactorizarlas. Los ingenieros de redes y seguridad usan controles de capa 3 y capa 4 para proporcionar protección mediante una combinación de dispositivos virtuales de red que imitan dispositivos físicos on-premise y reglas de cortafuegos en la red de VPC. Los propietarios de las cargas de trabajo implementan sus servicios en redes de VPC.

Patrón de servicios híbridos

Las cargas de trabajo creadas mediante la migración tal cual pueden necesitar acceso a servicios en la nube, como BigQuery o Cloud SQL. Normalmente, el acceso a estos servicios en la nube se realiza en las capas 4 y 7. En este contexto, el aislamiento y la seguridad no se pueden llevar a cabo estrictamente en la capa 3. Por lo tanto, las redes de servicios y los controles de servicio de VPC se usan para proporcionar conectividad y seguridad en función de las identidades del servicio al que se accede y del servicio que solicita el acceso. En este modelo, se pueden expresar políticas de control de acceso complejas.

Patrón distribuido de confianza cero

En una arquitectura de confianza cero, las aplicaciones empresariales amplían la seguridad más allá de los controles perimetrales. Dentro del perímetro, las cargas de trabajo solo pueden comunicarse con otras cargas de trabajo si su identidad de gestión de identidades y accesos tiene un permiso específico, que se deniega de forma predeterminada. En una arquitectura distribuida de confianza cero, la confianza se basa en la identidad y se aplica a cada aplicación. Las cargas de trabajo se compilan como microservicios que tienen identidades emitidas de forma centralizada. De esta forma, los servicios pueden validar a sus llamantes y tomar decisiones basadas en políticas para cada solicitud sobre si ese acceso es aceptable. Esta arquitectura se suele implementar mediante proxies distribuidos (una malla de servicios) en lugar de usar gateways centralizados.

Las empresas pueden aplicar el acceso de confianza cero de usuarios y dispositivos a las aplicaciones empresariales configurando Identity-Aware Proxy (IAP). IAP proporciona controles basados en la identidad y el contexto para el tráfico de usuarios desde Internet o la intranet.

Combinar patrones

Las empresas que están creando o migrando sus aplicaciones empresariales a la nube suelen usar una combinación de los tres patrones de arquitectura.

Google Cloud ofrece una cartera de productos y servicios que sirven como componentes básicos para implementar el plano de datos en la nube que impulsa los patrones de arquitectura. Estos elementos básicos se explican más adelante en este documento. La combinación de controles que se proporcionan en el plano de datos de la nube, junto con los controles administrativos para gestionar los recursos de la nube, forman la base de un perímetro de seguridad integral. El perímetro que se crea con esta combinación te permite controlar, desplegar y operar tus cargas de trabajo en la nube.

Jerarquía de recursos y controles administrativos

En esta sección se ofrece un resumen de los controles administrativos queGoogle Cloud proporciona como contenedores de recursos. Entre los controles se incluyenGoogle Cloud recursos de organización, carpetas y proyectos que te permiten agrupar y organizar de forma jerárquica recursos en la nube. Esta organización jerárquica te proporciona una estructura de propiedad y puntos de anclaje para aplicar políticas y controles.

Un recurso de organización de Google es el nodo raíz de la jerarquía y la base para crear implementaciones en la nube. Un recurso de organización puede tener carpetas y proyectos como elementos secundarios. Una carpeta tiene proyectos u otras carpetas como elementos secundarios. El resto de los recursos de la nube son elementos secundarios de los proyectos.

Puedes usar carpetas para agrupar proyectos. Los proyectos son la base para crear, habilitar y usar todos los Google Cloudservicios. Los proyectos te permiten gestionar APIs, habilitar la facturación, añadir y quitar colaboradores, y gestionar permisos.

Con Gestión de Identidades y Accesos (IAM) de Google, puedes asignar roles y definir políticas y permisos de acceso en todos los niveles de la jerarquía de recursos. Los recursos de niveles inferiores de la jerarquía heredan las políticas de gestión de identidades y accesos. Los propietarios de recursos que se encuentren en un nivel inferior de la jerarquía no pueden modificar estas políticas. En algunos casos, la gestión de identidades y accesos se proporciona a un nivel más granular, por ejemplo, en el ámbito de los objetos de un espacio de nombres o un clúster, como en Google Kubernetes Engine.

Consideraciones de diseño para las redes de nube privada virtual de Google

Cuando diseñes una estrategia de migración a la nube, es importante que desarrolles una estrategia sobre cómo usará tu empresa las redes VPC. Puedes considerar una red de VPC como una versión virtual de tu red física tradicional. Es una partición de red privada completamente aislada. De forma predeterminada, las cargas de trabajo o los servicios que se implementan en una red de VPC no pueden comunicarse con los trabajos de otra red de VPC. Por lo tanto, las redes de VPC permiten aislar las cargas de trabajo formando un límite de seguridad.

Como cada red de VPC de la nube es una red totalmente virtual, cada una tiene su propio espacio de direcciones IP privadas. Por lo tanto, puedes usar la misma dirección IP en varias redes de VPC sin que haya conflictos. Una implementación local típica puede consumir una gran parte del espacio de direcciones IP privadas RFC 1918. Por otro lado, si tienes cargas de trabajo tanto en las instalaciones como en redes de VPC, puedes reutilizar los mismos intervalos de direcciones en diferentes redes de VPC, siempre que esas redes no estén conectadas ni emparejadas. De esta forma, el espacio de direcciones IP se agotará más lentamente.

Las redes de VPC son globales

Las redes de VPC de Google Cloud son globales, lo que significa que los recursos desplegados en un proyecto que tiene una red de VPC pueden comunicarse entre sí directamente mediante la red troncal privada de Google.

Como se muestra en la figura 1, puedes tener una red de VPC en tu proyecto que contenga subredes en diferentes regiones que abarquen varias zonas. Las VMs de cualquier región pueden comunicarse entre sí de forma privada mediante las rutas de VPC locales.

Implementación de la red de VPC globalGoogle Cloud con subredes configuradas en diferentes regiones.

Figura 1. Google Cloud Implementación de una red de VPC global con subredes configuradas en diferentes regiones.

Compartir una red mediante VPC compartida

La VPC compartida permite que un recurso de la organización conecte varios proyectos a una red de VPC común para que puedan comunicarse entre sí de forma segura mediante direcciones IP internas de la red compartida. Los administradores de la red compartida aplican y hacen cumplir el control centralizado de los recursos de la red.

Cuando usas la VPC compartida, designas un proyecto como proyecto host y le asocias uno o varios proyectos de servicio. Las redes de VPC del proyecto del host se denominan redes de VPC compartidas. Los recursos aptos de los proyectos de servicio pueden usar subredes de la red de VPC compartida.

Las empresas suelen usar redes de VPC compartidas cuando necesitan que los administradores de redes y seguridad centralicen la gestión de los recursos de red, como las subredes y las rutas. Al mismo tiempo, las redes de VPC compartidas permiten que los equipos de aplicaciones y desarrollo creen y eliminen instancias de VM, así como que implementen cargas de trabajo en subredes designadas mediante los proyectos de servicio.

Aislar entornos mediante redes de VPC

Usar redes de VPC para aislar entornos tiene varias ventajas, pero también debes tener en cuenta algunos inconvenientes. En esta sección se abordan estas compensaciones y se describen patrones habituales para implementar el aislamiento.

Motivos para aislar entornos

Como las redes de VPC representan un dominio de aislamiento, muchas empresas las usan para mantener los entornos o las unidades de negocio en dominios independientes. Estos son algunos de los motivos habituales para crear aislamiento a nivel de VPC:

  • Una empresa quiere establecer comunicaciones de denegación predeterminada entre una red de VPC y otra, ya que estas redes representan una distinción significativa a nivel organizativo. Para obtener más información, consulta Patrones comunes de aislamiento de redes de VPC más adelante en este documento.
  • Una empresa necesita tener intervalos de direcciones IP superpuestos debido a entornos on-premise preexistentes, a adquisiciones o a implementaciones en otros entornos de nube.
  • Una empresa quiere delegar el control administrativo total de una red en una parte de la empresa.

Inconvenientes de aislar entornos

Crear entornos aislados con redes de VPC puede tener algunas desventajas. Tener varias redes de VPC puede aumentar la sobrecarga administrativa de la gestión de los servicios que abarcan varias redes. En este documento se describen las técnicas que puedes usar para gestionar esta complejidad.

Patrones de aislamiento de redes de VPC comunes

Hay algunos patrones comunes para aislar redes VPC:

  • Aísla los entornos de desarrollo, staging y producción. Este patrón permite a las empresas segregar por completo sus entornos de desarrollo, de preproducción y de producción. De hecho, esta estructura mantiene varias copias completas de las aplicaciones, con un lanzamiento progresivo entre cada entorno. En este patrón, las redes de VPC se usan como límites de seguridad. Los desarrolladores tienen un alto grado de acceso a las redes de VPC de desarrollo para hacer su trabajo diario. Cuando el desarrollo haya finalizado, un equipo de producción de ingeniería o un equipo de control de calidad pueden migrar los cambios a un entorno de preproducción, donde se pueden probar de forma integrada. Cuando los cambios están listos para desplegarse, se envían a un entorno de producción.
  • Aísla unidades de negocio. Algunas empresas quieren imponer un alto grado de aislamiento entre las unidades de negocio, especialmente en el caso de las unidades que se han adquirido o de las que exigen un alto grado de autonomía y aislamiento. En este patrón, las empresas suelen crear una red VPC para cada unidad de negocio y delegan el control de esa VPC en los administradores de la unidad de negocio. La empresa usa técnicas que se describen más adelante en este documento para exponer servicios que abarcan toda la empresa o para alojar aplicaciones orientadas al usuario que abarcan varias unidades de negocio.

Recomendación para crear entornos aislados

Te recomendamos que diseñes tus redes de VPC de forma que tengan el dominio más amplio posible que se ajuste a los límites administrativos y de seguridad de tu empresa. Puedes conseguir un aislamiento adicional entre las cargas de trabajo que se ejecutan en la misma red VPC mediante controles de seguridad, como cortafuegos.

Para obtener más información sobre cómo diseñar y crear una estrategia de aislamiento para tu organización, consulta las prácticas recomendadas y las arquitecturas de referencia para el diseño de VPC y la red en el Google Cloud plan de empresa.

Elementos de creación de redes en la nube

En esta sección se describen los componentes básicos importantes para la conectividad de red, la seguridad de la red, las redes de servicios y la seguridad de los servicios. En la figura 2 se muestra cómo se relacionan estos elementos entre sí. Puede usar uno o varios de los productos que se muestran en una fila determinada.

Componentes básicos en el ámbito de la conectividad y la seguridad de las redes en la nube.

Imagen 2. Componentes básicos en el ámbito de la conectividad y la seguridad de las redes en la nube.

En las siguientes secciones se explica cada uno de los componentes básicos y losGoogle Cloud servicios que puedes usar para cada uno de ellos.

Conectividad de red

El bloque de conectividad de red se encuentra en la base de la jerarquía. Se encarga de conectar Google Cloud recursos a centros de datos on‐premise u otras nubes. En función de tus necesidades, es posible que solo necesites uno de estos productos o que uses todos para gestionar diferentes casos prácticos.

Cloud VPN

Cloud VPN te permite conectar tus sucursales remotas u otros proveedores de la nube a las redes de VPC de Google a través de conexiones VPN IPsec. El tráfico entre ambas redes lo encripta una pasarela VPN y lo desencripta la otra, lo que ayuda a proteger los datos mientras viajan por Internet.

Cloud VPN te permite conectar tu entorno on‐premise y Google Cloud con un coste inferior, pero con un ancho de banda menor, que Cloud Interconnect (descrito en la siguiente sección). Puedes aprovisionar una VPN de alta disponibilidad para cumplir un requisito de SLA de hasta el 99,99% de disponibilidad si tienes la arquitectura adecuada. Por ejemplo, Cloud VPN es una buena opción para casos prácticos que no sean críticos o para ampliar la conectividad a otros proveedores de servicios en la nube.

Cloud Interconnect

Cloud Interconnect proporciona conectividad dedicada de nivel empresarial a Google Cloud que tiene un mayor rendimiento y un rendimiento de red más fiable en comparación con el uso de VPN o la entrada de Internet. Dedicated Interconnect proporciona conectividad física directa a la red de Google desde tus routers. Partner Interconnect proporciona conectividad dedicada a través de una amplia red de partners, que pueden ofrecer una cobertura más amplia u otras opciones de ancho de banda que Interconexión dedicada. Cross-Cloud Interconnect proporciona conectividad directa dedicada desde tus redes de VPC a otros proveedores de servicios en la nube. La interconexión dedicada requiere que te conectes en unas instalaciones de colocación en las que Google tenga presencia, mientras que Partner Interconnect no. Cloud Interconnect asegura que el tráfico entre tu red on-premise u otra red en la nube y tu red de VPC no atraviese la red pública de Internet.

Puedes aprovisionar estas conexiones de Cloud Interconnect para cumplir un requisito de SLA de hasta el 99,99% de disponibilidad si aprovisionas la arquitectura adecuada. Puedes usar Cloud Interconnect para admitir cargas de trabajo que requieran baja latencia, un ancho de banda elevado y un rendimiento predecible, al tiempo que te aseguras de que todo tu tráfico siga siendo privado.

Network Connectivity Center para entornos híbridos

Network Connectivity Center proporciona conectividad entre sitios de tus redes on-premise y de otras nubes. Para ello, usa la red troncal de Google, que ofrece una conectividad fiable entre tus sitios.

Además, puedes ampliar tu red superpuesta SD-WAN a Google Cloud configurando una VM o un dispositivo router de un proveedor externo como una vinculación de radio lógica.

Puedes acceder a los recursos de las redes de VPC mediante el dispositivo de router, la VPN o la red Cloud Interconnect como adjuntos de radio. Puedes usar Network Connectivity Center para consolidar la conectividad entre tus sitios locales, tu presencia en otras nubes yGoogle Cloud , y gestionarlo todo desde una sola vista.

Network Connectivity Center para redes de VPC

Network Connectivity Center también te permite crear una topología de malla o de estrella entre muchas redes de VPCs mediante radios de VPC. Puedes conectar el centro a nubes on-premise u otras nubes mediante radios híbridos de Network Connectivity Center.

Emparejamiento entre redes VPC

Emparejamiento de redes de VPC: te permite conectar redes de VPC de Google para que las cargas de trabajo de diferentes redes de VPC puedan comunicarse internamente, independientemente de si pertenecen al mismo proyecto o al mismo recurso de organización. El tráfico permanece en la red de Google y no atraviesa la red pública de Internet.

El emparejamiento entre redes VPC requiere que las redes que se van a emparejar no tengan direcciones IP superpuestas.

Seguridad de la red

El bloque de seguridad de la red se encuentra encima del bloque de conectividad de la red. Se encarga de permitir o denegar el acceso a los recursos en función de las características de los paquetes IP.

Cloud NGFW

Cloud Next Generation Firewall (Cloud NGFW) es un servicio de cortafuegos distribuido que te permite aplicar políticas de cortafuegos a nivel de organización, carpeta y red. Las reglas de cortafuegos habilitadas siempre se aplican, lo que protege tus instancias independientemente de su configuración, del sistema operativo o de si las VMs se han iniciado por completo. Las reglas se aplican por instancia, lo que significa que protegen las conexiones entre máquinas virtuales de una red determinada, así como las conexiones fuera de la red. La aplicación de reglas se puede controlar mediante etiquetas gestionadas por IAM, que te permiten controlar qué máquinas virtuales se rigen por reglas concretas. Cloud NGFW también ofrece la opción de inspeccionar paquetes de capa 7.

Replicación de paquetes

La replicación de paquetes clona el tráfico de las instancias especificadas en tu red de VPC y lo reenvía a los recopiladores para su análisis. La replicación de paquetes captura todo el tráfico y los datos de los paquetes, incluidas las cargas útiles y los encabezados. Puede configurar la creación de réplicas tanto para el tráfico de entrada como para el de salida, solo para el tráfico de entrada o solo para el de salida. La creación de reflejos se produce en las instancias de VM, no en la red.

Dispositivo virtual de red

Los dispositivos virtuales de red te permiten aplicar controles de seguridad y cumplimiento a la red virtual que sean coherentes con los controles del entorno local. Para ello, puedes implementar imágenes de VM disponibles en Google Cloud Marketplace en VMs que tengan varias interfaces de red, cada una de ellas conectada a una red de VPC diferente, para realizar diversas funciones virtuales de red.

Estos son algunos de los casos prácticos habituales de los dispositivos virtuales:

  • Cortafuegos de última generación (NGFW). Las NVAs de NGFW ofrecen protección en situaciones que no cubre Cloud NGFW o para proporcionar coherencia en la gestión con las instalaciones de NGFW on-premise.
  • Sistema de detección de intrusiones o sistema de prevención de intrusiones (IDS/IPS). Un IDS basado en la red ofrece visibilidad del tráfico potencialmente malicioso. Para evitar intrusiones, los dispositivos IPS pueden bloquear el tráfico malicioso para que no llegue a su destino. Google Cloud ofrece el sistema de detección de intrusos de Cloud (Cloud IDS) como servicio gestionado.
  • Pasarela web segura (SWG). Una SWG bloquea las amenazas de Internet permitiendo que las empresas apliquen políticas corporativas al tráfico que va y viene de Internet. Para ello, se usan el filtrado de URLs, la detección de código malicioso y el control de acceso. Google Cloud ofrece Secure Web Proxy como servicio gestionado.
  • Pasarela de traducción de direcciones de red (NAT). Una pasarela de NAT traduce direcciones IP y puertos. Por ejemplo, esta traducción ayuda a evitar que se solapen las direcciones IP. Google Cloud ofreceCloud NAT como servicio gestionado.
  • Cortafuegos de aplicaciones web (WAF). Un WAF se ha diseñado para bloquear el tráfico HTTP(S) malicioso que se dirige a una aplicación web. Google Cloud ofrece funciones de WAF a través de las políticas de seguridad de Google Cloud Armor. La funcionalidad exacta varía entre los proveedores de WAF, por lo que es importante determinar qué necesitas.

Cloud IDS

Cloud IDS es un servicio de detección de intrusos que permite detectar amenazas de intrusiones, malware, software espía y ataques de comando y control en tu red. Cloud IDS funciona creando una red emparejada gestionada por Google que contiene máquinas virtuales que recibirán tráfico replicado. A continuación, el tráfico replicado se inspecciona con las tecnologías de protección contra amenazas de Palo Alto Networks para ofrecer una detección avanzada de amenazas.

Cloud IDS ofrece una visibilidad total del tráfico dentro de la subred, lo que te permite monitorizar la comunicación entre máquinas virtuales y detectar movimientos laterales.

Cloud NAT

Cloud NAT ofrece una traducción de direcciones de red totalmente gestionada y definida por software para aplicaciones. Permite la traducción de direcciones de red de origen (NAT de origen o SNAT) para el tráfico orientado a Internet de las máquinas virtuales que no tienen direcciones IP externas.

Firewall Insights

Firewall Insights te ayuda a comprender y optimizar tus reglas de cortafuegos. Proporciona datos sobre cómo se utilizan las reglas de cortafuegos, expone los errores de configuración e identifica las reglas que podrían ser más estrictas. También usa el aprendizaje automático para predecir el uso futuro de tus reglas de cortafuegos, de forma que puedas tomar decisiones fundamentadas sobre si quieres eliminar o reforzar las reglas que parezcan demasiado permisivas.

Registro de red

Puede usar varios productos de Google Cloud para registrar y analizar el tráfico de red.

El almacenamiento de registros de reglas de cortafuegos te permite auditar, verificar y analizar los efectos de tus reglas de cortafuegos. Por ejemplo, puedes determinar si una regla de cortafuegos diseñada para denegar el tráfico funciona correctamente. La función Almacenamiento de registros de reglas de cortafuegos también es útil si necesitas determinar cuántas conexiones se ven afectadas por una regla de cortafuegos concreta.

Puedes habilitar el registro de reglas de cortafuegos de forma individual para cada regla de cortafuegos cuyas conexiones necesites registrar. El registro de reglas de cortafuegos es una opción para cualquier regla de cortafuegos, independientemente de la acción (permitir o denegar) o la dirección (entrada o salida) de la regla.

Registros de flujo de VPC registra una muestra de los flujos de red que envían y reciben las instancias de VM, incluidas las instancias que se usan como nodos de Google Kubernetes Engine (GKE). Estos registros se pueden usar para monitorizar la red, realizar análisis forenses, hacer análisis de seguridad en tiempo real y optimizar el gasto.

Redes de servicios

Los bloques de redes de servicios se encargan de proporcionar servicios de búsqueda que indican a los servicios dónde debe ir una solicitud (DNS, Service Directory) y de dirigir las solicitudes al lugar correcto (Private Service Connect, Cloud Load Balancing).

Cloud DNS

Se accede a las cargas de trabajo mediante nombres de dominio. Cloud DNS ofrece una traducción fiable y de baja latencia de nombres de dominio a direcciones IP que se encuentran en cualquier parte del mundo. Cloud DNS ofrece zonas públicas y zonas DNS gestionadas privadas. Las zonas públicas son visibles en Internet, mientras que las zonas privadas solo se pueden ver desde una o varias redes VPC que especifiques.

Cloud Load Balancing

Dentro de Google Cloud, los balanceadores de carga son un componente crucial, ya que dirigen el tráfico a varios servicios para proporcionar velocidad y eficiencia, así como para mejorar la seguridad a nivel global tanto para el tráfico interno como externo.

Nuestros balanceadores de carga también permiten que el tráfico se enrute y se escale en varias nubes o entornos híbridos. De esta forma, Cloud Load Balancing se convierte en la "puerta principal" a través de la cual se puede escalar cualquier aplicación, independientemente de dónde se encuentre o en cuántos lugares esté alojada. Google ofrece varios tipos de balanceo de carga: global y regional, externo e interno, y de capa 4 y capa 7.

Directorio de servicios

Directorio de servicios te permite gestionar tu inventario de servicios y te ofrece un lugar único y seguro para publicar, descubrir y conectar servicios. Todas las operaciones se basan en el control de acceso por identidad. Te permite registrar servicios con nombre y sus endpoints. El registro puede ser manual o mediante integraciones con Private Service Connect, GKE y Cloud Load Balancing. El descubrimiento de servicios se puede realizar mediante APIs HTTP y gRPC explícitas, así como con Cloud DNS.

Cloud Service Mesh

Cloud Service Mesh se ha diseñado para ejecutar aplicaciones distribuidas complejas. Para ello, habilita un amplio conjunto de políticas de gestión del tráfico y de seguridad en arquitecturas de malla de servicios.

Cloud Service Mesh admite despliegues regionales y globales basados en Kubernetes, tanto en la nube como en las instalaciones, que se benefician de un producto Istio gestionado. Google Cloud También admite Google Cloud el uso de proxies en máquinas virtuales o gRPC sin proxy.

Private Service Connect

Private Service Connect crea abstracciones de servicios al permitir que se pueda acceder a las cargas de trabajo en redes de VPC a través de un único punto final. Esto permite que dos redes se comuniquen en un modelo cliente-servidor que expone solo el servicio al consumidor en lugar de toda la red o la propia carga de trabajo. Un modelo de red orientado a servicios permite a los administradores de redes razonar sobre los servicios que exponen entre redes en lugar de subredes o VPCs, lo que permite el consumo de los servicios en un modelo productor-consumidor, ya sea para servicios propios o de terceros (SaaS).

Con Private Service Connect, una VPC de consumidor puede usar una dirección IP privada para conectarse a una API de Google o a un servicio de otra VPC.

Puedes ampliar Private Service Connect a tu red local para acceder a los puntos finales que se conectan a las APIs de Google o a los servicios gestionados de otra red de VPC. Private Service Connect permite consumir servicios en la capa 4 o en la capa 7.

En la capa 4, Private Service Connect requiere que el productor cree una o varias subredes específicas de Private Service Connect. Estas subredes también se denominan subredes NAT. Private Service Connect realiza NAT de origen mediante una dirección IP seleccionada de una de las subredes de Private Service Connect para enrutar las solicitudes a un productor de servicios. Con este enfoque, puedes usar direcciones IP superpuestas entre consumidores y productores.

En la capa 7, puedes crear un backend de Private Service Connect con un balanceador de carga de aplicaciones interno. El balanceador de carga de aplicación interno te permite elegir qué servicios están disponibles mediante un mapa de URLs. Para obtener más información, consulta Acerca de los back-ends de Private Service Connect.

Acceso a servicios privados

El acceso a servicios privados es una conexión privada entre tu red VPC y una red que pertenece a Google o a un tercero. Google o los terceros que ofrecen servicios se denominan productores de servicios. El acceso a servicios privados usa el emparejamiento entre redes VPC para establecer la conectividad y requiere que las redes VPC del productor y del consumidor estén emparejadas entre sí. Esto es diferente de Private Service Connect, que te permite proyectar una sola dirección IP privada en tu subred.

La conexión privada permite que las instancias de VM de tu red de VPC y los servicios a los que accedas se comuniquen exclusivamente mediante direcciones IP internas. Las instancias de VM no necesitan acceso a Internet ni direcciones IP externas para acceder a los servicios disponibles a través del acceso privado a los servicios. El acceso a servicios privados también se puede ampliar a la red on-premise mediante Cloud VPN o Cloud Interconnect para que los hosts on-premise puedan acceder a la red del productor de servicios. Para ver una lista de los servicios gestionados por Google que se admiten mediante el acceso a servicios privados, consulta la sección Servicios admitidos de la documentación de Virtual Private Cloud.

Acceso a VPC sin servidor

Acceso a VPC sin servidor te permite conectarte directamente a tu red de VPC desde servicios alojados en entornos sin servidor, como Cloud Run, App Engine o funciones de Cloud Run. Configurar Acceso a VPC sin servidor permite que tu entorno sin servidor envíe solicitudes a tu red de VPC mediante DNS interno y direcciones IP internas. Las respuestas a estas solicitudes también usan tu red virtual.

Acceso a VPC sin servidor envía tráfico interno desde tu red de VPC a tu entorno sin servidor solo cuando ese tráfico es una respuesta a una solicitud que se ha enviado desde tu entorno sin servidor a través del conector de Acceso a VPC sin servidor.

Acceso a VPC sin servidor ofrece las siguientes ventajas:

  • Las solicitudes enviadas a tu red de VPC nunca se exponen a Internet.
  • La comunicación a través de Acceso a VPC sin servidor puede tener una latencia menor que la comunicación a través de Internet.

Salida de VPC directa

Salida de VPC directa permite que tu servicio de Cloud Run envíe tráfico a una red de VPC sin configurar un conector de acceso a VPC sin servidor.

Seguridad del servicio

Los bloques de seguridad de servicios controlan el acceso a los recursos en función de la identidad del solicitante o de una comprensión de nivel superior de los patrones de paquetes, en lugar de solo las características de un paquete individual.

Cloud Armor para DDoS/WAF

Cloud Armor es un cortafuegos de aplicaciones web (WAF) y un servicio de mitigación de denegación de servicio distribuido (DDoS) que te ayuda a proteger tus aplicaciones y servicios web frente a varios tipos de amenazas. Entre estas amenazas se incluyen los ataques DDoS, los ataques basados en web, como el cross-site scripting (XSS) y la inyección de SQL (SQLi), así como los ataques de fraude y automatización.

Cloud Armor inspecciona las solicitudes entrantes en la red perimetral mundial de Google. Tiene un conjunto integrado de reglas de cortafuegos de aplicaciones web para detectar ataques web comunes y un sistema de detección de ataques avanzado basado en aprendizaje automático que crea un modelo de tráfico correcto y, a continuación, detecta el tráfico incorrecto. Por último, Cloud Armor se integra con reCAPTCHA de Google para ayudar a detectar y detener el fraude sofisticado y los ataques basados en la automatización mediante la telemetría de endpoints y la telemetría de la nube.

Identity-Aware Proxy (IAP)

Identity-Aware Proxy (IAP) proporciona controles de acceso contextuales a las aplicaciones y las máquinas virtuales basadas en la nube que se ejecutan en Google Cloud o que están conectadas a Google Cloudmediante cualquiera de las tecnologías de redes híbridas. IAP verifica la identidad del usuario y determina si la solicitud del usuario procede de fuentes de confianza en función de varios atributos contextuales. IAP también admite la creación de túneles TCP para el acceso SSH o RDP de los usuarios de la empresa.

Controles de Servicio de VPC

Controles de Servicio de VPC te ayuda a mitigar el riesgo de filtración externa de datos de Google Cloudservicios como Cloud Storage y BigQuery. Usar Controles de Servicio de VPC ayuda a asegurarse de que los servicios de Google Cloud solo se usen en entornos aprobados.

Puedes usar Controles de Servicio de VPC para crear perímetros que protejan los recursos y los datos de los servicios que especifiques limitando el acceso a elementos de identidad nativos de la nube específicos, como las cuentas de servicio y las redes de VPC. Una vez que se ha creado un perímetro, se deniega el acceso a los servicios de Google especificados, a menos que la solicitud proceda de dentro del perímetro.

Distribución de contenido

Los bloques de distribución de contenido controlan la optimización de la distribución de aplicaciones y contenido.

Cloud CDN

Cloud CDN ofrece aceleración de contenido estático mediante la red perimetral mundial de Google para distribuir contenido desde el punto más cercano al usuario. De esta forma, se reduce la latencia de tus sitios web y aplicaciones.

Media CDN

Media CDN es la solución de distribución de contenido multimedia de Google y se ha diseñado para cargas de trabajo de salida de alto rendimiento.

Observabilidad

Los bloques de observabilidad te permiten ver tu red y te proporcionan información valiosa que puedes usar para solucionar, documentar e investigar problemas.

Network Intelligence Center

Network Intelligence Center incluye varios productos que abordan distintos aspectos de la observabilidad de la red. Cada producto se centra en un aspecto diferente y proporciona estadísticas valiosas para informar a los administradores, arquitectos y profesionales sobre el estado y los problemas de la red.

Arquitecturas de referencia

En los siguientes documentos se presentan arquitecturas de referencia para diferentes tipos de cargas de trabajo: en la nube, orientadas a Internet e híbridas. Estas arquitecturas de carga de trabajo se basan en un plano de datos en la nube que se implementa mediante los componentes y los patrones de arquitectura que se han descrito en secciones anteriores de este documento.

Puedes usar las arquitecturas de referencia para diseñar formas de migrar o crear cargas de trabajo en la nube. Tus cargas de trabajo se basan en el plano de datos de la nube y usan las arquitecturas. Aunque estos documentos no proporcionan un conjunto exhaustivo de arquitecturas de referencia, sí cubren los casos más habituales.

Al igual que con los patrones de arquitectura de seguridad que se describen en Arquitecturas para proteger planos de datos en la nube, los servicios reales pueden usar una combinación de estos diseños. En estos documentos se analiza cada tipo de carga de trabajo y las consideraciones de cada arquitectura de seguridad.

Siguientes pasos