Semana 4 · Módulo 4 de 12

Redes en Google Cloud (II): conectividad híbrida, multicloud y entre VPC

Aprenderás a conectar Google Cloud con el centro de datos y con otras nubes (Cloud VPN, Cloud Interconnect), a conectar VPC entre sí (peering, Shared VPC, Network Connectivity Center) y a consumir y publicar servicios de forma privada (Private Service Connect, Private Service Access). Es el núcleo del apartado 2.1 y aparece en casi todos los casos de estudio.

Reparto de la semana

Por qué importa

Casi ninguna empresa empieza en la nube desde cero. Tiene un centro de datos, quizá otra nube, y necesita que todo se hable de forma privada, fiable y segura durante años (en la migración y después). Los casos de estudio del examen lo repiten: hay sistemas que se quedan on-premises, datos que viajan cada noche, fábricas o sedes que se conectan, otra nube que no se puede abandonar.

El apartado 2.1 de la guía pide exactamente esto: extender la red a on-premises (redes híbridas), a multicloud e incluso comunicar Google Cloud con Google Cloud (otras VPC, otros proyectos, otras organizaciones), protegerlo (intrusiones, control de acceso, firewalls) y dar acceso a servicios de la nube y «adyacentes». El 1.3 añade peering, Shared VPC y Private Service Connect como piezas de diseño.

Las preguntas suelen dar requisitos numéricos o de negocio («20 Gbps», «tráfico cifrado», «no tenemos presencia en un centro de colocación», «SLA del 99,99 %», «equipo de red central y equipos de aplicación separados») y tienes que elegir la pieza correcta. Esta semana aprendes a leer esos requisitos.

Cloud Router y BGP: la pieza común

Antes de los productos, el protocolo. BGP (Border Gateway Protocol) es el protocolo con el que dos redes se anuncian mutuamente qué rangos IP tienen. Cada extremo se identifica con un ASN (número de sistema autónomo); en conexiones privadas se usan ASN privados (64512-65534 o 4200000000-4294967294).

Cloud Router es el servicio gestionado que habla BGP en nombre de tu VPC:

• Es regional y pertenece a una VPC.
• Es un plano de control: aprende rutas del otro extremo y las instala como rutas dinámicas en la VPC; anuncia tus subredes al otro extremo. El tráfico no pasa por él.
• Es obligatorio para HA VPN, Dedicated Interconnect, Cross-Cloud Interconnect y los router appliances de Network Connectivity Center; también lo usa Cloud NAT (sin BGP).
• Anuncio por defecto: todas las subredes de la VPC (según el modo de enrutamiento). Anuncio personalizado (custom advertisement): eliges qué rangos anunciar, por ejemplo añadir 199.36.153.4/30 para Private Google Access desde on-premises o 35.199.192.0/19 para DNS.
• Admite BFD (detección rápida de caídas), autenticación MD5, IPv4 e IPv6 y prioridades de ruta (MED) para preferir un camino sobre otro (activo/pasivo).

El modo de enrutamiento dinámico de la VPC es clave:

• Regional: las rutas aprendidas por un Cloud Router solo llegan a las VMs de su región.
• Global: llegan a todas las regiones de la VPC.

flowchart LR
  OP["Centro de datos 10.0.0.0/16"] ---|"BGP sobre HA VPN"| CR["Cloud Router europe-southwest1"]
  CR --> VPC["VPC con modo de enrutamiento global"]
  VPC --> MAD["VMs en Madrid: ven 10.0.0.0/16"]
  VPC --> BEL["VMs en Bélgica: también lo ven"]

Cloud VPN

Cloud VPN conecta tu VPC con otra red mediante túneles IPsec cifrados que viajan por Internet pública. Hay dos tipos:

Datos que se preguntan:

• Ancho de banda por túnel: hasta 250.000 paquetes por segundo (entrada + salida), lo que equivale a entre 1 y 3 Gbps según el tamaño de paquete. Para más, añades túneles y repartes con ECMP.
• Soporta IKEv1 e IKEv2 con clave precompartida.
• El 99,99 % exige que ambas interfaces del gateway HA VPN tengan túnel hacia el otro extremo (dos dispositivos on-premises, o uno con dos interfaces, o dos gateways HA VPN entre VPC). Con un solo túnel no hay SLA de 99,99 %.
• Sirve para conectar con on-premises, con otras nubes (con AWS se usan cuatro túneles) y entre dos VPC de Google Cloud (útil cuando el peering no vale, por ejemplo para transitividad).
• Requiere el nivel de red Premium.
• Coste (estimación a 30/09/2026, precios de Cloud VPN): unos 0,05 USD/h por túnel en la mayoría de regiones (0,08 USD/h en algunas), más la salida de datos. Un HA VPN con dos túneles ronda los 73 USD/mes solo en túneles.

