Guía

Planificar el direccionamiento IP para implementaciones a gran escala o en la nube híbrida.

→Utilizar VPCs en modo personalizado. Asignar bloques CIDR RFC 1918 que no se superpongan (por ejemplo, 172.16.0.0/12) para evitar conflictos con redes on-prem (a menudo 10.0.0.0/8). Usar 100.64.0.0/10 para rangos secundarios de pods de GKE.

Por qué: Evita conflictos de IP con redes on-prem para futura conectividad híbrida y proporciona control total sobre el espacio de direcciones, lo cual es esencial para la escalabilidad y para evitar costosas re-IP.

Referencia↗

Proporcionar aislamiento de red para múltiples inquilinos/entornos (desarrollo, producción) mientras se centraliza la gestión de red y los servicios compartidos.

→Utilizar Shared VPC. El proyecto host contiene la VPC, las subredes, los firewalls y las interconexiones. Los inquilinos/entornos son proyectos de servicio adjuntos al proyecto host.

Por qué: Centraliza la administración de la red en el proyecto host mientras delega la gestión de recursos a los proyectos de servicio. Más escalable y gobernable que el VPC peering para muchos proyectos dentro de una organización.

Referencia↗

Planificar el direccionamiento IP para grandes clusters de GKE utilizando redes nativas de VPC.

→En una VPC de modo personalizado, planificar tres rangos CIDR: un rango primario para nodos, un rango secundario para Pods y otro para Services. Para la expansión, usar CIDR multi-pod discontinuo.

Por qué: La red nativa de VPC requiere rangos secundarios dedicados y no superpuestos para pods y servicios. Un dimensionamiento adecuado previene el agotamiento de IP, un problema común y disruptivo en clusters grandes.

Referencia↗

Las VMs sin IPs externas necesitan acceder a las APIs de Google Cloud (por ejemplo, Cloud Storage, BigQuery).

→Habilitar Private Google Access en la subred. Opcionalmente, configurar DNS para resolver `*.googleapis.com` a `restricted.googleapis.com` (199.36.153.4/30) para aplicar VPC-SC.

Por qué: Encaminará el tráfico a las APIs de Google a través de la red interna de Google sin requerir IPs públicas en las VMs. El uso de `restricted.googleapis.com` añade una capa de protección contra la exfiltración de datos.

Referencia↗

Proporcionar acceso privado a un servicio en su VPC para consumidores (socios, otras unidades de negocio) cuyas VPCs tienen rangos de IP superpuestos.

→Publicar el servicio (a través de un Internal Load Balancer) utilizando un adjunto de servicio de Private Service Connect (PSC). Los consumidores crean un endpoint de PSC en su VPC con una IP de su propio rango.

Por qué: PSC desacopla las redes del productor y del consumidor, utilizando NAT para manejar IPs superpuestas. Proporciona acceso seguro a nivel de servicio, no conectividad de red completa como el VPC peering.

Referencia↗

Conectar un gran número (más de 50) de VPCs y/o sitios on-prem en una topología de hub-and-spoke para una gestión y conectividad centralizadas.

→Utilizar Network Connectivity Center. Configurar el hub y adjuntar las VPCs como spokes de VPC y las conexiones on-prem (VPN/Interconnect) como spokes híbridos.

Por qué: NCC es la solución gestionada de Google para topologías hub-and-spoke a gran escala, simplificando la gestión de rutas y escalando más allá del límite de 25 pares del VPC peering.

Desplegar un cluster de GKE donde los nodos y el plano de control no tengan direcciones IP públicas para una seguridad mejorada.

→Crear un cluster de GKE Private. Esto asigna solo IPs internas a los nodos y crea un endpoint privado para el plano de control. Configurar redes autorizadas para restringir el acceso al plano de control.

Por qué: Un cluster privado elimina el plano de control y los nodos de la internet pública, reduciendo significativamente la superficie de ataque. Todo el tráfico de gestión y de carga de trabajo permanece en la red privada.

Las cargas de trabajo serverless (Cloud Run, Functions) necesitan acceder a recursos (por ejemplo, Cloud SQL, Memorystore) dentro de una VPC.

→Crear un conector de Serverless VPC Access en la VPC de destino. Configurar el servicio serverless para que use este conector para el tráfico de salida.

