GCP para ingenieros de AWS: cómo se traducen tus instintos de AWS (y dónde fallan)

Si dominas AWS y ahora te enfrentas a Google Cloud, la buena noticia es que aproximadamente el 80% de tus instintos se transfieren directamente: hay una jerarquía para organizar las cosas, una forma de conceder acceso basada en roles, una solución OIDC para CI sin claves, y un proceso de arranque para "inicializar tu state backend". La mala noticia es el otro 20% - y se concentra en algunos puntos de alto tráfico donde hacer las cosas a la manera de AWS produce una denegación confusa en lugar de un error obvio. Esta publicación es la capa de traducción: las mismas tareas que realizas en AWS, hechas en GCP, con las trampas señaladas.

La versión corta, si solo lees un párrafo: La jerarquía de GCP (organization -> folder -> project -> resource) se mapea limpiamente a AWS Organizations -> OU -> account -> resource, pero tres cosas rompen tu memoria muscular. IAM es una política de solo permitir vinculada al árbol de recursos y heredada hacia abajo - no hay una política adjunta a un usuario. Las API de servicio de un project comienzan todas desactivadas, y nada funciona hasta que habilitas cada una. Y no asumes roles, sino que suplantas service accounts, que son recursos con su propia política de acceso. Todo lo que sigue expande estos puntos.

El mayor cambio: los permisos residen en el árbol, no en las identidades

En AWS, el modelo mental es "adjuntar una política a una identidad". Creas un usuario o un rol, le adjuntas JSON, y el permiso viaja con el principal. Existen políticas de recursos, pero la política adjunta a la identidad es el centro de gravedad.

GCP invierte eso. Una política IAM es un conjunto de vinculaciones - pares (member, role) - adjuntas a un nodo en la jerarquía de recursos (organization, folder, project, o un recurso individual). La política reside en el elemento al que se accede, no en la identidad que realiza el acceso. Tu acceso efectivo en cualquier punto es la unión de cada vinculación heredada desde la raíz hasta ese nodo. Concede roles/compute.admin a un grupo a nivel de folder y cada project bajo ese folder lo hereda.

Si has tocado Azure RBAC esto te resultará familiar - es un rol en un ámbito con herencia descendente. La regla que te salva:

Cuando GCP deniega algo, deja de buscar "la política en el usuario". Busca la vinculación en la org, folder, project o resource - y recuerda que se hereda hacia abajo, por lo que la concesión importante puede estar tres niveles más arriba.

Algunas especificidades que difieren de AWS:

• Los roles vienen en tres grados. Los roles primitivos (roles/owner, roles/editor, roles/viewer) son el trío legado de grano grueso - evítalos en entornos reales. Los roles predefinidos son los roles por servicio de grano fino que realmente deberías usar (roles/storage.objectViewer, roles/compute.instanceAdmin.v1, ...). Los roles personalizados son los que puedes crear cuando el conjunto predefinido es demasiado amplio.
• El modelo base es aditivo y de solo permitir. No hay un Effect: Deny por declaración tejido en cada política como lo hay en AWS. El acceso efectivo es simplemente la unión de los permisos.
• La denegación es una capa separada. Cuando sí necesitas un "nunca, independientemente de las concesiones", escribes una política de denegación de IAM - un objeto distinto adjunto a org/folder/project que se evalúa antes de los permisos. Es lo más parecido a una declaración Deny en línea, pero está deliberadamente fuera de banda.
• Los guardarraíles son una tercera cosa: el Organization Policy Service. Restricciones como constraints/compute.vmExternalIpAccess o constraints/iam.disableServiceAccountKeyCreation son el análogo de GCP de los SCP. Se adjuntan a nivel de org/folder/project, se heredan hacia abajo y restringen lo que puede existir o configurarse en lugar de quién puede llamar a qué. Piensa en "guardarraíl con forma de SCP", no en "rol IAM".

Así, donde AWS te ofrece una gramática de permitir/denegar dentro de IAM, GCP distribuye la tarea entre vinculaciones de permitir, políticas de denegación y restricciones de políticas de organización. Mismos resultados, tres mecanismos.

