Google PCNE: Balanceo de cargas, Cloud CDN y gestión de tráfico global — 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

Esta sección explica cómo Google Cloud Load Balancing, Cloud CDN y la gestión de tráfico global funcionan en conjunto para ofrecer servicios resilientes, de alto rendimiento y seguros. Cubre las familias y la selección de balanceadores de cargas, el comportamiento de proxy frente al de passthrough, los componentes de backend y enrutamiento, la conmutación por error y la gestión de capacidad, el almacenamiento en caché de Cloud CDN y las protecciones de origen, los diseños anycast y multirregionales, el direccionamiento por DNS y las verificaciones de estado, la observabilidad y los patrones de diseño para puntos de entrada globales robustos.

Familias de balanceadores de cargas, selección y comportamiento del plano de datos

Google Cloud ofrece balanceadores de cargas externos e internos con características distintas de alcance, protocolo y plano de datos. Elegir el adecuado alinea las necesidades de protocolo, la geografía y los controles operativos.

• Proxy externo L7 (global): External Application Load Balancer para HTTP(S) y gRPC. Termina TLS, aplica políticas de L7, admite mapas de URL, Cloud CDN, Cloud Armor, funciones de solicitud/respuesta y anycast IPv4/IPv6. Es la mejor opción para API y sitios web orientados a Internet que requieren enrutamiento avanzado, seguridad y almacenamiento en caché.

• Proxy externo L4.5: External TCP Proxy Load Balancer (global) y External UDP Proxy Load Balancer (regional) terminan las conexiones de los clientes y las envían por proxy a los backends. Se utiliza cuando se necesita una VIP global y funciones de L4 (política de TLS, preservación de la IP del cliente mediante encabezados para TCP) sin enrutamiento de L7.

• Passthrough externo L3/L4 (regional): External Network Load Balancer reenvía paquetes sin terminar la conexión. Es el de menor latencia y el más simple; admite TCP/UDP/ESP/ICMP. Adecuado para migraciones lift-and-shift, backends heterogéneos o protocolos que no toleran la terminación de proxy. El NLB clásico utiliza target pools; el NLB passthrough regional más nuevo utiliza backend services.

• Proxy interno (regional): Internal HTTP(S) Load Balancer (L7) y Internal TCP Proxy Load Balancer (L4.5) terminan y actúan como proxy dentro de una VPC para el uso norte-sur de microservicios y de servicio a servicio. Admiten enrutamiento por host/ruta (HTTP), mTLS hacia los clientes a través de la aplicación y políticas de seguridad por servicio.

• Passthrough interno (regional): Internal TCP/UDP Load Balancer distribuye conexiones a los backends sobre direcciones privadas RFC1918, preservando la IP del cliente y utilizando el hashing MAGLEV. Ideal para servicios este-oeste (bases de datos, protocolos personalizados) que requieren una distribución consciente de la zona y una sobrecarga baja.

Compensaciones de capa y terminación:

• El proxy L7/4.5 ofrece enrutamiento avanzado, descarga de TLS, observabilidad, Cloud Armor/CDN y conmutación por error multirregional a costa de saltos adicionales y posibles cambios de encabezado/NAT. Es adecuado para puntos de entrada públicos y mallas de servicios.
• El passthrough L3/L4 preserva la IP del cliente de extremo a extremo y minimiza la latencia, pero no tiene funciones de L7 y menos ganchos de observabilidad. El comportamiento de la sesión se basa en hash; las verificaciones de estado son más simples.

Alcance y familias de IP:

• Las VIP anycast globales están disponibles para el External Application LB y el External TCP Proxy LB, proporcionando direcciones IPv4/IPv6 únicas accesibles desde cualquier lugar. Los LB regionales utilizan VIP unicast regionales. La exposición a IPv6 para servicios públicos se logra configurando un balanceador de cargas global externo con una dirección IPv6.

Puntos destacados de los criterios de selección:

• Si necesita enrutamiento por host/ruta, redirecciones, Cloud CDN, Cloud Armor o gRPC: External Application LB.
• Si necesita TCP global sin L7: External TCP Proxy LB.
• Para protocolos que no funcionan bien con proxies (p. ej., algunos legados como UDP/TFTP): Passthrough externo o interno.
• Para comunicación de servicio a servicio privada con enrutamiento HTTP: Internal HTTP(S) LB.
• Para minimizar el costo/saltos para el tráfico dentro de la VPC: Passthrough interno.

Servicios de backend, objetos de enrutamiento, estado y persistencia del tráfico

Objetos principales del plano de datos:

