Google PCA: Redes, Conectividad Híbrida y Arquitectura de Tráfico — Guía de estudio

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

Forma parte de la Google Professional Cloud Architect — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Google, o realiza tests cronometrados en ExamRoll.io.

Información general

La arquitectura de red, la conectividad híbrida y el tráfico en Google Cloud giran en torno a un diseño de Virtual Private Cloud (VPC) seguro y escalable, interconexiones híbridas fiables, gestión inteligente del tráfico y observabilidad robusta. El objetivo es ofrecer servicios resilientes y de baja latencia con una segmentación clara, egreso controlado y modos de fallo predecibles. Esta sección describe patrones de diseño prácticos, contrapartidas y orientación operativa sobre los servicios de red principales de Google Cloud.

Arquitectura y segmentación de VPC

• Planificación de direcciones y subredes

  • Utilice VPC en modo personalizado para controlar la creación de subredes y el direccionamiento IP. Evite las VPC por defecto en producción.
  • Asigne bloques RFC1918 no superpuestos de forma temprana. Considere el crecimiento futuro, las topologías de alta disponibilidad y las extensiones híbridas. Reserve rangos para servicios (por ejemplo, endpoints de Private Service Connect) y para peering/Interconnect.
  • Prefiera subredes más pequeñas, por función o por entorno, en lugar de grandes redes planas para minimizar el radio de impacto de los fallos y simplificar las reglas de firewall.

• Rutas

  • Cada VPC tiene una tabla de rutas del sistema; las rutas se evalúan por la coincidencia de prefijo más largo y luego por prioridad. Las rutas gestionadas por Google incluyen la ruta a Internet por defecto si existen IP externas, y las rutas de subred. Las rutas dinámicas se intercambian con el entorno on-premises a través de Cloud Router.
  • Use rutas estáticas personalizadas con moderación; confíe en el enrutamiento dinámico siempre que sea posible para obtener resiliencia. Evite las rutas blackhole excepto como un control deliberado.

• Reglas de firewall

  • El firewall de la VPC es stateful y se evalúa por prioridad, con una denegación implícita al final. Apunte por etiquetas de red o cuentas de servicio; apuntar por cuentas de servicio ofrece garantías de identidad más fuertes que las etiquetas.
  • Separe las reglas de permiso (allow) por propósito (chequeos de salud, intratier, administración) y acótelas a las cuentas de servicio o rangos IP de origen.
  • Registre las decisiones del firewall para las reglas críticas en Cloud Logging para ayudar en el análisis forense y de rendimiento.

• Políticas de firewall jerárquicas y políticas de organización

  • Las políticas de firewall jerárquicas se aplican a nivel de organización o carpeta y se evalúan antes que las reglas a nivel de VPC. Úselas para establecer barreras de protección globales (por ejemplo, denegar SSH desde 0.0.0.0/0) que los proyectos no puedan anular. Las políticas pre y post proporcionan flexibilidad, pero las denegaciones en niveles superiores no pueden ser reemplazadas.
  • Complemente con restricciones de políticas de organización (Organization Policy) (por ejemplo, restringir la creación de IP externas, no permitir la creación de VPC peering por parte de los proyectos) para hacer cumplir la gobernanza.

• Shared VPC y segmentación

  • Use Shared VPC para centralizar la red en proyectos anfitriones (Host Projects) mientras aísla las cargas de trabajo en proyectos de servicio (Service Projects). Este patrón reduce las rutas de egreso duplicadas, estandariza los controles y simplifica el tránsito híbrido.
  • Aísle los entornos (prod, no-prod) en proyectos anfitriones o carpetas separadas; imponga la segmentación con políticas jerárquicas y subredes separadas. Restrinja IAM para que solo los equipos de NetOps gestionen los recursos del proyecto anfitrión.

• VPC Network Peering

  • El VPC Network Peering es privado, escalable y de baja latencia, pero no es transitivo. Es ideal para conectar redes autónomas o servicios gestionados por terceros. Evite construir hubs de tránsito con peering; utilice Network Connectivity Center para el tránsito o una Shared VPC centralizada.
  • Limitaciones: no se permiten IP superpuestas; ciertas rutas (por ejemplo, la ruta a Internet por defecto) y algunos servicios no se propagan. Comprenda la importación/exportación de rutas personalizadas al diseñar.

Contrapartidas y modos de fallo:

