Guía Exhaustiva de AWS Organizations: Aprendiendo Diseño Multi-Cuenta Comparándolo con la Jerarquía de Recursos de GCP y los Management Groups de Azure

Introducción (Resumen de Puntos Clave)

• En este artículo ponemos AWS Organizations en el centro y ordenamos cuidadosamente el diseño en la era multi-account / multi-project mientras lo comparamos en paralelo con la jerarquía de recursos de GCP (Organization / Folder / Project) y la estructura de Management Groups + Subscriptions de Azure.
• AWS Organizations es un servicio que permite gestionar múltiples cuentas de AWS de forma centralizada y basada en políticas, habilitando automatización de creación de cuentas, gobernanza, gestión de costes y auditoría centralizada. No tiene coste adicional y sirve como la “base” para un entorno escalable.
• En contraste, GCP ofrece el mismo tipo de “gobernanza jerárquica” usando Organization / Folder / Project y Cloud IAM / Org Policy, mientras que Azure usa Management Group / Subscription / Resource Group combinado con Azure RBAC / Azure Policy.
• Los puntos clave de diseño son:
  1. Separar cuentas (o proyectos / suscripciones) no por el organigrama, sino por “gobernanza y responsabilidad”.
  2. Usar SCP (Service Control Policies), Org Policy y Azure Policy para definir “reglas de límite superior”.
  3. Preparar cuentas / proyectos “hub” para centralizar seguridad, logs y facturación.
  4. Organizar OUs / Folders / Management Groups por entorno (prod / stg / dev) y por equipo.
  5. Diseñar nombres, jerarquía y permisos de forma que puedan “reutilizarse entre nubes”, teniendo en mente un futuro multi-cloud.
• Este artículo está dirigido a propietarios corporativos de la nube (IT), ingenieros SRE / de plataforma, personal de seguridad y gobernanza, líderes técnicos en organizaciones con múltiples productos y CTOs de startups.
  • Es ideal para la fase en la que se está saliendo del modelo de una sola cuenta y se empieza a pensar “ya va siendo hora de dividir cuentas” o “queremos límites claros de responsabilidad por departamento”.

1. ¿Qué es AWS Organizations? – Un servicio que trata múltiples cuentas como “una sola organización”

1.1 Idea básica

En pocas palabras, AWS Organizations es:

“Un servicio que agrupa múltiples cuentas de AWS en una sola ‘organización’
y gestiona de forma centralizada la creación de cuentas, las políticas, la facturación y la gobernanza.”

Sus características principales son:

• Gestión centralizada de múltiples cuentas
  • Puedes colgar varias cuentas bajo una sola Organization y organizarlas jerárquicamente (OUs).
• Automatización del ciclo de vida de las cuentas
  • Puedes crear nuevas cuentas automáticamente vía API / CloudFormation / varias soluciones de landing zone.
• Gobernanza basada en políticas (SCP)
  • Puedes aplicar Service Control Policies (SCP) a nivel de Organization / OU / cuenta y definir reglas de límite superior, como por ejemplo “no se permite iam:* en ningún lugar de esta organización” o “las regiones distintas a Tokio están prohibidas en esta OU”.
• Facturación consolidada
  • Puedes agregar el consumo de todas las cuentas de la organización en una sola factura, facilitando la gestión de costes y aprovechando mejor los descuentos por volumen.

1.2 Componentes principales

Organicemos brevemente los conceptos clave que forman el mundo de AWS Organizations:

• Organization
  • Un conjunto de cuentas de AWS. Una cuenta de administración se encuentra en la parte superior y múltiples cuentas miembro cuelgan debajo.
• Management Account
  • La cuenta “madre” que crea la organización inicialmente.
  • Tiene privilegios muy potentes, como invitar / crear cuentas, definir SCP y gestionar la facturación, así que idealmente no quieres que la gente inicie sesión en ella para el trabajo del día a día.
• Member Account
  • Una cuenta normal que pertenece a la organización. Puedes invitar una cuenta existente o crear una nueva como miembro.