• Backend services: Definen los backends (grupos de instancias, NEG zonales, NEG híbridos, NEG sin servidor), las verificaciones de estado, el modo de balanceo, la capacidad, la afinidad de sesión, el tiempo de espera y la política de conmutación por error. Son necesarios para los balanceadores de carga de proxy y los balanceadores de carga de paso más nuevos.
• Target pools: Construcción heredada para el NLB externo clásico. Adecuado para distribuciones simples de TCP/UDP y máquinas virtuales heterogéneas durante una migración lift-and-shift.
• Named ports: Claves en los grupos de instancias que mapean nombres lógicos (p. ej., http) a números de puerto, a los que hacen referencia los servicios de backend y los mapas de URL. Aseguran la coherencia entre los miembros del grupo.

Verificaciones de estado y conmutación por error:

• Tipos: HTTP(S), HTTP/2, gRPC, TCP, SSL. Elige una verificación que valide la disponibilidad real del servicio, no solo la accesibilidad del sistema operativo.
• Alcance: Las verificaciones de estado son regionales; cada backend debe tener una verificación de estado con alcance en su región de servicio.
• Política de conmutación por error: El servicio de backend puede designar backends primarios y de conmutación por error. El tráfico conmuta por error cuando el backend primario no está en buen estado o se queda sin capacidad (si la conmutación por error por capacidad está habilitada y se alcanza el umbral). Considera el drenaje y la reserva de capacidad para evitar el efecto de estampida (thundering herd).

Mapas de URL y enrutamiento:

• El mapa de URL se adjunta al balanceador de carga HTTP(S) externo o interno y define las reglas de host y los comparadores de rutas (path matchers).
• Servicio predeterminado: Backend general (catch-all) para solicitudes que no coinciden con ninguna regla; si no se establece, se devuelve un 404.
• Redirecciones y reescrituras: Usa las acciones del mapa de URL para realizar redirecciones HTTPS, redirecciones de host canónico o reescrituras de ruta antes del enrutamiento.

Ejemplo: mapa de URL mínimo con redirección HTTPS y backend predeterminado

• Crear una regla de host para example.com, redirigir HTTP a HTTPS, enrutar /static a un bucket de backend habilitado para CDN y, por defecto, a un servicio de backend regional.

Afinidad de sesión y drenaje:

• Las opciones de afinidad dependen del tipo de balanceador de carga. Las opciones comunes son:
  • Ninguna: Ideal para servicios sin estado (stateless); maximiza la distribución de la carga.
  • IP del cliente: Persistencia por IP de origen en L4/L7; úsalo cuando múltiples protocolos (p. ej., HTTP y TFTP) deben tener persistencia conjunta (co-sticky) hacia el mismo backend.
  • Cookie generada (solo L7): El balanceador de carga establece una cookie para mantener la persistencia hacia un backend; mejor distribución que la IP del cliente en clientes con NAT.
• Compensaciones: La afinidad puede causar hotspotting (concentración de carga) y complicar el autoescalado. Prefiere la arquitectura sin estado (statelessness) siempre que sea posible.
• Drenaje de conexiones: Al reducir la escala o eliminar un backend, el balanceador de carga respeta el tiempo de espera de drenaje para permitir que las conexiones existentes se cierren correctamente. Ajusta el tiempo de drenaje a tu solicitud más larga esperada para evitar reinicios.

Capacidad y autoescalado:

• Modos de balanceo: Basados en la utilización (p. ej., CPU), RPS o conexiones. Cada backend anuncia su capacidad; el balanceador de carga desvía la carga o conmuta por error cuando se produce la saturación.
• Autoescalado: Los grupos de instancias administrados (Managed instance groups) escalan según señales (CPU, métricas personalizadas). El retraso en el escalado horizontal (scale-out) puede causar errores 503 si el balanceador de carga se queda sin capacidad; precalienta con un número mínimo de réplicas o con autoescalado predictivo para el tráfico diurno.
• Conmutación por error y desbordamiento: Habilitar la conmutación por error por capacidad con un umbral apropiado permite un desbordamiento fluido entre regiones.

Seguridad en los backends:

• Restringe el acceso al backend usando reglas de firewall dirigidas a etiquetas de instancia o cuentas de servicio. Permite solo el tráfico de los rangos de origen del balanceador de carga y de las verificaciones de estado de Google, y los rangos de tus clientes aprobados si se requiere acceso directo para clientes internos.

Ejemplo: restringir clientes y verificaciones de estado a un grupo etiquetado como backend

