¿Cuál es la mejor estructura organizacional para tu cuenta de AWS?

Orden desde el primer día#

Cuando empiezas en AWS lo normal es crear una cuenta, entrar como usuario raíz y desplegar todo ahí: pruebas, staging y producción mezclados. Funciona hasta que un script de pruebas borra un recurso que no debía, la factura no dice qué entorno gastó qué, o una credencial filtrada da acceso a todo a la vez.

La alternativa es definir desde el diseño una estructura organizativa segura y funcional. En AWS eso se hace con AWS Organizations: un servicio gratuito que agrupa varias cuentas bajo una misma administración, con facturación consolidada y políticas centralizadas.

En esta guía vemos cómo diseñar esa estructura de forma general: qué es cada pieza de AWS Organizations, cómo repartir cuentas por entorno y por carga de trabajo, cómo crear una OU y una cuenta de producción paso a paso en la consola nativa de AWS, cómo automatizarlo con la AWS CLI y Terraform, y qué guardrails, accesos y controles de facturación conviene activar desde el principio.

Documentación: AWS · Qué es AWS Organizations ↗ · AWS · Organizing your AWS environment (whitepaper) ↗

Los cuatro conceptos que debes distinguir#

El error de vocabulario más común (y que cometía la versión original de este artículo) es llamar organización a cada carpeta. En AWS Organizations hay piezas distintas:

• Organización: la entidad completa. Hay una sola por cuenta de administración y agrupa todas las cuentas.
• Cuenta de administración (management account): la cuenta que crea la organización. Paga la factura consolidada, crea e invita cuentas y administra políticas. Es la cuenta más sensible de todas.
• Root: el contenedor raíz de la jerarquía. Todas las OUs y cuentas cuelgan de él, directa o indirectamente.
• Unidad organizacional (OU): una carpeta dentro de Root (o dentro de otra OU) para agrupar cuentas que comparten políticas, por ejemplo production o sandbox.
• Cuenta miembro: una cuenta de AWS normal que pertenece a la organización. Es el verdadero límite de aislamiento para recursos, permisos y cuotas.

La idea clave: la cuenta es la frontera de seguridad y de facturación; la OU es la forma de aplicar reglas a un grupo de cuentas a la vez.

Documentación: AWS · Qué es AWS Organizations ↗

La estructura recomendada: separar por entorno#

AWS recomienda un entorno multi-cuenta porque cada cuenta aísla permisos, cuotas de servicio y costos. Si staging y producción viven en cuentas distintas, un error en staging no puede tocar producción aunque alguien tenga permisos de administrador en staging.

Para equipos que están empezando, una base razonable es:

• La cuenta de administración, sin cargas de trabajo: solo organización, facturación y políticas.
• Una OU para producción con su cuenta (o cuentas) de producción.
• Una OU para entornos no productivos (staging, QA, desarrollo).
• Una OU sandbox para experimentación, con restricciones de gasto y servicios.

A medida que crece la organización, el whitepaper de AWS Organizing Your AWS Environment propone OUs adicionales, como Security (cuentas de auditoría y log archive), Infrastructure (redes y servicios compartidos), Workloads (con producción y no producción), Sandbox, Policy Staging y Suspended. No necesitas todas el primer día, pero conviene que tus nombres sean compatibles con ese modelo.

Dentro de cada entorno, la unidad natural es la carga de trabajo: una cuenta por aplicación o dominio de negocio y por entorno (por ejemplo tienda-prod y tienda-staging). Así cada equipo tiene su propio límite de permisos y de cuotas, y la factura por cuenta ya te dice cuánto cuesta cada aplicación en cada entorno. Si tienes pocas aplicaciones, empezar con una cuenta de producción y otra de no producción es perfectamente válido; lo importante es que el diseño permita dividir después sin rehacer todo.

Root
├── cuenta de administración   (solo organización, facturación y políticas)
├── OU Security
│   ├── log-archive            (logs centralizados, acceso restringido)
│   └── audit                  (herramientas de seguridad, acceso de solo lectura)
├── OU Workloads
│   ├── OU Prod
│   │   ├── tienda-prod
│   │   └── pagos-prod
│   └── OU NonProd
│       ├── tienda-staging
│       └── pagos-staging
└── OU Sandbox
    └── sandbox-equipo-datos

