Google ACE: Redes de VPC, conectividad y gestión de tráfico — Guía de estudio

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

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

Descripción general

La red de Virtual Private Cloud (VPC) en Google Cloud proporciona primitivas de red globales definidas por software con control granular sobre el direccionamiento, enrutamiento, seguridad y gestión del tráfico. Esta sección se centra en temas prácticos de diseño y operaciones que utilizará para construir redes resilientes, seguras y observables que interconectan los servicios de Google Cloud, los entornos on-premise y la internet pública.

Arquitectura Central de VPC y Planificación de IP

• Redes VPC y subredes

  • Una VPC es un recurso global; sus subredes son regionales y pueden abarcar zonas. Las instancias en cualquier zona de la región pueden usar una subred.
  • Utilice VPC en modo personalizado para producción. El modo automático precrea una subred por región utilizando un conjunto predefinido de rangos CIDR y puede llevar a restricciones de IP superpuestas, desperdicio de espacio de direcciones y dolorosas refactorizaciones cuando se expanda.
  • Los rangos de IP secundarios en las subredes habilitan las IP de Pods/Servicios de GKE y las IP de alias para las VM. Planifique los CIDR primarios y secundarios por adelantado para evitar la renumeración.

• Planificación de direcciones IP

  • Elija un espacio RFC1918 no superpuesto para todas las VPC presentes y futuras y las redes on-premise que pueda conectar. Reserve bloques de crecimiento para futuras regiones y servicios.
  • Dimensione correctamente las subredes (p. ej., de /24 a /20) para el crecimiento y evite rangos demasiado grandes que complican las ACL y los diagnósticos.
  • Documente el uso de IP: rangos primarios para cargas de trabajo, rangos secundarios para GKE y bloques reservados para pools de NAT o puntos de conexión de servicios.

• Ejemplo

  • gcloud compute networks create prod-net –subnet-mode=custom
  • gcloud compute networks subnets create app-us-central1 –network=prod-net –region=us-central1 –range=10.10.0.0/20 –secondary-range=gke-pods=10.20.0.0/16,gke-svcs=10.21.0.0/20

Enrutamiento, Firewalls y Jerarquía de Políticas

• Rutas y modos de enrutamiento dinámico

  • Cada VPC tiene una tabla de enrutamiento compuesta por rutas de subred generadas por el sistema, rutas predeterminadas y rutas personalizadas estáticas o dinámicas.
  • Modo de enrutamiento dinámico:
    • Regional: las rutas dinámicas (BGP) aprendidas a través de Cloud Router solo pueden ser utilizadas por recursos en la misma región.
    • Global: las rutas dinámicas pueden ser utilizadas por recursos en todas las regiones de la VPC. Prefiera el modo global para redes híbridas que deben alcanzar el entorno on-premise desde múltiples regiones.
  • Siguientes saltos (Next hops): puerta de enlace de internet predeterminada (0.0.0.0/0), túnel VPN, Cloud Router (BGP), instancia (dispositivo de enrutamiento) o un balanceador de carga interno como siguiente salto para dispositivos virtuales.
  • Prioridad de ruta: se prefieren los números más bajos. Las prioridades mal configuradas pueden descartar tráfico (blackhole) o filtrarlo a un siguiente salto no deseado. Utilice convenciones claras (p. ej., 1000 para la salida predeterminada, 900 para rutas más específicas).

• Jerarquía de firewall

  • Las reglas de firewall de VPC tienen estado (stateful) y se evalúan antes del reenvío de paquetes. Existen a nivel de VPC y se aplican a todas las subredes.
  • Las políticas de firewall jerárquicas (adjuntas a la organización, carpeta o proyecto) aplican permisos/denegaciones antes que las reglas de VPC. Úselas para implementar barreras de protección centrales (guardrails) (p. ej., denegar puertos de administración expuestos a internet).
  • Reglas implícitas: existen una regla implícita de permitir egreso y una de denegar ingreso con la prioridad más baja; no se pueden eliminar. Toda la conectividad requiere reglas explícitas de permiso de ingreso.

• Reglas de firewall, etiquetas, cuentas de servicio y etiquetas seguras

  • Orientación (Targeting): utilice etiquetas de red o cuentas de servicio para aplicar reglas a VM específicas; la orientación por cuenta de servicio ofrece un control más estricto basado en la identidad.
  • Las etiquetas seguras (Secure tags) proporcionan etiquetas gestionadas de forma centralizada y protegidas por IAM para la orientación de políticas; evitan la autoasignación por parte de las cargas de trabajo y soportan la segmentación de confianza cero (zero-trust).
  • Registro (Logging): habilite el registro de firewall de forma selectiva para reglas de alto valor para equilibrar la visibilidad con el costo; muestree paquetes, no las cargas útiles completas.
  • Modos de fallo comunes: falta de los rangos de origen de las comprobaciones de estado (health checks), enrutamiento asimétrico que provoca la caída de respuestas, rangos de origen demasiado amplios que crean una exposición no deseada.