• Etiqueta las instancias con application.
• Crea una regla de permiso de entrada (ingress allow) para tcp:80 desde tus CIDR de cliente y los rangos de verificación de estado de Google, dirigida a la etiqueta application.
• Se recomienda denegar por defecto para que el tráfico descartado aparezca en los registros.

Cloud CDN, política de caché y protección del origen

Cloud CDN se integra con el Application Load Balancer externo para almacenar en caché las respuestas en los POPs de borde, reduciendo la latencia y descargando la capacidad del origen.

Modos de caché y TTLs:

• Usar encabezados de origen: Respeta Cache-Control y Expires de tu origen. Es la opción preferida para garantizar la corrección de los datos.
• Forzar caché: Almacena en caché todas las respuestas con un TTL predeterminado configurado, opcionalmente sobreescribiendo o ignorando los encabezados de origen para contenido estático. Úsalo con cuidado para evitar almacenar en caché datos dinámicos.
• Omitir caché: Útil para rutas que nunca deben almacenarse en caché.

Claves de caché:

• Los campos de la clave incluyen protocolo, host, ruta, parámetros de consulta, encabezados y cookies. Configura la política de cadena de consulta (incluir todo, incluir seleccionados u omitir), la inclusión selectiva de encabezados y cookies, y la segmentación por dispositivo según sea necesario.
• Mantén las claves al mínimo para maximizar la tasa de aciertos; varía solo en los campos que cambian la representación.

Solicitudes firmadas:

• URLs firmadas: Adjunta una firma HMAC o RSA con una caducidad y un alcance de ruta para otorgar acceso por tiempo limitado a recursos específicos. Es una buena opción para usar el CDN como acelerador con autorización por objeto.
• Cookies firmadas: Autoriza un conjunto de rutas con una cookie; útil para contenido restringido en todo el sitio.
• Rota las claves y aplica caducidades cortas para reducir el riesgo de ataques de repetición (replay).

Compresión y corrección:

• Los orígenes deben comprimir incluso cuando las solicitudes incluyen un encabezado Via. Si el CDN sirve objetos sin comprimir mientras que el origen “admite compresión”, verifica que el origen esté configurado para comprimir cuando el encabezado Via está presente.

Seguridad del origen:

• Usa HTTPS desde los proxies de borde hasta los orígenes con políticas de TLS modernas.
• Limita la alcanzabilidad del origen: reglas de firewall en el backend que solo permitan tráfico desde los rangos de origen del balanceador de carga y las verificaciones de estado de Google, y desde productores privados conocidos. Las instancias de backend no deben aceptar tráfico de entrada público arbitrario.
• Combínalo con Cloud Armor para protección contra DDoS/WAF de capa 7, limitación de velocidad y detección de amenazas. Usa el modo de vista previa (preview) para las nuevas reglas a fin de mitigar los falsos positivos.
• Invalida contenido intencionadamente usando las API de invalidación de caché cuando debas purgarlo antes de que expire el TTL. Para contenido dinámico, prefiere TTLs cortos y la revalidación (ETag/If-None-Match).

Modos de fallo y contrapartidas:

• Claves de caché demasiado amplias desperdician caché y reducen la tasa de aciertos; claves demasiado específicas corren el riesgo de servir variantes incorrectas.
• Forzar el almacenamiento en caché de datos dinámicos puede filtrar contenido personalizado.
• Las URLs/cookies firmadas protegen el acceso en el borde, pero el acceso directo al origen aún debe denegarse mediante una política de red.

Gestión de tráfico global, direccionamiento DNS, observabilidad y puntos de entrada resilientes

Puntos de entrada anycast y conmutación por error entre regiones:

• El Application LB externo y el TCP Proxy LB externo usan VIPs anycast globales para atraer a los clientes al borde de Google más cercano. El tráfico se redirige entonces mediante proxy al backend más cercano, en buen estado y con capacidad. Configure múltiples regiones de backend con verificaciones de estado y ajustes de capacidad consistentes para una conmutación por error y desbordamiento fluidos.
• Preaprovisione capacidad en las regiones secundarias para evitar penalizaciones de arranque en frío; coordine los valores mín/máx del autoescalador con los umbrales de capacidad del LB.

Gestión de tráfico interno regional:

• El HTTP(S) LB interno y el passthrough LB interno son regionales; diseñe para la diversidad de zonas dentro de una región y, cuando sea necesario, para múltiples regiones usando LBs separados con Private Service Connect o clientes conscientes del servicio para seleccionar los endpoints regionales.
• Mantenga baja la latencia este-oeste ubicando los servicios que se comunican en la misma región y VPC. Use direccionamiento RFC1918 con una única VPC o VPCs en peering para un costo mínimo y simplicidad operativa.