Si prefieres no montar todo a mano, AWS Control Tower crea una landing zone sobre Organizations con OUs Security, cuentas de log archive y audit y controles preconfigurados. Es una opción válida cuando quieres un punto de partida gobernado; los conceptos de esta guía siguen aplicando.

Documentación: AWS · Beneficios de usar varias cuentas ↗ · AWS · OUs y cuentas recomendadas ↗ · AWS · Qué es AWS Control Tower ↗

Paso 1: abre AWS Organizations#

Entra a la consola con un usuario de la cuenta que será la de administración. Escribe Organizations en la barra de búsqueda superior y selecciona AWS Organizations.

Verás uno de dos escenarios:

• Si nunca has creado una organización, la consola muestra el botón Create an organization. Al pulsarlo, tu cuenta actual pasa a ser la cuenta de administración y se crea Root.
• Si ya existe una organización, verás directamente la vista de estructura (AWS accounts), desde donde se crean cuentas y OUs.

Ten en cuenta que la cuenta que crea la organización queda como cuenta de administración de forma permanente para esa organización. Si hoy tienes cargas productivas en esa misma cuenta, lo recomendable es planear moverlas a una cuenta miembro con el tiempo, no seguir creciendo ahí.

Documentación: AWS · Qué es AWS Organizations ↗ · AWS · Buenas prácticas para la cuenta de administración ↗

Paso 2: crea la unidad organizacional production#

En la vista de estructura, selecciona Root, que será el padre de la nueva OU, y luego elige Organizational unit > Create new.

Se abre el formulario de creación. En el campo Organizational unit name escribe production y pulsa Create organizational unit.

Al volver al árbol comprobarás dos cosas:

• La OU production aparece como hija de Root, tal como la definiste.
• La OU está vacía: todavía no contiene ninguna cuenta ni otra OU.

Una OU vacía no cuesta nada ni tiene efecto por sí misma. Su valor aparece cuando le asignas cuentas y políticas.

Documentación: AWS · Crear una unidad organizacional ↗

Paso 3: crea la cuenta de AWS de producción#

Ahora crea la cuenta que vivirá en esa OU. Pulsa Add an AWS account y deja seleccionada la opción por defecto, Create an AWS account. Completa el formulario:

• AWS account name: lo práctico es usar el mismo nombre que la OU o el patrón carga-entorno (por ejemplo production o tienda-prod). Es solo una etiqueta y puedes cambiarla después.
• Email address of the account's owner: el correo del usuario raíz de la nueva cuenta. Debe ser válido y no estar usado por otra cuenta de AWS. Puede ser un alias; por ejemplo, Gmail y muchos proveedores aceptan direcciones con +, como [email protected]. Mejor aún si es una lista de distribución del equipo y no el buzón de una sola persona.
• IAM role name: deja el valor por defecto, OrganizationAccountAccessRole. Organizations crea ese rol en la cuenta nueva con permisos de administrador y confianza hacia la cuenta de administración, para que puedas entrar sin usar credenciales raíz.

Pulsa Create AWS account. La creación es asíncrona y puede tardar unos minutos; la consola muestra una notificación y puedes seguir el progreso con View all pending creation requests.

Cuando termina, la cuenta aparece en el árbol en el primer nivel, directamente bajo Root. Esto es esperado: las cuentas creadas desde la consola nacen en Root.

Documentación: AWS · Crear una cuenta miembro ↗ · AWS · Acceder a cuentas miembro con OrganizationAccountAccessRole ↗

Paso 4: mueve la cuenta a la OU correcta#

Para que la cuenta herede las políticas de production, muévela de Root a la OU:

• Selecciona la casilla de la cuenta production en el árbol.
• Elige Actions y, bajo AWS account, la opción Move.
• Indica la OU de destino, production, y pulsa Move AWS account.

Despliega la OU production para validar que la cuenta ahora está dentro. Este paso también demuestra algo útil: la jerarquía no es rígida. Puedes mover cuentas entre OUs más adelante si reorganizas tu estructura, aunque ten presente que al moverla la cuenta deja de heredar las políticas de la OU anterior y pasa a heredar las de la nueva, así que revisa las SCPs antes de hacerlo en producción.

