Google PCNE: Arquitectura de VPC, subredes y planificación de direcciones — Guía de estudio

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Forma parte de la Google Professional Cloud Network 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

Una Nube Privada Virtual (VPC) es una red global y lógicamente aislada que se extiende por todas las regiones de Google Cloud. Las subredes son constructos regionales dentro de una VPC y alojan los rangos de IP que respaldan a Compute Engine, GKE y otros recursos. Una arquitectura de VPC sólida equilibra la eficiencia de las direcciones, el crecimiento y el control operativo, al tiempo que garantiza una conectividad de baja latencia y rentable para las cargas de trabajo dentro y entre proyectos, y hacia las API de Google.

Alcance de la VPC, arquitectura de subredes y modos

• VPC global, subredes regionales

  • Una única VPC se extiende por todas las regiones. Las subredes se crean por región y definen los CIDR IPv4 primarios y rangos secundarios opcionales. Las instancias reciben IP de las subredes regionales, pero pueden comunicarse de forma privada entre regiones dentro de la misma VPC por defecto.
  • Modo de enrutamiento dinámico
    • Regional: Los Cloud Routers intercambian rutas solo con las subredes de su región.
    • Global: Los Cloud Routers de una región anuncian las rutas aprendidas a todas las regiones. Prefiera el modo global cuando se requieran cargas de trabajo multirregionales o una salida de alta disponibilidad (HA).

• Modo automático vs. modo personalizado

  • El modo automático crea una subred por región con CIDR preasignados. Es conveniente para inicios rápidos, pero inflexible a gran escala. Se puede convertir a modo personalizado; la conversión es unidireccional.
  • El modo personalizado proporciona control total sobre la creación de subredes y la elección de CIDR. Este es el patrón recomendado para la planificación de direcciones en producción, Shared VPC, peering y crecimiento.
  • Nota de migración: Después de convertir de modo automático a personalizado, los artefactos o plantillas que asumían la existencia de subredes automáticas suelen fallar hasta que se actualizan explícitamente para hacer referencia a las subredes personalizadas.

• Inmutabilidad y crecimiento de la subred

  • La región de una subred es inmutable; no se puede mover una subred entre regiones.
  • Los rangos IPv4 primarios se pueden expandir en el sitio (ampliando el prefijo), no se pueden reducir y no deben superponerse con otros rangos en la VPC ni en ninguna red conectada.
  • Los rangos secundarios se pueden agregar o eliminar (sujeto a su uso), pero tampoco deben superponerse.

Planificación de direcciones: rangos primarios/secundarios, IP de alias, IPv6 y espacio privado

• Rangos IPv4 primarios y secundarios

  • Rango primario: asigna direcciones a las interfaces de las VM (nic0 por defecto). Crea una ruta de subred generada por el sistema y se utiliza para la mayoría de la comunicación interna.
  • Rangos secundarios: asocian CIDR adicionales con la subred y son necesarios para los clústeres de GKE nativos de la VPC. Las rutas generadas por el sistema para los rangos secundarios permiten la conectividad este-oeste para los Pods y Services.

• IP de alias

  • Las IP de alias permiten que una NIC de VM posea múltiples IP de los rangos primarios o secundarios de la subred, lo que habilita políticas estrictas basadas en IP, IP de Pod para GKE nativo de la VPC y un uso eficiente de las IP.
  • Para GKE, planifique CIDR secundarios continuos y grandes para minimizar la fragmentación y futuros redimensionamientos. Ejemplo: para 100 nodos con 200 Pods/nodo y 1500 Services, asigne un rango secundario para Pods de al menos /17 y para Services de /21 para dejar margen de crecimiento.

• Diseño de espacio privado RFC 1918 y gestión de IP

  • Elija bloques que no se superpongan entre todas las VPC actuales y planificadas, las redes on-premise y las de socios. Reserve grandes bloques padres para cada entorno y luego divida sub-bloques predecibles por región y por función.
  • Reserve capacidad para el crecimiento, rangos secundarios, búferes de migración (dual-stack temporal/doble NAT) y endpoints de infraestructura (VIP de ILB, endpoints de PSC).
  • Evite los bloques empresariales más comunes si es probable que haya conectividad con socios; o segmente con NAT para evitar conflictos.

