El dominio de redes en el examen GCP-ACE exige más que memorización — requiere capacidad de tomar decisiones de arquitectura. ¿Cuándo se elige Shared VPC sobre VPC Peering? ¿Por qué Network Load Balancer es la respuesta incorrecta cuando se sirve tráfico HTTPS global? ¿Qué herramienta separa la estimación de costos de la facturación real? Estas decisiones de juicio definen la diferencia entre aprobar y adivinar. Esta guía recorre qué hace único al networking de GCP, cómo seleccionar el balanceador de carga correcto, qué servicios de soporte utilizar y cómo evitar las trampas de costos que sorprenden a los ingenieros.
---
Cómo el Networking de GCP Difiere de Otras Nubes
Lo primero que sorprende a los ingenieros que vienen de AWS o Azure es que el VPC de GCP es un recurso global. En AWS y Azure, un VPC o VNet pertenece a una región específica. Conectar un VPC en Seúl con uno en US-East requiere peering explícito o un Transit Gateway.
GCP funciona de manera diferente. Un VPC no tiene región — es una construcción global. Puedes colocar subredes en Seúl (asia-northeast3), US East (us-east1) y Europa (europe-west1) dentro del mismo VPC, y las VMs conectadas a esas subredes pueden comunicarse mediante IPs privadas sin configuración adicional.
Un segundo diferenciador es la red privada global de Google. Cuando el tráfico llega a un balanceador de carga global, se recibe en el PoP de Google más cercano y luego se transporta por la fibra privada de Google — no por la internet pública — hacia la región del backend. Esto es lo que permite que una sola IP Anycast global entregue respuestas de baja latencia en todo el mundo.
| Atributo | GCP | AWS | Azure | |----------|-----|-----|-------| | Alcance del VPC | Global (sin región) | Por región | Por región | | Alcance de Subred | Por región, abarca todas las zonas | Por zona de disponibilidad | Por región | | LB Global | IP Anycast única | Configuración separada requerida | Configuración separada requerida | | Backbone Global | Red privada de Google | Red interna de AWS | Red interna de Microsoft |
---
VPC y Subredes: El Modelo de VPC Global
Cuando creas un VPC en GCP, no seleccionas una región — es un contenedor de red global. Las regiones entran en juego a nivel de subred. Cuando creas una subred, especificas una región, y esa subred abarca automáticamente todas las zonas de disponibilidad en esa región. Una subred en Seúl y una en EE.UU. que viven en el mismo VPC permiten que sus VMs hablen mediante IPs privadas sin configuración adicional de enrutamiento o peering.
Las subredes de GCP admiten rangos de IP secundarios además del bloque CIDR primario. Se utilizan principalmente para pods y servicios de GKE, dando a las cargas de trabajo de Kubernetes un espacio de direcciones independiente que no colisiona con el espacio IP primario de las VMs.
Las reglas de firewall operan a nivel del VPC. Para aplicar una regla a un conjunto específico de VMs, usas etiquetas de red o cuentas de servicio como destinos. Esto difiere de los grupos de seguridad de AWS, que se adjuntan directamente a las instancias. En GCP, la regla se define en el VPC y la etiqueta en la instancia determina si la regla aplica.
| Elemento | Descripción | Limitación Clave | |----------|-------------|------------------| | VPC | Recurso global, sin afinidad de región | Límite predeterminado de 5 VPCs por proyecto | | Subred | Con alcance de región, cubre todas las zonas | No se permiten CIDRs superpuestos | | Rango de IP Secundario | Pool de IP adicional para pods y servicios de GKE | Hasta 30 rangos por subred | | Regla de Firewall | A nivel de VPC, dirigida mediante etiquetas o cuentas de servicio | Procesamiento stateful |
---
Modo Automático vs Modo Personalizado de VPC y Planificación de IPs
Al crear un VPC, eliges entre modo automático y modo personalizado. Puedes convertir un VPC en modo automático a modo personalizado, pero no al revés — así que la elección inicial importa.
El modo automático crea automáticamente una subred /20 en cada región desde el bloque 10.128.0.0/9. Es conveniente para entornos de desarrollo, prueba y aprendizaje donde la velocidad de configuración importa más que la precisión de IP. El modo personalizado te da control total sobre la creación de subredes — defines cada subred manualmente, eligiendo la región y el bloque CIDR.
Para cargas de trabajo en producción, el modo personalizado es la elección correcta cuando anticipas conectar a redes on-premises mediante Cloud Interconnect o VPN. El bloque 10.128.0.0/9 usado por el modo automático se superpone con rangos de direcciones comúnmente usados en centros de datos corporativos. Si existe una superposición cuando intentas conectar, rediseñar el VPC es tu única opción.
| Atributo | Modo Automático | Modo Personalizado | |----------|-----------------|--------------------| | Creación de Subred | Automática (/20 por región) | Manual (definida por usuario) | | Rango de IP | 10.128.0.0/9 fijo | Definido por usuario | | Recomendado Para | Dev/prueba, aprendizaje | Producción, empresarial | | Conectividad On-Premises | Alto riesgo de conflicto de IP | Conflicto evitable | | Conversión | Auto → Personalizado permitido | Personalizado → Auto no permitido |
!VPC en modo automático vs modo personalizado
Shared VPC y VPC Peering: Dos Modelos de Conectividad
Cuando necesitas conectividad de red entre múltiples proyectos de GCP, tienes dos opciones: Shared VPC y VPC Peering. Este es consistentemente uno de los temas más confundidos en el examen.
Shared VPC designa un proyecto como el proyecto host, que posee y gestiona el VPC. Otros proyectos — llamados proyectos de servicio — se adjuntan al host y despliegan sus VMs en subredes que pertenecen al VPC del host. Las VMs se comunican mediante IPs privadas dentro del mismo VPC, y hay una separación clara entre los administradores de red (equipo del proyecto host) y los equipos de aplicación (equipos de proyectos de servicio).
VPC Peering conecta dos VPCs punto a punto. Cada VPC permanece gestionado de forma independiente, y el peering habilita la comunicación mediante IP privada entre ellos. La propiedad crítica a recordar es la no-transitividad. Si el VPC A está emparejado con el VPC B, y el VPC B está emparejado con el VPC C, el VPC A y el VPC C no pueden comunicarse. Necesitarías establecer un peering directo entre A y C. Shared VPC evita esto completamente porque todos los proyectos de servicio comparten el mismo VPC.
| Atributo | Shared VPC | VPC Peering | |----------|------------|-------------| | Propiedad de Red | Proyecto host único | Cada VPC de propiedad independiente | | Modelo de Gestión | Centralizado (proyecto host) | Distribuido (cada equipo) | | Escala de Proyectos de Servicio | Hasta 1,000 proyectos de servicio | Requiere peerings N:N | | No-transitividad | No aplica (mismo VPC) | Aplica (A-B-C no puede transitar) | | Entre Organizaciones | No soportado (solo misma org) | Soportado | | Factor Principal de Decisión | Gobernanza de red central | Propiedad independiente de red |
Disparo de examen: múltiples VMs de proyectos necesitando comunicación IP privada con gestión central → Shared VPC. Dos VPCs independientes necesitando conectividad privada → VPC Peering.
---
Tipos de Balanceadores de Carga de GCP y Marco de Decisión
La selección de balanceador de carga es un tema de alta frecuencia en el examen GCP-ACE. El árbol de decisión corre a lo largo de tres ejes: alcance (global vs regional), dirección (externo vs interno) y capa (L7 aplicación vs L4 red).
El Application Load Balancer externo global (antes Global HTTP(S) LB) acepta tráfico mediante una IP Anycast única desde cualquier parte del mundo, enruta solicitudes a diferentes backends basándose en la ruta URL y el encabezado de host, y maneja la terminación SSL con certificados administrados por Google. Opera en Capa 7. Si necesitas enrutar /api/orders y /api/users a servicios backend separados, este es el balanceador de carga que necesitas.
El Application Load Balancer interno maneja tráfico HTTP dentro de un VPC. Se usa para comunicación privada entre microservicios y como puerta de enlace API privada. No tiene IP pública.
Network Load Balancer opera en Capa 4 y maneja TCP y UDP. No puede inspeccionar URLs, lo que lo hace inadecuado para enrutamiento basado en rutas. Destaca en escenarios de ultra-baja latencia como servidores de juegos y aplicaciones UDP en tiempo real.
| Tipo de Balanceador | Alcance | Capa | Capacidades Clave | Elegir Cuando | |---------------------|---------|------|-------------------|---------------| | Application LB Externo Global | Global | L7 | Enrutamiento URL, Anycast global, descarga SSL | HTTPS global, enrutamiento por ruta URL | | Application LB Externo Regional | Regional | L7 | Enrutamiento URL, descarga SSL | HTTPS de región única | | Application LB Interno | Regional | L7 | Tráfico HTTP privado dentro del VPC | HTTP entre microservicios | | Network LB Externo (passthrough) | Regional | L4 | TCP/UDP, ultra-baja latencia | Gaming, streaming, apps heredadas | | Network LB Interno (passthrough) | Regional | L4 | TCP/UDP privado dentro del VPC | Cargas de trabajo internas de alto rendimiento | | Proxy Network LB | Global/Regional | L4 | Proxy TCP | TCP + distribución global |
Guía de decisión: HTTPS global con enrutamiento URL → Application LB Externo Global. HTTP interno entre microservicios → Application LB Interno. UDP con ultra-baja latencia → Network LB. Failover regional automático → Application LB Global.
---
Cloud DNS, Cloud CDN y Cloud NAT: Roles y Límites
Los servicios de red de soporte aparecen en el examen, y sus límites importan. Saber qué hace cada uno — y qué no hace — previene la mala identificación bajo presión de tiempo.
Cloud DNS gestiona registros DNS con un SLA del 99.99%. Una zona pública maneja nombres de dominio resolubles externamente. Una zona privada se adjunta a uno o más VPCs y solo es visible pa