• Root
  • El nodo más alto de la jerarquía de la organización. Aplicar un SCP aquí afecta a todas las cuentas de la organización.
• OU (Organizational Unit)
  • Una unidad tipo “carpeta” para agrupar cuentas. Una OU puede contener OUs hijas, por lo que puedes expresar una estructura organizativa jerárquica.

Combinando estos elementos puedes organizar cuentas como “cuenta de seguridad”, “cuenta de archivo de logs”, “Product A prod”, “Product A staging”, etc.

2. Alineando las “estructuras jerárquicas” de AWS / GCP / Azure

Primero respondamos a la pregunta típica: “¿Cuál es el equivalente de Organizations en GCP y Azure?”

2.1 Comparación general de las estructuras jerárquicas de las tres nubes

AWS (Organizations + IAM)

• Organization
  • Root
    • OU (representa departamentos / entornos, etc.)
      • Account (cuenta de AWS)
        • Varios recursos (VPC, EC2, RDS, …)

GCP (Resource Manager + Cloud IAM)

• Organization
  • Folder (carpetas de profundidad arbitraria que representan departamentos / sistemas / entornos)
    • Project
      • Varios recursos (Compute Engine, Cloud SQL, GKE, …)

Azure (Management Groups + Subscriptions)

• Management Group (contenedor de nivel superior para la organización)
  • Management Group (anidables)
    • Subscription
      • Resource Group
        • Varios recursos (VM, Storage, SQL DB, AKS, …)

En las tres nubes se aplica la regla de que las políticas y permisos establecidos en nodos de nivel superior se heredan hacia abajo, implementada mediante:

• AWS: SCP + IAM
• GCP: políticas Allow / Deny de Cloud IAM + Org Policy
• Azure: Azure RBAC + Azure Policy

2.2 Tabla de mapeo intuitiva

Puedes pensar en el mapeo aproximadamente así:

• AWS Organization ⇔ GCP Organization ⇔ Azure Tenant + Management Groups
• AWS OU ⇔ GCP Folder ⇔ Azure Management Group
• AWS Account ⇔ GCP Project ⇔ Azure Subscription

No son idénticos al 100 %, pero en términos de “estructura de carpetas de alto nivel de la nube”, juegan un papel prácticamente igual.

3. Casos de uso representativos – ¿Cuándo se usa Organizations?

3.1 Separar cuentas por departamento / entorno para aplicar gobernanza

Una estructura común del árbol podría ser:

• Root

  • security OU
    • Cuenta de herramientas de seguridad
    • Cuenta de agregación de logs
  • shared-services OU
    • Cuenta de hub de red
    • Plataforma común (CI/CD, IAM Identity Center, etc.)
  • workloads OU
    • prod OU
      • Cuenta de producción del Producto A
      • Cuenta de producción del Producto B
    • nonprod OU
      • Cuenta de dev / staging del Producto A
      • Cuenta de dev / staging del Producto B

• Seguridad / red / plataforma compartida residen en cuentas de “servicios compartidos”.

• Cada equipo de producto trabaja dentro de su propia cuenta, mientras que las acciones peligrosas se restringen vía SCP.

Esto proporciona límites claros de responsabilidad y operaciones más limpias.

En GCP, crearías Folders security / shared / workloads bajo la Organization y colgarías Projects debajo. En Azure, crearías Subscriptions bajo Management Groups con una estructura similar, logrando casi la misma configuración.

3.2 Gestión de costes con facturación consolidada

Cuando quieres separar cuentas por departamento pero seguir teniendo una sola factura para contabilidad, Organizations es muy útil.

• Puedes ver el consumo por cuenta en Cost Explorer e informes de facturación.
• Pero las facturas se agregan a nivel de organización, de modo que el pago es sencillo.
• Los descuentos por volumen y Savings Plans también se aplican de forma más efectiva a través de la organización.

GCP ofrece algo similar con billing accounts + projects, y Azure mediante Enterprise Agreements / CSP + múltiples subscriptions, pero AWS tiene una integración especialmente estrecha entre Organizations y sus herramientas de gestión de costes.

3.3 Guardrails para requisitos regulatorios / de cumplimiento

Ejemplos de reglas a nivel de organización:

• “En esta organización, solo se pueden usar regiones específicas.”
• “En esta OU, se prohíben las operaciones del usuario root.”
• “Este departamento no puede usar ciertos servicios (por ejemplo, servicios de pruebas de alto riesgo).”

Puedes definir esto como SCP adjuntos a Root / OU, evitando que la configuración se desvíe en cada cuenta individual.

Del mismo modo, puedes usar Org Policy en GCP o Azure Policy + Management Groups en Azure para definir reglas a nivel de organización como “restricciones de región”, “restricciones de servicios” y “tags obligatorias”.

4. Establecer “límites superiores” con SCP (Service Control Policy)

4.1 El rol de las SCP

Mientras que las políticas IAM especifican los permisos concedidos a un usuario o rol, las SCP definen:

“Qué es lo que una cuenta (o las cuentas bajo una OU) no puede hacer en absoluto desde el principio.”

En otras palabras, las SCP son “barandillas de límite superior”.

• Incluso si algo está permitido por una política IAM, un Deny en una SCP lo bloqueará igualmente.
• A la inversa, aunque una SCP permita una acción, no tendrá éxito si IAM no la permite.

Así obtienes una estructura de control en dos capas.

4.2 Ejemplos representativos de SCP

4.2.1 Prohibir el uso de la API con el usuario root

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyRootUser",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:root"
        }
      }
    }
  ]
}

Adjunta esta SCP a Root o a una OU específica para bloquear completamente las operaciones de API por parte del usuario root (el comportamiento de la consola respecto a login / vistas de facturación depende de la implementación de AWS, pero al menos evitas el “uso accidental de claves root”).

4.2.2 Prohibir el uso de regiones distintas a Tokio

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyRegionsExceptTokyo",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": "ap-northeast-1"
        }
      }
    }
  ]
}

Esto es útil cuando necesitas restringir las regiones permitidas por motivos de cumplimiento.
En GCP harías algo parecido con Org Policy y constraints/gcp.resourceLocations, y en Azure con una Policy en un Management Group que restrinja location, logrando un comportamiento casi idéntico.

5. Patrones de estructura de cuentas – “Plantillas” por escala

5.1 Escala pequeña / startups (2–5 cuentas)

• management (o root): solo para gestión de Organizations y facturación (sin logins de día a día)
• security: agregación de CloudTrail, herramientas de seguridad, almacenamiento de logs
• shared: hub de VPC, IAM Identity Center, CI/CD compartido
• prod: cargas de trabajo de producción
• nonprod: cargas de trabajo de desarrollo / pruebas

Este nivel de simplicidad suele ser suficiente para empezar. Más adelante puedes añadir prod-a, prod-b, etc., según sea necesario.

En GCP, esto corresponde a Folders security / shared / prod / nonprod y Projects colgados bajo la Organization. En Azure, lo reflejarías mediante Management Groups y múltiples Subscriptions.

5.2 Organizaciones medianas–grandes (por departamento / país / unidad de negocio)

Ejemplo:

• security OU
• shared-services OU
• corp-it OU (sistemas internos de IT)
• business-unit-a OU
  • prod / nonprod
• business-unit-b OU
  • prod / nonprod

Aquí defines las OUs por unidad de negocio × entorno, y aplicas reglas comunes de SCP (restricciones de región, prohibición de root, logging obligatorio, etc.).

En GCP (Folders) y Azure (Management Groups), suelen verse estructuras como:

• org
  • shared
  • corp-it
  • bu-a
  • bu-b

con la gobernanza aplicada en cada nivel.

6. “Puntos calientes” de gobernanza vistos en comparación con GCP y Azure

6.1 Combinación con IAM