Documentación: AWS · Mover cuentas entre OUs ↗

Automatízalo: AWS CLI y Terraform#

La consola es perfecta para entender el proceso. Para repetirlo sin errores (otra cuenta para staging, otra para sandbox) conviene tenerlo como código. Estos son los mismos pasos con la AWS CLI:

# Ejecutar con credenciales de la cuenta de administración
ROOT_ID=$(aws organizations list-roots --query 'Roots[0].Id' --output text)

# 1. Crear la OU "production" bajo Root
OU_ID=$(aws organizations create-organizational-unit \
  --parent-id "$ROOT_ID" --name production \
  --query 'OrganizationalUnit.Id' --output text)

# 2. Crear la cuenta miembro (asíncrono: devuelve un request id)
REQ_ID=$(aws organizations create-account \
  --account-name production \
  --email [email protected] \
  --role-name OrganizationAccountAccessRole \
  --query 'CreateAccountStatus.Id' --output text)

# 3. Consultar el estado hasta que sea SUCCEEDED
aws organizations describe-create-account-status \
  --create-account-request-id "$REQ_ID"

# 4. Mover la cuenta de Root a la OU production
aws organizations move-account --account-id <ID_DE_LA_CUENTA> \
  --source-parent-id "$ROOT_ID" --destination-parent-id "$OU_ID"

Con Terraform puedes declarar la OU y la cuenta, y crear la cuenta directamente dentro de la OU con parent_id, lo que evita el paso de moverla:

data "aws_organizations_organization" "this" {}

resource "aws_organizations_organizational_unit" "production" {
  name      = "production"
  parent_id = data.aws_organizations_organization.this.roots[0].id
}

resource "aws_organizations_account" "production" {
  name      = "production"
  email     = "[email protected]"
  role_name = "OrganizationAccountAccessRole"
  # Se crea directamente dentro de la OU: no hace falta moverla después
  parent_id = aws_organizations_organizational_unit.production.id

  lifecycle {
    ignore_changes = [role_name]
  }
}

Documentación: Terraform AWS provider · aws_organizations_organizational_unit ↗ · Terraform AWS provider · aws_organizations_account ↗ · AWS · Crear una cuenta miembro ↗

Guardrails: SCPs, accesos y la cuenta de administración#

Tener cuentas separadas es la base; los guardrails son lo que la convierte en una estructura segura.

Service Control Policies (SCPs). Se adjuntan a Root, a una OU o a una cuenta y definen el máximo de permisos disponibles en las cuentas afectadas. No otorgan permisos por sí solas: limitan lo que IAM puede conceder. Un detalle importante: las SCPs no afectan a los usuarios ni roles de la cuenta de administración, otra razón para no desplegar cargas ahí.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeavingTheOrganization",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    }
  ]
}

Accesos. En lugar de compartir credenciales raíz o crear usuarios IAM en cada cuenta, usa IAM Identity Center para dar a cada persona acceso a las cuentas que necesita con permisos acotados. Protege el usuario raíz de cada cuenta con MFA y no lo uses para el trabajo diario.

Accesos. En lugar de compartir credenciales raíz o crear usuarios IAM en cada cuenta, usa IAM Identity Center (lo vemos en la siguiente sección). Protege el usuario raíz de cada cuenta con MFA y no lo uses para el trabajo diario.

Documentación: AWS · Service Control Policies (SCPs) ↗ · AWS · Qué es IAM Identity Center ↗ · AWS · Buenas prácticas para la cuenta de administración ↗ · AWS Well-Architected · Pilar de seguridad ↗ · AWS · Ejemplos de SCPs ↗

Accesos con IAM Identity Center#

Con varias cuentas, crear usuarios IAM en cada una se vuelve inmanejable. IAM Identity Center centraliza el acceso: conectas una fuente de identidad (su directorio propio, Active Directory o un proveedor externo como Okta o Microsoft Entra ID), defines permission sets y asignas grupos a cuentas concretas. Cada persona entra por un portal único y obtiene credenciales temporales para la cuenta y el rol que le toca.