• Planificación de IPv6

  • IPv6 externo: utilice direcciones IPv6 externas globales en los balanceadores de carga globales para el acceso de clientes y la accesibilidad anycast.
  • IPv6 interno: donde esté disponible, habilite subredes dual-stack para asignar IPv6 interno a las VM y ajuste las reglas de firewall correspondientemente. Planifique los registros AAAA de DNS y asegure la paridad con la política de IPv4.
  • Conserve IPv4 para los controles dentro de la nube y las integraciones de terceros; introduzca IPv6 de forma incremental a través de balanceadores de carga y subredes dual-stack.

Enrutamiento: rutas implícitas, rutas personalizadas, prioridades, etiquetas y siguientes saltos

• Rutas implícitas (generadas por el sistema)

  • Rutas de subred: una por subred principal y por cada rango secundario, el destino es igual al CIDR, el siguiente salto es la propia subred.
  • Ruta por defecto: se crea por defecto una ruta 0.0.0.0/0 hacia la puerta de enlace de internet predeterminada; el egreso a internet requiere una IP externa o NAT.

• Rutas personalizadas y lógica de selección

  • La coincidencia de prefijo más largo gana. Si varias rutas tienen la misma longitud de prefijo, gana el número de prioridad más bajo (prioridad por defecto 1000).
  • Etiquetas y cuentas de servicio
    • Las rutas sin etiquetas se aplican a todas las VM. Las rutas con alcance de etiqueta se aplican solo a instancias con etiquetas de red coincidentes.
    • Las reglas de firewall basadas en identidad pueden coincidir con cuentas de servicio; úsalas para un control más fino que las etiquetas cuando sea posible.

• Siguientes saltos

  • Los siguientes saltos admitidos para rutas personalizadas incluyen:
    • Puerta de enlace de internet predeterminada (0.0.0.0/0 o prefijos de egreso más específicos)
    • Instancia (requiere reenvío de IP para enrutar tráfico para otros; se usa para dispositivos virtuales)
    • Túnel de Cloud VPN (rutas estáticas)
    • Balanceador de carga interno regional como siguiente salto (para patrones de dispositivos escalables)
  • No se puede establecer el siguiente salto a una conexión de VPC peering; el peering gestiona su propio intercambio de rutas.

• Ejemplo de direccionamiento de tráfico (dispositivo virtual)

  • Crear una ruta más específica que la ruta de la subred con un siguiente salto a una instancia con reenvío de IP, con alcance definido por etiquetas en las VM de origen.

  • Ejemplo:

undefined

• Egreso a las API de Google sin IP externas
  • Opción 1: Habilitar Private Google Access (PGA) en las subredes, luego agregar rutas personalizadas para las VIP de las API de Google hacia la puerta de enlace de internet predeterminada para omitir una ruta de egreso predeterminada de terceros si es necesario.
  • Opción 2: Usar Cloud NAT con PGA para proporcionar egreso a las VM privadas hacia los servicios de Google.
  • Opción 3: Usar Private Service Connect para las API de Google para un consumo sin internet; el tráfico permanece en la red de Google y utiliza un punto de conexión privado RFC1918 en tu VPC.
  • Para un acceso restringido, apunta los clientes a las VIP restringidas de las API de Google y aplica controles de egreso.

Shared VPC, peering, administración delegada y cuentas de servicio

• Shared VPC

  • El proyecto anfitrión (host project) posee una o más VPC y subredes gestionadas centralmente. Los proyectos de servicio (service projects) adjuntan cargas de trabajo a las subredes compartidas seleccionadas.
  • Administración delegada
    • El Shared VPC Admin configura las adjunciones y el uso compartido de subredes.
    • Los Network Admins gestionan rutas, subredes y firewall en el proyecto anfitrión.
    • El IAM a nivel de proyecto en los proyectos de servicio controla el despliegue de cargas de trabajo; puedes compartir solo las subredes necesarias para limitar el radio de impacto (blast radius) y la visibilidad de las rutas.
  • Cuentas de servicio
    • Prefiere políticas de firewall basadas en cuentas de servicio para un control determinista y basado en identidad entre equipos.
    • Usa cuentas de servicio dedicadas por nivel y entorno, con roles de privilegio mínimo para el acceso a datos (por ejemplo, otorga Storage Object Viewer a una cuenta de servicio que lee de Cloud Storage).