• Los rangos de IP superpuestos bloquean el peering y el intercambio de rutas híbridas; resuélvalo con una renumeración de direcciones o NAT.
• Las reglas de firewall excesivamente permisivas o la falta de reglas para chequeos de salud causan interrupciones y comportamientos difíciles de diagnosticar.
• Las rutas estáticas crean dependencias frágiles; prefiera Cloud Router para la conmutación por error (failover).

Gestión de tráfico, DNS y seguridad en el borde

• Patrones de Cloud Load Balancing

  • External HTTP(S) Load Balancer es global anycast con una única VIP anycast, conmutación por error entre regiones, enrutamiento por ruta y host, e integración con CDN/Armor. Úsalo para cargas de trabajo web y de API orientadas a Internet.
  • Internal HTTP(S) Load Balancer es regional, para tráfico de servicio a servicio dentro de una VPC o a través de Private Service Connect.
  • External/Internal TCP/UDP Network Load Balancer es regional de capa 4 (L4); úsalo para protocolos que no son HTTP o donde se requiera preservar la IP de origen.
  • Servicios de backend y Network Endpoint Groups (NEGs): usa backends de grupos de instancias zonales para pools de VM; usa NEGs zonales, regionales o sin servidor para GKE, backends híbridos o Cloud Run. Crea servicios de backend separados por clase de tráfico, perfil de estado o política de capacidad. Ejemplo: servir versiones antiguas y nuevas de una API bajo el mismo nombre de host mediante el enrutamiento por ruta a servicios de backend distintos, manteniendo ambos desplegables y escalables de forma independiente.

• Comprobaciones de estado y errores comunes

  • Las comprobaciones de estado deben ser permitidas por el firewall. Para las comprobaciones de estado de HTTP(S) externos, permite el acceso de 130.211.0.0/22 y 35.191.0.0/16 a los backends. La falta de una regla hace que los backends se marquen como no saludables y provoca reinicios rápidos de las VM si el autoescalado reacciona a las señales del balanceador de carga.
  • Alinea las rutas y puertos de las comprobaciones de estado con los endpoints de preparación (readiness) de los contenedores; establece tiempos de espera y umbrales para equilibrar una conmutación por error rápida frente a los falsos positivos.

• Arquitectura de DNS

  • Usa Cloud DNS para zonas autoritativas. Crea zonas privadas para nombres internos; crea zonas públicas para nombres de Internet.
  • DNS de horizonte dividido (split-horizon): sirve respuestas diferentes interna y externamente creando zonas públicas y privadas separadas con nombres idénticos. Esto permite gestionar de forma segura nombres de host de servicios privados y registros de cara al público.
  • Zonas de reenvío y emparejamiento (peering): intégrate con el DNS local (on-premises) usando políticas de DNS y políticas de servidor para reenviar consultas de dominios específicos; usa el reenvío condicional para evitar bucles de recursión.
  • Descubrimiento de servicios (service discovery): adopta convenciones de nomenclatura coherentes por entorno y servicio. Para GKE, considera usar servicios headless con Cloud DNS, o mapear los endpoints de servicio a través de un Internal HTTP(S) Load Balancer y nombres DNS privados.

• Caché y protección en el borde

  • Cloud CDN descarga el contenido almacenable en caché en el borde, reduciendo la latencia del origen y el costo de egreso. Configura cuidadosamente las claves de caché, los TTL y el almacenamiento en caché negativo; omite la caché para endpoints personalizados o dinámicos.
  • Cloud Armor proporciona WAF, limitación de velocidad (rate limiting) y control de acceso basado en geolocalización/IP. Asocia políticas de seguridad a los balanceadores de carga; supervisa los registros de aciertos de las reglas. Usa reglas preconfiguradas para CVE comunes y firmas personalizadas para amenazas específicas de la aplicación.
  • La terminación TLS en el balanceador de carga centraliza la gestión de certificados; habilita el aprovisionamiento automático de certificados y las renovaciones gestionadas siempre que sea posible.

Guía operativa:

• APIs versionadas: implementa enrutamiento basado en ruta o en host hacia servicios de backend separados para que cada versión se despliegue de forma independiente con patrones blue-green o canary.
• Usa encabezados de solicitud y cookies para pruebas A/B mediante políticas de dirección de tráfico; valida siempre que los registros y las métricas se correlacionen con la identidad correcta del backend.

Conectividad híbrida, acceso privado y tránsito

