Redes en Google Cloud: VPC global, balanceo, DNS y Cloud Armor

En AWS piensas la red región por región: una VPC por región, subredes atadas a una zona y peering o Transit Gateway para unirlas. En Google Cloud una sola VPC cruza el planeta, las subredes son regionales y el balanceador de entrada puede ser global. Menos piezas, pero con trampas nuevas. Esta lección recorre la VPC, el firewall, la salida privada, el balanceo y la entrada con Cloud DNS, Cloud CDN y Cloud Armor.

VPC global, subredes regionales

Una VPC de Google Cloud no pertenece a ninguna región. Sus rutas y reglas de firewall son globales; sus subredes son regionales y cada una cubre todas las zonas de su región. Hay dos modos. El modo automático crea una subred por región dentro de 10.128.0.0/9, y la red default de cada proyecto nuevo es de ese tipo, con reglas permisivas. El modo personalizado no crea nada: tú eliges regiones y rangos. Para producción usa siempre modo personalizado; el automático choca con cualquier otra red que use esos rangos, incluida tu VPC de AWS. Puedes pasar de automático a personalizado, nunca al revés.

# VPC en modo personalizado: sin subredes automáticas
gcloud compute networks create red-prod --subnet-mode=custom \
  --bgp-routing-mode=global

# Una subred por región, con rangos secundarios para pods y servicios de GKE
gcloud compute networks subnets create prod-use1 --network=red-prod \
  --region=us-east1 --range=10.40.0.0/20 \
  --secondary-range=pods=10.44.0.0/14,servicios=10.48.0.0/20 \
  --enable-private-ip-google-access

# Salida a internet sin IP públicas: Cloud Router + Cloud NAT (por región)
gcloud compute routers create rt-use1 --network=red-prod --region=us-east1
gcloud compute routers nats create nat-use1 --router=rt-use1 \
  --region=us-east1 --auto-allocate-nat-external-ips \
  --nat-all-subnet-ip-ranges

Con --bgp-routing-mode=global, un Cloud Router de una región anuncia y aprende rutas para toda la VPC. Esto importa cuando conectes con AWS: una VPN en una región puede servir a subredes de otras. El plan de direcciones sin solapes entre nubes está en Conectar AWS y Google Cloud.

Firewall: reglas, políticas jerárquicas y de red

Las reglas de firewall de VPC son con estado, como un security group, pero admiten permitir y denegar, tienen prioridad numérica (0 es la más alta, 65535 la más baja) y se aplican a las VMs que elijas por etiqueta de red, por cuenta de servicio o a todas. Cada VPC trae dos reglas implícitas: denegar toda entrada y permitir toda salida.

Encima hay dos capas de políticas. Las políticas jerárquicas de firewall se adjuntan a la organización o a una carpeta y se evalúan primero: el equipo de seguridad fija lo que nadie puede abrir y delega el resto con goto_next. Las políticas de firewall de red, globales o regionales, agrupan reglas para una VPC y aceptan tags seguros gobernados por IAM, más confiables que las etiquetas de red que cualquier editor de la VM puede cambiar.

Salida privada: Cloud NAT, Private Google Access y Private Service Connect

Cloud NAT no es una máquina en el camino del tráfico, como el NAT Gateway por zona de AWS. Es una configuración regional sobre un Cloud Router que reparte la traducción entre las VMs, sin un punto único de falla dentro de la región. Necesitas uno por región que tenga cargas privadas.

Private Google Access se activa por subred y deja que VMs sin IP externa lleguen a las APIs de Google. Se parece a los gateway endpoints de S3 y DynamoDB, pero cubre casi todas las APIs. Private Service Connect es el equivalente de PrivateLink: un endpoint con IP interna en tu VPC que llega a las APIs de Google, a servicios administrados como Cloud SQL o a un servicio publicado por otro equipo mediante un service attachment, sin unir las redes ni preocuparte por rangos solapados.

Para compartir red hay dos caminos. VPC Network Peering une dos VPC y, como en AWS, no es transitivo. Shared VPC se parece a compartir subredes con AWS RAM: un proyecto host es dueño de la VPC y los proyectos de servicio crean sus recursos en subredes compartidas. La red queda en manos de un equipo y las aplicaciones en las de otros, y el permiso se da por subred con roles/compute.networkUser. Solo funciona dentro de la misma organización. Para topologías de centro y radios existe Network Connectivity Center, el pariente de Transit Gateway.

1. 1

   Proyecto host por entorno

   Un proyecto de red para producción y otro para el resto, cada uno con su VPC en modo personalizado.
2. 2

   Subredes por región

   Rangos que no se solapen con tus VPC de AWS ni con otras redes, con rangos secundarios si habrá GKE.
3. 3

   Guardarraíles de firewall

   Política jerárquica en la carpeta: denegar SSH y RDP desde internet, permitir los rangos de health check de Google.
4. 4

   Salida

   Cloud Router y Cloud NAT en cada región; Private Google Access en cada subred.
5. 5

   Servicios privados

   Endpoints de Private Service Connect para Cloud SQL, AlloyDB y servicios internos publicados.
6. 6

   Proyectos de servicio

   Adjúntalos al host y concede roles/compute.networkUser solo en las subredes que necesiten.

Cloud Load Balancing: qué balanceador elegir

Hay dos familias. Los Application Load Balancers trabajan en capa 7 (HTTP y HTTPS). Los Network Load Balancers trabajan en capa 4 y pueden ser proxy (terminan la conexión) o passthrough (dejan pasar el paquete y conservan la IP del cliente). Cada uno existe en variantes externas e internas, regionales o globales. La estrella es el Application Load Balancer externo global: una sola IP anycast anunciada desde el borde de Google, TLS terminado cerca del usuario y backends en varias regiones. En AWS necesitarías un ALB por región más Global Accelerator, o CloudFront delante.

Los backends son grupos de instancias o NEG (network endpoint groups): zonales para pods de GKE, serverless para Cloud Run, de internet o híbridos para destinos fuera de Google Cloud. Un NEG híbrido o de internet puede apuntar a un servicio en AWS, útil durante una migración. Repasa los equivalentes en balanceadores de carga.

El nivel de red cuenta. En Premium el tráfico entra y sale por el borde de Google más cercano al usuario y viaja por la red troncal de Google. En Standard entra y sale por internet cerca de la región, y solo admite balanceadores regionales. AWS no tiene un equivalente directo; lo más parecido es la diferencia entre internet pública y Global Accelerator.

Entrada: Cloud DNS, Cloud CDN y Cloud Armor

Cloud DNS ofrece zonas públicas y privadas (visibles solo desde las VPC que elijas), zonas de reenvío y de peering, que cumplen el papel de las reglas de Route 53 Resolver. Sus políticas de enrutamiento son tres: round robin ponderado, geolocalización y conmutación (activo y respaldo). Con health checks, una zona privada vigila balanceadores internos y una zona pública vigila endpoints externos por TCP, HTTP o HTTPS, desde tres regiones de sondeo. Si todos los endpoints fallan, Cloud DNS los devuelve todos, igual que Route 53.

Cloud CDN no es una distribución aparte como CloudFront: es una opción del backend del Application LB externo. Cloud Armor se adjunta como política de seguridad al backend y combina WAF (reglas preconfiguradas basadas en el OWASP Core Rule Set), limitación de tasa, listas de IP y geografía, y protección DDoS de capa 3 y 4 siempre activa. Cloud Armor Enterprise agrega Adaptive Protection, que aprende el tráfico normal y sugiere reglas ante ataques de capa 7, y protección avanzada para balanceadores de red y VMs con IP pública: es el equivalente de Shield Advanced.