• AWS:
  • Las SCP en Organizations definen “lo que como máximo puede estar permitido”, mientras que las políticas IAM definen “quién obtiene qué permisos realmente”.
• GCP:
  • Los roles de Cloud IAM + Org Policy controlan Allow / Deny en cada nivel de la jerarquía.
• Azure:
  • Roles RBAC + Azure Policy aplicados a nivel de Management Group / Subscription / Resource Group.

Todas las nubes comparten el patrón de “colocar barandillas en los contenedores superiores y conceder los permisos de operación diaria en niveles inferiores”.

6.2 Integración con logging y auditoría

• En AWS, un patrón común es crear una cuenta de archivo de logs bajo Organizations y centralizar logs como:
  • CloudTrail
  • Config
  • Logs relacionados con seguridad
• En GCP, prepararías un proyecto de destino de log sink, y reenviarías logs desde cada Project a ese proyecto. En Azure, crearías un Log Analytics workspace central y enviarías allí Activity Logs y diagnostic logs.

6.3 Una forma de pensar “cross-cloud”

A lo largo de AWS, GCP y Azure, puedes diseñar con el mismo patrón si piensas en tres pasos:

• Colocar las “reglas corporativas” en el nodo superior (Organization / Tenant / Management Group superior).
• Usar nodos intermedios (OU / Folder / Management Group) para representar departamento / sistema / entorno.
• Usar la unidad de facturación (Account / Project / Subscription) para separar responsabilidad y presupuesto.

7. Errores comunes y cómo evitarlos

7.1 Meter “todo en una sola cuenta” antes de pasar a Organizations

• Problema:
  • VPC, IAM, tags y convenciones de nombres se vuelven un caos en una sola cuenta.
  • Cuando por fin decides dividir cuentas, los costes de migración se disparan.
• Cómo evitarlo:
  • Adquiere el hábito de usar Organizations + al menos 2–3 cuentas cuando aún eres pequeño.
  • Del mismo modo, en GCP usa múltiples Projects desde el principio, y en Azure múltiples Subscriptions, tratándolo como algo “normal”.

7.2 Apretar demasiado con SCP y bloquearse

• Problema:
  • Si se dice “vamos a ser ultra seguros” y se ponen Deny * por todos lados en las SCP,
  • luego descubres que servicios esenciales están bloqueados y tienes que rediseñar las SCP desde cero.
• Cómo evitarlo:
  • Comienza con solo las “acciones claramente peligrosas” (APIs de root, restricciones de región, etc.) en las SCP.
  • En GCP / Azure, también despliega Org Policy / Azure Policy de forma gradual, en lugar de activar todas las reglas a la vez desde el primer día.

7.3 Hacer que la estructura de OU copie demasiado el organigrama de RR. HH.

• Problema:
  • Cada vez que RR. HH. reorganiza departamentos, te ves tentado a cambiar OUs, Folders o Management Groups.
  • Mover políticas de gobernanza se convierte en una pesadilla.
• Cómo evitarlo:
  • Construye tus estructuras de OU / Folder / Management Group alrededor de “responsabilidad y gobernanza”, “arquitectura de sistemas” y “entorno (prod / nonprod)”, y mantén relativamente flojo el vínculo con el organigrama de RR. HH.

8. Cómo ayuda esto a cada tipo de lector objetivo

8.1 Para IT corporativo / propietarios centrales de la nube

• A medida que varios departamentos y productos empiezan a usar AWS, surge la pregunta: “¿Cómo debemos dividir las cuentas para facilitar la gestión, la auditoría y el control de costes?”
• Usando AWS Organizations combinado con una estructura de OUs tipo security / shared / workloads + SCP + cuentas de archivo de logs, puedes:
  • Dar libertad a los departamentos, asegurando a la vez que “estas cosas mínimas son obligatorias”, y
  • Centralizar toda la actividad de cuentas y la facturación en un solo lugar,
    logrando una “gobernanza práctica” que equilibra control y autonomía.

8.2 Para ingenieros SRE / de plataforma