• Cloud Router y BGP

  • Cloud Router intercambia rutas dinámicamente con el entorno local (on-premises) a través de BGP para túneles de Cloud VPN y adjuntos de Interconnect. Use el modo de enrutamiento dinámico global en la VPC cuando se requiera conectividad entre radios (spokes) multirregionales.
  • Anuncie solo los prefijos necesarios; filtre para evitar fugas de rutas. Comprenda las interacciones de MED y prioridad al diseñar rutas primarias/de respaldo.

• Cloud VPN, Dedicated Interconnect y Partner Interconnect

  • HA VPN proporciona túneles redundantes con respaldo de SLA sobre IPsec, admite enrutamiento dinámico a través de Cloud Router y es adecuado para entornos híbridos de producción con necesidades moderadas de ancho de banda.
  • Dedicated Interconnect proporciona enlaces físicos de 10/100 Gbps en una o más ubicaciones; Partner Interconnect ofrece algo similar a través de un proveedor de servicios. Use al menos dos interconexiones diversas en ubicaciones metropolitanas distintas o zonas de borde separadas para alta disponibilidad.
  • Rutas redundantes y conmutación por error (failover): diseñe en modo activo/activo con BGP a través de dos Cloud Routers por región y dos routers locales (on-prem); valide la tolerancia al enrutamiento asimétrico. Pruebe la conmutación por error regularmente; ajuste los temporizadores de BFD y los umbrales de estado para la convergencia deseada.
  • Modos de fallo: un desajuste de MTU causa fragmentación y penalizaciones de rendimiento; asegure el uso de tramas jumbo (jumbo frames) de extremo a extremo para Interconnect. Filtros de ruta mal configurados pueden crear agujeros negros (blackhole) para subredes. Los circuitos de partner con una sola conexión (single-homed) son un punto único de fallo común.

• Cloud NAT, Private Google Access y Private Service Connect

  • Cloud NAT habilita el egreso a internet para VMs privadas sin IPs externas. Dimensione las IPs de NAT y las asignaciones de puertos para las conexiones pico para evitar el agotamiento de puertos; habilite el registro (logging) para la solución de problemas.
  • Private Google Access permite que las VMs privadas accedan a las APIs de Google usando IPs internas; habilítelo en las subredes para el acceso de VMs y en los nodos de GKE para el acceso a APIs desde el nodo local. Para clientes locales (on-prem), use Private Service Connect para APIs de Google para exponer VIPs privadas que actúan como frontend para las APIs de Google.
  • Private Service Connect para servicios de productor/consumidor proporciona puntos de conexión (endpoints) de IP internos y privados para la publicación de servicios entre proyectos u organizaciones; combínelo con DNS privado para dirigir el tráfico sin exponer las redes.

• Network Connectivity Center (NCC) y tránsito

  • NCC permite topologías de tipo hub-and-spoke donde los radios (spokes) son VPCs, túneles de HA VPN o adjuntos de Interconnect. Use un hub central para simplificar la distribución de rutas y el tránsito entre múltiples VPCs, especialmente entre proyectos u organizaciones.
  • Prefiera Shared VPC para el tránsito dentro de la organización cuando la gobernanza lo permita; use NCC cuando necesite tránsito flexible y multidominio o integración con SD-WAN.
  • Comprenda que VPC Peering no es transitivo; no dependa de él para el tránsito. NCC o una VPC centralizada con un firewall/balanceador de carga forma el núcleo de tránsito.

Decisiones multirregionales, latencia y costos de egreso:

• Ubique la computación cerca de los usuarios y de los backends con estado (stateful) para minimizar el RTT. External HTTP(S) Load Balancing proporciona ingreso global con enrutamiento inteligente, pero la latencia de replicación de la base de datos y la consistencia siguen siendo restricciones de la aplicación.
• El tráfico entre zonas incurre en costos dentro de una región; la replicación entre regiones añade cargos de egreso y latencia. Use Cloud CDN para reducir el egreso a internet y la carga en el origen, y mantenga los servicios con mucha comunicación (chatty) coubicados.
• Para la recuperación ante desastres, sopese un standby pasivo (warm standby) en otra región frente a los costos de egreso y la complejidad operativa. Use el balanceo de carga global con políticas de conmutación por error (failover) y verificaciones de estado (health checks) que abarquen regiones solo cuando el plano de datos y el plano de control puedan tolerar el aislamiento regional.

Observabilidad, operaciones de confiabilidad y controles