flowchart LR
  subgraph GC["Google Cloud, región europe-southwest1"]
    GW["HA VPN gateway: interfaz 0 e interfaz 1"]
    CR["Cloud Router ASN 65001"]
  end
  subgraph ON["On-premises"]
    R1["Router 1"]
    R2["Router 2"]
  end
  GW -->|"Túnel 0 + sesión BGP"| R1
  GW -->|"Túnel 1 + sesión BGP"| R2
  CR -.- GW

Cloud Interconnect

Cuando la VPN se queda corta (ancho de banda, latencia estable, coste por volumen), se usa Cloud Interconnect: conexiones físicas privadas que no pasan por Internet. Tres variantes:

Dedicated Interconnect

Un circuito físico directo entre tu router y la red de Google en un centro de colocación (colocation facility) donde Google está presente.

• Capacidades por circuito: 10 Gbps, 100 Gbps o 400 Gbps; puedes agrupar hasta 8 circuitos en una conexión (hasta 80 Gbps, 800 Gbps o 3,2 Tbps). El tipo de enlace no se puede cambiar después.
• Requisitos: estar (tú o tu operador) en el centro de colocación, router con fibra monomodo, LACP, 802.1Q (VLAN) y eBGP.
• Sobre la conexión física creas VLAN attachments (adjuntos de VLAN), cada uno asociado a un Cloud Router con su sesión BGP.
• Topologías para SLA:
  • 99,9 %: al menos 2 conexiones en la misma área metropolitana, en dominios de disponibilidad perimetral (edge availability domains) distintos.
  • 99,99 %: al menos 4 conexiones, 2 en una metrópoli y 2 en otra, con Cloud Routers en dos regiones (y la VPC en modo de enrutamiento global).

Partner Interconnect

Conectividad a través de un proveedor de servicios (operador) que ya está conectado con Google. Para cuando no puedes llegar a un centro de colocación o no necesitas 10 Gbps.

• Capacidades por VLAN attachment: de 50 Mbps a 50 Gbps (según lo que ofrezca el proveedor).
• Capa 2: el proveedor da la conexión y tú configuras BGP entre tu router y Cloud Router. Capa 3: el proveedor gestiona también BGP.
• El SLA de Google cubre la parte Google-proveedor; lo demás depende del contrato con el proveedor. Hay topologías de 99,9 % y 99,99 % (esta con attachments en dos regiones).

Cross-Cloud Interconnect

Enlace físico dedicado entre Google Cloud y otra nube: AWS, Microsoft Azure, Oracle Cloud Infrastructure (OCI) y Alibaba Cloud. Google provisiona el enlace físico hasta la otra nube.

• Capacidades: 10 y 100 Gbps (y 400 Gbps con AWS y OCI).
• Para SLA hay que comprar al menos una conexión primaria y otra redundante (99,9 %), o dos pares en metrópolis distintas (99,99 %).
• Es la respuesta a «multicloud con alto ancho de banda y privado». Con poco volumen, bastaría HA VPN hacia la otra nube.

Cifrado y otras opciones

• Cloud Interconnect no cifra el tráfico por defecto (es privado, pero no cifrado). Opciones: MACsec (cifrado de capa 2 entre tu router y el de Google en circuitos compatibles) o HA VPN sobre Cloud Interconnect (túneles IPsec sobre los VLAN attachments, para Dedicated y Partner). También puedes cifrar en la aplicación (TLS).
• Cross-Site Interconnect (en preview a fecha de redacción): conectividad de capa 2 entre tus propias sedes usando la red de Google.
• Direct Peering y Carrier Peering conectan con la red de Google para llegar a Google Workspace y APIs públicas, no a tus VPC, y no tienen SLA. Son distractores frecuentes.

Cómo elegir la conectividad híbrida