Por qué: El conector actúa como un proxy, permitiendo que los servicios serverless (que se ejecutan en un entorno gestionado por Google) envíen tráfico a una VPC gestionada por el cliente utilizando IPs internas.

Una aplicación (por ejemplo, HPC, trading financiero) requiere la latencia de red más baja posible entre un grupo de VMs.

→Crear una política de ubicación compacta y aplicarla a las VMs. Usar tipos de máquina con red Tier_1.

Por qué: Colocar las VMs dentro del mismo rack de red minimiza los saltos de red y la distancia física, reduciendo significativamente la latencia en comparación con la ubicación estándar de VMs.

Implementar un modelo de seguridad de confianza cero para microservicios, que requiera identidad fuerte, comunicación cifrada (mTLS) y autorización granular.

→Desplegar Anthos Service Mesh. Habilitar mTLS automático para toda la comunicación entre servicios. Usar recursos `AuthorizationPolicy` para definir la comunicación permitida.

Por qué: Una service mesh desacopla la seguridad de la red subyacente, proporcionando identidad de carga de trabajo, mTLS transparente y autorización L7, que son pilares fundamentales de una arquitectura de confianza cero.

Las cargas de trabajo (VMs, pods de GKE) sin IPs públicas necesitan una IP de origen estable y predecible para conexiones salientes a APIs externas que utilizan listas de permitidos.

→Desplegar Cloud NAT. Usar la opción "asignación manual de IP NAT" y asignar direcciones IP externas estáticas reservadas al gateway NAT.

Por qué: Cloud NAT con asignación manual proporciona un pool compartido de IPs estáticas de salida. Esto desacopla la carga de trabajo de la IP, permitiendo escalar sin necesidad de actualizar las listas de permitidos externas.

El VPC peering está establecido pero las VMs no pueden comunicarse entre VPCs emparejadas.

→Verificar que las reglas de firewall en *ambas* VPCs permitan el tráfico de entrada desde el rango IP de la otra VPC. La conexión de peering solo establece el enrutamiento; no crea implícitamente permisos de firewall.

Por qué: Un error común es asumir que el peering abre los puertos del firewall. La regla implícita de denegación de entrada bloquea el tráfico hasta que se crea una regla de permiso explícito.

En una Shared VPC, otorgar a un equipo/proyecto de servicio permiso para usar solo una subred específica, no toda la VPC.

→En el proyecto host, otorgar el rol IAM `compute.networkUser` a la identidad del proyecto de servicio (por ejemplo, cuenta de servicio, grupo) a nivel de recurso de subred.

Por qué: Los roles IAM se pueden delimitar a recursos específicos. Aplicar `compute.networkUser` a nivel de subred impone el principio de privilegio mínimo, permitiendo el uso solo de esa subred.

Implementar microsegmentación para una aplicación de múltiples niveles (por ejemplo, web, aplicación, base de datos) en Compute Engine.

→Asignar network tags a las VMs según su nivel (por ejemplo, `web-server`). Crear reglas de firewall que usen estas tags como especificadores de origen y destino.

Por qué: Las tags proporcionan una alternativa flexible y escalable a las reglas basadas en IP. La política de firewall es independiente del número o IPs de las VMs en un nivel.

Capturar metadatos de tráfico para cumplimiento/auditoría mientras se minimiza el volumen de logs y los costos de almacenamiento.

→Habilitar VPC Flow Logs con un intervalo de agregación más largo (por ejemplo, 10 minutos), una tasa de muestreo reducida (por ejemplo, 0.5) y filtrado de metadatos para excluir campos innecesarios.

Por qué: La configuración predeterminada genera una cantidad masiva de datos. Ajustar estos parámetros reduce significativamente el costo al tiempo que proporciona suficiente visibilidad para la mayoría de los casos de uso de auditoría.

Ofrecer una aplicación global con baja latencia, enrutando a los usuarios al backend saludable más cercano con conmutación por error automática.

→Utilizar un Global External Application Load Balancer (o TCP/SSL Proxy LB para no-HTTP). Configurar servicios de backend/NEGs en múltiples regiones. Utilizar red Premium Tier.

Por qué: La IP anycast del balanceador de carga dirige a los usuarios al PoP de borde de Google más cercano. El tráfico luego viaja a través de la red troncal privada de Google al backend saludable más cercano para un rendimiento óptimo.

Referencia↗