• Habilita IAM Identity Center desde la cuenta de administración de la organización y elige la fuente de identidad.
• Considera delegar la administración de Identity Center a una cuenta miembro, para que el día a día no requiera entrar a la cuenta de administración.
• Crea permission sets por función (por ejemplo AdministratorAccess para el equipo de plataforma, ReadOnly para consultas en producción) en lugar de por persona.
• Asigna grupos, no usuarios individuales, a cada cuenta con el permission set adecuado: acceso amplio en sandbox y staging, acotado en producción.

data "aws_ssoadmin_instances" "this" {}

locals {
  sso_instance_arn = tolist(data.aws_ssoadmin_instances.this.arns)[0]
}

# Permission set: un conjunto de permisos reutilizable en varias cuentas
resource "aws_ssoadmin_permission_set" "read_only" {
  name             = "ReadOnly"
  instance_arn     = local.sso_instance_arn
  session_duration = "PT4H"
}

resource "aws_ssoadmin_managed_policy_attachment" "read_only" {
  instance_arn       = local.sso_instance_arn
  permission_set_arn = aws_ssoadmin_permission_set.read_only.arn
  managed_policy_arn = "arn:aws:iam::aws:policy/ReadOnlyAccess"
}

# Asignación: el grupo "developers" entra a producción solo en lectura
resource "aws_ssoadmin_account_assignment" "developers_prod" {
  instance_arn       = local.sso_instance_arn
  permission_set_arn = aws_ssoadmin_permission_set.read_only.arn
  principal_type     = "GROUP"
  principal_id       = var.developers_group_id
  target_type        = "AWS_ACCOUNT"
  target_id          = aws_organizations_account.production.id
}

Documentación: AWS · Primeros pasos con IAM Identity Center ↗ · AWS · Permission sets ↗ · AWS · Administración delegada de IAM Identity Center ↗ · Terraform AWS provider · aws_ssoadmin_permission_set ↗ · Terraform AWS provider · aws_ssoadmin_account_assignment ↗

Facturación: una factura, costos por cuenta#

Organizations activa la facturación consolidada: la cuenta de administración paga una sola factura que suma el uso de todas las cuentas miembro. Esa es la razón práctica para separar por cuenta: el costo de cada entorno y de cada carga de trabajo aparece desglosado sin tener que etiquetar cada recurso a la perfección.

• Agrupa por cuenta vinculada (linked account) en Cost Explorer para ver el gasto de cada entorno y aplicación.
• Activa etiquetas de asignación de costos (por ejemplo team o project) desde la cuenta de administración para desglosar dentro de una cuenta compartida. Las etiquetas solo aparecen en los reportes después de activarlas.
• Crea presupuestos con AWS Budgets por cuenta, sobre todo en sandbox, con alertas antes de llegar al límite.
• Ten en cuenta que, por defecto, los descuentos de Reserved Instances y Savings Plans se comparten entre las cuentas de la organización; puedes desactivar ese reparto por cuenta si necesitas asignar el ahorro a un equipo concreto.

Documentación: AWS · Facturación consolidada ↗ · AWS · Etiquetas de asignación de costos ↗ · AWS · Gestionar costos con AWS Budgets ↗ · AWS · Desactivar el reparto de descuentos de RI y Savings Plans ↗

Checklist de la estructura#

• La cuenta de administración no ejecuta cargas de trabajo.
• Producción vive en su propia cuenta, dentro de una OU production.
• Staging, QA y sandbox están en cuentas y OUs separadas de producción.
• Cada cuenta usa un correo de equipo válido y único, y el usuario raíz tiene MFA.
• El acceso a las cuentas se hace con IAM Identity Center u OrganizationAccountAccessRole, no con credenciales raíz compartidas.
• Hay al menos una SCP base aplicada y probada antes en una OU de pruebas.
• La estructura está en código (CLI o Terraform) para poder repetirla.
• Cada carga de trabajo tiene su cuenta por entorno, o el diseño permite separarla sin rehacer la estructura.
• Hay presupuestos por cuenta y las etiquetas de costos que usas están activadas.

Con orden desde el diseño, añadir un entorno nuevo pasa de ser un proyecto a ser un cambio de pocas líneas. Es una base que escala a medida que crecen los equipos y los proyectos.

Documentación: AWS · OUs y cuentas recomendadas ↗