flowchart TD
  A{"¿Conectas con otra nube?"} -->|Sí| B{"¿Mucho volumen o latencia estable?"}
  B -->|Sí| CCI["Cross-Cloud Interconnect"]
  B -->|No| VPN1["HA VPN hacia la otra nube"]
  A -->|"No, con on-premises"| C{"¿Necesitas más de unos pocos Gbps o latencia estable?"}
  C -->|No| VPN2["HA VPN"]
  C -->|Sí| D{"¿Puedes llegar a un centro de colocación de Google y necesitas 10 Gbps o más?"}
  D -->|Sí| DI["Dedicated Interconnect"]
  D -->|No| PI["Partner Interconnect"]
  DI --> E{"¿Exigen cifrado?"}
  PI --> E
  E -->|Sí| F["MACsec o HA VPN sobre Interconnect"]

Conectar VPC entre sí

La comunicación «Google Cloud con Google Cloud» tiene tres herramientas principales, más la VPN entre VPC.

VPC Network Peering

VPC Network Peering une dos VPC (del mismo proyecto, de proyectos distintos e incluso de organizaciones distintas) para que se hablen por IP interna con el rendimiento de una sola red.

• Cada lado crea su parte del peering; cada administrador conserva el control de su VPC (útil entre empresas o unidades independientes).
• Se intercambian siempre las rutas de subred; las rutas estáticas y dinámicas personalizadas solo si las exportas e importas explícitamente (--export-custom-routes / --import-custom-routes).
• No es transitivo: si A está unida con B y B con C, A no llega a C. Tampoco se «hereda» la VPN o el Interconnect del vecino salvo que exportes/importes rutas personalizadas (y aun así no hay tránsito entre dos peerings).
• Los rangos no pueden solaparse.
• No se comparten reglas de firewall ni políticas; y las etiquetas y cuentas de servicio del otro lado no sirven en tus reglas (tienes que usar rangos IP).
• El DNS interno de Compute Engine no cruza el peering (usa zonas de peering de Cloud DNS).
• Hay cuotas de peerings por red y de recursos en el «grupo de peering» (consúltalas en la página de cuotas de VPC); con muchas VPC, los límites y la no transitividad empujan a otras soluciones.
• No tiene coste propio (solo el tráfico, como si fuera una misma red).

Shared VPC

Shared VPC permite que una VPC viva en un proyecto (host project) y que otros proyectos (service projects) creen sus recursos (VMs, GKE, balanceadores internos…) en sus subredes.

• Requiere una organización (los proyectos deben estar en la misma organización).
• Un proyecto es host o service, no ambos. Un service project se adjunta a un solo host project; una organización puede tener varios host projects (p. ej. uno de producción y otro de no producción).
• Roles:
  • Shared VPC Admin (roles/compute.xpnAdmin, a nivel de organización o carpeta): habilita host projects y adjunta service projects.
  • Network User (roles/compute.networkUser): se concede a los administradores de service projects sobre todo el host project o solo sobre subredes concretas para que puedan usar esas subredes.
  • El equipo de red central gestiona subredes, rutas, firewall, VPN e Interconnect en el host project.
• Facturación: cada recurso se factura al service project donde se crea, lo que permite repartir costes por equipo.

Es la respuesta de manual a separación de funciones: «un equipo central de red controla la red y la seguridad; los equipos de aplicación despliegan sus cargas sin poder tocar la red».

flowchart TB
  subgraph ORG["Organización"]
    subgraph HOST["Host project: red-prod"]
      VPC["Shared VPC con subredes, firewall, Cloud Router, VPN e Interconnect"]
    end
    SP1["Service project: tienda-prod"] -->|"usa subred-tienda"| VPC
    SP2["Service project: pagos-prod"] -->|"usa subred-pagos"| VPC
    SP3["Service project: datos-prod"] -->|"usa subred-datos"| VPC
  end
  VPC --- ONP["On-premises por Interconnect"]

Network Connectivity Center

Network Connectivity Center (NCC) es un modelo hub-and-spoke gestionado: creas un hub y le conectas spokes (radios):

• VPC spokes: VPC (de cualquier proyecto u organización, con aprobación) que obtienen conectividad entre sí de forma transitiva a través del hub. Topologías predefinidas: malla (todos con todos) o estrella (un grupo central habla con los extremos, los extremos no entre sí). Admiten filtros de exportación de rangos.
• Hybrid spokes: túneles HA VPN, VLAN attachments de Interconnect (Dedicated, Partner, Cross-Cloud) o router appliances (VMs de SD-WAN de terceros). Sus rutas dinámicas se propagan a los VPC spokes.
• Producer VPC spokes: llevan servicios publicados por productores (p. ej. los de Private Service Access) al resto de spokes.
• Transferencia de datos entre sedes (site-to-site data transfer): usar la red de Google como WAN entre tus oficinas o centros de datos.