Enrutar el tráfico interno basado en la ruta URL o el nombre de host, con terminación SSL, accesible solo dentro de la VPC o desde redes on-prem.

→Utilizar un Regional Internal Application Load Balancer. Configurar un mapa de URL para dirigir el tráfico basado en reglas de host/ruta. Requiere una subred de solo proxy.

Por qué: Este es el balanceador de carga interno L7 gestionado de Google. Proporciona características de enrutamiento avanzadas no disponibles con el L4 Internal Passthrough Network LB.

Utilizar Cloud CDN para cachear y servir contenido privado o específico del usuario sin hacerlo público.

→Habilitar Cloud CDN en un backend privado (por ejemplo, bucket de GCS). Generar Cloud CDN Signed URLs o Signed Cookies en su aplicación para otorgar a los usuarios acceso temporal y autenticado.

Por qué: Las Signed URLs/Cookies proporcionan un token seguro que Cloud CDN valida antes de servir un objeto cacheado, aprovechando el caching de borde mientras mantiene un estricto control de acceso.

Habilitar la resolución DNS bidireccional entre una red on-prem y una VPC de GCP.

→1) On-prem resuelve GCP: Crear una política de servidor entrante de Cloud DNS. Configurar el DNS on-prem para reenviar a las IPs del reenviador entrante. 2) GCP resuelve on-prem: Crear una zona de reenvío de Cloud DNS que apunte a los servidores DNS on-prem.

Por qué: Esta configuración estándar de dos partes proporciona una resolución de nombres privada y sin interrupciones para entornos híbridos, un componente crítico para la interoperabilidad de las aplicaciones.

La tasa de aciertos de caché de Cloud CDN es baja debido a variaciones de URL innecesarias (por ejemplo, parámetros de seguimiento).

→Configurar una política de clave de caché personalizada para el servicio de backend. Excluir parámetros de consulta, cookies y encabezados no esenciales de la clave de caché.

Por qué: Por defecto, la URL completa es la clave de caché. Normalizar la clave excluyendo parámetros irrelevantes previene la fragmentación de la caché y mejora drásticamente la tasa de aciertos.

Resolver un nombre DNS a una IP interna para clientes internos y una IP pública para clientes externos.

→Crear una zona privada de Cloud DNS para el dominio (visible para su VPC) con el registro IP interno. Crear una zona pública de Cloud DNS coincidente con el registro IP público.

Por qué: Cloud DNS sirve automáticamente la respuesta de la zona privada a los clientes dentro de la VPC autorizada, y la respuesta de la zona pública a todos los demás.

Una aplicación interna en una región necesita ser accesible por clientes (VMs, on-prem) en otras regiones.

→Habilitar la opción "Global Access" en el Internal TCP/UDP Load Balancer o en la regla de reenvío del Internal Application Load Balancer.

Por qué: Por defecto, los LBs internos son regionales. Global Access los hace accesibles desde cualquier región dentro de la red VPC, simplificando las arquitecturas de servicios internos multi-región.

Establecer conectividad de alta disponibilidad (SLA del 99.99%), alto ancho de banda (más de 10G) entre on-prem y GCP.

→Provisionar un mínimo de cuatro conexiones Dedicated Interconnect, dos en una metropolitana y dos en otra, con cada par metropolitano en diferentes dominios de disponibilidad de borde. Configurar BGP.

Por qué: La redundancia a través de áreas metropolitanas separadas y dominios de fallo (edge availability domains) es necesaria para el SLA del 99.99%.

Referencia↗

Necesita una conexión híbrida cifrada, fiable (SLA del 99.9% o 99.99%) y de rápido despliegue con ancho de banda moderado (menos de 6 Gbps).

→Utilizar HA VPN con BGP para enrutamiento dinámico. Para un SLA del 99.99%, usar dos gateways HA VPN. Para un SLA del 99.9%, usar un solo gateway con dos túneles.

Por qué: HA VPN es más rápida de configurar que Interconnect, proporciona un SLA robusto y ofrece suficiente ancho de banda para muchos casos de uso, lo que la convierte en la opción predeterminada para conexiones no físicas.

Cifrar todo el tráfico que atraviesa un enlace Dedicated o Partner Interconnect para cumplimiento normativo.

→Configurar HA VPN sobre Interconnect. Crear túneles HA VPN que utilicen los adjuntos VLAN de Interconnect para su transporte subyacente.