Todo es un project - y sus API comienzan desactivadas

El project es la unidad fundamental de GCP. Es el análogo aproximado de una cuenta de AWS: un límite de aislamiento, un alcance de IAM y un objetivo de facturación, todo a la vez. Pero un project es mucho más ligero que una cuenta - barato de crear, fácil de eliminar, diseñado para ser creado por docenas. El patrón idiomático es un project por carga de trabajo por entorno (app-qa, app-prod), no un puñado de cuentas compartidas divididas por etiquetas.

Tres cosas sobre los projects no tienen un equivalente claro en AWS:

• Un project tiene tres identificadores, y las diferencias son importantes. El project ID es una cadena globalmente única, elegida por humanos e inmutable (acme-app-prod-7f3a) - es lo que pones en casi todos los comandos y rutas de recursos. El project number es un entero globalmente único que asigna GCP. El display name es mutable y cosmético. Elige el ID con cuidado; nunca podrás cambiarlo.
• Las API de servicio están desactivadas por defecto. Este es el error más común del primer día. Antes de poder crear una VM, habilitas compute.googleapis.com; antes de un bucket, storage.googleapis.com; y así sucesivamente, por project. Tu primera "denegación" en GCP no suele ser un rol IAM faltante en absoluto - es API [compute.googleapis.com] not enabled on project. En AWS, los servicios simplemente están ahí; en GCP, cada project es una pizarra en blanco y activas exactamente la superficie que pretendes usar. (En Terraform esto es google_project_service; desde la CLI, gcloud services enable.)
• Los projects son el radio de explosión natural y el límite de cuota. Las cuotas, los presupuestos y la mayoría de los valores predeterminados son por project, por lo que iniciar un nuevo project para un experimento es el movimiento normal y económico, no la ceremonia que es una cuenta de AWS.

Service accounts: suplantas, no asumes

En AWS, un rol es un conjunto de permisos que un principal asume a través de STS, limitado por una política de confianza. En GCP, el caballo de batalla equivalente es la service account (SA), y funciona de una manera diferente que confunde a todo ingeniero de AWS.

Una service account es tanto una identidad como un recurso. Tiene un correo electrónico (deployer@acme-app-prod.iam.gserviceaccount.com), reside dentro de un project, y - crucialmente - tiene su propia política IAM que rige quién puede usarla. Esa segunda mitad es la parte sin reflejo de AWS:

• Para actuar como una service account, un principal necesita un rol en la propia SA - roles/iam.serviceAccountTokenCreator (para acuñar tokens de corta duración y suplantarla) o roles/iam.serviceAccountUser (para adjuntarla a un recurso que estás creando, como una VM o un servicio Cloud Run). Esta es la concesión de dos lados que la gente de AWS olvida: dar a tu principal de CI amplios derechos de project es inútil si no puede convertirse en la SA de despliegue.
• Suplantas una SA pidiendo un token (generateAccessToken), no asumiendo un rol con un handshake de política de confianza. El permiso para suplantar reside como una vinculación IAM ordinaria en el recurso SA - no hay un documento de confianza separado.
• Existen las Service account keys y deberías evitarlas en su mayoría. Una clave JSON descargada es una credencial de larga duración y un vector clásico de fuga; muchas organizaciones deshabilitan la creación de claves en toda la organización a través de la restricción mencionada anteriormente. Las alternativas sin clave son las que debes buscar.
• CI sin claves es Workload Identity Federation - la misma idea OIDC que la federación OIDC de AWS. Tus GitHub Actions o carga de trabajo externa presentan un token OIDC, un pool de identidad de carga de trabajo confía en el emisor, y GCP devuelve credenciales de corta duración para una SA. Sin secreto almacenado. (Dentro de GKE, el análogo es Workload Identity, que vincula una Kubernetes service account a una Google service account - la contraparte directa de IRSA de AWS.)

La traducción en una línea: un rol de AWS que asumes mediante una política de confianza se convierte en una service account de GCP que suplantas mediante una vinculación de creador de tokens en la SA.

El dominio de identidad: Cloud Identity, Workspace y la org