• VPC Network Peering

  • Restricciones
    • No transitivo: A↔B y B↔C no implican A↔C. Construye una malla completa (full mesh) si es necesario.
    • No se permiten rangos de IP superpuestos entre redes interconectadas (peered networks).
    • El intercambio se limita a las rutas de subred (incluyendo los rangos secundarios); no se admite el direccionamiento de siguiente salto a través del peering.
  • Usa el peering para una conectividad privada, de baja latencia y dentro de la organización con una sobrecarga operativa mínima cuando las VPC separadas deben permanecer administrativamente distintas.

• Conectividad híbrida

  • Centraliza Dedicated Interconnect y Cloud Router en un proyecto anfitrión de Shared VPC para compartir conectividad de alta capacidad con los proyectos de servicio de los departamentos.
  • Usa adjuntos de VLAN de alta disponibilidad (HA VLAN attachments), ubicaciones de borde diversas, Cloud Routers duales y enrutamiento dinámico global para resiliencia y propagación a todas las regiones necesarias.

Operaciones: expansión, alta disponibilidad (HA), acceso privado, verificación y solución de problemas

• Restricciones en la expansión y migración de subredes

  • Expande en el mismo lugar (in place) cuando una subred se acerca a su capacidad; valida que todas las redes conectadas no se superpongan y asegúrate de que los rangos secundarios dependientes de GKE sigan siendo adecuados.
  • Si los rangos se superponen entre organizaciones o socios, emplea NAT o una renumeración por etapas. No puedes establecer peering entre VPC superpuestas ni instalar rutas dinámicas superpuestas.

• Ubicación regional y alta disponibilidad

  • Ubica las subredes en las regiones más cercanas a los usuarios y los datos. Para bases de usuarios a ambos lados del Atlántico, una única VPC con subredes regionales en us-east1 y europe-west1 proporciona conectividad privada directa con latencia óptima y sin cargos de egreso dentro de la VPC.
  • Distribuye las cargas de trabajo entre zonas; utiliza grupos de instancias administrados regionales y balanceadores de carga internos/externos regionales para la tolerancia a fallos de zona.
  • Para entornos híbridos, despliega dos Cloud Routers y adjuntos por región o ubicación de borde; habilita BFD donde sea compatible; utiliza el enrutamiento dinámico global para la conmutación por error (failover).

• Acceso privado a Google y endpoints restringidos

  • Habilita PGA en las subredes que alojan instancias sin IP externas.
  • Para evitar el egreso general a Internet y al mismo tiempo permitir el acceso a las API de Google:
    • Enruta el tráfico por defecto a tu NGFW.
    • Añade rutas estáticas más específicas para las VIP de las API de Google hacia la puerta de enlace de Internet por defecto o despliega endpoints de PSC para las API de Google.

  • Ejemplo:

undefined

• Verificación de topología y solución de problemas
  • Usa Network Intelligence Center:
    • Connectivity Tests para validar la alcanzabilidad y simular decisiones de enrutamiento, firewall y puerta de enlace.
    • Performance Dashboard y Topology para visualizar las rutas y su estado.
  • Registros y telemetría:
    • VPC Flow Logs para observar permisos/denegaciones y latencia por interfaz.
    • Firewall Rules Logging para confirmar las coincidencias de reglas.
    • Registros y estado de Cloud NAT para problemas de egreso sin IP externas.
    • Registros del balanceador de carga y de las comprobaciones de estado (health-check) para ver la disponibilidad de los backends.

  • Comprobaciones por CLI:

undefined

y

undefined

para confirmar la política efectiva. -

undefined

y

undefined

desde VMs de prueba; utiliza el duplicado de paquetes (packet mirroring) para una inspección profunda cuando sea necesario.

Escenario de un Problema Práctico