Por qué: Este patrón combina el alto ancho de banda y la baja latencia de Interconnect con el cifrado IPsec de HA VPN, proporcionando lo mejor de ambos mundos.

Establecer conectividad dedicada, privada y de alto ancho de banda entre GCP y otro proveedor de la nube importante (AWS, Azure, OCI).

→Utilizar Cross-Cloud Interconnect. Provisionar una conexión física dedicada entre la red de Google y la red del otro proveedor de la nube. Configurar BGP con Cloud Router.

Por qué: Proporciona una ruta directa, respaldada por SLA y de baja latencia entre nubes, evitando la internet pública y el rendimiento variable de las VPNs.

Una red on-prem conectada a través de Interconnect a una región de GCP necesita acceder a recursos en todas las demás regiones de GCP.

→Habilitar el modo de enrutamiento dinámico "Global" en la VPC. El Cloud Router anunciará entonces rutas para todas las subredes de la VPC, no solo las de su región local.

Por qué: El enrutamiento global permite que un único punto de conexión híbrida sirva como acceso a toda la red global de Google, simplificando el acceso multi-región.

Influir en la selección de la ruta del tráfico sobre conexiones híbridas redundantes (VPN/Interconnect) utilizando BGP.

→Para influir en el tráfico de GCP a on-prem, hacer que on-prem anuncie rutas más específicas o use un AS_PATH más corto para la ruta preferida. Para influir en el tráfico de on-prem a GCP, anunciar desde Cloud Router con un valor MED más bajo para la ruta preferida.

Por qué: La selección de ruta BGP sigue un algoritmo claro. La coincidencia de prefijo más larga es clave para el tráfico saliente, mientras que MED influye en las decisiones de tráfico entrante.

Configurar una conmutación por error activa/pasiva entre una Dedicated Interconnect principal y una HA VPN de respaldo.

→Usar BGP en ambos. En Cloud Router, anunciar rutas sobre Interconnect con una prioridad base más baja (por ejemplo, 100) y sobre VPN con una prioridad base más alta (por ejemplo, 200).

Por qué: GCP prefiere las rutas BGP con un valor de prioridad más bajo (mayor preferencia). El tráfico utiliza el Interconnect principal. Tras un fallo, sus rutas son retiradas y las rutas VPN de respaldo se activan.

Prevenir la exfiltración de datos de servicios sensibles de Google Cloud (por ejemplo, BigQuery, GCS), asegurando el acceso solo desde redes autorizadas.

→Implementar VPC Service Controls. Crear un perímetro de servicio alrededor de proyectos con datos sensibles. Configurar niveles de acceso para definir fuentes autorizadas (rangos IP, estado del dispositivo, identidad).

Por qué: VPC-SC crea un límite de red virtual alrededor de los servicios gestionados por Google, bloqueando el acceso desde fuera del perímetro incluso con credenciales válidas. Un control crítico de gobernanza de datos.

Referencia↗

Aplicar reglas de firewall de línea base consistentes e inquebrantables en toda una organización, permitiendo al mismo tiempo la personalización a nivel de proyecto.

→Implementar políticas de firewall jerárquicas a nivel de organización o carpeta. Colocar aquí las reglas críticas. Usar la acción `goto_next` para delegar la evaluación a políticas de nivel inferior.

Por qué: Las políticas jerárquicas se evalúan antes que las reglas a nivel de VPC y no pueden ser modificadas por los propietarios de proyectos, lo que garantiza una gobernanza centralizada. `goto_next` proporciona flexibilidad.

Proteger una aplicación web de las vulnerabilidades OWASP Top 10 y aplicar limitación de tasa por IP de cliente.

→Adjuntar una política de seguridad de Cloud Armor al Global External Application LB. Aplicar reglas WAF preconfiguradas (por ejemplo, `sqli-v3.3-stable`) y añadir una regla basada en tasa.

Por qué: Cloud Armor proporciona seguridad de borde. Las reglas WAF preconfiguradas ofrecen protección gestionada, mientras que las reglas basadas en tasa mitigan los ataques DoS y de fuerza bruta.

Implementar seguridad de red granular a nivel de pod dentro de un cluster de GKE basada en etiquetas.

→Habilitar la aplicación de Network Policy en el cluster de GKE. Crear recursos `NetworkPolicy` de Kubernetes que definan reglas de entrada/salida para pods usando selectores de etiquetas.