Es la respuesta cuando hay muchas VPC que deben hablarse, cuando el peering se queda corto por no transitividad o límites, o cuando quieres usar Google como WAN corporativa.

Tabla de decisión: cómo conectar VPC

Acceso privado a servicios: PGA, PSC y PSA

Tres nombres parecidos que el examen adora confundir.

Private Google Access (repaso)

Lo viste en el módulo 3: VMs sin IP externa acceden a APIs de Google (Cloud Storage, BigQuery…) por sus IP públicas pero sin salir a Internet. Se activa por subred.

Desde on-premises: los hosts del centro de datos pueden usar las APIs de Google por la VPN o el Interconnect si:

1. Resuelves *.googleapis.com a private.googleapis.com (199.36.153.8/30) o a restricted.googleapis.com (199.36.153.4/30, si usas VPC Service Controls) en el DNS on-premises.
2. Anuncias ese rango desde Cloud Router con un anuncio personalizado.

Private Service Connect (PSC)

Private Service Connect crea en tu VPC un endpoint con una IP interna tuya que da acceso privado a un servicio. Hay dos grandes usos:

1. PSC para APIs de Google: un endpoint (una regla de reenvío global con IP interna) que apunta a un paquete de APIs: all-apis (casi todas) o vpc-sc (solo las compatibles con VPC Service Controls). Cloud DNS crea nombres del tipo storage-ENDPOINT.p.googleapis.com. Ventaja frente a PGA: eliges la IP, puedes alcanzarla desde on-premises y redes conectadas y tienes control fino del camino.
2. PSC para servicios publicados (published services): un productor (otro equipo, un SaaS o un servicio gestionado de Google) publica su servicio detrás de un balanceador interno mediante un service attachment (con su subred PSC y una lista de consumidores aceptados). El consumidor crea un endpoint en su VPC que apunta al service attachment.

Propiedades clave:

• Solo expone un servicio, no conecta las redes: el consumidor no ve el resto de la VPC del productor ni al revés.
• Usa NAT entre ambos lados, así que los rangos IP pueden solaparse y no hay que coordinar direccionamiento.
• Funciona entre proyectos y entre organizaciones.
• También hay PSC backends (el endpoint es un NEG detrás de un balanceador del consumidor, para añadir Cloud Armor, certificados propios, etc.) y PSC interfaces (el productor inicia conexiones hacia la red del consumidor).
• Coste orientativo (a 30/09/2026, precios de PSC): un endpoint para APIs de Google, unos 0,01 USD/h sin cargo por datos; publicar servicios no tiene cargo propio de PSC (el productor paga su balanceador).

flowchart LR
  subgraph CONS["VPC del consumidor 10.0.0.0/16"]
    VM["Cliente"] --> EP["Endpoint PSC 10.0.9.10"]
  end
  subgraph PROD["VPC del productor, también 10.0.0.0/16"]
    SA["Service attachment"] --> ILB["Balanceador interno"] --> APP["Backends del servicio"]
  end
  EP -->|"Private Service Connect con NAT"| SA

Private Service Access (PSA)

Private Service Access (acceso a servicios privados) es el mecanismo anterior con el que muchos servicios gestionados de Google se colocan con IP interna en tu red: Cloud SQL, Memorystore, AlloyDB, Filestore, entre otros.

• Reservas un rango IP en tu VPC para Google (gcloud compute addresses create ... --purpose=VPC_PEERING) y creas una conexión privada (gcloud services vpc-peerings connect ...) con la red de Service Networking.
• Por debajo es un VPC Network Peering con la VPC del productor (Google). Por tanto hereda sus límites: no es transitivo (otras VPC unidas por peering a la tuya no llegan al servicio) y, para llegar desde on-premises, hay que exportar rutas personalizadas en el peering.
• Muchos de estos servicios ya admiten también PSC, que evita esas limitaciones.

Comparativa

DNS híbrido

En una red híbrida, las VMs deben resolver nombres de on-premises y los servidores de on-premises, nombres de la nube. Piezas de Cloud DNS:

• Zona de reenvío (forwarding zone, salida): «las consultas de corp.ejemplo.com que hagan las VMs mándalas a los DNS de on-premises 10.0.0.53». Cloud DNS las envía desde el rango 35.199.192.0/19, así que on-premises debe tener ruta de vuelta hacia ese rango (anúncialo por Cloud Router) y permitirlo en sus firewalls.
• Política de servidor de entrada (inbound server policy): crea puntos de entrada con IP internas en tus subredes; los DNS de on-premises reenvían a ellos las consultas de las zonas privadas de la nube (gcp.ejemplo.com).
• Política de servidor de salida (outbound server policy): sustituye el resolvedor de la VPC por servidores alternativos (menos habitual; normalmente basta con zonas de reenvío).
• Zonas de peering: en un hub-and-spoke, cada VPC spoke delega la resolución en la VPC hub, que es la que tiene las zonas de reenvío y la política de entrada. Así el DNS híbrido se configura una sola vez.

flowchart LR
  subgraph ONP["On-premises"]
    DNSON["DNS corporativo"]
  end
  subgraph HUB["VPC hub"]
    IN["Punto de entrada: inbound server policy"]
    FZ["Zona de reenvío corp.ejemplo.com"]
    PZ["Zona privada gcp.ejemplo.com"]
  end
  subgraph SPOKE["VPC spoke"]
    PEER["Zona de peering hacia el hub"]
  end
  DNSON -->|"consulta gcp.ejemplo.com"| IN
  IN --> PZ
  FZ -->|"consulta corp.ejemplo.com desde 35.199.192.0/19"| DNSON
  PEER --> HUB

Topologías de referencia

Hub-and-spoke

Una VPC hub concentra la conectividad compartida (Interconnect/VPN hacia on-premises, appliances de seguridad, DNS híbrido, salida a Internet) y las VPC spoke (por equipo o entorno) se conectan al hub. Formas de unir hub y spokes:

• NCC con VPC spokes y hybrid spokes (la forma gestionada y transitiva actual).
• VPC Network Peering (sencillo, pero los spokes no llegan a on-premises a través del hub salvo con exportación de rutas personalizadas y no se hablan entre sí).
• HA VPN entre hub y spokes (da transitividad por BGP, a cambio de coste y límites de ancho de banda).
• Appliances de red en el hub (NVA, network virtual appliances) con balanceador interno de paso como siguiente salto, si hace falta inspección centralizada con un producto de terceros.

Redes por entorno con Shared VPC

El patrón más habitual en empresas (y en el enterprise foundations blueprint de Google): un host project de Shared VPC por entorno (producción, no producción, desarrollo…), cada uno con su VPC, y los proyectos de aplicación como service projects. Ventajas: separación de entornos, control central de red y seguridad, facturación por equipo. Los entornos se conectan a on-premises por Interconnect (directamente o a través de un hub).

flowchart TB
  ONP["On-premises"] ---|"Dedicated Interconnect, 4 conexiones en 2 metrópolis"| HUB["VPC hub de conectividad"]
  HUB --- NCC["Network Connectivity Center"]
  NCC --- PROD["Shared VPC producción"]
  NCC --- NOPROD["Shared VPC no producción"]
  PROD --- A1["Service projects de producción"]
  NOPROD --- A2["Service projects de pruebas y desarrollo"]

Multicloud

Para comunicar Google Cloud con AWS, Azure u OCI: HA VPN (poco volumen) o Cross-Cloud Interconnect (mucho volumen, latencia estable), idealmente terminando en una VPC hub y distribuyendo con NCC. Google agrupa estas arquitecturas bajo el nombre Cross-Cloud Network en su Architecture Center. Planifica el direccionamiento de todas las nubes a la vez para evitar solapes (y, si no hay más remedio, usa PSC o Private NAT).

Proteger la topología

La guía del examen pide «protección de seguridad (prevención de intrusiones, control de acceso, firewalls)». Las piezas:

