De AWS a Google Cloud: modelo de recursos y equivalencias

Ya sabes diseñar en AWS. Google Cloud resuelve los mismos problemas, pero dibuja las fronteras en otros lugares. Tres diferencias cambian tus diseños desde el primer día: la frontera de aislamiento es el proyecto, los permisos se heredan hacia abajo por la jerarquía, y muchos recursos de red son globales en vez de regionales. Esta lección te da el mapa para traducir lo que sabes sin cargar supuestos de AWS que aquí no aplican.

La jerarquía: organización, carpetas y proyectos

El nodo organización nace de un dominio de Google Workspace o Cloud Identity. Debajo cuelgan carpetas, que se pueden anidar, y de ellas los proyectos. Cada recurso (una VM, un bucket, una base de datos) pertenece a exactamente un proyecto. Un proyecto tiene tres identificadores: el project ID (único en todo Google Cloud e inmutable), el nombre (editable) y el número (asignado por Google).

El proyecto cumple el papel de la cuenta de AWS: aísla recursos, cuotas, APIs habilitadas y permisos. Pero cuesta mucho menos crearlo: es una llamada a la API, sin correo raíz ni contraseña. Por eso lo normal es tener un proyecto por aplicación y por entorno, y muchos más proyectos que cuentas tendrías en AWS. La comparación con AWS Organizations:

# Un proyecto nuevo dentro de la carpeta de producción
gcloud projects create pagos-prod-7f3a \
  --folder=123456789012 --name="Pagos prod"

# Sin cuenta de facturación vinculada, casi nada se puede crear
gcloud billing projects link pagos-prod-7f3a \
  --billing-account=0X0X0X-0X0X0X-0X0X0X

# Cada API se habilita por proyecto, antes de usarla
gcloud services enable compute.googleapis.com run.googleapis.com \
  sqladmin.googleapis.com --project=pagos-prod-7f3a

# Permiso a un grupo, en el proyecto (se hereda a todos sus recursos)
gcloud projects add-iam-policy-binding pagos-prod-7f3a \
  --member="group:equipo-pagos@ejemplo.com" --role="roles/run.developer"

Políticas de organización no son SCP

Aquí está la primera trampa. Una SCP limita qué acciones puede hacer cualquier identidad de una cuenta. Una política de organización limita qué configuración pueden tener los recursos, sin importar quién los cree. Ejemplos: gcp.resourceLocations restringe en qué regiones se crean recursos, compute.vmExternalIpAccess prohíbe IP públicas en VMs, compute.skipDefaultNetworkCreation evita la red por defecto e iam.disableServiceAccountKeyCreation bloquea las llaves de cuentas de servicio.

Se fijan en la organización, una carpeta o un proyecto y se heredan, aunque un nivel inferior puede reemplazarlas si tiene permiso. Hay restricciones de lista, booleanas, administradas por Google y personalizadas, y un modo de prueba (dry run) que solo registra violaciones. No son retroactivas: un recurso que ya incumple queda marcado, pero nadie lo apaga.

Lo más parecido a una SCP son las políticas de denegación de IAM (IAM deny policies): se adjuntan a la organización, a una carpeta o a un proyecto, se heredan y se evalúan antes que cualquier permiso concedido.

IAM de Google Cloud contra IAM de AWS

En AWS escribes políticas JSON y se las pegas a una identidad o a un recurso. En Google Cloud el modelo es una lista de asignaciones: quién (principal) recibe qué rol sobre qué recurso. Esa lista es la allow policy del recurso, y vive en el recurso: en la organización, una carpeta, un proyecto o un recurso concreto como un bucket o un secreto.

Dos diferencias pesan en el diseño. Primera: los permisos se suman al bajar por la jerarquía. Si alguien tiene un rol en una carpeta, lo tiene en todos los proyectos y recursos de esa carpeta, y ninguna allow policy de abajo se lo puede quitar; solo una política de denegación. Segunda: una cuenta de servicio no se asume como un rol de AWS con sts:AssumeRole; se adjunta a la VM, al servicio de Cloud Run o al pod, o se suplanta. Sus llaves JSON son el equivalente a las access keys de un usuario de IAM: evítalas. Para que una carga en AWS llame a Google Cloud sin llaves, usa Workload Identity Federation; lo verás en Conectar AWS y Google Cloud.

Regiones, zonas y el alcance de cada recurso

Una región se llama, por ejemplo, us-central1, y sus zonas us-central1-a, us-central1-b y así. La mayoría de regiones tiene tres zonas. Algunos servicios ofrecen multirregiones (us, eu o europe, asia) o configuraciones con nombre propio, como nam5 en Firestore. Como en el alcance de los servicios de AWS, cada recurso es global, regional o zonal, pero los límites no caen donde esperas:

Que la VPC y los firewall sean globales simplifica mucho la red multirregión, pero también agranda el radio de un error: un cambio en una regla puede afectar a todas las regiones a la vez. Lo verás en Redes en Google Cloud.

La tabla de equivalencias

Primero, el mapa rápido: cada servicio de Google Cloud junto a su pariente más cercano en AWS.

• Máquinas virtuales

  Compute Engine⇄Amazon EC2

• Kubernetes

  GKE⇄EKS

• Contenedores sin servidores

  Cloud Run⇄AWS Fargate

• Funciones

  Cloud Run functions⇄AWS Lambda

• Objetos

  Cloud Storage⇄S3

• Discos de bloque

  Persistent Disk⇄EBS

• Archivos compartidos

  Filestore⇄EFS

• Relacional administrada

  Cloud SQL⇄RDS

• PostgreSQL de alto rendimiento

  AlloyDB⇄Aurora

• Relacional global

  Spanner⇄Aurora DSQL

• Documentos y clave-valor

  Firestore⇄DynamoDB

• Caché en memoria

  Memorystore⇄ElastiCache

• Mensajería

  Pub/Sub⇄SNS + SQS

• Bus de eventos

  Eventarc⇄EventBridge

• Orquestación

  Workflows⇄Step Functions

• Red privada

  VPC (global)⇄VPC (regional)

• Balanceo

  Cloud Load Balancing⇄ELB

• DNS

  Cloud DNS⇄Route 53

• CDN

  Cloud CDN⇄CloudFront

• WAF y DDoS

  Cloud Armor⇄WAF + Shield

• Identidad y permisos

  IAM⇄IAM

• Llaves

  Cloud KMS⇄KMS

• Secretos

  Secret Manager⇄Secrets Manager

• Métricas y alarmas

  Cloud Monitoring⇄CloudWatch

• Auditoría

  Cloud Audit Logs⇄CloudTrail

• Imágenes de contenedor

  Artifact Registry⇄ECR

• Analítica

  BigQuery⇄Redshift, Athena

La correspondencia rara vez es exacta. La tabla completa agrega lo que cambia al traducir: