AWS vs GCP vs Azure: jerarquía de la organización, IAM y gestión de claves, uno al lado del otro

Si ya conoces el modelo de gobernanza de una nube, conoces el 80% de las otras dos — los conceptos son idénticos y solo cambia el vocabulario. Cada nube te obliga a responder las mismas tres preguntas antes de implementar algo real: ¿cómo organizo mis accounts?, ¿quién está autorizado a hacer qué? y ¿cómo se crean y controlan mis claves de cifrado? Esta publicación mapea AWS, Google Cloud y Azure entre sí, una capa a la vez, y señala los cuatro puntos donde la analogía se rompe sutilmente.

Esas cuatro capas —jerarquía, guardrails, identidad y gestión de claves— son también la columna vertebral de cada examen de arquitectura y seguridad en la nube. Así que la misma lectura que te ahorra una semana de confusión entre nubes es la mayor parte del temario para una certificación. Los Certs para profundizar en cada capa se enlazan al final.

Los tres problemas que resuelve cada nube

Dejando a un lado el marketing, cada discusión sobre gobernanza se compone de tres capas apiladas una encima de la otra:

• Estructura — un conjunto anidado de contenedores (organización → agrupación → límite de carga de trabajo) para que puedas aislar entornos, aplicar guardrails y dividir la factura.
• Identidad y permisos — qué principals pueden realizar qué acciones en qué recursos, además del límite que restringe lo que cualquier grant puede otorgar.
• Gestión de claves — dónde residen las claves criptográficas, quién puede usarlas y quién puede administrarlas — dos preguntas diferentes que la gente confunde constantemente.

La mayoría de los ingenieros pueden enumerar las piezas en la nube que mejor conocen. La parte difícil es la imagen completa: las capas que son fáciles de olvidar y cómo se traduce cada pieza a las otras dos nubes.

Capa 1 — la jerarquía de recursos

Cada nube tiene un nodo de organización de nivel superior, una capa intermedia de agrupación opcional que se anida para departamentos o entornos, y un límite de carga de trabajo que también sirve como unidad de facturación y blast radius. Las políticas establecidas en niveles superiores fluyen hacia abajo en las tres.

• Org root — AWS: una Organization con una management account. GCP: el organization node. Azure: el tenant root management group, respaldado por un tenant de Microsoft Entra.
• Contenedor de agrupación (anidable) — AWS: Organizational Unit (OU). GCP: folder. Azure: management group.
• Límite de carga de trabajo y facturación — AWS: account. GCP: project. Azure: subscription.
• Agrupación de recursos dentro del límite — AWS: ninguno (tags, o por account). GCP: ninguno — el project es el contenedor. Azure: el resource group, que es obligatorio; cada recurso reside exactamente en uno.

La primera divergencia real se esconde aquí. En AWS, la account es una barrera fuerte — la unidad por defecto de blast radius — por lo que las implementaciones maduras de AWS utilizan docenas o cientos de accounts. En GCP, el project realiza dos tareas a la vez: es tanto la unidad de agrupación como la unidad de facturación/aislamiento, por lo que no existe un concepto de "resource group" separado. Azure añade un cuarto nivel que los otros no tienen — el resource group — situado bajo la subscription como un contenedor de ciclo de vida que se despliega y elimina como una unidad.

Capa 2 — guardrails preventivos (el límite de permisos)

Antes de conceder algo a alguien, cada nube te permite establecer un límite superior sobre los permisos que pueden existir debajo de un nodo — un techo que ninguna grant individual puede atravesar. Esto no es lo mismo que otorgar acceso; es la capa de "nunca podrás, en toda la organización".

• Límite de lo que los principals pueden hacer — AWS: Service Control Policy (SCP). GCP: restricciones de Organization Policy más políticas de denegación de IAM. Azure: Azure Policy.
• Límite de quién puede tocar un recurso — AWS: Resource Control Policy (RCP). GCP: políticas de permiso/denegación de IAM en el recurso. Azure: Azure Policy más deny assignments.
• Aplicar la configuración del servicio — AWS: políticas declarativas. GCP: restricciones de Organization Policy. Azure: Azure Policy (deny / audit / deployIfNotExists).