Políticas de enrutamiento y verificaciones de estado de Cloud DNS:

• Políticas: Round robin ponderado (división de tráfico), geolocalización (enviar usuarios al VIP regional más cercano) y conmutación por error (primario/respaldo). Combine políticas para cumplir con las reglas de negocio.
• Verificaciones de estado: Asocie verificaciones de estado de DNS (HTTP/HTTPS/TCP) a los registros A/AAAA usados en el direccionamiento para que los endpoints en mal estado sean retirados. Tenga en cuenta el almacenamiento en caché del resolver (TTL), que retrasa la reacción; mantenga los TTLs bajos en los registros direccionados para mejorar la capacidad de respuesta de la conmutación por error a costa de más búsquedas de DNS.
• Direccionamiento de tráfico: Use políticas ponderadas para realizar migraciones por fases o para desplazar la carga entre regiones. Evite direccionar a direcciones privadas desde internet a menos que use DNS de horizonte dividido.

Observabilidad y diagnósticos:

• Registro de actividad del balanceador de carga: Habilite el registro para todos los LBs. Los registros de HTTP(S) incluyen el método/URI de la solicitud, latencia, acierto/fallo de caché, servicio de backend, regla del mapa de URL, detalles de TLS y códigos de respuesta. Los registros de TCP/UDP proporcionan metadatos de conexión y el estado de las sondas de verificación de estado.
• Métricas: Supervise el estado del backend, la utilización, RPS, conexiones, latencia, ratio de aciertos de caché, tasas de errores 4xx/5xx y saturación de capacidad. Genere alertas sobre cambios repentinos y umbrales sostenidos.
• Patrones de error comunes de HTTP(S):
  • 404: No hay coincidencia en el mapa de URL; confirme las reglas de host/ruta y el servicio predeterminado.
  • 301/302: Redirecciones intencionadas; verifique si hay bucles de redirección.
  • 502: Error de conexión con el backend o discrepancia de protocolo (p. ej., HTTP/1.1 vs gRPC); revise el estado y la configuración del protocolo del backend.
  • 503: No hay backends en buen estado o sin capacidad; verifique las verificaciones de estado, las cuotas y el comportamiento del autoescalador.
• Rastreo de solicitudes: Use X-Forwarded-For, X-Forwarded-Proto y los IDs de rastreo propagados por su aplicación. Correlacione los registros del LB con los registros del backend usando los IDs de solicitud.
• Estadísticas de firewall: Habilite el registro de firewall de VPC en las reglas de permitir y denegar. Para registrar explícitamente los descartes, añada una regla de denegar todo de baja prioridad con el registro habilitado.

Diseño de punto de entrada global resiliente:

• Use un único VIP anycast global en un Application LB externo que actúe como front-end para múltiples backends regionales. Ubique los backends serverless/VM/contenedores en al menos dos regiones. Habilite la conmutación por error y el desbordamiento entre regiones, configure verificaciones de estado conservadoras y ajuste el drenaje y los tiempos de espera para sus cargas de trabajo.
• Proteja el punto de entrada con Cloud Armor y políticas de limitación de cuota. Use Cloud CDN para contenido estático y dinámico almacenable en caché para absorber picos de tráfico en el borde.
• Exponga una pila doble IPv4/IPv6 en el LB global para servir a todas las redes. Para un acceso estricto de clientes, aplique reglas de firewall en el backend con rangos de origen precisos y etiquetas de instancia o cuentas de servicio.

Ejemplo: regla de firewall que restringe los rangos de clientes y de verificación de estado a backends etiquetados

• Etiquete las instancias con application.
• Cree una regla de entrada para permitir tcp:443 desde los rangos de origen source-ranges=203.0.113.0/24,198.51.100.0/24 y los rangos de verificación de estado de Google, apuntando a application.
• Asegúrese de que exista una regla de denegar todo de menor prioridad con el registro habilitado para capturar orígenes inesperados.

Escenario de problema práctico

Acme Retail lanza una plataforma global de comercio electrónico que necesita baja latencia, seguridad robusta y conmutación por error transparente entre us-east1 y europe-west1, al tiempo que sirve contenido multimedia estático de manera eficiente. Solo las oficinas corporativas y una red de staging de un CDN asociado deben poder acceder a la interfaz de administración privada.

1. Punto de entrada y backends