• Ejemplo

  • gcloud compute firewall-rules create allow-ilb-hc –network=prod-net –direction=INGRESS –action=ALLOW –priority=1000 –rules=tcp:80 –source-ranges=load-balancer-health-checks –target-service-accounts=web-sa@proj.iam.gserviceaccount.com

Balanceo de carga, direcciones IP, DNS y gestión de tráfico

• Tipos y comportamiento de Cloud Load Balancing

  • Basados en proxy global: HTTP(S) Externo, Proxy TCP Externo, Proxy SSL Externo. Terminan las conexiones de los clientes en el borde de la red de Google, admiten VIP globales anycast e insertan encabezados (p. ej., X-Forwarded-For). La IP original del cliente está disponible a través de encabezados o del protocolo PROXY (para TCP) en lugar de preservarse como origen L3.
  • De paso (passthrough) regional: External Network Load Balancer e Internal TCP/UDP Load Balancer enrutan el tráfico en L4 y preservan la IP del cliente. Úsalos cuando requieras visibilidad de la IP de origen en los backends sin el protocolo PROXY.
  • Internal HTTP(S) Load Balancer: proxy L7 regional para servicios internos con enrutamiento avanzado y opciones de mTLS.

• Servicios de backend, verificaciones de estado y políticas de tráfico

  • Los servicios de backend definen los backends (grupos de instancias, NEG/VM/Endpoint, servicios de GKE), el modo de balanceo (UTILIZATION o RATE), los límites de capacidad, la afinidad de sesión y el drenaje de conexiones.
  • Las verificaciones de estado deben permitirse a través de los firewalls desde los verificadores de estado de Google. Los backends en mal estado se eliminan automáticamente; verificaciones de estado mal configuradas pueden causar una interrupción total.
  • Las políticas de tráfico incluyen la localidad (región/zona), backends de desbordamiento y conmutación por error (failover), y división de tráfico ponderada para despliegues graduales en algunos tipos de balanceadores de carga.

• Direcciones IP externas e internas, reglas de reenvío

  • Las direcciones externas e internas pueden ser efímeras o estáticas reservadas. Las direcciones externas estáticas globales son utilizadas por los balanceadores de carga globales; la mayoría de las demás son regionales.
  • Las reglas de reenvío mapean una IP:puerto a un destino (p. ej., targetHttpProxy o servicio de backend). Elige reglas globales o regionales que coincidan con el tipo de balanceador de carga; una falta de coincidencia impide la creación.

• Cloud DNS

  • Zonas: las zonas públicas se resuelven en la internet pública; las zonas privadas solo se pueden resolver desde VPC autorizadas. Utiliza registros administrados (A/AAAA, CNAME, TXT, MX, SRV, etc.).
  • DNS de horizonte dividido (Split-horizon): crea zonas públicas y privadas para el mismo dominio para que los resolutores internos reciban respuestas privadas (p. ej., la IP de un ILB) mientras que los usuarios públicos obtienen IP de cara a internet.
  • Reenvío de DNS privado: usa políticas de Cloud DNS para el reenvío de entrada y de salida para integrarse con resolutores on-premise; usa el peering de DNS entre VPC para compartir zonas privadas sin conectividad de peering completa.

• Ejemplo

undefined

Conectividad híbrida y privada

• Cloud Router, Cloud NAT y Private Google Access

  • Cloud Router intercambia rutas con el entorno on-premise a través de BGP, anuncia las subredes de la VPC e importa los prefijos on-premise. Usa el enrutamiento dinámico global cuando varias regiones necesiten alcanzabilidad hacia el entorno on-premise.
  • Cloud NAT proporciona salida (egress) a internet para VM privadas y nodos de GKE sin direcciones IP externas. Dimensiona los grupos de IP de NAT para evitar el agotamiento de puertos; supervisa los registros en busca de conexiones caídas y escala las direcciones según sea necesario.
  • Private Google Access (PGA) permite que las VM privadas alcancen las API de Google sin direcciones IP externas a través de la ruta de enrutamiento predeterminada. Private Service Connect (PSC) para las API de Google proporciona puntos de conexión (endpoints) con IP privadas en tu VPC con control de políticas y evita por completo la salida pública; prefiere los endpoints de PSC para un control de salida más estricto y un DNS consistente.