AWS dividió esta tarea en dos. Las SCP son principal-centric ("nuestra gente no puede hacer X") y las más recientes RCP son resource-centric ("nadie —ni siquiera una account externa— puede tocar este bucket de S3, clave KMS o role a menos que estén en nuestra organización"). Usadas en conjunto, cierran brechas que ninguna cubre por sí sola. La trampa: en AWS y GCP, una SCP o una Org Policy nunca concede nada — solo resta. Azure funciona de manera diferente, separando claramente RBAC (permisos) de Azure Policy (cumplimiento y configuración), de modo que la tarea de guardrail pertenece principalmente a Azure Policy, mientras que "quién puede hacer qué" pertenece enteramente a RBAC.

Capa 3 — identidad y permisos

Cada nube expresa una grant como la misma tripleta — un principal, un role (un paquete de permisos) y un scope — pero ensambla las piezas de manera diferente.

• Directorio de identidad — AWS: IAM más IAM Identity Center (SSO). GCP: Cloud Identity / Google Workspace más IAM. Azure: Microsoft Entra ID.
• Paquete de permisos (el "role") — AWS: una IAM policy, gestionada o inline. GCP: un IAM role — básico, predefinido o personalizado. Azure: una definición de role de RBAC, integrada o personalizada.
• La propia grant — AWS: una policy adjunta a un usuario, grupo o role. GCP: un IAM binding (member + role, opcionalmente una condición) en un recurso. Azure: una role assignment (principal + role + scope).
• Condiciones y denegación explícita — AWS: IAM condition keys y Deny explícito. GCP: IAM Conditions y políticas de denegación. Azure: condiciones de RBAC y deny assignments.

La diferencia más profunda es dónde reside la grant. En AWS, la policy se adjunta principalmente a la identidad — un role o usuario — y el permiso viaja con ellos. En GCP, la allow policy se adjunta al recurso: otorgas principal P el role R en el recurso X, y este se hereda por la jerarquía. La role assignment de Azure se asemeja al binding de GCP, pero se ancla a un scope en la cadena management group → subscription → resource group → recurso. Internaliza "AWS = adjunto a la identidad, GCP y Azure = adjunto al recurso/scope" y gran parte de la confusión entre nubes desaparecerá.

Capa 3b — identidad de la carga de trabajo (la parte que la gente olvida)

Los humanos no son los únicos principals. Tu código también necesita una identidad, y hacerlo bien es la mayor palanca para el least privilege. La regla de oro en todas partes: nunca implementes claves estáticas de larga duración — en su lugar, adjunta una managed identity a la carga de trabajo.

• Identidad para una carga de trabajo en ejecución — AWS: un IAM role, asumido a través de instance profile, task role u OIDC. GCP: una service account adjunta al recurso. Azure: una managed identity, asignada por el sistema o por el usuario.
• App / principal no humano — AWS: IAM role. GCP: service account. Azure: service principal.
• Confianza sin claves desde fuera de la nube — AWS: IAM roles con federación OIDC/SAML. GCP: Workload Identity Federation. Azure: workload identity federation.

Fíjate en la superposición de nombres que confunde a todo el mundo: un "IAM role" en AWS es una workload identity que asumes, mientras que un "role" en GCP y Azure es solo un paquete de permisos — la identidad es una service account o una managed identity. Misma palabra, dos trabajos diferentes. Las keys de service account de GCP y los secrets de service principal de Azure todavía existen, pero ambas nubes ahora impulsan fuertemente la federación sin claves para cualquier cosa que se ejecute fuera de su perímetro.

Capa 4 — gestión de claves

Finalmente, el cifrado. Cada nube tiene un servicio de claves gestionado, organiza las claves en una pequeña jerarquía y —lo que es crucial— separa el uso de una clave (cifrar/descifrar) de la administración de una clave (rotar, deshabilitar, establecer policy).

• Servicio — AWS: KMS, más CloudHSM para hardware dedicado. GCP: Cloud KMS, más Cloud HSM / externo. Azure: Key Vault, más Managed HSM para hardware dedicado.
• Organización de claves — AWS: KMS keys (CMKs), aliases, multi-Region keys. GCP: key ring → key → key version. Azure: vault → key / secret / certificate.
• Control de acceso — AWS: key policy + grants + IAM (los tres se combinan). GCP: IAM bindings de Cloud KMS a nivel de project, key ring o key. Azure: RBAC por defecto, o políticas de acceso heredadas por vault; Managed HSM utiliza su propio RBAC local.
• División de uso vs. administración — AWS: acciones de cifrado/descifrado vs. acciones de administración de claves. GCP: cryptoKeyEncrypterDecrypter vs. roles admin. Azure: roles de estilo "Crypto User" vs. "Crypto Officer".