GCP separa la identidad de los recursos, pero de forma mucho más suave que Azure. El nodo organization se crea contra un dominio verificado que es propiedad de una cuenta de Cloud Identity o Google Workspace. Ese directorio - usuarios y grupos - se administra en la consola de administración (admin.google.com), una superficie diferente de la consola de Cloud donde gestionas los recursos.

• Los usuarios y grupos se crean en el directorio; el acceso se concede en IAM. No creas un "usuario de GCP" de la misma manera que creas un usuario IAM en AWS. El humano existe en Cloud Identity/Workspace (o está federado desde tu IdP), y los referencias - idealmente como un grupo - en las vinculaciones IAM en el árbol de recursos. La mejor práctica es vincular a grupos, nunca a usuarios individuales.
• No existe un almacén de "usuarios IAM" independiente como el de AWS. Los IdP externos (Okta, Entra ID, etc.) se federan en Cloud Identity; esa es la norma para el acceso de la fuerza laboral.
• Dos errores comunes a memorizar: los miembros especiales allUsers (literalmente cualquier persona en internet, sin autenticar) y allAuthenticatedUsers (cualquier persona con cualquier cuenta de Google). Vincular un rol a cualquiera de ellos es cómo los buckets se hacen públicos accidentalmente. Trátalos de la misma manera que tratas un Principal: "*" en una política de bucket de S3.

La analogía aproximada: la organization más su dominio de Cloud Identity es aproximadamente "una AWS Organization fusionada con el directorio de IAM Identity Center" - pero el trabajo diario con los recursos se realiza a través de vinculaciones IAM en el árbol, no a través de políticas adjuntas a la identidad.

La facturación es un objeto separado que vinculas a los projects

Una billing account en GCP es un recurso propio - no es un nodo en la jerarquía org -> folder -> project. Los projects se vinculan a una billing account (cada project a exactamente una), y una única billing account puede financiar muchos projects.

• Tiene su propio IAM. roles/billing.admin, roles/billing.user, roles/billing.creator residen en la billing account, separados de tus roles de recursos. En particular, para adjuntar un nuevo project a una billing account necesitas roles/billing.user en esa billing account - los derechos amplios de project por sí solos no serán suficientes.
• "Puedo desplegar" no dice nada sobre "Puedo crear un project con cargos". Para levantar un project que pueda incurrir en cargos necesitas tanto resourcemanager.projectCreator (a nivel de org/folder) como billing.user (en la billing account). Si te falta el segundo, la creación del project tendrá un éxito parcial en un project que en realidad no puede ejecutar nada.

Esto es más suave que la dura pared del plano comercial de Azure - la facturación de GCP está conectada a Cloud IAM, por lo que aparece en las mismas interfaces de gcloud y Terraform en lugar de un mundo completamente separado. Pero sigue siendo un objeto distinto con roles distintos, y es la segunda sorpresa más común de "pero soy un administrador" después de las API no habilitadas.

Nombres, ID y una sorpresa de red