• Cree un Application Load Balancer externo con un VIP anycast de pila doble y certificados TLS para el nombre de host público de la tienda.
• Defina dos servicios de backend, cada uno apuntando a un grupo de instancias administrado regional en us-east1 y europe-west1. Habilite las verificaciones de estado (HTTPS) y establezca el modo de balanceo en utilización con un umbral de capacidad del 80%. Justificación: Anycast más backends multirregionales asegura que los usuarios lleguen al borde más cercano y conmuten por error de forma fluida si una región no está en buen estado o está saturada.

2. Mapa de URL, enrutamiento y redirecciones

• Configure un mapa de URL con reglas de host para los nombres de host de la tienda pública y del administrador privado. Enrute /static a un bucket de backend con Cloud CDN habilitado; enrute /api y / a los backends de VM. Añada una redirección de HTTP a HTTPS. Justificación: El enrutamiento por host/ruta separa el tráfico estático del dinámico y fuerza el acceso seguro.

3. Política de Cloud CDN

• Para el bucket de backend /static, establezca el modo de caché para usar las cabeceras de origen y defina una clave de caché que ignore los parámetros de consulta no funcionales e incluya solo la cabecera Accept-Encoding. Habilite el almacenamiento en caché negativo para errores 404 comunes con un TTL corto. Justificación: Respeta la semántica del contenido, maximiza el ratio de aciertos y evita almacenar en caché variantes incorrectas.

4. Afinidad de sesión y drenaje de conexiones

• Establezca afinidad por cookie generada para la tienda pública y ninguna para los activos estáticos; establezca el drenaje de conexiones en 60 segundos. Justificación: Las cookies mantienen estables las sesiones del carrito de compras mientras permiten una distribución amplia; el drenaje previene errores visibles para el usuario durante el escalado hacia adentro o la conmutación por error.

5. Conmutación por error entre regiones y autoescalado

• Habilite la conmutación por error por capacidad con un umbral de desbordamiento del 90% para desplazar el exceso a la otra región. Configure el autoescalado del MIG con un mínimo de 4 réplicas por región y objetivos de CPU que coincidan con la utilización del LB. Justificación: Evita caídas abruptas de capacidad y coordina las decisiones del LB y del autoescalador para un escalado fluido.

6. Restricción de la interfaz de administración

• Cree un HTTP(S) Load Balancer interno para el nombre de host del administrador privado, accesible solo dentro de la VPC. Publique un DNS de horizonte dividido en Cloud DNS para que los clientes internos resuelvan al VIP del ILB y los clientes externos reciban NXDOMAIN. Justificación: Mantiene el tráfico de administración privado y controlado sin exponer endpoints públicos.

7. Firewall de backend y seguridad de origen

• Etiquete los backends de administración y web como application y añada una regla de permiso para tcp:443 desde los CIDRs corporativos y de staging, además de los rangos de origen del balanceador de carga y de las verificaciones de estado de Google; añada una regla de denegar todo con registro a una prioridad más baja. Justificación: Asegura que solo los clientes previstos y la infraestructura de Google puedan llegar a los backends y proporciona visibilidad sobre los paquetes descartados.

8. Cloud Armor

• Aplique una política de seguridad con reglas WAF administradas y un límite de tasa en modo de vista previa para ráfagas en /api. Justificación: La protección en L7 y la aplicación por fases reducen el riesgo mientras se realizan ajustes.

9. Direccionamiento y verificaciones de estado de Cloud DNS

• Publique registros A y AAAA para el nombre de host de la tienda pública apuntando al VIP anycast del ALB. Para un canary azul/verde, cree una política ponderada en un nombre de host designado para el canary, dividiendo el 5% al ALB exclusivo de europe-west1 y el 95% a la implementación global. Asocie verificaciones de estado HTTPS para retirar el canary si no está en buen estado y establezca el TTL en 20 segundos. Justificación: El canary basado en DNS permite una exposición gradual con eliminación basada en el estado y una convergencia rápida.

10. Observabilidad

• Habilite los registros del LB y de CDN; expórtelos a BigQuery para su análisis. Establezca alertas sobre la tasa de errores 5xx, la capacidad del backend, los fallos en las verificaciones de estado y el ratio de aciertos de CDN. Use pruebas de mapa de URL y registros de solicitudes para diagnosticar errores de enrutamiento; inspeccione los picos de 502/503 en busca de saturación del backend o discrepancias de protocolo. Justificación: La supervisión proactiva y los diagnósticos rápidos minimizan el MTTR y preservan la experiencia del usuario.

← Conectividad híbrida · Todos los dominios · Cloud DNS →

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

Explorar Google →