• En tareas como “diseñar la landing zone” y “distribuir baselines seguras”, Organizations es una pieza imprescindible.

• Si tomas los patrones de este artículo y los codificas vía IaC:

  • Estructura de OUs
  • Roles y responsabilidades de cuentas
  • Plantillas de SCP
  • Patrones de agregación de logs

  podrás poner en marcha nuevos productos y equipos rápidamente usando el mismo plano.

8.3 Para personal de seguridad y gobernanza

• SCP / Org Policy / Azure Policy permiten implementar “lo que nuestra empresa jamás debe hacer en la nube” no solo como documentos, sino como barandillas técnicas.

• Si defines:

  • restricciones del usuario root
  • restricciones de región
  • logging obligatorio

  como SCP a nivel de Organizations y replicas las mismas reglas en GCP / Azure, podrás mantener un cumplimiento multi-cloud consistente con mayor facilidad.

8.4 Para CTOs de startups y tech leads

• En la fase muy inicial es tentador decir “hagámoslo todo en una sola cuenta”, pero dividir después es extremadamente doloroso.

• Si adoptas la “estructura de 5 cuentas” desde el principio, tendrás espacio para soportar:

  • Explicaciones a inversores y auditorías
  • Incorporación de nuevos productos
  • Expansión internacional

  con transiciones mucho más suaves.

9. Tres pasos que puedes empezar hoy mismo

1. Haz inventario de tus cuentas / proyectos / suscripciones actuales.
   • Deja por escrito “para qué sirve cada entorno”, “quién es responsable” y “a dónde van los logs y la facturación”.
2. Mapéalos al “modelo de 5 cuentas (o 5 proyectos / suscripciones)”.
   • Asígnalos a security / shared / prod / nonprod / management e identifica los huecos.
3. Crea una jerarquía mínima en Organizations (o GCP Org, Azure Management Groups).
   • No busques la perfección al principio: el simple hecho de crear OUs / Folders / Management Groups como security / shared / workloads directamente bajo Root ya aporta mucha claridad.

10. Resumen: divide cuentas por “responsabilidad y gobernanza”, no por organigrama

AWS Organizations es más que un servicio para agrupar cuentas. Es:

• Un marco para definir “plantillas” de diseño de cuentas,
• La base para establecer barandillas a nivel de organización mediante SCP, y
• Un punto central para agrupar logs, facturación y seguridad.

El Resource Manager de GCP (Organization / Folder / Project) y los Management Groups + Subscriptions de Azure comparten el mismo objetivo.
En lugar de perderse en las diferencias menores entre nubes, céntrate en dominar este enfoque común:

1. Coloca las reglas corporativas en el nivel superior.
2. Usa capas intermedias para representar departamentos, sistemas y entornos.
3. Usa la unidad de facturación (Account / Project / Subscription) para separar responsabilidad y presupuesto.

Una vez que tengas esta “forma de pensar cross-cloud”, el mundo multi-cloud se vuelve mucho menos confuso.

En el siguiente artículo profundizaremos en el diseño de la nube desde la perspectiva de “dónde y cómo ejecutar aplicaciones”, usando ECS / EKS (plataformas de contenedores estrechamente vinculadas a Organizations, IAM y VPC) y comparándolas con GCP (GKE / Cloud Run) y Azure (AKS / Container Apps).
Vamos a ir construyendo juntos un entorno cloud resiliente y escalable.

Enlaces de referencia (documentación oficial en japonés e inglés)

• ¿Qué es AWS Organizations? (User Guide)

• Página de producto AWS Organizations (Cloud Management)

• Explicación de AWS Organizations (japonés, diapositivas Black Belt)

• Google Cloud Resource Manager: Resource hierarchy

• Descripción general de Azure Management Groups / Subscriptions

  • Management Groups Overview
  • Overview of Azure Subscriptions

※ Para límites concretos, funciones más recientes y precios, consulta siempre la documentación oficial y las páginas de precios de cada proveedor cloud.