Cada recurso de GCP tiene un nombre de recurso relativo como projects/acme-app-prod/zones/us-central1-a/instances/web-1 (y una forma completamente cualificada //compute.googleapis.com/...). El project ID viaja con cada línea de registro y llamada API - la misma función que la cuenta de un ARN en AWS - así, como en Azure, tus nombres de recursos pueden omitir lo que el project ya codifica. Los mismos nombres cortos pueden repetirse de forma segura en tus projects -dev, -qa y -prod.

El truco de red que vale la pena señalar de antemano, porque viola silenciosamente los instintos de AWS: una red VPC en GCP es un recurso global, y sus subredes son regionales. En AWS, una VPC está limitada a una región; en GCP, una VPC abarca todas las regiones, y se crean subredes regionales dentro de ella. Una única VPC global con subredes regionales es el valor predeterminado, no una configuración exótica multirregión - no recurras al VPC peering para hacer lo que una subred ya te ofrece.

El mapa rápido de AWS -> GCP

Ten esto a mano durante el primer mes:

• Organization -> organization. Misma idea, pero la org de GCP está vinculada a tu dominio de Cloud Identity/Workspace.
• Organizational Unit (OU) -> folder. Nodo de agrupación anidable; los folders pueden contener folders.
• Account -> project. La unidad de aislamiento, IAM y facturación - pero ligera y desechable, hecha por docenas.
• SCP (guardrail) -> Organization Policy constraint en un ámbito de org/folder/project - restringe lo que puede existir o configurarse, se hereda hacia abajo.
• IAM identity-attached policy -> IAM binding (member, role) en un nodo de árbol. No hay política en el usuario; la concesión reside en el recurso y se hereda hacia abajo.
• IAM role you assume (via STS + trust policy) -> service account you impersonate (via a token-creator binding on the SA). Recuerda la concesión de dos lados.
• Explicit Deny statement -> IAM deny policy - un objeto separado, evaluado antes de los permisos.
• IRSA (IAM Roles for Service Accounts) -> Workload Identity (GKE) / Workload Identity Federation (external CI) - la misma idea OIDC, sin claves.
• "The service is just available" -> enable its API per project first (google_project_service). No hay equivalente en AWS.
• ARN in logs -> el resource name (projects/<id>/...); el contexto del project está estructurado, no codificado en el nombre.

Inicializando el estado de Terraform, traducido

Aquí hay un lugar donde tu runbook de AWS casi funciona, y luego falla en el paso cero.

El arranque de AWS que conoces: inicializar un backend de estado en la cuenta de administración (estado local, luego migrar el backend a sí mismo), mantener el estado de los backends por OU en ese backend raíz, y crear cuentas miembro usando sus propios backends. El invariante que lo hace limpio es que siempre puedes arrancar desde la cuenta de administración, porque siempre existe y puede contener un bucket de S3.

GCP rompe ese invariante en su génesis de la misma manera que Azure: el objeto que siempre existe es la organization, pero un nodo de org no puede contener recursos. Un bucket de GCS reside en un project, y un project necesita un padre y (para hacer algo real) un enlace de facturación y API habilitadas. Así, la "cuenta raíz" de GCP es un project semilla que coronas conscientemente - el nombre idiomático es algo como prj-bootstrap o un project semilla de Cloud Foundation Toolkit.

El flujo traducido, cuando la org y una billing account ya existen (el caso común):

1. Un único arranque en frío, para siempre: crea el project semilla imperativamente (gcloud projects create), habilita las API de arranque en él (cloudresourcemanager, cloudbilling, serviceusage, iam, storage), vincula la facturación y crea el bucket de estado de GCS con estado local de Terraform - luego init -migrate-state en ese bucket.
2. Una service account de arranque con roles a nivel de org: concédele resourcemanager.projectCreator, billing.user y tus roles de administrador de org-policy/IAM en el nodo organization, para que pueda crear y gobernar cada project descendente.
3. Todo lo demás es un apply normal: projects, folders y sus recursos adicionales son creados por Terraform suplantando esa SA de arranque, el estado de cada project residiendo bajo un prefix en el único backend de GCS.

Desde cero absoluto, el orden es forzado - project semilla primero, bucket de estado segundo - porque un backend es un bucket de GCS y un bucket necesita un project para residir. Y hay una pequeña arruga de huevo y gallina, al igual que en Azure: el proveedor google necesita un project y API habilitadas para hacer cualquier cosa, así que creas ese primer project y habilitas sus API con una llamada gcloud imperativa, luego lo adoptas en Terraform. (El módulo terraform-google-modules/bootstrap empaqueta exactamente esta danza de project-semilla-más-SA.)

Y aquí es donde GCP es genuinamente más simple que la memoria muscular de AWS: el backend en el project semilla más los recursos en el miembro no necesita ninguna de la maquinaria de confianza hub-and-spoke de AWS - sin role_arn de backend, sin assume_role de proveedor, sin políticas de confianza de dos lados. Una service account a nivel de org con los roles correctos funciona en toda la org porque IAM hereda hacia abajo; el proveedor "salta" entre projects simplemente configurando project; y se convierte en la identidad de despliegue configurando impersonate_service_account. La comunicación entre projects es un parámetro, no una negociación de confianza. (Esto lo ajustarás más tarde con roles personalizados, SA por project y identidades de CI dedicadas - pero incluso entonces son vinculaciones de roles en ámbitos, nunca un handshake de política de confianza.) Si quieres profundizar en la codificación de cualquiera de los lados, el examen HashiCorp Terraform Authoring & Operations Pro se basa exactamente en estos patrones de estado y proveedor.

Los cuatro puntos donde tus instintos de AWS te engañarán activamente

Si olvidas todo lo demás, recuerda esto:

1. No hay política en el usuario. Deja de buscar el JSON adjunto a una identidad. Los permisos son vinculaciones (member, role) en la org, folder, project o resource, y se heredan hacia abajo. La concesión que necesitas puede estar tres niveles más arriba.
2. Nada funciona hasta que habilitas la API. Tu primer 403 en un nuevo project suele ser API not enabled, no un rol faltante. Cada servicio está desactivado hasta que lo activas, por project.
3. Suplantas service accounts, no asumes roles. Y la SA es un recurso con su propia política de acceso - dar a tu principal amplios derechos de project es inútil sin una vinculación de creador de tokens en la SA.
4. La facturación es un objeto separado. "Puedo desplegar cualquier cosa" no dice nada sobre "Puedo crear un project con cargos o vincular una billing account". Recurso diferente, roles diferentes - billing.user en la billing account, no administrador de project.

Qué certificaciones profundizan en cada lado

La gobernanza de la nube - jerarquía, identidad, guardarraíles y estado - es la columna vertebral de los exámenes de arquitectura y administración en ambas nubes, por lo que estudiarlos es también la forma más rápida de asimilar los conceptos anteriores. Si ya posees la credencial de AWS, la de Google Cloud en la misma fila es tu siguiente paso natural.

Por el lado de AWS (el conocimiento del que estás traduciendo):

• AWS Certified Cloud Practitioner (CLF-C02) - los fundamentos de cuentas, IAM y Organizations.
• AWS Certified Solutions Architect - Associate (SAA-C03) - IAM, estructura multi-cuenta y arquitectura central.
• AWS Certified Solutions Architect - Professional (SAP-C02) - Organizations multi-cuenta, SCPs y acceso entre cuentas a escala.
• AWS Certified Security - Specialty (SCS-C03) - Profundidad de IAM, SCPs y gestión de claves.

Por el lado de Google Cloud (el conocimiento al que estás traduciendo):

• Google Cloud Digital Leader - organizations, projects, IAM y facturación a nivel fundamental.
• Google Cloud Associate Cloud Engineer - el plano del día a día: projects, vinculaciones IAM, service accounts y gcloud.
• Google Cloud Professional Cloud Architect - la jerarquía org/folder/project, diseño de landing zones y gobernanza a escala.
• Google Cloud Professional Cloud Security Engineer - Profundidad de IAM, política de org, seguridad de service accounts y gestión de claves.

Un camino pragmático si estás certificado en AWS hoy: comienza con el Cloud Digital Leader para mapear el vocabulario, luego salta al Associate Cloud Engineer (que reside en el plano de project y IAM que más usarás), y añade el Professional Cloud Architect o Professional Cloud Security Engineer dependiendo de si tu trabajo se inclina más hacia la arquitectura o la seguridad.

En resumen

GCP no es más difícil que AWS - está factorizado de manera diferente. AWS adjunta permisos a las identidades, te entrega una cuenta pesada con todo activado y concentra la mayor parte de la autoridad en IAM. GCP cuelga los permisos en un árbol de recursos que hereda hacia abajo, te da projects desechables y económicos que comienzan como pizarras en blanco, y te hace suplantar service accounts en lugar de asumir roles. Traduce los conceptos una vez - las políticas se mueven de las identidades al árbol, las cuentas se convierten en projects con sus API desactivadas, los roles se convierten en service accounts que suplantas, y la facturación es un objeto separado que vinculas - y el resto es vocabulario. Practícalo con las certificaciones anteriores, y las partes que parecían denegaciones arbitrarias comenzarán a leerse como un diseño coherente y deliberado.