• Observabilidad de la red

  • VPC Flow Logs: habilítalos a nivel de subred y ajusta las opciones de muestreo y metadatos. Úsalos para establecer bases de referencia de tráfico, análisis de egreso y búsqueda de amenazas. Expórtalos a BigQuery para análisis a largo plazo.
  • Registro de reglas de firewall: habilítalo en reglas críticas para capturar el tráfico permitido y denegado; correlaciónalo con los registros de flujo para detectar configuraciones incorrectas.
  • Connectivity Tests: modela rutas de origen-destino para validar la alcanzabilidad, la selección de rutas y la evaluación del firewall. Intégralo en CI/CD para detectar desviaciones antes del despliegue.
  • Paneles de estado: monitorea el estado de los backends del balanceador de carga, la utilización de puertos de Cloud NAT, el estado de la sesión BGP de Cloud Router y la utilización de Interconnect. Alerta sobre desviaciones.

• Patrones de confiabilidad y modos de falla comunes

  • Resiliencia zonal: distribuye los backends en al menos dos zonas; utiliza grupos de instancias administrados o grupos de nodos de GKE multizonales. Valida que las verificaciones de estado y las etiquetas de firewall se apliquen a todas las zonas.
  • Resiliencia de enrutamiento: utiliza enrutamiento dinámico global y múltiples Cloud Routers para conectividad que abarque varias regiones. Prueba escenarios de agujero negro (blackhole) y asegúrate de que el monitoreo cubra la retirada de rutas.
  • Resiliencia de DNS: despliega múltiples servidores de nombres por defecto con Cloud DNS; para entornos híbridos, asegúrate de que los reenviadores (forwarders) sean redundantes y evita puntos únicos de falla en los resolutores locales (on-prem). Previene configuraciones incorrectas de horizonte dividido (split-horizon) que devuelvan respuestas no enrutables desde el lado equivocado.
  • Seguridad en el borde: aplica límites de tasa (rate limits) de Cloud Armor para proteger el origen de inundaciones de tráfico; no hacerlo puede desencadenar tormentas de autoescalado y picos de costos.

• Controles de costos

  • Minimiza las llamadas entre regiones, prefiere el balanceo de carga interno para el tráfico dentro de la VPC y considera PSC para el tráfico productor-consumidor para evitar el egreso por NAT.
  • Usa Cloud CDN para activos estáticos y semiestáticos; ajusta la capacidad de almacenamiento en caché. Dimensiona la capacidad de Interconnect para evitar pagar de más por capacidad ociosa; utiliza los datos de tráfico para dimensionar correctamente los compromisos.

Fragmentos operativos:

• Permitir verificaciones de estado del balanceador de carga a backends privados:

undefined

• Habilitar Private Google Access en una subred:

undefined

• Crear un Cloud Router para HA VPN:

undefined

Escenario de problema práctico

Contoso Retail planea lanzar una API de comercio electrónico global con versionado sin tiempo de inactividad, conectividad privada estricta a los sistemas de back-office y sin IPs públicas en las VMs de la aplicación. La solución debe proporcionar protección DDoS, caché en el borde y acceso híbrido confiable desde dos centros de datos.

Enfoque:

1. Diseñar la VPC y la segmentación

• Crear un proyecto anfitrión (Host Project) de Shared VPC en modo personalizado con subredes dedicadas por nivel (web, api, datos) en dos regiones. Justificación: Shared VPC centraliza los controles mientras que los proyectos de servicio aíslan a los equipos. Las subredes por nivel permiten un firewall de privilegios mínimos y dominios de falla más pequeños.
• Aplicar políticas de firewall jerárquicas a nivel de organización para denegar SSH entrante desde internet y restringir el egreso a destinos permitidos. Justificación: Las barreras de protección (guardrails) globales reducen el riesgo de configuraciones incorrectas en los proyectos.

2. Implementar el ingreso global basado en rutas y el versionado de la API