Un detalle actual que vale la pena conocer: para nuevos Key Vaults en versiones recientes de la API, Azure RBAC es ahora el modelo de acceso predeterminado, y las políticas de acceso por vault más antiguas son el camino heredado — lo que finalmente alinea Key Vault con la forma en que el resto de Azure gestiona los permisos. AWS sigue siendo la excepción: la key policy de una clave KMS es autoritaria y puede otorgar acceso independientemente de IAM, por lo que un error clásico en AWS es bloquearte el acceso a una clave al editar IAM y olvidar la key policy. En GCP, el acceso a KMS es simplemente IAM como todo lo demás.

Dónde falla el modelo mental

Un mapeo limpio es peligroso si se confía en él demasiado literalmente. Los cuatro puntos donde la analogía se filtra:

• "IAM role" significa dos cosas diferentes. En AWS es una identity asumible; en GCP y Azure un "role" es solo un permission set, con la identidad separada. Nunca lo traduzcas literalmente.
• AWS adjunta permisos a las identidades; GCP y Azure los adjuntan a los recursos y scopes. Tu instinto de "¿dónde busco para auditar el acceso?" tiene que cambiar cuando cambias de nube.
• Account, project y subscription no son el mismo blast radius. Una account de AWS es una pared sólida; un project de GCP es pared, factura y agrupación en uno; una subscription de Azure es principalmente un límite de facturación y escala, con el resource group manejando el ciclo de vida diario.
• Los guardrails restan, las grants suman — excepto que Azure divide las tareas. Las SCP y las Org Policies solo limitan los permisos; Azure los limita a través de Policy y los concede a través de RBAC como dos sistemas separados.

El principio subyacente a los tres es el mismo: least privilege, aplicado por la estructura. Coloca los guardrails en lo alto (org, OU, folder, management group), concede de forma restringida y prefiere los roles sobre las claves estáticas, y mantén "puede usar una clave" separado de "puede administrar una clave". Los nombres cambian entre nubes; la disciplina no.

Conclusiones prácticas

• Diseña la jerarquía antes de la primera carga de trabajo. Reajustar accounts, projects o subscriptions más tarde es perjudicial en cada nube.
• Establece límites altos, concede poco. SCP/RCP, Org Policy o Azure Policy en la cima; roles específicos en el scope más estrecho que funcione.
• Por defecto, utiliza managed identities. IAM roles en AWS, service accounts en GCP, managed identities en Azure — y federación sin claves para cualquier cosa que cruce un límite de la nube.
• Trata la administración de claves como privilegiada. Separa cifrar/descifrar de rotar/deshabilitar/establecer-policy, y en AWS siempre verifica la key policy, no solo IAM.
• Si utilizas Terraform u OpenTofu, estas primitivas son exactamente lo que codificarás — aws_organizations_*, google_folder, azurerm_management_group, y los recursos de IAM/RBAC y KMS debajo de ellos.

Profundiza en cada capa, por nube

Las certificaciones de arquitectura y seguridad de cada nube se basan directamente en la jerarquía de recursos, IAM/RBAC y la gestión de claves. Si deseas practicarlas con preguntas de examen reales, CertLabPro tiene una ruta para cada una:

• AWS — Solutions Architect Associate (SAA-C03) para la jerarquía e IAM, y Security Specialty (SCS-C03) para SCPs, RCPs y KMS. ¿Nuevo en AWS? Comienza con Cloud Practitioner (CLF-C02).
• Google Cloud — Professional Cloud Architect para organización, folders, projects e IAM, y Professional Cloud Security Engineer para políticas de denegación de IAM, Org Policy y Cloud KMS.
• Azure — Solutions Architect Expert (AZ-305) para management groups y gobernanza, y Security Engineer (AZ-500) para RBAC, Azure Policy y Key Vault. ¿Nuevo en Azure? Comienza con Azure Fundamentals (AZ-900).

En resumen

AWS, Google Cloud y Azure no son tan diferentes como sus documentos hacen sentir. Cada uno te proporciona una jerarquía para organizar accounts, un modelo de identidad construido sobre principal-role-scope, una capa de guardrail que limita los permisos que pueden existir, y un servicio de claves que separa el uso de claves de su administración. Aprende las cuatro capas una vez y la traducción entre nubes es principalmente vocabulario — y aprende los cuatro puntos donde la analogía se filtra, y esquivarás los errores que el vocabulario oculta. Esos fundamentos son exactamente lo que los bancos de preguntas de CertLabPro están diseñados para practicar, en las tres nubes.