• Private Service Connect (servicios productores y consumidores)

  • Expón servicios internos detrás de un adjunto de servicio (service attachment) en un proyecto productor y consúmelos a través de puntos de conexión privados en proyectos consumidores. El mapeo de DNS y las políticas de permiso explícitas controlan el acceso. Esto mejora el aislamiento en comparación con VPC Peering y centraliza la publicación de servicios.

• VPC Network Peering, VPC compartida y segmentación

  • VPC Peering ofrece conectividad privada entre VPC con baja latencia. No es transitivo y no permite IP superpuestas. La importación/exportación opcional de rutas personalizadas amplía la alcanzabilidad, pero aun así no crea enrutamiento transitivo; planifica el modelo hub-and-spoke de forma deliberada.
  • La VPC compartida centraliza las subredes en un proyecto anfitrión (host) para que las usen los proyectos de servicio. Esto permite centralizar el enrutamiento, los firewalls, NAT y los balanceadores de carga, mientras se delega el IAM por aplicación. Combínalo con firewalls jerárquicos y etiquetas seguras para la segmentación.
  • Network Connectivity Center (NCC) proporciona un hub para orquestar los radios (spokes) (VPN, Interconnect, dispositivo de router, radios de VPC) y gestionar topologías WAN empresariales de forma consistente.

• Cloud VPN, Cloud Interconnect y BGP

  • Cloud VPN: usa HA VPN con enrutamiento dinámico (BGP) para obtener disponibilidad y conmutación por error automática de rutas. Construye dos túneles por par (peer) a través de interfaces de Cloud VPN independientes y dispositivos/enlaces on-premise distintos cuando sea posible.
  • Cloud Interconnect: Dedicated Interconnect proporciona enlaces privados de 10–100 Gbps; Partner Interconnect utiliza un proveedor de servicios. Para la resiliencia, despliega interconexiones redundantes en dominios de disponibilidad de borde (edge) diversos y usa BFD con BGP donde sea compatible.
  • Dominios de fallo: aísla por región, zona, dispositivo y proveedor. Prueba la conmutación por error (failover) regularmente; las rutas asimétricas pueden romper los firewalls con estado (stateful) on-premise.

• Ejemplos

undefined

undefined

undefined

Observabilidad y resolución de problemas

• Connectivity Tests
  • Simulan y verifican la alcanzabilidad entre orígenes y destinos a través de VPCs, on-premise (a través de enlaces híbridos) y balanceadores de carga. La herramienta evalúa rutas, reglas de firewall y configuración para localizar caídas o tráfico mal enrutado antes de los cambios en producción.
  • Ejemplo:

undefined

• VPC Flow Logs

  • Habilitar a nivel de subred para obtener información en tiempo real sobre flujos de 5 tuplas, bytes, caídas y latencia. Exportar a Cloud Logging, Pub/Sub o BigQuery para análisis. Ajustar los niveles de muestreo y metadatos para controlar el costo.
  • Casos de uso: validar la efectividad del firewall, detectar la exfiltración, planificación de capacidad y monitoreo de SLO.

• Packet Mirroring

  • Replicar el tráfico de VM o GKE a puntos finales de recolección para inspección profunda de paquetes o IDS. Limitar el alcance de la replicación por subred, etiqueta o instancia. Comprender la sobrecarga de rendimiento y asegurarse de que los recolectores puedan manejar el volumen replicado. Evitar replicar el tráfico post-NAT cuando se necesiten las cabeceras originales.

• Patrones comunes de diagnóstico

  • Agujero negro (Blackhole): la ruta existe pero la ruta de respuesta está bloqueada por un firewall o enrutamiento asimétrico; validar con Connectivity Tests y flow logs en ambos lados.
  • Fallas en la verificación de estado (health check): confirmar que el firewall permite el tráfico desde los verificadores de estado y que los backends escuchan en los puertos correctos; probar localmente desde una VM en la misma subred.
  • Agotamiento de NAT: buscar flujos denegados con el motivo “no available NAT ports”; agregar más IPs de NAT o reducir los límites de puertos por VM.

Escenario de problema práctico

Acme Retail opera una plataforma de comercio electrónico multirregional con backends privados, una entrada web pública y un ERP on-premise. Deben segmentar las cargas de trabajo, proporcionar egreso privado a las APIs de Google, habilitar la alcanzabilidad híbrida desde todas las regiones y reforzar la seguridad manteniendo la observabilidad.