• Políticas de firewall jerárquicas (módulo 3): reglas obligatorias para toda la organización o carpeta, gestionadas por seguridad, que los proyectos no pueden saltarse (p. ej. denegar tráfico entre entornos, permitir solo rangos corporativos al SSH).
• Cloud NGFW Enterprise: añade servicio de prevención de intrusiones (IPS) basado en tecnología de Palo Alto Networks. Se despliegan firewall endpoints (recursos zonales a nivel de organización), se asocian a las VPC y, en las reglas de una política de firewall, se usa la acción apply_security_profile_group para enviar el tráfico a inspección con un perfil de seguridad (qué hacer según la severidad de la amenaza). Puede hacer inspección TLS. Coste orientativo (a 30/09/2026, precios de Cloud NGFW): unos 1,75 USD/h por endpoint más unos 0,02 USD por GiB inspeccionado.
• Cloud IDS (Cloud Intrusion Detection System): detección de intrusiones (no bloquea), también con tecnología de Palo Alto Networks. Recibe una copia del tráfico con Packet Mirroring hacia un endpoint gestionado (conectado por Private Service Access) y genera alertas. Coste orientativo: 1,50 USD/h por endpoint más 0,07 USD/GiB.
• Cloud Armor en los balanceadores externos (módulo 3).
• VPC Service Controls (lo verás en el módulo 7): perímetros alrededor de las APIs de Google para evitar exfiltración de datos; combinable con restricted.googleapis.com y PSC vpc-sc.
• Identity-Aware Proxy (IAP) para acceso administrativo sin IP públicas ni VPN de usuario.

Trampas típicas del examen

• HA VPN exige BGP (Cloud Router). Si el dispositivo on-premises solo soporta rutas estáticas, HA VPN no encaja (Classic VPN es heredado y con menor SLA).
• 99,99 % con HA VPN requiere los dos túneles (ambas interfaces). Con Interconnect, 4 conexiones en 2 metrópolis (Dedicated) y Cloud Routers en 2 regiones.
• Cloud Interconnect no cifra por defecto. Si piden cifrado: MACsec o HA VPN sobre Interconnect.
• Direct/Carrier Peering no llegan a tus VPC ni tienen SLA: son para Google Workspace y APIs públicas.
• Partner frente a Dedicated: «no estamos en un centro de colocación» o «menos de 10 Gbps» → Partner.
• Modo de enrutamiento regional: VMs de otras regiones no ven las rutas de la VPN. Solución: modo global.
• Peering no transitivo, sin solapes, no comparte firewall y no permite usar etiquetas del otro lado.
• Shared VPC requiere organización y separa funciones; un service project solo se adjunta a un host.
• PSA es peering por debajo: otras VPC unidas por peering no llegan a Cloud SQL con IP privada; on-premises necesita exportar rutas personalizadas.
• PSC es la respuesta cuando hay rangos solapados, organizaciones distintas o solo se quiere exponer un servicio.
• IDS detecta, NGFW Enterprise previene.
• DNS híbrido: permitir y anunciar 35.199.192.0/19 hacia on-premises; política de entrada para que on-premises resuelva zonas privadas.

Resumen

• Cloud Router es el plano de control BGP común a HA VPN e Interconnect; el modo de enrutamiento global propaga las rutas aprendidas a todas las regiones.
• HA VPN: IPsec por Internet, 99,99 %, BGP obligatorio, 1-3 Gbps por túnel, unos 0,05 USD/h por túnel.
• Dedicated Interconnect (10/100/400 Gbps en colocación), Partner Interconnect (50 Mbps-50 Gbps vía operador) y Cross-Cloud Interconnect (a AWS, Azure, OCI y Alibaba); no cifran por defecto.
• VPC Network Peering: rendimiento de red única, no transitivo, sin solapes, válido entre organizaciones.
• Shared VPC: host project con la red, service projects con las cargas; separación de funciones; requiere organización.
• Network Connectivity Center: hub-and-spoke gestionado y transitivo para VPC y conexiones híbridas.
• PGA (APIs de Google sin IP externa), PSC (endpoint con IP propia hacia APIs o servicios publicados, admite solapes) y PSA (peering con productores como Cloud SQL).
• DNS híbrido: zonas de reenvío, política de servidor de entrada y zonas de peering centralizadas en el hub.
• Protección: firewall jerárquico, Cloud NGFW Enterprise (IPS), Cloud IDS (detección), Cloud Armor y VPC Service Controls.

Practica lo aprendido

Documentación oficial para ampliar

• Choose a Network Connectivity product
• Cloud VPN overview
• Cloud Interconnect overview
• Cross-Cloud Interconnect overview
• Cloud Router overview
• VPC Network Peering
• Shared VPC
• Private Service Connect
• Private services access
• Network Connectivity Center overview
• DNS server policies
• Cloud NGFW intrusion prevention service