Letra ChicaDiccionario
No servicios sino estructura: cómo organiza cada nube cuentas, redes, zonas, identidad y metadatos. Es donde más se confunde quien salta de una nube a otra.
Jerarquía de recursosOrganización
Cómo se organizan las cuentas y los recursos, y dónde se aplican y heredan los permisos y las políticas.
Azure
Tenant root group → management groups (hasta seis niveles, sin contar la raíz ni las suscripciones) → suscripciones → resource groups → recursos. Roles y políticas asignados arriba se heredan hacia abajo.
AWS
Root → OUs anidadas (hasta cinco niveles) → cuentas. La cuenta es el límite de recursos, de IAM y de facturación; no hay un contenedor equivalente al resource group dentro de ella.
GCP
Organización → carpetas (opcionales, hasta diez niveles) → proyectos → recursos. La policy efectiva de IAM es la unión de la del recurso y la de todos sus ancestros.
⚠ Dónde se rompe la analogía
El resource group de Azure no tiene equivalente directo: en AWS los "Resource Groups" son una consulta por tags o por stack de CloudFormation, no un contenedor, y en GCP el contenedor más cercano es el proyecto.
En AWS las SCP nunca otorgan permisos: ponen un techo, y no afectan a la cuenta de management. En Azure y GCP un rol asignado arriba sí otorga acceso a todo lo que está abajo.
Límite de facturación y cuotasOrganización
Qué objeto recibe la factura y en qué nivel se aplican las cuotas.
Azure
La suscripción es la unidad de facturación y de límites de servicio; varias suscripciones se agrupan en management groups.
AWS
Cada cuenta es un límite de facturación; con Organizations la facturación de las cuentas miembro se consolida en la cuenta de management.
GCP
Una cuenta de Cloud Billing paga los proyectos vinculados a ella; las cuotas se aplican en general por proyecto.
⚠ Dónde se rompe la analogía
En GCP la cuenta de facturación es un objeto aparte de la jerarquía: un proyecto se puede mover de carpeta sin cambiar quién lo paga, y viceversa.
Identidad de las personasIdentidad
Dónde viven los usuarios humanos y cómo obtienen acceso a varias cuentas, suscripciones o proyectos.
Azure
Cada suscripción confía en un único tenant de Entra ID; los usuarios del tenant reciben roles sobre management groups, suscripciones o recursos.
AWS
IAM es por cuenta. Para personas, AWS recomienda IAM Identity Center, que da acceso a varias cuentas con permission sets, en lugar de crear usuarios IAM en cada cuenta.
GCP
La organización de Google Cloud está vinculada a una cuenta de Cloud Identity o Workspace; las personas reciben roles de IAM en la jerarquía.
⚠ Dónde se rompe la analogía
En Azure el directorio es uno solo para todas las suscripciones que confían en él. En AWS cada cuenta tiene su propio IAM y el acceso de personas se centraliza con Identity Center: un usuario IAM creado en una cuenta no existe en las demás.
Alcance de la red virtualRed
Si la red y sus subnets son globales, regionales o zonales, y qué implica para el diseño multi-región y multi-zona.
Azure
La VNet es regional y sus subnets abarcan todas las zonas de la región. Multi-región = una VNet por región, conectadas.
AWS
La VPC es regional y abarca todas las AZs de la región, pero cada subnet vive en una sola AZ. Alta disponibilidad = una subnet por AZ.
GCP
La VPC es global (con sus rutas y reglas de firewall) y las subnets son regionales. Una sola red puede cubrir varias regiones.
⚠ Dónde se rompe la analogía
La misma palabra "VPC" significa cosas distintas en AWS (regional, subnets zonales) y en GCP (global, subnets regionales). La subnet de Azure se parece más a la de GCP que a la de AWS.
Zonas de disponibilidadRed
Cómo se nombran las zonas y si el nombre que ves apunta al mismo datacenter que ve otra cuenta o suscripción.
Azure
Las zonas físicas se mapean a zonas lógicas por suscripción, y dos suscripciones pueden tener un orden distinto. Para alinear zonas entre suscripciones hay que consultar el mapeo (az account list-locations).
AWS
El AZ ID identifica la misma zona física en todas las cuentas. En cuentas viejas de las regiones más antiguas, el nombre de AZ puede apuntar a zonas distintas según la cuenta; desde noviembre de 2025 las cuentas nuevas tienen el mismo mapeo.
GCP
Las zonas se nombran región + letra. La documentación las describe como abstracciones lógicas de recursos físicos y no detalla un mapeo por proyecto.
⚠ Dónde se rompe la analogía
"Zona 1" en dos suscripciones de Azure, o "us-east-1a" en dos cuentas viejas de AWS, no garantiza el mismo datacenter. Si una arquitectura cruza suscripciones o cuentas y depende de la latencia o del aislamiento por zona, alineá por el ID físico.
Identificadores de recursosOperación
El formato del ID completo de un recurso, el que aparece en policies, logs y referencias entre recursos.
Azure
Una ruta jerárquica /subscriptions/{id}/resourceGroups/{rg}/providers/{namespace}/{tipo}/{nombre}.
AWS
arn:partition:servicio:región:cuenta:recurso. Algunos servicios omiten la región, la cuenta o ambas (por ejemplo, los buckets de S3).
GCP
//servicio.googleapis.com/projects/{proyecto}/… con el servicio como prefijo, por ejemplo //compute.googleapis.com/projects/p/zones/z/instances/vm.
⚠ Dónde se rompe la analogía
El ID de Azure incluye el resource group, así que mover un recurso de resource group cambia su ID. En GCP el proyecto se identifica por ID (elegido, permanente) o por número (asignado): algunas APIs y principals usan el número.