• Desplegar un External HTTP(S) Load Balancer con una única IP anycast y terminación HTTPS. Configurar mapas de URL para enrutar /v1/* y /v2/* a servicios de backend separados respaldados por NEGs zonales regionales. Justificación: Los servicios de backend distintos permiten el despliegue y la reversión independientes para cada versión de la API bajo un único nombre de host y TLS.
• Asociar Cloud Armor WAF y límites de tasa; habilitar Cloud CDN para los puntos de conexión que se pueden almacenar en caché (por ejemplo, imágenes de productos). Justificación: Protege el origen y reduce la latencia y los costos de egreso.

3. Asegurar la alcanzabilidad y el estado de los backends

• Crear una regla de firewall para permitir las verificaciones de estado del balanceador de carga a los grupos de instancias de la API en los puertos esperados. Justificación: Sin esto, las verificaciones de estado fallan y los autoescaladores pueden funcionar de manera errática (thrash) al considerar que las instancias no están en buen estado.
• Distribuir las instancias en dos zonas por región; establecer umbrales de verificación de estado de forma conservadora para evitar el ‘flapping’ (cambios de estado rápidos). Justificación: La diversidad zonal y las políticas de estado estables mejoran la disponibilidad.

4. Construir el DNS con horizonte dividido y descubrimiento de servicios

• Crear una zona pública de Cloud DNS para contoso.com y una zona privada con el mismo nombre para registros solo internos (por ejemplo, db.internal.contoso.com). Justificación: El horizonte dividido (split-horizon) evita que los nombres internos se filtren al exterior, manteniendo al mismo tiempo una nomenclatura coherente.
• Configurar políticas de DNS para reenviar las consultas locales (on-premises) de corp.local al DNS corporativo e importar zonas privadas en los proyectos de aplicación. Justificación: Resolución fluida a través de los límites híbridos sin bucles de recursión.

5. Establecer conectividad híbrida con redundancia

• En cada región, aprovisionar dos túneles HA VPN a cada centro de datos, cada par en Cloud Routers separados con BGP. Si la capacidad y las necesidades de SLA lo justifican, agregar Partner Interconnect con adjuntos redundantes en zonas de borde separadas. Justificación: Múltiples rutas diversas proporcionan conmutación por error (failover); BGP permite una convergencia rápida y un intercambio dinámico de rutas.
• Usar enrutamiento dinámico global en la Shared VPC y aplicar filtros de ruta para evitar que se propaguen prefijos locales (on-premises) no deseados. Justificación: Enrutamiento coherente entre regiones mientras se reduce el riesgo de fugas de rutas.

6. Proporcionar acceso privado a las APIs de Google e internet saliente

• Habilitar Private Google Access en las subredes de la aplicación y configurar puntos de conexión de Private Service Connect para las APIs de Google utilizadas por los trabajos por lotes (batch jobs). Usar Cloud NAT para el egreso saliente que no sea de API cuando sea necesario. Justificación: Los backends no tienen IPs públicas pero aun así pueden alcanzar los servicios necesarios; PSC simplifica la resolución de nombres con DNS privado.

7. Centralizar el tránsito y la conectividad con terceros

• Crear un hub de Network Connectivity Center en el proyecto anfitrión (Host Project); adjuntar los HA VPNs, los adjuntos de Interconnect y cualquier spoke de SD-WAN. Justificación: El tránsito en modo hub-and-spoke simplifica la distribución de rutas entre múltiples VPCs y redes externas en comparación con las mallas de peering.

8. Implementar observabilidad y barreras de protección (guardrails)

• Habilitar VPC Flow Logs en todas las subredes con un muestreo adecuado; habilitar los registros de firewall en reglas críticas; exportar a BigQuery. Usar Connectivity Tests en CI/CD antes de promover nuevos cambios de firewall o rutas. Justificación: La visibilidad profunda apoya la resolución de problemas, la planificación de capacidad y la auditabilidad.
• Establecer alertas para caídas de sesión BGP de Cloud Router, agotamiento de puertos de Cloud NAT, caídas en el estado de los backends y activaciones de reglas de Cloud Armor. Justificación: La detección temprana de fallas y ataques reduce el MTTR (Tiempo Medio de Recuperación).

9. Optimizar para rendimiento y costo

• Coubicar los servicios con estado (stateful) con la computación en la misma región; almacenar en caché el contenido estático en el borde con Cloud CDN. Justificación: Minimiza el RTT (Tiempo de Ida y Vuelta) y el egreso entre regiones.
• Revisar periódicamente los registros de flujo para identificar la comunicación excesiva entre zonas (‘cross-zone chatter’) y ajustar la ubicación o los límites del servicio. Justificación: Reduce el egreso innecesario y la latencia.

Este diseño ofrece un ingreso global y seguro con enrutamiento versionado, conectividad híbrida resiliente con conmutación por error dinámica, acceso privado a los servicios requeridos y observabilidad integral, mientras controla la latencia y los costos de egreso.

← Almacenamiento de Datos · Todos los dominios · Seguridad →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Explorar Google →