Por qué: Kubernetes NetworkPolicy es la forma nativa de implementar microsegmentación a nivel de pod, ofreciendo más granularidad que las reglas de firewall de VPC que operan a nivel de nodo.

Inspeccionar todo el tráfico entre VPCs o de VPC a internet utilizando un firewall/NVA de terceros centralizado.

→Crear una topología hub-and-spoke. Desplegar el NVA(s) en una VPC hub. Configurar rutas personalizadas en los spokes que dirijan el tráfico a un Internal Load Balancer en el hub como el siguiente salto.

Por qué: Este patrón fuerza el tráfico a través de un punto de inspección central. El ILB proporciona una IP de siguiente salto estable y de alta disponibilidad para los NVAs.

Proporcionar acceso seguro, basado en identidad y de confianza cero para usuarios a aplicaciones web internas o VMs sin usar una VPN.

→Para aplicaciones web, habilitar IAP en un servicio de backend de External HTTPS LB. Para SSH/RDP, usar IAP para el reenvío TCP. Otorgar roles IAM de IAP apropiados a los usuarios.

Por qué: IAP mueve el control de acceso del perímetro de la red a la identidad del usuario, autenticando y autorizando cada solicitud. Es un componente central del modelo de confianza cero BeyondCorp de Google.

Implementar prevención de amenazas (IDS/IPS) para tráfico entre VPCs o de VPC a internet, incluyendo detección de malware e inspección TLS.

→Utilizar Cloud NGFW. Asociar una política de firewall con la VPC, crear reglas con perfiles de seguridad para la prevención de amenazas y, opcionalmente, habilitar la inspección TLS.

Por qué: Cloud NGFW es el servicio de firewall distribuido y gestionado de Google que proporciona capacidades avanzadas de inspección L7 de Palo Alto Networks, integrado directamente en la VPC.

Inspeccionar, registrar y controlar centralmente todo el tráfico de salida de una VPC hacia internet para seguridad y cumplimiento.

→Desplegar Secure Web Proxy. Configurar políticas de seguridad para filtrado de URL e inspección TLS. Enrutar el tráfico de las subredes al proxy usando rutas personalizadas.

Por qué: Esta es la solución gestionada de Google para la salida segura, proporcionando visibilidad y control L7 sin requerir flotas de proxy autogestionadas.

Diagnosticar rápidamente un fallo de conectividad entre dos endpoints dentro de GCP (por ejemplo, VM a VM, VM a Cloud SQL).

→Usar las Pruebas de Conectividad de Network Intelligence Center. Especificar el origen y el destino, y analizará toda la ruta configurada en busca de problemas.

Por qué: Esta herramienta no intrusiva proporciona un análisis definitivo de la ruta, identificando el punto exacto de fallo (firewall, ruta, etc.) mucho más rápido que la inspección manual.

Una sesión BGP sobre una conexión híbrida se reinicia intermitentemente ("flapping").

→Verificar una inconsistencia en los temporizadores de keepalive/hold de BGP. Si los temporizadores expiran bajo carga, aumentarlos (por ejemplo, 60s keepalive, 180s hold). Además, verificar la configuración de MTU y habilitar BFD.

Por qué: Los temporizadores desajustados o excesivamente agresivos son una causa común de "flapping" de BGP, ya que la congestión transitoria de la red puede retrasar los paquetes keepalive más allá del tiempo de hold.

Investigar informes de aumento de latencia para el tráfico entre regiones de GCP.

→Usar el Performance Dashboard de Network Intelligence Center para ver métricas históricas y en tiempo real de latencia y pérdida de paquetes entre todos los pares de zonas de GCP.

Por qué: Esta herramienta proporciona visibilidad directa del rendimiento de la red troncal de Google, ayudando a distinguir entre un problema de aplicación y un problema de infraestructura de red.

Las VMs que usan Cloud NAT experimentan fallos intermitentes en las conexiones salientes, y los logs de NAT muestran caídas de `OUT_OF_RESOURCES`.

→Esto es probablemente agotamiento de puertos NAT. Aumentar el número de IPs NAT asignadas, aumentar los "Puertos mínimos por instancia de VM", y/o habilitar la Asignación Dinámica de Puertos.

Por qué: Altas tasas de conexión desde muchas VMs pueden agotar el pool de puertos de origen asignado por IP NAT. Asignar más recursos es la solución requerida.