Acme Retail Group necesita una red en Google Cloud multirregional y de baja latencia con control centralizado, acceso sin Internet a las API de Google para instancias privadas y un aislamiento estricto entre departamentos que no necesitan comunicarse. Algunos equipos ejecutan GKE con una alta densidad de Pods. Acme también dirige el egreso general a través de un firewall de terceros, pero quiere que el tráfico de las API de Google evite dicho firewall.

1. Construye una única Shared VPC en un proyecto host en modo personalizado con enrutamiento dinámico global, y crea subredes regionales en us-east1 y europe-west1 con rangos secundarios reservados para GKE.

• Justificación: Una única VPC proporciona conectividad privada, sin costo y multirregional sobre direcciones RFC1918 para una eficiencia óptima. El modo personalizado y el enrutamiento dinámico global soportan una planificación de IP precisa y la propagación de rutas multirregión.

2. Comparte solo las subredes específicas necesarias con el proyecto de servicio de cada departamento; crea tres proyectos de servicio (Ventas, Finanzas, Marketing) y expón solo las subredes requeridas a cada uno.

• Justificación: Compartir por subred limita el radio de impacto (blast radius) y la exposición de rutas, aplicando el aislamiento a la vez que permite operaciones centrales. El IAM delegado permite que los administradores de red centrales gestionen los firewalls y las rutas, mientras que los equipos de aplicaciones despliegan las cargas de trabajo de forma independiente.

3. Para los departamentos que deben comunicarse, establece un peering entre sus VPC dedicadas o colócalos en las mismas subredes de la Shared VPC; para los departamentos aislados, abstente de hacer peering y no compartas subredes superpuestas.

• Justificación: El peering proporciona conectividad privada de baja latencia con una sobrecarga operativa mínima. La no transitividad requiere conexiones de malla explícitas solo donde sea necesario, lo que preserva el aislamiento por defecto.

4. Habilita Private Google Access en todas las subredes compartidas y despliega endpoints de Private Service Connect para las API de Google; mantén la ruta por defecto hacia un firewall de terceros, y además añade rutas estáticas más específicas para las VIP de las API de Google hacia la puerta de enlace de Internet por defecto.

• Justificación: PGA y PSC proporcionan un consumo de API sin Internet desde VMs privadas. Las rutas más específicas aseguran que el tráfico de la API evite el NGFW, mientras que el egreso a Internet que no es de Google continúa a través de la ruta de inspección.

5. Asigna CIDR primarios y secundarios con margen para el crecimiento: para GKE, dimensiona un rango secundario para Pods (por ejemplo, /17) y un secundario para Servicios (/21) por cada región concurrida; utiliza IP de alias para los Pods y Servicios y crea clústeres nativos de la VPC vinculados a esos rangos.

• Justificación: Los rangos secundarios y las IP de alias evitan el agotamiento de las IP de los nodos y permiten una programación densa. Dimensionar para la demanda futura evita redimensionamientos disruptivos y la renumeración de los rangos secundarios.

6. Implementa HA para el tráfico híbrido y de appliances: despliega dos Cloud Routers y HA VPN o Interconnect según sea necesario; donde se requiera dirigir el tráfico a través de un appliance virtual, utiliza una ruta personalizada más específica con el siguiente salto (next hop) configurado a un balanceador de carga interno regional o a una instancia con reenvío de IP (IP forwarding) y aplicabilidad acotada por etiquetas (tag-scoped).

• Justificación: La alta disponibilidad en el borde (edge) asegura la continuidad durante las fallas. Acotar el alcance de la ruta por etiquetas evita el hairpinning de tráfico accidental y permite que solo las instancias seleccionadas atraviesen la ruta del appliance.

7. Verifica y opera con Connectivity Tests de Network Intelligence Center, VPC Flow Logs y Firewall Rules Logging; aplica políticas de firewall basadas en identidad utilizando cuentas de servicio y mantén registros de IPAM con búferes reservados por región y función.

• Justificación: La verificación proactiva previene interrupciones durante los cambios. Las políticas basadas en identidad son más robustas que los enfoques basados solo en etiquetas. La disciplina en IPAM previene la superposición que podría bloquear el peering o suprimir las rutas aprendidas.

Todos los dominios · Política de firewall →

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

Explorar Google →