1. Crear una Shared VPC en modo personalizado para un control centralizado

undefined

• Justificación: El modo personalizado evita los CIDR asignados automáticamente y permite una planificación deliberada de IPs. Shared VPC centraliza el enrutamiento, los firewalls y el NAT en un proyecto anfitrión (host project) mientras permite que los proyectos de servicio (service projects) se desplieguen de forma segura.

2. Planificar y crear subredes con rangos secundarios para GKE

undefined

• Justificación: Los rangos primarios y secundarios no superpuestos evitan futuros conflictos de peering y permiten el uso de IPs de alias para GKE sin agotar las IPs.

3. Establecer el enrutamiento dinámico de la VPC a global y desplegar Cloud Router

undefined

undefined

• Justificación: El modo global hace que las rutas on-premise aprendidas por BGP sean utilizables desde todas las regiones, simplificando la alcanzabilidad híbrida y la conmutación por error (failover).

4. Establecer una HA VPN hacia on-premise y anunciar las subredes

• Crear dos túneles HA VPN a través de dispositivos on-premise diversos. Usar BGP para intercambiar prefijos y permitir una conmutación por error controlada (graceful failover).
• Justificación: Los túneles dobles eliminan los puntos únicos de fallo; BGP hace converger las rutas rápidamente durante el mantenimiento o las interrupciones.

5. Desplegar Cloud NAT para el egreso privado y PSC para las APIs de Google

undefined

• Crear puntos finales de Private Service Connect para las APIs de Google y actualizar el DNS privado para mapear los puntos finales de las API a PSC.
• Justificación: NAT permite el egreso a Internet sin IPs externas en las VM; PSC mantiene el tráfico de las API en IPs privadas y bajo un control de políticas explícito, eliminando las rutas de egreso públicas.

6. Frontend con un External HTTP(S) Load Balancer global; servicios internos a través de Internal HTTP(S)

• Crear un LB externo global HTTP(S) con un certificado gestionado y un servicio de backend que apunte a backends NEG.
• Crear LBs internos regionales HTTP(S) para el tráfico de servicio a servicio con mTLS entre microservicios.
• Justificación: El LB proxy global proporciona anycast, autoescalado y CDN; el LB L7 interno ofrece enrutamiento enriquecido y seguridad para el tráfico este-oeste.

7. Implementar políticas de firewall jerárquicas y segmentación por identidad de carga de trabajo

• Asociar una política a nivel de organización que deniegue los puertos de administración desde Internet; permitir solo los orígenes de las verificaciones de estado del LB.
• Crear reglas de VPC dirigidas a cuentas de servicio para un acceso de mínimo privilegio entre capas; usar etiquetas seguras (secure tags) para la segmentación dinámica.
• Justificación: La jerarquía impone barreras de protección (guardrails) de forma centralizada; la segmentación basada en identidad resiste la suplantación de etiquetas (tag spoofing) y simplifica la automatización.

8. Configurar Cloud DNS con horizonte dividido (split-horizon) y reenvío (forwarding)

• Crear una zona pública acme.com para la VIP web, y una zona privada acme.com para los nombres de servicios internos que se mapean a los ILBs.
• Configurar el reenvío de salida (outbound) al DNS on-premise y el de entrada (inbound) para que on-premise pueda resolver las zonas privadas.
• Justificación: El horizonte dividido previene la fuga de datos y asegura la resolución de nombres correcta según la red de origen; el reenvío integra los espacios de nombres heredados (legacy).

9. Usar Connectivity Tests, flow logs y packet mirroring para la visibilidad

• Crear pruebas para las rutas críticas (usuario al LB web, web a servicios internos, servicios al ERP on-premise).
• Habilitar flow logs en las subredes; exportar a BigQuery para el análisis de tendencias. Habilitar packet mirroring temporalmente durante la respuesta a incidentes.
• Justificación: La validación proactiva y la telemetría acortan el MTTR, revelan configuraciones incorrectas y proporcionan información sobre la capacidad.

10. Documentar y probar escenarios de fallo

• Simular la pérdida de un túnel VPN, una región y un MIG de backend. Verificar la conmutación por error de BGP, la eliminación por parte de la verificación de estado del LB y la correctitud del DNS.
• Justificación: Los ‘game days’ regulares confirman las suposiciones sobre la redundancia y exponen la deriva de la configuración (configuration drift) antes de que cause interrupciones.

← Contenedores · Todos los dominios · Almacenamiento →

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

Explorar Google →